From nobody Mon Feb 6 09:31:26 2017 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 3A9C71295A4 for ; Mon, 6 Feb 2017 09:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 CXs_AD8XoFcq for ; Mon, 6 Feb 2017 09:31:23 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 C2CFB129418 for ; Mon, 6 Feb 2017 09:31:23 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id w204so50853779oiw.0 for ; Mon, 06 Feb 2017 09:31:23 -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; bh=wYxQVWPjA6FaG9NvKBJajQtvPtFvFzzCd3tv8cMTEZY=; b=FjazVEQQwx1G+BmNB1CxSDj2cwm8OzuuzqaQvcIxklOiULS7ZRvfxhOb4dgz9yFAVq 4gvBE3W/YoC6iZ7e5zzTWAlPUDnqXY3eAJKpzvhr9qbiJHzLY2J0Cy/C2WCAkyKbUpH2 f7qijeNtcbkLB2+5ntDTEYVxyJfV+NWhxnShJ//Dn3lqqYFiPz4BjzEncoxWdQiMFazS t5/boU5X8VKvdbhX5WjnHaUUdm/i1hk6RhxZlFGooA4tg14reZnkLX1DDX8C4WO/5ptF Q+a56i5v2D1MCaAOsPq44k8klc7h90DM8aZ94ZonmsVhLGIcr65vyJgyJMDeFSb7mgf3 gwow== 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; bh=wYxQVWPjA6FaG9NvKBJajQtvPtFvFzzCd3tv8cMTEZY=; b=clD8uWSGnqB2HNaF4UK+LJJT+vrsueo9T2KOpGNFZKzjhS3qrwbbHDfiXxzOsBke7V RC5lUCO8uiHtAgD5jRZmyS9fSqFIBNE1kNa4M+k6Mfx5YngBf8m2aOns8m9HZdfYVtGh ZD3N7yQvT31eGkBaHriTHfFJAj4mCpwH+HHLwMEeyg820+u84oyLfL5tQFcMAr4ZZF86 6+KQZg0H3yE2SPOzYbxZF2b3+t3vT4juD1CX4JIrRZmdDV58sq/KVSKi1CSXqQNe3Luv z4aCks864NypsX4e1TZENj/Ppu9axxKUJS+J9UKXFK/TpZjum3DWiEQxyla7uAJPEnQu 7Wfg== X-Gm-Message-State: AMke39mi4jGlktFeOZTUdVLR8+SPpLwrfy6JpdZGfL/BzRdRj2q+MIaouAQQ3zdS8MRnMTigJQgUYy3TwPVfPA== X-Received: by 10.202.239.2 with SMTP id n2mr5888672oih.157.1486402282876; Mon, 06 Feb 2017 09:31:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Mon, 6 Feb 2017 09:31:22 -0800 (PST) From: Greg Mirsky Date: Mon, 6 Feb 2017 09:31:22 -0800 Message-ID: To: sfc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0931da10779c0547e0001d Archived-At: Subject: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:31:25 -0000 --94eb2c0931da10779c0547e0001d Content-Type: text/plain; charset=UTF-8 Dear All, during SFC WG interim meeting support of infinite loop prevention by introducing TTL field was proposed and discussed. This and other proposals will change NSH Base Header affecting existing implementations. The discussion of backward compatibily have started but, as I recal, we haven't reached any conclusion. I'd like to propose couple changes to Value field: - Section 3.2 OLD TEXT Version: The version field is used to ensure backward compatibility going forward with future NSH updates. It MUST be set to 0x0 by the sender, in this first revision of NSH. Given the widespread implementation of existing hardware that uses the first nibble after an MPLS label stack for ECMP decision processing, this document reserves version 01 and this value MUST NOT be used in future versions of the protocol. Please see [RFC7325 ] for further discussion of MPLS-related forwarding requirements. NEW TEXT Version: The version field is used to ensure backward compatibility going forward with future NSH updates. It MUST be set to 0x10 by the sender, in this revision of NSH. Given the widespread implementation of existing hardware that uses the first nibble after an MPLS label stack for ECMP decision processing, this document reserves version 0x01 and this value MUST NOT be used in future versions of the protocol. Value of 0x00 is reserved for Experimental use in Section 12.2.1. [Please see [RFC7325 ] for further discussion of MPLS-related forwarding requirements. - Section 12.2.1 OLD TEXT Version 00: This protocol version. This document. Version 01: Reserved. This document. Version 10: Unassigned. Version 11: Unassigned. NEW TEXT Version 0x00: Experimental. This document. Version 0x01: Reserved. This document. Version 0x10: This protocol version. This document. Version 0x11: Unassigned. Appreciate your comments, suggestions. Regards, Greg --94eb2c0931da10779c0547e0001d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
during SFC WG interim meeting support of inf= inite loop prevention by introducing TTL field was proposed and discussed. = This and other proposals will change NSH Base Header affecting existing imp= lementations. The discussion of backward compatibily have started but, as I= recal, we haven't reached any conclusion. I'd like to propose coup= le changes to Value field:
  • Section 3.2
OLD TEXT<= /div>
  Version: The version field is=
 used to ensure backward compatibility
   going forward with future NSH updates.  It MUST be set to 0x0 by the
   sender, in this first revision of NSH.  Given the widespread
   implementation of existing hardware that uses the first nibble after
   an MPLS label stack for ECMP decision processing, this document
   reserves version 01 and this value MUST NOT be used in future
   versions of the protocol.  Please see [RFC7325] for further
   discussion of MPLS-related forwarding requirements.
NEW TEXT
  Version: =
The version field is used to ensure backward compatibility
   going forward with future NSH updates.  It MUST be set to 0x10 by the
   sender, in this revision of NSH.  Given the widespread
   implementation of existing hardware that uses the first nibble after
   an MPLS label stack for ECMP decision processing, this document
   reserves version 0x01 and this value MUST NOT be used in future
   versions of the protocol.  Value of 0x00 is reserved for Experimental
   use in Section 12.2.1. [Please see =
[RFC7325] for furthe=
r
   discussion of MPLS-related forwarding requirements.

  • Section 12.2.1
OLD TEXT
   Version 00: This protocol version.  This docum=
ent.
   Version 01: Reserved.  This document.
   Version 10: Unassigned.
   Version 11: Unassigned.

NEW TEXT
   Version =
0x00: Experimental.  This document.
   Version 0x01: Reserved.  This document.
   Version 0x10: This protocol version. This document.
   Version 0x11: Unassigned.


Appreciate your comments, suggestions.

Regards,
Greg

--94eb2c0931da10779c0547e0001d-- From nobody Mon Feb 6 09:35:57 2017 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 D0F57129418 for ; Mon, 6 Feb 2017 09:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 2xiqv2nuwaux for ; Mon, 6 Feb 2017 09:35:54 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7060D128B44 for ; Mon, 6 Feb 2017 09:35:54 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Feb 2017 12:35:52 -0500 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Mon, 6 Feb 2017 12:35:52 -0500 From: Dave Dolson To: Greg Mirsky , "sfc@ietf.org" Thread-Topic: [sfc] Continue discussion of changes to NSH Thread-Index: AQHSgJ7aC4LNGAIn5UO9FHAqOiXhDqFcPMDw Date: Mon, 6 Feb 2017 17:35:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98704FC7C1wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:35:56 -0000 --_000_E8355113905631478EFF04F5AA706E98704FC7C1wtlexchp1sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCk9uIHRoZSBjb250cmFyeSwgSSB1bmRlcnN0b29kIHdlIGhhZCBkZXZpc2VkIGEgbWVj aGFuaXNtIHRoYXQgd291bGQgTk9UIHJlcXVpcmUgY2hhbmdpbmcgdGhlIHZlcnNpb24gbnVtYmVy Lg0KDQpUaGUgYmFzaWMgaWRlYSB3YXMgdGhhdCBieSB1c2luZyB0aGUgdW5hc3NpZ25lZCBmbGFn cyBmaWVsZHMsIG5vIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyB3b3VsZCBiZSByZWFkaW5nIG9y IGNoYW5naW5nIHRob3NlIGZpZWxkcy4gU28gYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaXMgYWNo aWV2ZWQgYnkgYWNjZXB0aW5nIHRoYXQgbm90IGFsbCBmb3J3YXJkZXJzIG9yIFNGcyB3b3VsZCBi dW1wIHRoZSBob3AgY291bnQuDQoNCkkgaG9wZSB3ZSBjYW4gc2VlIHRoaXMgc29vbiBpbiBhIG5l dyB2ZXJzaW9uIG9mIHRoZSBkcmFmdOKApg0KDQotRGF2ZQ0KDQoNCkZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IE1v bmRheSwgRmVicnVhcnkgMDYsIDIwMTcgMTI6MzEgUE0NClRvOiBzZmNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFtzZmNdIENvbnRpbnVlIGRpc2N1c3Npb24gb2YgY2hhbmdlcyB0byBOU0gNCg0KRGVhciBB bGwsDQpkdXJpbmcgU0ZDIFdHIGludGVyaW0gbWVldGluZyBzdXBwb3J0IG9mIGluZmluaXRlIGxv b3AgcHJldmVudGlvbiBieSBpbnRyb2R1Y2luZyBUVEwgZmllbGQgd2FzIHByb3Bvc2VkIGFuZCBk aXNjdXNzZWQuIFRoaXMgYW5kIG90aGVyIHByb3Bvc2FscyB3aWxsIGNoYW5nZSBOU0ggQmFzZSBI ZWFkZXIgYWZmZWN0aW5nIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4gVGhlIGRpc2N1c3Npb24g b2YgYmFja3dhcmQgY29tcGF0aWJpbHkgaGF2ZSBzdGFydGVkIGJ1dCwgYXMgSSByZWNhbCwgd2Ug aGF2ZW4ndCByZWFjaGVkIGFueSBjb25jbHVzaW9uLiBJJ2QgbGlrZSB0byBwcm9wb3NlIGNvdXBs ZSBjaGFuZ2VzIHRvIFZhbHVlIGZpZWxkOg0KDQogICogICBTZWN0aW9uIDMuMg0KT0xEIFRFWFQN Cg0KICBWZXJzaW9uOiBUaGUgdmVyc2lvbiBmaWVsZCBpcyB1c2VkIHRvIGVuc3VyZSBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5DQoNCiAgIGdvaW5nIGZvcndhcmQgd2l0aCBmdXR1cmUgTlNIIHVwZGF0 ZXMuICBJdCBNVVNUIGJlIHNldCB0byAweDAgYnkgdGhlDQoNCiAgIHNlbmRlciwgaW4gdGhpcyBm aXJzdCByZXZpc2lvbiBvZiBOU0guICBHaXZlbiB0aGUgd2lkZXNwcmVhZA0KDQogICBpbXBsZW1l bnRhdGlvbiBvZiBleGlzdGluZyBoYXJkd2FyZSB0aGF0IHVzZXMgdGhlIGZpcnN0IG5pYmJsZSBh ZnRlcg0KDQogICBhbiBNUExTIGxhYmVsIHN0YWNrIGZvciBFQ01QIGRlY2lzaW9uIHByb2Nlc3Np bmcsIHRoaXMgZG9jdW1lbnQNCg0KICAgcmVzZXJ2ZXMgdmVyc2lvbiAwMSBhbmQgdGhpcyB2YWx1 ZSBNVVNUIE5PVCBiZSB1c2VkIGluIGZ1dHVyZQ0KDQogICB2ZXJzaW9ucyBvZiB0aGUgcHJvdG9j b2wuICBQbGVhc2Ugc2VlIFtSRkM3MzI1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 MzI1Pl0gZm9yIGZ1cnRoZXINCg0KICAgZGlzY3Vzc2lvbiBvZiBNUExTLXJlbGF0ZWQgZm9yd2Fy ZGluZyByZXF1aXJlbWVudHMuDQoNCk5FVyBURVhUDQoNCiAgVmVyc2lvbjogVGhlIHZlcnNpb24g ZmllbGQgaXMgdXNlZCB0byBlbnN1cmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eQ0KDQogICBnb2lu ZyBmb3J3YXJkIHdpdGggZnV0dXJlIE5TSCB1cGRhdGVzLiAgSXQgTVVTVCBiZSBzZXQgdG8gMHgx MCBieSB0aGUNCg0KICAgc2VuZGVyLCBpbiB0aGlzIHJldmlzaW9uIG9mIE5TSC4gIEdpdmVuIHRo ZSB3aWRlc3ByZWFkDQoNCiAgIGltcGxlbWVudGF0aW9uIG9mIGV4aXN0aW5nIGhhcmR3YXJlIHRo YXQgdXNlcyB0aGUgZmlyc3QgbmliYmxlIGFmdGVyDQoNCiAgIGFuIE1QTFMgbGFiZWwgc3RhY2sg Zm9yIEVDTVAgZGVjaXNpb24gcHJvY2Vzc2luZywgdGhpcyBkb2N1bWVudA0KDQogICByZXNlcnZl cyB2ZXJzaW9uIDB4MDEgYW5kIHRoaXMgdmFsdWUgTVVTVCBOT1QgYmUgdXNlZCBpbiBmdXR1cmUN Cg0KICAgdmVyc2lvbnMgb2YgdGhlIHByb3RvY29sLiAgVmFsdWUgb2YgMHgwMCBpcyByZXNlcnZl ZCBmb3IgRXhwZXJpbWVudGFsDQoNCiAgIHVzZSBpbiBTZWN0aW9uIDEyLjIuMS4gW1BsZWFzZSBz ZWUgW1JGQzczMjU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzczMjU+XSBmb3IgZnVy dGhlcg0KDQogICBkaXNjdXNzaW9uIG9mIE1QTFMtcmVsYXRlZCBmb3J3YXJkaW5nIHJlcXVpcmVt ZW50cy4NCg0KDQoNCsK3ICAgICAgICAgU2VjdGlvbiAxMi4yLjENCg0KT0xEIFRFWFQNCg0KICAg VmVyc2lvbiAwMDogVGhpcyBwcm90b2NvbCB2ZXJzaW9uLiAgVGhpcyBkb2N1bWVudC4NCg0KICAg VmVyc2lvbiAwMTogUmVzZXJ2ZWQuICBUaGlzIGRvY3VtZW50Lg0KDQogICBWZXJzaW9uIDEwOiBV bmFzc2lnbmVkLg0KDQogICBWZXJzaW9uIDExOiBVbmFzc2lnbmVkLg0KDQpORVcgVEVYVA0KDQog ICBWZXJzaW9uIDB4MDA6IEV4cGVyaW1lbnRhbC4gIFRoaXMgZG9jdW1lbnQuDQoNCiAgIFZlcnNp b24gMHgwMTogUmVzZXJ2ZWQuICBUaGlzIGRvY3VtZW50Lg0KDQogICBWZXJzaW9uIDB4MTA6IFRo aXMgcHJvdG9jb2wgdmVyc2lvbi4gVGhpcyBkb2N1bWVudC4NCg0KICAgVmVyc2lvbiAweDExOiBV bmFzc2lnbmVkLg0KDQoNCg0KQXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzLCBzdWdnZXN0aW9ucy4N Cg0KDQoNClJlZ2FyZHMsDQoNCkdyZWcNCg0KDQo= --_000_E8355113905631478EFF04F5AA706E98704FC7C1wtlexchp1sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDo1MDA5NzU2ODM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTQy NjMxNDY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE0MjQx ODgwODk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjc4MTA4NzIyODt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HcmVnLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5PbiB0aGUgY29udHJhcnksIEkgdW5kZXJzdG9vZCB3ZSBoYWQg ZGV2aXNlZCBhIG1lY2hhbmlzbSB0aGF0IHdvdWxkIE5PVCByZXF1aXJlIGNoYW5naW5nIHRoZSB2 ZXJzaW9uIG51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBiYXNpYyBpZGVhIHdhcyB0aGF0IGJ5IHVzaW5n IHRoZSB1bmFzc2lnbmVkIGZsYWdzIGZpZWxkcywgbm8gZXhpc3RpbmcgaW1wbGVtZW50YXRpb25z IHdvdWxkIGJlIHJlYWRpbmcgb3IgY2hhbmdpbmcgdGhvc2UgZmllbGRzLiBTbyBiYWNrd2FyZHMg Y29tcGF0aWJpbGl0eQ0KIGlzIGFjaGlldmVkIGJ5IGFjY2VwdGluZyB0aGF0IG5vdCBhbGwgZm9y d2FyZGVycyBvciBTRnMgd291bGQgYnVtcCB0aGUgaG9wIGNvdW50LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBob3Bl IHdlIGNhbiBzZWUgdGhpcyBzb29uIGluIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ04oCmPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5HcmVnIE1pcnNreTxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDA2LCAyMDE3IDEyOjMxIFBNPGJyPg0KPGI+VG86PC9i PiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NmY10gQ29udGludWUgZGlzY3Vz c2lvbiBvZiBjaGFuZ2VzIHRvIE5TSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRlYXIgQWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmR1cmluZyBTRkMgV0cgaW50ZXJpbSBtZWV0aW5nIHN1cHBvcnQgb2YgaW5maW5pdGUgbG9vcCBw cmV2ZW50aW9uIGJ5IGludHJvZHVjaW5nIFRUTCBmaWVsZCB3YXMgcHJvcG9zZWQgYW5kIGRpc2N1 c3NlZC4gVGhpcyBhbmQgb3RoZXIgcHJvcG9zYWxzIHdpbGwgY2hhbmdlIE5TSCBCYXNlIEhlYWRl ciBhZmZlY3RpbmcgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLiBUaGUgZGlzY3Vzc2lvbiBvZiBi YWNrd2FyZCBjb21wYXRpYmlseQ0KIGhhdmUgc3RhcnRlZCBidXQsIGFzIEkgcmVjYWwsIHdlIGhh dmVuJ3QgcmVhY2hlZCBhbnkgY29uY2x1c2lvbi4gSSdkIGxpa2UgdG8gcHJvcG9zZSBjb3VwbGUg Y2hhbmdlcyB0byBWYWx1ZSBmaWVsZDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KU2VjdGlvbiAzLjI8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9MRCBURVhUPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IFZlcnNpb246IFRoZSB2ZXJzaW9uIGZpZWxkIGlz IHVzZWQgdG8gZW5zdXJlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZ29pbmcg Zm9yd2FyZCB3aXRoIGZ1dHVyZSBOU0ggdXBkYXRlcy4mbmJzcDsgSXQgTVVTVCBiZSBzZXQgdG8g MHgwIGJ5IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzZW5kZXIsIGluIHRoaXMgZmlyc3QgcmV2aXNpb24gb2Yg TlNILiZuYnNwOyBHaXZlbiB0aGUgd2lkZXNwcmVhZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRhdGlv biBvZiBleGlzdGluZyBoYXJkd2FyZSB0aGF0IHVzZXMgdGhlIGZpcnN0IG5pYmJsZSBhZnRlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBhbiBNUExTIGxhYmVsIHN0YWNrIGZvciBFQ01QIGRlY2lzaW9uIHByb2Nlc3Np bmcsIHRoaXMgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVzZXJ2ZXMgdmVyc2lvbiAwMSBhbmQgdGhp cyB2YWx1ZSBNVVNUIE5PVCBiZSB1c2VkIGluIGZ1dHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB2ZXJzaW9ucyBv ZiB0aGUgcHJvdG9jb2wuJm5ic3A7IFBsZWFzZSBzZWUgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3MzI1IiB0aXRsZT0iJnF1b3Q7TVBMUyBGb3J3YXJkaW5nIENvbXBs aWFuY2UgYW5kIFBlcmZvcm1hbmNlIFJlcXVpcmVtZW50cyZxdW90OyI+UkZDNzMyNTwvYT5dIGZv ciBmdXJ0aGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRpc2N1c3Npb24gb2YgTVBMUy1yZWxhdGVkIGZvcndhcmRp bmcgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPk5FVyBURVhUPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IFZlcnNpb246IFRoZSB2ZXJzaW9uIGZpZWxk IGlzIHVzZWQgdG8gZW5zdXJlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZ29p bmcgZm9yd2FyZCB3aXRoIGZ1dHVyZSBOU0ggdXBkYXRlcy4mbmJzcDsgSXQgTVVTVCBiZSBzZXQg dG8gMHgxMCBieSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2VuZGVyLCBpbiB0aGlzIHJldmlzaW9uIG9mIE5T SC4mbmJzcDsgR2l2ZW4gdGhlIHdpZGVzcHJlYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24g b2YgZXhpc3RpbmcgaGFyZHdhcmUgdGhhdCB1c2VzIHRoZSBmaXJzdCBuaWJibGUgYWZ0ZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgYW4gTVBMUyBsYWJlbCBzdGFjayBmb3IgRUNNUCBkZWNpc2lvbiBwcm9jZXNzaW5n LCB0aGlzIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJlc2VydmVzIHZlcnNpb24gMHgwMSBhbmQgdGhp cyB2YWx1ZSBNVVNUIE5PVCBiZSB1c2VkIGluIGZ1dHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB2ZXJzaW9ucyBv ZiB0aGUgcHJvdG9jb2wuJm5ic3A7IFZhbHVlIG9mIDB4MDAgaXMgcmVzZXJ2ZWQgZm9yIEV4cGVy aW1lbnRhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyB1c2UgaW4gU2VjdGlvbiAxMi4yLjEuIFtQbGVhc2Ugc2VlIFs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzMyNSIgdGl0bGU9IiZxdW90 O01QTFMgRm9yd2FyZGluZyBDb21wbGlhbmNlIGFuZCBQZXJmb3JtYW5jZSBSZXF1aXJlbWVudHMm cXVvdDsiPlJGQzczMjU8L2E+XSBmb3IgZnVydGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBkaXNjdXNzaW9uIG9m IE1QTFMtcmVsYXRlZCBmb3J3YXJkaW5nIHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNlY3Rpb24gMTIuMi4xPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T0xE IFRFWFQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgVmVyc2lvbiAwMDogVGhpcyBwcm90b2NvbCB2ZXJzaW9uLiZuYnNw OyBUaGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBWZXJzaW9uIDAxOiBSZXNlcnZlZC4mbmJzcDsg VGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVmVyc2lvbiAxMDogVW5hc3NpZ25lZC48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgVmVyc2lvbiAxMTogVW5hc3NpZ25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxk aXY+DQo8cHJlPk5FVyBURVhUPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVmVyc2lvbiAweDAwOiBFeHBl cmltZW50YWwuJm5ic3A7IFRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFZlcnNpb24gMHgwMTog UmVzZXJ2ZWQuJm5ic3A7IFRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFZlcnNpb24gMHgxMDog VGhpcyBwcm90b2NvbCB2ZXJzaW9uLiBUaGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBWZXJzaW9u IDB4MTE6IFVuYXNzaWduZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzLCBzdWdnZXN0 aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0K PGRpdj4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E8355113905631478EFF04F5AA706E98704FC7C1wtlexchp1sandvi_-- From nobody Mon Feb 6 09:40:05 2017 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 A62D4129418 for ; Mon, 6 Feb 2017 09:40:03 -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 ej6PqSqfxiGR for ; Mon, 6 Feb 2017 09:40:01 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 9FE3C1293D8 for ; Mon, 6 Feb 2017 09:40:01 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id 73so67448491otj.0 for ; Mon, 06 Feb 2017 09:40:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AH7vMBxo4IMo5MFiCgGXbkznwrRWdie8FkVWwbx0B24=; b=oU0eowOxe0WBTng+fX+hdrFK4iMunpAM6aMiYqJBWfNrLrS7Hk12TYBVcLiJyOAiiL Pzys1zmobG3wYwEoQsRp+8ILHvTXSwmwLZ4cAbm9CcRCO5sqWv3ETTAcZRnB5Z98fVa3 Am4UZiA8wiZDBk4MZKdVMCQOv7lYfIn/FB4YghhjfB3EEgcgsN6Wd+WcTHe9M4kNNS9o hQWrQfZgOQlYptGahaoRfjbgxO+n4Fb7+3fjNy+CV67gf3wyvMR9U+x5lQNU1lyZj/4P 1l0Cq4Q9JpDIIyy+J5eL+hGm9pwbEeuHBijZs2Gz6duJ/dMQaUSXHbxKoz4SwmfdT5nf h5bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AH7vMBxo4IMo5MFiCgGXbkznwrRWdie8FkVWwbx0B24=; b=o8DIFLM8mTLFIvJd8IWh9MnSGubATf0L+tfbSDx5C9oYIivWhsRLz6aE58+2P8jeIq uNEAKnZa7hzZtRDowoDrQ28piPn4hJ37tdePXM5dU4zQYDHASAqwwbrH61YZ/ucnA8q+ MLAjumEsCstxy8StyH+oCSB5HXFRdaGOIUdvMMBt0iVlqBeSIEyafFDpn6j/rp4jK5XW 6tyWvS+fTBI66gsChCL2bPsigdJiKyTG+/4jyQw8s+FN5TgmvHq5VJ92ecRmjHyS3H9g xDFDAdEc1QgxI1C5azS3FxoAlGkS7uO9hW8NYQII6uw5txKDh5IrrTY8nT3kcJ0C9kx6 weyA== X-Gm-Message-State: AIkVDXK+JsT/yd6Sf7VKyiUw6JnM92KAg0pqdw5/APX0zY6IGYi2Wv7KE00Ej6Y2koEHVT9gQKaMBlyfMbt44w== X-Received: by 10.157.38.237 with SMTP id i42mr6368183otd.76.1486402800945; Mon, 06 Feb 2017 09:40:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Mon, 6 Feb 2017 09:40:00 -0800 (PST) In-Reply-To: References: From: Greg Mirsky Date: Mon, 6 Feb 2017 09:40:00 -0800 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a11353282f1927a0547e01ec5 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:40:03 -0000 --001a11353282f1927a0547e01ec5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dave, thank you for the clarification. I've missed that part clearly. Let's wait for the new version and discuss it then. How many bits for TTL field were considered? Regards, Greg On Mon, Feb 6, 2017 at 9:35 AM, Dave Dolson wrote: > Greg, > > On the contrary, I understood we had devised a mechanism that would NOT > require changing the version number. > > > > The basic idea was that by using the unassigned flags fields, no existing > implementations would be reading or changing those fields. So backwards > compatibility is achieved by accepting that not all forwarders or SFs wou= ld > bump the hop count. > > > > I hope we can see this soon in a new version of the draft=E2=80=A6 > > > > -Dave > > > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Monday, February 06, 2017 12:31 PM > *To:* sfc@ietf.org > *Subject:* [sfc] Continue discussion of changes to NSH > > > > Dear All, > > during SFC WG interim meeting support of infinite loop prevention by > introducing TTL field was proposed and discussed. This and other proposal= s > will change NSH Base Header affecting existing implementations. The > discussion of backward compatibily have started but, as I recal, we haven= 't > reached any conclusion. I'd like to propose couple changes to Value field= : > > - Section 3.2 > > OLD TEXT > > Version: The version field is used to ensure backward compatibility > > going forward with future NSH updates. It MUST be set to 0x0 by the > > sender, in this first revision of NSH. Given the widespread > > implementation of existing hardware that uses the first nibble after > > an MPLS label stack for ECMP decision processing, this document > > reserves version 01 and this value MUST NOT be used in future > > versions of the protocol. Please see [RFC7325 ] for further > > discussion of MPLS-related forwarding requirements. > > NEW TEXT > > Version: The version field is used to ensure backward compatibility > > going forward with future NSH updates. It MUST be set to 0x10 by the > > sender, in this revision of NSH. Given the widespread > > implementation of existing hardware that uses the first nibble after > > an MPLS label stack for ECMP decision processing, this document > > reserves version 0x01 and this value MUST NOT be used in future > > versions of the protocol. Value of 0x00 is reserved for Experimental > > use in Section 12.2.1. [Please see [RFC7325 ] for further > > discussion of MPLS-related forwarding requirements. > > > > =C2=B7 Section 12.2.1 > > OLD TEXT > > Version 00: This protocol version. This document. > > Version 01: Reserved. This document. > > Version 10: Unassigned. > > Version 11: Unassigned. > > NEW TEXT > > Version 0x00: Experimental. This document. > > Version 0x01: Reserved. This document. > > Version 0x10: This protocol version. This document. > > Version 0x11: Unassigned. > > > > Appreciate your comments, suggestions. > > > > Regards, > > Greg > > > > --001a11353282f1927a0547e01ec5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,
thank you for the clarification. I've mis= sed that part clearly. Let's wait for the new version and discuss it th= en. How many bits for TTL field were considered?

R= egards,
Greg

On Mon, Feb 6, 2017 at 9:35 AM, Dave Dolson <ddolson@s= andvine.com> wrote:

Greg,

On the contrary, I unders= tood we had devised a mechanism that would NOT require changing the version= number.

=C2=A0

The basic idea was that b= y using the unassigned flags fields, no existing implementations would be r= eading or changing those fields. So backwards compatibility is achieved by accepting that not all forwarders or SFs would bump the hop= count.

=C2=A0

I hope we can see this so= on in a new version of the draft=E2=80=A6

=C2=A0

-Dave

=C2=A0

=C2=A0

From: sfc [mai= lto:sfc-bounces@i= etf.org] On Behalf Of Greg Mirsky
Sent: Monday, February 06, 2017 12:31 PM
To: sfc@ietf.org
Subject: [sfc] Continue discussion of changes to NSH

=C2=A0

Dear All,

during SFC WG interim meeting support of infinite lo= op prevention by introducing TTL field was proposed and discussed. This and= other proposals will change NSH Base Header affecting existing implementat= ions. The discussion of backward compatibily have started but, as I recal, we haven't reached any conclusion. I'= ;d like to propose couple changes to Value field:

  • Section 3.2

OLD TEXT

=C2=A0 Version: The version field is used =
to ensure backward compatibility
=C2=A0=C2=A0 going forward with future NSH=
 updates.=C2=A0 It MUST be set to 0x0 by the
=C2=A0=C2=A0 sender, in this first revisio=
n of NSH.=C2=A0 Given the widespread
=C2=A0=C2=A0 implementation of existing ha=
rdware that uses the first nibble after
=C2=A0=C2=A0 an MPLS label stack for ECMP =
decision processing, this document
=C2=A0=C2=A0 reserves version 01 and this =
value MUST NOT be used in future
=C2=A0=C2=A0 versions of the protocol.=C2=
=A0 Please see [RFC7325] for further
=C2=A0=C2=A0 discussion of MPLS-related fo=
rwarding requirements.
NEW TEXT
=C2=A0 Version: The version field is used =
to ensure backward compatibility
=C2=A0=C2=A0 going forward with future NSH=
 updates.=C2=A0 It MUST be set to 0x10 by the
=C2=A0=C2=A0 sender, in this revision of N=
SH.=C2=A0 Given the widespread
=C2=A0=C2=A0 implementation of existing ha=
rdware that uses the first nibble after
=C2=A0=C2=A0 an MPLS label stack for ECMP =
decision processing, this document
=C2=A0=C2=A0 reserves version 0x01 and thi=
s value MUST NOT be used in future
=C2=A0=C2=A0 versions of the protocol.=C2=
=A0 Value of 0x00 is reserved for Experimental
=C2=A0=C2=A0 use in Section 12.2.1. [Pleas=
e see [RFC7325] for further
=C2=A0=C2=A0 discussion of MPLS-related fo=
rwarding requirements.
=C2=A0
<=
span>=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 12.2.1
OLD TEXT
=C2=A0=C2=A0 Version 00: This protocol ver=
sion.=C2=A0 This document.
=C2=A0=C2=A0 Version 01: Reserved.=C2=A0 T=
his document.
=C2=A0=C2=A0 Version 10: Unassigned.
=C2=A0=C2=A0 Version 11: Unassigned.
NEW TEXT
=C2=A0=C2=A0 Version 0x00: Experimental.=
=C2=A0 This document.
=C2=A0=C2=A0 Version 0x01: Reserved.=C2=A0=
 This document.
=C2=A0=C2=A0 Version 0x10: This protocol v=
ersion. This document.
=C2=A0=C2=A0 Version 0x11: Unassigned.<=
/u>
=C2=A0
Appreciate your comments, suggestions.<=
/u>
=C2=A0
Regards,
Greg
=C2=A0

--001a11353282f1927a0547e01ec5-- From nobody Mon Feb 6 09:47:20 2017 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 B6E27129454 for ; Mon, 6 Feb 2017 09:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ZZcJWkZ5dOPt for ; Mon, 6 Feb 2017 09:47:18 -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 A666A129435 for ; Mon, 6 Feb 2017 09:47:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 903E11C0564; Mon, 6 Feb 2017 09:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486403238; bh=73pzIvPSt0F5nqz4mbF/gxeInYT1dTyvKgzwFRnlGLE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iZypVIwbxADUZy/FL+BYqKz1AGl24gkZCjtU9aBxzXEBP3CsuWmqFNYIK9Q8wVrfv iTySwMgSla5xIGINwFugYusO5zOjQ3Ks8Bw61uj0QgW+Ztyx58G0G4PEZGji6G0C8c K+fIyRKlsu8lQyX+IOQEov3bo+F3cBovo9hqvRHE= 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 04F971C018B; Mon, 6 Feb 2017 09:47:17 -0800 (PST) To: Dave Dolson , Greg Mirsky , "sfc@ietf.org" References: From: "Joel M. Halpern" Message-ID: <7e0d88e8-0e0c-6a1f-e8c9-5a01673214f4@joelhalpern.com> Date: Mon, 6 Feb 2017 12:47:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:47:19 -0000 Actually, Jim and I have an action item (on me, probably Wednesday) to provide an email to the list discussing the issue and approach. Regardign the version number, the goal of the approach is to avoid needing to change the version number while still preserving interoperability (although obviously not full support of the RFC-to-be) for existing implementations. Yours, Joel On 2/6/17 12:35 PM, Dave Dolson wrote: > Greg, > > On the contrary, I understood we had devised a mechanism that would NOT > require changing the version number. > > > > The basic idea was that by using the unassigned flags fields, no > existing implementations would be reading or changing those fields. So > backwards compatibility is achieved by accepting that not all forwarders > or SFs would bump the hop count. > > > > I hope we can see this soon in a new version of the draft… > > > > -Dave > > > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Monday, February 06, 2017 12:31 PM > *To:* sfc@ietf.org > *Subject:* [sfc] Continue discussion of changes to NSH > > > > Dear All, > > during SFC WG interim meeting support of infinite loop prevention by > introducing TTL field was proposed and discussed. This and other > proposals will change NSH Base Header affecting existing > implementations. The discussion of backward compatibily have started > but, as I recal, we haven't reached any conclusion. I'd like to propose > couple changes to Value field: > > * Section 3.2 > > OLD TEXT > > Version: The version field is used to ensure backward compatibility > > going forward with future NSH updates. It MUST be set to 0x0 by the > > sender, in this first revision of NSH. Given the widespread > > implementation of existing hardware that uses the first nibble after > > an MPLS label stack for ECMP decision processing, this document > > reserves version 01 and this value MUST NOT be used in future > > versions of the protocol. Please see [RFC7325 > ] for further > > discussion of MPLS-related forwarding requirements. > > NEW TEXT > > Version: The version field is used to ensure backward compatibility > > going forward with future NSH updates. It MUST be set to 0x10 by the > > sender, in this revision of NSH. Given the widespread > > implementation of existing hardware that uses the first nibble after > > an MPLS label stack for ECMP decision processing, this document > > reserves version 0x01 and this value MUST NOT be used in future > > versions of the protocol. Value of 0x00 is reserved for Experimental > > use in Section 12.2.1. [Please see [RFC7325 > ] for further > > discussion of MPLS-related forwarding requirements. > > > > · Section 12.2.1 > > OLD TEXT > > Version 00: This protocol version. This document. > > Version 01: Reserved. This document. > > Version 10: Unassigned. > > Version 11: Unassigned. > > NEW TEXT > > Version 0x00: Experimental. This document. > > Version 0x01: Reserved. This document. > > Version 0x10: This protocol version. This document. > > Version 0x11: Unassigned. > > > > Appreciate your comments, suggestions. > > > > Regards, > > Greg > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Feb 6 12:38:41 2017 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 D772A12963B for ; Mon, 6 Feb 2017 12:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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_LOW=-0.7, 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 mm6FpqPurUcb for ; Mon, 6 Feb 2017 12:38:38 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 E6B83129500 for ; Mon, 6 Feb 2017 12:38:37 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id u63so24189450wmu.2 for ; Mon, 06 Feb 2017 12:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ctIXISQ4/cDcemR8GY7aLceIBm0CImXV0sA5UItV1hk=; b=vTNwC0uMAyYBhFrBZ8gpStONzPlqe4de1HiP6lADayF9kdZhm5iZ++HMjFDpvga2ws YCipBG9swEXRgSOYtF/v3Wbf7EcjYBgFuUd69Ch2lgyTzyJNCY3IZners+0YwN/VApVS fydltvhxWnooA5cmNiNyAhkUA1DhmzmQLOWn3Z6+gzanbkPUvF4DvnnyCVenf1XSNZ4z CFIcB8L+qB1fVJD+MGS+zqfL0ZYoMyCyeIBXk+W5KwlLgmnQpgUUju6LOl/HjzC7Ob8o x68xCFNwgdpAHBCaIiAFvgJD+llKoA6qwDVpLTcQw6OX7Ibzq65FYurSZhcHWc9l+wLm xrzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=ctIXISQ4/cDcemR8GY7aLceIBm0CImXV0sA5UItV1hk=; b=XyeIW/0y8Pf7Bp1u37pCQp0fhkvEz1ghSGiYgOU5dJXOQeKc4IA2qADhav0qHcG6AK p0BZ3ivEh5L9S6rruy25kIpqKKqPfGyNRxMrxvUMXqDY/M1OdzUd6RCxDRSv9BQPWFgg ZS7xcOXcsf/+nmVYWlWMt9Kd++C5AhijXubwsc5qDBh+PKTZyNeRC4wgH8LHesfykvIQ CuakXoOWUGogLiGBBrSTrxXxQidxWSuVFj4qSyKg0Gbgk8/mm5Eb31AJCTJO91tUqK5k B154e0xRLUAy4Yc1M0pBFNB8SC3b0LODH1qU0PCyWcCWCkknInQBzJ6QNcUqnR3S+CMd Fffg== X-Gm-Message-State: AMke39m94ZaUgy93FSeLj70lMR4qm9ffB6jHink7M0sMKJlVqHEUALPvix7VObN87nLI2SlPHmkAHPyr/iA1rg== X-Received: by 10.28.196.133 with SMTP id u127mr9628563wmf.34.1486413516373; Mon, 06 Feb 2017 12:38:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.138.146 with HTTP; Mon, 6 Feb 2017 12:38:36 -0800 (PST) In-Reply-To: References: From: Behcet Sarikaya Date: Mon, 6 Feb 2017 14:38:36 -0600 Message-ID: To: Greg Mirsky Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 20:38:40 -0000 Hi Greg, On Mon, Feb 6, 2017 at 11:31 AM, Greg Mirsky wrote: > Dear All, > during SFC WG interim meeting support of infinite loop prevention by > introducing TTL field was proposed and discussed. This and other proposals > will change NSH Base Header affecting existing implementations. The > discussion of backward compatibily have started but, as I recal, we haven't > reached any conclusion. I'd like to propose couple changes to Value field: Sorry but I don't understand this discussion on backward compatibility. As far as I know SFC is not deployed. The nsh protocol in draft-ietf-sfc-nsh-10.txt has not been standardized, I.e. no RFC yet, no interoperability tests, no nothing. Why should the WG spend cycles on a "baby" that has not even born yet :)? Regards, Behcet > > Section 3.2 > > OLD TEXT > > Version: The version field is used to ensure backward compatibility > going forward with future NSH updates. It MUST be set to 0x0 by the > sender, in this first revision of NSH. Given the widespread > implementation of existing hardware that uses the first nibble after > an MPLS label stack for ECMP decision processing, this document > reserves version 01 and this value MUST NOT be used in future > versions of the protocol. Please see [RFC7325] for further > discussion of MPLS-related forwarding requirements. > > NEW TEXT > > Version: The version field is used to ensure backward compatibility > going forward with future NSH updates. It MUST be set to 0x10 by the > sender, in this revision of NSH. Given the widespread > implementation of existing hardware that uses the first nibble after > an MPLS label stack for ECMP decision processing, this document > reserves version 0x01 and this value MUST NOT be used in future > versions of the protocol. Value of 0x00 is reserved for Experimental > > use in Section 12.2.1. [Please see [RFC7325] for further > discussion of MPLS-related forwarding requirements. > > > Section 12.2.1 > > OLD TEXT > > Version 00: This protocol version. This document. > Version 01: Reserved. This document. > Version 10: Unassigned. > Version 11: Unassigned. > > NEW TEXT > > Version 0x00: Experimental. This document. > Version 0x01: Reserved. This document. > Version 0x10: This protocol version. This document. > Version 0x11: Unassigned. > > > Appreciate your comments, suggestions. > > > Regards, > > Greg > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Feb 6 13:13:19 2017 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 7BB431294EA for ; Mon, 6 Feb 2017 13:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 mVSRmjeKQpLB for ; Mon, 6 Feb 2017 13:13:16 -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 2C34B1294F1 for ; Mon, 6 Feb 2017 13:13:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 11B034602FC; Mon, 6 Feb 2017 13:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486415596; bh=K74G+ObMtk+jHvRWhNciMjcX5QZFkwWZ6NLdx+n9n5E=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=oWWgXkscDw6Ij8pqKjEaGj/mgDwH8n1nhsn7uMnaQzDCp5YLb2e+gZyUcY/wz768P MGUA9t/dYTzK4IPwDaPEgOvJ3NVBPHXZIpqyk7nleONKgihcQqrUIgOg7BlfDnIPXE ydLIhzv5vQAUt7XNDeaCG+wwQttL2ZoYFcrsjxuY= 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 99B4D4602F4; Mon, 6 Feb 2017 13:13:15 -0800 (PST) To: sarikaya@ieee.org References: From: "Joel M. Halpern" Message-ID: Date: Mon, 6 Feb 2017 16:13:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 21:13:18 -0000 We as a working group are free to make changes that we need technically. That is even the case after publication of a PS RFC. It is certainly the case before document completion. At the same time, folks have been implementing our work. Which is a good and highly desirable thing. So when we make changes, if we can do so in ways that reduce the pain for earlier implementors, that is desirable. Yours, Joel On 2/6/17 3:38 PM, Behcet Sarikaya wrote: > Hi Greg, > > > On Mon, Feb 6, 2017 at 11:31 AM, Greg Mirsky wrote: >> Dear All, >> during SFC WG interim meeting support of infinite loop prevention by >> introducing TTL field was proposed and discussed. This and other proposals >> will change NSH Base Header affecting existing implementations. The >> discussion of backward compatibily have started but, as I recal, we haven't >> reached any conclusion. I'd like to propose couple changes to Value field: > > Sorry but I don't understand this discussion on backward compatibility. > As far as I know SFC is not deployed. > The nsh protocol in > > draft-ietf-sfc-nsh-10.txt > has not been standardized, I.e. no RFC yet, no interoperability tests, > no nothing. > > Why should the WG spend cycles on a "baby" that has not even born yet :)? > > Regards, > > Behcet > >> >> Section 3.2 >> >> OLD TEXT >> >> Version: The version field is used to ensure backward compatibility >> going forward with future NSH updates. It MUST be set to 0x0 by the >> sender, in this first revision of NSH. Given the widespread >> implementation of existing hardware that uses the first nibble after >> an MPLS label stack for ECMP decision processing, this document >> reserves version 01 and this value MUST NOT be used in future >> versions of the protocol. Please see [RFC7325] for further >> discussion of MPLS-related forwarding requirements. >> >> NEW TEXT >> >> Version: The version field is used to ensure backward compatibility >> going forward with future NSH updates. It MUST be set to 0x10 by the >> sender, in this revision of NSH. Given the widespread >> implementation of existing hardware that uses the first nibble after >> an MPLS label stack for ECMP decision processing, this document >> reserves version 0x01 and this value MUST NOT be used in future >> versions of the protocol. Value of 0x00 is reserved for Experimental >> >> use in Section 12.2.1. [Please see [RFC7325] for further >> discussion of MPLS-related forwarding requirements. >> >> >> Section 12.2.1 >> >> OLD TEXT >> >> Version 00: This protocol version. This document. >> Version 01: Reserved. This document. >> Version 10: Unassigned. >> Version 11: Unassigned. >> >> NEW TEXT >> >> Version 0x00: Experimental. This document. >> Version 0x01: Reserved. This document. >> Version 0x10: This protocol version. This document. >> Version 0x11: Unassigned. >> >> >> Appreciate your comments, suggestions. >> >> >> Regards, >> >> Greg >> >> >> >> _______________________________________________ >> 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 Tue Feb 7 07:16:54 2017 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 9C4C7129CAB for ; Tue, 7 Feb 2017 07:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0vFdNlBaxeBL for ; Tue, 7 Feb 2017 07:16:50 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5A1129CA0 for ; Tue, 7 Feb 2017 07:16:49 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v17FGlIU026433; Tue, 7 Feb 2017 15:16:47 GMT Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v17FGhSq026375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2017 15:16:45 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: In-Reply-To: Date: Tue, 7 Feb 2017 15:16:43 -0000 Message-ID: <038401d28155$32626c40$972744c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMwW1cHrKG968Th9x+fN229nJwszwHbHX70AuxsmOiee7XvEA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22870.007 X-TM-AS-Result: No--36.036-10.0-31-10 X-imss-scan-details: No--36.036-10.0-31-10 X-TMASE-MatchedRID: oll/cJ/dUC5g1ikzUgbeZJU7Bltw5qVLMZm0+sEE9msGW3hFnC9N1XfJ eIW4slJZawXcTS0v2tswvNmv/UBFtGsV28ESZOe8aK+MsTwM+1kgzzoB6jqxgnyKcwQTdriqieN LxQp9Df73CpTH+JeALqhOh6D70UhxoFqeGJbCj1Xx5KZMlKYS/VHewY36PuY0zPV+pffXxU8tiY Zvl2ghiptFQKdM8wCFy9zCpgoSH0GOUv+G6OvDW691/YHX0i1lbv16+gil4jcifM7JMNHW64n0H W7/NyYsM2Tsx24vptBjbpWJNJ4FnAKqb6K4fx6OQpxiLlDD9FWeKBD/0uNkNoqUnvVNf36Dm4VT AbNZWtNjhWF3jds/0NeQ0sCk/jpIaOcyGCMoiI+9sVmyowX1j1NfPqmlqqgMRJWmeOMHa+QFyDe G+pLXl6kgaPEyjjoDrQHrXBQuxm+BodaikgIubQlojktAVaJI2aYdnwn7qHeTMTaQzhvoeilvGM mQeNSZZhkGmB04AKJQzokjoJLokIU36stNQ3oEqeBupNgLgYevFlDTfVnoWtUykPK1RFAoR05HQ qBvtpeX6o9MRYKNOt/s1qYy9uXiYw1f/0r5B964jAucHcCqnak89YpdLgI7mBadosOIaCHpnb3o TQwhQozIgBPIhs6Z+wH5AeQIx1QFCdq0JvYbZZ1U1lojafr/QZXZg2I8JabnU40jhQv76qPFjJE Fr+olfeZdJ1XsorhYoPZAqTBHwlZ0V5tYhzdWxEHRux+uk8jpP8tMOyYmaA== Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 15:16:52 -0000 Yes. Wot Joel sez. Basically, *if* we can add the function in a way that does not trash existing early implementations and that supports a mixed deployment, then let's do that. We thought in Westford that we had a way to do this. Admittedly it was invented somewhat on the fly and a couple of people needed to go home to check what this would do to their code. As Joel says, he and Jim took the action to write up (down?) what we discussed. But, I think it is clearly understood that if we can't find a (practical way) then the early implementers pay the price of early implementation and (probably) we cycle the version number (similar to Greg's proposal). We would certainly not be the first protocol to go to RFC with a version number that has incremented. Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 06 February 2017 21:13 > To: sarikaya@ieee.org > Cc: sfc@ietf.org > Subject: Re: [sfc] Continue discussion of changes to NSH > > We as a working group are free to make changes that we need technically. > That is even the case after publication of a PS RFC. It is certainly > the case before document completion. > > At the same time, folks have been implementing our work. Which is a > good and highly desirable thing. > > So when we make changes, if we can do so in ways that reduce the pain > for earlier implementors, that is desirable. > > Yours, > Joel > > On 2/6/17 3:38 PM, Behcet Sarikaya wrote: > > Hi Greg, > > > > > > On Mon, Feb 6, 2017 at 11:31 AM, Greg Mirsky > wrote: > >> Dear All, > >> during SFC WG interim meeting support of infinite loop prevention by > >> introducing TTL field was proposed and discussed. This and other proposals > >> will change NSH Base Header affecting existing implementations. The > >> discussion of backward compatibily have started but, as I recal, we haven't > >> reached any conclusion. I'd like to propose couple changes to Value field: > > > > Sorry but I don't understand this discussion on backward compatibility. > > As far as I know SFC is not deployed. > > The nsh protocol in > > > > draft-ietf-sfc-nsh-10.txt > > has not been standardized, I.e. no RFC yet, no interoperability tests, > > no nothing. > > > > Why should the WG spend cycles on a "baby" that has not even born yet :)? > > > > Regards, > > > > Behcet > > > >> > >> Section 3.2 > >> > >> OLD TEXT > >> > >> Version: The version field is used to ensure backward compatibility > >> going forward with future NSH updates. It MUST be set to 0x0 by the > >> sender, in this first revision of NSH. Given the widespread > >> implementation of existing hardware that uses the first nibble after > >> an MPLS label stack for ECMP decision processing, this document > >> reserves version 01 and this value MUST NOT be used in future > >> versions of the protocol. Please see [RFC7325] for further > >> discussion of MPLS-related forwarding requirements. > >> > >> NEW TEXT > >> > >> Version: The version field is used to ensure backward compatibility > >> going forward with future NSH updates. It MUST be set to 0x10 by the > >> sender, in this revision of NSH. Given the widespread > >> implementation of existing hardware that uses the first nibble after > >> an MPLS label stack for ECMP decision processing, this document > >> reserves version 0x01 and this value MUST NOT be used in future > >> versions of the protocol. Value of 0x00 is reserved for Experimental > >> > >> use in Section 12.2.1. [Please see [RFC7325] for further > >> discussion of MPLS-related forwarding requirements. > >> > >> > >> Section 12.2.1 > >> > >> OLD TEXT > >> > >> Version 00: This protocol version. This document. > >> Version 01: Reserved. This document. > >> Version 10: Unassigned. > >> Version 11: Unassigned. > >> > >> NEW TEXT > >> > >> Version 0x00: Experimental. This document. > >> Version 0x01: Reserved. This document. > >> Version 0x10: This protocol version. This document. > >> Version 0x11: Unassigned. > >> > >> > >> Appreciate your comments, suggestions. > >> > >> > >> Regards, > >> > >> Greg > >> > >> > >> > >> _______________________________________________ > >> 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 From nobody Tue Feb 7 08:13:59 2017 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 62946129D09 for ; Tue, 7 Feb 2017 08:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ex4LlJWhVT7G for ; Tue, 7 Feb 2017 08:13:57 -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 90946129D07 for ; Tue, 7 Feb 2017 08:13:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 783FE4C79EC for ; Tue, 7 Feb 2017 08:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486484037; bh=6Sr8MsJC9uWAcuwCojpv+eAIrLaHxqqOhLvYpk15FSI=; h=To:From:Subject:Date:From; b=WNc5ShXVH38j56/krj4VVOciIuXyo+dwJ+0OqkE2o9F/VT1EiKzqf1LvH218o00J7 5psDUK+merH4n+xS5pEO7v270U004S3akkEgTvvBSugLkmoiHcmWQWBygVFh2s402U OOM85E6j/TiB9ZeXctVZDGJcJ8CbleaKxWtFputk= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (static-173-63-5-2.nwrknj.fios.verizon.net [173.63.5.2]) (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 2536F4C12F2 for ; Tue, 7 Feb 2017 08:13:57 -0800 (PST) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> Date: Tue, 7 Feb 2017 11:13:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:13:58 -0000 (This is my paraphrase of the discussion. I am posting it in my role as co-chair. This is intended to promote discussion. It is not the resolution.) On the list and at the interim meeting there has been discussion of the fact that the SI does not serve to prevent or detect loops strictly among SFF. At the interim, Adrian also observed that a reclassifier can produce loops and it would be highly desirable to have a way to detect those. The following describes an approach to solving this problem that was discussed at the interim meeting. We would like WG feedback on this, as if adopted it needs to go into the NSH document. Some of the details are under-specified. If the WG likes the approach, we can fill in those details. The goal is to add a TTL field that can be decremented (or, if the WG prefers, increment) at every SFF and reclassifier. It is not sued for forwarding, but only to detect loops. In order to allow for large deployments, the interim felt that 6 bits of TTL field was enough. So where to get the bits? The proposal is to take the six unused flag bits, and turn them into a TTL field. Then, in order to have some flag bits for future use, we take the upper bits (4? 3? 5?) of the corrent MD-type field and use those for flag bits for any new flags. We then had a discussion on how this works with existing devices. As noted in earlier discussions, we are not seeking to make those devices compliant, but to enable easier transition and limited interoperability. THe first observation is that as long as none of the new flag bits are used, any existing device that examines the MD type field as an octet will understand the value. Eventually, we expect that we will need to use those flags. We hope that devices will be upgraded before then. And if not, well, things happen. The harder question is how to handle the TTL with non-upgraded devices. Obviously, they will not adjust it. Which is unfortunate as it reduces protection. But it is not fatal. Also, as these are flags already expected to be ignored on reception (like most IETF reserved fields), we believe that no existing implementation will break if the TTL is set. There is one further compatibility issue. What if the ingress classifier that creates the NSH header does not know how to set it. There seem to be two possibilities. One is to say that we could up from 0. As such, existing implementations will set it correctly. This works. But it is contrary to conventional practice. The other choice is to count down, but declare that 1 is expiration, and 0 means not-counting. This is more limiting. Opinions? Thanks, Joel From nobody Tue Feb 7 08:22:45 2017 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 1E6CD129D2E for ; Tue, 7 Feb 2017 08:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 LadmKrWkYqua for ; Tue, 7 Feb 2017 08:22:43 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 17CD9129D2B for ; Tue, 7 Feb 2017 08:22:43 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id j15so67459078oih.2 for ; Tue, 07 Feb 2017 08:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LYli7EpoCiP2qY4rKJu7oGMf1DjkpMMEcTmoRa/prNM=; b=gC9S2a/kWQchTdgt69ecXSTaWmoAo8erigbFj7lPVz4Cq72Xwby3ZlNAIhMLq8mO17 PeJzMoi3IVv3Jbrw22rgTcreNPJd2C82cuJ+UhgjhKcCVQpi+PcLFiFJeCaX8yIgabZH QDF4T1JX5UFthBExwiKNmkbQ6Gl89wjwlvImPI8plQHk69FGoktyc4kYy6A9i99cCce3 ub84iK/ZjviLd70oJIj6ybrvMU2RFN5G52T/emO+WIPjtNwVFoVH4XO42KmTG0drb2uR LW60UbZEd76XfgLZ1fu9KAgf2uYBjupEUYvAyMT17bNSd6UOYa4kX8chdN8RZKUr0+w/ 0DJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LYli7EpoCiP2qY4rKJu7oGMf1DjkpMMEcTmoRa/prNM=; b=saEpG6Ewt6iNz82InBjVl6bIYCg+IVHc0OkCt+gE1pXOSFdZ8HHZwGjFgh8+7SbwwM 6yUkB1FFwo1jPBTvZHASdWyzOkaLEtrQ0p6ocKo2DT0Fjf4g/JuDTBMIoMfIP1K6+Net XK+EGjPp+0F8P01iWFj9IvUDwwmZBZi/nvJxdDYkeR9p4XVgRbUDeE+SWr+g1zikDwok R5ZMxHSqB4sObvaYXiaDKbfw+P77CdUa95d785lhh5DDLf/c+KnhrI7Ax24Rf2Vug3a0 gORGM2aNrJd7qhC0x6L/WJFGpgjprF4OBF1JATfYIJ7MQUYojmmOOl+979EPVF8D9VXq +bEw== X-Gm-Message-State: AMke39nHCrAhcKcVsQuU2tFYHS+CHsv6x1bSIverG/yHHfoysfwD9vHsJDbwfrsKA6+uFYXbW34nZlKFp+Y/cA== X-Received: by 10.202.220.198 with SMTP id t189mr8347929oig.94.1486484562464; Tue, 07 Feb 2017 08:22:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Tue, 7 Feb 2017 08:22:22 -0800 (PST) In-Reply-To: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> From: "Andrew G. Malis" Date: Tue, 7 Feb 2017 17:22:22 +0100 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a113d634a4f56bc0547f32871 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:22:44 -0000 --001a113d634a4f56bc0547f32871 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joel, I=E2=80=99m in favor of loop prevention along the lines that we discussed i= n Westford. With specific regard to: There is one further compatibility issue. What if the ingress classifier > that creates the NSH header does not know how to set it. There seem to be > two possibilities. One is to say that we could up from 0. As such, > existing implementations will set it correctly. This works. But it is > contrary to conventional practice. The other choice is to count down, bu= t > declare that 1 is expiration, and 0 means not-counting. This is more > limiting. > > I=E2=80=99m in favor of starting from zero and counting up, for maximal b= ackwards compatibility. Consistency to prior practice for its own sake is a poor argument unless there=E2=80=99s a good technical reason for it, such as eas= e of implementation. Cheers, Andy PS To quote Emerson, consistency is the hobgoblin of little minds. --001a113d634a4f56bc0547f32871 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joel,

I=E2=80=99m in favor of loop pr= evention along the lines that we discussed in Westford. With specific regar= d to:

=
There is one further compatibility is= sue.=C2=A0 What if the ingress classifier that creates the NSH header does = not know how to set it. There seem to be two possibilities.=C2=A0 One is to= say that we could up from 0.=C2=A0 As such, existing implementations will = set it correctly.=C2=A0 This works.=C2=A0 But it is contrary to conventiona= l practice.=C2=A0 The other choice is to count down, but declare that 1 is = expiration, and 0 means not-counting.=C2=A0 This is more limiting.

I=E2=80=99m in favo= r of starting from zero and counting up, for maximal backwards compatibilit= y. Consistency to prior practice for its own sake is a poor argument unless= there=E2=80=99s a good technical reason for it, such as ease of implementa= tion.

= Cheers,
Andy

PS To quote Emerson, consistency is = the hobgoblin of little minds.

--001a113d634a4f56bc0547f32871-- From nobody Tue Feb 7 09:08:40 2017 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 840C3129DA4 for ; Tue, 7 Feb 2017 09:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_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=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 KO8Q3oudJ1l9 for ; Tue, 7 Feb 2017 09:08:37 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 70083129D9C for ; Tue, 7 Feb 2017 09:08:37 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id t18so44306936wmt.0 for ; Tue, 07 Feb 2017 09:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VisH9/nXmyBOaCv8obPaFttQ4GwpBOsowZvecPnLdkA=; b=sAyzjG5f6P1xQOJkJWFLi/rh4AI5cBd2FmSiMsXBsNFrcKBCT6KnpjXvcLhbzvNJyR Q4YWxiqvkcCYEbATmpOCSzeC9gmIGbMbAXRKkRddcgIuGVAdetLhRz+/QssdImrZFlN9 5usy83LewF1418rbJOw68v1kTmoxqkMqIa1rMjlr5v62bMEpb/Qqi/xusPFgtznwVsG9 o8uWrlN2menObewUtS96wimZWEnt6X8M35pjPBLKJSmOcweYGxhJ3r86kz22zRCWwewN kTupcI/ECY3WwUu4cYDWMvl1i1AyJi4zBHai8myBTURlGU5EI9dtOdzzZQFePTW2/rfW UR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=VisH9/nXmyBOaCv8obPaFttQ4GwpBOsowZvecPnLdkA=; b=alecBoN/RybiuRbtGCauVSBNWpplai4kUuHNbWgKervxfE6AvgzH0Misek9ZADZ4pS ntfoLYbZWEjQulq7RMjr1RxVM1jRBQkeWR5ThAV74/RQLe3/Hpviv4kONsAfWtdE90Ki mPqfzY9ip036c/SfVxxgr5bTkF9nz6fqgEJfwxp9H4wb5MK4Jzru30VQAsVSHTewZORO 2w7VccHZ6ldCzx8CIrPL4ajQa9neHIPo2QQVt6v+WHsoNk0SeSc578KY69l5rxiALGcZ h4mJsxe30fig7QbwR1mJdcazghVfOXqzWvuJ8pocvaYV9sQCTYz7QxZbU1kR8pyPcM9L 51ag== X-Gm-Message-State: AMke39l180r1dcBj4E+0xsGfh08pnFCKuse6OdysfBwLZdPkPe1uf1nJl3CVJw4u3cUz+qG46JzZeo4+bjiahQ== X-Received: by 10.28.196.133 with SMTP id u127mr13332427wmf.34.1486487315881; Tue, 07 Feb 2017 09:08:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.138.146 with HTTP; Tue, 7 Feb 2017 09:08:35 -0800 (PST) In-Reply-To: References: From: Behcet Sarikaya Date: Tue, 7 Feb 2017 11:08:35 -0600 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:08:39 -0000 On Mon, Feb 6, 2017 at 3:13 PM, Joel M. Halpern wrote: > We as a working group are free to make changes that we need technically. > That is even the case after publication of a PS RFC. It is certainly the > case before document completion. > > At the same time, folks have been implementing our work. Which is a good > and highly desirable thing. > > So when we make changes, if we can do so in ways that reduce the pain for > earlier implementors, that is desirable. > Maybe we should add a warning to the draft for the early implementers saying that the risk belongs to you and the WG does not take any responsibility for the early birds. Regards, Behcet > Yours, > Joel > > > On 2/6/17 3:38 PM, Behcet Sarikaya wrote: >> >> Hi Greg, >> >> >> On Mon, Feb 6, 2017 at 11:31 AM, Greg Mirsky >> wrote: >>> >>> Dear All, >>> during SFC WG interim meeting support of infinite loop prevention by >>> introducing TTL field was proposed and discussed. This and other >>> proposals >>> will change NSH Base Header affecting existing implementations. The >>> discussion of backward compatibily have started but, as I recal, we >>> haven't >>> reached any conclusion. I'd like to propose couple changes to Value >>> field: >> >> >> Sorry but I don't understand this discussion on backward compatibility. >> As far as I know SFC is not deployed. >> The nsh protocol in >> >> draft-ietf-sfc-nsh-10.txt >> has not been standardized, I.e. no RFC yet, no interoperability tests, >> no nothing. >> >> Why should the WG spend cycles on a "baby" that has not even born yet :)? >> >> Regards, >> >> Behcet >> >>> >>> Section 3.2 >>> >>> OLD TEXT >>> >>> Version: The version field is used to ensure backward compatibility >>> going forward with future NSH updates. It MUST be set to 0x0 by the >>> sender, in this first revision of NSH. Given the widespread >>> implementation of existing hardware that uses the first nibble after >>> an MPLS label stack for ECMP decision processing, this document >>> reserves version 01 and this value MUST NOT be used in future >>> versions of the protocol. Please see [RFC7325] for further >>> discussion of MPLS-related forwarding requirements. >>> >>> NEW TEXT >>> >>> Version: The version field is used to ensure backward compatibility >>> going forward with future NSH updates. It MUST be set to 0x10 by the >>> sender, in this revision of NSH. Given the widespread >>> implementation of existing hardware that uses the first nibble after >>> an MPLS label stack for ECMP decision processing, this document >>> reserves version 0x01 and this value MUST NOT be used in future >>> versions of the protocol. Value of 0x00 is reserved for Experimental >>> >>> use in Section 12.2.1. [Please see [RFC7325] for further >>> discussion of MPLS-related forwarding requirements. >>> >>> >>> Section 12.2.1 >>> >>> OLD TEXT >>> >>> Version 00: This protocol version. This document. >>> Version 01: Reserved. This document. >>> Version 10: Unassigned. >>> Version 11: Unassigned. >>> >>> NEW TEXT >>> >>> Version 0x00: Experimental. This document. >>> Version 0x01: Reserved. This document. >>> Version 0x10: This protocol version. This document. >>> Version 0x11: Unassigned. >>> >>> >>> Appreciate your comments, suggestions. >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> _______________________________________________ >>> 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 Tue Feb 7 09:15:42 2017 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 3FD4C12944F for ; Tue, 7 Feb 2017 09:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, 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=mellanox.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 UUU9abvF8Cnp for ; Tue, 7 Feb 2017 09:15:38 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0045.outbound.protection.outlook.com [104.47.0.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FD11293D9 for ; Tue, 7 Feb 2017 09:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dIeosXnNSIedHOlX1UVWBt/yNFlAQCK56XN0GSY/l2w=; b=Brx6AEr/8pGww4gOfH95geEuXPz1O+co7Oi2hs7IAcqZ/ZzVj0uLTLDDCUbnWXtvwWWp7ce5JHTylCt4QXXA1+YSUahhBZUDuDMsoZD29Ba+MKll2v8unxiHD6bcBLFNYxhOiF3d5foXwEkp5etB2LiOu1L7FguxctryIMyhCsM= Received: from HE1PR0501MB2138.eurprd05.prod.outlook.com (10.167.246.22) by HE1PR0501MB2138.eurprd05.prod.outlook.com (10.167.246.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 7 Feb 2017 17:15:34 +0000 Received: from HE1PR0501MB2138.eurprd05.prod.outlook.com ([10.167.246.22]) by HE1PR0501MB2138.eurprd05.prod.outlook.com ([10.167.246.22]) with mapi id 15.01.0888.026; Tue, 7 Feb 2017 17:15:34 +0000 From: David Mozes To: "Andrew G. Malis" , "Joel M. Halpern" Thread-Topic: [sfc] Loop prevention Thread-Index: AQHSgV006ERnxsBQCUCxLbTFg8ULT6Fduf0AgAAObLA= Date: Tue, 7 Feb 2017 17:15:34 +0000 Message-ID: References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> 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=davidm@mellanox.com; x-originating-ip: [77.138.166.110] x-ms-office365-filtering-correlation-id: f04dd132-075a-49a2-9366-08d44f7cedbd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0501MB2138; x-microsoft-exchange-diagnostics: 1; HE1PR0501MB2138; 7:YWiNEEKpI6JqjMhVdyEZtWwIoe0wIJ2Fjo0niuYpfqCJH0MuQs9g5+5gyFoC4q1IyuJF3S20HDC19tyKWI9tLzrpAs/G0e1KvhXtIGLTX+6i11NKyzCOmzpNxR9eLfrr31m+EQn5JooDYi4UWigyc7+IF2VzBCgng4QCcgGIqUu7PIj2Ut7Crru0LqFo6hpYYJmT8wC1NiZ6iIwe8wj0zmXOI9Ch2M/5ess+nV57gbBMAoxddBSnREyGC7Ax+TK80Hc052tYwZHarnsPa2k9P8FjweJpQNit3MFbarBlCybNnBugj/xLXV6dAi9yGmtF7YN3YZtI1dycT1U0ypqvnrqR2GHtxwZEQiDeAg2Q2gfq9ETVm0jrWjca3a6xvg0DHH52aS+ni/j71IMe685ou4AO049UPukuNxfZwqDGGfjZva221WISqXjP+g7tH8iMS/0pL64Cvw32lN0juVSi7CMoMoiNtba+jwY4iBJPwV6Nd2EjBaFzwqzM1z7VXPH66OtgzwFmv05GgKbUcOT3RQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(2017020603029)(20170203043)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(6072148); SRVR:HE1PR0501MB2138; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0501MB2138; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(189002)(377454003)(199003)(2900100001)(6506006)(86362001)(39060400001)(53936002)(77096006)(66066001)(106116001)(105586002)(3280700002)(8936002)(106356001)(6436002)(25786008)(2950100002)(102836003)(6116002)(38730400002)(6246003)(3846002)(229853002)(55016002)(99286003)(2906002)(54896002)(6306002)(9686003)(92566002)(122556002)(790700001)(74316002)(101416001)(68736007)(33656002)(189998001)(50986999)(7696004)(4326007)(97736004)(7736002)(5660300001)(8676002)(81156014)(76176999)(54356999)(81166006)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0501MB2138; H:HE1PR0501MB2138.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0501MB2138A202249641493140CEE3B6430HE1PR0501MB2138_" MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2017 17:15:34.7864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2138 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:15:40 -0000 --_000_HE1PR0501MB2138A202249641493140CEE3B6430HE1PR0501MB2138_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q291bnQgZG93biBUVEwgYW5kIGNvbXBhcmUgdG8gMCAgaXMgaG93IG1vc3Qgb2Ygbm90IGFsbCBv ZiB0aGUgQXBwbGljYXRpb25zICBiZWhhdmUgdG9kYXkNCg0KRnJvbTogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IFR1 ZXNkYXksIEZlYnJ1YXJ5IDA3LCAyMDE3IDY6MjIgUE0NClRvOiBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb20+DQpDYzogc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10g TG9vcCBwcmV2ZW50aW9uDQoNCkpvZWwsDQoNCknigJltIGluIGZhdm9yIG9mIGxvb3AgcHJldmVu dGlvbiBhbG9uZyB0aGUgbGluZXMgdGhhdCB3ZSBkaXNjdXNzZWQgaW4gV2VzdGZvcmQuIFdpdGgg c3BlY2lmaWMgcmVnYXJkIHRvOg0KDQpUaGVyZSBpcyBvbmUgZnVydGhlciBjb21wYXRpYmlsaXR5 IGlzc3VlLiAgV2hhdCBpZiB0aGUgaW5ncmVzcyBjbGFzc2lmaWVyIHRoYXQgY3JlYXRlcyB0aGUg TlNIIGhlYWRlciBkb2VzIG5vdCBrbm93IGhvdyB0byBzZXQgaXQuIFRoZXJlIHNlZW0gdG8gYmUg dHdvIHBvc3NpYmlsaXRpZXMuICBPbmUgaXMgdG8gc2F5IHRoYXQgd2UgY291bGQgdXAgZnJvbSAw LiAgQXMgc3VjaCwgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHdpbGwgc2V0IGl0IGNvcnJlY3Rs eS4gIFRoaXMgd29ya3MuICBCdXQgaXQgaXMgY29udHJhcnkgdG8gY29udmVudGlvbmFsIHByYWN0 aWNlLiAgVGhlIG90aGVyIGNob2ljZSBpcyB0byBjb3VudCBkb3duLCBidXQgZGVjbGFyZSB0aGF0 IDEgaXMgZXhwaXJhdGlvbiwgYW5kIDAgbWVhbnMgbm90LWNvdW50aW5nLiAgVGhpcyBpcyBtb3Jl IGxpbWl0aW5nLg0KSeKAmW0gaW4gZmF2b3Igb2Ygc3RhcnRpbmcgZnJvbSB6ZXJvIGFuZCBjb3Vu dGluZyB1cCwgZm9yIG1heGltYWwgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuIENvbnNpc3RlbmN5 IHRvIHByaW9yIHByYWN0aWNlIGZvciBpdHMgb3duIHNha2UgaXMgYSBwb29yIGFyZ3VtZW50IHVu bGVzcyB0aGVyZeKAmXMgYSBnb29kIHRlY2huaWNhbCByZWFzb24gZm9yIGl0LCBzdWNoIGFzIGVh c2Ugb2YgaW1wbGVtZW50YXRpb24uDQoNCkNoZWVycywNCkFuZHkNCg0KUFMgVG8gcXVvdGUgRW1l cnNvbiwgY29uc2lzdGVuY3kgaXMgdGhlIGhvYmdvYmxpbiBvZiBsaXR0bGUgbWluZHMuDQoNCg== --_000_HE1PR0501MB2138A202249641493140CEE3B6430HE1PR0501MB2138_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q291bnQgZG93biBUVEwgYW5k IGNvbXBhcmUgdG8gMCAmbmJzcDtpcyBob3cgbW9zdCBvZiBub3QgYWxsIG9mIHRoZSBBcHBsaWNh dGlvbnMgJm5ic3A7YmVoYXZlIHRvZGF5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHJldyBHLiBNYWxpczxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAwNywgMjAxNyA2OjIyIFBNPGJyPg0KPGI+VG86 PC9iPiBKb2VsIE0uIEhhbHBlcm4gJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIExvb3Ag cHJldmVudGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5K b2VsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5J4oCZbSBpbiBmYXZvciBvZiBsb29wIHByZXZlbnRpb24gYWxvbmcgdGhlIGxpbmVzIHRoYXQg d2UgZGlzY3Vzc2VkIGluIFdlc3Rmb3JkLiBXaXRoIHNwZWNpZmljIHJlZ2FyZCB0bzo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2IGlkPSI6 MWF2Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ VGhlcmUgaXMgb25lIGZ1cnRoZXIgY29tcGF0aWJpbGl0eSBpc3N1ZS4mbmJzcDsgV2hhdCBpZiB0 aGUgaW5ncmVzcyBjbGFzc2lmaWVyIHRoYXQgY3JlYXRlcyB0aGUgTlNIIGhlYWRlciBkb2VzIG5v dCBrbm93IGhvdyB0byBzZXQgaXQuIFRoZXJlIHNlZW0gdG8gYmUgdHdvIHBvc3NpYmlsaXRpZXMu Jm5ic3A7IE9uZSBpcyB0byBzYXkgdGhhdCB3ZSBjb3VsZCB1cCBmcm9tIDAuJm5ic3A7DQogQXMg c3VjaCwgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHdpbGwgc2V0IGl0IGNvcnJlY3RseS4mbmJz cDsgVGhpcyB3b3Jrcy4mbmJzcDsgQnV0IGl0IGlzIGNvbnRyYXJ5IHRvIGNvbnZlbnRpb25hbCBw cmFjdGljZS4mbmJzcDsgVGhlIG90aGVyIGNob2ljZSBpcyB0byBjb3VudCBkb3duLCBidXQgZGVj bGFyZSB0aGF0IDEgaXMgZXhwaXJhdGlvbiwgYW5kIDAgbWVhbnMgbm90LWNvdW50aW5nLiZuYnNw OyBUaGlzIGlzIG1vcmUgbGltaXRpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGluIGZhdm9y IG9mIHN0YXJ0aW5nIGZyb20gemVybyBhbmQgY291bnRpbmcgdXAsIGZvciBtYXhpbWFsIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5LiBDb25zaXN0ZW5jeSB0byBwcmlvciBwcmFjdGljZSBmb3IgaXRz IG93biBzYWtlIGlzIGEgcG9vciBhcmd1bWVudCB1bmxlc3MgdGhlcmXigJlzIGEgZ29vZCB0ZWNo bmljYWwgcmVhc29uIGZvciBpdCwgc3VjaCBhcyBlYXNlIG9mIGltcGxlbWVudGF0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBT IFRvIHF1b3RlIEVtZXJzb24sIGNvbnNpc3RlbmN5IGlzIHRoZSBob2Jnb2JsaW4gb2YgbGl0dGxl IG1pbmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_HE1PR0501MB2138A202249641493140CEE3B6430HE1PR0501MB2138_-- From nobody Tue Feb 7 09:32:26 2017 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 DCCC112958B for ; Tue, 7 Feb 2017 09:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, 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 fu6b2BLX9mAI for ; Tue, 7 Feb 2017 09:32:24 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A5E129540 for ; Tue, 7 Feb 2017 09:32:23 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 7 Feb 2017 12:32:22 -0500 From: Dave Dolson To: David Mozes , "Andrew G. Malis" , "Joel M. Halpern" Thread-Topic: [sfc] Loop prevention Thread-Index: AQHSgV0zP3ZOpy8lukiNw70noAdQzqFeDc8AgAAO3QD//6+vwA== Date: Tue, 7 Feb 2017 17:32:21 +0000 Message-ID: References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98704FEEFDwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:32:25 -0000 --_000_E8355113905631478EFF04F5AA706E98704FEEFDwtlexchp1sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gYmUgcHJlY2lzZSwgSeKAmWQgbGlrZSB0byBwcm9wb3NlIHRoaXMgYmVoYXZpb3IgYnkgU0ZG czoNCmlmKFRUTCAhPTApIHRoZW4NCiAgICBzZXQgVFRMID0gVFRMIC0gMQ0KICAgIGlmKFRUTCA9 PTApIHRoZW4gZHJvcA0KZW5kaWYNCg0KVGhpcyBzaG91bGQgYmUgZG9uZSB3aGVuIGZvcndhcmRp bmcgTlNIICh2cy4gcmVjZWl2aW5nKSB0byBhbGxvdyBhIHBhY2tldCB3aXRoIFRUTD09MSB0byBi ZSByZWNlaXZlZCBhdCB0aGUgcGF0aCB0ZXJtaW51cyB3aXRob3V0IGRyb3BwaW5nIGl0Lg0KDQpB cyBKb2VsIHN1Z2dlc3RlZCwgMCBtZWFucyDigJxub3QgY291bnRpbmfigJ0uDQoNCi1EYXZlDQoN Cg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBE YXZpZCBNb3plcw0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDcsIDIwMTcgMTI6MTYgUE0NClRv OiBBbmRyZXcgRy4gTWFsaXM7IEpvZWwgTS4gSGFscGVybg0KQ2M6IHNmY0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtzZmNdIExvb3AgcHJldmVudGlvbg0KDQpDb3VudCBkb3duIFRUTCBhbmQgY29t cGFyZSB0byAwICBpcyBob3cgbW9zdCBvZiBub3QgYWxsIG9mIHRoZSBBcHBsaWNhdGlvbnMgIGJl aGF2ZSB0b2RheQ0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpcw0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDcsIDIw MTcgNjoyMiBQTQ0KVG86IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCkNj OiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBMb29wIHByZXZlbnRpb24NCg0KSm9l bCwNCg0KSeKAmW0gaW4gZmF2b3Igb2YgbG9vcCBwcmV2ZW50aW9uIGFsb25nIHRoZSBsaW5lcyB0 aGF0IHdlIGRpc2N1c3NlZCBpbiBXZXN0Zm9yZC4gV2l0aCBzcGVjaWZpYyByZWdhcmQgdG86DQoN ClRoZXJlIGlzIG9uZSBmdXJ0aGVyIGNvbXBhdGliaWxpdHkgaXNzdWUuICBXaGF0IGlmIHRoZSBp bmdyZXNzIGNsYXNzaWZpZXIgdGhhdCBjcmVhdGVzIHRoZSBOU0ggaGVhZGVyIGRvZXMgbm90IGtu b3cgaG93IHRvIHNldCBpdC4gVGhlcmUgc2VlbSB0byBiZSB0d28gcG9zc2liaWxpdGllcy4gIE9u ZSBpcyB0byBzYXkgdGhhdCB3ZSBjb3VsZCB1cCBmcm9tIDAuICBBcyBzdWNoLCBleGlzdGluZyBp bXBsZW1lbnRhdGlvbnMgd2lsbCBzZXQgaXQgY29ycmVjdGx5LiAgVGhpcyB3b3Jrcy4gIEJ1dCBp dCBpcyBjb250cmFyeSB0byBjb252ZW50aW9uYWwgcHJhY3RpY2UuICBUaGUgb3RoZXIgY2hvaWNl IGlzIHRvIGNvdW50IGRvd24sIGJ1dCBkZWNsYXJlIHRoYXQgMSBpcyBleHBpcmF0aW9uLCBhbmQg MCBtZWFucyBub3QtY291bnRpbmcuICBUaGlzIGlzIG1vcmUgbGltaXRpbmcuDQpJ4oCZbSBpbiBm YXZvciBvZiBzdGFydGluZyBmcm9tIHplcm8gYW5kIGNvdW50aW5nIHVwLCBmb3IgbWF4aW1hbCBi YWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gQ29uc2lzdGVuY3kgdG8gcHJpb3IgcHJhY3RpY2UgZm9y IGl0cyBvd24gc2FrZSBpcyBhIHBvb3IgYXJndW1lbnQgdW5sZXNzIHRoZXJl4oCZcyBhIGdvb2Qg dGVjaG5pY2FsIHJlYXNvbiBmb3IgaXQsIHN1Y2ggYXMgZWFzZSBvZiBpbXBsZW1lbnRhdGlvbi4N Cg0KQ2hlZXJzLA0KQW5keQ0KDQpQUyBUbyBxdW90ZSBFbWVyc29uLCBjb25zaXN0ZW5jeSBpcyB0 aGUgaG9iZ29ibGluIG9mIGxpdHRsZSBtaW5kcy4NCg0K --_000_E8355113905631478EFF04F5AA706E98704FEEFDwtlexchp1sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gYmUgcHJlY2lzZSwgSeKAmWQgbGlr ZSB0byBwcm9wb3NlIHRoaXMgYmVoYXZpb3IgYnkgU0ZGczo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aWYoVFRMICE9MCkgdGhlbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgc2V0IFRUTCA9IFRUTCAt IDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwO2lmKFRU TCA9PTApIHRoZW4gZHJvcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5lbmRpZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhpcyBzaG91bGQgYmUgZG9uZSB3aGVuIGZvcndhcmRpbmcgTlNIICh2cy4gcmVjZWl2 aW5nKQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50 byBhbGxvdyBhIHBhY2tldCB3aXRoIFRUTD09MSB0byBiZSByZWNlaXZlZCBhdCB0aGUgcGF0aCB0 ZXJtaW51cyB3aXRob3V0IGRyb3BwaW5nIGl0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBKb2VsIHN1Z2dlc3RlZCwgMCBtZWFu cyDigJxub3QgY291bnRpbmfigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2aWQgTW96ZXM8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMDcsIDIwMTcgMTI6MTYgUE08YnI+DQo8Yj5Ubzo8 L2I+IEFuZHJldyBHLiBNYWxpczsgSm9lbCBNLiBIYWxwZXJuPGJyPg0KPGI+Q2M6PC9iPiBzZmNA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIExvb3AgcHJldmVudGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db3VudCBkb3duIFRUTCBhbmQgY29tcGFy ZSB0byAwICZuYnNwO2lzIGhvdyBtb3N0IG9mIG5vdCBhbGwgb2YgdGhlIEFwcGxpY2F0aW9ucyAm bmJzcDtiZWhhdmUgdG9kYXkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QW5kcmV3IEcuIE1hbGlzPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5 IDA3LCAyMDE3IDY6MjIgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvZWwgTS4gSGFscGVybiAmbHQ7am1o QGpvZWxoYWxwZXJuLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3NmY10gTG9vcCBwcmV2ZW50aW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZWwsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGluIGZhdm9yIG9mIGxvb3AgcHJl dmVudGlvbiBhbG9uZyB0aGUgbGluZXMgdGhhdCB3ZSBkaXNjdXNzZWQgaW4gV2VzdGZvcmQuIFdp dGggc3BlY2lmaWMgcmVnYXJkIHRvOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2IGlkPSI6MWF2Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+VGhlcmUgaXMgb25lIGZ1cnRoZXIgY29tcGF0aWJpbGl0eSBpc3N1ZS4mbmJzcDsg V2hhdCBpZiB0aGUgaW5ncmVzcyBjbGFzc2lmaWVyIHRoYXQgY3JlYXRlcyB0aGUgTlNIIGhlYWRl ciBkb2VzIG5vdCBrbm93IGhvdyB0byBzZXQgaXQuIFRoZXJlIHNlZW0gdG8gYmUgdHdvIHBvc3Np YmlsaXRpZXMuJm5ic3A7IE9uZSBpcyB0byBzYXkgdGhhdCB3ZSBjb3VsZCB1cCBmcm9tIDAuJm5i c3A7DQogQXMgc3VjaCwgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHdpbGwgc2V0IGl0IGNvcnJl Y3RseS4mbmJzcDsgVGhpcyB3b3Jrcy4mbmJzcDsgQnV0IGl0IGlzIGNvbnRyYXJ5IHRvIGNvbnZl bnRpb25hbCBwcmFjdGljZS4mbmJzcDsgVGhlIG90aGVyIGNob2ljZSBpcyB0byBjb3VudCBkb3du LCBidXQgZGVjbGFyZSB0aGF0IDEgaXMgZXhwaXJhdGlvbiwgYW5kIDAgbWVhbnMgbm90LWNvdW50 aW5nLiZuYnNwOyBUaGlzIGlzIG1vcmUgbGltaXRpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJlt IGluIGZhdm9yIG9mIHN0YXJ0aW5nIGZyb20gemVybyBhbmQgY291bnRpbmcgdXAsIGZvciBtYXhp bWFsIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LiBDb25zaXN0ZW5jeSB0byBwcmlvciBwcmFjdGlj ZSBmb3IgaXRzIG93biBzYWtlIGlzIGEgcG9vciBhcmd1bWVudCB1bmxlc3MgdGhlcmXigJlzIGEg Z29vZCB0ZWNobmljYWwgcmVhc29uIGZvciBpdCwgc3VjaCBhcyBlYXNlIG9mIGltcGxlbWVudGF0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlBTIFRvIHF1b3RlIEVtZXJzb24sIGNvbnNpc3RlbmN5IGlzIHRoZSBob2Jnb2JsaW4g b2YgbGl0dGxlIG1pbmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_E8355113905631478EFF04F5AA706E98704FEEFDwtlexchp1sandvi_-- From nobody Tue Feb 7 09:32:38 2017 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 6419A129DEF for ; Tue, 7 Feb 2017 09:32:35 -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, 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 lSG52q5Q6NYC for ; Tue, 7 Feb 2017 09:32:31 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 5D6AE129DEB for ; Tue, 7 Feb 2017 09:32:31 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id s203so68719287oie.1 for ; Tue, 07 Feb 2017 09:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v5bhPjL7mDOtNz9WuAfq9BlgCSqiH31mANiCPSsqNjI=; b=reESAmjvet11dpjXoDeNOccJx5v7M3ezsEG08V+4c008M4gkc7EprPK8gdwymaiej8 lmVxk2o4a4TM0b9nvQ3T/QAV/aOtqtTuRzKSjDhGmwreCXsO1KbMab4NV3uwrxXlLzj6 nmAGMPZrgIVO9oFKX6DcxvaXJIyR41hkPsLLTkwpYk7RfC1k0332kzQI3YBscYm6ObJs aWEJ0NU7dWtaYbljbMMwo/aLHwLT3Nzs3oBGqoJj4FT1K/QqJzWt1dOuwLl19/beTeQG olLn2AIs3HCiRpEvMxjZmsg0FkeHJ4V1V//qxqi52s9tAMr93JRzsxmcokE+fR1Hd4X0 BdrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v5bhPjL7mDOtNz9WuAfq9BlgCSqiH31mANiCPSsqNjI=; b=J0PSYm2q+jTxFzmbqM2to3duKZ/2kAR+/G0BQ+TkvjGC1UJwPXp6S8WBr/20pWLAJw OQDtR0FQCkI0aaieV8vO1dL/r7RU0P+lhg5L0JHdxJLEtXUwiPE0bfAphq8VmpiD/WJR IhBbmLDf8tQBlH/5ICKOFAls0xXQcAyX6dWr7Kly7PrDbCUYVEGX90kuD154MK4CxGHT Qo7NQKfbO6Xfbd0hadEBEswf1PvZfDuMT1tkjM0loupeFoktnP3aYEJPTUTfmPkXYtEO y5XLyf5BVz16W33InP5HFjtkPy69z6Ntrvw1pS4ydiASGYxm2SKnTYWHCsh/X5R3TL9E GLRg== X-Gm-Message-State: AMke39lwah49kqLHsnMXd2F+ZpsKIe9lSij1btUdL3VuuqtGUX/7QkG3fEoYmhzLrrSFgKY/fTMUZvKp6fs5MA== X-Received: by 10.202.220.198 with SMTP id t189mr8531301oig.94.1486488750745; Tue, 07 Feb 2017 09:32:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Tue, 7 Feb 2017 09:32:10 -0800 (PST) In-Reply-To: References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> From: "Andrew G. Malis" Date: Tue, 7 Feb 2017 18:32:10 +0100 Message-ID: To: David Mozes Content-Type: multipart/alternative; boundary=001a113d634af370830547f42107 Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:32:36 -0000 --001a113d634af370830547f42107 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David, Back in the 60s or 70s, that may have been the easiest way to implement, say, IP TTL, and everything else followed. However, is increment and compare to all ones any more difficult these days? Cheers, Andy On Tue, Feb 7, 2017 at 6:15 PM, David Mozes wrote: > Count down TTL and compare to 0 is how most of not all of the > Applications behave today > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Andrew G. Malis > *Sent:* Tuesday, February 07, 2017 6:22 PM > *To:* Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] Loop prevention > > > > Joel, > > > > I=E2=80=99m in favor of loop prevention along the lines that we discussed= in > Westford. With specific regard to: > > > > There is one further compatibility issue. What if the ingress classifier > that creates the NSH header does not know how to set it. There seem to be > two possibilities. One is to say that we could up from 0. As such, > existing implementations will set it correctly. This works. But it is > contrary to conventional practice. The other choice is to count down, bu= t > declare that 1 is expiration, and 0 means not-counting. This is more > limiting. > > I=E2=80=99m in favor of starting from zero and counting up, for maximal b= ackwards > compatibility. Consistency to prior practice for its own sake is a poor > argument unless there=E2=80=99s a good technical reason for it, such as e= ase of > implementation. > > > > Cheers, > > Andy > > > > PS To quote Emerson, consistency is the hobgoblin of little minds. > > > --001a113d634af370830547f42107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,

Back in the 60s or 70s, that may= have been the easiest way to implement, say, IP TTL, and everything else f= ollowed. However, is increment and compare to all ones any more difficult t= hese days?

Cheers,
Andy


On Tue,= Feb 7, 2017 at 6:15 PM, David Mozes <davidm@mellanox.com>= wrote:

Count down TTL and compare to 0 =C2= =A0is how most of not all of the Applications =C2=A0behave today

=C2=A0

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Tuesday, February 07, 2017 6:22 PM
To: Joel M. Halpern <jmh@joelhalpern.com>
Cc: sfc@ietf.org
Subject: Re: [sfc] Loop prevention

=C2=A0

Joel,

=C2=A0

I=E2=80=99m in favor of loop prevention along the li= nes that we discussed in Westford. With specific regard to:

=C2=A0

There is one further = compatibility issue.=C2=A0 What if the ingress classifier that creates the = NSH header does not know how to set it. There seem to be two possibilities.= =C2=A0 One is to say that we could up from 0.=C2=A0 As such, existing implementations will set it correctly.=C2=A0 This works.= =C2=A0 But it is contrary to conventional practice.=C2=A0 The other choice = is to count down, but declare that 1 is expiration, and 0 means not-countin= g.=C2=A0 This is more limiting.

I=E2=80=99m in favor of starting from zero and count= ing up, for maximal backwards compatibility. Consistency to prior practice = for its own sake is a poor argument unless there=E2=80=99s a good technical= reason for it, such as ease of implementation.

=C2=A0

Cheers,

Andy

=C2=A0

PS To quote Emerson, consistency is the hobgoblin of= little minds.

=C2=A0


--001a113d634af370830547f42107-- From nobody Tue Feb 7 09:40:01 2017 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 F1DC0129592 for ; Tue, 7 Feb 2017 09:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 eXQdp-_QjLOP for ; Tue, 7 Feb 2017 09:39:58 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 271AB129591 for ; Tue, 7 Feb 2017 09:39:58 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id u143so68735367oif.3 for ; Tue, 07 Feb 2017 09:39:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ndN6ClpZhsiejAnjZQngpwKMlK65HChXHPP8fPhXEtU=; b=MhJZ7Xb385BHX6EObGCS801ABcJLH7uabrTJopEsq1gCFXS7IrtuG/t5ZvWpFEWuug znq/pOn8rK2GUy/xykepIt42cGsqGxuryH62QWZ5MqIb2p13gVlZRNK9D+t6O08XWK/H SLSwZj6Ns3cRbrF1nvd9aIXlb6zybzO+qdb7WrZy+S4bWziCzeFOLNMEq4TqXZvylaU+ Ou7fbrMWsFHVKLGAdKyIMH+NNV8EoZpKBFzg0bNIsNYbLh3fzXqy1y/JKJ6ljndax78I OugKg75+1v/Tb1QSzh2Jqfux/j4/CmZUxUtKEhY7pd4i4RW0hMFH/3/qlRQw/s9rbsjc CU7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ndN6ClpZhsiejAnjZQngpwKMlK65HChXHPP8fPhXEtU=; b=UAbsVzZvnSucwZEpn8G8s1iHJVogNecaSW2ZsZw/K8//jNxtmx2oL083r+6ydQ63aF ltU/UpwEZKQJLVKd55MO71zYR5ZINH5/Kax13DCElFwfbALEUfcZcB7o9sKIGZef7w6M RFmaYtPbfvb/P334pO+HSVS4FYo+odvuhxVkysTHQmrlOejLvWP+nXe9+YVjL1zWXiTm 3oBK15+PELiIJcmBVxgL2FBufMKwXMMvWWy/cls2MN94g69rjO0sZxtr6X5wReji4V2Y gDAf8465j4r45gn6Dea8MYV4anRAUV2a6NB+md8J53GEsOWCuFp+rRS+Lt3pg8ZRcGjf h5jw== X-Gm-Message-State: AMke39lKkF2xQZiFdBAm1u7T9L16yq3FwMtliE+i6gxlvSPFCSCFwluVqOSz69ZgNzfdApWCvGbkFUJT1n/vFw== X-Received: by 10.202.181.11 with SMTP id e11mr8597569oif.57.1486489197480; Tue, 07 Feb 2017 09:39:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Tue, 7 Feb 2017 09:39:37 -0800 (PST) In-Reply-To: References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> From: "Andrew G. Malis" Date: Tue, 7 Feb 2017 18:39:37 +0100 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a113cfef89410b80547f43c9d Archived-At: Cc: David Mozes , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:40:00 -0000 --001a113cfef89410b80547f43c9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dave, I agree that works, but it=E2=80=99s slight more complicated logic and coul= d potentially allow more packets to loop, those from early implementations that don=E2=80=99t know how to start TTL from any value other than zero. St= arting from zero would allow loop checking for packets originating from early implementations. Cheers, Andy On Tue, Feb 7, 2017 at 6:32 PM, Dave Dolson wrote: > To be precise, I=E2=80=99d like to propose this behavior by SFFs: > > if(TTL !=3D0) then > > set TTL =3D TTL - 1 > > if(TTL =3D=3D0) then drop > > endif > > > > This should be done when forwarding NSH (vs. receiving) to allow a packet > with TTL=3D=3D1 to be received at the path terminus without dropping it. > > > > As Joel suggested, 0 means =E2=80=9Cnot counting=E2=80=9D. > > > > -Dave > > > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Mozes > *Sent:* Tuesday, February 07, 2017 12:16 PM > *To:* Andrew G. Malis; Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] Loop prevention > > > > Count down TTL and compare to 0 is how most of not all of the > Applications behave today > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Andrew G. Malis > *Sent:* Tuesday, February 07, 2017 6:22 PM > *To:* Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] Loop prevention > > > > Joel, > > > > I=E2=80=99m in favor of loop prevention along the lines that we discussed= in > Westford. With specific regard to: > > > > There is one further compatibility issue. What if the ingress classifier > that creates the NSH header does not know how to set it. There seem to be > two possibilities. One is to say that we could up from 0. As such, > existing implementations will set it correctly. This works. But it is > contrary to conventional practice. The other choice is to count down, bu= t > declare that 1 is expiration, and 0 means not-counting. This is more > limiting. > > I=E2=80=99m in favor of starting from zero and counting up, for maximal b= ackwards > compatibility. Consistency to prior practice for its own sake is a poor > argument unless there=E2=80=99s a good technical reason for it, such as e= ase of > implementation. > > > > Cheers, > > Andy > > > > PS To quote Emerson, consistency is the hobgoblin of little minds. > > > --001a113cfef89410b80547f43c9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dave,

I agree that works, but it=E2=80= =99s slight more complicated logic and could potentially allow more packets= to loop, those from early implementations that don=E2=80=99t know how to s= tart TTL from any value other than zero. Starting from zero would allow loo= p checking for packets originating from early implementations.
Cheers,
Andy


On Tue, Feb 7, 2017 at 6:32 PM= , Dave Dolson <ddolson@sandvine.com> wrote:

To be precise, I=E2=80=99= d like to propose this behavior by SFFs:<= u>

if(TTL !=3D0) then=

=C2=A0=C2=A0=C2=A0 set TT= L =3D TTL - 1

=C2=A0=C2=A0 =C2=A0if(TTL= =3D=3D0) then drop

endif

=C2=A0

This should be done when = forwarding NSH (vs. receiving) to allow a packet with TTL=3D=3D1 to be r= eceived at the path terminus without dropping it.

=C2=A0

As Joel suggested, 0 mean= s =E2=80=9Cnot counting=E2=80=9D.

=C2=A0

-Dave

=C2=A0

=C2=A0

From: sfc [mai= lto:sfc-bounces@i= etf.org] On Behalf Of David Mozes
Sent: Tuesday, February 07, 2017 12:16 PM
To: Andrew G. Malis; Joel M. Halpern
Cc: sfc@ietf.org
Subject: Re: [sfc] Loop prevention

=C2=A0

Count down TTL and compar= e to 0 =C2=A0is how most of not all of the Applications =C2=A0behave today

=C2=A0

From: sfc [m= ailto:sfc-bounces= @ietf.org] On Behalf Of Andrew G. Malis
Sent: Tuesday, February 07, 2017 6:22 PM
To: Joel M. Halpern <jmh@joelhalpern.com>
Cc: sfc@ietf.org
Subject: Re: [sfc] Loop prevention

=C2=A0

Joel,

=C2=A0

I=E2=80=99m in favor of loop prevention along the li= nes that we discussed in Westford. With specific regard to:

=C2=A0

There is one further = compatibility issue.=C2=A0 What if the ingress classifier that creates the = NSH header does not know how to set it. There seem to be two possibilities.= =C2=A0 One is to say that we could up from 0.=C2=A0 As such, existing implementations will set it correctly.=C2=A0 This works.= =C2=A0 But it is contrary to conventional practice.=C2=A0 The other choice = is to count down, but declare that 1 is expiration, and 0 means not-countin= g.=C2=A0 This is more limiting.

I=E2=80=99m in favor of starting from zero and count= ing up, for maximal backwards compatibility. Consistency to prior practice = for its own sake is a poor argument unless there=E2=80=99s a good technical= reason for it, such as ease of implementation.

=C2=A0

Cheers,

Andy

=C2=A0

PS To quote Emerson, consistency is the hobgoblin of= little minds.

=C2=A0


--001a113cfef89410b80547f43c9d-- From nobody Tue Feb 7 09:47:55 2017 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 9F7E9129E01 for ; Tue, 7 Feb 2017 09:47:53 -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 696G15x9uhkU for ; Tue, 7 Feb 2017 09:47:51 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 45EE2129592 for ; Tue, 7 Feb 2017 09:47:51 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id 32so91927769oth.3 for ; Tue, 07 Feb 2017 09:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5w9ATCnQAaAAELaKjS0VBr58VIEz+DUr0H/bIA9CkfI=; b=QYZ65sgZjWWinWgsdSzuda2ujcnm0n4kxdbILOwq7N3jTwc4oYU349/3EfLf6K3fYb 02uDR7OkWo7FelTSijyYPMfH/79NPY4RXXIGjvYqomzpPAfiiYI5ngGJJ70Fuwry/JK5 5peNXmEiDgCNjV8FGXlU/pvOtwwKH/Yb1ZLBds7JDNtTKE6iqPxMjOpgiK3Q73K9T0+R 5ykVlYhBoqxPu7ZG7DsCPzWwaQWBApnDfpC97GP+uR1ALk9QBeot878iqFWSux6pH5sL v3GlWX69XnDvK2q15xTSTgqw1WSLxoyvbvB0mK6UY3BZh2ABA3gZDOCj034XSHk+pYxw CB7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5w9ATCnQAaAAELaKjS0VBr58VIEz+DUr0H/bIA9CkfI=; b=J1CdCupj+JgZmG+D06+Q6Fe1K9BUjL+EMvMAlBFobt5HXlOt/mlJTVcShTF0gusm5H 77xHbcn/TU9WrICSaFCc0D+MLIOXM+arqV9cOJaNVxiQYLUvO4Z1OKyY/Z5XD19nRdsG 3vGPQhGAbQmAVgWcEWvDgnUznpDYiSDfyYS5rMDZH3kGT+wkGZ5Is8xdTzkEjsgHM0Ar +shunGyU8BuetOkC/E1hc5f66wpqUgI1RlV5yyQdIRu7wFyYOpP9XA0IFzKHEwZk9+IJ 3PcVGz7TSuW2YNyDdYrD5NVrMTsjTOvkkGJNm2Nenq/rfSwW7Ak6BlT5qJEDL3zN3EJ5 to7Q== X-Gm-Message-State: AMke39kzbQju7MFuW2/0N+tGD47LN/cvsR98m2SNwBxb55UgX8Aye7GDXWQmPemISAA5mY/Z87RN+S2C1Rcw4Q== X-Received: by 10.157.51.112 with SMTP id u45mr9603166otd.252.1486489670661; Tue, 07 Feb 2017 09:47:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Tue, 7 Feb 2017 09:47:30 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 7 Feb 2017 18:47:30 +0100 Message-ID: To: sarikaya Content-Type: multipart/alternative; boundary=001a113dfc76c83c650547f4588a Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:47:53 -0000 --001a113dfc76c83c650547f4588a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Behcet, That=E2=80=99s a well-known chance that you take when you implement any dra= ft rather than the final RFC. However, early implementations are to be encouraged, since they act as a proof of concept and often point out improvements that can be made to the published version of the protocol. So if the WG can easily make changes that are backwards compatible to earily implementations, that is to be encouraged. However, as Joel pointed out, that isn=E2=80=99t always possible. Cheers, Andy On Tue, Feb 7, 2017 at 6:08 PM, Behcet Sarikaya wrote: > On Mon, Feb 6, 2017 at 3:13 PM, Joel M. Halpern > wrote: > > We as a working group are free to make changes that we need technically= . > > That is even the case after publication of a PS RFC. It is certainly t= he > > case before document completion. > > > > At the same time, folks have been implementing our work. Which is a go= od > > and highly desirable thing. > > > > So when we make changes, if we can do so in ways that reduce the pain f= or > > earlier implementors, that is desirable. > > > > Maybe we should add a warning to the draft for the early implementers > saying that the risk belongs to you and the WG does not take any > responsibility for the early birds. > > > Regards, > > Behcet > > Yours, > > Joel > > > > > > On 2/6/17 3:38 PM, Behcet Sarikaya wrote: > >> > >> Hi Greg, > >> > >> > >> On Mon, Feb 6, 2017 at 11:31 AM, Greg Mirsky > >> wrote: > >>> > >>> Dear All, > >>> during SFC WG interim meeting support of infinite loop prevention by > >>> introducing TTL field was proposed and discussed. This and other > >>> proposals > >>> will change NSH Base Header affecting existing implementations. The > >>> discussion of backward compatibily have started but, as I recal, we > >>> haven't > >>> reached any conclusion. I'd like to propose couple changes to Value > >>> field: > >> > >> > >> Sorry but I don't understand this discussion on backward compatibility= . > >> As far as I know SFC is not deployed. > >> The nsh protocol in > >> > >> draft-ietf-sfc-nsh-10.txt > >> has not been standardized, I.e. no RFC yet, no interoperability tests, > >> no nothing. > >> > >> Why should the WG spend cycles on a "baby" that has not even born yet > :)? > >> > >> Regards, > >> > >> Behcet > >> > >>> > >>> Section 3.2 > >>> > >>> OLD TEXT > >>> > >>> Version: The version field is used to ensure backward compatibility > >>> going forward with future NSH updates. It MUST be set to 0x0 by t= he > >>> sender, in this first revision of NSH. Given the widespread > >>> implementation of existing hardware that uses the first nibble aft= er > >>> an MPLS label stack for ECMP decision processing, this document > >>> reserves version 01 and this value MUST NOT be used in future > >>> versions of the protocol. Please see [RFC7325] for further > >>> discussion of MPLS-related forwarding requirements. > >>> > >>> NEW TEXT > >>> > >>> Version: The version field is used to ensure backward compatibility > >>> going forward with future NSH updates. It MUST be set to 0x10 by > the > >>> sender, in this revision of NSH. Given the widespread > >>> implementation of existing hardware that uses the first nibble aft= er > >>> an MPLS label stack for ECMP decision processing, this document > >>> reserves version 0x01 and this value MUST NOT be used in future > >>> versions of the protocol. Value of 0x00 is reserved for > Experimental > >>> > >>> use in Section 12.2.1. [Please see [RFC7325] for further > >>> discussion of MPLS-related forwarding requirements. > >>> > >>> > >>> Section 12.2.1 > >>> > >>> OLD TEXT > >>> > >>> Version 00: This protocol version. This document. > >>> Version 01: Reserved. This document. > >>> Version 10: Unassigned. > >>> Version 11: Unassigned. > >>> > >>> NEW TEXT > >>> > >>> Version 0x00: Experimental. This document. > >>> Version 0x01: Reserved. This document. > >>> Version 0x10: This protocol version. This document. > >>> Version 0x11: Unassigned. > >>> > >>> > >>> Appreciate your comments, suggestions. > >>> > >>> > >>> Regards, > >>> > >>> Greg > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > --001a113dfc76c83c650547f4588a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Behcet,

That=E2=80=99s a well-known cha= nce that you take when you implement any draft rather than the final RFC. H= owever, early implementations are to be encouraged, since they act as a pro= of of concept and=C2=A0often point out improvements that can be made to the= published version of the protocol. So if the WG can easily make changes th= at are backwards compatible to earily implementations, that is to be encour= aged. However, as Joel pointed out, that isn=E2=80=99t always possible.

Cheers,
Andy


On Tue, Feb 7, 2017 a= t 6:08 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wro= te:
On Mon, Feb 6, 2017 = at 3:13 PM, Joel M. Halpern <jmh@= joelhalpern.com> wrote:
> We as a working group are free to make changes that we need technicall= y.
> That is even the case after publication of a PS RFC.=C2=A0 It is certa= inly the
> case before document completion.
>
> At the same time, folks have been implementing our work.=C2=A0 Which i= s a good
> and highly desirable thing.
>
> So when we make changes, if we can do so in ways that reduce the pain = for
> earlier implementors, that is desirable.
>

Maybe we should add a warning to the draft for the early implementer= s
saying that the risk belongs to you and the WG does not take any
responsibility for the early birds.


Regards,

Behcet
> Yours,
> Joel
>
>
> On 2/6/17 3:38 PM, Behcet Sarikaya wrote:
>>
>> Hi Greg,
>>
>>
>> On Mon, Feb 6, 2017 at 11:31 AM, Greg Mirsky <gregimirsky@gmail.com>
>> wrote:
>>>
>>> Dear All,
>>> during SFC WG interim meeting support of infinite loop prevent= ion by
>>> introducing TTL field was proposed and discussed. This and oth= er
>>> proposals
>>> will change NSH Base Header affecting existing implementations= . The
>>> discussion of backward compatibily have started but, as I reca= l, we
>>> haven't
>>> reached any conclusion. I'd like to propose couple changes= to Value
>>> field:
>>
>>
>> Sorry but I don't understand this discussion on backward compa= tibility.
>> As far as I know SFC is not deployed.
>> The nsh protocol in
>>
>> draft-ietf-sfc-nsh-10.txt
>> has not been standardized, I.e. no RFC yet, no interoperability te= sts,
>> no nothing.
>>
>> Why should the WG spend cycles on a "baby" that has not = even born yet :)?
>>
>> Regards,
>>
>> Behcet
>>
>>>
>>> Section 3.2
>>>
>>> OLD TEXT
>>>
>>>=C2=A0 =C2=A0Version: The version field is used to ensure backw= ard compatibility
>>>=C2=A0 =C2=A0 going forward with future NSH updates.=C2=A0 It M= UST be set to 0x0 by the
>>>=C2=A0 =C2=A0 sender, in this first revision of NSH.=C2=A0 Give= n the widespread
>>>=C2=A0 =C2=A0 implementation of existing hardware that uses the= first nibble after
>>>=C2=A0 =C2=A0 an MPLS label stack for ECMP decision processing,= this document
>>>=C2=A0 =C2=A0 reserves version 01 and this value MUST NOT be us= ed in future
>>>=C2=A0 =C2=A0 versions of the protocol.=C2=A0 Please see [RFC73= 25] for further
>>>=C2=A0 =C2=A0 discussion of MPLS-related forwarding requirement= s.
>>>
>>> NEW TEXT
>>>
>>>=C2=A0 =C2=A0Version: The version field is used to ensure backw= ard compatibility
>>>=C2=A0 =C2=A0 going forward with future NSH updates.=C2=A0 It M= UST be set to 0x10 by the
>>>=C2=A0 =C2=A0 sender, in this revision of NSH.=C2=A0 Given the = widespread
>>>=C2=A0 =C2=A0 implementation of existing hardware that uses the= first nibble after
>>>=C2=A0 =C2=A0 an MPLS label stack for ECMP decision processing,= this document
>>>=C2=A0 =C2=A0 reserves version 0x01 and this value MUST NOT be = used in future
>>>=C2=A0 =C2=A0 versions of the protocol.=C2=A0 Value of 0x00 is = reserved for Experimental
>>>
>>>=C2=A0 =C2=A0 use in Section 12.2.1. [Please see [RFC7325] for = further
>>>=C2=A0 =C2=A0 discussion of MPLS-related forwarding requirement= s.
>>>
>>>
>>> Section 12.2.1
>>>
>>> OLD TEXT
>>>
>>>=C2=A0 =C2=A0 Version 00: This protocol version.=C2=A0 This doc= ument.
>>>=C2=A0 =C2=A0 Version 01: Reserved.=C2=A0 This document.
>>>=C2=A0 =C2=A0 Version 10: Unassigned.
>>>=C2=A0 =C2=A0 Version 11: Unassigned.
>>>
>>> NEW TEXT
>>>
>>>=C2=A0 =C2=A0 Version 0x00: Experimental.=C2=A0 This document.<= br> >>>=C2=A0 =C2=A0 Version 0x01: Reserved.=C2=A0 This document.
>>>=C2=A0 =C2=A0 Version 0x10: This protocol version. This documen= t.
>>>=C2=A0 =C2=A0 Version 0x11: Unassigned.
>>>
>>>
>>> Appreciate your comments, suggestions.
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

--001a113dfc76c83c650547f4588a-- From nobody Tue Feb 7 10:08:13 2017 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 9E61D12940E for ; Tue, 7 Feb 2017 10:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, 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 gEAvb4heVpme for ; Tue, 7 Feb 2017 10:08:10 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F44128824 for ; Tue, 7 Feb 2017 10:08:09 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 7 Feb 2017 13:08:07 -0500 From: Dave Dolson To: "Andrew G. Malis" Thread-Topic: [sfc] Loop prevention Thread-Index: AQHSgV0zP3ZOpy8lukiNw70noAdQzqFeDc8AgAAO3QD//6+vwIAAVwmA//+zJuA= Date: Tue, 7 Feb 2017 18:08:06 +0000 Message-ID: References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98704FF00Fwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Cc: David Mozes , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:08:12 -0000 --_000_E8355113905631478EFF04F5AA706E98704FF00Fwtlexchp1sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCmIHdoaWNoIHdvdWxkIGJlIHRoZSBmb2xsb3dpbmcsIGNoZWNraW5nIGZvciBUVEw9MCBvbmx5 ICphZnRlciogZGVjcmVtZW50aW5nICh6ZXJvIGJlaW5nIGEgdmFsaWQgdmFsdWUgb24gdGhlIHdp cmUpOg0KDQogICAgc2V0IFRUTCA9IFRUTCAtIDEgICAgIC8vIHVuc2lnbmVkIDYtYml0IG1hdGg7 IHVuZGVyZmxvdyBmcm9tIDAtLT4weDNmIGlzIGV4cGVjdGVkDQogICAgaWYoVFRMID09MCkgdGhl biBkcm9wDQoNCg0KDQpGcm9tOiBBbmRyZXcgRy4gTWFsaXMgW21haWx0bzphZ21hbGlzQGdtYWls LmNvbV0NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA3LCAyMDE3IDEyOjQwIFBNDQpUbzogRGF2 ZSBEb2xzb24NCkNjOiBEYXZpZCBNb3plczsgSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbc2ZjXSBMb29wIHByZXZlbnRpb24NCg0KRGF2ZSwNCg0KSSBhZ3JlZSB0 aGF0IHdvcmtzLCBidXQgaXTigJlzIHNsaWdodCBtb3JlIGNvbXBsaWNhdGVkIGxvZ2ljIGFuZCBj b3VsZCBwb3RlbnRpYWxseSBhbGxvdyBtb3JlIHBhY2tldHMgdG8gbG9vcCwgdGhvc2UgZnJvbSBl YXJseSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkb27igJl0IGtub3cgaG93IHRvIHN0YXJ0IFRUTCBm cm9tIGFueSB2YWx1ZSBvdGhlciB0aGFuIHplcm8uIFN0YXJ0aW5nIGZyb20gemVybyB3b3VsZCBh bGxvdyBsb29wIGNoZWNraW5nIGZvciBwYWNrZXRzIG9yaWdpbmF0aW5nIGZyb20gZWFybHkgaW1w bGVtZW50YXRpb25zLg0KDQpDaGVlcnMsDQpBbmR5DQoNCg0KT24gVHVlLCBGZWIgNywgMjAxNyBh dCA2OjMyIFBNLCBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xz b25Ac2FuZHZpbmUuY29tPj4gd3JvdGU6DQpUbyBiZSBwcmVjaXNlLCBJ4oCZZCBsaWtlIHRvIHBy b3Bvc2UgdGhpcyBiZWhhdmlvciBieSBTRkZzOg0KaWYoVFRMICE9MCkgdGhlbg0KICAgIHNldCBU VEwgPSBUVEwgLSAxDQogICAgaWYoVFRMID09MCkgdGhlbiBkcm9wDQplbmRpZg0KDQpUaGlzIHNo b3VsZCBiZSBkb25lIHdoZW4gZm9yd2FyZGluZyBOU0ggKHZzLiByZWNlaXZpbmcpIHRvIGFsbG93 IGEgcGFja2V0IHdpdGggVFRMPT0xIHRvIGJlIHJlY2VpdmVkIGF0IHRoZSBwYXRoIHRlcm1pbnVz IHdpdGhvdXQgZHJvcHBpbmcgaXQuDQoNCkFzIEpvZWwgc3VnZ2VzdGVkLCAwIG1lYW5zIOKAnG5v dCBjb3VudGluZ+KAnS4NCg0KLURhdmUNCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRGF2 aWQgTW96ZXMNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA3LCAyMDE3IDEyOjE2IFBNDQpUbzog QW5kcmV3IEcuIE1hbGlzOyBKb2VsIE0uIEhhbHBlcm4NCkNjOiBzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBMb29wIHByZXZlbnRpb24NCg0KQ291 bnQgZG93biBUVEwgYW5kIGNvbXBhcmUgdG8gMCAgaXMgaG93IG1vc3Qgb2Ygbm90IGFsbCBvZiB0 aGUgQXBwbGljYXRpb25zICBiZWhhdmUgdG9kYXkNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m IEFuZHJldyBHLiBNYWxpcw0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDcsIDIwMTcgNjoyMiBQ TQ0KVG86IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbT4+DQpDYzogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3NmY10gTG9vcCBwcmV2ZW50aW9uDQoNCkpvZWwsDQoNCknigJltIGluIGZh dm9yIG9mIGxvb3AgcHJldmVudGlvbiBhbG9uZyB0aGUgbGluZXMgdGhhdCB3ZSBkaXNjdXNzZWQg aW4gV2VzdGZvcmQuIFdpdGggc3BlY2lmaWMgcmVnYXJkIHRvOg0KDQpUaGVyZSBpcyBvbmUgZnVy dGhlciBjb21wYXRpYmlsaXR5IGlzc3VlLiAgV2hhdCBpZiB0aGUgaW5ncmVzcyBjbGFzc2lmaWVy IHRoYXQgY3JlYXRlcyB0aGUgTlNIIGhlYWRlciBkb2VzIG5vdCBrbm93IGhvdyB0byBzZXQgaXQu IFRoZXJlIHNlZW0gdG8gYmUgdHdvIHBvc3NpYmlsaXRpZXMuICBPbmUgaXMgdG8gc2F5IHRoYXQg d2UgY291bGQgdXAgZnJvbSAwLiAgQXMgc3VjaCwgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHdp bGwgc2V0IGl0IGNvcnJlY3RseS4gIFRoaXMgd29ya3MuICBCdXQgaXQgaXMgY29udHJhcnkgdG8g Y29udmVudGlvbmFsIHByYWN0aWNlLiAgVGhlIG90aGVyIGNob2ljZSBpcyB0byBjb3VudCBkb3du LCBidXQgZGVjbGFyZSB0aGF0IDEgaXMgZXhwaXJhdGlvbiwgYW5kIDAgbWVhbnMgbm90LWNvdW50 aW5nLiAgVGhpcyBpcyBtb3JlIGxpbWl0aW5nLg0KSeKAmW0gaW4gZmF2b3Igb2Ygc3RhcnRpbmcg ZnJvbSB6ZXJvIGFuZCBjb3VudGluZyB1cCwgZm9yIG1heGltYWwgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkuIENvbnNpc3RlbmN5IHRvIHByaW9yIHByYWN0aWNlIGZvciBpdHMgb3duIHNha2UgaXMg YSBwb29yIGFyZ3VtZW50IHVubGVzcyB0aGVyZeKAmXMgYSBnb29kIHRlY2huaWNhbCByZWFzb24g Zm9yIGl0LCBzdWNoIGFzIGVhc2Ugb2YgaW1wbGVtZW50YXRpb24uDQoNCkNoZWVycywNCkFuZHkN Cg0KUFMgVG8gcXVvdGUgRW1lcnNvbiwgY29uc2lzdGVuY3kgaXMgdGhlIGhvYmdvYmxpbiBvZiBs aXR0bGUgbWluZHMuDQoNCg0K --_000_E8355113905631478EFF04F5AA706E98704FF00Fwtlexchp1sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCm IHdoaWNoIHdvdWxkIGJlIHRoZSBmb2xsb3dpbmcsIGNoZWNraW5nIGZvciBUVEw9MCBvbmx5ICo8 Yj5hZnRlcjwvYj4qIGRlY3JlbWVudGluZyAoemVybyBiZWluZyBhIHZhbGlkIHZhbHVlIG9uIHRo ZSB3aXJlKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBzZXQgVFRMID0gVFRMIC0gMSAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvLyB1bnNpZ25lZCA2LWJpdCBtYXRoOyB1bmRlcmZsb3cg ZnJvbSAwLS0mZ3Q7MHgzZiBpcyBleHBlY3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaWYoVFRMID09MCkgdGhlbiBkcm9wPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFu ZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDA3LCAyMDE3IDEyOjQwIFBNPGJyPg0KPGI+VG86PC9iPiBE YXZlIERvbHNvbjxicj4NCjxiPkNjOjwvYj4gRGF2aWQgTW96ZXM7IEpvZWwgTS4gSGFscGVybjsg c2ZjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBMb29wIHByZXZlbnRp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZlLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0IHdvcmtzLCBi dXQgaXTigJlzIHNsaWdodCBtb3JlIGNvbXBsaWNhdGVkIGxvZ2ljIGFuZCBjb3VsZCBwb3RlbnRp YWxseSBhbGxvdyBtb3JlIHBhY2tldHMgdG8gbG9vcCwgdGhvc2UgZnJvbSBlYXJseSBpbXBsZW1l bnRhdGlvbnMgdGhhdCBkb27igJl0IGtub3cgaG93IHRvIHN0YXJ0IFRUTCBmcm9tIGFueSB2YWx1 ZSBvdGhlciB0aGFuIHplcm8uIFN0YXJ0aW5nIGZyb20gemVybyB3b3VsZCBhbGxvdw0KIGxvb3Ag Y2hlY2tpbmcgZm9yIHBhY2tldHMgb3JpZ2luYXRpbmcgZnJvbSBlYXJseSBpbXBsZW1lbnRhdGlv bnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUdWUsIEZlYiA3LCAyMDE3IGF0IDY6MzIgUE0sIERhdmUgRG9sc29uICZsdDs8 YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kZG9s c29uQHNhbmR2aW5lLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UbyBiZSBwcmVjaXNlLCBJ4oCZZCBsaWtlIHRvIHByb3Bvc2UgdGhpcyBi ZWhhdmlvciBieSBTRkZzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmlmKFRUTCAh PTApIHRoZW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsgc2V0IFRUTCA9IFRUTCAtIDE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7ICZuYnNwO2lmKFRUTCA9PTApIHRoZW4gZHJvcDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPmVuZGlmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBzaG91bGQgYmUgZG9uZSB3aGVuIGZv cndhcmRpbmcgTlNIICh2cy4gcmVjZWl2aW5nKSB0byBhbGxvdyBhIHBhY2tldCB3aXRoIFRUTD09 MSB0byBiZSByZWNlaXZlZA0KIGF0IHRoZSBwYXRoIHRlcm1pbnVzIHdpdGhvdXQgZHJvcHBpbmcg aXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QXMgSm9lbCBzdWdnZXN0ZWQsIDAgbWVhbnMg4oCcbm90IGNvdW50 aW5n4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1EYXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2aWQgTW96ZXM8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMDcsIDIwMTcgMTI6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+ IEFuZHJldyBHLiBNYWxpczsgSm9lbCBNLiBIYWxwZXJuPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gTG9vcCBwcmV2ZW50aW9uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db3VudCBkb3duIFRUTCBhbmQgY29tcGFyZSB0byAw ICZuYnNwO2lzIGhvdyBtb3N0IG9mIG5vdCBhbGwgb2YgdGhlIEFwcGxpY2F0aW9ucyAmbmJzcDti ZWhhdmUgdG9kYXkNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gc2ZjIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5BbmRyZXcgRy4gTWFsaXM8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkg MDcsIDIwMTcgNjoyMiBQTTxicj4NCjxiPlRvOjwvYj4gSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBo cmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2Vs aGFscGVybi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtzZmNdIExvb3AgcHJldmVudGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Sm9lbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJltIGluIGZhdm9yIG9mIGxvb3AgcHJl dmVudGlvbiBhbG9uZyB0aGUgbGluZXMgdGhhdCB3ZSBkaXNjdXNzZWQgaW4gV2VzdGZvcmQuIFdp dGggc3BlY2lmaWMgcmVnYXJkIHRvOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXYgaWQ9Im1fMzAyMDQ1Njc3ODg5OTM1MTU3NjoxYXYiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5U aGVyZSBpcyBvbmUgZnVydGhlciBjb21wYXRpYmlsaXR5IGlzc3VlLiZuYnNwOyBXaGF0IGlmIHRo ZSBpbmdyZXNzIGNsYXNzaWZpZXIgdGhhdCBjcmVhdGVzIHRoZSBOU0ggaGVhZGVyIGRvZXMgbm90 IGtub3cgaG93IHRvIHNldCBpdC4gVGhlcmUgc2VlbSB0byBiZSB0d28gcG9zc2liaWxpdGllcy4m bmJzcDsgT25lIGlzIHRvIHNheSB0aGF0DQogd2UgY291bGQgdXAgZnJvbSAwLiZuYnNwOyBBcyBz dWNoLCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgd2lsbCBzZXQgaXQgY29ycmVjdGx5LiZuYnNw OyBUaGlzIHdvcmtzLiZuYnNwOyBCdXQgaXQgaXMgY29udHJhcnkgdG8gY29udmVudGlvbmFsIHBy YWN0aWNlLiZuYnNwOyBUaGUgb3RoZXIgY2hvaWNlIGlzIHRvIGNvdW50IGRvd24sIGJ1dCBkZWNs YXJlIHRoYXQgMSBpcyBleHBpcmF0aW9uLCBhbmQgMCBtZWFucyBub3QtY291bnRpbmcuJm5ic3A7 IFRoaXMgaXMgbW9yZSBsaW1pdGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSBpbiBmYXZv ciBvZiBzdGFydGluZyBmcm9tIHplcm8gYW5kIGNvdW50aW5nIHVwLCBmb3IgbWF4aW1hbCBiYWNr d2FyZHMgY29tcGF0aWJpbGl0eS4gQ29uc2lzdGVuY3kgdG8gcHJpb3IgcHJhY3RpY2UgZm9yIGl0 cyBvd24gc2FrZSBpcyBhIHBvb3IgYXJndW1lbnQgdW5sZXNzIHRoZXJl4oCZcyBhIGdvb2QNCiB0 ZWNobmljYWwgcmVhc29uIGZvciBpdCwgc3VjaCBhcyBlYXNlIG9mIGltcGxlbWVudGF0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5QUyBUbyBxdW90ZSBFbWVyc29uLCBjb25zaXN0ZW5jeSBpcyB0aGUgaG9iZ29i bGluIG9mIGxpdHRsZSBtaW5kcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E8355113905631478EFF04F5AA706E98704FF00Fwtlexchp1sandvi_-- From nobody Tue Feb 7 10:14:57 2017 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 B1000129E05 for ; Tue, 7 Feb 2017 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hfrmszSZSv-u for ; Tue, 7 Feb 2017 10:14:53 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 0D8E7129E0C for ; Tue, 7 Feb 2017 10:14:07 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id v77so166405023wmv.0 for ; Tue, 07 Feb 2017 10:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jp5sr108b6lrxzu9wInjyVDvBeizeRnUt2irgAaMS50=; b=VJMuFpjx+UzxxTFkqHaFMDGDyumY8nRdnZWjbF7TiTIwPDe5VEVmmbnLeWCc3+8OTS 4r31eGF7OUh3xW6rMltuaU1ZCf5/eE+NbMD2YNMYj10OyhOdho4suLug0jvm3yPxyEze aeNtQmQ0Kki12oRc3jQpOiwQmGZDZ7UDuPJKWc/gSwIlJUpzSEYPHF43Ys0opsR53LZN +GKDyTo6LdyJl49IdmgBQPjU+VbaJi1CfpGD/BId7fmpE3Wx7Xd9EYaMhtePwhWcP4m1 WOhHB6AjnV2ChRvF4rrX/IB5q6tcIHbxsKHUCZQOBYaUnAFLDI8MPPW106vrH9FuqlOn tREg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jp5sr108b6lrxzu9wInjyVDvBeizeRnUt2irgAaMS50=; b=LoQOfDA0XvUFCH2yDHD3L5VeFZlJqgWwjFJMxFTtj0dsf48fia6obLeo2E0Sq4rxIi ogXYgZciHNdCE8wOAxHAX1DfZ2+u+Qr1HmDwQi8Ed9AelcgC5cp8hNF/Qq8hhVPgE95I QYXHmVhKqN3Ai/SuCuGkJXHQMkVnfr5youQp9U2pzqxLDcIS0WqJdWEwSadqwkkfDKni FuDSPp/bW6inhAdiJ1oOEhqQG8RWenXkOsHRQWzTGr+us2G891p+cbBSorVrqqKZ2SdH tCZpPj0gxPY61PqFcQGFPKFCYu2b3sLQ2yPSkIg1LkXkY9BWpy3Vm78N2ZH1ODlnwdIu O/Zw== X-Gm-Message-State: AMke39nsZBi1X/4iFNSH+h2c5Jvbl5FYJ6aiVArtPwZusJOe73nj4jPZXBIGyeB3DxI5ZW3pXxfctVsrJixxKg== X-Received: by 10.28.19.207 with SMTP id 198mr13322362wmt.70.1486491245515; Tue, 07 Feb 2017 10:14:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.142.108 with HTTP; Tue, 7 Feb 2017 10:14:05 -0800 (PST) In-Reply-To: References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> From: Alia Atlas Date: Tue, 7 Feb 2017 13:14:05 -0500 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a1145b3f0a69bce0547f4b6f9 Archived-At: Cc: David Mozes , "Joel M. Halpern" , "Andrew G. Malis" , "sfc@ietf.org" Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:14:55 -0000 --001a1145b3f0a69bce0547f4b6f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [no hats] To support a uniform tunnel mode or to get an initial TTL, it is common to copy the TTL from the header being encapsulated (if it has one). Granted that there will already be round-off special considerations if 6 bits instead of 8 bits are used, but this is another aspect to consider when deciding whether to count down or up - along with the principal of least surprises. Regards, Alia On Tue, Feb 7, 2017 at 1:08 PM, Dave Dolson wrote: > =E2=80=A6 which would be the following, checking for TTL=3D0 only **after= ** > decrementing (zero being a valid value on the wire): > > > > set TTL =3D TTL - 1 // unsigned 6-bit math; underflow from 0-->0x= 3f > is expected > > if(TTL =3D=3D0) then drop > > > > > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Tuesday, February 07, 2017 12:40 PM > *To:* Dave Dolson > *Cc:* David Mozes; Joel M. Halpern; sfc@ietf.org > > *Subject:* Re: [sfc] Loop prevention > > > > Dave, > > > > I agree that works, but it=E2=80=99s slight more complicated logic and co= uld > potentially allow more packets to loop, those from early implementations > that don=E2=80=99t know how to start TTL from any value other than zero. = Starting > from zero would allow loop checking for packets originating from early > implementations. > > > > Cheers, > > Andy > > > > > > On Tue, Feb 7, 2017 at 6:32 PM, Dave Dolson wrote: > > To be precise, I=E2=80=99d like to propose this behavior by SFFs: > > if(TTL !=3D0) then > > set TTL =3D TTL - 1 > > if(TTL =3D=3D0) then drop > > endif > > > > This should be done when forwarding NSH (vs. receiving) to allow a packet > with TTL=3D=3D1 to be received at the path terminus without dropping it. > > > > As Joel suggested, 0 means =E2=80=9Cnot counting=E2=80=9D. > > > > -Dave > > > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Mozes > *Sent:* Tuesday, February 07, 2017 12:16 PM > *To:* Andrew G. Malis; Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] Loop prevention > > > > Count down TTL and compare to 0 is how most of not all of the > Applications behave today > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Andrew G. Malis > *Sent:* Tuesday, February 07, 2017 6:22 PM > *To:* Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] Loop prevention > > > > Joel, > > > > I=E2=80=99m in favor of loop prevention along the lines that we discussed= in > Westford. With specific regard to: > > > > There is one further compatibility issue. What if the ingress classifier > that creates the NSH header does not know how to set it. There seem to be > two possibilities. One is to say that we could up from 0. As such, > existing implementations will set it correctly. This works. But it is > contrary to conventional practice. The other choice is to count down, bu= t > declare that 1 is expiration, and 0 means not-counting. This is more > limiting. > > I=E2=80=99m in favor of starting from zero and counting up, for maximal b= ackwards > compatibility. Consistency to prior practice for its own sake is a poor > argument unless there=E2=80=99s a good technical reason for it, such as e= ase of > implementation. > > > > Cheers, > > Andy > > > > PS To quote Emerson, consistency is the hobgoblin of little minds. > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --001a1145b3f0a69bce0547f4b6f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[no hats]

To support a uniform tunnel m= ode or to get an initial TTL, it is common to copy the
TTL from t= he header being encapsulated (if it has one).=C2=A0 Granted that there will= already
be round-off special considerations if 6 bits instead of= 8 bits are used, but this is another
aspect to consider when dec= iding whether to count down or up - along with the principal
of l= east surprises.

Regards,
Alia

On Tue, Feb 7, 2= 017 at 1:08 PM, Dave Dolson <ddolson@sandvine.com> wrote:=

=E2=80=A6 which would be = the following, checking for TTL=3D0 only *after* decrementing (zero = being a valid value on the wire):

=C2=A0

=C2=A0=C2=A0=C2=A0 set TT= L =3D TTL - 1 =C2=A0=C2=A0=C2=A0=C2=A0// unsigned 6-bit math; underflow fro= m 0-->0x3f is expected

=C2=A0=C2=A0=C2=A0 if(TTL= =3D=3D0) then drop

=C2=A0

=C2=A0

=C2=A0

From: Andrew G= . Malis [mailto:agma= lis@gmail.com]
Sent: Tuesday, February 07, 2017 12:40 PM
To: Dave Dolson
Cc: David Mozes; Joel M. Halpern; sfc@ietf.org


Subject: Re: [sfc] Loop prevention

<= div>

=C2=A0

Dave,

=C2=A0

I agree that works, but it=E2=80=99s slight more com= plicated logic and could potentially allow more packets to loop, those from= early implementations that don=E2=80=99t know how to start TTL from any va= lue other than zero. Starting from zero would allow loop checking for packets originating from early implementations.

=C2=A0

Cheers,

Andy

=C2=A0

=C2=A0

On Tue, Feb 7, 2017 at 6:32 PM, Dave Dolson <ddolson@sandvine.com<= /a>> wrote:

To be precise, I=E2=80=99= d like to propose this behavior by SFFs:

if(TTL !=3D0) then=

=C2=A0=C2=A0=C2=A0 set TT= L =3D TTL - 1=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0 =C2=A0if(TTL= =3D=3D0) then drop

endif

=C2=A0

This should be done when = forwarding NSH (vs. receiving) to allow a packet with TTL=3D=3D1 to be rece= ived at the path terminus without dropping it.

=C2=A0

As Joel suggested, 0 mean= s =E2=80=9Cnot counting=E2=80=9D.

=C2=A0

-Dave

=C2=A0

=C2=A0

From: sfc [mai= lto:sfc-bounces@i= etf.org] On Behalf Of David Mozes
Sent: Tuesday, February 07, 2017 12:16 PM
To: Andrew G. Malis; Joel M. Halpern
Cc: sfc@ietf.org
Subject: Re: [sfc] Loop prevention

=C2=A0

Count down TTL and compar= e to 0 =C2=A0is how most of not all of the Applications =C2=A0behave today

=C2=A0

From: sfc [m= ailto:sfc-bounces= @ietf.org] On Behalf Of Andrew G. Malis
Sent: Tuesday, February 07, 2017 6:22 PM
To: Joel M. Halpern <jmh@joelhalpern.com>
Cc: sfc@ietf.org
Subject: Re: [sfc] Loop prevention

=C2=A0

Joel,

=C2=A0

I=E2=80=99m in favor of loop prevention along the li= nes that we discussed in Westford. With specific regard to:

=C2=A0

There is one further = compatibility issue.=C2=A0 What if the ingress classifier that creates the = NSH header does not know how to set it. There seem to be two possibilities.= =C2=A0 One is to say that we could up from 0.=C2=A0 As such, existing implementations will set it co= rrectly.=C2=A0 This works.=C2=A0 But it is contrary to conventional practic= e.=C2=A0 The other choice is to count down, but declare that 1 is expiratio= n, and 0 means not-counting.=C2=A0 This is more limiting.

I=E2=80=99m in favor of starting from zero and count= ing up, for maximal backwards compatibility. Consistency to prior practice = for its own sake is a poor argument unless there=E2=80=99s a good technical reason for it, such as ease of implementation.

=C2=A0

Cheers,

Andy

=C2=A0

PS To quote Emerson, consistency is the hobgoblin of= little minds.

=C2=A0

=C2=A0


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


--001a1145b3f0a69bce0547f4b6f9-- From nobody Tue Feb 7 10:34:22 2017 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 3C2CB129E14 for ; Tue, 7 Feb 2017 10:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=mellanox.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 moEP-ca8eBDx for ; Tue, 7 Feb 2017 10:34:18 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0070.outbound.protection.outlook.com [104.47.2.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B22129593 for ; Tue, 7 Feb 2017 10:34:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AQ054WRBcCYzDebpjIjDHnOSxG3kFx76k/emdBhpvB4=; b=bbPyI0F/RHmD/Hzx6VPh8bWJ4Om5KA1HNmrBLPle7jXWANSnrODE1YFrpof+t6n+25K6wy9VvAsSXgdSyy88uq5mw3b5V7U73QAAIMMjV+N9/Mu9o2957Hz9LtQel2/Kh/GDdYpbVRAbe6jGj7O750YdC8439Z0J9iMyky4MoGk= Received: from HE1PR0501MB2138.eurprd05.prod.outlook.com (10.167.246.22) by HE1PR0501MB2139.eurprd05.prod.outlook.com (10.167.246.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 7 Feb 2017 18:34:14 +0000 Received: from HE1PR0501MB2138.eurprd05.prod.outlook.com ([10.167.246.22]) by HE1PR0501MB2138.eurprd05.prod.outlook.com ([10.167.246.22]) with mapi id 15.01.0888.026; Tue, 7 Feb 2017 18:34:14 +0000 From: David Mozes To: "Andrew G. Malis" Thread-Topic: [sfc] Loop prevention Thread-Index: AQHSgV006ERnxsBQCUCxLbTFg8ULT6Fduf0AgAAObLCAAAUVAIAAECBg Date: Tue, 7 Feb 2017 18:34:13 +0000 Message-ID: References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> 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=davidm@mellanox.com; x-originating-ip: [77.138.166.110] x-ms-office365-filtering-correlation-id: e4b19c0e-960c-4f14-ecbd-08d44f87ea8c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0501MB2139; x-microsoft-exchange-diagnostics: 1; HE1PR0501MB2139; 7:fAGJKB48DsjXX4lcLnfk5Kwx5CyPxAHuSR0tICHIjvdxogogR3VcP30Pm/Lu+eM3yIdWCKXycvZSfXvFJ3EfTtVWPBbuHveEZydmHTa5cPmuKQ1J18o2PXbTyDaXfvk2Ydl00HMqy9/r2e2FAvYT8aiv0DoEajKQ1vDdn6l3t9sFLwgbgKDXgksPmjeH2CCos+IbEoo/pdsed5KHgeLVT+2tLLqQt1iH67tMOPUfWGdMgXyP+qeKy9XrWitcgFHxTvhNXcAQigzFKjOnSM5iLnUvCy5RM+AzgLhS4Iq1dduz92NfkJdIANH4pafbrEcDp9LDcepF5Ap0ZhgXHAt1bjPpcVWd9CddDCtChSWS+duOU08Q/GBxX6H8FtcknBS/PADYVybs/y7clueyQGgO9mCIWWAGl8CqwqcZCexbEAUtzJSpVL2tnwFradGBzlhL12hGRuKZw0WneM2DS7Fbb73klq9kv38I9bVZLc23d3m8c0akqXLSmTRZweK127pEYZienLwSosTf2ei0LdI1Tg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(20170203043)(8121501046)(2017020603029)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(20161123555025)(6072148); SRVR:HE1PR0501MB2139; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0501MB2139; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(377454003)(189002)(24454002)(199003)(8936002)(2900100001)(101416001)(50986999)(81156014)(81166006)(54356999)(76176999)(93886004)(106356001)(106116001)(6116002)(102836003)(8676002)(105586002)(2906002)(6436002)(3660700001)(39060400001)(6506006)(122556002)(77096006)(3846002)(790700001)(6306002)(189998001)(92566002)(229853002)(236005)(110136004)(1411001)(7696004)(25786008)(38730400002)(54896002)(3280700002)(55016002)(66066001)(2950100002)(5660300001)(74316002)(54906002)(4326007)(99286003)(53936002)(97736004)(33656002)(68736007)(7736002)(86362001)(6246003)(9686003)(6916009)(19609705001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0501MB2139; H:HE1PR0501MB2138.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0501MB2138868274B4B1CF5139E13CB6430HE1PR0501MB2138_" MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2017 18:34:13.8264 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2139 Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:34:20 -0000 --_000_HE1PR0501MB2138868274B4B1CF5139E13CB6430HE1PR0501MB2138_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IHNwZWFrIG9uIOKAnEFMVeKAnSBjb21wYXJlIGlzIHRoZSBzYW1lIHRoZXNlIGRheXMg YXMgb24gNjAtNzAgIHNpbmNlICBpbiB0aGUgSFcgeW91IHdpbGwgZG8NCklmICgoIGFsbC14KSA9 PSAwICkgIHRvZGF5IGFzIHdlbGwgLg0KSWYgeW91IHNwZWFrIG9uIFRDQU0gY29tcGFyZSBpdCBp cyBwb3NzaWJsZSAuSG93ZXZlciB5b3UgYXJlIGxpbWl0IHlvdXJzZWxmLi4NCg0KRnJvbTogQW5k cmV3IEcuIE1hbGlzIFttYWlsdG86YWdtYWxpc0BnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBG ZWJydWFyeSAwNywgMjAxNyA3OjMyIFBNDQpUbzogRGF2aWQgTW96ZXMgPGRhdmlkbUBtZWxsYW5v eC5jb20+DQpDYzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgc2ZjQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gTG9vcCBwcmV2ZW50aW9uDQoNCkRhdmlkLA0KDQpC YWNrIGluIHRoZSA2MHMgb3IgNzBzLCB0aGF0IG1heSBoYXZlIGJlZW4gdGhlIGVhc2llc3Qgd2F5 IHRvIGltcGxlbWVudCwgc2F5LCBJUCBUVEwsIGFuZCBldmVyeXRoaW5nIGVsc2UgZm9sbG93ZWQu IEhvd2V2ZXIsIGlzIGluY3JlbWVudCBhbmQgY29tcGFyZSB0byBhbGwgb25lcyBhbnkgbW9yZSBk aWZmaWN1bHQgdGhlc2UgZGF5cz8NCg0KQ2hlZXJzLA0KQW5keQ0KDQoNCk9uIFR1ZSwgRmViIDcs IDIwMTcgYXQgNjoxNSBQTSwgRGF2aWQgTW96ZXMgPGRhdmlkbUBtZWxsYW5veC5jb208bWFpbHRv OmRhdmlkbUBtZWxsYW5veC5jb20+PiB3cm90ZToNCkNvdW50IGRvd24gVFRMIGFuZCBjb21wYXJl IHRvIDAgIGlzIGhvdyBtb3N0IG9mIG5vdCBhbGwgb2YgdGhlIEFwcGxpY2F0aW9ucyAgYmVoYXZl IHRvZGF5DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6 IFR1ZXNkYXksIEZlYnJ1YXJ5IDA3LCAyMDE3IDY6MjIgUE0NClRvOiBKb2VsIE0uIEhhbHBlcm4g PGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Pg0KQ2M6IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIExvb3Ag cHJldmVudGlvbg0KDQpKb2VsLA0KDQpJ4oCZbSBpbiBmYXZvciBvZiBsb29wIHByZXZlbnRpb24g YWxvbmcgdGhlIGxpbmVzIHRoYXQgd2UgZGlzY3Vzc2VkIGluIFdlc3Rmb3JkLiBXaXRoIHNwZWNp ZmljIHJlZ2FyZCB0bzoNCg0KVGhlcmUgaXMgb25lIGZ1cnRoZXIgY29tcGF0aWJpbGl0eSBpc3N1 ZS4gIFdoYXQgaWYgdGhlIGluZ3Jlc3MgY2xhc3NpZmllciB0aGF0IGNyZWF0ZXMgdGhlIE5TSCBo ZWFkZXIgZG9lcyBub3Qga25vdyBob3cgdG8gc2V0IGl0LiBUaGVyZSBzZWVtIHRvIGJlIHR3byBw b3NzaWJpbGl0aWVzLiAgT25lIGlzIHRvIHNheSB0aGF0IHdlIGNvdWxkIHVwIGZyb20gMC4gIEFz IHN1Y2gsIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyB3aWxsIHNldCBpdCBjb3JyZWN0bHkuICBU aGlzIHdvcmtzLiAgQnV0IGl0IGlzIGNvbnRyYXJ5IHRvIGNvbnZlbnRpb25hbCBwcmFjdGljZS4g IFRoZSBvdGhlciBjaG9pY2UgaXMgdG8gY291bnQgZG93biwgYnV0IGRlY2xhcmUgdGhhdCAxIGlz IGV4cGlyYXRpb24sIGFuZCAwIG1lYW5zIG5vdC1jb3VudGluZy4gIFRoaXMgaXMgbW9yZSBsaW1p dGluZy4NCknigJltIGluIGZhdm9yIG9mIHN0YXJ0aW5nIGZyb20gemVybyBhbmQgY291bnRpbmcg dXAsIGZvciBtYXhpbWFsIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LiBDb25zaXN0ZW5jeSB0byBw cmlvciBwcmFjdGljZSBmb3IgaXRzIG93biBzYWtlIGlzIGEgcG9vciBhcmd1bWVudCB1bmxlc3Mg dGhlcmXigJlzIGEgZ29vZCB0ZWNobmljYWwgcmVhc29uIGZvciBpdCwgc3VjaCBhcyBlYXNlIG9m IGltcGxlbWVudGF0aW9uLg0KDQpDaGVlcnMsDQpBbmR5DQoNClBTIFRvIHF1b3RlIEVtZXJzb24s IGNvbnNpc3RlbmN5IGlzIHRoZSBob2Jnb2JsaW4gb2YgbGl0dGxlIG1pbmRzLg0KDQoNCg== --_000_HE1PR0501MB2138868274B4B1CF5139E13CB6430HE1PR0501MB2138_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHlvdSBzcGVhayBvbiDigJxBTFXigJ0g Y29tcGFyZSBpcyB0aGUgc2FtZSB0aGVzZSBkYXlzIGFzIG9uIDYwLTcwICZuYnNwO3NpbmNlICZu YnNwO2luIHRoZSBIVyB5b3Ugd2lsbCBkbyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmICgo IGFsbC14KSA9PSAwICkgJm5ic3A7dG9kYXkgYXMgd2VsbCAuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklm IHlvdSBzcGVhayBvbiBUQ0FNIGNvbXBhcmUgaXQgaXMgcG9zc2libGUgLkhvd2V2ZXIgeW91IGFy ZSBsaW1pdCB5b3Vyc2VsZi4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5kcmV3IEcuIE1hbGlzIFttYWlsdG86YWdt YWxpc0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMDcs IDIwMTcgNzozMiBQTTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgTW96ZXMgJmx0O2RhdmlkbUBtZWxs YW5veC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb2VsIE0uIEhhbHBlcm4gJmx0O2ptaEBqb2Vs aGFscGVybi5jb20mZ3Q7OyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtz ZmNdIExvb3AgcHJldmVudGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkRhdmlkLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFj ayBpbiB0aGUgNjBzIG9yIDcwcywgdGhhdCBtYXkgaGF2ZSBiZWVuIHRoZSBlYXNpZXN0IHdheSB0 byBpbXBsZW1lbnQsIHNheSwgSVAgVFRMLCBhbmQgZXZlcnl0aGluZyBlbHNlIGZvbGxvd2VkLiBI b3dldmVyLCBpcyBpbmNyZW1lbnQgYW5kIGNvbXBhcmUgdG8gYWxsIG9uZXMgYW55IG1vcmUgZGlm ZmljdWx0IHRoZXNlIGRheXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiA3LCAyMDE3IGF0IDY6MTUgUE0sIERh dmlkIE1vemVzICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWRtQG1lbGxhbm94LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmRhdmlkbUBtZWxsYW5veC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItcmlnaHQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db3VudCBkb3duIFRUTCBhbmQgY29tcGFyZSB0 byAwICZuYnNwO2lzIGhvdyBtb3N0IG9mIG5vdCBhbGwgb2YgdGhlIEFwcGxpY2F0aW9ucyAmbmJz cDtiZWhhdmUgdG9kYXkNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc2ZjIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZXcgRy4gTWFsaXM8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMDcsIDIwMTcgNjoyMiBQTTxicj4NCjxiPlRvOjwvYj4g Sm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIExvb3AgcHJldmVudGlvbjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Kb2VsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SeKAmW0gaW4gZmF2b3Igb2YgbG9vcCBwcmV2ZW50aW9uIGFsb25nIHRoZSBs aW5lcyB0aGF0IHdlIGRpc2N1c3NlZCBpbiBXZXN0Zm9yZC4gV2l0aCBzcGVjaWZpYyByZWdhcmQg dG86PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgaWQ9Im1fLTc2ODQz NDkxMTAxNzg4NjM5MTY6MWF2Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlcmUgaXMgb25lIGZ1cnRo ZXIgY29tcGF0aWJpbGl0eSBpc3N1ZS4mbmJzcDsgV2hhdCBpZiB0aGUgaW5ncmVzcyBjbGFzc2lm aWVyIHRoYXQgY3JlYXRlcyB0aGUgTlNIIGhlYWRlciBkb2VzIG5vdCBrbm93IGhvdyB0byBzZXQg aXQuIFRoZXJlIHNlZW0gdG8gYmUgdHdvIHBvc3NpYmlsaXRpZXMuJm5ic3A7IE9uZSBpcyB0byBz YXkgdGhhdA0KIHdlIGNvdWxkIHVwIGZyb20gMC4mbmJzcDsgQXMgc3VjaCwgZXhpc3RpbmcgaW1w bGVtZW50YXRpb25zIHdpbGwgc2V0IGl0IGNvcnJlY3RseS4mbmJzcDsgVGhpcyB3b3Jrcy4mbmJz cDsgQnV0IGl0IGlzIGNvbnRyYXJ5IHRvIGNvbnZlbnRpb25hbCBwcmFjdGljZS4mbmJzcDsgVGhl IG90aGVyIGNob2ljZSBpcyB0byBjb3VudCBkb3duLCBidXQgZGVjbGFyZSB0aGF0IDEgaXMgZXhw aXJhdGlvbiwgYW5kIDAgbWVhbnMgbm90LWNvdW50aW5nLiZuYnNwOyBUaGlzIGlzIG1vcmUgbGlt aXRpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmW0gaW4gZmF2b3Igb2Ygc3RhcnRpbmcgZnJv bSB6ZXJvIGFuZCBjb3VudGluZyB1cCwgZm9yIG1heGltYWwgYmFja3dhcmRzIGNvbXBhdGliaWxp dHkuIENvbnNpc3RlbmN5IHRvIHByaW9yIHByYWN0aWNlIGZvciBpdHMgb3duIHNha2UgaXMgYSBw b29yIGFyZ3VtZW50IHVubGVzcyB0aGVyZeKAmXMgYSBnb29kDQogdGVjaG5pY2FsIHJlYXNvbiBm b3IgaXQsIHN1Y2ggYXMgZWFzZSBvZiBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoZWVycyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5keTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UFMgVG8g cXVvdGUgRW1lcnNvbiwgY29uc2lzdGVuY3kgaXMgdGhlIGhvYmdvYmxpbiBvZiBsaXR0bGUgbWlu ZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR0501MB2138868274B4B1CF5139E13CB6430HE1PR0501MB2138_-- From nobody Tue Feb 7 10:51:45 2017 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 E49951295AC for ; Tue, 7 Feb 2017 10:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 TMkoefZiljCS for ; Tue, 7 Feb 2017 10:51:42 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BAA1295AB for ; Tue, 7 Feb 2017 10:51:42 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v17IpdFf028908; Tue, 7 Feb 2017 18:51:39 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v17IpYat028869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2017 18:51:38 GMT From: "Adrian Farrel" To: References: In-Reply-To: Date: Tue, 7 Feb 2017 18:51:33 -0000 Message-ID: <043701d28173$36ba5910$a42f0b30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMwW1cHrKG968Th9x+fN229nJwszwHbHX70AuxsmOgBqeoenp5unxcw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22872.001 X-TM-AS-Result: No--4.788-10.0-31-10 X-imss-scan-details: No--4.788-10.0-31-10 X-TMASE-MatchedRID: O/y65JfDwwuprq1S5LAsRovtmwtVGLEkMvOr6OZ/YUGae6AcsiK/zXhO h+DpnSW+nVYlQsH/svMw6avziiXmYTRn2xdwrsXpOuYv9zBApTy6WbbLoel2pSxfh0kL+Aj+BUz 2Q+xpjHgJWFp83EhTV6nP+GlAtqbK5UcZtwNsCro5f9Xw/xqKXVsKO+9Zlb5Jme9AzntO/JtQSF bL1bvQASdET58jp62SWJrP2U6HaLtEPWh3zfwJh0ixTH65Mut4rEg3ietvc3/MkkBfRu6VsJXxt w29Ds3QxxubCYCBm2N0/tMEY01lbyiguUAvmyXo6Hq9RCTLxvsstHmcXeW1eBVSGW4LjW40FYnP SoXfG8ckhYHVA/r8kw== Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:51:44 -0000 A bit surprised that we're having this conversation, but anyway how about we include some text like the following in the NSH draft? Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Adrian > Maybe we should add a warning to the draft for the early implementers > saying that the risk belongs to you and the WG does not take any > responsibility for the early birds. From nobody Tue Feb 7 11:02:41 2017 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 4FB991295AB for ; Tue, 7 Feb 2017 11:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rY8EvKdVSot for ; Tue, 7 Feb 2017 11:02:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3D3129430 for ; Tue, 7 Feb 2017 11:02:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAE53885; Tue, 07 Feb 2017 19:02:34 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 19:02:33 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 11:02:29 -0800 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: NSH base header length Thread-Index: AdKBciU5/sPmZdaqR7eR29Y7qdfNlw== Date: Tue, 7 Feb 2017 19:02:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.102] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5D4CSJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.589A19CA.00D2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 042c5747e99d494055ad3f62caaa99a2 Archived-At: Subject: [sfc] NSH base header length X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:02:38 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5D4CSJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings WG, At the recent interim meeting we discussed the current text around the leng= th field in the NSH base header. The last sentence of this text in section = 3.2 of draft-ietf-sfc-nsh-10 reads: "The length field indicates the "end" of NSH and where the original packet/= frame begins." A proposed rework of this text is as follows: "The length field indicates the beginning of the packet/frame of the next p= rotocol reflected in the NSH base header". Please provide comments to the mailing list for this change. Thanks! Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5D4CSJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings WG,

 

At the recent interim meeting we discussed the curre= nt text around the length field in the NSH base header. The last sentence o= f this text in section 3.2 of draft-ietf-sfc-nsh-10 reads:

 

“The length field indicates the “endR= 21; of NSH and where the original packet/frame begins.”

 

A proposed rework of this text is as follows:

 

“The length field indicates the beginning of t= he packet/frame of the next protocol reflected in the NSH base header”= ;.

 

Please provide comments to the mailing list for this= change.

 

Thanks!

 

Jim & Joel

 

 

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5D4CSJCEML701CHMchina_-- From nobody Tue Feb 7 11:26:25 2017 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 045BA129E25 for ; Tue, 7 Feb 2017 11:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSt_B73BZfhA for ; Tue, 7 Feb 2017 11:26:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDAD12940D for ; Tue, 7 Feb 2017 11:26:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAE55814; Tue, 07 Feb 2017 19:26:20 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 19:26:18 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 11:24:08 -0800 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pA== Date: Tue, 7 Feb 2017 19:24:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.102] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5D99SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.589A1F5C.0065, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d1f32a448bb7c1945c369553efff5b34 Archived-At: Subject: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:26:24 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5D99SJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings WG, At the recent interim meeting we discussed the current text on decrementing= the service index in the NSH service path header. The existing text in sec= tion 3.3 of draft-ietf-sfc-nsh-10 reads: "Service Index MUST be decremented by Service Functions or by SFC Proxy nod= es after performing required services ..." A request was made to be more specific and update the text as follows: "Service index MUST be decremented by a value of 1 by Service Functions or = by SFC Proxy nodes after performing required services ..." Please provide comments on this change to the mailing list. Thanks! Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5D99SJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings WG,

 

At the recent interim meeting we discussed the curre= nt text on decrementing the service index in the NSH service path header. T= he existing text in section 3.3 of draft-ietf-sfc-nsh-10 reads:<= /p>

 

“Service Index MUST be decremented by Service = Functions or by SFC Proxy nodes after performing required services …&= #8221;

 

A request was made to be more specific and update th= e text as follows:

 

“Service index MUST be decremented by a val= ue of 1 by Service Functions or by SFC Proxy nodes after performing req= uired services …”

 

Please provide comments on this change to the mailin= g list.

 

Thanks!

 

Jim & Joel

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5D99SJCEML701CHMchina_-- From nobody Tue Feb 7 11:34:16 2017 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 1B1C5129E4D for ; Tue, 7 Feb 2017 11:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7V4XQgevceA for ; Tue, 7 Feb 2017 11:34:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851A3129E4A for ; Tue, 7 Feb 2017 11:34:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAE56460; Tue, 07 Feb 2017 19:34:11 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 19:34:10 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 11:32:45 -0800 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: SFC Interim minutes posted to datatracker Thread-Index: AdKBeNwr3UkT6SoySTqbfKoeth6MmA== Date: Tue, 7 Feb 2017 19:32:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.102] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5DB4SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.589A2134.001E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 15f3e11ede66eefd53ddb00007448908 Archived-At: Subject: [sfc] SFC Interim minutes posted to datatracker X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:34:15 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5DB4SJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG, Meeting minutes for the SFC interim meeting now posted here: https://datatracker.ietf.org/meeting/interim-2017-sfc-01/session/sfc Thanks! Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5DB4SJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG,

 

Meeting minutes for the SFC interim meeting now post= ed here:

 

https://datatracker.ietf.org/meeting/interim-2017-sf= c-01/session/sfc

 

Thanks!

 

Jim & Joel

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5DB4SJCEML701CHMchina_-- From nobody Tue Feb 7 11:34:44 2017 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 BAF83129E4D for ; Tue, 7 Feb 2017 11:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, 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 8VRz2afyg7iC for ; Tue, 7 Feb 2017 11:34:41 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB19129E4A for ; Tue, 7 Feb 2017 11:34:35 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 7 Feb 2017 14:34:34 -0500 From: Dave Dolson To: James N Guichard , "sfc@ietf.org" Thread-Topic: NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAAAhKfQ Date: Tue, 7 Feb 2017 19:34:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98704FF5D9wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:34:43 -0000 --_000_E8355113905631478EFF04F5AA706E98704FF5D9wtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I approve of this clarification. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of James N Guichard Sent: Tuesday, February 07, 2017 2:24 PM To: sfc@ietf.org Subject: [sfc] NSH Service Index Decrement Greetings WG, At the recent interim meeting we discussed the current text on decrementing= the service index in the NSH service path header. The existing text in sec= tion 3.3 of draft-ietf-sfc-nsh-10 reads: "Service Index MUST be decremented by Service Functions or by SFC Proxy nod= es after performing required services ..." A request was made to be more specific and update the text as follows: "Service index MUST be decremented by a value of 1 by Service Functions or = by SFC Proxy nodes after performing required services ..." Please provide comments on this change to the mailing list. Thanks! Jim & Joel --_000_E8355113905631478EFF04F5AA706E98704FF5D9wtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I approve of this clar= ification.

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of James N Guichard
Sent: Tuesday, February 07, 2017 2:24 PM
To: sfc@ietf.org
Subject: [sfc] NSH Service Index Decrement

 

Greetings WG,

 

At the recent interim meeting we discussed the curre= nt text on decrementing the service index in the NSH service path header. T= he existing text in section 3.3 of draft-ietf-sfc-nsh-10 reads:<= /p>

 

“Service Index MUST be decremented by Service = Functions or by SFC Proxy nodes after performing required services …&= #8221;

 

A request was made to be more specific and update th= e text as follows:

 

“Service index MUST be decremented by a val= ue of 1 by Service Functions or by SFC Proxy nodes after performing req= uired services …”

 

Please provide comments on this change to the mailin= g list.

 

Thanks!

 

Jim & Joel

 

--_000_E8355113905631478EFF04F5AA706E98704FF5D9wtlexchp1sandvi_-- From nobody Tue Feb 7 11:34:59 2017 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 66BB8129E4A for ; Tue, 7 Feb 2017 11:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, 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 gocouppW-X5e for ; Tue, 7 Feb 2017 11:34:57 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8889F129E3E for ; Tue, 7 Feb 2017 11:34:54 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 7 Feb 2017 14:34:53 -0500 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 7 Feb 2017 14:34:53 -0500 From: Dave Dolson To: James N Guichard , "sfc@ietf.org" Thread-Topic: NSH base header length Thread-Index: AdKBciU5/sPmZdaqR7eR29Y7qdfNlwABxVWw Date: Tue, 7 Feb 2017 19:34:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98704FF5EDwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH base header length X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:34:58 -0000 --_000_E8355113905631478EFF04F5AA706E98704FF5EDwtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I approve. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of James N Guichard Sent: Tuesday, February 07, 2017 2:02 PM To: sfc@ietf.org Subject: [sfc] NSH base header length Greetings WG, At the recent interim meeting we discussed the current text around the leng= th field in the NSH base header. The last sentence of this text in section = 3.2 of draft-ietf-sfc-nsh-10 reads: "The length field indicates the "end" of NSH and where the original packet/= frame begins." A proposed rework of this text is as follows: "The length field indicates the beginning of the packet/frame of the next p= rotocol reflected in the NSH base header". Please provide comments to the mailing list for this change. Thanks! Jim & Joel --_000_E8355113905631478EFF04F5AA706E98704FF5EDwtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I approve.<= /span>

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of James N Guichard
Sent: Tuesday, February 07, 2017 2:02 PM
To: sfc@ietf.org
Subject: [sfc] NSH base header length

 

Greetings WG,

 

At the recent interim meeting we discussed the curre= nt text around the length field in the NSH base header. The last sentence o= f this text in section 3.2 of draft-ietf-sfc-nsh-10 reads:

 

“The length field indicates the “endR= 21; of NSH and where the original packet/frame begins.”

 

A proposed rework of this text is as follows:

 

“The length field indicates the beginning of t= he packet/frame of the next protocol reflected in the NSH base header”= ;.

 

Please provide comments to the mailing list for this= change.

 

Thanks!

 

Jim & Joel

 

 

 

 

--_000_E8355113905631478EFF04F5AA706E98704FF5EDwtlexchp1sandvi_-- From nobody Tue Feb 7 12:27:48 2017 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 4979B1295D0 for ; Tue, 7 Feb 2017 12:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0cE5fBgRQt1 for ; Tue, 7 Feb 2017 12:27:43 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD7B129548 for ; Tue, 7 Feb 2017 12:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13188; q=dns/txt; s=iport; t=1486499263; x=1487708863; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aUcyWGR8Pga+q3nmNZPgiy8uM+SIC/Ug8FkIqBa0vu4=; b=hU4fZY0iLDh0YwmkjSgN1U8VKGkvBsl0ENm4kUnw3weI9Hl0zjERESeg pHp1H5optBsizbgYq69psh41pJObaVWuoZSnKrRRHrcPWiiScsPaJILNI +aqhmSF3HOeW5MebDtLFiBP+LP+vTFYgFrzWZLzBoS0JEEgobfttMQH2A Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAQA0LZpY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB4NRigiRb5AphSyCDB8BCoV4AhqCPD8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEagIEAQEhSwsQAgEGAj8DAgICJQsUEQEBBA4FiXMOkmqdToIli0oBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYZMggUIgmKFCoJQLoIxBZVShhkBkg2Be4UXiXG?= =?us-ascii?q?IKYplAR84fk8VPBEBhjB1AYdngQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208,217";a="382615062" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2017 20:27:42 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v17KRgDn009094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Feb 2017 20:27:42 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Feb 2017 15:27:41 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 7 Feb 2017 15:27:41 -0500 From: "Carlos Pignataro (cpignata)" To: James N Guichard Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAAM3ZGA Date: Tue, 7 Feb 2017 20:27:41 +0000 Message-ID: <7D3A8BCA-A7B6-4987-9F3F-5171F5CB4C59@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.72.44] Content-Type: multipart/alternative; boundary="_000_7D3A8BCAA7B649879F3F5171F5CB4C59ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:27:46 -0000 --_000_7D3A8BCAA7B649879F3F5171F5CB4C59ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIHVzZWZ1bCBjbGFyaWZpY2F0aW9uLg0KDQpUaGFua3MsDQoNCuKAlA0KQ2FybG9z IFBpZ25hdGFybywgY2FybG9zQGNpc2NvLmNvbTxtYWlsdG86Y2FybG9zQGNpc2NvLmNvbT4NCg0K 4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3Rh bmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5kIG1vcmUgcGhvdG9zeW50aGVzaXMuIg0KDQpPbiBGZWIg NywgMjAxNywgYXQgMjoyNCBQTSwgSmFtZXMgTiBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBo dWF3ZWkuY29tPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20+PiB3cm90ZToNCg0K R3JlZXRpbmdzIFdHLA0KDQpBdCB0aGUgcmVjZW50IGludGVyaW0gbWVldGluZyB3ZSBkaXNjdXNz ZWQgdGhlIGN1cnJlbnQgdGV4dCBvbiBkZWNyZW1lbnRpbmcgdGhlIHNlcnZpY2UgaW5kZXggaW4g dGhlIE5TSCBzZXJ2aWNlIHBhdGggaGVhZGVyLiBUaGUgZXhpc3RpbmcgdGV4dCBpbiBzZWN0aW9u IDMuMyBvZiBkcmFmdC1pZXRmLXNmYy1uc2gtMTAgcmVhZHM6DQoNCuKAnFNlcnZpY2UgSW5kZXgg TVVTVCBiZSBkZWNyZW1lbnRlZCBieSBTZXJ2aWNlIEZ1bmN0aW9ucyBvciBieSBTRkMgUHJveHkg bm9kZXMgYWZ0ZXIgcGVyZm9ybWluZyByZXF1aXJlZCBzZXJ2aWNlcyDigKbigJ0NCg0KQSByZXF1 ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUgc3BlY2lmaWMgYW5kIHVwZGF0ZSB0aGUgdGV4dCBhcyBm b2xsb3dzOg0KDQrigJxTZXJ2aWNlIGluZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgYnkgYSB2YWx1 ZSBvZiAxIGJ5IFNlcnZpY2UgRnVuY3Rpb25zIG9yIGJ5IFNGQyBQcm94eSBub2RlcyBhZnRlciBw ZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZpY2VzIOKApuKAnQ0KDQpQbGVhc2UgcHJvdmlkZSBjb21t ZW50cyBvbiB0aGlzIGNoYW5nZSB0byB0aGUgbWFpbGluZyBsaXN0Lg0KDQpUaGFua3MhDQoNCkpp bSAmIEpvZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K --_000_7D3A8BCAA7B649879F3F5171F5CB4C59ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5EB79AE0FD5B894991C8C200853A21F8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhpcyBpcyBhIHVzZWZ1bCBjbGFy aWZpY2F0aW9uLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdv cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdl YmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K4oCUPC9kaXY+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkNhcmxvcyBQaWduYXRhcm8sJm5ic3A7 PGEgaHJlZj0ibWFpbHRvOmNhcmxvc0BjaXNjby5jb20iIGNsYXNzPSIiPmNhcmxvc0BjaXNjby5j b208L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGkgY2xhc3M9IiI+4oCcU29tZXRp bWVzIEkgdXNlIGJpZyB3b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1h a2UgbXlzZWxmIHNvdW5kIG1vcmUmbmJzcDtwaG90b3N5bnRoZXNpcy4mcXVvdDs8L2k+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IEZlYiA3LCAyMDE3LCBhdCAyOjI0IFBNLCBKYW1lcyBOIEd1aWNoYXJkICZsdDs8YSBocmVmPSJt YWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tIiBjbGFzcz0iIj5qYW1lcy5uLmd1aWNo YXJkQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50 ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KR3JlZXRpbmdzIFdHLDxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCkF0IHRoZSByZWNlbnQgaW50ZXJpbSBtZWV0aW5nIHdlIGRp c2N1c3NlZCB0aGUgY3VycmVudCB0ZXh0IG9uIGRlY3JlbWVudGluZyB0aGUgc2VydmljZSBpbmRl eCBpbiB0aGUgTlNIIHNlcnZpY2UgcGF0aCBoZWFkZXIuIFRoZSBleGlzdGluZyB0ZXh0IGluIHNl Y3Rpb24gMy4zIG9mIGRyYWZ0LWlldGYtc2ZjLW5zaC0xMCByZWFkczo8bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQrigJxTZXJ2aWNlIEluZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQg YnkgU2VydmljZSBGdW5jdGlvbnMgb3IgYnkgU0ZDIFByb3h5IG5vZGVzIGFmdGVyIHBlcmZvcm1p bmcgcmVxdWlyZWQgc2VydmljZXMg4oCm4oCdPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KQSByZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUgc3BlY2lmaWMgYW5kIHVwZGF0ZSB0 aGUgdGV4dCBhcyBmb2xsb3dzOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCuKA nFNlcnZpY2UgaW5kZXggTVVTVCBiZSBkZWNyZW1lbnRlZDxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5ieSBhIHZhbHVlIG9mIDE8L2I+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmJ5IFNlcnZp Y2UgRnVuY3Rpb25zIG9yIGJ5IFNGQyBQcm94eSBub2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVp cmVkIHNlcnZpY2VzIOKApuKAnTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ01vbm90eXBlIENv cnNpdmEnOyBjb2xvcjogcmdiKDAsIDExMiwgMTkyKTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpQbGVhc2UgcHJvdmlkZSBjb21tZW50cyBvbiB0 aGlzIGNoYW5nZSB0byB0aGUgbWFpbGluZyBsaXN0LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4NClRoYW5rcyE8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpKaW0g JmFtcDsgSm9lbDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5zZmMNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcmdi KDE0OSwgNzksIDExNCk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT48YnIg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMiIHN0eWxlPSJjb2xvcjogcmdiKDE0OSwgNzksIDExNCk7IHRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7D3A8BCAA7B649879F3F5171F5CB4C59ciscocom_-- From nobody Tue Feb 7 12:34:46 2017 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 25EAB1294B3 for ; Tue, 7 Feb 2017 12:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYxMK552xj6Z for ; Tue, 7 Feb 2017 12:34:44 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD14C12949A for ; Tue, 7 Feb 2017 12:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14542; q=dns/txt; s=iport; t=1486499149; x=1487708749; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WMEq1BXAcyHpz+mE+r6QANhKbWt1VBQfeGP1KzBvzuw=; b=HH+OAFuBihmDNMBoshdKVK7Q2rdiiw8DUqDIr2yQvy8JF9qgTN7+MbHO 2FAJ58L2XbY3X5N4ol1Nvex5BrJvECQjQroHBRtFwnKAj/WoxNxaEDhlP LcBWTLs6a7DhKEXh6v+HK3EFjNQOiiY17CgtUsd5DbP7DQzQqNzLxI+t5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAQCKLJpY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB4NRigiRb5AphSyCDB8BCoV4AhqCPD8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEagIEAQEhSwsQAgEIPwMCAgIlCxQRAQEEDgWJcw6wOIIli0kBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZMggUIgmKHWi6CMQWVUoYZAZINgXuFF4lxkw4BHzh?= =?us-ascii?q?+TxU8EQGGMHUBh2eBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208,217";a="209523125" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2017 20:25:48 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v17KPmVk029932 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Feb 2017 20:25:48 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Feb 2017 15:25:47 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 7 Feb 2017 15:25:47 -0500 From: "Carlos Pignataro (cpignata)" To: James N Guichard Thread-Topic: [sfc] NSH base header length Thread-Index: AdKBciU5/sPmZdaqR7eR29Y7qdfNlwAOCEGA Date: Tue, 7 Feb 2017 20:25:47 +0000 Message-ID: <459DB47D-9AFA-4257-80C9-1B2FB2307A0C@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.72.44] Content-Type: multipart/alternative; boundary="_000_459DB47D9AFA425780C91B2FB2307A0Cciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH base header length X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:34:45 -0000 --_000_459DB47D9AFA425780C91B2FB2307A0Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmltLCBKb2VsLA0KDQpUaGUgcHJvcG9zZWQgcmV3b3JkaW5nIHdvdWxkIG5vdCBmdWxseSB3b3Jr IHdpdGggYSBwb3RlbnRpYWwgZnV0dXJlIE5VTEwgbmV4dCBwcm90b2NvbCwgaWYgdGhhdCB3ZXJl IHRvIGV2ZXIgZXhpc3QuIEJ1dCByZWdhcmRsZXNzLCB0aGUgb25seSB0aGluZyB3ZSBrbm93IGlz IHRoYXQgaXQgaXMgdGhlIGVuZCBvZiB0aGUgTlNILg0KDQpGb3IgZm9yd2FyZCBjb21wYXRpYmls aXR5LCBJIHJlY29tbWVuZCBzb21ldGhpbmcgbGlrZSDigJx0aGUgZW5kIG9mICp0aGlzKiBOU0gu 4oCdIGFuZCBiZSBkb25lLiBPciBqdXN0IHJlbW92aW5nIHRoZSBzZW50ZW5jZSBhbGwgdG9nZXRo ZXIsIHNpbmNlIHRoZSBkZWZpbml0aW9uIGlzIHByZXNjcmlwdGl2ZSBlbm91Z2guDQoNClRoYW5r cywNCg0K4oCUDQpDYXJsb3MgUGlnbmF0YXJvLCBjYXJsb3NAY2lzY28uY29tPG1haWx0bzpjYXJs b3NAY2lzY28uY29tPg0KDQrigJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBu b3QgZnVsbHkgdW5kZXJzdGFuZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSBwaG90b3N5bnRo ZXNpcy4iDQoNCk9uIEZlYiA3LCAyMDE3LCBhdCAyOjAyIFBNLCBKYW1lcyBOIEd1aWNoYXJkIDxq YW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2Vp LmNvbT4+IHdyb3RlOg0KDQpHcmVldGluZ3MgV0csDQoNCkF0IHRoZSByZWNlbnQgaW50ZXJpbSBt ZWV0aW5nIHdlIGRpc2N1c3NlZCB0aGUgY3VycmVudCB0ZXh0IGFyb3VuZCB0aGUgbGVuZ3RoIGZp ZWxkIGluIHRoZSBOU0ggYmFzZSBoZWFkZXIuIFRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoaXMgdGV4 dCBpbiBzZWN0aW9uIDMuMiBvZiBkcmFmdC1pZXRmLXNmYy1uc2gtMTAgcmVhZHM6DQoNCuKAnFRo ZSBsZW5ndGggZmllbGQgaW5kaWNhdGVzIHRoZSDigJxlbmTigJ0gb2YgTlNIIGFuZCB3aGVyZSB0 aGUgb3JpZ2luYWwgcGFja2V0L2ZyYW1lIGJlZ2lucy7igJ0NCg0KQSBwcm9wb3NlZCByZXdvcmsg b2YgdGhpcyB0ZXh0IGlzIGFzIGZvbGxvd3M6DQoNCuKAnFRoZSBsZW5ndGggZmllbGQgaW5kaWNh dGVzIHRoZSBiZWdpbm5pbmcgb2YgdGhlIHBhY2tldC9mcmFtZSBvZiB0aGUgbmV4dCBwcm90b2Nv bCByZWZsZWN0ZWQgaW4gdGhlIE5TSCBiYXNlIGhlYWRlcuKAnS4NCg0KUGxlYXNlIHByb3ZpZGUg Y29tbWVudHMgdG8gdGhlIG1haWxpbmcgbGlzdCBmb3IgdGhpcyBjaGFuZ2UuDQoNClRoYW5rcyEN Cg0KSmltICYgSm9lbA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --_000_459DB47D9AFA425780C91B2FB2307A0Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <38F3ED49953E164DB74911049C02158B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSmltLCBKb2VsLA0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIHByb3Bvc2VkIHJl d29yZGluZyB3b3VsZCBub3QgZnVsbHkgd29yayB3aXRoIGEgcG90ZW50aWFsIGZ1dHVyZSBOVUxM IG5leHQgcHJvdG9jb2wsIGlmIHRoYXQgd2VyZSB0byBldmVyIGV4aXN0LiBCdXQgcmVnYXJkbGVz cywgdGhlIG9ubHkgdGhpbmcgd2Uga25vdyBpcyB0aGF0IGl0IGlzIHRoZSBlbmQgb2YgdGhlIE5T SC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkZvciBmb3J3YXJkIGNvbXBhdGliaWxpdHksIEkgcmVjb21tZW5kIHNvbWV0aGluZyBsaWtl IOKAnHRoZSBlbmQgb2YgKnRoaXMqIE5TSC7igJ0gYW5kIGJlIGRvbmUuIE9yIGp1c3QgcmVtb3Zp bmcgdGhlIHNlbnRlbmNlIGFsbCB0b2dldGhlciwgc2luY2UgdGhlIGRlZmluaXRpb24gaXMgcHJl c2NyaXB0aXZlIGVub3VnaC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij4NCuKAlDwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpDYXJsb3MgUGln bmF0YXJvLCZuYnNwOzxhIGhyZWY9Im1haWx0bzpjYXJsb3NAY2lzY28uY29tIiBjbGFzcz0iIj5j YXJsb3NAY2lzY28uY29tPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxpIGNsYXNz PSIiPuKAnFNvbWV0aW1lcyBJIHVzZSBiaWcgd29yZHMgdGhhdCBJIGRvIG5vdCBmdWxseSB1bmRl cnN0YW5kLCB0byBtYWtlIG15c2VsZiBzb3VuZCBtb3JlJm5ic3A7cGhvdG9zeW50aGVzaXMuJnF1 b3Q7PC9pPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5PbiBGZWIgNywgMjAxNywgYXQgMjowMiBQTSwgSmFtZXMgTiBHdWljaGFyZCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbSIgY2xhc3M9IiI+ amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkdyZWV0aW5ncyBXRyw8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpBdCB0aGUgcmVjZW50IGludGVyaW0g bWVldGluZyB3ZSBkaXNjdXNzZWQgdGhlIGN1cnJlbnQgdGV4dCBhcm91bmQgdGhlIGxlbmd0aCBm aWVsZCBpbiB0aGUgTlNIIGJhc2UgaGVhZGVyLiBUaGUgbGFzdCBzZW50ZW5jZSBvZiB0aGlzIHRl eHQgaW4gc2VjdGlvbiAzLjIgb2YgZHJhZnQtaWV0Zi1zZmMtbnNoLTEwIHJlYWRzOjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCuKAnFRoZSBsZW5ndGggZmllbGQgaW5kaWNhdGVz IHRoZSDigJxlbmTigJ0gb2YgTlNIIGFuZCB3aGVyZSB0aGUgb3JpZ2luYWwgcGFja2V0L2ZyYW1l IGJlZ2lucy7igJ08bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpBIHByb3Bvc2Vk IHJld29yayBvZiB0aGlzIHRleHQgaXMgYXMgZm9sbG93czo8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQrigJxUaGUgbGVuZ3RoIGZpZWxkIGluZGljYXRlcyB0aGUgYmVnaW5uaW5n IG9mIHRoZSBwYWNrZXQvZnJhbWUgb2YgdGhlIG5leHQgcHJvdG9jb2wgcmVmbGVjdGVkIGluIHRo ZSBOU0ggYmFzZSBoZWFkZXLigJ0uPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K UGxlYXNlIHByb3ZpZGUgY29tbWVudHMgdG8gdGhlIG1haWxpbmcgbGlzdCBmb3IgdGhpcyBjaGFu Z2UuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KVGhhbmtzITxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkppbSAmYW1wOyBKb2VsPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnTW9ub3R5cGUgQ29y c2l2YSc7IGNvbG9yOiByZ2IoMCwgMTEyLCAxOTIpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5zZmMNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHN0eWxlPSJj b2xvcjogcmdiKDE0OSwgNzksIDExNCk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPnNmY0BpZXRmLm9y ZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIHN0eWxlPSJjb2xvcjogcmdiKDE0OSwgNzks IDExNCk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_459DB47D9AFA425780C91B2FB2307A0Cciscocom_-- From nobody Tue Feb 7 12:56:22 2017 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 19F751294DC for ; Tue, 7 Feb 2017 12:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_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=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 hHBa1IGufcNL for ; Tue, 7 Feb 2017 12:56:19 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 6480F1294E9 for ; Tue, 7 Feb 2017 12:56:18 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id v186so28065054wmd.0 for ; Tue, 07 Feb 2017 12:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=L6LYN8VFAQ2zSdjKzjF8ezfgX9boN8HxnnjPm5jvZpc=; b=YCBfUN0RV16lJXJ3qquPfW/F6IuRGnhQtFXNjw9rqK/TR4OTVcCGi9MXn9DqWpB4ih eUUY6L1bgqrh/gGK3FBGhLC8vsltGYnK7Hik+uJjCRxsHMAdhulrIMdOct9RYHDOlbVM S7WOwLHr6YQay9q7W0GOBaXxfk4y0780czMTrLUpLo5zWtcJ6nYXkm5LljVpJCkS94Hb UCD6/JJf1HrOLKx37gfJRytHNpZamEkHLMS7/dqa/U2k6THzeUO5U+Ji/65AwyjQjbNJ ZqtGImi1wnXzK0NYqCgdrAC/naMEyF9KeikUcHKb6Mrcj2sN6GJU8InKbE9vlq8X1f+x JvQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=L6LYN8VFAQ2zSdjKzjF8ezfgX9boN8HxnnjPm5jvZpc=; b=VPf0jM2RnZYTY0Kq49ThFzAN2hWC+NS/fG2HxExwWJAUmI0zUYtgl3lmPAmRTPU/qV omRHBEtARTdrzk007Bpuj53vrTVoWwL39SWaIh++Au7m+zt/F/F5mXlQtBxYJY27ffFB D07Dxo0NZJT3TCoi1lstdXrb5v0333+TlPdYO1gIYAv+oC/GL++lN2VIOKVSD8n2dMFD /oray04tPyU4agGRpVsRj7oaZOf9rJyMx01tMie66pBsGmpbcyhionV2Nu3SAVm9PSxx lnQ3mhtFVEPnuZruAyVhzC/sCN8CfJK9xOFwRtPdDdbdcPaZb4jcCPo/1dO89hiP8Xqb LXuQ== X-Gm-Message-State: AMke39mmrz9smwM1JG+6/COG00q4pf5ydVZ5U5o+fvoJwSjKslcUvUUhZV7EzKePb3UNoPybyuM2AG92vfIBmg== X-Received: by 10.28.196.133 with SMTP id u127mr14086862wmf.34.1486500976942; Tue, 07 Feb 2017 12:56:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.138.146 with HTTP; Tue, 7 Feb 2017 12:56:16 -0800 (PST) In-Reply-To: <043701d28173$36ba5910$a42f0b30$@olddog.co.uk> References: <043701d28173$36ba5910$a42f0b30$@olddog.co.uk> From: Behcet Sarikaya Date: Tue, 7 Feb 2017 14:56:16 -0600 Message-ID: To: Adrian Farrel Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:56:21 -0000 On Tue, Feb 7, 2017 at 12:51 PM, Adrian Farrel wrote: > A bit surprised that we're having this conversation, but anyway how about we > include some text like the following in the NSH draft? > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > Absolutely. BTW I agree with Andy. Regards, Behcet > Adrian > >> Maybe we should add a warning to the draft for the early implementers >> saying that the risk belongs to you and the WG does not take any >> responsibility for the early birds. > From nobody Tue Feb 7 13:28:01 2017 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 78501129499 for ; Tue, 7 Feb 2017 13:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVDd7gBV3nUZ for ; Tue, 7 Feb 2017 13:27:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A48128874 for ; Tue, 7 Feb 2017 13:27:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGA03163; Tue, 07 Feb 2017 21:27:55 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 21:27:53 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 13:27:49 -0800 From: James N Guichard To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] NSH base header length Thread-Index: AdKBciU5/sPmZdaqR7eR29Y7qdfNlwAOCEGAAAh4mRA= Date: Tue, 7 Feb 2017 21:27:48 +0000 Message-ID: References: <459DB47D-9AFA-4257-80C9-1B2FB2307A0C@cisco.com> In-Reply-To: <459DB47D-9AFA-4257-80C9-1B2FB2307A0C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.102] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5E33SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.589A3BDB.0372, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 738c1f6a2d49b11f3a2b7f413a9fbb58 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH base header length X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:28:00 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5E33SJCEML701CHMchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpbY2hhaXIgaGF0IG9mZiDigKZdIC4uIEdpdmVuIHRoYXQgdGhlIHByZXZp b3VzIHRleHQgZGVzY3JpYmVzIHRoYXQgdGhlIHRvdGFsIGxlbmd0aCBpbmNsdWRlcyB0aGUgYmFz ZSBoZWFkZXIsIHRoZSBzZXJ2aWNlIHBhdGggaGVhZGVyLCBhbmQgY29udGV4dCBoZWFkZXJzL1RM VnMsIEkgdGVuZCB0byBhZ3JlZSB0aGF0IHRoZSBsYXN0IHNlbnRlbmNlIGlzIHNvbWV3aGF0IHJl ZHVuZGFudCBhbmQgcmVtb3ZpbmcgaXQgaXMgY2VydGFpbmx5IGFuIG9wdGlvbiB0aGUgV0cgc2hv dWxkIGNvbnNpZGVyLg0KDQpKaW0NCg0KRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp IFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDcs IDIwMTcgMzoyNiBQTQ0KVG86IEphbWVzIE4gR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAaHVh d2VpLmNvbT4NCkNjOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggYmFzZSBo ZWFkZXIgbGVuZ3RoDQoNCkppbSwgSm9lbCwNCg0KVGhlIHByb3Bvc2VkIHJld29yZGluZyB3b3Vs ZCBub3QgZnVsbHkgd29yayB3aXRoIGEgcG90ZW50aWFsIGZ1dHVyZSBOVUxMIG5leHQgcHJvdG9j b2wsIGlmIHRoYXQgd2VyZSB0byBldmVyIGV4aXN0LiBCdXQgcmVnYXJkbGVzcywgdGhlIG9ubHkg dGhpbmcgd2Uga25vdyBpcyB0aGF0IGl0IGlzIHRoZSBlbmQgb2YgdGhlIE5TSC4NCg0KRm9yIGZv cndhcmQgY29tcGF0aWJpbGl0eSwgSSByZWNvbW1lbmQgc29tZXRoaW5nIGxpa2Ug4oCcdGhlIGVu ZCBvZiAqdGhpcyogTlNILuKAnSBhbmQgYmUgZG9uZS4gT3IganVzdCByZW1vdmluZyB0aGUgc2Vu dGVuY2UgYWxsIHRvZ2V0aGVyLCBzaW5jZSB0aGUgZGVmaW5pdGlvbiBpcyBwcmVzY3JpcHRpdmUg ZW5vdWdoLg0KDQpUaGFua3MsDQoNCuKAlA0KQ2FybG9zIFBpZ25hdGFybywgY2FybG9zQGNpc2Nv LmNvbTxtYWlsdG86Y2FybG9zQGNpc2NvLmNvbT4NCg0K4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3 b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5k IG1vcmUgcGhvdG9zeW50aGVzaXMuIg0KDQpPbiBGZWIgNywgMjAxNywgYXQgMjowMiBQTSwgSmFt ZXMgTiBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPG1haWx0bzpqYW1lcy5u Lmd1aWNoYXJkQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KR3JlZXRpbmdzIFdHLA0KDQpBdCB0aGUg cmVjZW50IGludGVyaW0gbWVldGluZyB3ZSBkaXNjdXNzZWQgdGhlIGN1cnJlbnQgdGV4dCBhcm91 bmQgdGhlIGxlbmd0aCBmaWVsZCBpbiB0aGUgTlNIIGJhc2UgaGVhZGVyLiBUaGUgbGFzdCBzZW50 ZW5jZSBvZiB0aGlzIHRleHQgaW4gc2VjdGlvbiAzLjIgb2YgZHJhZnQtaWV0Zi1zZmMtbnNoLTEw IHJlYWRzOg0KDQrigJxUaGUgbGVuZ3RoIGZpZWxkIGluZGljYXRlcyB0aGUg4oCcZW5k4oCdIG9m IE5TSCBhbmQgd2hlcmUgdGhlIG9yaWdpbmFsIHBhY2tldC9mcmFtZSBiZWdpbnMu4oCdDQoNCkEg cHJvcG9zZWQgcmV3b3JrIG9mIHRoaXMgdGV4dCBpcyBhcyBmb2xsb3dzOg0KDQrigJxUaGUgbGVu Z3RoIGZpZWxkIGluZGljYXRlcyB0aGUgYmVnaW5uaW5nIG9mIHRoZSBwYWNrZXQvZnJhbWUgb2Yg dGhlIG5leHQgcHJvdG9jb2wgcmVmbGVjdGVkIGluIHRoZSBOU0ggYmFzZSBoZWFkZXLigJ0uDQoN ClBsZWFzZSBwcm92aWRlIGNvbW1lbnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgZm9yIHRoaXMgY2hh bmdlLg0KDQpUaGFua3MhDQoNCkppbSAmIEpvZWwNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCg0K --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5E33SJCEML701CHMchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTW9ub3R5cGUg Q29yc2l2YSI7DQoJcGFub3NlLTE6MyAxIDEgMSAxIDIgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBD YXJsb3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bY2hhaXIg aGF0IG9mZiDigKZdIC4uIEdpdmVuIHRoYXQgdGhlIHByZXZpb3VzIHRleHQgZGVzY3JpYmVzIHRo YXQgdGhlIHRvdGFsIGxlbmd0aCBpbmNsdWRlcyB0aGUgYmFzZSBoZWFkZXIsIHRoZSBzZXJ2aWNl IHBhdGggaGVhZGVyLCBhbmQgY29udGV4dCBoZWFkZXJzL1RMVnMsDQogSSB0ZW5kIHRvIGFncmVl IHRoYXQgdGhlIGxhc3Qgc2VudGVuY2UgaXMgc29tZXdoYXQgcmVkdW5kYW50IGFuZCByZW1vdmlu ZyBpdCBpcyBjZXJ0YWlubHkgYW4gb3B0aW9uIHRoZSBXRyBzaG91bGQgY29uc2lkZXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KaW08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAwNywgMjAxNyAzOjI2IFBNPGJy Pg0KPGI+VG86PC9iPiBKYW1lcyBOIEd1aWNoYXJkICZsdDtqYW1lcy5uLmd1aWNoYXJkQGh1YXdl aS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzZmNdIE5TSCBiYXNlIGhlYWRlciBsZW5ndGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0sIEpvZWwsIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb3Bvc2VkIHJld29yZGluZyB3b3VsZCBu b3QgZnVsbHkgd29yayB3aXRoIGEgcG90ZW50aWFsIGZ1dHVyZSBOVUxMIG5leHQgcHJvdG9jb2ws IGlmIHRoYXQgd2VyZSB0byBldmVyIGV4aXN0LiBCdXQgcmVnYXJkbGVzcywgdGhlIG9ubHkgdGhp bmcgd2Uga25vdyBpcyB0aGF0IGl0IGlzIHRoZSBlbmQgb2YgdGhlIE5TSC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGZvcndhcmQgY29t cGF0aWJpbGl0eSwgSSByZWNvbW1lbmQgc29tZXRoaW5nIGxpa2Ug4oCcdGhlIGVuZCBvZiAqdGhp cyogTlNILuKAnSBhbmQgYmUgZG9uZS4gT3IganVzdCByZW1vdmluZyB0aGUgc2VudGVuY2UgYWxs IHRvZ2V0aGVyLCBzaW5jZSB0aGUgZGVmaW5pdGlvbiBpcyBwcmVzY3JpcHRpdmUgZW5vdWdoLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPuKAlDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Q2FybG9zIFBpZ25hdGFybywmbmJzcDs8YSBocmVmPSJtYWlsdG86Y2Fy bG9zQGNpc2NvLmNvbSI+Y2FybG9zQGNpc2NvLmNvbTwvYT48YnI+DQo8YnI+DQo8aT7igJxTb21l dGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCwgdG8g bWFrZSBteXNlbGYgc291bmQgbW9yZSZuYnNwO3Bob3Rvc3ludGhlc2lzLiZxdW90OzwvaT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiA3LCAyMDE3LCBhdCAyOjAyIFBNLCBKYW1lcyBOIEd1 aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tIj5q YW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+R3JlZXRpbmdz IFdHLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BdCB0aGUg cmVjZW50IGludGVyaW0gbWVldGluZyB3ZSBkaXNjdXNzZWQgdGhlIGN1cnJlbnQgdGV4dCBhcm91 bmQgdGhlIGxlbmd0aCBmaWVsZCBpbiB0aGUgTlNIIGJhc2UgaGVhZGVyLiBUaGUgbGFzdCBzZW50 ZW5jZSBvZiB0aGlzIHRleHQgaW4gc2VjdGlvbiAzLjIgb2YgZHJhZnQtaWV0Zi1zZmMtbnNoLTEw DQogcmVhZHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKA nFRoZSBsZW5ndGggZmllbGQgaW5kaWNhdGVzIHRoZSDigJxlbmTigJ0gb2YgTlNIIGFuZCB3aGVy ZSB0aGUgb3JpZ2luYWwgcGFja2V0L2ZyYW1lIGJlZ2lucy7igJ08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QSBwcm9wb3NlZCByZXdvcmsgb2YgdGhpcyB0ZXh0 IGlzIGFzIGZvbGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPuKAnFRoZSBsZW5ndGggZmllbGQgaW5kaWNhdGVzIHRoZSBiZWdpbm5pbmcgb2YgdGhlIHBh Y2tldC9mcmFtZSBvZiB0aGUgbmV4dCBwcm90b2NvbCByZWZsZWN0ZWQgaW4gdGhlIE5TSCBiYXNl IGhlYWRlcuKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ UGxlYXNlIHByb3ZpZGUgY29tbWVudHMgdG8gdGhlIG1haWxpbmcgbGlzdCBmb3IgdGhpcyBjaGFu Z2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SmltICZhbXA7IEpv ZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbm90eXBlIENvcnNpdmEmcXVvdDs7Y29sb3I6IzAwNzBD MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJy Pg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Izk1NEY3MiI+c2ZjQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB5E33SJCEML701CHMchina_-- From nobody Tue Feb 7 14:54:03 2017 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 10DD5129561 for ; Tue, 7 Feb 2017 14:54: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 SGKDpQU9d52t for ; Tue, 7 Feb 2017 14:54:00 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 60A7A129500 for ; Tue, 7 Feb 2017 14:54:00 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id f9so98187470otd.1 for ; Tue, 07 Feb 2017 14:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ms6hhgGknbvJ/OGffRHmEbLJ7jCyxKdOSgkjCV/zq7c=; b=CnQayhfFt3o9u8YXRNZDFkbbs3mW/Bpgr51DQGc+4cb01Rf4ILYM0242y3EzGmr7N0 7hIvzA1/zQ29v936CNIrxwlPHuOtjRAMqwk15PUqZoVvgYqirBudeq4diSX7AQJBI4Mt Q8MKjdIO5E5OpLD0D7eVuAKccVZag8lPFjE6zz9p6Vnsyq3jJO7ArT3Qgjqo+DfxP4N2 YqmCiJcmHq2/ORxkFHBN5HpFOBitDiDei4c80BUTWuVTyZEZcTzCuDUqa9nEdp9ErtJD vzbkEogOZ0kr/ReYs3IGj7cHaEWx6X8reohSTDGl5+EziyY+EjsZU6LFjkwwpHom15Xz 9T8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ms6hhgGknbvJ/OGffRHmEbLJ7jCyxKdOSgkjCV/zq7c=; b=Qc/bGBM87+SMdsR3bPqnFCTu4jGSS5yS1tiE9Sx+xxprrq0Skf8uwFYC2bSmTeZ6Ru 2+86mWMWkVl0TQtkv7selA21f20sPraj0H3RsfDA/mkW/1TCnh7oDohCrIdKPwKHC9E+ rRelxQzPD71sqFR0BmE2uJ/IlLDxoYGUKZXUT9KdqhIjaCnjXvLsfynUZBOp1WMBwUlm gPQxBkk5FWE5bHeTzHV0XENfU4TIh08dhvdooJ6RILJYEv09gEsNinLz203WkaroSlxE 5t+0/0x9Vn/wMlKFR+FpMqlmTns5jOOhQNH4LAdKNmGOPG/WXOr0Nm/LGSS+cdxAYR3K 2yPA== X-Gm-Message-State: AIkVDXK9hBrfx93tj9DOdUyA9SD/mdNtPE/MWRQBBe2U/S5AujkUW9dxJ3Il3WPB0jcWhGQB9dEfaPYni6/FuQ== X-Received: by 10.157.0.37 with SMTP id 34mr8680360ota.35.1486508039687; Tue, 07 Feb 2017 14:53:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Tue, 7 Feb 2017 14:53:59 -0800 (PST) In-Reply-To: <459DB47D-9AFA-4257-80C9-1B2FB2307A0C@cisco.com> References: <459DB47D-9AFA-4257-80C9-1B2FB2307A0C@cisco.com> From: Greg Mirsky Date: Tue, 7 Feb 2017 14:53:59 -0800 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=94eb2c032edaa957730547f89f9e Archived-At: Cc: "sfc@ietf.org" , James N Guichard Subject: Re: [sfc] NSH base header length X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 22:54:02 -0000 --94eb2c032edaa957730547f89f9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All, the preceding text explains clearly what must be included in Length field value. I agree that the last sentence of the paragraph, i.e. "The length field indicates ..." is redundant. (It should be s/length/Length/) Regards, Greg On Tue, Feb 7, 2017 at 12:25 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Jim, Joel, > > The proposed rewording would not fully work with a potential future NULL > next protocol, if that were to ever exist. But regardless, the only thing > we know is that it is the end of the NSH. > > For forward compatibility, I recommend something like =E2=80=9Cthe end of= *this* > NSH.=E2=80=9D and be done. Or just removing the sentence all together, si= nce the > definition is prescriptive enough. > > Thanks, > > =E2=80=94 > Carlos Pignataro, carlos@cisco.com > > *=E2=80=9CSometimes I use big words that I do not fully understand, to ma= ke myself > sound more photosynthesis."* > > On Feb 7, 2017, at 2:02 PM, James N Guichard > wrote: > > Greetings WG, > > At the recent interim meeting we discussed the current text around the > length field in the NSH base header. The last sentence of this text in > section 3.2 of draft-ietf-sfc-nsh-10 reads: > > =E2=80=9CThe length field indicates the =E2=80=9Cend=E2=80=9D of NSH and = where the original > packet/frame begins.=E2=80=9D > > A proposed rework of this text is as follows: > > =E2=80=9CThe length field indicates the beginning of the packet/frame of = the next > protocol reflected in the NSH base header=E2=80=9D. > > Please provide comments to the mailing list for this change. > > Thanks! > > Jim & 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 > > --94eb2c032edaa957730547f89f9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
the preceding text explains clearly what mus= t be included in Length field value. I agree that the last sentence of the = paragraph, i.e. "The length field indicates ..." is redundant. (I= t should be s/length/Length/)

Regards,
G= reg

On= Tue, Feb 7, 2017 at 12:25 PM, Carlos Pignataro (cpignata) <cpignata@cisc= o.com> wrote:
Jim, Joel,

The proposed rewording would not fully work with a potential future NU= LL next protocol, if that were to ever exist. But regardless, the only thin= g we know is that it is the end of the NSH.

For forward compatibility, I recommend something like =E2=80=9Cthe end= of *this* NSH.=E2=80=9D and be done. Or just removing the sentence all tog= ether, since the definition is prescriptive enough.

Thanks,

=E2=80=94
Carlos Pignataro,=C2=A0carlos@cisco.com

=E2=80=9CSometimes I use big words that I do not fully understand, to ma= ke myself sound more=C2=A0photosynthesis."

On Feb 7, 2017, at 2:02 PM, James N Guichard <james.n.guichard@huawei.com= > wrote:

Greetings WG,
=C2=A0
At the recent interim meeting we discussed the current text around the leng= th field in the NSH base header. The last sentence of this text in section = 3.2 of draft-ietf-sfc-nsh-10 reads:
=C2=A0
=E2=80=9CThe length field indicates the =E2=80=9Cend=E2=80=9D of NSH and wh= ere the original packet/frame begins.=E2=80=9D
=C2=A0
A proposed rework of this text is as follows:
=C2=A0
=E2=80=9CThe length field indicates the beginning of the packet/frame of th= e next protocol reflected in the NSH base header=E2=80=9D.
=C2=A0
Please provide comments to the mailing list for this change.<= /div>
=C2=A0
Thanks!
=C2=A0
Jim & Joel
=C2=A0
=C2=A0
=C2=A0
=C2=A0
__________________________= _____________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/l= istinfo/sfc


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


--94eb2c032edaa957730547f89f9e-- From nobody Wed Feb 8 02:22:33 2017 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 1ACE91295B4 for ; Wed, 8 Feb 2017 02:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 09zL0bUMNcey for ; Wed, 8 Feb 2017 02:22:30 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BDB2128E18 for ; Wed, 8 Feb 2017 02:22:30 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18AMSJ3030741 for ; Wed, 8 Feb 2017 10:22:28 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18AMQVc030718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Feb 2017 10:22:27 GMT From: "Adrian Farrel" To: References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> In-Reply-To: Date: Wed, 8 Feb 2017 10:22:24 -0000 Message-ID: <060501d281f5$3f8e32a0$beaa97e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEh9UKTEmGth2POBil92ZSCwVfVhgK2Xcy7ArPbFMgCVeS70AFwOn9+onZ7gdA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22872.006 X-TM-AS-Result: No--1.764-10.0-31-10 X-imss-scan-details: No--1.764-10.0-31-10 X-TMASE-MatchedRID: sDm3xtR6Ud+FqCjfEeLPM7dQIb8hCnY+0X0X5dpeBd43Z3efQH+wj438 i28x7thQZK2BJNgnRB1vcmY92rn2+b9ZdlL8eona0C1sQRfQzEHEQdG7H66TyMdRT5TQAJnA7qH 1XxoGP98TElF2YgjAG/D9V09R9g2ioqtDMZEUakCvY4BboIs67rHhMA9aDpuh/WyINg5Mqdqesp y8+E36a0PhZp6NP5kf Archived-At: Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 10:22:32 -0000 Dave D has it right, I think. IIRC two tests are done today anyway. 1. Does the received packet have TTL =3D=3D 0 2. Would decrementing the TTL take it to 0 Obviously h/w vendors can comment, but I believe it is possible to fork = on these results. Adrian From nobody Wed Feb 8 02:27:36 2017 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 63430129590 for ; Wed, 8 Feb 2017 02:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 BmzxJN8OObsN for ; Wed, 8 Feb 2017 02:27:33 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F72129552 for ; Wed, 8 Feb 2017 02:27:32 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18ARU0d003561; Wed, 8 Feb 2017 10:27:30 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18ARPOs003288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2017 10:27:28 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> In-Reply-To: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> Date: Wed, 8 Feb 2017 10:27:25 -0000 Message-ID: <060c01d281f5$f304bbb0$d90e3310$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_060D_01D281F5.F30705A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEh9UKTEmGth2POBil92ZSCwVfVhqK//yvA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22872.006 X-TM-AS-Result: No--23.986-10.0-31-10 X-imss-scan-details: No--23.986-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wt35+5/2RxqmU2fjZiNvIymsVbcspinhtKz0 ZAuVCW0jwulnsMSzBfh1qNKN8EpwsCF/6JJtzFXK8eSmTJSmEv1R3sGN+j7mNMz1fqX318VP0u5 faGP8ztQldGcRGMgoNCi4p8x6JCkkUbB/xcdu03yuJZEHbH9COofGLZ++QpQzbwEqeAk8h3KHb/ mufqR9wBaF+uiyS2LkCFTBt6PkxuZdNTUXNjj5cvOHbIp2eXtYQRPZCRdX9cLSYAzZ6KmqWsit/ eCfvDyivFNr77O5fQHWeGzBXK7oTQtbZsj4NhjssyNb+yeIRArDHSNFHFxB83e9QDr8+LTceoRv SkKpP/gdI+kDNTZELqRXuaJXolrxAbDZOrlndJjYd2+/8wYTdVjyZ+FJjLlS/RM/+SKR6qeeSLW phADC0U0q0J71K/Zg/u8+5fXRUZZ4kJF7CcEyKMLPXKYZysJR/RmmEswf7Ie7+NPPxj+R6gsed7 xgehs0e0dHh3IIJ0OWJcbpNaIEAPs6AFvEdeZfHPCema1j/6vfVqwz+CynaalVRHRK9i1K/hkBS y3LYQ17CjyP3UZ5MbpGAQ2wD/3Qyx6w4CJ+2uVLc5N+0s1+DZT1elWqouGw8cWgFw6wp7OI+yd4 8zjY3SWuqxiUeEX6MLog80/xRYlR4vrwuhcS/AVOLlPuctdqLdLfmiFS7fuSs1st/hpgblzOKVR 59i8DP5mpBtPr/e7et/aEQRVJHkNKRRr2LbXrWCjDJRYeAZ0BL/XzNFFmHxS11FlOYRohXalr5o kxvJqcV82SZ+zUCLI2bT94ZMbKizFhECDuofCeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7GNgbF0oRDZ0XhUo0iFKxEHzzk1H5TBaektHznTVip+xIMHMyRXwbGutLx66XEb6cg== Archived-At: Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 10:27:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_060D_01D281F5.F30705A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey Joel, Thanks for this write-up. For those (like me)-: who need pictures, I think this represents the conversation 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C| TTL | Length | MD Type |R|R|R|R| Proto | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There was a second conversation that turns out to be not quite orthogonal: Do we need the C bit? If that goes away, we could have... 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O| TTL | Length | MD Type |R|R|R|R| Proto | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [I do solemnly swear and pledge not to re-open the discussion about why the length field can't start on a byte boundary ;-0 ] Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 07 February 2017 16:14 > To: sfc@ietf.org > Subject: [sfc] Loop prevention > > (This is my paraphrase of the discussion. I am posting it in my role as > co-chair. This is intended to promote discussion. It is not the > resolution.) > > On the list and at the interim meeting there has been discussion of the > fact that the SI does not serve to prevent or detect loops strictly > among SFF. At the interim, Adrian also observed that a reclassifier can > produce loops and it would be highly desirable to have a way to detect > those. > > The following describes an approach to solving this problem that was > discussed at the interim meeting. We would like WG feedback on this, as > if adopted it needs to go into the NSH document. > Some of the details are under-specified. If the WG likes the approach, > we can fill in those details. > > The goal is to add a TTL field that can be decremented (or, if the WG > prefers, increment) at every SFF and reclassifier. It is not sued for > forwarding, but only to detect loops. > > In order to allow for large deployments, the interim felt that 6 bits of > TTL field was enough. So where to get the bits? > > The proposal is to take the six unused flag bits, and turn them into a > TTL field. > > Then, in order to have some flag bits for future use, we take the upper > bits (4? 3? 5?) of the corrent MD-type field and use those for flag bits > for any new flags. > > We then had a discussion on how this works with existing devices. As > noted in earlier discussions, we are not seeking to make those devices > compliant, but to enable easier transition and limited interoperability. > > THe first observation is that as long as none of the new flag bits are > used, any existing device that examines the MD type field as an octet > will understand the value. Eventually, we expect that we will need to > use those flags. We hope that devices will be upgraded before then. > And if not, well, things happen. > > The harder question is how to handle the TTL with non-upgraded devices. > Obviously, they will not adjust it. Which is unfortunate as it reduces > protection. But it is not fatal. Also, as these are flags already > expected to be ignored on reception (like most IETF reserved fields), we > believe that no existing implementation will break if the TTL is set. > > There is one further compatibility issue. What if the ingress > classifier that creates the NSH header does not know how to set it. > There seem to be two possibilities. One is to say that we could up from > 0. As such, existing implementations will set it correctly. This > works. But it is contrary to conventional practice. The other choice > is to count down, but declare that 1 is expiration, and 0 means > not-counting. This is more limiting. > > Opinions? > Thanks, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc ------=_NextPart_000_060D_01D281F5.F30705A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Joel,

 

Thanks = for this write-up.

 

For = those (like me)-: who need pictures, I think this represents the = conversation

 

     0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     |Ver|O|C|  =   TTL    |   Length  |    MD Type    |R|R|R|R| Proto = |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

There was a second conversation that turns out to = be not quite orthogonal: Do we need the C bit?

 

If = that goes away, we could have...

 

      0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     |Ver|O|     TTL     |   Length  |    MD Type    |R|R|R|R| Proto = |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

[I do solemnly swear and pledge not to re-open the = discussion about why the length field can't start on a byte boundary ;-0 = ]

 

Adrian

 

> = -----Origina= l Message-----

> From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern

> Sent: 07 = February 2017 16:14

> To: = sfc@ietf.org

> Subject: = [sfc] Loop prevention

>

> (This is my paraphrase of the discussion.  I am posting it in my role = as

> co-chair.  This is intended to promote = discussion.  It is not = the

> resolution.)

>

> On the list = and at the interim meeting there has been discussion of the

> fact that the SI does not serve to prevent or = detect loops strictly

> among SFF.  At the interim, Adrian also = observed that a reclassifier can

> produce = loops and it would be highly desirable to have a way to detect

> those.

>

> The following describes an approach to solving = this problem that was

> discussed at the = interim meeting.  We would = like WG feedback on this, as

> if adopted = it needs to go into the NSH document.

> = Some of the details are under-specified.  If the WG likes the = approach,

> we can fill in those = details.

>

> The goal is to add a TTL field that can be = decremented (or, if the WG

> prefers, = increment) at every SFF and reclassifier.  It is not sued for

> forwarding, but only to detect loops.

>

> In order to = allow for large deployments, the interim felt that 6 bits of

> TTL field was enough.  So where to get the bits?

>

> The proposal = is to take the six unused flag bits, and turn them into a

> TTL field.

> =

> Then, in order to have some flag bits = for future use, we take the upper

> bits = (4? 3? 5?) of the corrent MD-type field and use those for flag = bits

> for any new flags.

>

> We then had a = discussion on how this works with existing devices.  As

> noted in earlier discussions, we are not = seeking to make those devices

> compliant, = but to enable easier transition and limited interoperability.

>

> THe first = observation is that as long as none of the new flag bits are

> used, any existing device that examines the MD = type field as an octet

> will understand = the value.  Eventually, we = expect that we will need to

> use those = flags.  We hope that = devices will be upgraded before then.

> = And if not, well, things happen.

>

> The harder question is how to handle the TTL = with non-upgraded devices.

> Obviously, = they will not adjust it.  = Which is unfortunate as it reduces

> protection.  But it is not fatal.  Also, as these are flags = already

> expected to be ignored on = reception (like most IETF reserved fields), we

> believe that no existing implementation will = break if the TTL is set.

>

> There is one further compatibility issue.  What if the ingress

> classifier that creates the NSH header does = not know how to set it.

> There seem to be = two possibilities.  One is = to say that we could up from

> 0.  As such, existing = implementations will set it correctly.  This

> works.  = But it is contrary to conventional practice.  The other choice

> is to count down, but declare that 1 is = expiration, and 0 means

> = not-counting.  This is more = limiting.

>

> Opinions?

> = Thanks,

> Joel

>

> = _______________________________________________

> sfc mailing list

> sfc@ietf.org

> = https://www.ietf.org/mailman/listinfo/sfc

------=_NextPart_000_060D_01D281F5.F30705A0-- From nobody Wed Feb 8 02:37:44 2017 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 B0CF91299EE for ; Wed, 8 Feb 2017 02:37:42 -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] 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 zdfmU9QRTKTj for ; Wed, 8 Feb 2017 02:37:41 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC411299EF for ; Wed, 8 Feb 2017 02:37:40 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18AbcX5026405 for ; Wed, 8 Feb 2017 10:37:38 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18AbWMl026390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Feb 2017 10:37:35 GMT From: "Adrian Farrel" To: References: <459DB47D-9AFA-4257-80C9-1B2FB2307A0C@cisco.com> In-Reply-To: Date: Wed, 8 Feb 2017 10:37:32 -0000 Message-ID: <061701d281f7$5cfdd550$16f97ff0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0618_01D281F7.5D03C8C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK4aa2PKQ9Zw81MzqfKdx3dtg6V4wGZpnH4AiVYjNGfdSCqsA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22872.006 X-TM-AS-Result: No--21.162-10.0-31-10 X-imss-scan-details: No--21.162-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkDtvMVN/9JMygjyj6hG1N2TIaVkFIrQFhtUvqB5o/Lqc6Zx 7QnMuk5OIxs6GXbRLf3oe5qck0DaiTuP8LNrii1sLi5PDX0qWHql9VzHf0qr7qkR7klxT3MWyFO zCzp9kGam0GokG6bBMkb5H/7zTJtBfnxfMuVa9+LFW296Y1uTJ8C5Zx1NKJANVQiUeC6CbuLtAS mtGl/5kTnIGY38z2oQAvAS+4MtyNG75mcLmnLCO+E86+k9uTZHGSqdEmeD/nV0TRq4bcxmH5MUS KwVMFaMH/rIuTKAdIOF7EFMC0qKnX5n/qoxf9eEt1AhvyEKdj4S12tj9Zvd88A5YKm8dwM675T4 BPuNkdpJ0V+lzA7revx0y/M2VFKeX+AaUzfp3hPVBYYEz+/21joSfZud5+GgOcqlsYvgKFUONnC OtDoJBZ6Ss6O2bihGHDnwvr6B+jT1lGRVqRJJbe9VsdrlGzy3/bFfU5WtaotXG3yI9k2vbOTUuE DszCu7ewo8j91GeTG6RgENsA/90MsesOAiftrlS3OTftLNfg2U9XpVqqLhsPHFoBcOsKezdXDbH Fxm2F+dv7RrSohAJCkm8kuls98/aEoHA+Yew8W7vYqkCS0dL7YidXoBo/qVlSFPfwjN9pHsoEFn ZAFTLE+J83GmsfZy66Wuu9SwKD8te86LJsGE3lgowyUWHgGdAS/18zRRZh8UtdRZTmEaIU92x1c 6E6fkF5YdjcsqfMe0XdFsGUlXTTScgMqgJnG/5HDr20Bhc0ZxtWYlDuRQpbXvDHySC+eU1BoO0F XL0shrar1QOTCmjzl5+IQAcYVk8lEDYmoBkrOeAiCmPx4NwGmRqNBHmBveGtkvK5L7RXEXvQkGi 3tjz6XlY8h5Lp1jKjY1NNV5bi9GD4vdK14W976oyVGVU2OEspTkF9aap54= Archived-At: Subject: Re: [sfc] NSH base header length X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 10:37:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0618_01D281F7.5D03C8C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, =20 Can't we describe the length field as a length field not as some form of = pointer to this or that? =20 Thus, just strike that last sentence: it is redundant and polishing it = will not change that. =20 Thus: =20 Length: total length, in 4-byte words, of NSH including the Base Header, the Service Path Header and the context headers or optional variable length metadata. The Length MUST be of value 0x6 for MD Type equal to 0x1 and MUST be of value 0x2 or greater for MD Type equal to 0x2. The NSH header length MUST be an integer number of 4 bytes. =20 Then we can focus on polishing *this* text! =20 How about... =20 Length: The total length, in 4-byte words, of the NSH including the=20 Base Header, the Service Path Header, and any Context Headers or optional variable length metadata that is present. The Length MUST be of value 0x6 for MD Type equal to 0x1, and MUST be of value 0x2 or greater for MD Type equal to 0x2. The length of the NSH header MUST be an integer multiple of 4 bytes, thus variable length metadata is always padded out to a multiple of 4 bytes. =20 Cordially, Adrian =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: 07 February 2017 22:54 To: Carlos Pignataro (cpignata) Cc: sfc@ietf.org; James N Guichard Subject: Re: [sfc] NSH base header length =20 Dear All, the preceding text explains clearly what must be included in Length = field value. I agree that the last sentence of the paragraph, i.e. "The = length field indicates ..." is redundant. (It should be = s/length/Length/) =20 Regards, Greg =20 On Tue, Feb 7, 2017 at 12:25 PM, Carlos Pignataro (cpignata) = wrote: Jim, Joel,=20 =20 The proposed rewording would not fully work with a potential future NULL = next protocol, if that were to ever exist. But regardless, the only = thing we know is that it is the end of the NSH. =20 For forward compatibility, I recommend something like =E2=80=9Cthe end = of *this* NSH.=E2=80=9D and be done. Or just removing the sentence all = together, since the definition is prescriptive enough. =20 Thanks, =20 =E2=80=94 Carlos Pignataro, carlos@cisco.com =E2=80=9CSometimes I use big words that I do not fully understand, to = make myself sound more photosynthesis." =20 On Feb 7, 2017, at 2:02 PM, James N Guichard = wrote: =20 Greetings WG, =20 At the recent interim meeting we discussed the current text around the = length field in the NSH base header. The last sentence of this text in = section 3.2 of draft-ietf-sfc-nsh-10 reads: =20 =E2=80=9CThe length field indicates the =E2=80=9Cend=E2=80=9D of NSH and = where the original packet/frame begins.=E2=80=9D =20 A proposed rework of this text is as follows: =20 =E2=80=9CThe length field indicates the beginning of the packet/frame of = the next protocol reflected in the NSH base header=E2=80=9D. =20 Please provide comments to the mailing list for this change. =20 Thanks! =20 Jim & Joel =20 =20 =20 =20 _______________________________________________ sfc mailing list sfc@ietf.org = https://www.ietf.org/mailman/listinfo/sfc =20 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc =20 ------=_NextPart_000_0618_01D281F7.5D03C8C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All,

 

Can't we describe the length = field as a length field not as some form of pointer to this or = that?

 

Thus, just strike that last = sentence: it is redundant and polishing it will not change = that.

 

Thus:

 

=C2=A0=C2=A0 Length: total length, in = 4-byte words, of NSH including the Base

=C2=A0=C2=A0 Header, the Service Path = Header and the context headers or optional

=C2=A0=C2=A0 variable length = metadata.=C2=A0 The Length MUST = be of value 0x6 for MD

=C2=A0=C2=A0 Type equal to 0x1 and = MUST be of value 0x2 or greater for MD Type

=C2=A0=C2=A0 equal to 0x2.=C2=A0 The NSH header length MUST be = an integer number of 4

=C2=A0=C2=A0 = bytes.

 

Then we can focus on polishing = *this* text!

 

How = about...

 

=C2=A0=C2=A0 Length: The total length, = in 4-byte words, of the NSH including the

=C2=A0=C2=A0=C2=A0Base Header, the = Service Path Header, and any Context Headers or

=C2=A0=C2=A0 optional variable length = metadata that is present.=C2=A0 = The Length MUST

=C2=A0=C2=A0 be of value 0x6 for MD = Type equal to 0x1, and MUST be of value 0x2

=C2=A0=C2=A0 or greater for MD Type = equal to 0x2.=C2=A0 The length = of the NSH header

=C2=A0=C2=A0 MUST be an integer = multiple of 4 bytes, thus variable length = metadata

=C2=A0=C2=A0 is always padded out to a = multiple of 4 bytes.

 

Cordially,

Adrian

 

From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Greg = Mirsky
Sent: 07 February 2017 22:54
To: Carlos = Pignataro (cpignata)
Cc: sfc@ietf.org; James N = Guichard
Subject: Re: [sfc] NSH base header = length

 

Dear = All,

the preceding text explains = clearly what must be included in Length field value. I agree that the = last sentence of the paragraph, i.e. "The length field indicates = ..." is redundant. (It should be = s/length/Length/)

 

Regards,

Greg

 

On Tue, = Feb 7, 2017 at 12:25 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Jim, Joel, =

 

The proposed rewording would not fully work with a = potential future NULL next protocol, if that were to ever exist. But = regardless, the only thing we know is that it is the end of the = NSH.

 

For forward compatibility, I recommend something like = =E2=80=9Cthe end of *this* NSH.=E2=80=9D and be done. Or just removing = the sentence all together, since the definition is prescriptive = enough.

 

Thanks,

 

=E2=80=94

Carlos Pignataro, carlos@cisco.com

=E2=80=9CSometimes I = use big words that I do not fully understand, to make myself sound = more photosynthesis."

 

On Feb 7, 2017, at 2:02 PM, James N Guichard <james.n.guichard@huawei.com> = wrote:

 

Greetings WG,

 

At the recent interim meeting we discussed the = current text around the length field in the NSH base header. The last = sentence of this text in section 3.2 of draft-ietf-sfc-nsh-10 = reads:

 

=E2=80=9CThe length field indicates the = =E2=80=9Cend=E2=80=9D of NSH and where the original packet/frame = begins.=E2=80=9D

 

A proposed rework of this text is as = follows:

 

=E2=80=9CThe length field indicates the beginning of = the packet/frame of the next protocol reflected in the NSH base = header=E2=80=9D.

 

Please provide comments to the mailing list for this = change.

 

Thanks!

 

Jim & Joel

 

 

 

 

<= p class=3DMsoNormal>__________= _____________________________________
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

 

------=_NextPart_000_0618_01D281F7.5D03C8C0-- From nobody Wed Feb 8 02:40:05 2017 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 BC8C81296C1 for ; Wed, 8 Feb 2017 02:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 LyJ5LhgOM0OO for ; Wed, 8 Feb 2017 02:40:01 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C911295D4 for ; Wed, 8 Feb 2017 02:40:00 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18Addrt024435; Wed, 8 Feb 2017 10:39:40 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18AdYnb024284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2017 10:39:37 GMT From: "Adrian Farrel" To: "'James N Guichard'" References: <7D3A8BCA-A7B6-4987-9F3F-5171F5CB4C59@cisco.com> In-Reply-To: <7D3A8BCA-A7B6-4987-9F3F-5171F5CB4C59@cisco.com> Date: Wed, 8 Feb 2017 10:39:34 -0000 Message-ID: <061c01d281f7$a5ad50f0$f107f2d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_061D_01D281F7.A5B01010" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHoYgY6PCVGpHJ8su3f5ejQO2dmKAGMufYpoSbFDbA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22872.006 X-TM-AS-Result: No--34.227-10.0-31-10 X-imss-scan-details: No--34.227-10.0-31-10 X-TMASE-MatchedRID: HLMPCFyIyBN5X0FJZbmEpvs9nOJYqD5IGbJMFqqIm9yo+b+yOP0oGCUA H9djEVi7P6S6MfRN2hR3mw+/xP6FdGlXDj6OOdTjJrUxoq6hvw8/SBHrmIp7lEPjBoD4R1AmcEk cDUL7jxpeLzEzfDI1uSYZP4JD7us6D+ZG9KyphXvhuXUWQoMQt+pSY1z1IiHUDO+DX+rUwfZQqb MfbYKhso3teKhhdzVPliXG6TWiBAD7OgBbxHXmXxzwnpmtY/+r31asM/gsp2mpVUR0SvYtSv4ZA Usty2ENqv6+7o00zYeLFgnz+hpr+XW0oJLOugKBj1RGQOB2Vvn9GaYSzB/sh6Jd7mc2dRi3oEoz raubH2nx6gF+AN4QjuBe5QRmIfivPwbcb/CNUOlwvDydhBUuyCAXLFyLhL5W5GdZsk1yqBcqoeX FMnt4lSJunynLhcivKEdCtwyfJsLWV8MKb34RlRZU/yoIC8o9JVsoL7U3JcDimKcLRvsB1UauzW hZogiAzkH/0tV77RA9ihzfHXEWBFN5kIZnYeEYY4guKfvwCBYzH3zWWApNwxYSQwnOv0yVgVlXn 0pINKXzbeV2VN8Li3ZBE86uj+HtT+Zs2lM+sEAQ9/tMNQ4ait5EdUpA6Nu/DC/Vm90If4WtEJi9 sK8Vj6U0FnO4agCuaP8PQQl9LAFTovWuZWqWkd/wYmMFcJSIX6IRwqkp2m5B06yZQQa9pbAecSq 7h+GuMw7gci9X94KkLSzpHNTR2kXs1WbxNtVLhDK4kXfgEbrVWJXkRYrtO5soi2XrUn/JlR1cT9 YafQVKWdTfwsJjywPb516tYfF10ZX3wXm3Eb9zqRJM60Ta33tpdR0V6ycCWLX5fdhD3H3bWxjX+ xJeXg== Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 10:40:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_061D_01D281F7.A5B01010 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, thank you. =20 Clarity is Queen. =20 Adrian =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro = (cpignata) Sent: 07 February 2017 20:28 To: James N Guichard Cc: sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement =20 This is a useful clarification.=20 =20 Thanks, =20 =E2=80=94 Carlos Pignataro, carlos@cisco.com =E2=80=9CSometimes I use big words that I do not fully understand, to = make myself sound more photosynthesis." =20 On Feb 7, 2017, at 2:24 PM, James N Guichard = wrote: =20 Greetings WG, =20 At the recent interim meeting we discussed the current text on = decrementing the service index in the NSH service path header. The = existing text in section 3.3 of draft-ietf-sfc-nsh-10 reads: =20 =E2=80=9CService Index MUST be decremented by Service Functions or by = SFC Proxy nodes after performing required services =E2=80=A6=E2=80=9D =20 A request was made to be more specific and update the text as follows: =20 =E2=80=9CService index MUST be decremented by a value of 1 by Service = Functions or by SFC Proxy nodes after performing required services = =E2=80=A6=E2=80=9D =20 Please provide comments on this change to the mailing list. =20 Thanks! =20 Jim & Joel =20 _______________________________________________ sfc mailing list sfc@ietf.org = https://www.ietf.org/mailman/listinfo/sfc =20 ------=_NextPart_000_061D_01D281F7.A5B01010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yes, thank = you.

 

Clarity is = Queen.

 

Adrian

 

From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro = (cpignata)
Sent: 07 February 2017 20:28
To: James N = Guichard
Cc: sfc@ietf.org
Subject: Re: [sfc] NSH = Service Index Decrement

 

This is a useful = clarification.

 

Thanks,

 

=E2=80=94

Carlos Pignataro, carlos@cisco.com

=E2=80=9C= Sometimes I use big words that I do not fully understand, to make myself = sound = more photosynthesis."

 

On Feb 7, 2017, at 2:24 PM, James N Guichard <james.n.guichard@huawei.com> wrote:

 

=

At the = recent interim meeting we discussed the current text on decrementing the = service index in the NSH service path header. The existing text in = section 3.3 of draft-ietf-sfc-nsh-10 = reads:

 

=

=E2=80=9CService Index MUST be = decremented by Service Functions or by SFC Proxy nodes after performing = required services =E2=80=A6=E2=80=9D

 

=

A request = was made to be more specific and update the text as = follows:

 

=

=E2=80=9CService index MUST be = decremented by a = value of 1 by = Service Functions or by SFC Proxy nodes after performing required = services =E2=80=A6=E2=80=9D

 

=

Please = provide comments on this change to the mailing = list.

 

=

 

------=_NextPart_000_061D_01D281F7.A5B01010-- From nobody Wed Feb 8 03:22:17 2017 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 4D3F31299F7 for ; Wed, 8 Feb 2017 03:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 Kt_vJv59cj7s for ; Wed, 8 Feb 2017 03:22:14 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 8648D1298BC for ; Wed, 8 Feb 2017 03:22:14 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id j15so80088864oih.2 for ; Wed, 08 Feb 2017 03:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LycrvZneQEPy66e+5MsKDHifugDpbLCCrRAD6/ZuWe0=; b=EYuc72kWFD1Pns3ussRZfmRjWMyZQgjnmNQSCLCDMMInM1r7MdwQz9AsybZ3d1zRcv gPkVF1m/P601mv1CsWXh+x4PSYKIH27tVfumAGymiwuf7BsQTCiFAvo0LOutLKCJ7VzS ngXPiD8HvT6D7Kuc3fB7xwfl4ZKWzwxYVd+HgqFawds7rF0lVFdkwetDm04Qm2teSlyT QWT43EW01fZzPKy90fDTdBfuYDlfOTZL9VEWvG4lH81xQDo8yVFqpzAeATUICNgsNUwW BezSifhEDLSBSmrTlrXdpL/DTOMA4xKNjXkTuos2cUT7GN7jzpGMRXcu9SWvWTyzbDLN rQ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LycrvZneQEPy66e+5MsKDHifugDpbLCCrRAD6/ZuWe0=; b=aZ4yyJFVlCg4j8fIpGeM3Bul/wh0XlHQUqEcFYCX5jehNRB+o3wzpVGKnJMiqLjwBS TzuchvgIg9BNZkdtSkCnEb43nMFJbipOggxtQcJwe7YxACcp71geP/CWfFUsosxbLRhi wf5NIsaDbTTsFrOnmEfdA1V94imHcYeuLDpUzeZbhuaLpu7gp6s8yMK/KJHvK983lkRh dnZZG6uyOUenb/5nKQ4weqJmNXMXLqXIOo7OQPidUxBywiajPKqK3MUDmyzoNdaIiNYJ JtevU+e67t8Qun3PQWFp3qlk43jlFuKZQlSRDluJIQ0LprRrJ1XPyn+Oc8dnmFGVn+lm Te8g== X-Gm-Message-State: AMke39m3CdqwxHkCVwjuE8rRcWu+zIvr6n0EGpa5pEwDJQ/hjRUfiZW5W6/hHGZbd8laE6NUeir4Z1Vag6Jl9g== X-Received: by 10.202.181.11 with SMTP id e11mr10635937oif.57.1486552933858; Wed, 08 Feb 2017 03:22:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Wed, 8 Feb 2017 03:21:53 -0800 (PST) In-Reply-To: References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> From: "Andrew G. Malis" Date: Wed, 8 Feb 2017 12:21:53 +0100 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a113cfef890032f05480313ed Archived-At: Cc: David Mozes , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 11:22:16 -0000 --001a113cfef890032f05480313ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dave D., This solution works for me. It provides backwards compatibility and keeps decrementers happy! :-) Cheers, Andy On Tue, Feb 7, 2017 at 7:08 PM, Dave Dolson wrote: > =E2=80=A6 which would be the following, checking for TTL=3D0 only **after= ** > decrementing (zero being a valid value on the wire): > > > > set TTL =3D TTL - 1 // unsigned 6-bit math; underflow from 0-->0x= 3f > is expected > > if(TTL =3D=3D0) then drop > > > > > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Tuesday, February 07, 2017 12:40 PM > *To:* Dave Dolson > *Cc:* David Mozes; Joel M. Halpern; sfc@ietf.org > > *Subject:* Re: [sfc] Loop prevention > > > > Dave, > > > > I agree that works, but it=E2=80=99s slight more complicated logic and co= uld > potentially allow more packets to loop, those from early implementations > that don=E2=80=99t know how to start TTL from any value other than zero. = Starting > from zero would allow loop checking for packets originating from early > implementations. > > > > Cheers, > > Andy > > > > > > On Tue, Feb 7, 2017 at 6:32 PM, Dave Dolson wrote: > > To be precise, I=E2=80=99d like to propose this behavior by SFFs: > > if(TTL !=3D0) then > > set TTL =3D TTL - 1 > > if(TTL =3D=3D0) then drop > > endif > > > > This should be done when forwarding NSH (vs. receiving) to allow a packet > with TTL=3D=3D1 to be received at the path terminus without dropping it. > > > > As Joel suggested, 0 means =E2=80=9Cnot counting=E2=80=9D. > > > > -Dave > > > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Mozes > *Sent:* Tuesday, February 07, 2017 12:16 PM > *To:* Andrew G. Malis; Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] Loop prevention > > > > Count down TTL and compare to 0 is how most of not all of the > Applications behave today > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Andrew G. Malis > *Sent:* Tuesday, February 07, 2017 6:22 PM > *To:* Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] Loop prevention > > > > Joel, > > > > I=E2=80=99m in favor of loop prevention along the lines that we discussed= in > Westford. With specific regard to: > > > > There is one further compatibility issue. What if the ingress classifier > that creates the NSH header does not know how to set it. There seem to be > two possibilities. One is to say that we could up from 0. As such, > existing implementations will set it correctly. This works. But it is > contrary to conventional practice. The other choice is to count down, bu= t > declare that 1 is expiration, and 0 means not-counting. This is more > limiting. > > I=E2=80=99m in favor of starting from zero and counting up, for maximal b= ackwards > compatibility. Consistency to prior practice for its own sake is a poor > argument unless there=E2=80=99s a good technical reason for it, such as e= ase of > implementation. > > > > Cheers, > > Andy > > > > PS To quote Emerson, consistency is the hobgoblin of little minds. > > > > > --001a113cfef890032f05480313ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dave D.,

This solution works for me. It= provides backwards compatibility and keeps decrementers happy! :-)

Cheers,
Andy


On Tue, Feb 7, 2017 at 7:= 08 PM, Dave Dolson <ddolson@sandvine.com> wrote:

=E2=80=A6 which would be = the following, checking for TTL=3D0 only *after* decrementing (zero = being a valid value on the wire):

=C2=A0

=C2=A0=C2=A0=C2=A0 set TT= L =3D TTL - 1 =C2=A0=C2=A0=C2=A0=C2=A0// unsigned 6-bit math; underflow fro= m 0-->0x3f is expected

=C2=A0=C2=A0=C2=A0 if(TTL= =3D=3D0) then drop

=C2=A0

=C2=A0

=C2=A0

From: Andrew G= . Malis [mailto:agma= lis@gmail.com]
Sent: Tuesday, February 07, 2017 12:40 PM
To: Dave Dolson
Cc: David Mozes; Joel M. Halpern; sfc@ietf.org


Subject: Re: [sfc] Loop prevention

<= div>

=C2=A0

Dave,

=C2=A0

I agree that works, but it=E2=80=99s slight more com= plicated logic and could potentially allow more packets to loop, those from= early implementations that don=E2=80=99t know how to start TTL from any va= lue other than zero. Starting from zero would allow loop checking for packets originating from early implementations.

=C2=A0

Cheers,

Andy

=C2=A0

=C2=A0

On Tue, Feb 7, 2017 at 6:32 PM, Dave Dolson <ddolson@sandvine.com<= /a>> wrote:

To be precise, I=E2=80=99= d like to propose this behavior by SFFs:

if(TTL !=3D0) then=

=C2=A0=C2=A0=C2=A0 set TT= L =3D TTL - 1=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0 =C2=A0if(TTL= =3D=3D0) then drop

endif

=C2=A0

This should be done when = forwarding NSH (vs. receiving) to allow a packet with TTL=3D=3D1 to be rece= ived at the path terminus without dropping it.

=C2=A0

As Joel suggested, 0 mean= s =E2=80=9Cnot counting=E2=80=9D.

=C2=A0

-Dave

=C2=A0

=C2=A0

From: sfc [mai= lto:sfc-bounces@i= etf.org] On Behalf Of David Mozes
Sent: Tuesday, February 07, 2017 12:16 PM
To: Andrew G. Malis; Joel M. Halpern
Cc: sfc@ietf.org
Subject: Re: [sfc] Loop prevention

=C2=A0

Count down TTL and compar= e to 0 =C2=A0is how most of not all of the Applications =C2=A0behave today

=C2=A0

From: sfc [m= ailto:sfc-bounces= @ietf.org] On Behalf Of Andrew G. Malis
Sent: Tuesday, February 07, 2017 6:22 PM
To: Joel M. Halpern <jmh@joelhalpern.com>
Cc: sfc@ietf.org
Subject: Re: [sfc] Loop prevention

=C2=A0

Joel,

=C2=A0

I=E2=80=99m in favor of loop prevention along the li= nes that we discussed in Westford. With specific regard to:

=C2=A0

There is one further = compatibility issue.=C2=A0 What if the ingress classifier that creates the = NSH header does not know how to set it. There seem to be two possibilities.= =C2=A0 One is to say that we could up from 0.=C2=A0 As such, existing implementations will set it co= rrectly.=C2=A0 This works.=C2=A0 But it is contrary to conventional practic= e.=C2=A0 The other choice is to count down, but declare that 1 is expiratio= n, and 0 means not-counting.=C2=A0 This is more limiting.

I=E2=80=99m in favor of starting from zero and count= ing up, for maximal backwards compatibility. Consistency to prior practice = for its own sake is a poor argument unless there=E2=80=99s a good technical reason for it, such as ease of implementation.

=C2=A0

Cheers,

Andy

=C2=A0

PS To quote Emerson, consistency is the hobgoblin of= little minds.

=C2=A0

=C2=A0


--001a113cfef890032f05480313ed-- From nobody Wed Feb 8 06:30:16 2017 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 210AA129B01 for ; Wed, 8 Feb 2017 06:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 7KkJIvrkvtxD for ; Wed, 8 Feb 2017 06:30:11 -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 E2AB6129B22 for ; Wed, 8 Feb 2017 06:30:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CBED924676C; Wed, 8 Feb 2017 06:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486564206; bh=qYtMVnBJmXXcTOU7rOlYx/gOoaYxhvUz49YwzUQkw/I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=booSP0OBcX5T/U1PjYLLiQAVgl+Aq1iVbTgp/dcomLJGrALmv+pbEfy2JUvVZNZC8 vyZ0LA3kJs9XV79pYa3ygvpgTbzaqAQAbTTMHgym8463919HFk7JGkGhCHOXrcSKTr PfGzTF7V2x3FcCFUVX6f/wHP2phTgNyN6bR2vX8A= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MBP.home (pool-98-114-54-105.phlapa.fios.verizon.net [98.114.54.105]) (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 387FD245B8D; Wed, 8 Feb 2017 06:30:06 -0800 (PST) To: adrian@olddog.co.uk, sfc@ietf.org References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> <060c01d281f5$f304bbb0$d90e3310$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: <7b587208-382a-edb9-3631-cb0c0bebcee9@joelhalpern.com> Date: Wed, 8 Feb 2017 09:30:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <060c01d281f5$f304bbb0$d90e3310$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:30:13 -0000 One clarification. The proposal is to take the bits (shown as 4 R bits) from the MD Type field, not from the next Proto field. Next Proto could easily need more than 16 values. MD-Type currently has two values, and while it may need a few more, 8 or 16 would seem more than plenty. Yours, Joel On 2/8/17 5:27 AM, Adrian Farrel wrote: > Hey Joel, > > > > Thanks for this write-up. > > > > For those (like me)-: who need pictures, I think this represents the > conversation > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Ver|O|C| TTL | Length | MD Type |R|R|R|R| Proto | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > There was a second conversation that turns out to be not quite > orthogonal: Do we need the C bit? > > > > If that goes away, we could have... > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Ver|O| TTL | Length | MD Type |R|R|R|R| Proto | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > [I do solemnly swear and pledge not to re-open the discussion about why > the length field can't start on a byte boundary ;-0 ] > > > > Adrian > > > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > >> Sent: 07 February 2017 16:14 > >> To: sfc@ietf.org > >> Subject: [sfc] Loop prevention > >> > >> (This is my paraphrase of the discussion. I am posting it in my role as > >> co-chair. This is intended to promote discussion. It is not the > >> resolution.) > >> > >> On the list and at the interim meeting there has been discussion of the > >> fact that the SI does not serve to prevent or detect loops strictly > >> among SFF. At the interim, Adrian also observed that a reclassifier can > >> produce loops and it would be highly desirable to have a way to detect > >> those. > >> > >> The following describes an approach to solving this problem that was > >> discussed at the interim meeting. We would like WG feedback on this, as > >> if adopted it needs to go into the NSH document. > >> Some of the details are under-specified. If the WG likes the approach, > >> we can fill in those details. > >> > >> The goal is to add a TTL field that can be decremented (or, if the WG > >> prefers, increment) at every SFF and reclassifier. It is not sued for > >> forwarding, but only to detect loops. > >> > >> In order to allow for large deployments, the interim felt that 6 bits of > >> TTL field was enough. So where to get the bits? > >> > >> The proposal is to take the six unused flag bits, and turn them into a > >> TTL field. > >> > >> Then, in order to have some flag bits for future use, we take the upper > >> bits (4? 3? 5?) of the corrent MD-type field and use those for flag bits > >> for any new flags. > >> > >> We then had a discussion on how this works with existing devices. As > >> noted in earlier discussions, we are not seeking to make those devices > >> compliant, but to enable easier transition and limited interoperability. > >> > >> THe first observation is that as long as none of the new flag bits are > >> used, any existing device that examines the MD type field as an octet > >> will understand the value. Eventually, we expect that we will need to > >> use those flags. We hope that devices will be upgraded before then. > >> And if not, well, things happen. > >> > >> The harder question is how to handle the TTL with non-upgraded devices. > >> Obviously, they will not adjust it. Which is unfortunate as it reduces > >> protection. But it is not fatal. Also, as these are flags already > >> expected to be ignored on reception (like most IETF reserved fields), we > >> believe that no existing implementation will break if the TTL is set. > >> > >> There is one further compatibility issue. What if the ingress > >> classifier that creates the NSH header does not know how to set it. > >> There seem to be two possibilities. One is to say that we could up from > >> 0. As such, existing implementations will set it correctly. This > >> works. But it is contrary to conventional practice. The other choice > >> is to count down, but declare that 1 is expiration, and 0 means > >> not-counting. This is more limiting. > >> > >> Opinions? > >> Thanks, > >> Joel > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Feb 8 07:34:14 2017 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 7E380129BBD for ; Wed, 8 Feb 2017 07:34:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQdB46NpgN7W for ; Wed, 8 Feb 2017 07:34:06 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 B23E4129BC8 for ; Wed, 8 Feb 2017 07:34:06 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v18FPNnW019689; Wed, 8 Feb 2017 07:34:04 -0800 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 28g5ra83ap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 08 Feb 2017 07:34:04 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 17:34:01 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Wed, 8 Feb 2017 17:34:01 +0200 From: Tal Mizrahi To: Greg Mirsky , "sfc@ietf.org" Thread-Topic: [EXT] [sfc] Continue discussion of changes to NSH Thread-Index: AQHSgJ7ab2z0q81fM0m6utxhZru6yKFfQAEg Date: Wed, 8 Feb 2017 15:34:01 +0000 Message-ID: <77b4cb88812a4042883cfbdcfd04bc0c@IL-EXCH01.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_77b4cb88812a4042883cfbdcfd04bc0cILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-08_10:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702080151 Archived-At: Subject: Re: [sfc] [EXT] Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:34:08 -0000 --_000_77b4cb88812a4042883cfbdcfd04bc0cILEXCH01marvellcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gaW5jcmVtZW50aW5nIHRoZSB2ZXJzaW9uIG51bWJlci4NCkluZGVlZCwgaXQgaGFzIGJl ZW4gZGlzY3Vzc2VkIG9uIHRoZSBpbnRlcmltLg0KRldJVywgSSBiZWxpZXZlIGl0IGlzIHN0aWxs IHdvcnRoIGZ1cnRoZXIgY29uc2lkZXJhdGlvbi4NCg0KQ2hlZXJzLA0KVGFsLg0KDQpGcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWcgTWlyc2t5 DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA2LCAyMDE3IDc6MzEgUE0NClRvOiBzZmNAaWV0Zi5v cmcNClN1YmplY3Q6IFtFWFRdIFtzZmNdIENvbnRpbnVlIGRpc2N1c3Npb24gb2YgY2hhbmdlcyB0 byBOU0gNCg0KRXh0ZXJuYWwgRW1haWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpEZWFyIEFsbCwNCmR1cmluZyBTRkMgV0cgaW50ZXJpbSBtZWV0aW5nIHN1cHBvcnQgb2YgaW5m aW5pdGUgbG9vcCBwcmV2ZW50aW9uIGJ5IGludHJvZHVjaW5nIFRUTCBmaWVsZCB3YXMgcHJvcG9z ZWQgYW5kIGRpc2N1c3NlZC4gVGhpcyBhbmQgb3RoZXIgcHJvcG9zYWxzIHdpbGwgY2hhbmdlIE5T SCBCYXNlIEhlYWRlciBhZmZlY3RpbmcgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLiBUaGUgZGlz Y3Vzc2lvbiBvZiBiYWNrd2FyZCBjb21wYXRpYmlseSBoYXZlIHN0YXJ0ZWQgYnV0LCBhcyBJIHJl Y2FsLCB3ZSBoYXZlbid0IHJlYWNoZWQgYW55IGNvbmNsdXNpb24uIEknZCBsaWtlIHRvIHByb3Bv c2UgY291cGxlIGNoYW5nZXMgdG8gVmFsdWUgZmllbGQ6DQoNCiAgKiAgIFNlY3Rpb24gMy4yDQpP TEQgVEVYVA0KDQogIFZlcnNpb246IFRoZSB2ZXJzaW9uIGZpZWxkIGlzIHVzZWQgdG8gZW5zdXJl IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkNCg0KICAgZ29pbmcgZm9yd2FyZCB3aXRoIGZ1dHVyZSBO U0ggdXBkYXRlcy4gIEl0IE1VU1QgYmUgc2V0IHRvIDB4MCBieSB0aGUNCg0KICAgc2VuZGVyLCBp biB0aGlzIGZpcnN0IHJldmlzaW9uIG9mIE5TSC4gIEdpdmVuIHRoZSB3aWRlc3ByZWFkDQoNCiAg IGltcGxlbWVudGF0aW9uIG9mIGV4aXN0aW5nIGhhcmR3YXJlIHRoYXQgdXNlcyB0aGUgZmlyc3Qg bmliYmxlIGFmdGVyDQoNCiAgIGFuIE1QTFMgbGFiZWwgc3RhY2sgZm9yIEVDTVAgZGVjaXNpb24g cHJvY2Vzc2luZywgdGhpcyBkb2N1bWVudA0KDQogICByZXNlcnZlcyB2ZXJzaW9uIDAxIGFuZCB0 aGlzIHZhbHVlIE1VU1QgTk9UIGJlIHVzZWQgaW4gZnV0dXJlDQoNCiAgIHZlcnNpb25zIG9mIHRo ZSBwcm90b2NvbC4gIFBsZWFzZSBzZWUgW1JGQzczMjU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzczMjU+XSBmb3IgZnVydGhlcg0KDQogICBkaXNjdXNzaW9uIG9mIE1QTFMtcmVsYXRl ZCBmb3J3YXJkaW5nIHJlcXVpcmVtZW50cy4NCg0KTkVXIFRFWFQNCg0KICBWZXJzaW9uOiBUaGUg dmVyc2lvbiBmaWVsZCBpcyB1c2VkIHRvIGVuc3VyZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQoN CiAgIGdvaW5nIGZvcndhcmQgd2l0aCBmdXR1cmUgTlNIIHVwZGF0ZXMuICBJdCBNVVNUIGJlIHNl dCB0byAweDEwIGJ5IHRoZQ0KDQogICBzZW5kZXIsIGluIHRoaXMgcmV2aXNpb24gb2YgTlNILiAg R2l2ZW4gdGhlIHdpZGVzcHJlYWQNCg0KICAgaW1wbGVtZW50YXRpb24gb2YgZXhpc3RpbmcgaGFy ZHdhcmUgdGhhdCB1c2VzIHRoZSBmaXJzdCBuaWJibGUgYWZ0ZXINCg0KICAgYW4gTVBMUyBsYWJl bCBzdGFjayBmb3IgRUNNUCBkZWNpc2lvbiBwcm9jZXNzaW5nLCB0aGlzIGRvY3VtZW50DQoNCiAg IHJlc2VydmVzIHZlcnNpb24gMHgwMSBhbmQgdGhpcyB2YWx1ZSBNVVNUIE5PVCBiZSB1c2VkIGlu IGZ1dHVyZQ0KDQogICB2ZXJzaW9ucyBvZiB0aGUgcHJvdG9jb2wuICBWYWx1ZSBvZiAweDAwIGlz IHJlc2VydmVkIGZvciBFeHBlcmltZW50YWwNCg0KICAgdXNlIGluIFNlY3Rpb24gMTIuMi4xLiBb UGxlYXNlIHNlZSBbUkZDNzMyNTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzMyNT5d IGZvciBmdXJ0aGVyDQoNCiAgIGRpc2N1c3Npb24gb2YgTVBMUy1yZWxhdGVkIGZvcndhcmRpbmcg cmVxdWlyZW1lbnRzLg0KDQoNCg0KwrcgICAgICAgICBTZWN0aW9uIDEyLjIuMQ0KDQpPTEQgVEVY VA0KDQogICBWZXJzaW9uIDAwOiBUaGlzIHByb3RvY29sIHZlcnNpb24uICBUaGlzIGRvY3VtZW50 Lg0KDQogICBWZXJzaW9uIDAxOiBSZXNlcnZlZC4gIFRoaXMgZG9jdW1lbnQuDQoNCiAgIFZlcnNp b24gMTA6IFVuYXNzaWduZWQuDQoNCiAgIFZlcnNpb24gMTE6IFVuYXNzaWduZWQuDQoNCk5FVyBU RVhUDQoNCiAgIFZlcnNpb24gMHgwMDogRXhwZXJpbWVudGFsLiAgVGhpcyBkb2N1bWVudC4NCg0K ICAgVmVyc2lvbiAweDAxOiBSZXNlcnZlZC4gIFRoaXMgZG9jdW1lbnQuDQoNCiAgIFZlcnNpb24g MHgxMDogVGhpcyBwcm90b2NvbCB2ZXJzaW9uLiBUaGlzIGRvY3VtZW50Lg0KDQogICBWZXJzaW9u IDB4MTE6IFVuYXNzaWduZWQuDQoNCg0KDQpBcHByZWNpYXRlIHlvdXIgY29tbWVudHMsIHN1Z2dl c3Rpb25zLg0KDQoNCg0KUmVnYXJkcywNCg0KR3JlZw0KDQoNCg== --_000_77b4cb88812a4042883cfbdcfd04bc0cILEXCH01marvellcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+ PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9y OnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0t LT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAw IDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTYwNzUxMDI4Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMTA4NTIxMDk2NDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgw LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxOTQ3ODEyMjg5Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMjA5NDUxNzc1Mjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYj NDM7MSBvbiBpbmNyZW1lbnRpbmcgdGhlIHZlcnNpb24gbnVtYmVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JbmRlZWQsIGl0IGhhcyBiZWVuIGRpc2N1c3NlZCBvbiB0aGUgaW50ZXJp bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RldJVywgSSBiZWxpZXZlIGl0IGlzIHN0 aWxsIHdvcnRoIGZ1cnRoZXIgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+R3JlZyBNaXJza3k8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJy dWFyeSAwNiwgMjAxNyA3OjMxIFBNPGJyPg0KPGI+VG86PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW0VYVF0gW3NmY10gQ29udGludWUgZGlzY3Vzc2lvbiBvZiBjaGFuZ2Vz IHRvIE5TSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpyZWQiPkV4dGVybmFsIEVtYWlsPC9zcGFuPiA8bzpwPjwvbzpwPjwv cD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIEFsbCw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kdXJpbmcgU0ZDIFdHIGludGVyaW0gbWVl dGluZyBzdXBwb3J0IG9mIGluZmluaXRlIGxvb3AgcHJldmVudGlvbiBieSBpbnRyb2R1Y2luZyBU VEwgZmllbGQgd2FzIHByb3Bvc2VkIGFuZCBkaXNjdXNzZWQuIFRoaXMgYW5kIG90aGVyIHByb3Bv c2FscyB3aWxsIGNoYW5nZSBOU0ggQmFzZSBIZWFkZXIgYWZmZWN0aW5nIGV4aXN0aW5nIGltcGxl bWVudGF0aW9ucy4gVGhlIGRpc2N1c3Npb24gb2YgYmFja3dhcmQgY29tcGF0aWJpbHkNCiBoYXZl IHN0YXJ0ZWQgYnV0LCBhcyBJIHJlY2FsLCB3ZSBoYXZlbid0IHJlYWNoZWQgYW55IGNvbmNsdXNp b24uIEknZCBsaWtlIHRvIHByb3Bvc2UgY291cGxlIGNoYW5nZXMgdG8gVmFsdWUgZmllbGQ6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClNlY3Rpb24gMy4yPG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PTEQgVEVYVDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyBWZXJzaW9uOiBUaGUgdmVyc2lvbiBmaWVsZCBpcyB1c2VkIHRvIGVuc3VyZSBiYWNrd2FyZCBj b21wYXRpYmlsaXR5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGdvaW5nIGZvcndhcmQgd2l0aCBmdXR1cmUgTlNIIHVw ZGF0ZXMuJm5ic3A7IEl0IE1VU1QgYmUgc2V0IHRvIDB4MCBieSB0aGU8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2Vu ZGVyLCBpbiB0aGlzIGZpcnN0IHJldmlzaW9uIG9mIE5TSC4mbmJzcDsgR2l2ZW4gdGhlIHdpZGVz cHJlYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24gb2YgZXhpc3RpbmcgaGFyZHdhcmUgdGhh dCB1c2VzIHRoZSBmaXJzdCBuaWJibGUgYWZ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYW4gTVBMUyBsYWJlbCBz dGFjayBmb3IgRUNNUCBkZWNpc2lvbiBwcm9jZXNzaW5nLCB0aGlzIGRvY3VtZW50PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IHJlc2VydmVzIHZlcnNpb24gMDEgYW5kIHRoaXMgdmFsdWUgTVVTVCBOT1QgYmUgdXNlZCBp biBmdXR1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgdmVyc2lvbnMgb2YgdGhlIHByb3RvY29sLiZuYnNwOyBQbGVh c2Ugc2VlIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzMyNSIgdGl0 bGU9IiZxdW90O01QTFMgRm9yd2FyZGluZyBDb21wbGlhbmNlIGFuZCBQZXJmb3JtYW5jZSBSZXF1 aXJlbWVudHMmcXVvdDsiPlJGQzczMjU8L2E+XSBmb3IgZnVydGhlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBkaXNj dXNzaW9uIG9mIE1QTFMtcmVsYXRlZCBmb3J3YXJkaW5nIHJlcXVpcmVtZW50cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5ORVcgVEVYVDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyBWZXJzaW9uOiBUaGUgdmVyc2lvbiBmaWVsZCBpcyB1c2VkIHRvIGVuc3VyZSBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGdvaW5nIGZvcndhcmQgd2l0aCBmdXR1cmUgTlNI IHVwZGF0ZXMuJm5ic3A7IEl0IE1VU1QgYmUgc2V0IHRvIDB4MTAgYnkgdGhlPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IHNlbmRlciwgaW4gdGhpcyByZXZpc2lvbiBvZiBOU0guJm5ic3A7IEdpdmVuIHRoZSB3aWRlc3By ZWFkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGF0aW9uIG9mIGV4aXN0aW5nIGhhcmR3YXJlIHRoYXQg dXNlcyB0aGUgZmlyc3QgbmliYmxlIGFmdGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFuIE1QTFMgbGFiZWwgc3Rh Y2sgZm9yIEVDTVAgZGVjaXNpb24gcHJvY2Vzc2luZywgdGhpcyBkb2N1bWVudDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyByZXNlcnZlcyB2ZXJzaW9uIDB4MDEgYW5kIHRoaXMgdmFsdWUgTVVTVCBOT1QgYmUgdXNlZCBp biBmdXR1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgdmVyc2lvbnMgb2YgdGhlIHByb3RvY29sLiZuYnNwOyBWYWx1 ZSBvZiAweDAwIGlzIHJlc2VydmVkIGZvciBFeHBlcmltZW50YWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdXNlIGlu IFNlY3Rpb24gMTIuMi4xLiBbUGxlYXNlIHNlZSBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzczMjUiIHRpdGxlPSImcXVvdDtNUExTIEZvcndhcmRpbmcgQ29tcGxpYW5j ZSBhbmQgUGVyZm9ybWFuY2UgUmVxdWlyZW1lbnRzJnF1b3Q7Ij5SRkM3MzI1PC9hPl0gZm9yIGZ1 cnRoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgZGlzY3Vzc2lvbiBvZiBNUExTLXJlbGF0ZWQgZm9yd2FyZGluZyBy ZXF1aXJlbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGly PSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNlY3Rpb24gMTIuMi4xPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T0xE IFRFWFQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgVmVyc2lvbiAwMDogVGhpcyBwcm90b2NvbCB2ZXJzaW9uLiZuYnNw OyBUaGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBWZXJzaW9uIDAxOiBSZXNlcnZlZC4mbmJzcDsg VGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVmVyc2lvbiAxMDogVW5hc3NpZ25lZC48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgVmVyc2lvbiAxMTogVW5hc3NpZ25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxk aXY+DQo8cHJlPk5FVyBURVhUPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVmVyc2lvbiAweDAwOiBFeHBl cmltZW50YWwuJm5ic3A7IFRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFZlcnNpb24gMHgwMTog UmVzZXJ2ZWQuJm5ic3A7IFRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFZlcnNpb24gMHgxMDog VGhpcyBwcm90b2NvbCB2ZXJzaW9uLiBUaGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBWZXJzaW9u IDB4MTE6IFVuYXNzaWduZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzLCBzdWdnZXN0 aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0K PGRpdj4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_77b4cb88812a4042883cfbdcfd04bc0cILEXCH01marvellcom_-- From nobody Wed Feb 8 07:49:15 2017 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 1C431129BF8 for ; Wed, 8 Feb 2017 07:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKtGaaDvAOZj for ; Wed, 8 Feb 2017 07:49:11 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 C3BAB129BF9 for ; Wed, 8 Feb 2017 07:49:11 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v18Fe8bJ031298; Wed, 8 Feb 2017 07:49:10 -0800 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 28g5ywg4n5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 08 Feb 2017 07:49:09 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 17:49:07 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Wed, 8 Feb 2017 17:49:06 +0200 From: Tal Mizrahi To: "adrian@olddog.co.uk" , "sarikaya@ieee.org" Thread-Topic: [EXT] Re: [sfc] Continue discussion of changes to NSH Thread-Index: AQHSgLkCSggq0DGCJUGDw0fjTMt4OaFcWK4AgAFN+oCAABzFgIABgHdw Date: Wed, 8 Feb 2017 15:49:06 +0000 Message-ID: <9e3c17fede1c472ea2d30e12eaa8fe62@IL-EXCH01.marvell.com> References: <043701d28173$36ba5910$a42f0b30$@olddog.co.uk> In-Reply-To: <043701d28173$36ba5910$a42f0b30$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-08_10:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702080154 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] [EXT] Re: Continue discussion of changes to NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:49:14 -0000 Hi, >From a strictly formal perspective, it is absolutely right that the WG is a= llowed to change the document, as it has not been published as an RFC yet. Having said that, this draft went into WG LC almost a year ago. To some imp= lementers that is an indication that the document is pretty stable. Specifically, the topic of loop prevention, and whether SFFs need to take p= art in it, was actually discussed back in 2015 (https://www.ietf.org/mail-a= rchive/web/sfc/current/msg03814.html), and there was no decision back then = to add a TTL to the NSH.=20 Certainly, it is possible to rethink the topic a year and a half later and = to take a different decision. But at the same time we have to work out a so= lution that is reasonable for pre-standard implementers. It would be very problematic to send out a message: "do not implement this = until there is an RFC number". My two cents... Cheers, Tal. >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel >Sent: Tuesday, February 07, 2017 8:52 PM >To: sarikaya@ieee.org >Cc: sfc@ietf.org >Subject: [EXT] Re: [sfc] Continue discussion of changes to NSH > >External Email > >---------------------------------------------------------------------- >A bit surprised that we're having this conversation, but anyway how about = we >include some text like the following in the NSH draft? > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > >Adrian > >> Maybe we should add a warning to the draft for the early implementers >> saying that the risk belongs to you and the WG does not take any >> responsibility for the early birds. > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Feb 8 08:10:58 2017 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 43B8B129BF4 for ; Wed, 8 Feb 2017 08:10:56 -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] 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 rwlpzdNkAGbU for ; Wed, 8 Feb 2017 08:10:54 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B59129BED for ; Wed, 8 Feb 2017 08:10:53 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18GApbp005465; Wed, 8 Feb 2017 16:10:51 GMT Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18GAkeB005342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2017 16:10:49 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: <51a11c02-3f76-de03-6775-2bdca800e804@joelhalpern.com> <060c01d281f5$f304bbb0$d90e3310$@olddog.co.uk> <7b587208-382a-edb9-3631-cb0c0bebcee9@joelhalpern.com> In-Reply-To: <7b587208-382a-edb9-3631-cb0c0bebcee9@joelhalpern.com> Date: Wed, 8 Feb 2017 16:10:45 -0000 Message-ID: <074f01d28225$ea076640$be1632c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0750_01D28225.EA0E9230" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEh9UKTEmGth2POBil92ZSCwVfVhgJcClL/ASKsBfCipGqzwA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22872.007 X-TM-AS-Result: No--35.022-10.0-31-10 X-imss-scan-details: No--35.022-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFrYfPOPCpnfAvHkpkyUphL9Ud7Bjfo+5jTM9X6l99fFT9Lu X2hj/M7UJXRnERjIKDTkM/LrOP97cw7AfikPXgOwmlaAItiONP0S12tj9Zvd80BaUEeQUq8E80U 9wiBmXuP2wl2DcpALwXWo0o3wSnCwIX/okm3MVcpswYo64ufkVbTEjNWvtSVvQ+MGgPhHUCZ4NB lm/4a7fRReg6Fqy0BjVF62j7LnCqYyuNiVUr7twO0/o+/4D7DzDRi0jfY6gL0JW4Re2U2pyyc44 4AUxvz5KbI2WyKlikl1jYNX3WIaFA9FV6kNYiPHjoyKzEmtrEeP/EshoNKyEfgnJH5vm2+g7aXG VbcCMAgo8MP1pOP867BCniyyRpOaNJ5ZSyMUWeYVglQa/gMvfAkN8Uvsy+nt/ZNsWvQIY4MW2eN mieahN/3gQoLrz94du7lWxrcycwQot+I23PFav527E5uNICcPhEIiqNvBrmOYFp2iw4hoIZXedL akhtIrVGsas+O/nn5EFD0y4YG0VngQ7j04K+UlnVTWWiNp+v9BldmDYjwlpgzzaIyrVuO8q6JSR xKNxGg22uoEm245foFaNaPuEIbSqg73pN+Zqlyd27eF5UDFow/i8FY2vTOBIDp4740OYDGnhZyb KoFsXELduO9IO73n36y5gCD1lYkzG8Dg48sJ/vIVL3+KSNgwkTzAgHG5eNKgJH974mpbq6gTkLg TtTggXql2hIcwl2sTHy/6jlpjHT4gGkEowIKZNs3S39zaoXYU2wesiIXyuxW+93iqRvX7VD4IX3 GhzkucTZGiBUd8fawQUp5/xlTGp/nT+xnI1R2eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7Hzw+XD1ifTXIAcCikR3vq9Pt6eZ87MrrSInBgygdOM/4P7d+1wxgENpzDHny6VYMt27B+Bc 0URa Archived-At: Subject: Re: [sfc] Loop prevention X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 16:10:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0750_01D28225.EA0E9230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Correct. You see, there is value to a figure :-) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C| TTL | Length |R|R|R|R|MD Type| Proto | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adrian > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 08 February 2017 14:30 > To: adrian@olddog.co.uk; sfc@ietf.org > Subject: Re: [sfc] Loop prevention > > One clarification. The proposal is to take the bits (shown as 4 R bits) > from the MD Type field, not from the next Proto field. Next Proto could > easily need more than 16 values. MD-Type currently has two values, and > while it may need a few more, 8 or 16 would seem more than plenty. > > Yours, > Joel > > On 2/8/17 5:27 AM, Adrian Farrel wrote: > > Hey Joel, > > > > > > > > Thanks for this write-up. > > > > > > > > For those (like me)-: who need pictures, I think this represents the > > conversation > > > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |Ver|O|C| TTL | Length | MD Type |R|R|R|R| Proto | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > There was a second conversation that turns out to be not quite > > orthogonal: Do we need the C bit? > > > > > > > > If that goes away, we could have... > > > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |Ver|O| TTL | Length | MD Type |R|R|R|R| Proto | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > [I do solemnly swear and pledge not to re-open the discussion about why > > the length field can't start on a byte boundary ;-0 ] > > > > > > > > Adrian > > > > > > > >> -----Original Message----- > > > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > > >> Sent: 07 February 2017 16:14 > > > >> To: sfc@ietf.org > > > >> Subject: [sfc] Loop prevention > > > >> > > > >> (This is my paraphrase of the discussion. I am posting it in my role as > > > >> co-chair. This is intended to promote discussion. It is not the > > > >> resolution.) > > > >> > > > >> On the list and at the interim meeting there has been discussion of the > > > >> fact that the SI does not serve to prevent or detect loops strictly > > > >> among SFF. At the interim, Adrian also observed that a reclassifier can > > > >> produce loops and it would be highly desirable to have a way to detect > > > >> those. > > > >> > > > >> The following describes an approach to solving this problem that was > > > >> discussed at the interim meeting. We would like WG feedback on this, as > > > >> if adopted it needs to go into the NSH document. > > > >> Some of the details are under-specified. If the WG likes the approach, > > > >> we can fill in those details. > > > >> > > > >> The goal is to add a TTL field that can be decremented (or, if the WG > > > >> prefers, increment) at every SFF and reclassifier. It is not sued for > > > >> forwarding, but only to detect loops. > > > >> > > > >> In order to allow for large deployments, the interim felt that 6 bits of > > > >> TTL field was enough. So where to get the bits? > > > >> > > > >> The proposal is to take the six unused flag bits, and turn them into a > > > >> TTL field. > > > >> > > > >> Then, in order to have some flag bits for future use, we take the upper > > > >> bits (4? 3? 5?) of the corrent MD-type field and use those for flag bits > > > >> for any new flags. > > > >> > > > >> We then had a discussion on how this works with existing devices. As > > > >> noted in earlier discussions, we are not seeking to make those devices > > > >> compliant, but to enable easier transition and limited interoperability. > > > >> > > > >> THe first observation is that as long as none of the new flag bits are > > > >> used, any existing device that examines the MD type field as an octet > > > >> will understand the value. Eventually, we expect that we will need to > > > >> use those flags. We hope that devices will be upgraded before then. > > > >> And if not, well, things happen. > > > >> > > > >> The harder question is how to handle the TTL with non-upgraded devices. > > > >> Obviously, they will not adjust it. Which is unfortunate as it reduces > > > >> protection. But it is not fatal. Also, as these are flags already > > > >> expected to be ignored on reception (like most IETF reserved fields), we > > > >> believe that no existing implementation will break if the TTL is set. > > > >> > > > >> There is one further compatibility issue. What if the ingress > > > >> classifier that creates the NSH header does not know how to set it. > > > >> There seem to be two possibilities. One is to say that we could up from > > > >> 0. As such, existing implementations will set it correctly. This > > > >> works. But it is contrary to conventional practice. The other choice > > > >> is to count down, but declare that 1 is expiration, and 0 means > > > >> not-counting. This is more limiting. > > > >> > > > >> Opinions? > > > >> Thanks, > > > >> Joel > > > >> > > > >> _______________________________________________ > > > >> sfc mailing list > > > >> sfc@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/sfc > > ------=_NextPart_000_0750_01D28225.EA0E9230 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correct.

 

You = see, there is value to a figure :-)

 

  0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

  |Ver|O|C|    TTL    |   Length  |R|R|R|R|MD Type|     Proto     = |

  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

Adrian

 

> = -----Origina= l Message-----

> From: Joel = M. Halpern [mailto:jmh@joelhalpern.com]

> Sent: 08 = February 2017 14:30

> To: = adrian@olddog.co.uk; sfc@ietf.org

> = Subject: = Re: [sfc] Loop prevention

>

> One clarification.  The proposal is to take the = bits (shown as 4 R bits)

> from the MD = Type field, not from the next Proto field.  Next Proto could

> easily need more than 16 values.  MD-Type currently has two = values, and

> while it may need a few = more, 8 or 16 would seem more than plenty.

>

> Yours,

> Joel

>

> On 2/8/17 5:27 AM, Adrian Farrel wrote:

> > Hey Joel,

> = >

> >

> >

> > = Thanks for this write-up.

> >

> >

> = >

> > For those (like me)-: who need = pictures, I think this represents the

> = > conversation

> >

> >

> = >

> >      0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

> >

> >      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /p>

> >

> = >      = |Ver|O|C|    = TTL    = |   Length  |    MD Type    |R|R|R|R| Proto = |

> >

> = >      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /p>

> >

> = >

> >

> > There was a second conversation that = turns out to be not quite

> > = orthogonal: Do we need the C bit?

> = >

> >

> >

> > If = that goes away, we could have...

> = >

> >

> >

> >       0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

> >

> >      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /p>

> >

> = >      = |Ver|O|     = TTL     = |   Length  |    MD Type    |R|R|R|R| Proto = |

> >

> = >      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /p>

> >

> = >

> >

> > [I do solemnly swear and pledge not to = re-open the discussion about why

> > = the length field can't start on a byte boundary ;-0 ]

> >

> = >

> >

> > Adrian

> = >

> >

> >

> >> = -----Original Message-----

> >

> >> From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern

> >

> >> = Sent: 07 February 2017 16:14

> >

> >> To: sfc@ietf.org

> >

> >> = Subject: [sfc] Loop prevention

> = >

> >>

> >

> >> = (This is my paraphrase of the discussion.  I am posting it in my role = as

> >

> = >> co-chair.  This is = intended to promote discussion.  = It is not the

> >

> >> resolution.)

> >

> = >>

> >

> >> On the list and at the interim = meeting there has been discussion of the

> = >

> >> fact that the SI does not = serve to prevent or detect loops strictly

> >

> >> = among SFF.  At the interim, = Adrian also observed that a reclassifier can

> >

> >> = produce loops and it would be highly desirable to have a way to = detect

> >

> >> those.

> >

> = >>

> >

> >> The following describes an approach = to solving this problem that was

> = >

> >> discussed at the interim = meeting.  We would like WG = feedback on this, as

> >

> >> if adopted it needs to go into the = NSH document.

> >

> >> Some of the details are = under-specified.  If the WG = likes the approach,

> >

> >> we can fill in those details.

> >

> = >>

> >

> >> The goal is to add a TTL field that = can be decremented (or, if the WG

> = >

> >> prefers, increment) at = every SFF and reclassifier.  = It is not sued for

> >

> >> forwarding, but only to detect = loops.

> >

> >>

> = >

> >> In order to allow for = large deployments, the interim felt that 6 bits of

> >

> >> = TTL field was enough.  So = where to get the bits?

> >

> >>

> = >

> >> The proposal is to take = the six unused flag bits, and turn them into a

> >

> >> = TTL field.

> >

> >>

> = >

> >> Then, in order to have = some flag bits for future use, we take the upper

> >

> >> = bits (4? 3? 5?) of the corrent MD-type field and use those for flag = bits

> >

> >> for any new flags.

> >

> = >>

> >

> >> We then had a discussion on how this = works with existing devices.  = As

> >

> >> noted in earlier discussions, we are = not seeking to make those devices

> = >

> >> compliant, but to enable = easier transition and limited interoperability.

> >

> = >>

> >

> >> THe first observation is that as long = as none of the new flag bits are

> = >

> >> used, any existing device = that examines the MD type field as an octet

> >

> >> = will understand the value.  = Eventually, we expect that we will need to

> >

> >> = use those flags.  We hope = that devices will be upgraded before then.

> >

> >> = And if not, well, things happen.

> = >

> >>

> >

> >> = The harder question is how to handle the TTL with non-upgraded = devices.

> >

> >> Obviously, they will not adjust = it.  Which is unfortunate = as it reduces

> >

> >> protection.  But it is not fatal.  Also, as these are flags = already

> >

> >> expected to be ignored on reception = (like most IETF reserved fields), we

> = >

> >> believe that no existing = implementation will break if the TTL is set.

> >

> = >>

> >

> >> There is one further compatibility = issue.  What if the = ingress

> >

> >> classifier that creates the NSH = header does not know how to set it.

> = >

> >> There seem to be two = possibilities.  One is to = say that we could up from

> >

> >> 0.  As such, existing = implementations will set it correctly.  This

> >

> >> = works.  But it is contrary = to conventional practice.  = The other choice

> >

> >> is to count down, but declare that 1 = is expiration, and 0 means

> >

> >> not-counting.  This is more limiting.

> >

> = >>

> >

> >> Opinions?

> >

> >> = Thanks,

> >

> >> Joel

> = >

> >>

> >

> >> = _______________________________________________

> >

> >> = sfc mailing list

> >

> >> sfc@ietf.org

> >

> >> = https://www.ietf.org/mailman/listinfo/sfc

> >

------=_NextPart_000_0750_01D28225.EA0E9230-- From nobody Wed Feb 8 08:53:21 2017 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 DFC77129C52 for ; Wed, 8 Feb 2017 08:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=junipernetworks.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 FljWmIu9g8Cv for ; Wed, 8 Feb 2017 08:53:18 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0092.outbound.protection.outlook.com [104.47.42.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D36129C51 for ; Wed, 8 Feb 2017 08:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pf9l3cHVAdaHjbJ8fdFhtu10lKtstos4J62RdfBZ9/w=; b=RLvksQJgX2hmY+YxorOPRHJ6jshVyrWwOjp0Cs1UJ0Jhy7gjRZpNTwRTg0C2ox0JghjPmXFIYCUySAXcBoWoByil2951SuHeBlecEHyiB7ohOfeoELBtrQHcISPk8BwhM2DUAyNZ/rQp4ShqevlLaCgH8MrsfaLA14XxV/uTB/8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.33.88] (66.129.241.12) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Wed, 8 Feb 2017 16:53:17 +0000 To: James N Guichard , "sfc@ietf.org" References: From: Eric C Rosen Message-ID: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> Date: Wed, 8 Feb 2017 11:53:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F711FC80208D5212E3B20A0C" X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR01CA0060.prod.exchangelabs.com (10.172.194.150) To BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) X-MS-Office365-Filtering-Correlation-Id: 9c6a2133-6865-475e-439e-08d45042fb00 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:S0uIhlgNhyIhqQ98AmfJvFnjSTsUDTbKjIJs2/xmCdKIyxfuB3d7DuHCFRL7o9bJXAsASX+cKQThYX2Bm/4zD7Ki1XogEh1S+1V8E+RfgM01y9GP7U0t7c5FnEaQJ5jTWM/54/Ngbax2+6tDU54IYtefxrNTEZqUckfT8um5DdKd0ocGYcXDvRhEBv5MimnCISkoMXfe0ibuThIToV38OdrNlQs3S2yo5WNwnfUTBWtMMsCJbs8pX7vMp13+1A5sIiyQNk8CYPUlT98QZjcv8PIp3MTX4D7xkuDuBKD7Lug=; 25:r6RYLSoomenptYQUKkWUlHv4oLjGny7CL9+6xQBf1BDbTzDMS850Z8Xhu0MD25bceVdfnA1tOD8CofzpEqlzE2Z2ObzWKr78H5/iKVWeBrg4v9htQCXI21wNZr0yeVXLd9i1TViHL/4880XByhF4XG82w8fGxvlLKtPzq/0+asoBtgMFelBePXANRVT9tPDQZ7Yks+wLCZR7mtOh/m6jjp3Hk4pB7YNaGV86UquEUtY/JfevtPRrm1n3ugKP7TVJvuOmR2V40MvWp2DvxaJwZjfQdacgC/6Q1JzdT2xfyEVi8etjzeV30ZYMsLdgbcaCx6u6TALUUquml1qCLgcK/kTNvS+QexbqpArvEEeZW9GeUnbtd/MSMY45Y73P7MZG9YTyPAXI/dU8403T26rSF4V6vSHcWHTS3RaGj3UfPZTmDN8uXKadLmf+kzOlgjHOJABqabC/UUrXAf8N/nMuDw== X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:N1Ssp252osUV+J3Ez1hmRDOUp4zhHvS1sjjUTGL/0xgpWtVNlaZekc/vnJ3vBeKesxh0POFNMGyB+hIw0wGpb9NxX9jhTDR0orGJl/Z5m8c1wJDRd0k+vORpE3mfpcRqlX7ZQvWl4DbFp3HSkbsdeYb26iOmDEdoByWFjQyd7ARna8nUqhSMoBkTLGy0Ba+xpnqZXVW85qChpQuxAIBp5lActekEJQxXcoxeY84AdVUQhivXj1SY5D6hAq/o1Hv9; 20:KqH+iLHwJx8cDWgb+cAySr5bvT+i5x8KdSivEuPK/Xy5ULgQW0v0I0Pmb+y5+jsuegUHvjtbPserNiFQprmyxaMWlsossyrfIZXXendO91rHL5R/4f9nvhcwKVQfC2DltQ6MBpsPLyAZ4zL8W22lV9qlg2ENWioAwKWnzN9WeDMZhhyHdL2g02aE0SeCqdOIKFZEHXroWGAYZy4bzflRwNKYgEE675spWwwZaq/3+b7IVGiKbNA2HHBT8rIOfKqInbBdZGK2NrV+TfudLULFsEXVdmU6gSlu+bj8htPuCXARfep70c/0JlemQREwWmehnDfg9xvP3ytdXthMXZH6wqZQ1k8NeQMw9yB1PEh+EwT0D2PbeUBSurn8E0q0pP6QLW+f0cp5Ve8HK3dtQcU/Hak1KUbMbNauAkxoWZFU0UlUsMe6xKYZW9nGfPqrxjMbHR8hW9sk5MdTYVBtySmsUsiA3WfsHkZ9XPpXMMBixRLthXERPukv/WdtO2Stzr6sc5/2n1x4jrgwPWOrLK/TowrDN5i7NH++ZqPx30smcqk3si/MTwKS/DQ7j18Y1/a+p5pBUpi1Y6ZRVxGOrDnYylHA/VCROFRbDxu7uGKL1M0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(50582790962513); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(2017020702029)(5005006)(20170203043)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(6072148); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:SbIFH3FfVrNgwdwINlJ72w1pb4KUKSvt5JAQVs5Vdzl7OX3m7TV2zwQr5wTTpABHm2B+rZkUNhFhkYUsg45GTDCc86H0gmHoX/lnNcCLgb7lBd1SLs9vhvE2fA1JpR8/HrEeyBR/c8sdYN/7QnL/ajbAAqjmyyrMsdo8wfHKEmPy+FBbmNNzkmvGRRgEbjqykzwNMKTWBtJ1z0qd1N27Bbq4kxNpXsuN5nkUwbpjY3AWc6d5niMAQoytDsRJ90f+jALqCikNC11q5w/rXbjCP8jA8PicHsl6S4MRZX2CgaOY0+hn3Oc7vy9lIe6QIa5vLvDz6nGSEuiNgspuY5Ma3XG5xYW9XhzDhB30v4yw/n3VUYaUOceXfjp+1IpJwqfAMCNV/86GafBQ5HxvbpAoKStlumORoliRyEcqFdwuBRt/0fdUc3Rmn3H7R1ue5FGb3Bd2lFaU1xj6gr3afEE8zvnmpjvU06rRGjgOi5yHQwgOYGi14Rrm0gnWjcjjKMwzgI+ZOBnOWB4e8P7GGWAljoYdASZyflkSaDlsXZgApl+6p5+dJuhI3gAPW1GtigK3YKCCCG20DTugXWF9HDmS0gHAZ8PnAlJJYR9oQKGwFC37rRm7oq1Un5Gj6EFW1tPBKcEdEQl7xfie9vhUCMOEU+nc6J/qUEdsc1pHtR+L9E54+NxAxKLQXn/FBDFny0esJVvLCWpcjPtFkLKOUdbp7xP6r4HvfjFgfZgShc3K5W0= X-Forefront-PRVS: 0212BDE3BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(24454002)(199003)(377454003)(189002)(189998001)(86362001)(83506001)(4001350100001)(64126003)(97736004)(3846002)(229853002)(65806001)(2906002)(65956001)(66066001)(6116002)(25786008)(6486002)(2501003)(90366009)(77096006)(512944002)(68736007)(2950100002)(53546003)(6246003)(53936002)(38730400002)(81156014)(81166006)(42186005)(33646002)(31686004)(106356001)(7736002)(65826007)(101416001)(92566002)(5660300001)(84326002)(31696002)(105586002)(36756003)(76176999)(8676002)(54356999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.33.88]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB2180; 23:fN/VH5xFnguGqG1MNTWhnniDX7f4pzPGS8yMJW+rE?= =?us-ascii?Q?vGyRLOffdtICkAS4pQmLxyqk6P39PCQrAkcnVr2m8aYr5sbRr5VMcLJrbghF?= =?us-ascii?Q?4qnzx6KzHSvkllbPlFhqSee8r13/+MF9fgRwlIJ+HLOgq4SvqKECqZLhNnOI?= =?us-ascii?Q?3b8VKcayPF5Q9JVjWObMkT96oFty/WZmMez6Mzml2/BI6bQ5KXsq+d2Sq3Dx?= =?us-ascii?Q?ZJKPNUORWuitcS//JPRV0Uj+1p2nKtec4G0MlJc28JiH4e7R2HYAgpix+EmQ?= =?us-ascii?Q?Q0owNm8cL3d4zEbVSlvXj9B225i5ZGIKia3AvttmWX4otJgIOecYW3XdS1YF?= =?us-ascii?Q?fSufU8HhjlPcGR3+zP4orwa5a6NMa5PLjD5wmRncErY6OYtkB5ZYb3AB+iyZ?= =?us-ascii?Q?lgajZ1Vwdg3o5sJ28wNGbET5p5izOwj1BZZ6GeMK0kjRvqcQe+2gJ7gycT7h?= =?us-ascii?Q?G+p05Wj8TTePZYC3xsrVBPGi8zoYKkk31L6VhcqXMOenrONMZi+fCeZDh5Hg?= =?us-ascii?Q?s+tBMx6aJDaeMN6noW53hOUOKLYYi7gkyjPiL5XRE5wVmR4OW8AJ4tzPPO1i?= =?us-ascii?Q?VAHyq03arqznSPP7eCHIo407HwL8OCgHxS4wedhhjsD3R1y7kS7e/UZbVV+U?= =?us-ascii?Q?W0EUnEG6ynrrfnyTEn2EC3iiHP+u5fEVZUevDLdExs/oFEn1dxXCdhJPghUl?= =?us-ascii?Q?MMYgGydeBD+nbdDTDnV3BAg0jRWbL72p+LDIlIMRWuasZNURzfySc7QNbGOd?= =?us-ascii?Q?F6kt92CqYkzswxxNDzqBxodvcsM8E78++SAxciYtcQ7uLS0Npi9WDLPFwNzX?= =?us-ascii?Q?+QXmyKsvv6ibwyiYD/2SNdX4jdWRC9dV7et2K7Oz1aHv9QWzXuIC3tFSzHDv?= =?us-ascii?Q?v2zYLo0qXHO5YkTYzjIMWmjqdXMTiUQRQ6RPY2eJ1J6zSdpdbg8ERQa2/D17?= =?us-ascii?Q?r+196/r2AmnB3ZLvqP+wwvVzbVodQD1N+eDW9zQst3XJcoMUgcMO6Y6loLkE?= =?us-ascii?Q?0jUrTXGLvGRGEaQk+2nHjKfWB+t3nbeowXP8UE4y3AKvQvLCh8kYdHbs9BCz?= =?us-ascii?Q?C/AINsj4nTfKncicVEmesmCbaEeZDqdgko5rET4lv/BDO5/Soy98E5hBdyZm?= =?us-ascii?Q?Ma1wJpWqlg/xdRNv1cHUHTYFYWC31OEjGkvzPpjAnPQY3U8OVSgYumwXMtOS?= =?us-ascii?Q?To7TaKHKVxBQ8bX0sm4uMXPoEY0ITibUApNiedGm1PYjsr2SauU1QtO4hnG9?= =?us-ascii?Q?ufrVdfeWK6+mD0EJ5sgQQK2HVOkOvlZHQxySJF4pbtX0AirQ/aY68SwDlPbj?= =?us-ascii?Q?+AXaJ7Kidr+aYRCbkezjrXkCd7Efq8BxLCQU04zD1ymf4EnsishZIiJuAq1m?= =?us-ascii?Q?atPiXrpmnpeuQ+AGM0/ZLTC3do=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:mUBjMfdCzYN6X5n4eH0sTPqpl93koFWjpI04zqOHjf5/wCuJrLnFyMCevtjEVD+og42WKBvevNz4LG29DTNHk3rJ0W2lkW7L+BOd6wFJiTIDQtmFfXCVNybHN8xzhm3aqBi9QLLM6c+GZrlUcJHInnz5WoLMTTERFvGAM5Lcbq8urV9dLMKEqbd2YAW3tOHowJ8RULEQTvynY0Y9eEcL9cLp5xuzD9p1iPn8ECaQ2sT/sfdXYtFrcmE6D+MeQdMojN5TQJvMPeZzDzySlNFqKKtgII5bS45CiNqyi4/mgD8SXwPPh+wZjV7jW9Ffs5c5Ios4xWvz6i8H9MbPwOyuVXbvXCDFgLZn4zj3YjuWQ486scsobCZp5XqZzifWHo0ihsXNa5WtZNEA5LJcbe8ZTQtHieG3FtdgP4R9qDt2tcA=; 5:9NPFwUFYd/r44RQQw3jhyWptzlTsldpi5FcZ6S7pJHBnsgAUh9t4n8mgHw1e4nr+0l2B51kwh+7hBt2QT3bQOCxZSvZd1pgSNYBA2d7S508bySSGxsZdR/d9kZoItLO9JELt56/Xum12rA1/9svV6g==; 24:rC22ru7dfssVXzjRW9mxujsYlLbMA/ONskLvi6WWy6xzOzwNkhZ5hDLtKt/n2dSWjapoK2ER92zfJ///jeKbWzpC2cY/VpEiKxJbynPVi70= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:0+njbYRZB9REMkCCHLZ8Fzu4kfzvcBhKb0dHnid8f6Gp3sSgCdwSUiq8rhZ8nKJETgWx7D+WiQlF07WkdjPzpycSewJo0ftuGRrkmGYmTaJuusL2Q6BN7f7ft0pRChX/p6irVxjMnHo9IzIodV3/7CaOVMbyrQQX8z3+OJjkeOCaeLqhc6xW3Ub5OaplouOLruwJ6B14IBcLhqoIgPwPezIDXkDnggIpUxE38TZTgoIDZNCwpo3jZbpfz1sWTYWFJuKatQNs98GKPnHn6lqAEkVPe/xCxdAhC2iyBosrlO47U+QUpclFi2U4uYVKdZDXee8vGj/uczgqWWl6Az8VXG4Ox6lsZg/G0gHOjWAfLpchJDJLd5S8qK3hhlPV+jCT+uTUPXfXvX0vrci2nS462u3521BSwdaydWEVXz+twwpslZAgl5cDZlA/S9Ys9GpNOrNCz6WGhGaAdN2jO5Kx/ZjQiLyJcJAgZfJEbbRLu/nCNaP+Cc8bAMO2T0jSvy8khwZFEsSdAjzfm/JshFTfcg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2017 16:53:17.0991 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180 Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 16:53:20 -0000 --------------F711FC80208D5212E3B20A0C Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit On 2/7/2017 2:24 PM, James N Guichard wrote: > > A request was made to be more specific and update the text as follows: > > “Service index MUST be decremented *by a value of 1* by Service > Functions or by SFC Proxy nodes after performing required services …” > A couple of observations: - The term "SFC Proxy node" is not defined in either the NSH draft or in RFC 7665. I think the intention here is to say "SFC Proxy". - Is the intention that the SI remain unchanged while the SF is operating on the packet, or is the intention only that the SI be decremented before the packet is delivered by the SF or SFC Proxy to an SFF? I'd suggest either: "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the SI by 1 before delivering the packet to the next SFF" or "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the SI by 1 before delivering the packet to the next SFF, but not until the SF has finished all its other processing of the packet" depending upon which is intended. I think an implication of these procedures is that an SI value of 1 is not valid. If an SF gets an NSH packet with an SI of 1, the SF will decrement the SI (setting it to 0), send the packet to an SFF, and the SFF will discard it, because 0 is an invalid SI value. Is that the intention? The draft makes it clear (well, sort of) that an SFF should discard a packet with an SI of 0, but does not seem to say that an SF or SFC Proxy should discard a packet it receives with an SI of 0. It would probably be a good idea to say that. Some text in the draft (e.g., section 7.1) states than an SFF should discard a packet with an SI of zero, but other text in the draft (e.g., section 3.3) only says that an SFF should log an error if it sees an SI of zero. It's probably best to change the text in 3.3. to say "SHOULD generate an error/log message and MUST discard the packet", or something similar. --------------F711FC80208D5212E3B20A0C Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit On 2/7/2017 2:24 PM, James N Guichard wrote:

A request was made to be more specific and update the text as follows:

 

“Service index MUST be decremented by a value of 1 by Service Functions or by SFC Proxy nodes after performing required services …”


A couple of observations:

- The term "SFC Proxy node" is not defined in either the NSH draft or in RFC 7665.  I think the intention here is to say "SFC Proxy".

- Is the intention that the SI remain unchanged while the SF is operating on the packet, or is the intention only that the SI be decremented before the packet is delivered by the SF or SFC Proxy to an SFF?

I'd suggest either:

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the SI by 1 before delivering the packet to the next SFF"

or

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the SI by 1 before delivering the packet to the next SFF, but not until the SF has finished all its other processing of the packet"

depending upon which is intended.

I think an implication of these procedures is that an SI value of 1 is not valid.  If an SF gets an NSH packet with an SI of 1, the SF will decrement the SI (setting it to 0), send the packet to an SFF, and the SFF will discard it, because 0 is an invalid SI value.  Is that the intention?

The draft makes it clear (well, sort of) that an SFF should discard a packet with an SI of 0, but does not seem to say that an SF or SFC Proxy should discard a packet it receives with an SI of 0.  It would probably be a good idea to say that.

Some text in the draft (e.g., section 7.1) states than an SFF should discard a packet with an SI of zero, but other text in the draft (e.g., section 3.3) only says that an SFF should log an error if it sees an SI of zero.  It's probably best to change the text in 3.3. to say "SHOULD generate an error/log message and MUST discard the packet", or something similar.


--------------F711FC80208D5212E3B20A0C-- From nobody Wed Feb 8 10:04:53 2017 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 8215E12945A for ; Wed, 8 Feb 2017 10:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01] 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 hGVWYkkZ8bnl for ; Wed, 8 Feb 2017 10:04:51 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95FF129580 for ; Wed, 8 Feb 2017 10:04:50 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 13:04:49 -0500 From: Dave Dolson To: Eric C Rosen , James N Guichard , "sfc@ietf.org" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA3q0iAAAgj/lA= Date: Wed, 8 Feb 2017 18:04:47 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> In-Reply-To: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98705018EFwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 18:04:52 -0000 --_000_E8355113905631478EFF04F5AA706E98705018EFwtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, I was never quite happy with the outcome that neither 0 nor 1 is a valid SI= . (Because if received with value of 1, it is decremented and discarded.) It seems to waste an index value. I guess I'm interested to know if that is important to other implementers, = or if that was even the intention? -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Wednesday, February 08, 2017 11:53 AM To: James N Guichard; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement On 2/7/2017 2:24 PM, James N Guichard wrote: A request was made to be more specific and update the text as follows: "Service index MUST be decremented by a value of 1 by Service Functions or = by SFC Proxy nodes after performing required services ..." A couple of observations: - The term "SFC Proxy node" is not defined in either the NSH draft or in RF= C 7665. I think the intention here is to say "SFC Proxy". - Is the intention that the SI remain unchanged while the SF is operating o= n the packet, or is the intention only that the SI be decremented before th= e packet is delivered by the SF or SFC Proxy to an SFF? I'd suggest either: "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the= SI by 1 before delivering the packet to the next SFF" or "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the= SI by 1 before delivering the packet to the next SFF, but not until the SF= has finished all its other processing of the packet" depending upon which is intended. I think an implication of these procedures is that an SI value of 1 is not = valid. If an SF gets an NSH packet with an SI of 1, the SF will decrement = the SI (setting it to 0), send the packet to an SFF, and the SFF will disca= rd it, because 0 is an invalid SI value. Is that the intention? The draft makes it clear (well, sort of) that an SFF should discard a packe= t with an SI of 0, but does not seem to say that an SF or SFC Proxy should = discard a packet it receives with an SI of 0. It would probably be a good = idea to say that. Some text in the draft (e.g., section 7.1) states than an SFF should discar= d a packet with an SI of zero, but other text in the draft (e.g., section 3= .3) only says that an SFF should log an error if it sees an SI of zero. It= 's probably best to change the text in 3.3. to say "SHOULD generate an erro= r/log message and MUST discard the packet", or something similar. --_000_E8355113905631478EFF04F5AA706E98705018EFwtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

I was never quite happy w= ith the outcome that neither 0 nor 1 is a valid SI.

(Because if received with= value of 1, it is decremented and discarded.)

 <= /p>

It seems to waste an inde= x value.

 <= /p>

I guess I’m interes= ted to know if that is important to other implementers, or if that was even= the intention?

 <= /p>

 <= /p>

-Dave

 <= /p>

 <= /p>

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric C Rosen
Sent: Wednesday, February 08, 2017 11:53 AM
To: James N Guichard; sfc@ietf.org
Subject: Re: [sfc] NSH Service Index Decrement

 

On 2/7/2017 2:24 PM, James N Guichard wrote:

A request was made to be more specific and update the text as foll= ows:

 

“Service index MUST be decremented by a value of 1 by Service Functions or by SFC Proxy nodes after per= forming required services …”


A couple of observations:

- The term "SFC Proxy node" is not defined in either the NSH draf= t or in RFC 7665.  I think the intention here is to say "SFC Prox= y".

- Is the intention that the SI remain unchanged while the SF is operating o= n the packet, or is the intention only that the SI be decremented before th= e packet is delivered by the SF or SFC Proxy to an SFF?

I'd suggest either:

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decremen= t the SI by 1 before delivering the packet to the next SFF"

or

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decremen= t the SI by 1 before delivering the packet to the next SFF, but not until t= he SF has finished all its other processing of the packet"

depending upon which is intended.

I think an implication of these procedures is that an SI value of 1 is not = valid.  If an SF gets an NSH packet with an SI of 1, the SF will decre= ment the SI (setting it to 0), send the packet to an SFF, and the SFF will = discard it, because 0 is an invalid SI value.  Is that the intention?

The draft makes it clear (well, sort of) that an SFF should discard a packe= t with an SI of 0, but does not seem to say that an SF or SFC Proxy should = discard a packet it receives with an SI of 0.  It would probably be a = good idea to say that.

Some text in the draft (e.g., section 7.1) states than an SFF should discar= d a packet with an SI of zero, but other text in the draft (e.g., section 3= .3) only says that an SFF should log an error if it sees an SI of zero.&nbs= p; It's probably best to change the text in 3.3. to say "SHOULD generate an error/log message and MUST discard= the packet", or something similar.

--_000_E8355113905631478EFF04F5AA706E98705018EFwtlexchp1sandvi_-- From nobody Wed Feb 8 17:50:54 2017 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 BCB9512954A for ; Wed, 8 Feb 2017 17:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.889 X-Spam-Level: X-Spam-Status: No, score=-6.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 d-rCTEre6hi4 for ; Wed, 8 Feb 2017 17:50:50 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 4DC661293F2 for ; Wed, 8 Feb 2017 17:50:50 -0800 (PST) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id E2BE0F3124375; Thu, 9 Feb 2017 01:50:48 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v191omrT006582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Feb 2017 01:50:48 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v191ohOX023257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Feb 2017 01:50:46 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.132]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Wed, 8 Feb 2017 20:50:43 -0500 From: "Dolganow, Andrew (Nokia - SG)" To: Dave Dolson , Eric C Rosen , James N Guichard , "sfc@ietf.org" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA3q0iAAAgj/lAAHXyRAA== Date: Thu, 9 Feb 2017 01:50:42 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_F8E7003712494D9A9834CD65C836F2EEnokiacom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 01:50:53 -0000 --_000_F8E7003712494D9A9834CD65C836F2EEnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhc3N1bWVkIHRoYXQgaWYgd2UgZ2V0IHZhbHVlIDEgd2UgcHJvY2VzcyB0aGVuIGZvcndhcmQg d2l0aG91dCBOU0ggaGVhZGVyIChpLmUuKSB0aGlzIGlzIHRoZSBsYXN0IFNGIHByb2Nlc3Npbmcu DQoNClNvIHdpdGggdGhhdCBhc3N1bXB0aW9uLCBhIG1vcmUgZXhwbGljaXQgdGV4dCB3b3VsZCBi ZToNCg0KQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBh Y2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBhZnRlciBwZXJmb3JtaW5nIGFsbCByZXF1 aXJlZCBsb2NhbCBwcm9jZXNzaW5nIGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFja2V0IHRv IHRoZSBuZXh0IFNGRi4gSWYgdGhlIHJlc3VsdGluZyBTSSBpcyAwLCB0aGUgU0YgTVVTVCByZW1v dmUgdGhlIE5TSCBoZWFkZXIgYmVmb3JlIGZvcndhcmRpbmcgdGhlIHBhY2tldC4NCg0KQW5kcmV3 DQpGcm9tOiBzZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGF2ZSBEb2xz b24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPg0KRGF0ZTogVGh1cnNkYXksIEZlYnJ1YXJ5IDksIDIw MTcgYXQgMjowNCBBTQ0KVG86IEVyaWMgUm9zZW4gPGVyb3NlbkBqdW5pcGVyLm5ldD4sIEphbWVz IE4gR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbT4sICJzZmNAaWV0Zi5vcmci IDxzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVj cmVtZW50DQoNCkVyaWMsDQpJIHdhcyBuZXZlciBxdWl0ZSBoYXBweSB3aXRoIHRoZSBvdXRjb21l IHRoYXQgbmVpdGhlciAwIG5vciAxIGlzIGEgdmFsaWQgU0kuDQooQmVjYXVzZSBpZiByZWNlaXZl ZCB3aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRlY3JlbWVudGVkIGFuZCBkaXNjYXJkZWQuKQ0KDQpJ dCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2YWx1ZS4NCg0KSSBndWVzcyBJ4oCZbSBpbnRlcmVz dGVkIHRvIGtub3cgaWYgdGhhdCBpcyBpbXBvcnRhbnQgdG8gb3RoZXIgaW1wbGVtZW50ZXJzLCBv ciBpZiB0aGF0IHdhcyBldmVuIHRoZSBpbnRlbnRpb24/DQoNCg0KLURhdmUNCg0KDQoNCkZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBDIFJv c2VuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3IDExOjUzIEFNDQpUbzogSmFt ZXMgTiBHdWljaGFyZDsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZp Y2UgSW5kZXggRGVjcmVtZW50DQoNCk9uIDIvNy8yMDE3IDI6MjQgUE0sIEphbWVzIE4gR3VpY2hh cmQgd3JvdGU6DQoNCg0KQSByZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUgc3BlY2lmaWMgYW5k IHVwZGF0ZSB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KDQrigJxTZXJ2aWNlIGluZGV4IE1VU1QgYmUg ZGVjcmVtZW50ZWQgYnkgYSB2YWx1ZSBvZiAxIGJ5IFNlcnZpY2UgRnVuY3Rpb25zIG9yIGJ5IFNG QyBQcm94eSBub2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZpY2VzIOKApuKAnQ0K DQpBIGNvdXBsZSBvZiBvYnNlcnZhdGlvbnM6DQoNCi0gVGhlIHRlcm0gIlNGQyBQcm94eSBub2Rl IiBpcyBub3QgZGVmaW5lZCBpbiBlaXRoZXIgdGhlIE5TSCBkcmFmdCBvciBpbiBSRkMgNzY2NS4g IEkgdGhpbmsgdGhlIGludGVudGlvbiBoZXJlIGlzIHRvIHNheSAiU0ZDIFByb3h5Ii4NCg0KLSBJ cyB0aGUgaW50ZW50aW9uIHRoYXQgdGhlIFNJIHJlbWFpbiB1bmNoYW5nZWQgd2hpbGUgdGhlIFNG IGlzIG9wZXJhdGluZyBvbiB0aGUgcGFja2V0LCBvciBpcyB0aGUgaW50ZW50aW9uIG9ubHkgdGhh dCB0aGUgU0kgYmUgZGVjcmVtZW50ZWQgYmVmb3JlIHRoZSBwYWNrZXQgaXMgZGVsaXZlcmVkIGJ5 IHRoZSBTRiBvciBTRkMgUHJveHkgdG8gYW4gU0ZGPw0KDQpJJ2Qgc3VnZ2VzdCBlaXRoZXI6DQoN CiJBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0 IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQg dG8gdGhlIG5leHQgU0ZGIg0KDQpvcg0KDQoiQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBh biBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBiZWZv cmUgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRiwgYnV0IG5vdCB1bnRpbCB0 aGUgU0YgaGFzIGZpbmlzaGVkIGFsbCBpdHMgb3RoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0 Ig0KDQpkZXBlbmRpbmcgdXBvbiB3aGljaCBpcyBpbnRlbmRlZC4NCg0KSSB0aGluayBhbiBpbXBs aWNhdGlvbiBvZiB0aGVzZSBwcm9jZWR1cmVzIGlzIHRoYXQgYW4gU0kgdmFsdWUgb2YgMSBpcyBu b3QgdmFsaWQuICBJZiBhbiBTRiBnZXRzIGFuIE5TSCBwYWNrZXQgd2l0aCBhbiBTSSBvZiAxLCB0 aGUgU0Ygd2lsbCBkZWNyZW1lbnQgdGhlIFNJIChzZXR0aW5nIGl0IHRvIDApLCBzZW5kIHRoZSBw YWNrZXQgdG8gYW4gU0ZGLCBhbmQgdGhlIFNGRiB3aWxsIGRpc2NhcmQgaXQsIGJlY2F1c2UgMCBp cyBhbiBpbnZhbGlkIFNJIHZhbHVlLiAgSXMgdGhhdCB0aGUgaW50ZW50aW9uPw0KDQpUaGUgZHJh ZnQgbWFrZXMgaXQgY2xlYXIgKHdlbGwsIHNvcnQgb2YpIHRoYXQgYW4gU0ZGIHNob3VsZCBkaXNj YXJkIGEgcGFja2V0IHdpdGggYW4gU0kgb2YgMCwgYnV0IGRvZXMgbm90IHNlZW0gdG8gc2F5IHRo YXQgYW4gU0Ygb3IgU0ZDIFByb3h5IHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IGl0IHJlY2VpdmVz IHdpdGggYW4gU0kgb2YgMC4gIEl0IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIHNh eSB0aGF0Lg0KDQpTb21lIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0aW9uIDcuMSkgc3Rh dGVzIHRoYW4gYW4gU0ZGIHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IHdpdGggYW4gU0kgb2YgemVy bywgYnV0IG90aGVyIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0aW9uIDMuMykgb25seSBz YXlzIHRoYXQgYW4gU0ZGIHNob3VsZCBsb2cgYW4gZXJyb3IgaWYgaXQgc2VlcyBhbiBTSSBvZiB6 ZXJvLiAgSXQncyBwcm9iYWJseSBiZXN0IHRvIGNoYW5nZSB0aGUgdGV4dCBpbiAzLjMuIHRvIHNh eSAiU0hPVUxEIGdlbmVyYXRlIGFuIGVycm9yL2xvZyBtZXNzYWdlIGFuZCBNVVNUIGRpc2NhcmQg dGhlIHBhY2tldCIsIG9yIHNvbWV0aGluZyBzaW1pbGFyLg0KDQoNCg== --_000_F8E7003712494D9A9834CD65C836F2EEnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <7A75CD714B29C74896FE0D8187D27CCD@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjp3aW5kb3d0ZXh0Ij5JIGFzc3VtZWQgdGhhdCBpZiB3ZSBn ZXQgdmFsdWUgMSB3ZSBwcm9jZXNzIHRoZW4gZm9yd2FyZCB3aXRob3V0IE5TSCBoZWFkZXIgKGku ZS4pIHRoaXMgaXMgdGhlIGxhc3QgU0YgcHJvY2Vzc2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6d2luZG93dGV4dCI+U28gd2l0aCB0aGF0IGFzc3Vt cHRpb24sIGEgbW9yZSBleHBsaWNpdCB0ZXh0IHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjp3aW5kb3d0ZXh0Ij5BbiBTRiBvciBTRkMgUHJv eHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRo ZSBTSSBieSAxIGFmdGVyIHBlcmZvcm1pbmcgYWxsIHJlcXVpcmVkIGxvY2FsIHByb2Nlc3Npbmcg YW5kIGJlZm9yZSBmb3J3YXJkaW5nIHRoZSBwYWNrZXQgdG8gdGhlDQogbmV4dCBTRkYuIElmIHRo ZSByZXN1bHRpbmcgU0kgaXMgMCwgdGhlIFNGIE1VU1QgcmVtb3ZlIHRoZSBOU0ggaGVhZGVyIGJl Zm9yZSBmb3J3YXJkaW5nIHRoZSBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpO2NvbG9yOndpbmRvd3RleHQiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+c2Zj ICZsdDtzZmMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIERhdmUgRG9sc29uICZs dDtkZG9sc29uQHNhbmR2aW5lLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIEZl YnJ1YXJ5IDksIDIwMTcgYXQgMjowNCBBTTxicj4NCjxiPlRvOiA8L2I+RXJpYyBSb3NlbiAmbHQ7 ZXJvc2VuQGp1bmlwZXIubmV0Jmd0OywgSmFtZXMgTiBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWlj aGFyZEBodWF3ZWkuY29tJmd0OywgJnF1b3Q7c2ZjQGlldGYub3JnJnF1b3Q7ICZsdDtzZmNAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRl eCBEZWNyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPkVyaWMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5JIHdhcyBuZXZlciBxdWl0ZSBoYXBweSB3aXRoIHRoZSBv dXRjb21lIHRoYXQgbmVpdGhlciAwIG5vciAxIGlzIGEgdmFsaWQgU0kuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjoj MUY0OTdEIj4oQmVjYXVzZSBpZiByZWNlaXZlZCB3aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRlY3Jl bWVudGVkIGFuZCBkaXNjYXJkZWQuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aTtjb2xvcjojMUY0OTdEIj5JdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2YWx1ZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyBJ4oCZ bSBpbnRlcmVzdGVkIHRvIGtub3cgaWYgdGhhdCBpcyBpbXBvcnRhbnQgdG8gb3RoZXIgaW1wbGVt ZW50ZXJzLCBvciBpZiB0aGF0IHdhcyBldmVuIHRoZSBpbnRlbnRpb24/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6 IzFGNDk3RCI+LURhdmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7 Y29sb3I6d2luZG93dGV4dCI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5FcmljIEMgUm9zZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBGZWJydWFyeSAwOCwgMjAxNyAxMTo1MyBBTTxicj4NCjxiPlRvOjwvYj4gSmFtZXMgTiBHdWlj aGFyZDsgc2ZjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBOU0ggU2Vy dmljZSBJbmRleCBEZWNyZW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5PbiAyLzcvMjAxNyAyOjI0IFBNLCBKYW1lcyBOIEd1aWNoYXJkIHdyb3RlOjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjM2LjBwdCI+DQpBIHJlcXVlc3Qgd2FzIG1hZGUgdG8gYmUgbW9yZSBzcGVjaWZpYyBh bmQgdXBkYXRlIHRoZSB0ZXh0IGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQrigJxTZXJ2aWNlIGlu ZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgPGI+YnkgYSB2YWx1ZSBvZiAxPC9iPiBieSBTZXJ2aWNl IEZ1bmN0aW9ucyBvciBieSBTRkMgUHJveHkgbm9kZXMgYWZ0ZXIgcGVyZm9ybWluZyByZXF1aXJl ZCBzZXJ2aWNlcyDigKbigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxicj4NCkEgY291cGxlIG9mIG9ic2VydmF0 aW9uczo8YnI+DQo8YnI+DQotIFRoZSB0ZXJtICZxdW90O1NGQyBQcm94eSBub2RlJnF1b3Q7IGlz IG5vdCBkZWZpbmVkIGluIGVpdGhlciB0aGUgTlNIIGRyYWZ0IG9yIGluIFJGQyA3NjY1LiZuYnNw OyBJIHRoaW5rIHRoZSBpbnRlbnRpb24gaGVyZSBpcyB0byBzYXkgJnF1b3Q7U0ZDIFByb3h5JnF1 b3Q7Ljxicj4NCjxicj4NCi0gSXMgdGhlIGludGVudGlvbiB0aGF0IHRoZSBTSSByZW1haW4gdW5j aGFuZ2VkIHdoaWxlIHRoZSBTRiBpcyBvcGVyYXRpbmcgb24gdGhlIHBhY2tldCwgb3IgaXMgdGhl IGludGVudGlvbiBvbmx5IHRoYXQgdGhlIFNJIGJlIGRlY3JlbWVudGVkIGJlZm9yZSB0aGUgcGFj a2V0IGlzIGRlbGl2ZXJlZCBieSB0aGUgU0Ygb3IgU0ZDIFByb3h5IHRvIGFuIFNGRj8NCjxicj4N Cjxicj4NCkknZCBzdWdnZXN0IGVpdGhlcjo8YnI+DQo8YnI+DQomcXVvdDtBbiBTRiBvciBTRkMg UHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50 IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZG JnF1b3Q7PGJyPg0KPGJyPg0Kb3I8YnI+DQo8YnI+DQomcXVvdDtBbiBTRiBvciBTRkMgUHJveHkg cmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBT SSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGLCBidXQg bm90IHVudGlsIHRoZSBTRiBoYXMgZmluaXNoZWQgYWxsIGl0cyBvdGhlciBwcm9jZXNzaW5nIG9m IHRoZSBwYWNrZXQmcXVvdDs8YnI+DQo8YnI+DQpkZXBlbmRpbmcgdXBvbiB3aGljaCBpcyBpbnRl bmRlZC48YnI+DQo8YnI+DQpJIHRoaW5rIGFuIGltcGxpY2F0aW9uIG9mIHRoZXNlIHByb2NlZHVy ZXMgaXMgdGhhdCBhbiBTSSB2YWx1ZSBvZiAxIGlzIG5vdCB2YWxpZC4mbmJzcDsgSWYgYW4gU0Yg Z2V0cyBhbiBOU0ggcGFja2V0IHdpdGggYW4gU0kgb2YgMSwgdGhlIFNGIHdpbGwgZGVjcmVtZW50 IHRoZSBTSSAoc2V0dGluZyBpdCB0byAwKSwgc2VuZCB0aGUgcGFja2V0IHRvIGFuIFNGRiwgYW5k IHRoZSBTRkYgd2lsbCBkaXNjYXJkIGl0LCBiZWNhdXNlIDAgaXMgYW4gaW52YWxpZCBTSQ0KIHZh bHVlLiZuYnNwOyBJcyB0aGF0IHRoZSBpbnRlbnRpb24/PGJyPg0KPGJyPg0KVGhlIGRyYWZ0IG1h a2VzIGl0IGNsZWFyICh3ZWxsLCBzb3J0IG9mKSB0aGF0IGFuIFNGRiBzaG91bGQgZGlzY2FyZCBh IHBhY2tldCB3aXRoIGFuIFNJIG9mIDAsIGJ1dCBkb2VzIG5vdCBzZWVtIHRvIHNheSB0aGF0IGFu IFNGIG9yIFNGQyBQcm94eSBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCBpdCByZWNlaXZlcyB3aXRo IGFuIFNJIG9mIDAuJm5ic3A7IEl0IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIHNh eSB0aGF0Ljxicj4NCjxicj4NClNvbWUgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNlY3Rpb24g Ny4xKSBzdGF0ZXMgdGhhbiBhbiBTRkYgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQgd2l0aCBhbiBT SSBvZiB6ZXJvLCBidXQgb3RoZXIgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNlY3Rpb24gMy4z KSBvbmx5IHNheXMgdGhhdCBhbiBTRkYgc2hvdWxkIGxvZyBhbiBlcnJvciBpZiBpdCBzZWVzIGFu IFNJIG9mIHplcm8uJm5ic3A7IEl0J3MgcHJvYmFibHkgYmVzdCB0byBjaGFuZ2UgdGhlIHRleHQN CiBpbiAzLjMuIHRvIHNheSAmcXVvdDtTSE9VTEQgZ2VuZXJhdGUgYW4gZXJyb3IvbG9nIG1lc3Nh Z2UgYW5kIE1VU1QgZGlzY2FyZCB0aGUgcGFja2V0JnF1b3Q7LCBvciBzb21ldGhpbmcgc2ltaWxh ci48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_F8E7003712494D9A9834CD65C836F2EEnokiacom_-- From nobody Thu Feb 9 04:12:45 2017 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 180191299AA for ; Thu, 9 Feb 2017 04:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 jA4HMlHH4qof for ; Thu, 9 Feb 2017 04:12:40 -0800 (PST) Received: from smtp2.telecom.pt (smtp2.telecom.pt [83.240.175.146]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4371299B8 for ; Thu, 9 Feb 2017 04:12:38 -0800 (PST) From: Fabricio Ferraz To: "Dolganow, Andrew (Nokia - SG)" , Dave Dolson , Eric C Rosen , James N Guichard , "sfc@ietf.org" Date: Thu, 9 Feb 2017 12:12:34 +0000 Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA3q0iAAAgj/lAAHXyRAAAH1qCQ Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> In-Reply-To: Accept-Language: pt-PT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT, en-US Content-Type: multipart/alternative; boundary="_000_CB8C08780539D74B9BE1ED5174662634D2D7553139PTPPICEX01PTP_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 12:12:44 -0000 --_000_CB8C08780539D74B9BE1ED5174662634D2D7553139PTPPICEX01PTP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KSeKAmW0gbmV3IGhlcmUgKGp1c3QgcmVhZCB0aGUgZHJhZnQgbGFzdCB3ZWVrKSBi dXQgYWNjb3JkaW5nIHRvIGNoYXB0ZXIgNCAoY2hlY2sgZmlndXJlIDggZm9yIGV4YW1wbGUpLCBh biBTRiBpcyBub3QgYWxsb3dlZCB0byBpbnNlcnQgb3IgcmVtb3ZlIE5TSC4gVGhlIHJlbW92YWwg b2YgTlNIIGlzIHJlcG9uc2FiaWxpdHkgb2YgdGhlIFNTRiwgcmlnaHQ/DQoNCiAgRmlndXJlIDgg bWFwcyBlYWNoIG9mIHRoZSBmb3VyIGFjdGlvbnMgYWJvdmUgdG8gdGhlIGNvbXBvbmVudHMgaW4g dGhlDQogICBTRkMgYXJjaGl0ZWN0dXJlIHRoYXQgY2FuIHBlcmZvcm0gaXQuDQoNCistLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0rDQp8ICAgICAgICAgICAgICAgIHwgIEluc2VydCAgICAgICAgIHxTZWxlY3QgfCAgIFVw ZGF0ZSAgICAgICB8U2VydmljZSAgfA0KfCAgICAgICAgICAgICAgICB8ICBvciByZW1vdmUgTlNI ICB8U2VydmljZXwgICAgTlNIICAgICAgICAgfHBvbGljeSAgIHwNCnwgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgfEZ1bmN0aW9ufCAgICAgICAgICAgICAgIHxzZWxlY3Rpb258DQp8 IENvbXBvbmVudCAgICAgICstLS0tLS0tLSstLS0tLS0tLStQYXRoICAgKy0tLS0tLS0tLS0tLS0t LS0rICAgICAgICAgfA0KfCAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICB8ICAgICAg IHwgRGVjLiAgIHxVcGRhdGUgfCAgICAgICAgIHwNCnwgICAgICAgICAgICAgICAgfCBJbnNlcnQg fCBSZW1vdmUgfCAgICAgICB8U2VydmljZSB8Q29udGV4dHwgICAgICAgICB8DQp8ICAgICAgICAg ICAgICAgIHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCBJbmRleCAgfEhlYWRlciB8ICAgICAg ICAgfA0KKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0t LSstLS0tLS0tKy0tLS0tLS0tLSsNCnwgICAgICAgICAgICAgICAgfCAgICsgICAgfCAgICsgICAg fCAgICAgICB8ICAgICAgICB8ICAgKyAgIHwgICAgICAgICB8DQp8Q2xhc3NpZmllciAgICAgIHwg ICAgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICAgfA0KKy0t LS0tLS0tLS0tLS0tLSArLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0t Ky0tLS0tLS0tLSsNCnxTZXJ2aWNlIEZ1bmN0aW9ufCAgICAgICAgfCAgICsgICAgfCAgKyAgICB8 ICAgICAgICB8ICAgICAgIHwgICAgICAgICB8DQp8Rm9yd2FyZGVyKFNGRikgIHwgICAgICAgIHwg ICAgICAgIHwgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICAgfA0KKy0tLS0tLS0tLS0t LS0tLSArLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0t LSsNCnxTZXJ2aWNlICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgKyAgICB8 ICAgKyAgIHwgICArICAgICB8DQp8RnVuY3Rpb24gIChTRikgIHwgICAgICAgIHwgICAgICAgIHwg ICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0tLSArLS0t LS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsNCnxTRkMg UHJveHkgICAgICAgfCAgICsgICAgfCAgICsgICAgfCAgICAgICB8ICAgKyAgICB8ICAgICAgIHwg ICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tKw0KDQogICAgICAgICAgICAgICAgICAgRmlndXJlIDg6 IE5TSCBBY3Rpb24gYW5kIFJvbGUgTWFwcGluZw0KDQoNCkFuIFNGIGNvdWxkIHJlY2VpdmUgYW4g TlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIGFuZCByZWNsYXNzaWZ5IGl0IHRvIGEgZGlmZmVy ZW50IFNQSSBhbmQgU0ksIHJpZ2h0PyBTbyB3aGVuIGEgU0YgcmVjZWl2ZXMgYSBOU0ggcGFja2V0 IHdpdGggU0kgPSAxIHRoYXQgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbnMgYSBub24gdmFsaWQg cGFja2V0Lg0KQW5kIHRoYXQgY2FuIGV2ZW4gd29yayBmb3IgU0k9MCwgc2luY2UgeW91IGRlY3Jl bWVudCB0aGUgU0kgaW4gdGhlIGVncmVzcy4NCg0KRmFicmljaW8NCg0KDQpGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERvbGdhbm93LCBBbmRyZXcg KE5va2lhIC0gU0cpDQpTZW50OiBxdWludGEtZmVpcmEsIDkgZGUgZmV2ZXJlaXJvIGRlIDIwMTcg MDE6NTENClRvOiBEYXZlIERvbHNvbjsgRXJpYyBDIFJvc2VuOyBKYW1lcyBOIEd1aWNoYXJkOyBz ZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1l bnQNCg0KSSBhc3N1bWVkIHRoYXQgaWYgd2UgZ2V0IHZhbHVlIDEgd2UgcHJvY2VzcyB0aGVuIGZv cndhcmQgd2l0aG91dCBOU0ggaGVhZGVyIChpLmUuKSB0aGlzIGlzIHRoZSBsYXN0IFNGIHByb2Nl c3NpbmcuDQoNClNvIHdpdGggdGhhdCBhc3N1bXB0aW9uLCBhIG1vcmUgZXhwbGljaXQgdGV4dCB3 b3VsZCBiZToNCg0KQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxh dGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBhZnRlciBwZXJmb3JtaW5nIGFs bCByZXF1aXJlZCBsb2NhbCBwcm9jZXNzaW5nIGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFj a2V0IHRvIHRoZSBuZXh0IFNGRi4gSWYgdGhlIHJlc3VsdGluZyBTSSBpcyAwLCB0aGUgU0YgTVVT VCByZW1vdmUgdGhlIE5TSCBoZWFkZXIgYmVmb3JlIGZvcndhcmRpbmcgdGhlIHBhY2tldC4NCg0K QW5kcmV3DQpGcm9tOiBzZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5j b208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4NCkRhdGU6IFRodXJzZGF5LCBGZWJydWFy eSA5LCAyMDE3IGF0IDI6MDQgQU0NClRvOiBFcmljIFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ8 bWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5ldD4+LCBKYW1lcyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1 aWNoYXJkQGh1YXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbT4+LCAi c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3Jl bWVudA0KDQpFcmljLA0KSSB3YXMgbmV2ZXIgcXVpdGUgaGFwcHkgd2l0aCB0aGUgb3V0Y29tZSB0 aGF0IG5laXRoZXIgMCBub3IgMSBpcyBhIHZhbGlkIFNJLg0KKEJlY2F1c2UgaWYgcmVjZWl2ZWQg d2l0aCB2YWx1ZSBvZiAxLCBpdCBpcyBkZWNyZW1lbnRlZCBhbmQgZGlzY2FyZGVkLikNCg0KSXQg c2VlbXMgdG8gd2FzdGUgYW4gaW5kZXggdmFsdWUuDQoNCkkgZ3Vlc3MgSeKAmW0gaW50ZXJlc3Rl ZCB0byBrbm93IGlmIHRoYXQgaXMgaW1wb3J0YW50IHRvIG90aGVyIGltcGxlbWVudGVycywgb3Ig aWYgdGhhdCB3YXMgZXZlbiB0aGUgaW50ZW50aW9uPw0KDQoNCi1EYXZlDQoNCg0KDQpGcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgQyBSb3Nl bg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyAxMTo1MyBBTQ0KVG86IEphbWVz IE4gR3VpY2hhcmQ7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudA0KDQpPbiAyLzcvMjAxNyAyOjI0 IFBNLCBKYW1lcyBOIEd1aWNoYXJkIHdyb3RlOg0KDQpBIHJlcXVlc3Qgd2FzIG1hZGUgdG8gYmUg bW9yZSBzcGVjaWZpYyBhbmQgdXBkYXRlIHRoZSB0ZXh0IGFzIGZvbGxvd3M6DQoNCuKAnFNlcnZp Y2UgaW5kZXggTVVTVCBiZSBkZWNyZW1lbnRlZCBieSBhIHZhbHVlIG9mIDEgYnkgU2VydmljZSBG dW5jdGlvbnMgb3IgYnkgU0ZDIFByb3h5IG5vZGVzIGFmdGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQg c2VydmljZXMg4oCm4oCdDQoNCkEgY291cGxlIG9mIG9ic2VydmF0aW9uczoNCg0KLSBUaGUgdGVy bSAiU0ZDIFByb3h5IG5vZGUiIGlzIG5vdCBkZWZpbmVkIGluIGVpdGhlciB0aGUgTlNIIGRyYWZ0 IG9yIGluIFJGQyA3NjY1LiAgSSB0aGluayB0aGUgaW50ZW50aW9uIGhlcmUgaXMgdG8gc2F5ICJT RkMgUHJveHkiLg0KDQotIElzIHRoZSBpbnRlbnRpb24gdGhhdCB0aGUgU0kgcmVtYWluIHVuY2hh bmdlZCB3aGlsZSB0aGUgU0YgaXMgb3BlcmF0aW5nIG9uIHRoZSBwYWNrZXQsIG9yIGlzIHRoZSBp bnRlbnRpb24gb25seSB0aGF0IHRoZSBTSSBiZSBkZWNyZW1lbnRlZCBiZWZvcmUgdGhlIHBhY2tl dCBpcyBkZWxpdmVyZWQgYnkgdGhlIFNGIG9yIFNGQyBQcm94eSB0byBhbiBTRkY/DQoNCkknZCBz dWdnZXN0IGVpdGhlcjoNCg0KIkFuIFNGIG9yIFNGQyBQcm94eSByZWNlaXZpbmcgYW4gTlNILWVu Y2Fwc3VsYXRlZCBwYWNrZXQgTVVTVCBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEgYmVmb3JlIGRlbGl2 ZXJpbmcgdGhlIHBhY2tldCB0byB0aGUgbmV4dCBTRkYiDQoNCm9yDQoNCiJBbiBTRiBvciBTRkMg UHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50 IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZG LCBidXQgbm90IHVudGlsIHRoZSBTRiBoYXMgZmluaXNoZWQgYWxsIGl0cyBvdGhlciBwcm9jZXNz aW5nIG9mIHRoZSBwYWNrZXQiDQoNCmRlcGVuZGluZyB1cG9uIHdoaWNoIGlzIGludGVuZGVkLg0K DQpJIHRoaW5rIGFuIGltcGxpY2F0aW9uIG9mIHRoZXNlIHByb2NlZHVyZXMgaXMgdGhhdCBhbiBT SSB2YWx1ZSBvZiAxIGlzIG5vdCB2YWxpZC4gIElmIGFuIFNGIGdldHMgYW4gTlNIIHBhY2tldCB3 aXRoIGFuIFNJIG9mIDEsIHRoZSBTRiB3aWxsIGRlY3JlbWVudCB0aGUgU0kgKHNldHRpbmcgaXQg dG8gMCksIHNlbmQgdGhlIHBhY2tldCB0byBhbiBTRkYsIGFuZCB0aGUgU0ZGIHdpbGwgZGlzY2Fy ZCBpdCwgYmVjYXVzZSAwIGlzIGFuIGludmFsaWQgU0kgdmFsdWUuICBJcyB0aGF0IHRoZSBpbnRl bnRpb24/DQoNClRoZSBkcmFmdCBtYWtlcyBpdCBjbGVhciAod2VsbCwgc29ydCBvZikgdGhhdCBh biBTRkYgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQgd2l0aCBhbiBTSSBvZiAwLCBidXQgZG9lcyBu b3Qgc2VlbSB0byBzYXkgdGhhdCBhbiBTRiBvciBTRkMgUHJveHkgc2hvdWxkIGRpc2NhcmQgYSBw YWNrZXQgaXQgcmVjZWl2ZXMgd2l0aCBhbiBTSSBvZiAwLiAgSXQgd291bGQgcHJvYmFibHkgYmUg YSBnb29kIGlkZWEgdG8gc2F5IHRoYXQuDQoNClNvbWUgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4s IHNlY3Rpb24gNy4xKSBzdGF0ZXMgdGhhbiBhbiBTRkYgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQg d2l0aCBhbiBTSSBvZiB6ZXJvLCBidXQgb3RoZXIgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNl Y3Rpb24gMy4zKSBvbmx5IHNheXMgdGhhdCBhbiBTRkYgc2hvdWxkIGxvZyBhbiBlcnJvciBpZiBp dCBzZWVzIGFuIFNJIG9mIHplcm8uICBJdCdzIHByb2JhYmx5IGJlc3QgdG8gY2hhbmdlIHRoZSB0 ZXh0IGluIDMuMy4gdG8gc2F5ICJTSE9VTEQgZ2VuZXJhdGUgYW4gZXJyb3IvbG9nIG1lc3NhZ2Ug YW5kIE1VU1QgZGlzY2FyZCB0aGUgcGFja2V0Iiwgb3Igc29tZXRoaW5nIHNpbWlsYXIuDQoNCg== --_000_CB8C08780539D74B9BE1ED5174662634D2D7553139PTPPICEX01PTP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnBy ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0 ZSBsYW5nPVBUIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IaSBhbGwsPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+SeKAmW0gbmV3IGhlcmUgKGp1c3QgcmVhZCB0aGUgZHJhZnQgbGFzdCB3 ZWVrKSBidXQgYWNjb3JkaW5nIHRvIGNoYXB0ZXIgNCAoY2hlY2sgZmlndXJlIDggZm9yIGV4YW1w bGUpLCBhbiBTRiBpcyBub3QgYWxsb3dlZCB0byBpbnNlcnQgb3IgcmVtb3ZlIE5TSC4gVGhlIHJl bW92YWwgb2YgTlNIIGlzIHJlcG9uc2FiaWxpdHkgb2YgdGhlIFNTRiwgcmlnaHQ/PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J21zby1lbGVt ZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjcu MHB0IDcuMHB0IDcuMHB0IDcuMHB0O2JhY2tncm91bmQ6I0ZGRkRGNSc+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i cmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoCBGaWd1 cmUgOCBtYXBzIGVhY2ggb2YgdGhlIGZvdXIgYWN0aW9ucyBhYm92ZSB0byB0aGUgY29tcG9uZW50 cyBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1h bGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgIFNGQyBhcmNoaXRlY3R1 cmUgdGhhdCBjYW4gcGVyZm9ybSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29y ZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9y ZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4gKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVw dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFk ZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAg SW5zZXJ0wqDCoMKgwqDCoMKgwqDCoCB8U2VsZWN0IHzCoMKgIFVwZGF0ZcKgwqDCoMKgwqDCoCB8 U2VydmljZcKgIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4gfMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8wqAgb3IgcmVtb3ZlIE5TSMKgIHxTZXJ2aWNlfMKgwqDCoCBOU0jC oMKgwqDCoMKgwqDCoMKgIHxwb2xpY3nCoMKgIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZE RjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfEZ1bmN0aW9ufMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfHNlbGVj dGlvbnw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7 Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4gfCBDb21wb25lbnTCoMKgwqDCoMKg ICstLS0tLS0tLSstLS0tLS0tLStQYXRowqDCoCArLS0tLS0tLS0tLS0tLS0tLSvCoMKgwqDCoMKg wqDCoMKgIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1h bGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4gfMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKg wqAgfCBEZWMuwqDCoCB8VXBkYXRlIHzCoMKgwqDCoMKgwqDCoMKgIHw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNr Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzow Y20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IEluc2VydCB8 IFJlbW92ZSB8wqDCoMKgwqDCoMKgIHxTZXJ2aWNlIHxDb250ZXh0fMKgwqDCoMKgwqDCoMKgwqAg fDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3Jk ZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIHzCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoCB8IElu ZGV4wqAgfEhlYWRlciB8wqDCoMKgwqDCoMKgwqDCoCB8PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDoj RkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+ICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0t LS0rLS0tLS0tLSstLS0tLS0tLS0rPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt YnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+IHzCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqAgK8KgwqDCoCB8wqDCoCArwqDCoMKgIHzC oMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgICvCoMKgIHzCoMKgwqDCoMKgwqDCoMKg IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9y ZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4gfENsYXNzaWZpZXLCoMKgwqDCoMKgIHzC oMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKg wqAgfMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoCB8PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3Vu ZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+ICstLS0tLS0tLS0tLS0tLS0gKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0t LS0tLS0rLS0tLS0tLSstLS0tLS0tLS0rPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv cmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+IHxT ZXJ2aWNlIEZ1bmN0aW9ufMKgwqDCoMKgwqDCoMKgIHzCoMKgICvCoMKgwqAgfMKgICvCoMKgwqAg fMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqAgfDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ny4x NXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtw YWRkaW5nOjBjbSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiB8Rm9yd2FyZGVyKFNGRinCoCB8wqDCoMKgwqDCoMKgwqAg fMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKg wqAgfMKgwqDCoMKgwqDCoMKgwqAgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk LWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiArLS0t LS0tLS0tLS0tLS0tICstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0r LS0tLS0tLS0tKzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiB8U2VydmljZcKgwqDCoMKg wqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoCB8IMKgwqDCoMKgwqDCoHzC oMKgICvCoMKgwqAgfMKgwqAgK8KgwqAgfMKgwqAgK8KgwqDCoMKgIHw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNr Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzow Y20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4gfEZ1bmN0aW9uwqAgKFNGKcKgIHzCoMKgwqDCoMKgwqDCoCB8wqDCoMKg wqDCoMKgwqAgfMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoCB8wqDC oMKgwqDCoMKgwqDCoCB8PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ICstLS0tLS0tLS0t LS0tLS0gKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0t LS0rPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2Jv cmRlcjpub25lO3BhZGRpbmc6MGNtJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+IHxTRkMgUHJveHnCoMKgwqDCoMKgwqAg fMKgwqAgK8KgwqDCoCB8wqDCoCArwqDCoMKgIHzCoMKgwqDCoMKgwqAgfMKgwqAgK8KgwqDCoCB8 wqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNG RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz4gKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0t LSstLS0tLS0tKy0tLS0tLS0tLSs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i cmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90 dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVy Om5vbmU7cGFkZGluZzowY20nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgRmlndXJlIDg6IE5TSCBBY3Rpb24gYW5kIFJvbGUgTWFwcGluZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkFuIFNGIGNvdWxkIHJlY2VpdmUgYW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIGFu ZCByZWNsYXNzaWZ5IGl0IHRvIGEgZGlmZmVyZW50IFNQSSBhbmQgU0ksIHJpZ2h0PyBTbyB3aGVu IGEgU0YgcmVjZWl2ZXMgYSBOU0ggcGFja2V0IHdpdGggU0kgPSAxIHRoYXQgZG9lcyBub3QgbmVj ZXNzYXJpbHkgbWVhbnMgYSBub24gdmFsaWQgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFuZCB0 aGF0IGNhbiBldmVuIHdvcmsgZm9yIFNJPTAsIHNpbmNlIHlvdSBkZWNyZW1lbnQgdGhlIFNJIGlu IHRoZSBlZ3Jlc3MuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RmFi cmljaW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz4gc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+RG9sZ2Fub3cs IEFuZHJldyAoTm9raWEgLSBTRyk8YnI+PGI+U2VudDo8L2I+IHF1aW50YS1mZWlyYSwgOSBkZSBm ZXZlcmVpcm8gZGUgMjAxNyAwMTo1MTxicj48Yj5Ubzo8L2I+IERhdmUgRG9sc29uOyBFcmljIEMg Um9zZW47IEphbWVzIE4gR3VpY2hhcmQ7IHNmY0BpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4g UmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5JIGFz c3VtZWQgdGhhdCBpZiB3ZSBnZXQgdmFsdWUgMSB3ZSBwcm9jZXNzIHRoZW4gZm9yd2FyZCB3aXRo b3V0IE5TSCBoZWFkZXIgKGkuZS4pIHRoaXMgaXMgdGhlIGxhc3QgU0YgcHJvY2Vzc2luZy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5TbyB3aXRoIHRoYXQg YXNzdW1wdGlvbiwgYSBtb3JlIGV4cGxpY2l0IHRleHQgd291bGQgYmU6PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93 dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+QW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2Vp dmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkg MSBhZnRlciBwZXJmb3JtaW5nIGFsbCByZXF1aXJlZCBsb2NhbCBwcm9jZXNzaW5nIGFuZCBiZWZv cmUgZm9yd2FyZGluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRi4gSWYgdGhlIHJlc3VsdGlu ZyBTSSBpcyAwLCB0aGUgU0YgTVVTVCByZW1vdmUgdGhlIE5TSCBoZWFkZXIgYmVmb3JlIGZvcndh cmRpbmcgdGhlIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5k b3d0ZXh0Jz5BbmRyZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48Yj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPnNmYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEYXZlIERv bHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tIj5kZG9sc29uQHNh bmR2aW5lLmNvbTwvYT4mZ3Q7PGJyPjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgRmVicnVhcnkgOSwg MjAxNyBhdCAyOjA0IEFNPGJyPjxiPlRvOiA8L2I+RXJpYyBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmVyb3NlbkBqdW5pcGVyLm5ldCI+ZXJvc2VuQGp1bmlwZXIubmV0PC9hPiZndDssIEphbWVz IE4gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5j b20iPmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48Yj5TdWJqZWN0OiA8 L2I+UmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYu MHB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FcmljLDwvc3Bh bj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkkgd2FzIG5ldmVyIHF1aXRlIGhhcHB5IHdpdGggdGhlIG91dGNvbWUgdGhhdCBuZWl0 aGVyIDAgbm9yIDEgaXMgYSB2YWxpZCBTSS48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4w cHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4oQmVjYXVzZSBpZiByZWNlaXZl ZCB3aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRlY3JlbWVudGVkIGFuZCBkaXNjYXJkZWQuKTwvc3Bh bj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkl0IHNlZW1zIHRvIHdhc3RlIGFuIGluZGV4IHZhbHVl Ljwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZ3Vlc3MgSeKAmW0gaW50ZXJlc3RlZCB0 byBrbm93IGlmIHRoYXQgaXMgaW1wb3J0YW50IHRvIG90aGVyIGltcGxlbWVudGVycywgb3IgaWYg dGhhdCB3YXMgZXZlbiB0aGUgaW50ZW50aW9uPzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2 LjBwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPi1EYXZlPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0 Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWxlZnQ6MzYuMHB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48 L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3 aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93 dGV4dCc+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgQyBSb3Nl bjxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyAxMTo1MyBBTTxi cj48Yj5Ubzo8L2I+IEphbWVzIE4gR3VpY2hhcmQ7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBOU0ggU2Vy dmljZSBJbmRleCBEZWNyZW1lbnQ8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFu Zz1FTi1VUz5PbiAyLzcvMjAxNyAyOjI0IFBNLCBKYW1lcyBOIEd1aWNoYXJkIHdyb3RlOjxicj48 YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MzYuMHB0Jz48c3BhbiBsYW5nPUVOLVVTPkEgcmVxdWVzdCB3YXMgbWFkZSB0byBiZSBtb3JlIHNw ZWNpZmljIGFuZCB1cGRhdGUgdGhlIHRleHQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4t VVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MzYuMHB0Jz48c3BhbiBsYW5nPUVOLVVTPuKAnFNlcnZpY2UgaW5kZXggTVVTVCBiZSBk ZWNyZW1lbnRlZCA8Yj5ieSBhIHZhbHVlIG9mIDE8L2I+IGJ5IFNlcnZpY2UgRnVuY3Rpb25zIG9y IGJ5IFNGQyBQcm94eSBub2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZpY2VzIOKA puKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDtt YXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVM+PGJyPkEgY291cGxlIG9mIG9ic2Vy dmF0aW9uczo8YnI+PGJyPi0gVGhlIHRlcm0gJnF1b3Q7U0ZDIFByb3h5IG5vZGUmcXVvdDsgaXMg bm90IGRlZmluZWQgaW4gZWl0aGVyIHRoZSBOU0ggZHJhZnQgb3IgaW4gUkZDIDc2NjUuJm5ic3A7 IEkgdGhpbmsgdGhlIGludGVudGlvbiBoZXJlIGlzIHRvIHNheSAmcXVvdDtTRkMgUHJveHkmcXVv dDsuPGJyPjxicj4tIElzIHRoZSBpbnRlbnRpb24gdGhhdCB0aGUgU0kgcmVtYWluIHVuY2hhbmdl ZCB3aGlsZSB0aGUgU0YgaXMgb3BlcmF0aW5nIG9uIHRoZSBwYWNrZXQsIG9yIGlzIHRoZSBpbnRl bnRpb24gb25seSB0aGF0IHRoZSBTSSBiZSBkZWNyZW1lbnRlZCBiZWZvcmUgdGhlIHBhY2tldCBp cyBkZWxpdmVyZWQgYnkgdGhlIFNGIG9yIFNGQyBQcm94eSB0byBhbiBTRkY/IDxicj48YnI+SSdk IHN1Z2dlc3QgZWl0aGVyOjxicj48YnI+JnF1b3Q7QW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2Vpdmlu ZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBi ZWZvcmUgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRiZxdW90Ozxicj48YnI+ b3I8YnI+PGJyPiZxdW90O0FuIFNGIG9yIFNGQyBQcm94eSByZWNlaXZpbmcgYW4gTlNILWVuY2Fw c3VsYXRlZCBwYWNrZXQgTVVTVCBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEgYmVmb3JlIGRlbGl2ZXJp bmcgdGhlIHBhY2tldCB0byB0aGUgbmV4dCBTRkYsIGJ1dCBub3QgdW50aWwgdGhlIFNGIGhhcyBm aW5pc2hlZCBhbGwgaXRzIG90aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBhY2tldCZxdW90Ozxicj48 YnI+ZGVwZW5kaW5nIHVwb24gd2hpY2ggaXMgaW50ZW5kZWQuPGJyPjxicj5JIHRoaW5rIGFuIGlt cGxpY2F0aW9uIG9mIHRoZXNlIHByb2NlZHVyZXMgaXMgdGhhdCBhbiBTSSB2YWx1ZSBvZiAxIGlz IG5vdCB2YWxpZC4mbmJzcDsgSWYgYW4gU0YgZ2V0cyBhbiBOU0ggcGFja2V0IHdpdGggYW4gU0kg b2YgMSwgdGhlIFNGIHdpbGwgZGVjcmVtZW50IHRoZSBTSSAoc2V0dGluZyBpdCB0byAwKSwgc2Vu ZCB0aGUgcGFja2V0IHRvIGFuIFNGRiwgYW5kIHRoZSBTRkYgd2lsbCBkaXNjYXJkIGl0LCBiZWNh dXNlIDAgaXMgYW4gaW52YWxpZCBTSSB2YWx1ZS4mbmJzcDsgSXMgdGhhdCB0aGUgaW50ZW50aW9u Pzxicj48YnI+VGhlIGRyYWZ0IG1ha2VzIGl0IGNsZWFyICh3ZWxsLCBzb3J0IG9mKSB0aGF0IGFu IFNGRiBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCB3aXRoIGFuIFNJIG9mIDAsIGJ1dCBkb2VzIG5v dCBzZWVtIHRvIHNheSB0aGF0IGFuIFNGIG9yIFNGQyBQcm94eSBzaG91bGQgZGlzY2FyZCBhIHBh Y2tldCBpdCByZWNlaXZlcyB3aXRoIGFuIFNJIG9mIDAuJm5ic3A7IEl0IHdvdWxkIHByb2JhYmx5 IGJlIGEgZ29vZCBpZGVhIHRvIHNheSB0aGF0Ljxicj48YnI+U29tZSB0ZXh0IGluIHRoZSBkcmFm dCAoZS5nLiwgc2VjdGlvbiA3LjEpIHN0YXRlcyB0aGFuIGFuIFNGRiBzaG91bGQgZGlzY2FyZCBh IHBhY2tldCB3aXRoIGFuIFNJIG9mIHplcm8sIGJ1dCBvdGhlciB0ZXh0IGluIHRoZSBkcmFmdCAo ZS5nLiwgc2VjdGlvbiAzLjMpIG9ubHkgc2F5cyB0aGF0IGFuIFNGRiBzaG91bGQgbG9nIGFuIGVy cm9yIGlmIGl0IHNlZXMgYW4gU0kgb2YgemVyby4mbmJzcDsgSXQncyBwcm9iYWJseSBiZXN0IHRv IGNoYW5nZSB0aGUgdGV4dCBpbiAzLjMuIHRvIHNheSAmcXVvdDtTSE9VTEQgZ2VuZXJhdGUgYW4g ZXJyb3IvbG9nIG1lc3NhZ2UgYW5kIE1VU1QgZGlzY2FyZCB0aGUgcGFja2V0JnF1b3Q7LCBvciBz b21ldGhpbmcgc2ltaWxhci48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --_000_CB8C08780539D74B9BE1ED5174662634D2D7553139PTPPICEX01PTP_-- From nobody Thu Feb 9 08:22:28 2017 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 07A9D129B3C for ; Thu, 9 Feb 2017 08:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 sKpH0DP71M99 for ; Thu, 9 Feb 2017 08:22:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A587129B6C for ; Thu, 9 Feb 2017 08:22:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGD28087; Thu, 09 Feb 2017 16:22:22 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 9 Feb 2017 16:22:21 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Thu, 9 Feb 2017 08:22:12 -0800 From: James N Guichard To: "Dolganow, Andrew (Nokia - SG)" , Dave Dolson , Eric C Rosen , "sfc@ietf.org" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAANKsrg Date: Thu, 9 Feb 2017 16:22:10 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.56] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB6868SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.589C973E.0387, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a70407c9a835e72958c2c0bc1d89c9e Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:22:27 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB6868SJCEML701CHMchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5kcmV3LA0KDQpUaGUgbGFzdCBzZW50ZW5jZSBpcyBpbmNvcnJlY3QgYXMgdGhlIGN1cnJl bnQgYXJjaGl0ZWN0dXJlIHNwZWNpZmllcyB0aGF0IHJlbW92YWwgb2YgTlNIIGlzIHRoZSByZXNw b25zaWJpbGl0eSBvZiBhbiBTRkYgYW5kL29yIHJlLWNsYXNzaWZpZXIgKHNlZSBzZWN0aW9uIDQs IGJ1bGxldCBwb2ludCAxIGZvciB0aGUgcmVsZXZhbnQgdGV4dCkuDQoNClRoZSBTRiByZXNwb25z aWJpbGl0eSBpcyBzaW1wbHkgdG8gZGVjcmVtZW50IHRoZSBTSSBieSBhIHZhbHVlIG9mIDEuDQoN CkppbQ0KDQpGcm9tOiBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKSBbbWFpbHRvOmFuZHJl dy5kb2xnYW5vd0Bub2tpYS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3 IDg6NTEgUE0NClRvOiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+OyBFcmljIEMg Um9zZW4gPGVyb3NlbkBqdW5pcGVyLm5ldD47IEphbWVzIE4gR3VpY2hhcmQgPGphbWVzLm4uZ3Vp Y2hhcmRAaHVhd2VpLmNvbT47IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIE5TSCBT ZXJ2aWNlIEluZGV4IERlY3JlbWVudA0KDQpJIGFzc3VtZWQgdGhhdCBpZiB3ZSBnZXQgdmFsdWUg MSB3ZSBwcm9jZXNzIHRoZW4gZm9yd2FyZCB3aXRob3V0IE5TSCBoZWFkZXIgKGkuZS4pIHRoaXMg aXMgdGhlIGxhc3QgU0YgcHJvY2Vzc2luZy4NCg0KU28gd2l0aCB0aGF0IGFzc3VtcHRpb24sIGEg bW9yZSBleHBsaWNpdCB0ZXh0IHdvdWxkIGJlOg0KDQpBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2 aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAx IGFmdGVyIHBlcmZvcm1pbmcgYWxsIHJlcXVpcmVkIGxvY2FsIHByb2Nlc3NpbmcgYW5kIGJlZm9y ZSBmb3J3YXJkaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGLiBJZiB0aGUgcmVzdWx0aW5n IFNJIGlzIDAsIHRoZSBTRiBNVVNUIHJlbW92ZSB0aGUgTlNIIGhlYWRlciBiZWZvcmUgZm9yd2Fy ZGluZyB0aGUgcGFja2V0Lg0KDQpBbmRyZXcNCkZyb206IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERhdmUgRG9sc29u IDxkZG9sc29uQHNhbmR2aW5lLmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+Pg0KRGF0 ZTogVGh1cnNkYXksIEZlYnJ1YXJ5IDksIDIwMTcgYXQgMjowNCBBTQ0KVG86IEVyaWMgUm9zZW4g PGVyb3NlbkBqdW5pcGVyLm5ldDxtYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0Pj4sIEphbWVzIE4g R3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWlj aGFyZEBodWF3ZWkuY29tPj4sICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10gTlNI IFNlcnZpY2UgSW5kZXggRGVjcmVtZW50DQoNCkVyaWMsDQpJIHdhcyBuZXZlciBxdWl0ZSBoYXBw eSB3aXRoIHRoZSBvdXRjb21lIHRoYXQgbmVpdGhlciAwIG5vciAxIGlzIGEgdmFsaWQgU0kuDQoo QmVjYXVzZSBpZiByZWNlaXZlZCB3aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRlY3JlbWVudGVkIGFu ZCBkaXNjYXJkZWQuKQ0KDQpJdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2YWx1ZS4NCg0KSSBn dWVzcyBJ4oCZbSBpbnRlcmVzdGVkIHRvIGtub3cgaWYgdGhhdCBpcyBpbXBvcnRhbnQgdG8gb3Ro ZXIgaW1wbGVtZW50ZXJzLCBvciBpZiB0aGF0IHdhcyBldmVuIHRoZSBpbnRlbnRpb24/DQoNCg0K LURhdmUNCg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgRXJpYyBDIFJvc2VuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3 IDExOjUzIEFNDQpUbzogSmFtZXMgTiBHdWljaGFyZDsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50 DQoNCk9uIDIvNy8yMDE3IDI6MjQgUE0sIEphbWVzIE4gR3VpY2hhcmQgd3JvdGU6DQoNCkEgcmVx dWVzdCB3YXMgbWFkZSB0byBiZSBtb3JlIHNwZWNpZmljIGFuZCB1cGRhdGUgdGhlIHRleHQgYXMg Zm9sbG93czoNCg0K4oCcU2VydmljZSBpbmRleCBNVVNUIGJlIGRlY3JlbWVudGVkIGJ5IGEgdmFs dWUgb2YgMSBieSBTZXJ2aWNlIEZ1bmN0aW9ucyBvciBieSBTRkMgUHJveHkgbm9kZXMgYWZ0ZXIg cGVyZm9ybWluZyByZXF1aXJlZCBzZXJ2aWNlcyDigKbigJ0NCg0KQSBjb3VwbGUgb2Ygb2JzZXJ2 YXRpb25zOg0KDQotIFRoZSB0ZXJtICJTRkMgUHJveHkgbm9kZSIgaXMgbm90IGRlZmluZWQgaW4g ZWl0aGVyIHRoZSBOU0ggZHJhZnQgb3IgaW4gUkZDIDc2NjUuICBJIHRoaW5rIHRoZSBpbnRlbnRp b24gaGVyZSBpcyB0byBzYXkgIlNGQyBQcm94eSIuDQoNCi0gSXMgdGhlIGludGVudGlvbiB0aGF0 IHRoZSBTSSByZW1haW4gdW5jaGFuZ2VkIHdoaWxlIHRoZSBTRiBpcyBvcGVyYXRpbmcgb24gdGhl IHBhY2tldCwgb3IgaXMgdGhlIGludGVudGlvbiBvbmx5IHRoYXQgdGhlIFNJIGJlIGRlY3JlbWVu dGVkIGJlZm9yZSB0aGUgcGFja2V0IGlzIGRlbGl2ZXJlZCBieSB0aGUgU0Ygb3IgU0ZDIFByb3h5 IHRvIGFuIFNGRj8NCg0KSSdkIHN1Z2dlc3QgZWl0aGVyOg0KDQoiQW4gU0Ygb3IgU0ZDIFByb3h5 IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUg U0kgYnkgMSBiZWZvcmUgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRiINCg0K b3INCg0KIkFuIFNGIG9yIFNGQyBQcm94eSByZWNlaXZpbmcgYW4gTlNILWVuY2Fwc3VsYXRlZCBw YWNrZXQgTVVTVCBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEgYmVmb3JlIGRlbGl2ZXJpbmcgdGhlIHBh Y2tldCB0byB0aGUgbmV4dCBTRkYsIGJ1dCBub3QgdW50aWwgdGhlIFNGIGhhcyBmaW5pc2hlZCBh bGwgaXRzIG90aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBhY2tldCINCg0KZGVwZW5kaW5nIHVwb24g d2hpY2ggaXMgaW50ZW5kZWQuDQoNCkkgdGhpbmsgYW4gaW1wbGljYXRpb24gb2YgdGhlc2UgcHJv Y2VkdXJlcyBpcyB0aGF0IGFuIFNJIHZhbHVlIG9mIDEgaXMgbm90IHZhbGlkLiAgSWYgYW4gU0Yg Z2V0cyBhbiBOU0ggcGFja2V0IHdpdGggYW4gU0kgb2YgMSwgdGhlIFNGIHdpbGwgZGVjcmVtZW50 IHRoZSBTSSAoc2V0dGluZyBpdCB0byAwKSwgc2VuZCB0aGUgcGFja2V0IHRvIGFuIFNGRiwgYW5k IHRoZSBTRkYgd2lsbCBkaXNjYXJkIGl0LCBiZWNhdXNlIDAgaXMgYW4gaW52YWxpZCBTSSB2YWx1 ZS4gIElzIHRoYXQgdGhlIGludGVudGlvbj8NCg0KVGhlIGRyYWZ0IG1ha2VzIGl0IGNsZWFyICh3 ZWxsLCBzb3J0IG9mKSB0aGF0IGFuIFNGRiBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCB3aXRoIGFu IFNJIG9mIDAsIGJ1dCBkb2VzIG5vdCBzZWVtIHRvIHNheSB0aGF0IGFuIFNGIG9yIFNGQyBQcm94 eSBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCBpdCByZWNlaXZlcyB3aXRoIGFuIFNJIG9mIDAuICBJ dCB3b3VsZCBwcm9iYWJseSBiZSBhIGdvb2QgaWRlYSB0byBzYXkgdGhhdC4NCg0KU29tZSB0ZXh0 IGluIHRoZSBkcmFmdCAoZS5nLiwgc2VjdGlvbiA3LjEpIHN0YXRlcyB0aGFuIGFuIFNGRiBzaG91 bGQgZGlzY2FyZCBhIHBhY2tldCB3aXRoIGFuIFNJIG9mIHplcm8sIGJ1dCBvdGhlciB0ZXh0IGlu IHRoZSBkcmFmdCAoZS5nLiwgc2VjdGlvbiAzLjMpIG9ubHkgc2F5cyB0aGF0IGFuIFNGRiBzaG91 bGQgbG9nIGFuIGVycm9yIGlmIGl0IHNlZXMgYW4gU0kgb2YgemVyby4gIEl0J3MgcHJvYmFibHkg YmVzdCB0byBjaGFuZ2UgdGhlIHRleHQgaW4gMy4zLiB0byBzYXkgIlNIT1VMRCBnZW5lcmF0ZSBh biBlcnJvci9sb2cgbWVzc2FnZSBhbmQgTVVTVCBkaXNjYXJkIHRoZSBwYWNrZXQiLCBvciBzb21l dGhpbmcgc2ltaWxhci4NCg0K --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB6868SJCEML701CHMchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBBbmRyZXcsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgbGFzdCBzZW50ZW5jZSBpcyBpbmNv cnJlY3QgYXMgdGhlIGN1cnJlbnQgYXJjaGl0ZWN0dXJlIHNwZWNpZmllcyB0aGF0IHJlbW92YWwg b2YgTlNIIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBhbiBTRkYgYW5kL29yIHJlLWNsYXNzaWZp ZXIgKHNlZSBzZWN0aW9uIDQsDQogYnVsbGV0IHBvaW50IDEgZm9yIHRoZSByZWxldmFudCB0ZXh0 KS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUg U0YgcmVzcG9uc2liaWxpdHkgaXMgc2ltcGx5IHRvIGRlY3JlbWVudCB0aGUgU0kgYnkgYSB2YWx1 ZSBvZiAxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmltDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBEb2xnYW5v dywgQW5kcmV3IChOb2tpYSAtIFNHKSBbbWFpbHRvOmFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyA4OjUxIFBN PGJyPg0KPGI+VG86PC9iPiBEYXZlIERvbHNvbiAmbHQ7ZGRvbHNvbkBzYW5kdmluZS5jb20mZ3Q7 OyBFcmljIEMgUm9zZW4gJmx0O2Vyb3NlbkBqdW5pcGVyLm5ldCZndDs7IEphbWVzIE4gR3VpY2hh cmQgJmx0O2phbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbSZndDs7IHNmY0BpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPkkgYXNzdW1lZCB0aGF0IGlmIHdlIGdldCB2YWx1ZSAxIHdl IHByb2Nlc3MgdGhlbiBmb3J3YXJkIHdpdGhvdXQgTlNIIGhlYWRlciAoaS5lLikgdGhpcyBpcyB0 aGUgbGFzdCBTRiBwcm9jZXNzaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dCI+U28gd2l0aCB0aGF0IGFzc3VtcHRpb24sIGEgbW9yZSBleHBsaWNpdCB0 ZXh0IHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+QW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBh Y2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBhZnRlciBwZXJmb3JtaW5nIGFsbCByZXF1 aXJlZCBsb2NhbCBwcm9jZXNzaW5nIGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUNCiBwYWNrZXQg dG8gdGhlIG5leHQgU0ZGLiBJZiB0aGUgcmVzdWx0aW5nIFNJIGlzIDAsIHRoZSBTRiBNVVNUIHJl bW92ZSB0aGUgTlNIIGhlYWRlciBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFja2V0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+QW5kcmV3PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnNmYyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEYXZlIERvbHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRkb2xzb25Ac2FuZHZpbmUuY29tIj5kZG9sc29uQHNhbmR2aW5lLmNvbTwvYT4mZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPlRodXJzZGF5LCBGZWJydWFyeSA5LCAyMDE3IGF0IDI6MDQgQU08YnI+DQo8 Yj5UbzogPC9iPkVyaWMgUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplcm9zZW5AanVuaXBlci5u ZXQiPmVyb3NlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7LCBKYW1lcyBOIEd1aWNoYXJkICZsdDs8YSBo cmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tIj5qYW1lcy5uLmd1aWNoYXJk QGh1YXdlaS5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIE5TSCBT ZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVyaWMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JIHdhcyBuZXZlciBxdWl0ZSBoYXBweSB3aXRoIHRoZSBvdXRjb21l IHRoYXQgbmVpdGhlciAwIG5vciAxIGlzIGEgdmFsaWQgU0kuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4oQmVjYXVzZSBpZiByZWNlaXZlZCB3aXRoIHZhbHVlIG9m IDEsIGl0IGlzIGRlY3JlbWVudGVkIGFuZCBkaXNjYXJkZWQuKTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2YWx1ZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyBJ4oCZbSBpbnRlcmVzdGVkIHRv IGtub3cgaWYgdGhhdCBpcyBpbXBvcnRhbnQgdG8gb3RoZXIgaW1wbGVtZW50ZXJzLCBvciBpZiB0 aGF0IHdhcyBldmVuIHRoZSBpbnRlbnRpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ LURhdmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgQyBSb3Nlbjxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3IDExOjUzIEFNPGJy Pg0KPGI+VG86PC9iPiBKYW1lcyBOIEd1aWNoYXJkOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBOU0gg U2VydmljZSBJbmRleCBEZWNyZW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4t bGVmdDouNWluIj4NCk9uIDIvNy8yMDE3IDI6MjQgUE0sIEphbWVzIE4gR3VpY2hhcmQgd3JvdGU6 PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6LjVpbiI+DQpBIHJlcXVlc3Qgd2FzIG1hZGUgdG8gYmUgbW9yZSBzcGVjaWZpYyBhbmQg dXBkYXRlIHRoZSB0ZXh0IGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCuKAnFNlcnZpY2UgaW5kZXggTVVT VCBiZSBkZWNyZW1lbnRlZCA8Yj5ieSBhIHZhbHVlIG9mIDE8L2I+IGJ5IFNlcnZpY2UgRnVuY3Rp b25zIG9yIGJ5IFNGQyBQcm94eSBub2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZp Y2VzIOKApuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBw dDttYXJnaW4tbGVmdDouNWluIj4NCjxicj4NCkEgY291cGxlIG9mIG9ic2VydmF0aW9uczo8YnI+ DQo8YnI+DQotIFRoZSB0ZXJtICZxdW90O1NGQyBQcm94eSBub2RlJnF1b3Q7IGlzIG5vdCBkZWZp bmVkIGluIGVpdGhlciB0aGUgTlNIIGRyYWZ0IG9yIGluIFJGQyA3NjY1LiZuYnNwOyBJIHRoaW5r IHRoZSBpbnRlbnRpb24gaGVyZSBpcyB0byBzYXkgJnF1b3Q7U0ZDIFByb3h5JnF1b3Q7Ljxicj4N Cjxicj4NCi0gSXMgdGhlIGludGVudGlvbiB0aGF0IHRoZSBTSSByZW1haW4gdW5jaGFuZ2VkIHdo aWxlIHRoZSBTRiBpcyBvcGVyYXRpbmcgb24gdGhlIHBhY2tldCwgb3IgaXMgdGhlIGludGVudGlv biBvbmx5IHRoYXQgdGhlIFNJIGJlIGRlY3JlbWVudGVkIGJlZm9yZSB0aGUgcGFja2V0IGlzIGRl bGl2ZXJlZCBieSB0aGUgU0Ygb3IgU0ZDIFByb3h5IHRvIGFuIFNGRj8NCjxicj4NCjxicj4NCkkn ZCBzdWdnZXN0IGVpdGhlcjo8YnI+DQo8YnI+DQomcXVvdDtBbiBTRiBvciBTRkMgUHJveHkgcmVj ZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBi eSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGJnF1b3Q7PGJy Pg0KPGJyPg0Kb3I8YnI+DQo8YnI+DQomcXVvdDtBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5n IGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJl Zm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGLCBidXQgbm90IHVudGls IHRoZSBTRiBoYXMgZmluaXNoZWQgYWxsIGl0cyBvdGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNr ZXQmcXVvdDs8YnI+DQo8YnI+DQpkZXBlbmRpbmcgdXBvbiB3aGljaCBpcyBpbnRlbmRlZC48YnI+ DQo8YnI+DQpJIHRoaW5rIGFuIGltcGxpY2F0aW9uIG9mIHRoZXNlIHByb2NlZHVyZXMgaXMgdGhh dCBhbiBTSSB2YWx1ZSBvZiAxIGlzIG5vdCB2YWxpZC4mbmJzcDsgSWYgYW4gU0YgZ2V0cyBhbiBO U0ggcGFja2V0IHdpdGggYW4gU0kgb2YgMSwgdGhlIFNGIHdpbGwgZGVjcmVtZW50IHRoZSBTSSAo c2V0dGluZyBpdCB0byAwKSwgc2VuZCB0aGUgcGFja2V0IHRvIGFuIFNGRiwgYW5kIHRoZSBTRkYg d2lsbCBkaXNjYXJkIGl0LCBiZWNhdXNlIDAgaXMgYW4gaW52YWxpZCBTSQ0KIHZhbHVlLiZuYnNw OyBJcyB0aGF0IHRoZSBpbnRlbnRpb24/PGJyPg0KPGJyPg0KVGhlIGRyYWZ0IG1ha2VzIGl0IGNs ZWFyICh3ZWxsLCBzb3J0IG9mKSB0aGF0IGFuIFNGRiBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCB3 aXRoIGFuIFNJIG9mIDAsIGJ1dCBkb2VzIG5vdCBzZWVtIHRvIHNheSB0aGF0IGFuIFNGIG9yIFNG QyBQcm94eSBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCBpdCByZWNlaXZlcyB3aXRoIGFuIFNJIG9m IDAuJm5ic3A7IEl0IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIHNheSB0aGF0Ljxi cj4NCjxicj4NClNvbWUgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNlY3Rpb24gNy4xKSBzdGF0 ZXMgdGhhbiBhbiBTRkYgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQgd2l0aCBhbiBTSSBvZiB6ZXJv LCBidXQgb3RoZXIgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNlY3Rpb24gMy4zKSBvbmx5IHNh eXMgdGhhdCBhbiBTRkYgc2hvdWxkIGxvZyBhbiBlcnJvciBpZiBpdCBzZWVzIGFuIFNJIG9mIHpl cm8uJm5ic3A7IEl0J3MgcHJvYmFibHkgYmVzdCB0byBjaGFuZ2UgdGhlIHRleHQNCiBpbiAzLjMu IHRvIHNheSAmcXVvdDtTSE9VTEQgZ2VuZXJhdGUgYW4gZXJyb3IvbG9nIG1lc3NhZ2UgYW5kIE1V U1QgZGlzY2FyZCB0aGUgcGFja2V0JnF1b3Q7LCBvciBzb21ldGhpbmcgc2ltaWxhci48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB6868SJCEML701CHMchina_-- From nobody Thu Feb 9 08:25:42 2017 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 50BEB129B93 for ; Thu, 9 Feb 2017 08:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 ceVLxvEwHgB4 for ; Thu, 9 Feb 2017 08:25:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF345129B8E for ; Thu, 9 Feb 2017 08:25:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAH60804; Thu, 09 Feb 2017 16:25:33 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 9 Feb 2017 16:25:32 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Thu, 9 Feb 2017 08:25:26 -0800 From: James N Guichard To: Fabricio Ferraz , "Dolganow, Andrew (Nokia - SG)" , Dave Dolson , "Eric C Rosen" , "sfc@ietf.org" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNA= Date: Thu, 9 Feb 2017 16:25:25 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.56] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB687CSJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.589C97FE.01F9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4d81cfe7ba5a2cd3e08d723a0d90cf99 Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:25:41 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB687CSJCEML701CHMchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRmFicmljaW8sDQoNCldlbGNvbWUhDQoNClllcywgcmVtb3ZhbCBvZiBOU0ggaXMgdGhlIHJl c3BvbnNpYmlsaXR5IG9mIGFuIFNGRiBvciBhIHJlLWNsYXNzaWZpZXIgKHNlY3Rpb24gNCwgYnVs bGV0IHBvaW50IDEgbGF5cyB0aGlzIG91dCkuIFdpdGggdGhlIGN1cnJlbnQgYXJjaGl0ZWN0dXJl IHRoZSBTRiBkb2VzIG5vdCBjYXJlIHdoYXQgU0kgdmFsdWUgaXQgZ2V0cywgaXQganVzdCBuZWVk cyB0byB3b3JyeSBhYm91dCBkZWNyZW1lbnRpbmcgaXQsIGFuZCBsZWF2ZSBpdCB1cCB0byB0aGUg U0ZGIHRvIGV2YWx1YXRlIHRoZSBTSSB2YWx1ZSBhbmQgYXNzb2NpYXRlZCBhY3Rpb24uDQoNCkpp bQ0KDQpGcm9tOiBGYWJyaWNpbyBGZXJyYXogW21haWx0bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNv bS5wdF0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyA3OjEzIEFNDQpUbzogRG9s Z2Fub3csIEFuZHJldyAoTm9raWEgLSBTRykgPGFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+OyBE YXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+OyBFcmljIEMgUm9zZW4gPGVyb3NlbkBq dW5pcGVyLm5ldD47IEphbWVzIE4gR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNv bT47IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERl Y3JlbWVudA0KDQpIaSBhbGwsDQpJ4oCZbSBuZXcgaGVyZSAoanVzdCByZWFkIHRoZSBkcmFmdCBs YXN0IHdlZWspIGJ1dCBhY2NvcmRpbmcgdG8gY2hhcHRlciA0IChjaGVjayBmaWd1cmUgOCBmb3Ig ZXhhbXBsZSksIGFuIFNGIGlzIG5vdCBhbGxvd2VkIHRvIGluc2VydCBvciByZW1vdmUgTlNILiBU aGUgcmVtb3ZhbCBvZiBOU0ggaXMgcmVwb25zYWJpbGl0eSBvZiB0aGUgU1NGLCByaWdodD8NCg0K ICBGaWd1cmUgOCBtYXBzIGVhY2ggb2YgdGhlIGZvdXIgYWN0aW9ucyBhYm92ZSB0byB0aGUgY29t cG9uZW50cyBpbiB0aGUNCiAgIFNGQyBhcmNoaXRlY3R1cmUgdGhhdCBjYW4gcGVyZm9ybSBpdC4N Cg0KKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLSsNCnwgICAgICAgICAgICAgICAgfCAgSW5zZXJ0ICAgICAgICAgfFNl bGVjdCB8ICAgVXBkYXRlICAgICAgIHxTZXJ2aWNlICB8DQp8ICAgICAgICAgICAgICAgIHwgIG9y IHJlbW92ZSBOU0ggIHxTZXJ2aWNlfCAgICBOU0ggICAgICAgICB8cG9saWN5ICAgfA0KfCAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8RnVuY3Rpb258ICAgICAgICAgICAgICAgfHNl bGVjdGlvbnwNCnwgQ29tcG9uZW50ICAgICAgKy0tLS0tLS0tKy0tLS0tLS0tK1BhdGggICArLS0t LS0tLS0tLS0tLS0tLSsgICAgICAgICB8DQp8ICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAg ICAgIHwgICAgICAgfCBEZWMuICAgfFVwZGF0ZSB8ICAgICAgICAgfA0KfCAgICAgICAgICAgICAg ICB8IEluc2VydCB8IFJlbW92ZSB8ICAgICAgIHxTZXJ2aWNlIHxDb250ZXh0fCAgICAgICAgIHwN CnwgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8IEluZGV4ICB8SGVh ZGVyIHwgICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0t LS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tKw0KfCAgICAgICAgICAgICAgICB8ICAgKyAg ICB8ICAgKyAgICB8ICAgICAgIHwgICAgICAgIHwgICArICAgfCAgICAgICAgIHwNCnxDbGFzc2lm aWVyICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICB8ICAgICAgIHwgICAg ICAgICB8DQorLS0tLS0tLS0tLS0tLS0tICstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0t LS0tKy0tLS0tLS0rLS0tLS0tLS0tKw0KfFNlcnZpY2UgRnVuY3Rpb258ICAgICAgICB8ICAgKyAg ICB8ICArICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICAgIHwNCnxGb3J3YXJkZXIoU0ZGKSAg fCAgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICB8ICAgICAgIHwgICAgICAgICB8DQor LS0tLS0tLS0tLS0tLS0tICstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0t LS0rLS0tLS0tLS0tKw0KfFNlcnZpY2UgICAgICAgICB8ICAgICAgICB8ICAgICAgICB8ICAgICAg IHwgICArICAgIHwgICArICAgfCAgICsgICAgIHwNCnxGdW5jdGlvbiAgKFNGKSAgfCAgICAgICAg fCAgICAgICAgfCAgICAgICB8ICAgICAgICB8ICAgICAgIHwgICAgICAgICB8DQorLS0tLS0tLS0t LS0tLS0tICstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0t LS0tKw0KfFNGQyBQcm94eSAgICAgICB8ICAgKyAgICB8ICAgKyAgICB8ICAgICAgIHwgICArICAg IHwgICAgICAgfCAgICAgICAgIHwNCistLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0t Ky0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAg ICBGaWd1cmUgODogTlNIIEFjdGlvbiBhbmQgUm9sZSBNYXBwaW5nDQoNCg0KQW4gU0YgY291bGQg cmVjZWl2ZSBhbiBOU0ggcGFja2V0IHdpdGggYW4gU0kgb2YgMSwgYW5kIHJlY2xhc3NpZnkgaXQg dG8gYSBkaWZmZXJlbnQgU1BJIGFuZCBTSSwgcmlnaHQ/IFNvIHdoZW4gYSBTRiByZWNlaXZlcyBh IE5TSCBwYWNrZXQgd2l0aCBTSSA9IDEgdGhhdCBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFucyBh IG5vbiB2YWxpZCBwYWNrZXQuDQpBbmQgdGhhdCBjYW4gZXZlbiB3b3JrIGZvciBTST0wLCBzaW5j ZSB5b3UgZGVjcmVtZW50IHRoZSBTSSBpbiB0aGUgZWdyZXNzLg0KDQpGYWJyaWNpbw0KDQoNCkZy b206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRG9sZ2Fu b3csIEFuZHJldyAoTm9raWEgLSBTRykNClNlbnQ6IHF1aW50YS1mZWlyYSwgOSBkZSBmZXZlcmVp cm8gZGUgMjAxNyAwMTo1MQ0KVG86IERhdmUgRG9sc29uOyBFcmljIEMgUm9zZW47IEphbWVzIE4g R3VpY2hhcmQ7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudA0KDQpJIGFzc3VtZWQgdGhhdCBpZiB3 ZSBnZXQgdmFsdWUgMSB3ZSBwcm9jZXNzIHRoZW4gZm9yd2FyZCB3aXRob3V0IE5TSCBoZWFkZXIg KGkuZS4pIHRoaXMgaXMgdGhlIGxhc3QgU0YgcHJvY2Vzc2luZy4NCg0KU28gd2l0aCB0aGF0IGFz c3VtcHRpb24sIGEgbW9yZSBleHBsaWNpdCB0ZXh0IHdvdWxkIGJlOg0KDQpBbiBTRiBvciBTRkMg UHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50 IHRoZSBTSSBieSAxIGFmdGVyIHBlcmZvcm1pbmcgYWxsIHJlcXVpcmVkIGxvY2FsIHByb2Nlc3Np bmcgYW5kIGJlZm9yZSBmb3J3YXJkaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGLiBJZiB0 aGUgcmVzdWx0aW5nIFNJIGlzIDAsIHRoZSBTRiBNVVNUIHJlbW92ZSB0aGUgTlNIIGhlYWRlciBi ZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFja2V0Lg0KDQpBbmRyZXcNCkZyb206IHNmYyA8c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmlu ZS5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIEZlYnJ1YXJ5IDksIDIwMTcgYXQgMjowNCBBTQ0KVG86 IEVyaWMgUm9zZW4gPGVyb3NlbkBqdW5pcGVyLm5ldDxtYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0 Pj4sIEphbWVzIE4gR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbTxtYWlsdG86 amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPj4sICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50DQoNCkVyaWMsDQpJIHdhcyBuZXZl ciBxdWl0ZSBoYXBweSB3aXRoIHRoZSBvdXRjb21lIHRoYXQgbmVpdGhlciAwIG5vciAxIGlzIGEg dmFsaWQgU0kuDQooQmVjYXVzZSBpZiByZWNlaXZlZCB3aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRl Y3JlbWVudGVkIGFuZCBkaXNjYXJkZWQuKQ0KDQpJdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2 YWx1ZS4NCg0KSSBndWVzcyBJ4oCZbSBpbnRlcmVzdGVkIHRvIGtub3cgaWYgdGhhdCBpcyBpbXBv cnRhbnQgdG8gb3RoZXIgaW1wbGVtZW50ZXJzLCBvciBpZiB0aGF0IHdhcyBldmVuIHRoZSBpbnRl bnRpb24/DQoNCg0KLURhdmUNCg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBDIFJvc2VuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDA4LCAyMDE3IDExOjUzIEFNDQpUbzogSmFtZXMgTiBHdWljaGFyZDsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5k ZXggRGVjcmVtZW50DQoNCk9uIDIvNy8yMDE3IDI6MjQgUE0sIEphbWVzIE4gR3VpY2hhcmQgd3Jv dGU6DQpBIHJlcXVlc3Qgd2FzIG1hZGUgdG8gYmUgbW9yZSBzcGVjaWZpYyBhbmQgdXBkYXRlIHRo ZSB0ZXh0IGFzIGZvbGxvd3M6DQoNCuKAnFNlcnZpY2UgaW5kZXggTVVTVCBiZSBkZWNyZW1lbnRl ZCBieSBhIHZhbHVlIG9mIDEgYnkgU2VydmljZSBGdW5jdGlvbnMgb3IgYnkgU0ZDIFByb3h5IG5v ZGVzIGFmdGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQgc2VydmljZXMg4oCm4oCdDQoNCkEgY291cGxl IG9mIG9ic2VydmF0aW9uczoNCg0KLSBUaGUgdGVybSAiU0ZDIFByb3h5IG5vZGUiIGlzIG5vdCBk ZWZpbmVkIGluIGVpdGhlciB0aGUgTlNIIGRyYWZ0IG9yIGluIFJGQyA3NjY1LiAgSSB0aGluayB0 aGUgaW50ZW50aW9uIGhlcmUgaXMgdG8gc2F5ICJTRkMgUHJveHkiLg0KDQotIElzIHRoZSBpbnRl bnRpb24gdGhhdCB0aGUgU0kgcmVtYWluIHVuY2hhbmdlZCB3aGlsZSB0aGUgU0YgaXMgb3BlcmF0 aW5nIG9uIHRoZSBwYWNrZXQsIG9yIGlzIHRoZSBpbnRlbnRpb24gb25seSB0aGF0IHRoZSBTSSBi ZSBkZWNyZW1lbnRlZCBiZWZvcmUgdGhlIHBhY2tldCBpcyBkZWxpdmVyZWQgYnkgdGhlIFNGIG9y IFNGQyBQcm94eSB0byBhbiBTRkY/DQoNCkknZCBzdWdnZXN0IGVpdGhlcjoNCg0KIkFuIFNGIG9y IFNGQyBQcm94eSByZWNlaXZpbmcgYW4gTlNILWVuY2Fwc3VsYXRlZCBwYWNrZXQgTVVTVCBkZWNy ZW1lbnQgdGhlIFNJIGJ5IDEgYmVmb3JlIGRlbGl2ZXJpbmcgdGhlIHBhY2tldCB0byB0aGUgbmV4 dCBTRkYiDQoNCm9yDQoNCiJBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNh cHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVy aW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGLCBidXQgbm90IHVudGlsIHRoZSBTRiBoYXMg ZmluaXNoZWQgYWxsIGl0cyBvdGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQiDQoNCmRlcGVu ZGluZyB1cG9uIHdoaWNoIGlzIGludGVuZGVkLg0KDQpJIHRoaW5rIGFuIGltcGxpY2F0aW9uIG9m IHRoZXNlIHByb2NlZHVyZXMgaXMgdGhhdCBhbiBTSSB2YWx1ZSBvZiAxIGlzIG5vdCB2YWxpZC4g IElmIGFuIFNGIGdldHMgYW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIHRoZSBTRiB3aWxs IGRlY3JlbWVudCB0aGUgU0kgKHNldHRpbmcgaXQgdG8gMCksIHNlbmQgdGhlIHBhY2tldCB0byBh biBTRkYsIGFuZCB0aGUgU0ZGIHdpbGwgZGlzY2FyZCBpdCwgYmVjYXVzZSAwIGlzIGFuIGludmFs aWQgU0kgdmFsdWUuICBJcyB0aGF0IHRoZSBpbnRlbnRpb24/DQoNClRoZSBkcmFmdCBtYWtlcyBp dCBjbGVhciAod2VsbCwgc29ydCBvZikgdGhhdCBhbiBTRkYgc2hvdWxkIGRpc2NhcmQgYSBwYWNr ZXQgd2l0aCBhbiBTSSBvZiAwLCBidXQgZG9lcyBub3Qgc2VlbSB0byBzYXkgdGhhdCBhbiBTRiBv ciBTRkMgUHJveHkgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQgaXQgcmVjZWl2ZXMgd2l0aCBhbiBT SSBvZiAwLiAgSXQgd291bGQgcHJvYmFibHkgYmUgYSBnb29kIGlkZWEgdG8gc2F5IHRoYXQuDQoN ClNvbWUgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNlY3Rpb24gNy4xKSBzdGF0ZXMgdGhhbiBh biBTRkYgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQgd2l0aCBhbiBTSSBvZiB6ZXJvLCBidXQgb3Ro ZXIgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNlY3Rpb24gMy4zKSBvbmx5IHNheXMgdGhhdCBh biBTRkYgc2hvdWxkIGxvZyBhbiBlcnJvciBpZiBpdCBzZWVzIGFuIFNJIG9mIHplcm8uICBJdCdz IHByb2JhYmx5IGJlc3QgdG8gY2hhbmdlIHRoZSB0ZXh0IGluIDMuMy4gdG8gc2F5ICJTSE9VTEQg Z2VuZXJhdGUgYW4gZXJyb3IvbG9nIG1lc3NhZ2UgYW5kIE1VU1QgZGlzY2FyZCB0aGUgcGFja2V0 Iiwgb3Igc29tZXRoaW5nIHNpbWlsYXIuDQo= --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB687CSJCEML701CHMchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBG YWJyaWNpbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlbGNv bWUhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXMsIHJlbW92 YWwgb2YgTlNIIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBhbiBTRkYgb3IgYSByZS1jbGFzc2lm aWVyIChzZWN0aW9uIDQsIGJ1bGxldCBwb2ludCAxIGxheXMgdGhpcyBvdXQpLiBXaXRoIHRoZSBj dXJyZW50IGFyY2hpdGVjdHVyZSB0aGUgU0YgZG9lcyBub3QNCiBjYXJlIHdoYXQgU0kgdmFsdWUg aXQgZ2V0cywgaXQganVzdCBuZWVkcyB0byB3b3JyeSBhYm91dCBkZWNyZW1lbnRpbmcgaXQsIGFu ZCBsZWF2ZSBpdCB1cCB0byB0aGUgU0ZGIHRvIGV2YWx1YXRlIHRoZSBTSSB2YWx1ZSBhbmQgYXNz b2NpYXRlZCBhY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5KaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBG YWJyaWNpbyBGZXJyYXogW21haWx0bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdF0NCjxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMDksIDIwMTcgNzoxMyBBTTxicj4NCjxi PlRvOjwvYj4gRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRykgJmx0O2FuZHJldy5kb2xnYW5v d0Bub2tpYS5jb20mZ3Q7OyBEYXZlIERvbHNvbiAmbHQ7ZGRvbHNvbkBzYW5kdmluZS5jb20mZ3Q7 OyBFcmljIEMgUm9zZW4gJmx0O2Vyb3NlbkBqdW5pcGVyLm5ldCZndDs7IEphbWVzIE4gR3VpY2hh cmQgJmx0O2phbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbSZndDs7IHNmY0BpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IlBUIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5J4oCZbSBuZXcgaGVyZSAoanVzdCByZWFkIHRoZSBkcmFmdCBsYXN0IHdlZWspIGJ1dCBh Y2NvcmRpbmcgdG8gY2hhcHRlciA0IChjaGVjayBmaWd1cmUgOCBmb3IgZXhhbXBsZSksIGFuIFNG IGlzIG5vdCBhbGxvd2VkIHRvIGluc2VydCBvciByZW1vdmUgTlNILiBUaGUgcmVtb3ZhbA0KIG9m IE5TSCBpcyByZXBvbnNhYmlsaXR5IG9mIHRoZSBTU0YsIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjcuMHB0IDcuMHB0IDcuMHB0IDcuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZE RjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IEZpZ3VyZSA4IG1hcHMg ZWFjaCBvZiB0aGUgZm91ciBhY3Rpb25zIGFib3ZlIHRvIHRoZSBjb21wb25lbnRzIGluIHRoZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFNGQyBhcmNoaXRlY3R1cmUgdGhhdCBjYW4gcGVyZm9ybSBp dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29y ZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzstLS0tLS0tLS0tLS0tLS0mIzQzOy0t LS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0t LS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyBJbnNlcnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfFNlbGVjdCB8Jm5ic3A7Jm5ic3A7IFVwZGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8U2VydmljZSZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6 I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgb3IgcmVtb3ZlIE5TSCZuYnNwOyB8U2VydmljZXwm bmJzcDsmbmJzcDsmbmJzcDsgTlNIJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHxwb2xpY3kmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHxGdW5jdGlvbnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfHNlbGVjdGlvbnw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPnwgQ29tcG9uZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MztQYXRoJm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0t LS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCBEZWMuJm5ic3A7Jm5ic3A7IHxVcGRhdGUgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZG RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwgSW5zZXJ0IHwgUmVtb3ZlIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfFNlcnZpY2UgfENvbnRleHR8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZG REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBJbmRleCZuYnNwOyB8SGVhZGVyIHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVw dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0 MzstLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0m IzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVw dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4x NXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58 Q2xhc3NpZmllciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy ZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLS0tLS0tLSAmIzQzOy0tLS0t LS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQz Oy0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy ZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58U2VydmljZSBGdW5jdGlvbnwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPnxGb3J3YXJkZXIoU0ZGKSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFr OmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLS0tLS0tLSAmIzQzOy0tLS0tLS0t JiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0t LS0tLS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFr OmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58U2VydmljZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyAmIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tn cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58RnVuY3Rpb24m bmJzcDsgKFNGKSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mIzQzOy0tLS0tLS0tLS0tLS0tLSAmIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tLSYjNDM7LS0t LS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLSYjNDM7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij58U0ZDIFByb3h5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0t LS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0t JiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7 d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSA4OiBOU0ggQWN0aW9uIGFuZCBSb2xl IE1hcHBpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuIFNGIGNvdWxkIHJlY2VpdmUgYW4gTlNIIHBh Y2tldCB3aXRoIGFuIFNJIG9mIDEsIGFuZCByZWNsYXNzaWZ5IGl0IHRvIGEgZGlmZmVyZW50IFNQ SSBhbmQgU0ksIHJpZ2h0PyBTbyB3aGVuIGEgU0YgcmVjZWl2ZXMgYSBOU0ggcGFja2V0IHdpdGgg U0kgPSAxIHRoYXQgZG9lcw0KIG5vdCBuZWNlc3NhcmlseSBtZWFucyBhIG5vbiB2YWxpZCBwYWNr ZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCB0aGF0IGNhbiBldmVuIHdvcmsgZm9yIFNJPTAsIHNp bmNlIHlvdSBkZWNyZW1lbnQgdGhlIFNJIGluIHRoZSBlZ3Jlc3MuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5GYWJyaWNpbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+RG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRyk8YnI+DQo8Yj5TZW50Ojwv Yj4gcXVpbnRhLWZlaXJhLCA5IGRlIGZldmVyZWlybyBkZSAyMDE3IDAxOjUxPGJyPg0KPGI+VG86 PC9iPiBEYXZlIERvbHNvbjsgRXJpYyBDIFJvc2VuOyBKYW1lcyBOIEd1aWNoYXJkOyA8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJQVCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkkgYXNzdW1lZCB0aGF0IGlmIHdlIGdl dCB2YWx1ZSAxIHdlIHByb2Nlc3MgdGhlbiBmb3J3YXJkIHdpdGhvdXQgTlNIIGhlYWRlciAoaS5l LikgdGhpcyBpcyB0aGUgbGFzdCBTRiBwcm9jZXNzaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+U28gd2l0aCB0aGF0IGFzc3VtcHRpb24sIGEgbW9y ZSBleHBsaWNpdCB0ZXh0IHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+QW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5j YXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBhZnRlciBwZXJmb3Jt aW5nIGFsbCByZXF1aXJlZCBsb2NhbCBwcm9jZXNzaW5nIGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0 aGUNCiBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGLiBJZiB0aGUgcmVzdWx0aW5nIFNJIGlzIDAsIHRo ZSBTRiBNVVNUIHJlbW92ZSB0aGUgTlNIIGhlYWRlciBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFj a2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+QW5k cmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206DQo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPnNmYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEYXZlIERvbHNvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tIj5kZG9sc29uQHNhbmR2aW5lLmNvbTwv YT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBGZWJydWFyeSA5LCAyMDE3IGF0IDI6 MDQgQU08YnI+DQo8Yj5UbzogPC9iPkVyaWMgUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplcm9z ZW5AanVuaXBlci5uZXQiPmVyb3NlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7LCBKYW1lcyBOIEd1aWNo YXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tIj5qYW1l cy5uLmd1aWNoYXJkQGh1YXdlaS5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVyaWMsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHdhcyBuZXZlciBxdWl0ZSBoYXBweSB3aXRo IHRoZSBvdXRjb21lIHRoYXQgbmVpdGhlciAwIG5vciAxIGlzIGEgdmFsaWQgU0kuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4oQmVjYXVzZSBpZiByZWNlaXZlZCB3 aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRlY3JlbWVudGVkIGFuZCBkaXNjYXJkZWQuKTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2 YWx1ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyBJ4oCZbSBp bnRlcmVzdGVkIHRvIGtub3cgaWYgdGhhdCBpcyBpbXBvcnRhbnQgdG8gb3RoZXIgaW1wbGVtZW50 ZXJzLCBvciBpZiB0aGF0IHdhcyBldmVuIHRoZSBpbnRlbnRpb24/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+LURhdmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVy aWMgQyBSb3Nlbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3 IDExOjUzIEFNPGJyPg0KPGI+VG86PC9iPiBKYW1lcyBOIEd1aWNoYXJkOyA8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEy LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCk9uIDIvNy8yMDE3IDI6MjQgUE0sIEphbWVzIE4gR3Vp Y2hhcmQgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6LjVpbiI+DQpBIHJlcXVlc3Qgd2FzIG1hZGUgdG8gYmUgbW9yZSBzcGVjaWZpYyBhbmQg dXBkYXRlIHRoZSB0ZXh0IGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCuKAnFNlcnZpY2UgaW5kZXggTVVT VCBiZSBkZWNyZW1lbnRlZCA8Yj5ieSBhIHZhbHVlIG9mIDE8L2I+IGJ5IFNlcnZpY2UgRnVuY3Rp b25zIG9yIGJ5IFNGQyBQcm94eSBub2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZp Y2VzIOKApuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBw dDttYXJnaW4tbGVmdDouNWluIj4NCjxicj4NCkEgY291cGxlIG9mIG9ic2VydmF0aW9uczo8YnI+ DQo8YnI+DQotIFRoZSB0ZXJtICZxdW90O1NGQyBQcm94eSBub2RlJnF1b3Q7IGlzIG5vdCBkZWZp bmVkIGluIGVpdGhlciB0aGUgTlNIIGRyYWZ0IG9yIGluIFJGQyA3NjY1LiZuYnNwOyBJIHRoaW5r IHRoZSBpbnRlbnRpb24gaGVyZSBpcyB0byBzYXkgJnF1b3Q7U0ZDIFByb3h5JnF1b3Q7Ljxicj4N Cjxicj4NCi0gSXMgdGhlIGludGVudGlvbiB0aGF0IHRoZSBTSSByZW1haW4gdW5jaGFuZ2VkIHdo aWxlIHRoZSBTRiBpcyBvcGVyYXRpbmcgb24gdGhlIHBhY2tldCwgb3IgaXMgdGhlIGludGVudGlv biBvbmx5IHRoYXQgdGhlIFNJIGJlIGRlY3JlbWVudGVkIGJlZm9yZSB0aGUgcGFja2V0IGlzIGRl bGl2ZXJlZCBieSB0aGUgU0Ygb3IgU0ZDIFByb3h5IHRvIGFuIFNGRj8NCjxicj4NCjxicj4NCkkn ZCBzdWdnZXN0IGVpdGhlcjo8YnI+DQo8YnI+DQomcXVvdDtBbiBTRiBvciBTRkMgUHJveHkgcmVj ZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBi eSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGJnF1b3Q7PGJy Pg0KPGJyPg0Kb3I8YnI+DQo8YnI+DQomcXVvdDtBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5n IGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJl Zm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGLCBidXQgbm90IHVudGls IHRoZSBTRiBoYXMgZmluaXNoZWQgYWxsIGl0cyBvdGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNr ZXQmcXVvdDs8YnI+DQo8YnI+DQpkZXBlbmRpbmcgdXBvbiB3aGljaCBpcyBpbnRlbmRlZC48YnI+ DQo8YnI+DQpJIHRoaW5rIGFuIGltcGxpY2F0aW9uIG9mIHRoZXNlIHByb2NlZHVyZXMgaXMgdGhh dCBhbiBTSSB2YWx1ZSBvZiAxIGlzIG5vdCB2YWxpZC4mbmJzcDsgSWYgYW4gU0YgZ2V0cyBhbiBO U0ggcGFja2V0IHdpdGggYW4gU0kgb2YgMSwgdGhlIFNGIHdpbGwgZGVjcmVtZW50IHRoZSBTSSAo c2V0dGluZyBpdCB0byAwKSwgc2VuZCB0aGUgcGFja2V0IHRvIGFuIFNGRiwgYW5kIHRoZSBTRkYg d2lsbCBkaXNjYXJkIGl0LCBiZWNhdXNlIDAgaXMgYW4gaW52YWxpZCBTSQ0KIHZhbHVlLiZuYnNw OyBJcyB0aGF0IHRoZSBpbnRlbnRpb24/PGJyPg0KPGJyPg0KVGhlIGRyYWZ0IG1ha2VzIGl0IGNs ZWFyICh3ZWxsLCBzb3J0IG9mKSB0aGF0IGFuIFNGRiBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCB3 aXRoIGFuIFNJIG9mIDAsIGJ1dCBkb2VzIG5vdCBzZWVtIHRvIHNheSB0aGF0IGFuIFNGIG9yIFNG QyBQcm94eSBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCBpdCByZWNlaXZlcyB3aXRoIGFuIFNJIG9m IDAuJm5ic3A7IEl0IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIHNheSB0aGF0Ljxi cj4NCjxicj4NClNvbWUgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNlY3Rpb24gNy4xKSBzdGF0 ZXMgdGhhbiBhbiBTRkYgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQgd2l0aCBhbiBTSSBvZiB6ZXJv LCBidXQgb3RoZXIgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNlY3Rpb24gMy4zKSBvbmx5IHNh eXMgdGhhdCBhbiBTRkYgc2hvdWxkIGxvZyBhbiBlcnJvciBpZiBpdCBzZWVzIGFuIFNJIG9mIHpl cm8uJm5ic3A7IEl0J3MgcHJvYmFibHkgYmVzdCB0byBjaGFuZ2UgdGhlIHRleHQNCiBpbiAzLjMu IHRvIHNheSAmcXVvdDtTSE9VTEQgZ2VuZXJhdGUgYW4gZXJyb3IvbG9nIG1lc3NhZ2UgYW5kIE1V U1QgZGlzY2FyZCB0aGUgcGFja2V0JnF1b3Q7LCBvciBzb21ldGhpbmcgc2ltaWxhci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB687CSJCEML701CHMchina_-- From nobody Thu Feb 9 08:48:51 2017 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 75859129BD7 for ; Thu, 9 Feb 2017 08:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 3hNkgztT9LhJ for ; Thu, 9 Feb 2017 08:48:47 -0800 (PST) Received: from smtp2.telecom.pt (smtp2.telecom.pt [83.240.175.146]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1F2129BC0 for ; Thu, 9 Feb 2017 08:48:45 -0800 (PST) From: Fabricio Ferraz To: James N Guichard , "Dolganow, Andrew (Nokia - SG)" , Dave Dolson , "Eric C Rosen" , "sfc@ietf.org" Date: Thu, 9 Feb 2017 16:48:40 +0000 Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkA== Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> In-Reply-To: Accept-Language: pt-PT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT, en-US Content-Type: multipart/alternative; boundary="_000_CB8C08780539D74B9BE1ED5174662634D2D755333CPTPPICEX01PTP_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:48:49 -0000 --_000_CB8C08780539D74B9BE1ED5174662634D2D755333CPTPPICEX01PTP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLA0KVGhhbmtzLg0KDQpPbmUgbW9yZSBxdWVzdGlvbiBhYm91dCB0aGUgU0kuDQoNClNl Y3Rpb24gMyBzdGF0ZXMgdGhhdDoNCg0KU2VydmljZSBJbmRleCAoU0kpOiBwcm92aWRlcyBsb2Nh dGlvbiB3aXRoaW4gdGhlIFNGUC4gVGhlIGluaXRpYWwgY2xhc3NpZmllciBNVVNUIHNldCB0aGUg YXBwcm9wcmlhdGUgU0kgdmFsdWUgZm9yIGEgZ2l2ZW4gY2xhc3NpZmljYXRpb24gcmVzdWx0LiBU aGUgaW5pdGlhbCBTSSB2YWx1ZSBTSE9VTEQgZGVmYXVsdCB0byAyNTUuIEhvd2V2ZXIsIHRoZSBj bGFzc2lmaWVyIE1VU1QgYWxsb3cgY29uZmlndXJhdGlvbiBvZiBvdGhlciBTSSB2YWx1ZXMuDQpT ZXJ2aWNlIEluZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgYnkgU2VydmljZSBGdW5jdGlvbnMgb3Ig YnkgU0ZDIFByb3h5IG5vZGVzIGFmdGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQgc2VydmljZXMgYW5k IHRoZSBuZXcgZGVjcmVtZW50ZWQgU0kgdmFsdWUgTVVTVCBiZSB1c2VkIGluIHRoZSBlZ3Jlc3Mg TlNIIHBhY2tldC4NClRoZSBpbml0aWFsIENsYXNzaWZpZXIgTVVTVCBzZW5kIHRoZSBwYWNrZXQg dG8gdGhlIGZpcnN0IFNGRiBpbiB0aGUgaWRlbnRpZmllZCBTRlAgZm9yIGZvcndhcmRpbmcgYWxv bmcgYW4gU0ZQLg0KSWYgcmUtY2xhc3NpZmljYXRpb24gb2NjdXJzLCBhbmQgdGhhdCByZS1jbGFz c2lmaWNhdGlvbiByZXN1bHRzIGluIGEgbmV3IFNQSSwgdGhlIChyZSljbGFzc2lmaWVyIGlzLCBp biBlZmZlY3QsIHRoZSBpbml0aWFsIGNsYXNzaWZpZXIgZm9yIHRoZSByZXN1bHRhbnQgU1BJLg0K DQpUaHVzOg0KDQphKSAgICAgIEluaXRpYWwgU0kgdmFsdWUgc2hvdWxkIGJlIDI1NSBidXQgb3Ro ZXIgdmFsdWVzIGNhbiBiZSBjb25maWd1cmVkIGJ5IHRoZSBjbGFzc2lmaWVyLg0KDQpiKSAgICAg IFNGIGRlY3JlbWVudHMgdGhlIFNJIHZhbHVlIG9uIHRoZSBlZ3Jlc3MgTlNIIHBhY2tldA0KDQpj KSAgICAgICBJZiByZS1jbGFzc2lmaWNhdGlvbiBvY2N1cnMgd2l0aCBuZXcgU1BJLCB0aGUgcmUt Y2xhc3NpZmllciBpcyB0aGUgaW5pdGlhbCBjbGFzc2lmaWVyLCBzbyBieSAgYSksIFNJIHNob3Vs ZCBiZSBhZ2FpbiAyNTUgb3Igb3RoZXIgdmFsdWUNCg0KU28gYW55IFNJIHZhbHVlIGNhbiBiZSBy ZWNlaXZlIGJ5IGFuIFNGLCBldmVuIDEgb3IgMCBiZWNhdXNlOg0KDQrDqCBJZiBTST0xIGFuZCB0 aGVyZSBpcyBubyByZS1jbGFzc2lmaWNhdGlvbiwgdGhlIGVncmVzcyBOU0ggd2lsbCBoYXZlIFNJ PTANCg0Kw6ggSWYgU0k9MCBhbmQgdGhlcmUgaXMgcmUtY2xhc3NpZmljYXRpb24gd2l0aCBuZXcg U1BJLCB0aGUgZWdyZXNzIE5TSCB3aWxsIGhhdmUgYSBuZXcgU1BJIGFuZCBhIFNJPSAyNTUgb3Ig b3RoZXIgdmFsdWUsIGFzIHN0YXRlZCBpbiBhKS4NCg0Kw6ggSWYgU0k9MCBhbmQgdGhlcmUgaXMg bm8gcmUtY2xhc3NpZmljYXRpb24gdGhlIFNGIHNob3VsZCBkaXNjYXJkIHRoZSBwYWNrZXQNCg0K QWxzbyBhbiBTRkYgc2hvdWxkIGZvcndhcmQvaGFuZGxlIHBhY2tldHMgd2l0aCBOU0ggd2l0aCBT ST0xIG9yIFNJPTAuDQoNCkRvIHlvdSBhZ3JlZT8NCg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFtZXMgTiBHdWljaGFyZA0KU2VudDog cXVpbnRhLWZlaXJhLCA5IGRlIGZldmVyZWlybyBkZSAyMDE3IDE2OjI1DQpUbzogRmFicmljaW8g RmVycmF6OyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRGF2ZSBEb2xzb247IEVyaWMg QyBSb3Nlbjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5k ZXggRGVjcmVtZW50DQoNCkhpIEZhYnJpY2lvLA0KDQpXZWxjb21lIQ0KDQpZZXMsIHJlbW92YWwg b2YgTlNIIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBhbiBTRkYgb3IgYSByZS1jbGFzc2lmaWVy IChzZWN0aW9uIDQsIGJ1bGxldCBwb2ludCAxIGxheXMgdGhpcyBvdXQpLiBXaXRoIHRoZSBjdXJy ZW50IGFyY2hpdGVjdHVyZSB0aGUgU0YgZG9lcyBub3QgY2FyZSB3aGF0IFNJIHZhbHVlIGl0IGdl dHMsIGl0IGp1c3QgbmVlZHMgdG8gd29ycnkgYWJvdXQgZGVjcmVtZW50aW5nIGl0LCBhbmQgbGVh dmUgaXQgdXAgdG8gdGhlIFNGRiB0byBldmFsdWF0ZSB0aGUgU0kgdmFsdWUgYW5kIGFzc29jaWF0 ZWQgYWN0aW9uLg0KDQpKaW0NCg0KRnJvbTogRmFicmljaW8gRmVycmF6IFttYWlsdG86ZmFicmlj aW8tZmVycmF6QHRlbGVjb20ucHRdDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDksIDIwMTcg NzoxMyBBTQ0KVG86IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpIDxhbmRyZXcuZG9sZ2Fu b3dAbm9raWEuY29tPG1haWx0bzphbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPj47IERhdmUgRG9s c29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+Pjsg RXJpYyBDIFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ8bWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5l dD4+OyBKYW1lcyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb208bWFpbHRv OmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbT4+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQN Cg0KSGkgYWxsLA0KSeKAmW0gbmV3IGhlcmUgKGp1c3QgcmVhZCB0aGUgZHJhZnQgbGFzdCB3ZWVr KSBidXQgYWNjb3JkaW5nIHRvIGNoYXB0ZXIgNCAoY2hlY2sgZmlndXJlIDggZm9yIGV4YW1wbGUp LCBhbiBTRiBpcyBub3QgYWxsb3dlZCB0byBpbnNlcnQgb3IgcmVtb3ZlIE5TSC4gVGhlIHJlbW92 YWwgb2YgTlNIIGlzIHJlcG9uc2FiaWxpdHkgb2YgdGhlIFNTRiwgcmlnaHQ/DQoNCiAgRmlndXJl IDggbWFwcyBlYWNoIG9mIHRoZSBmb3VyIGFjdGlvbnMgYWJvdmUgdG8gdGhlIGNvbXBvbmVudHMg aW4gdGhlDQogICBTRkMgYXJjaGl0ZWN0dXJlIHRoYXQgY2FuIHBlcmZvcm0gaXQuDQoNCistLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0rDQp8ICAgICAgICAgICAgICAgIHwgIEluc2VydCAgICAgICAgIHxTZWxlY3QgfCAg IFVwZGF0ZSAgICAgICB8U2VydmljZSAgfA0KfCAgICAgICAgICAgICAgICB8ICBvciByZW1vdmUg TlNIICB8U2VydmljZXwgICAgTlNIICAgICAgICAgfHBvbGljeSAgIHwNCnwgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgfEZ1bmN0aW9ufCAgICAgICAgICAgICAgIHxzZWxlY3Rpb258 DQp8IENvbXBvbmVudCAgICAgICstLS0tLS0tLSstLS0tLS0tLStQYXRoICAgKy0tLS0tLS0tLS0t LS0tLS0rICAgICAgICAgfA0KfCAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICB8ICAg ICAgIHwgRGVjLiAgIHxVcGRhdGUgfCAgICAgICAgIHwNCnwgICAgICAgICAgICAgICAgfCBJbnNl cnQgfCBSZW1vdmUgfCAgICAgICB8U2VydmljZSB8Q29udGV4dHwgICAgICAgICB8DQp8ICAgICAg ICAgICAgICAgIHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCBJbmRleCAgfEhlYWRlciB8ICAg ICAgICAgfA0KKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0t LS0tLSstLS0tLS0tKy0tLS0tLS0tLSsNCnwgICAgICAgICAgICAgICAgfCAgICsgICAgfCAgICsg ICAgfCAgICAgICB8ICAgICAgICB8ICAgKyAgIHwgICAgICAgICB8DQp8Q2xhc3NpZmllciAgICAg IHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICAgfA0K Ky0tLS0tLS0tLS0tLS0tLSArLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0t LS0tKy0tLS0tLS0tLSsNCnxTZXJ2aWNlIEZ1bmN0aW9ufCAgICAgICAgfCAgICsgICAgfCAgKyAg ICB8ICAgICAgICB8ICAgICAgIHwgICAgICAgICB8DQp8Rm9yd2FyZGVyKFNGRikgIHwgICAgICAg IHwgICAgICAgIHwgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICAgfA0KKy0tLS0tLS0t LS0tLS0tLSArLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0t LS0tLSsNCnxTZXJ2aWNlICAgICAgICAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgKyAg ICB8ICAgKyAgIHwgICArICAgICB8DQp8RnVuY3Rpb24gIChTRikgIHwgICAgICAgIHwgICAgICAg IHwgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0tLSAr LS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsNCnxT RkMgUHJveHkgICAgICAgfCAgICsgICAgfCAgICsgICAgfCAgICAgICB8ICAgKyAgICB8ICAgICAg IHwgICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0t Ky0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tKw0KDQogICAgICAgICAgICAgICAgICAgRmlndXJl IDg6IE5TSCBBY3Rpb24gYW5kIFJvbGUgTWFwcGluZw0KDQoNCkFuIFNGIGNvdWxkIHJlY2VpdmUg YW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIGFuZCByZWNsYXNzaWZ5IGl0IHRvIGEgZGlm ZmVyZW50IFNQSSBhbmQgU0ksIHJpZ2h0PyBTbyB3aGVuIGEgU0YgcmVjZWl2ZXMgYSBOU0ggcGFj a2V0IHdpdGggU0kgPSAxIHRoYXQgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbnMgYSBub24gdmFs aWQgcGFja2V0Lg0KQW5kIHRoYXQgY2FuIGV2ZW4gd29yayBmb3IgU0k9MCwgc2luY2UgeW91IGRl Y3JlbWVudCB0aGUgU0kgaW4gdGhlIGVncmVzcy4NCg0KRmFicmljaW8NCg0KDQpGcm9tOiBzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERvbGdhbm93LCBBbmRy ZXcgKE5va2lhIC0gU0cpDQpTZW50OiBxdWludGEtZmVpcmEsIDkgZGUgZmV2ZXJlaXJvIGRlIDIw MTcgMDE6NTENClRvOiBEYXZlIERvbHNvbjsgRXJpYyBDIFJvc2VuOyBKYW1lcyBOIEd1aWNoYXJk OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBO U0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQNCg0KSSBhc3N1bWVkIHRoYXQgaWYgd2UgZ2V0IHZh bHVlIDEgd2UgcHJvY2VzcyB0aGVuIGZvcndhcmQgd2l0aG91dCBOU0ggaGVhZGVyIChpLmUuKSB0 aGlzIGlzIHRoZSBsYXN0IFNGIHByb2Nlc3NpbmcuDQoNClNvIHdpdGggdGhhdCBhc3N1bXB0aW9u LCBhIG1vcmUgZXhwbGljaXQgdGV4dCB3b3VsZCBiZToNCg0KQW4gU0Ygb3IgU0ZDIFByb3h5IHJl Y2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kg YnkgMSBhZnRlciBwZXJmb3JtaW5nIGFsbCByZXF1aXJlZCBsb2NhbCBwcm9jZXNzaW5nIGFuZCBi ZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRi4gSWYgdGhlIHJlc3Vs dGluZyBTSSBpcyAwLCB0aGUgU0YgTVVTVCByZW1vdmUgdGhlIE5TSCBoZWFkZXIgYmVmb3JlIGZv cndhcmRpbmcgdGhlIHBhY2tldC4NCg0KQW5kcmV3DQpGcm9tOiBzZmMgPHNmYy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEYXZlIERv bHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4N CkRhdGU6IFRodXJzZGF5LCBGZWJydWFyeSA5LCAyMDE3IGF0IDI6MDQgQU0NClRvOiBFcmljIFJv c2VuIDxlcm9zZW5AanVuaXBlci5uZXQ8bWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5ldD4+LCBKYW1l cyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb208bWFpbHRvOmphbWVzLm4u Z3VpY2hhcmRAaHVhd2VpLmNvbT4+LCAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzZmNd IE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudA0KDQpFcmljLA0KSSB3YXMgbmV2ZXIgcXVpdGUg aGFwcHkgd2l0aCB0aGUgb3V0Y29tZSB0aGF0IG5laXRoZXIgMCBub3IgMSBpcyBhIHZhbGlkIFNJ Lg0KKEJlY2F1c2UgaWYgcmVjZWl2ZWQgd2l0aCB2YWx1ZSBvZiAxLCBpdCBpcyBkZWNyZW1lbnRl ZCBhbmQgZGlzY2FyZGVkLikNCg0KSXQgc2VlbXMgdG8gd2FzdGUgYW4gaW5kZXggdmFsdWUuDQoN CkkgZ3Vlc3MgSeKAmW0gaW50ZXJlc3RlZCB0byBrbm93IGlmIHRoYXQgaXMgaW1wb3J0YW50IHRv IG90aGVyIGltcGxlbWVudGVycywgb3IgaWYgdGhhdCB3YXMgZXZlbiB0aGUgaW50ZW50aW9uPw0K DQoNCi1EYXZlDQoNCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEVyaWMgQyBSb3Nlbg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwg MjAxNyAxMTo1MyBBTQ0KVG86IEphbWVzIE4gR3VpY2hhcmQ7IHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3Jl bWVudA0KDQpPbiAyLzcvMjAxNyAyOjI0IFBNLCBKYW1lcyBOIEd1aWNoYXJkIHdyb3RlOg0KQSBy ZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUgc3BlY2lmaWMgYW5kIHVwZGF0ZSB0aGUgdGV4dCBh cyBmb2xsb3dzOg0KDQrigJxTZXJ2aWNlIGluZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgYnkgYSB2 YWx1ZSBvZiAxIGJ5IFNlcnZpY2UgRnVuY3Rpb25zIG9yIGJ5IFNGQyBQcm94eSBub2RlcyBhZnRl ciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZpY2VzIOKApuKAnQ0KDQpBIGNvdXBsZSBvZiBvYnNl cnZhdGlvbnM6DQoNCi0gVGhlIHRlcm0gIlNGQyBQcm94eSBub2RlIiBpcyBub3QgZGVmaW5lZCBp biBlaXRoZXIgdGhlIE5TSCBkcmFmdCBvciBpbiBSRkMgNzY2NS4gIEkgdGhpbmsgdGhlIGludGVu dGlvbiBoZXJlIGlzIHRvIHNheSAiU0ZDIFByb3h5Ii4NCg0KLSBJcyB0aGUgaW50ZW50aW9uIHRo YXQgdGhlIFNJIHJlbWFpbiB1bmNoYW5nZWQgd2hpbGUgdGhlIFNGIGlzIG9wZXJhdGluZyBvbiB0 aGUgcGFja2V0LCBvciBpcyB0aGUgaW50ZW50aW9uIG9ubHkgdGhhdCB0aGUgU0kgYmUgZGVjcmVt ZW50ZWQgYmVmb3JlIHRoZSBwYWNrZXQgaXMgZGVsaXZlcmVkIGJ5IHRoZSBTRiBvciBTRkMgUHJv eHkgdG8gYW4gU0ZGPw0KDQpJJ2Qgc3VnZ2VzdCBlaXRoZXI6DQoNCiJBbiBTRiBvciBTRkMgUHJv eHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRo ZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGIg0K DQpvcg0KDQoiQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVk IHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBiZWZvcmUgZGVsaXZlcmluZyB0aGUg cGFja2V0IHRvIHRoZSBuZXh0IFNGRiwgYnV0IG5vdCB1bnRpbCB0aGUgU0YgaGFzIGZpbmlzaGVk IGFsbCBpdHMgb3RoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0Ig0KDQpkZXBlbmRpbmcgdXBv biB3aGljaCBpcyBpbnRlbmRlZC4NCg0KSSB0aGluayBhbiBpbXBsaWNhdGlvbiBvZiB0aGVzZSBw cm9jZWR1cmVzIGlzIHRoYXQgYW4gU0kgdmFsdWUgb2YgMSBpcyBub3QgdmFsaWQuICBJZiBhbiBT RiBnZXRzIGFuIE5TSCBwYWNrZXQgd2l0aCBhbiBTSSBvZiAxLCB0aGUgU0Ygd2lsbCBkZWNyZW1l bnQgdGhlIFNJIChzZXR0aW5nIGl0IHRvIDApLCBzZW5kIHRoZSBwYWNrZXQgdG8gYW4gU0ZGLCBh bmQgdGhlIFNGRiB3aWxsIGRpc2NhcmQgaXQsIGJlY2F1c2UgMCBpcyBhbiBpbnZhbGlkIFNJIHZh bHVlLiAgSXMgdGhhdCB0aGUgaW50ZW50aW9uPw0KDQpUaGUgZHJhZnQgbWFrZXMgaXQgY2xlYXIg KHdlbGwsIHNvcnQgb2YpIHRoYXQgYW4gU0ZGIHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IHdpdGgg YW4gU0kgb2YgMCwgYnV0IGRvZXMgbm90IHNlZW0gdG8gc2F5IHRoYXQgYW4gU0Ygb3IgU0ZDIFBy b3h5IHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IGl0IHJlY2VpdmVzIHdpdGggYW4gU0kgb2YgMC4g IEl0IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIHNheSB0aGF0Lg0KDQpTb21lIHRl eHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0aW9uIDcuMSkgc3RhdGVzIHRoYW4gYW4gU0ZGIHNo b3VsZCBkaXNjYXJkIGEgcGFja2V0IHdpdGggYW4gU0kgb2YgemVybywgYnV0IG90aGVyIHRleHQg aW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0aW9uIDMuMykgb25seSBzYXlzIHRoYXQgYW4gU0ZGIHNo b3VsZCBsb2cgYW4gZXJyb3IgaWYgaXQgc2VlcyBhbiBTSSBvZiB6ZXJvLiAgSXQncyBwcm9iYWJs eSBiZXN0IHRvIGNoYW5nZSB0aGUgdGV4dCBpbiAzLjMuIHRvIHNheSAiU0hPVUxEIGdlbmVyYXRl IGFuIGVycm9yL2xvZyBtZXNzYWdlIGFuZCBNVVNUIGRpc2NhcmQgdGhlIHBhY2tldCIsIG9yIHNv bWV0aGluZyBzaW1pbGFyLg0K --_000_CB8C08780539D74B9BE1ED5174662634D2D755333CPTPPICEX01PTP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjE5Mjg5MTU4NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6OTk4MTU3NDUwIDEzNTY1OTU0MyAxMzU2NTk1NDUgMTM1NjU5NTQ3IDEzNTY1OTUzNSAxMzU2 NTk1NDUgMTM1NjU5NTQ3IDEzNTY1OTUzNSAxMzU2NTk1NDUgMTM1NjU5NTQ3O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDENCgl7 bXNvLWxpc3QtaWQ6MTkyMjEzNTU2MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTgyNzE3OTY5MCAtMTI1NzcyNDgwNiAxMzU2NTk1MjMgMTM1NjU5NTI1 IDEzNTY1OTUyMSAxMzU2NTk1MjMgMTM1NjU5NTI1IDEzNTY1OTUyMSAxMzU2NTk1MjMgMTM1NjU5 NTI1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674OoOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xv cj13aGl0ZSBsYW5nPVBUIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2Vj dGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5IaSBKaW0sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPk9uZSBtb3JlIHF1ZXN0aW9uIGFib3V0IHRoZSBTSS4gPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U2VjdGlvbiAzIHN0YXRlcyB0aGF0 OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5TZXJ2aWNlIEluZGV4IChTSSk6IHByb3ZpZGVzIGxv Y2F0aW9uIHdpdGhpbiB0aGUgU0ZQLiBUaGUgaW5pdGlhbCBjbGFzc2lmaWVyIE1VU1Qgc2V0IHRo ZSBhcHByb3ByaWF0ZSBTSSB2YWx1ZSBmb3IgYSBnaXZlbiBjbGFzc2lmaWNhdGlvbiByZXN1bHQu IFRoZSBpbml0aWFsIFNJIHZhbHVlIFNIT1VMRCBkZWZhdWx0IHRvIDI1NS4gSG93ZXZlciwgdGhl IGNsYXNzaWZpZXIgTVVTVCBhbGxvdyBjb25maWd1cmF0aW9uIG9mIG90aGVyIFNJIHZhbHVlcy4g PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PlNlcnZpY2UgSW5kZXggTVVTVCBiZSBkZWNyZW1lbnRlZCBieSBTZXJ2aWNlIEZ1bmN0aW9ucyBv ciBieSBTRkMgUHJveHkgbm9kZXMgYWZ0ZXIgcGVyZm9ybWluZyByZXF1aXJlZCBzZXJ2aWNlcyBh bmQgdGhlIG5ldyBkZWNyZW1lbnRlZCBTSSB2YWx1ZSBNVVNUIGJlIHVzZWQgaW4gdGhlIGVncmVz cyBOU0ggcGFja2V0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVM+VGhlIGluaXRpYWwgQ2xhc3NpZmllciBNVVNUIHNlbmQgdGhlIHBhY2tl dCB0byB0aGUgZmlyc3QgU0ZGIGluIHRoZSBpZGVudGlmaWVkIFNGUCBmb3IgZm9yd2FyZGluZyBh bG9uZyBhbiBTRlAuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUz5JZiByZS1jbGFzc2lmaWNhdGlvbiBvY2N1cnMsIGFuZCB0aGF0IHJlLWNs YXNzaWZpY2F0aW9uIHJlc3VsdHMgaW4gYSBuZXcgU1BJLCB0aGUgKHJlKWNsYXNzaWZpZXIgaXMs IGluIGVmZmVjdCwgdGhlIGluaXRpYWwgY2xhc3NpZmllciBmb3IgdGhlIHJlc3VsdGFudCBTUEku PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaHVzOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmEpPHNwYW4gc3R5 bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPkluaXRpYWwgU0kgdmFsdWUgc2hvdWxkIGJlIDI1NSBidXQgb3RoZXIg dmFsdWVzIGNhbiBiZSBjb25maWd1cmVkIGJ5IHRoZSBjbGFzc2lmaWVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ Yik8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U0YgZGVjcmVtZW50cyB0aGUgU0kgdmFsdWUgb24g dGhlIGVncmVzcyBOU0ggcGFja2V0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xp c3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5jKTxzcGFuIHN0eWxlPSdmb250Ojcu MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5JZiByZS1jbGFzc2lmaWNhdGlvbiBvY2N1cnMgd2l0aCBuZXcgU1BJLCB0aGUg cmUtY2xhc3NpZmllciBpcyB0aGUgaW5pdGlhbCBjbGFzc2lmaWVyLCBzbyBieSDCoGEpLCBTSSBz aG91bGQgYmUgYWdhaW4gMjU1IG9yIG90aGVyIHZhbHVlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlNvIGFueSBTSSB2YWx1ZSBjYW4gYmUgcmVjZWl2ZSBieSBhbiBT RiwgZXZlbiAxIG9yIDAgYmVjYXVzZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZl bDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCc+PHNwYW4g c3R5bGU9J21zby1saXN0Oklnbm9yZSc+w6g8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMg TmV3IFJvbWFuIic+IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+SWYgU0k9MSBhbmQgdGhlcmUgaXMgbm8gcmUtY2xhc3NpZmlj YXRpb24sIHRoZSBlZ3Jlc3MgTlNIIHdpbGwgaGF2ZSBTST0wPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsOoPHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklmIFNJPTAgYW5kIHRoZXJlIGlzIHJl LWNsYXNzaWZpY2F0aW9uIHdpdGggbmV3IFNQSSwgdGhlIGVncmVzcyBOU0ggd2lsbCBoYXZlIGEg bmV3IFNQSSBhbmQgYSBTST0gMjU1IG9yIG90aGVyIHZhbHVlLCBhcyBzdGF0ZWQgaW4gYSkuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsOo PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklmIFNJ PTAgYW5kIHRoZXJlIGlzIG5vIHJlLWNsYXNzaWZpY2F0aW9uIHRoZSBTRiBzaG91bGQgZGlzY2Fy ZCB0aGUgcGFja2V0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWxz byBhbiBTRkYgc2hvdWxkIGZvcndhcmQvaGFuZGxlIHBhY2tldHMgd2l0aCBOU0ggd2l0aCBTST0x IG9yIFNJPTAuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RG8geW91 IGFncmVlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkphbWVzIE4gR3VpY2hhcmQ8YnI+PGI+U2VudDo8L2I+IHF1 aW50YS1mZWlyYSwgOSBkZSBmZXZlcmVpcm8gZGUgMjAxNyAxNjoyNTxicj48Yj5Ubzo8L2I+IEZh YnJpY2lvIEZlcnJhejsgRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRyk7IERhdmUgRG9sc29u OyBFcmljIEMgUm9zZW47IHNmY0BpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNd IE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IaSBGYWJyaWNpbyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XZWxjb21lITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlllcywgcmVtb3ZhbCBvZiBOU0ggaXMgdGhl IHJlc3BvbnNpYmlsaXR5IG9mIGFuIFNGRiBvciBhIHJlLWNsYXNzaWZpZXIgKHNlY3Rpb24gNCwg YnVsbGV0IHBvaW50IDEgbGF5cyB0aGlzIG91dCkuIFdpdGggdGhlIGN1cnJlbnQgYXJjaGl0ZWN0 dXJlIHRoZSBTRiBkb2VzIG5vdCBjYXJlIHdoYXQgU0kgdmFsdWUgaXQgZ2V0cywgaXQganVzdCBu ZWVkcyB0byB3b3JyeSBhYm91dCBkZWNyZW1lbnRpbmcgaXQsIGFuZCBsZWF2ZSBpdCB1cCB0byB0 aGUgU0ZGIHRvIGV2YWx1YXRlIHRoZSBTSSB2YWx1ZSBhbmQgYXNzb2NpYXRlZCBhY3Rpb24uPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmltPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjwvYT48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz4gRmFicmljaW8gRmVycmF6IFs8YSBocmVm PSJtYWlsdG86ZmFicmljaW8tZmVycmF6QHRlbGVjb20ucHQiPm1haWx0bzpmYWJyaWNpby1mZXJy YXpAdGVsZWNvbS5wdDwvYT5dIDxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDA5 LCAyMDE3IDc6MTMgQU08YnI+PGI+VG86PC9iPiBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNH KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20iPmFuZHJldy5k b2xnYW5vd0Bub2tpYS5jb208L2E+Jmd0OzsgRGF2ZSBEb2xzb24gJmx0OzxhIGhyZWY9Im1haWx0 bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+ZGRvbHNvbkBzYW5kdmluZS5jb208L2E+Jmd0OzsgRXJp YyBDIFJvc2VuICZsdDs8YSBocmVmPSJtYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0Ij5lcm9zZW5A anVuaXBlci5uZXQ8L2E+Jmd0OzsgSmFtZXMgTiBHdWljaGFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbSI+amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29t PC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48 YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkni gJltIG5ldyBoZXJlIChqdXN0IHJlYWQgdGhlIGRyYWZ0IGxhc3Qgd2VlaykgYnV0IGFjY29yZGlu ZyB0byBjaGFwdGVyIDQgKGNoZWNrIGZpZ3VyZSA4IGZvciBleGFtcGxlKSwgYW4gU0YgaXMgbm90 IGFsbG93ZWQgdG8gaW5zZXJ0IG9yIHJlbW92ZSBOU0guIFRoZSByZW1vdmFsIG9mIE5TSCBpcyBy ZXBvbnNhYmlsaXR5IG9mIHRoZSBTU0YsIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjcuMHB0IDcuMHB0IDcuMHB0IDcuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyBGaWd1cmUgOCBtYXBzIGVhY2ggb2YgdGhlIGZvdXIg YWN0aW9ucyBhYm92ZSB0byB0aGUgY29tcG9uZW50cyBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsg U0ZDIGFyY2hpdGVjdHVyZSB0aGF0IGNhbiBwZXJmb3JtIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91 bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ny4x NXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCc+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPist LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0rPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJl YWstYWxsJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7IEluc2VydCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8U2VsZWN0IHwmbmJzcDsmbmJzcDsgVXBkYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHxTZXJ2aWNlJm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7 d29yZC1icmVhazpicmVhay1hbGwnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsgb3IgcmVtb3ZlIE5TSCZuYnNwOyB8U2VydmljZXwmbmJzcDsmbmJz cDsmbmJzcDsgTlNIJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHxwb2xpY3kmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3 b3JkLWJyZWFrOmJyZWFrLWFsbCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8RnVuY3Rp b258Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxzZWxlY3Rpb258PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFj a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsJz48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+fCBDb21wb25l bnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0tLS0tLS0tKy0tLS0tLS0tK1BhdGgm bmJzcDsmbmJzcDsgKy0tLS0tLS0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29y ZC1icmVhazpicmVhay1hbGwnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRGVjLiZuYnNwOyZuYnNwOyB8VXBkYXRlIHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tn cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCc+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBJbnNlcnQgfCBSZW1vdmUgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8U2VydmljZSB8Q29udGV4dHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6 I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBJbmRleCZuYnNwOyB8SGVhZGVyIHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ny4xNXB0 O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCc+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPistLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSst LS0tLS0tLS0rPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7ICsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo3 LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsJz48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ fENsYXNzaWZpZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFr OmJyZWFrLWFsbCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPistLS0tLS0tLS0tLS0tLS0gKy0tLS0tLS0tKy0tLS0tLS0t Ky0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0rPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3Vu ZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+fFNlcnZpY2UgRnVuY3Rp b258Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsgKyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPnxGb3J3YXJkZXIoU0ZGKSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Ky0tLS0tLS0tLS0tLS0tLSArLS0tLS0tLS0rLS0tLS0tLS0r LS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5k OiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz58U2VydmljZSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5i c3A7Jm5ic3A7ICsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsgKyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFj a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsJz48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+fEZ1bmN0aW9u Jm5ic3A7IChTRikmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206Ny4x NXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCc+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPist LS0tLS0tLS0tLS0tLS0gKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0rLS0tLS0t LSstLS0tLS0tLS0rPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJl YWstYWxsJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+fFNGQyBQcm94eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAr Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Ky0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0t LSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZE RjU7d29yZC1icmVhazpicmVhay1hbGwnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNr Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwnPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDg6IE5TSCBB Y3Rpb24gYW5kIFJvbGUgTWFwcGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFuIFNGIGNvdWxkIHJlY2VpdmUg YW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIGFuZCByZWNsYXNzaWZ5IGl0IHRvIGEgZGlm ZmVyZW50IFNQSSBhbmQgU0ksIHJpZ2h0PyBTbyB3aGVuIGEgU0YgcmVjZWl2ZXMgYSBOU0ggcGFj a2V0IHdpdGggU0kgPSAxIHRoYXQgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbnMgYSBub24gdmFs aWQgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFuZCB0aGF0IGNhbiBldmVuIHdvcmsgZm9yIFNJ PTAsIHNpbmNlIHlvdSBkZWNyZW1lbnQgdGhlIFNJIGluIHRoZSBlZ3Jlc3MuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RmFicmljaW88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFs ZiBPZiA8L2I+RG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRyk8YnI+PGI+U2VudDo8L2I+IHF1 aW50YS1mZWlyYSwgOSBkZSBmZXZlcmVpcm8gZGUgMjAxNyAwMTo1MTxicj48Yj5Ubzo8L2I+IERh dmUgRG9sc29uOyBFcmljIEMgUm9zZW47IEphbWVzIE4gR3VpY2hhcmQ7IDxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBb c2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+SSBhc3N1bWVk IHRoYXQgaWYgd2UgZ2V0IHZhbHVlIDEgd2UgcHJvY2VzcyB0aGVuIGZvcndhcmQgd2l0aG91dCBO U0ggaGVhZGVyIChpLmUuKSB0aGlzIGlzIHRoZSBsYXN0IFNGIHByb2Nlc3NpbmcuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+U28gd2l0aCB0aGF0IGFzc3Vt cHRpb24sIGEgbW9yZSBleHBsaWNpdCB0ZXh0IHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkFuIFNGIG9yIFNGQyBQcm94eSByZWNlaXZpbmcg YW4gTlNILWVuY2Fwc3VsYXRlZCBwYWNrZXQgTVVTVCBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEgYWZ0 ZXIgcGVyZm9ybWluZyBhbGwgcmVxdWlyZWQgbG9jYWwgcHJvY2Vzc2luZyBhbmQgYmVmb3JlIGZv cndhcmRpbmcgdGhlIHBhY2tldCB0byB0aGUgbmV4dCBTRkYuIElmIHRoZSByZXN1bHRpbmcgU0kg aXMgMCwgdGhlIFNGIE1VU1QgcmVtb3ZlIHRoZSBOU0ggaGVhZGVyIGJlZm9yZSBmb3J3YXJkaW5n IHRoZSBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4 dCc+QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PGI+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiJz5zZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y ZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGF2ZSBEb2xzb24g Jmx0OzxhIGhyZWY9Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+ZGRvbHNvbkBzYW5kdmlu ZS5jb208L2E+Jmd0Ozxicj48Yj5EYXRlOiA8L2I+VGh1cnNkYXksIEZlYnJ1YXJ5IDksIDIwMTcg YXQgMjowNCBBTTxicj48Yj5UbzogPC9iPkVyaWMgUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpl cm9zZW5AanVuaXBlci5uZXQiPmVyb3NlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7LCBKYW1lcyBOIEd1 aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tIj5q YW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+PGI+U3ViamVjdDogPC9iPlJl OiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 MzYuMHB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RXJpYyw8L3NwYW4+PHNw YW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5JIHdhcyBuZXZlciBxdWl0ZSBoYXBweSB3aXRoIHRoZSBvdXRjb21lIHRoYXQgbmVpdGhlciAw IG5vciAxIGlzIGEgdmFsaWQgU0kuPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+KEJlY2F1c2UgaWYgcmVjZWl2ZWQgd2l0 aCB2YWx1ZSBvZiAxLCBpdCBpcyBkZWNyZW1lbnRlZCBhbmQgZGlzY2FyZGVkLik8L3NwYW4+PHNw YW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5JdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2YWx1ZS48L3Nw YW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGd1ZXNzIEnigJltIGludGVyZXN0ZWQgdG8ga25v dyBpZiB0aGF0IGlzIGltcG9ydGFudCB0byBvdGhlciBpbXBsZW1lbnRlcnMsIG9yIGlmIHRoYXQg d2FzIGV2ZW4gdGhlIGludGVudGlvbj88L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQn PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz4tRGF2ZTwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVO LVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93 dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQn PiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIEMgUm9zZW48YnI+ PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTcgMTE6NTMgQU08YnI+PGI+ VG86PC9iPiBKYW1lcyBOIEd1aWNoYXJkOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5z ZmNAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gTlNIIFNlcnZpY2Ug SW5kZXggRGVjcmVtZW50PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYu MHB0Jz48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4t VVM+T24gMi83LzIwMTcgMjoyNCBQTSwgSmFtZXMgTiBHdWljaGFyZCB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFu IGxhbmc9RU4tVVM+QSByZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUgc3BlY2lmaWMgYW5kIHVw ZGF0ZSB0aGUgdGV4dCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQn PjxzcGFuIGxhbmc9RU4tVVM+4oCcU2VydmljZSBpbmRleCBNVVNUIGJlIGRlY3JlbWVudGVkIDxi PmJ5IGEgdmFsdWUgb2YgMTwvYj4gYnkgU2VydmljZSBGdW5jdGlvbnMgb3IgYnkgU0ZDIFByb3h5 IG5vZGVzIGFmdGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQgc2VydmljZXMg4oCm4oCdPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2 LjBwdCc+PHNwYW4gbGFuZz1FTi1VUz48YnI+QSBjb3VwbGUgb2Ygb2JzZXJ2YXRpb25zOjxicj48 YnI+LSBUaGUgdGVybSAmcXVvdDtTRkMgUHJveHkgbm9kZSZxdW90OyBpcyBub3QgZGVmaW5lZCBp biBlaXRoZXIgdGhlIE5TSCBkcmFmdCBvciBpbiBSRkMgNzY2NS4mbmJzcDsgSSB0aGluayB0aGUg aW50ZW50aW9uIGhlcmUgaXMgdG8gc2F5ICZxdW90O1NGQyBQcm94eSZxdW90Oy48YnI+PGJyPi0g SXMgdGhlIGludGVudGlvbiB0aGF0IHRoZSBTSSByZW1haW4gdW5jaGFuZ2VkIHdoaWxlIHRoZSBT RiBpcyBvcGVyYXRpbmcgb24gdGhlIHBhY2tldCwgb3IgaXMgdGhlIGludGVudGlvbiBvbmx5IHRo YXQgdGhlIFNJIGJlIGRlY3JlbWVudGVkIGJlZm9yZSB0aGUgcGFja2V0IGlzIGRlbGl2ZXJlZCBi eSB0aGUgU0Ygb3IgU0ZDIFByb3h5IHRvIGFuIFNGRj8gPGJyPjxicj5JJ2Qgc3VnZ2VzdCBlaXRo ZXI6PGJyPjxicj4mcXVvdDtBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNh cHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVy aW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGJnF1b3Q7PGJyPjxicj5vcjxicj48YnI+JnF1 b3Q7QW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tl dCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBiZWZvcmUgZGVsaXZlcmluZyB0aGUgcGFja2V0 IHRvIHRoZSBuZXh0IFNGRiwgYnV0IG5vdCB1bnRpbCB0aGUgU0YgaGFzIGZpbmlzaGVkIGFsbCBp dHMgb3RoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0JnF1b3Q7PGJyPjxicj5kZXBlbmRpbmcg dXBvbiB3aGljaCBpcyBpbnRlbmRlZC48YnI+PGJyPkkgdGhpbmsgYW4gaW1wbGljYXRpb24gb2Yg dGhlc2UgcHJvY2VkdXJlcyBpcyB0aGF0IGFuIFNJIHZhbHVlIG9mIDEgaXMgbm90IHZhbGlkLiZu YnNwOyBJZiBhbiBTRiBnZXRzIGFuIE5TSCBwYWNrZXQgd2l0aCBhbiBTSSBvZiAxLCB0aGUgU0Yg d2lsbCBkZWNyZW1lbnQgdGhlIFNJIChzZXR0aW5nIGl0IHRvIDApLCBzZW5kIHRoZSBwYWNrZXQg dG8gYW4gU0ZGLCBhbmQgdGhlIFNGRiB3aWxsIGRpc2NhcmQgaXQsIGJlY2F1c2UgMCBpcyBhbiBp bnZhbGlkIFNJIHZhbHVlLiZuYnNwOyBJcyB0aGF0IHRoZSBpbnRlbnRpb24/PGJyPjxicj5UaGUg ZHJhZnQgbWFrZXMgaXQgY2xlYXIgKHdlbGwsIHNvcnQgb2YpIHRoYXQgYW4gU0ZGIHNob3VsZCBk aXNjYXJkIGEgcGFja2V0IHdpdGggYW4gU0kgb2YgMCwgYnV0IGRvZXMgbm90IHNlZW0gdG8gc2F5 IHRoYXQgYW4gU0Ygb3IgU0ZDIFByb3h5IHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IGl0IHJlY2Vp dmVzIHdpdGggYW4gU0kgb2YgMC4mbmJzcDsgSXQgd291bGQgcHJvYmFibHkgYmUgYSBnb29kIGlk ZWEgdG8gc2F5IHRoYXQuPGJyPjxicj5Tb21lIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0 aW9uIDcuMSkgc3RhdGVzIHRoYW4gYW4gU0ZGIHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IHdpdGgg YW4gU0kgb2YgemVybywgYnV0IG90aGVyIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0aW9u IDMuMykgb25seSBzYXlzIHRoYXQgYW4gU0ZGIHNob3VsZCBsb2cgYW4gZXJyb3IgaWYgaXQgc2Vl cyBhbiBTSSBvZiB6ZXJvLiZuYnNwOyBJdCdzIHByb2JhYmx5IGJlc3QgdG8gY2hhbmdlIHRoZSB0 ZXh0IGluIDMuMy4gdG8gc2F5ICZxdW90O1NIT1VMRCBnZW5lcmF0ZSBhbiBlcnJvci9sb2cgbWVz c2FnZSBhbmQgTVVTVCBkaXNjYXJkIHRoZSBwYWNrZXQmcXVvdDssIG9yIHNvbWV0aGluZyBzaW1p bGFyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_CB8C08780539D74B9BE1ED5174662634D2D755333CPTPPICEX01PTP_-- From nobody Thu Feb 9 09:00:26 2017 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 90EFC129BFC for ; Thu, 9 Feb 2017 09:00:24 -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_HELO_PASS=-0.001, 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 OCinO76Wm8lj for ; Thu, 9 Feb 2017 09:00:22 -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 04990129C29 for ; Thu, 9 Feb 2017 09:00:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DC987320066; Thu, 9 Feb 2017 09:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486659618; bh=UvIk0nyKuYwlJx7zPX98FEdZ9HWwCOz1bEEhzw3bcmQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HptuJZbSVTu4XSmwoHQtCylCCcy/VZGzey7e+1j9XCc5T3uhdUc8G3Cy1n+cpWpF+ McMY5EdvcgAJ6OJ6bmfIFAIRTlap5AZgGcYQCcJwn3YDqEWHlLkJXi8bMImfYZWKu8 Bf63OTrk6xtnF5lSZ5nQFEugFWDcSHuOwKCE6lHw= 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 4D69C320050; Thu, 9 Feb 2017 09:00:18 -0800 (PST) To: Fabricio Ferraz , "sfc@ietf.org" References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> From: "Joel M. Halpern" Message-ID: <985245cb-8d2e-d094-4d1d-18fb0ffcb903@joelhalpern.com> Date: Thu, 9 Feb 2017 12:00:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:00:24 -0000 An SF should never receive a packet with SI 0. But it is not its responsibility to enforce that. An SFF that receives a packet with SI 0 is required to drop that packet. Usually, an SFF which is expected to receive an SI of 1 for a given SPI is also configured to be the termination / egress for that SPI. It is legal for the index 1 to go to an SF and a reclassifier, and thus get NEW NSH information. This would correspond to a case where there are multiple alternative next service function paths, none of them being continuations of the original path. I am not sure what the "Egress NSH" is in your description. Remember that a classifier or reclassifier is (archtiecturally) separate from an SF or an SFF. It is a distinct set of fnctionality. Yours, Joel On 2/9/17 11:48 AM, Fabricio Ferraz wrote: > Hi Jim, > > Thanks. > > > > One more question about the SI. > > > > Section 3 states that: > > > > Service Index (SI): provides location within the SFP. The initial > classifier MUST set the appropriate SI value for a given classification > result. The initial SI value SHOULD default to 255. However, the > classifier MUST allow configuration of other SI values. > > Service Index MUST be decremented by Service Functions or by SFC Proxy > nodes after performing required services and the new decremented SI > value MUST be used in the egress NSH packet. > > The initial Classifier MUST send the packet to the first SFF in the > identified SFP for forwarding along an SFP. > > If re-classification occurs, and that re-classification results in a new > SPI, the (re)classifier is, in effect, the initial classifier for the > resultant SPI. > > > > Thus: > > a) Initial SI value should be 255 but other values can be > configured by the classifier. > > b) SF decrements the SI value on the egress NSH packet > > c) If re-classification occurs with new SPI, the re-classifier is > the initial classifier, so by a), SI should be again 255 or other value > > > > So any SI value can be receive by an SF, even 1 or 0 because: > > èIf SI=1 and there is no re-classification, the egress NSH will have SI=0 > > èIf SI=0 and there is re-classification with new SPI, the egress NSH > will have a new SPI and a SI= 255 or other value, as stated in a). > > èIf SI=0 and there is no re-classification the SF should discard the packet > > > > Also an SFF should forward/handle packets with NSH with SI=1 or SI=0. > > > > Do you agree? > > > > > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N Guichard > *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eric > C Rosen; sfc@ietf.org > *Subject:* Re: [sfc] NSH Service Index Decrement > > > > Hi Fabricio, > > > > Welcome! > > > > Yes, removal of NSH is the responsibility of an SFF or a re-classifier > (section 4, bullet point 1 lays this out). With the current architecture > the SF does not care what SI value it gets, it just needs to worry about > decrementing it, and leave it up to the SFF to evaluate the SI value and > associated action. > > > > Jim > > > > *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > *Sent:* Thursday, February 09, 2017 7:13 AM > *To:* Dolganow, Andrew (Nokia - SG) >; Dave Dolson >; Eric C Rosen >; James N Guichard > >; > sfc@ietf.org > *Subject:* RE: [sfc] NSH Service Index Decrement > > > > Hi all, > > I’m new here (just read the draft last week) but according to chapter 4 > (check figure 8 for example), an SF is not allowed to insert or remove > NSH. The removal of NSH is reponsability of the SSF, right? > > > > Figure 8 maps each of the four actions above to the components in the > > SFC architecture that can perform it. > > > > +---------------+------------------+-------+----------------+---------+ > > | | Insert |Select | Update |Service | > > | | or remove NSH |Service| NSH |policy | > > | | |Function| |selection| > > | Component +--------+--------+Path +----------------+ | > > | | | | | Dec. |Update | | > > | | Insert | Remove | |Service |Context| | > > | | | | | Index |Header | | > > +----------------+--------+--------+-------+--------+-------+---------+ > > | | + | + | | | + | | > > |Classifier | | | | | | | > > +--------------- +--------+--------+-------+--------+-------+---------+ > > |Service Function| | + | + | | | | > > |Forwarder(SFF) | | | | | | | > > +--------------- +--------+--------+-------+--------+-------+---------+ > > |Service | | | | + | + | + | > > |Function (SF) | | | | | | | > > +--------------- +--------+--------+-------+--------+-------+---------+ > > |SFC Proxy | + | + | | + | | | > > +----------------+--------+--------+-------+--------+-------+---------+ > > > > Figure 8: NSH Action and Role Mapping > > > > > > An SF could receive an NSH packet with an SI of 1, and reclassify it to > a different SPI and SI, right? So when a SF receives a NSH packet with > SI = 1 that does not necessarily means a non valid packet. > > And that can even work for SI=0, since you decrement the SI in the egress. > > > > Fabricio > > > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, Andrew > (Nokia - SG) > *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org > > *Subject:* Re: [sfc] NSH Service Index Decrement > > > > I assumed that if we get value 1 we process then forward without NSH > header (i.e.) this is the last SF processing. > > > > So with that assumption, a more explicit text would be: > > > > An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement > the SI by 1 after performing all required local processing and before > forwarding the packet to the next SFF. If the resulting SI is 0, the SF > MUST remove the NSH header before forwarding the packet. > > > > Andrew > > *From: *sfc > on > behalf of Dave Dolson > > *Date: *Thursday, February 9, 2017 at 2:04 AM > *To: *Eric Rosen >, James > N Guichard >, "sfc@ietf.org > " > > *Subject: *Re: [sfc] NSH Service Index Decrement > > > > Eric, > > I was never quite happy with the outcome that neither 0 nor 1 is a valid SI. > > (Because if received with value of 1, it is decremented and discarded.) > > > > It seems to waste an index value. > > > > I guess I’m interested to know if that is important to other > implementers, or if that was even the intention? > > > > > > -Dave > > > > > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C Rosen > *Sent:* Wednesday, February 08, 2017 11:53 AM > *To:* James N Guichard; sfc@ietf.org > *Subject:* Re: [sfc] NSH Service Index Decrement > > > > On 2/7/2017 2:24 PM, James N Guichard wrote: > > A request was made to be more specific and update the text as follows: > > > > “Service index MUST be decremented *by a value of 1* by Service > Functions or by SFC Proxy nodes after performing required services …” > > > A couple of observations: > > - The term "SFC Proxy node" is not defined in either the NSH draft or in > RFC 7665. I think the intention here is to say "SFC Proxy". > > - Is the intention that the SI remain unchanged while the SF is > operating on the packet, or is the intention only that the SI be > decremented before the packet is delivered by the SF or SFC Proxy to an > SFF? > > I'd suggest either: > > "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement > the SI by 1 before delivering the packet to the next SFF" > > or > > "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement > the SI by 1 before delivering the packet to the next SFF, but not until > the SF has finished all its other processing of the packet" > > depending upon which is intended. > > I think an implication of these procedures is that an SI value of 1 is > not valid. If an SF gets an NSH packet with an SI of 1, the SF will > decrement the SI (setting it to 0), send the packet to an SFF, and the > SFF will discard it, because 0 is an invalid SI value. Is that the > intention? > > The draft makes it clear (well, sort of) that an SFF should discard a > packet with an SI of 0, but does not seem to say that an SF or SFC Proxy > should discard a packet it receives with an SI of 0. It would probably > be a good idea to say that. > > Some text in the draft (e.g., section 7.1) states than an SFF should > discard a packet with an SI of zero, but other text in the draft (e.g., > section 3.3) only says that an SFF should log an error if it sees an SI > of zero. It's probably best to change the text in 3.3. to say "SHOULD > generate an error/log message and MUST discard the packet", or something > similar. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Feb 9 09:02:37 2017 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 70506129BF6 for ; Thu, 9 Feb 2017 09:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 NJheTMKgSoHp for ; Thu, 9 Feb 2017 09:02:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F678129BFC for ; Thu, 9 Feb 2017 09:02:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGD32878; Thu, 09 Feb 2017 17:02:29 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 9 Feb 2017 17:02:27 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Thu, 9 Feb 2017 09:02:22 -0800 From: James N Guichard To: Fabricio Ferraz , "Dolganow, Andrew (Nokia - SG)" , Dave Dolson , "Eric C Rosen" , "sfc@ietf.org" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkAAeZjIw Date: Thu, 9 Feb 2017 17:02:21 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.56] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB68F0SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.589CA0A6.008F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a70407c9a835e72958c2c0bc1d89c9e Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:02:36 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB68F0SJCEML701CHMchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IGV4YWN0bHkuIFNlY3Rpb24gMy4zIHNwZWNpZmllcyDigJxUaGUgdmFsdWUgemVybyBmb3Ig U0kgaXMgbm90IHZhbGlkIGFuZCBpbmRpY2F0ZXMgYSBicm9rZW4gU0ZDIG9yIG1hbGZ1bmN0aW9u aW5nIFNG4oCdIC4uIEluIG90aGVyIHdvcmRzIGFuIFNGIHNob3VsZCBuZXZlciByZWNlaXZlIGFu IE5TSCBwYWNrZXQgd2l0aCBTSSA9IDAuIE5vdGUgdGhhdCBpZiB0aGlzIGhhcHBlbmVkIHRoZW4g ZWl0aGVyIGEpIGEgY2xhc3NpZmllciBzZXQgdGhlIFNJIGluY29ycmVjdGx5LCBvciBiKSBhIHJl LWNsYXNzaWZpZXIgc2V0IHRoZSBTSSBpbmNvcnJlY3RseSwgb3IgYykgYW4gdXBzdHJlYW0gU0Yg c2V0IHRoZSBTSSBpbmNvcnJlY3RseTsgYWxsIG9mIHRoZXNlIGNhc2VzIHNob3VsZCBiZSBjYXVn aHQgYnkgdGhlIFNGRiB3aG9zZSBqb2IgaXQgaXMgdG8gZGlzY2FyZCBOU0ggcGFja2V0cyB3aXRo IFNJID0gMC4NCg0KSmltDQoNCkZyb206IEZhYnJpY2lvIEZlcnJheiBbbWFpbHRvOmZhYnJpY2lv LWZlcnJhekB0ZWxlY29tLnB0XQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAyMDE3IDEx OjQ5IEFNDQpUbzogSmFtZXMgTiBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29t PjsgRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRykgPGFuZHJldy5kb2xnYW5vd0Bub2tpYS5j b20+OyBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+OyBFcmljIEMgUm9zZW4gPGVy b3NlbkBqdW5pcGVyLm5ldD47IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzZmNdIE5TSCBT ZXJ2aWNlIEluZGV4IERlY3JlbWVudA0KDQpIaSBKaW0sDQpUaGFua3MuDQoNCk9uZSBtb3JlIHF1 ZXN0aW9uIGFib3V0IHRoZSBTSS4NCg0KU2VjdGlvbiAzIHN0YXRlcyB0aGF0Og0KDQpTZXJ2aWNl IEluZGV4IChTSSk6IHByb3ZpZGVzIGxvY2F0aW9uIHdpdGhpbiB0aGUgU0ZQLiBUaGUgaW5pdGlh bCBjbGFzc2lmaWVyIE1VU1Qgc2V0IHRoZSBhcHByb3ByaWF0ZSBTSSB2YWx1ZSBmb3IgYSBnaXZl biBjbGFzc2lmaWNhdGlvbiByZXN1bHQuIFRoZSBpbml0aWFsIFNJIHZhbHVlIFNIT1VMRCBkZWZh dWx0IHRvIDI1NS4gSG93ZXZlciwgdGhlIGNsYXNzaWZpZXIgTVVTVCBhbGxvdyBjb25maWd1cmF0 aW9uIG9mIG90aGVyIFNJIHZhbHVlcy4NClNlcnZpY2UgSW5kZXggTVVTVCBiZSBkZWNyZW1lbnRl ZCBieSBTZXJ2aWNlIEZ1bmN0aW9ucyBvciBieSBTRkMgUHJveHkgbm9kZXMgYWZ0ZXIgcGVyZm9y bWluZyByZXF1aXJlZCBzZXJ2aWNlcyBhbmQgdGhlIG5ldyBkZWNyZW1lbnRlZCBTSSB2YWx1ZSBN VVNUIGJlIHVzZWQgaW4gdGhlIGVncmVzcyBOU0ggcGFja2V0Lg0KVGhlIGluaXRpYWwgQ2xhc3Np ZmllciBNVVNUIHNlbmQgdGhlIHBhY2tldCB0byB0aGUgZmlyc3QgU0ZGIGluIHRoZSBpZGVudGlm aWVkIFNGUCBmb3IgZm9yd2FyZGluZyBhbG9uZyBhbiBTRlAuDQpJZiByZS1jbGFzc2lmaWNhdGlv biBvY2N1cnMsIGFuZCB0aGF0IHJlLWNsYXNzaWZpY2F0aW9uIHJlc3VsdHMgaW4gYSBuZXcgU1BJ LCB0aGUgKHJlKWNsYXNzaWZpZXIgaXMsIGluIGVmZmVjdCwgdGhlIGluaXRpYWwgY2xhc3NpZmll ciBmb3IgdGhlIHJlc3VsdGFudCBTUEkuDQoNClRodXM6DQoNCmEpICAgICAgSW5pdGlhbCBTSSB2 YWx1ZSBzaG91bGQgYmUgMjU1IGJ1dCBvdGhlciB2YWx1ZXMgY2FuIGJlIGNvbmZpZ3VyZWQgYnkg dGhlIGNsYXNzaWZpZXIuDQoNCmIpICAgICAgU0YgZGVjcmVtZW50cyB0aGUgU0kgdmFsdWUgb24g dGhlIGVncmVzcyBOU0ggcGFja2V0DQoNCmMpICAgICAgIElmIHJlLWNsYXNzaWZpY2F0aW9uIG9j Y3VycyB3aXRoIG5ldyBTUEksIHRoZSByZS1jbGFzc2lmaWVyIGlzIHRoZSBpbml0aWFsIGNsYXNz aWZpZXIsIHNvIGJ5ICBhKSwgU0kgc2hvdWxkIGJlIGFnYWluIDI1NSBvciBvdGhlciB2YWx1ZQ0K DQpTbyBhbnkgU0kgdmFsdWUgY2FuIGJlIHJlY2VpdmUgYnkgYW4gU0YsIGV2ZW4gMSBvciAwIGJl Y2F1c2U6DQoNCsOoIElmIFNJPTEgYW5kIHRoZXJlIGlzIG5vIHJlLWNsYXNzaWZpY2F0aW9uLCB0 aGUgZWdyZXNzIE5TSCB3aWxsIGhhdmUgU0k9MA0KDQrDqCBJZiBTST0wIGFuZCB0aGVyZSBpcyBy ZS1jbGFzc2lmaWNhdGlvbiB3aXRoIG5ldyBTUEksIHRoZSBlZ3Jlc3MgTlNIIHdpbGwgaGF2ZSBh IG5ldyBTUEkgYW5kIGEgU0k9IDI1NSBvciBvdGhlciB2YWx1ZSwgYXMgc3RhdGVkIGluIGEpLg0K DQrDqCBJZiBTST0wIGFuZCB0aGVyZSBpcyBubyByZS1jbGFzc2lmaWNhdGlvbiB0aGUgU0Ygc2hv dWxkIGRpc2NhcmQgdGhlIHBhY2tldA0KDQpBbHNvIGFuIFNGRiBzaG91bGQgZm9yd2FyZC9oYW5k bGUgcGFja2V0cyB3aXRoIE5TSCB3aXRoIFNJPTEgb3IgU0k9MC4NCg0KRG8geW91IGFncmVlPw0K DQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBKYW1lcyBOIEd1aWNoYXJkDQpTZW50OiBxdWludGEtZmVpcmEsIDkgZGUgZmV2ZXJlaXJvIGRl IDIwMTcgMTY6MjUNClRvOiBGYWJyaWNpbyBGZXJyYXo7IERvbGdhbm93LCBBbmRyZXcgKE5va2lh IC0gU0cpOyBEYXZlIERvbHNvbjsgRXJpYyBDIFJvc2VuOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1l bnQNCg0KSGkgRmFicmljaW8sDQoNCldlbGNvbWUhDQoNClllcywgcmVtb3ZhbCBvZiBOU0ggaXMg dGhlIHJlc3BvbnNpYmlsaXR5IG9mIGFuIFNGRiBvciBhIHJlLWNsYXNzaWZpZXIgKHNlY3Rpb24g NCwgYnVsbGV0IHBvaW50IDEgbGF5cyB0aGlzIG91dCkuIFdpdGggdGhlIGN1cnJlbnQgYXJjaGl0 ZWN0dXJlIHRoZSBTRiBkb2VzIG5vdCBjYXJlIHdoYXQgU0kgdmFsdWUgaXQgZ2V0cywgaXQganVz dCBuZWVkcyB0byB3b3JyeSBhYm91dCBkZWNyZW1lbnRpbmcgaXQsIGFuZCBsZWF2ZSBpdCB1cCB0 byB0aGUgU0ZGIHRvIGV2YWx1YXRlIHRoZSBTSSB2YWx1ZSBhbmQgYXNzb2NpYXRlZCBhY3Rpb24u DQoNCkppbQ0KDQpGcm9tOiBGYWJyaWNpbyBGZXJyYXogW21haWx0bzpmYWJyaWNpby1mZXJyYXpA dGVsZWNvbS5wdF0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyA3OjEzIEFNDQpU bzogRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRykgPGFuZHJldy5kb2xnYW5vd0Bub2tpYS5j b208bWFpbHRvOmFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+PjsgRGF2ZSBEb2xzb24gPGRkb2xz b25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+OyBFcmljIEMgUm9z ZW4gPGVyb3NlbkBqdW5pcGVyLm5ldDxtYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0Pj47IEphbWVz IE4gR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbTxtYWlsdG86amFtZXMubi5n dWljaGFyZEBodWF3ZWkuY29tPj47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K U3ViamVjdDogUkU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudA0KDQpIaSBhbGws DQpJ4oCZbSBuZXcgaGVyZSAoanVzdCByZWFkIHRoZSBkcmFmdCBsYXN0IHdlZWspIGJ1dCBhY2Nv cmRpbmcgdG8gY2hhcHRlciA0IChjaGVjayBmaWd1cmUgOCBmb3IgZXhhbXBsZSksIGFuIFNGIGlz IG5vdCBhbGxvd2VkIHRvIGluc2VydCBvciByZW1vdmUgTlNILiBUaGUgcmVtb3ZhbCBvZiBOU0gg aXMgcmVwb25zYWJpbGl0eSBvZiB0aGUgU1NGLCByaWdodD8NCg0KICBGaWd1cmUgOCBtYXBzIGVh Y2ggb2YgdGhlIGZvdXIgYWN0aW9ucyBhYm92ZSB0byB0aGUgY29tcG9uZW50cyBpbiB0aGUNCiAg IFNGQyBhcmNoaXRlY3R1cmUgdGhhdCBjYW4gcGVyZm9ybSBpdC4NCg0KKy0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSsN CnwgICAgICAgICAgICAgICAgfCAgSW5zZXJ0ICAgICAgICAgfFNlbGVjdCB8ICAgVXBkYXRlICAg ICAgIHxTZXJ2aWNlICB8DQp8ICAgICAgICAgICAgICAgIHwgIG9yIHJlbW92ZSBOU0ggIHxTZXJ2 aWNlfCAgICBOU0ggICAgICAgICB8cG9saWN5ICAgfA0KfCAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICB8RnVuY3Rpb258ICAgICAgICAgICAgICAgfHNlbGVjdGlvbnwNCnwgQ29tcG9u ZW50ICAgICAgKy0tLS0tLS0tKy0tLS0tLS0tK1BhdGggICArLS0tLS0tLS0tLS0tLS0tLSsgICAg ICAgICB8DQp8ICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCBEZWMu ICAgfFVwZGF0ZSB8ICAgICAgICAgfA0KfCAgICAgICAgICAgICAgICB8IEluc2VydCB8IFJlbW92 ZSB8ICAgICAgIHxTZXJ2aWNlIHxDb250ZXh0fCAgICAgICAgIHwNCnwgICAgICAgICAgICAgICAg fCAgICAgICAgfCAgICAgICAgfCAgICAgICB8IEluZGV4ICB8SGVhZGVyIHwgICAgICAgICB8DQor LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0t LS0rLS0tLS0tLS0tKw0KfCAgICAgICAgICAgICAgICB8ICAgKyAgICB8ICAgKyAgICB8ICAgICAg IHwgICAgICAgIHwgICArICAgfCAgICAgICAgIHwNCnxDbGFzc2lmaWVyICAgICAgfCAgICAgICAg fCAgICAgICAgfCAgICAgICB8ICAgICAgICB8ICAgICAgIHwgICAgICAgICB8DQorLS0tLS0tLS0t LS0tLS0tICstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0t LS0tKw0KfFNlcnZpY2UgRnVuY3Rpb258ICAgICAgICB8ICAgKyAgICB8ICArICAgIHwgICAgICAg IHwgICAgICAgfCAgICAgICAgIHwNCnxGb3J3YXJkZXIoU0ZGKSAgfCAgICAgICAgfCAgICAgICAg fCAgICAgICB8ICAgICAgICB8ICAgICAgIHwgICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tICst LS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tKw0KfFNl cnZpY2UgICAgICAgICB8ICAgICAgICB8ICAgICAgICB8ICAgICAgIHwgICArICAgIHwgICArICAg fCAgICsgICAgIHwNCnxGdW5jdGlvbiAgKFNGKSAgfCAgICAgICAgfCAgICAgICAgfCAgICAgICB8 ICAgICAgICB8ICAgICAgIHwgICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tICstLS0tLS0tLSst LS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tKw0KfFNGQyBQcm94eSAg ICAgICB8ICAgKyAgICB8ICAgKyAgICB8ICAgICAgIHwgICArICAgIHwgICAgICAgfCAgICAgICAg IHwNCistLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0r LS0tLS0tLSstLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgICBGaWd1cmUgODogTlNIIEFj dGlvbiBhbmQgUm9sZSBNYXBwaW5nDQoNCg0KQW4gU0YgY291bGQgcmVjZWl2ZSBhbiBOU0ggcGFj a2V0IHdpdGggYW4gU0kgb2YgMSwgYW5kIHJlY2xhc3NpZnkgaXQgdG8gYSBkaWZmZXJlbnQgU1BJ IGFuZCBTSSwgcmlnaHQ/IFNvIHdoZW4gYSBTRiByZWNlaXZlcyBhIE5TSCBwYWNrZXQgd2l0aCBT SSA9IDEgdGhhdCBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFucyBhIG5vbiB2YWxpZCBwYWNrZXQu DQpBbmQgdGhhdCBjYW4gZXZlbiB3b3JrIGZvciBTST0wLCBzaW5jZSB5b3UgZGVjcmVtZW50IHRo ZSBTSSBpbiB0aGUgZWdyZXNzLg0KDQpGYWJyaWNpbw0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRG9sZ2Fub3csIEFuZHJldyAoTm9raWEg LSBTRykNClNlbnQ6IHF1aW50YS1mZWlyYSwgOSBkZSBmZXZlcmVpcm8gZGUgMjAxNyAwMTo1MQ0K VG86IERhdmUgRG9sc29uOyBFcmljIEMgUm9zZW47IEphbWVzIE4gR3VpY2hhcmQ7IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIE5TSCBTZXJ2aWNl IEluZGV4IERlY3JlbWVudA0KDQpJIGFzc3VtZWQgdGhhdCBpZiB3ZSBnZXQgdmFsdWUgMSB3ZSBw cm9jZXNzIHRoZW4gZm9yd2FyZCB3aXRob3V0IE5TSCBoZWFkZXIgKGkuZS4pIHRoaXMgaXMgdGhl IGxhc3QgU0YgcHJvY2Vzc2luZy4NCg0KU28gd2l0aCB0aGF0IGFzc3VtcHRpb24sIGEgbW9yZSBl eHBsaWNpdCB0ZXh0IHdvdWxkIGJlOg0KDQpBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFu IE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGFmdGVy IHBlcmZvcm1pbmcgYWxsIHJlcXVpcmVkIGxvY2FsIHByb2Nlc3NpbmcgYW5kIGJlZm9yZSBmb3J3 YXJkaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGLiBJZiB0aGUgcmVzdWx0aW5nIFNJIGlz IDAsIHRoZSBTRiBNVVNUIHJlbW92ZSB0aGUgTlNIIGhlYWRlciBiZWZvcmUgZm9yd2FyZGluZyB0 aGUgcGFja2V0Lg0KDQpBbmRyZXcNCkZyb206IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERhdmUgRG9sc29uIDxkZG9s c29uQHNhbmR2aW5lLmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+Pg0KRGF0ZTogVGh1 cnNkYXksIEZlYnJ1YXJ5IDksIDIwMTcgYXQgMjowNCBBTQ0KVG86IEVyaWMgUm9zZW4gPGVyb3Nl bkBqdW5pcGVyLm5ldDxtYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0Pj4sIEphbWVzIE4gR3VpY2hh cmQgPGphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWljaGFyZEBo dWF3ZWkuY29tPj4sICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZp Y2UgSW5kZXggRGVjcmVtZW50DQoNCkVyaWMsDQpJIHdhcyBuZXZlciBxdWl0ZSBoYXBweSB3aXRo IHRoZSBvdXRjb21lIHRoYXQgbmVpdGhlciAwIG5vciAxIGlzIGEgdmFsaWQgU0kuDQooQmVjYXVz ZSBpZiByZWNlaXZlZCB3aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRlY3JlbWVudGVkIGFuZCBkaXNj YXJkZWQuKQ0KDQpJdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2YWx1ZS4NCg0KSSBndWVzcyBJ 4oCZbSBpbnRlcmVzdGVkIHRvIGtub3cgaWYgdGhhdCBpcyBpbXBvcnRhbnQgdG8gb3RoZXIgaW1w bGVtZW50ZXJzLCBvciBpZiB0aGF0IHdhcyBldmVuIHRoZSBpbnRlbnRpb24/DQoNCg0KLURhdmUN Cg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRXJpYyBDIFJvc2VuDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3IDExOjUz IEFNDQpUbzogSmFtZXMgTiBHdWljaGFyZDsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50DQoNCk9u IDIvNy8yMDE3IDI6MjQgUE0sIEphbWVzIE4gR3VpY2hhcmQgd3JvdGU6DQpBIHJlcXVlc3Qgd2Fz IG1hZGUgdG8gYmUgbW9yZSBzcGVjaWZpYyBhbmQgdXBkYXRlIHRoZSB0ZXh0IGFzIGZvbGxvd3M6 DQoNCuKAnFNlcnZpY2UgaW5kZXggTVVTVCBiZSBkZWNyZW1lbnRlZCBieSBhIHZhbHVlIG9mIDEg YnkgU2VydmljZSBGdW5jdGlvbnMgb3IgYnkgU0ZDIFByb3h5IG5vZGVzIGFmdGVyIHBlcmZvcm1p bmcgcmVxdWlyZWQgc2VydmljZXMg4oCm4oCdDQoNCkEgY291cGxlIG9mIG9ic2VydmF0aW9uczoN Cg0KLSBUaGUgdGVybSAiU0ZDIFByb3h5IG5vZGUiIGlzIG5vdCBkZWZpbmVkIGluIGVpdGhlciB0 aGUgTlNIIGRyYWZ0IG9yIGluIFJGQyA3NjY1LiAgSSB0aGluayB0aGUgaW50ZW50aW9uIGhlcmUg aXMgdG8gc2F5ICJTRkMgUHJveHkiLg0KDQotIElzIHRoZSBpbnRlbnRpb24gdGhhdCB0aGUgU0kg cmVtYWluIHVuY2hhbmdlZCB3aGlsZSB0aGUgU0YgaXMgb3BlcmF0aW5nIG9uIHRoZSBwYWNrZXQs IG9yIGlzIHRoZSBpbnRlbnRpb24gb25seSB0aGF0IHRoZSBTSSBiZSBkZWNyZW1lbnRlZCBiZWZv cmUgdGhlIHBhY2tldCBpcyBkZWxpdmVyZWQgYnkgdGhlIFNGIG9yIFNGQyBQcm94eSB0byBhbiBT RkY/DQoNCkknZCBzdWdnZXN0IGVpdGhlcjoNCg0KIkFuIFNGIG9yIFNGQyBQcm94eSByZWNlaXZp bmcgYW4gTlNILWVuY2Fwc3VsYXRlZCBwYWNrZXQgTVVTVCBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEg YmVmb3JlIGRlbGl2ZXJpbmcgdGhlIHBhY2tldCB0byB0aGUgbmV4dCBTRkYiDQoNCm9yDQoNCiJB biBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1V U1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8g dGhlIG5leHQgU0ZGLCBidXQgbm90IHVudGlsIHRoZSBTRiBoYXMgZmluaXNoZWQgYWxsIGl0cyBv dGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQiDQoNCmRlcGVuZGluZyB1cG9uIHdoaWNoIGlz IGludGVuZGVkLg0KDQpJIHRoaW5rIGFuIGltcGxpY2F0aW9uIG9mIHRoZXNlIHByb2NlZHVyZXMg aXMgdGhhdCBhbiBTSSB2YWx1ZSBvZiAxIGlzIG5vdCB2YWxpZC4gIElmIGFuIFNGIGdldHMgYW4g TlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIHRoZSBTRiB3aWxsIGRlY3JlbWVudCB0aGUgU0kg KHNldHRpbmcgaXQgdG8gMCksIHNlbmQgdGhlIHBhY2tldCB0byBhbiBTRkYsIGFuZCB0aGUgU0ZG IHdpbGwgZGlzY2FyZCBpdCwgYmVjYXVzZSAwIGlzIGFuIGludmFsaWQgU0kgdmFsdWUuICBJcyB0 aGF0IHRoZSBpbnRlbnRpb24/DQoNClRoZSBkcmFmdCBtYWtlcyBpdCBjbGVhciAod2VsbCwgc29y dCBvZikgdGhhdCBhbiBTRkYgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQgd2l0aCBhbiBTSSBvZiAw LCBidXQgZG9lcyBub3Qgc2VlbSB0byBzYXkgdGhhdCBhbiBTRiBvciBTRkMgUHJveHkgc2hvdWxk IGRpc2NhcmQgYSBwYWNrZXQgaXQgcmVjZWl2ZXMgd2l0aCBhbiBTSSBvZiAwLiAgSXQgd291bGQg cHJvYmFibHkgYmUgYSBnb29kIGlkZWEgdG8gc2F5IHRoYXQuDQoNClNvbWUgdGV4dCBpbiB0aGUg ZHJhZnQgKGUuZy4sIHNlY3Rpb24gNy4xKSBzdGF0ZXMgdGhhbiBhbiBTRkYgc2hvdWxkIGRpc2Nh cmQgYSBwYWNrZXQgd2l0aCBhbiBTSSBvZiB6ZXJvLCBidXQgb3RoZXIgdGV4dCBpbiB0aGUgZHJh ZnQgKGUuZy4sIHNlY3Rpb24gMy4zKSBvbmx5IHNheXMgdGhhdCBhbiBTRkYgc2hvdWxkIGxvZyBh biBlcnJvciBpZiBpdCBzZWVzIGFuIFNJIG9mIHplcm8uICBJdCdzIHByb2JhYmx5IGJlc3QgdG8g Y2hhbmdlIHRoZSB0ZXh0IGluIDMuMy4gdG8gc2F5ICJTSE9VTEQgZ2VuZXJhdGUgYW4gZXJyb3Iv bG9nIG1lc3NhZ2UgYW5kIE1VU1QgZGlzY2FyZCB0aGUgcGFja2V0Iiwgb3Igc29tZXRoaW5nIHNp bWlsYXIuDQo= --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB68F0SJCEML701CHMchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNr O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTkyODkxNTg1Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5OTgxNTc0NTAgMTM1NjU5NTQzIDEzNTY1 OTU0NSAxMzU2NTk1NDcgMTM1NjU5NTM1IDEzNTY1OTU0NSAxMzU2NTk1NDcgMTM1NjU5NTM1IDEz NTY1OTU0NSAxMzU2NTk1NDc7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNv LWxpc3QtaWQ6MTkyMjEzNTU2MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTgyNzE3OTY5MCAtMTI1NzcyNDgwNiAxMzU2NTk1MjMgMTM1NjU5NTI1IDEz NTY1OTUyMSAxMzU2NTk1MjMgMTM1NjU5NTI1IDEzNTY1OTUyMSAxMzU2NTk1MjMgMTM1NjU5NTI1 O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674OoOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ob3QgZXhhY3RseS4g U2VjdGlvbiAzLjMgc3BlY2lmaWVzIOKAnFRoZSB2YWx1ZSB6ZXJvIGZvciBTSSBpcyBub3QgdmFs aWQgYW5kIGluZGljYXRlcyBhIGJyb2tlbiBTRkMgb3IgbWFsZnVuY3Rpb25pbmcgU0bigJ0gLi4g SW4gb3RoZXIgd29yZHMgYW4gU0Ygc2hvdWxkIG5ldmVyIHJlY2VpdmUNCiBhbiBOU0ggcGFja2V0 IHdpdGggU0kgPSAwLiBOb3RlIHRoYXQgaWYgdGhpcyBoYXBwZW5lZCB0aGVuIGVpdGhlciBhKSBh IGNsYXNzaWZpZXIgc2V0IHRoZSBTSSBpbmNvcnJlY3RseSwgb3IgYikgYSByZS1jbGFzc2lmaWVy IHNldCB0aGUgU0kgaW5jb3JyZWN0bHksIG9yIGMpIGFuIHVwc3RyZWFtIFNGIHNldCB0aGUgU0kg aW5jb3JyZWN0bHk7IGFsbCBvZiB0aGVzZSBjYXNlcyBzaG91bGQgYmUgY2F1Z2h0IGJ5IHRoZSBT RkYgd2hvc2Ugam9iIGl0DQogaXMgdG8gZGlzY2FyZCBOU0ggcGFja2V0cyB3aXRoIFNJID0gMC4g PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KaW08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBGYWJyaWNpbyBGZXJyYXog W21haWx0bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgRmVicnVhcnkgMDksIDIwMTcgMTE6NDkgQU08YnI+DQo8Yj5Ubzo8L2I+IEphbWVz IE4gR3VpY2hhcmQgJmx0O2phbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbSZndDs7IERvbGdhbm93 LCBBbmRyZXcgKE5va2lhIC0gU0cpICZsdDthbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tJmd0Ozsg RGF2ZSBEb2xzb24gJmx0O2Rkb2xzb25Ac2FuZHZpbmUuY29tJmd0OzsgRXJpYyBDIFJvc2VuICZs dDtlcm9zZW5AanVuaXBlci5uZXQmZ3Q7OyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5IaSBKaW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9uZSBtb3JlIHF1ZXN0aW9uIGFib3V0IHRoZSBTSS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiAzIHN0 YXRlcyB0aGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXJ2aWNlIEluZGV4IChTSSk6IHByb3ZpZGVzIGxvY2F0 aW9uIHdpdGhpbiB0aGUgU0ZQLiBUaGUgaW5pdGlhbCBjbGFzc2lmaWVyIE1VU1Qgc2V0IHRoZSBh cHByb3ByaWF0ZSBTSSB2YWx1ZSBmb3IgYSBnaXZlbiBjbGFzc2lmaWNhdGlvbiByZXN1bHQuIFRo ZSBpbml0aWFsIFNJIHZhbHVlIFNIT1VMRCBkZWZhdWx0IHRvIDI1NS4gSG93ZXZlciwgdGhlIGNs YXNzaWZpZXIgTVVTVCBhbGxvdyBjb25maWd1cmF0aW9uDQogb2Ygb3RoZXIgU0kgdmFsdWVzLiA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlcnZpY2UgSW5kZXggTVVTVCBi ZSBkZWNyZW1lbnRlZCBieSBTZXJ2aWNlIEZ1bmN0aW9ucyBvciBieSBTRkMgUHJveHkgbm9kZXMg YWZ0ZXIgcGVyZm9ybWluZyByZXF1aXJlZCBzZXJ2aWNlcyBhbmQgdGhlIG5ldyBkZWNyZW1lbnRl ZCBTSSB2YWx1ZSBNVVNUIGJlIHVzZWQgaW4gdGhlIGVncmVzcyBOU0ggcGFja2V0Lg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW5pdGlhbCBDbGFzc2lmaWVyIE1V U1Qgc2VuZCB0aGUgcGFja2V0IHRvIHRoZSBmaXJzdCBTRkYgaW4gdGhlIGlkZW50aWZpZWQgU0ZQ IGZvciBmb3J3YXJkaW5nIGFsb25nIGFuIFNGUC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgcmUtY2xhc3NpZmljYXRpb24gb2NjdXJzLCBhbmQgdGhhdCByZS1jbGFz c2lmaWNhdGlvbiByZXN1bHRzIGluIGEgbmV3IFNQSSwgdGhlIChyZSljbGFzc2lmaWVyIGlzLCBp biBlZmZlY3QsIHRoZSBpbml0aWFsIGNsYXNzaWZpZXIgZm9yIHRoZSByZXN1bHRhbnQgU1BJLjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRodXM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEpPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SW5pdGlhbCBTSSB2YWx1ZSBzaG91bGQgYmUgMjU1IGJ1dCBvdGhlciB2 YWx1ZXMgY2FuIGJlIGNvbmZpZ3VyZWQgYnkgdGhlIGNsYXNzaWZpZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5i KTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNGIGRlY3JlbWVudHMgdGhlIFNJIHZh bHVlIG9uIHRoZSBlZ3Jlc3MgTlNIIHBhY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yyk8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiByZS1jbGFzc2lmaWNhdGlvbiBvY2N1cnMgd2l0 aCBuZXcgU1BJLCB0aGUgcmUtY2xhc3NpZmllciBpcyB0aGUgaW5pdGlhbCBjbGFzc2lmaWVyLCBz byBieSAmbmJzcDthKSwgU0kgc2hvdWxkIGJlIGFnYWluIDI1NSBvciBvdGhlciB2YWx1ZQ0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbyBhbnkgU0kgdmFsdWUg Y2FuIGJlIHJlY2VpdmUgYnkgYW4gU0YsIGV2ZW4gMSBvciAwIGJlY2F1c2U6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DqDxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIFNJPTEgYW5kIHRo ZXJlIGlzIG5vIHJlLWNsYXNzaWZpY2F0aW9uLCB0aGUgZWdyZXNzIE5TSCB3aWxsIGhhdmUgU0k9 MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w6g8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPg0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J ZiBTST0wIGFuZCB0aGVyZSBpcyByZS1jbGFzc2lmaWNhdGlvbiB3aXRoIG5ldyBTUEksIHRoZSBl Z3Jlc3MgTlNIIHdpbGwgaGF2ZSBhIG5ldyBTUEkgYW5kIGEgU0k9IDI1NSBvciBvdGhlciB2YWx1 ZSwgYXMgc3RhdGVkIGluIGEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVs MSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+w6g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPg0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JZiBTST0wIGFuZCB0aGVyZSBpcyBubyByZS1jbGFzc2lmaWNhdGlv biB0aGUgU0Ygc2hvdWxkIGRpc2NhcmQgdGhlIHBhY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+QWxzbyBhbiBTRkYgc2hvdWxkIGZvcndhcmQvaGFuZGxlIHBh Y2tldHMgd2l0aCBOU0ggd2l0aCBTST0xIG9yIFNJPTAuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5EbyB5b3UgYWdyZWU/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkphbWVzIE4gR3VpY2hh cmQ8YnI+DQo8Yj5TZW50OjwvYj4gcXVpbnRhLWZlaXJhLCA5IGRlIGZldmVyZWlybyBkZSAyMDE3 IDE2OjI1PGJyPg0KPGI+VG86PC9iPiBGYWJyaWNpbyBGZXJyYXo7IERvbGdhbm93LCBBbmRyZXcg KE5va2lhIC0gU0cpOyBEYXZlIERvbHNvbjsgRXJpYyBDIFJvc2VuOw0KPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlBUIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgRmFicmljaW8sPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5XZWxjb21lITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+WWVzLCByZW1vdmFsIG9mIE5TSCBpcyB0aGUgcmVzcG9uc2liaWxpdHkg b2YgYW4gU0ZGIG9yIGEgcmUtY2xhc3NpZmllciAoc2VjdGlvbiA0LCBidWxsZXQgcG9pbnQgMSBs YXlzIHRoaXMgb3V0KS4gV2l0aCB0aGUgY3VycmVudCBhcmNoaXRlY3R1cmUgdGhlIFNGIGRvZXMg bm90DQogY2FyZSB3aGF0IFNJIHZhbHVlIGl0IGdldHMsIGl0IGp1c3QgbmVlZHMgdG8gd29ycnkg YWJvdXQgZGVjcmVtZW50aW5nIGl0LCBhbmQgbGVhdmUgaXQgdXAgdG8gdGhlIFNGRiB0byBldmFs dWF0ZSB0aGUgU0kgdmFsdWUgYW5kIGFzc29jaWF0ZWQgYWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmltPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gRmFicmlj aW8gRmVycmF6IFs8YSBocmVmPSJtYWlsdG86ZmFicmljaW8tZmVycmF6QHRlbGVjb20ucHQiPm1h aWx0bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g VGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAyMDE3IDc6MTMgQU08YnI+DQo8Yj5Ubzo8L2I+IERvbGdh bm93LCBBbmRyZXcgKE5va2lhIC0gU0cpICZsdDs8YSBocmVmPSJtYWlsdG86YW5kcmV3LmRvbGdh bm93QG5va2lhLmNvbSI+YW5kcmV3LmRvbGdhbm93QG5va2lhLmNvbTwvYT4mZ3Q7OyBEYXZlIERv bHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tIj5kZG9sc29uQHNh bmR2aW5lLmNvbTwvYT4mZ3Q7OyBFcmljIEMgUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplcm9z ZW5AanVuaXBlci5uZXQiPmVyb3NlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7Ow0KIEphbWVzIE4gR3Vp Y2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20iPmph bWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NmY10g TlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlBUIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J4oCZbSBuZXcgaGVyZSAoanVzdCBy ZWFkIHRoZSBkcmFmdCBsYXN0IHdlZWspIGJ1dCBhY2NvcmRpbmcgdG8gY2hhcHRlciA0IChjaGVj ayBmaWd1cmUgOCBmb3IgZXhhbXBsZSksIGFuIFNGIGlzIG5vdCBhbGxvd2VkIHRvIGluc2VydCBv ciByZW1vdmUgTlNILiBUaGUgcmVtb3ZhbA0KIG9mIE5TSCBpcyByZXBvbnNhYmlsaXR5IG9mIHRo ZSBTU0YsIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjcuMHB0 IDcuMHB0IDcuMHB0IDcuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7IEZpZ3VyZSA4IG1hcHMgZWFjaCBvZiB0aGUgZm91ciBhY3Rpb25zIGFi b3ZlIHRvIHRoZSBjb21wb25lbnRzIGluIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNG RkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFNGQyBh cmNoaXRlY3R1cmUgdGhhdCBjYW4gcGVyZm9ybSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3Vu ZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+JiM0MzstLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7 YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBJbnNlcnQmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfFNlbGVjdCB8Jm5ic3A7Jm5ic3A7 IFVwZGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8U2VydmljZSZuYnNw OyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs bCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsg b3IgcmVtb3ZlIE5TSCZuYnNwOyB8U2VydmljZXwmbmJzcDsmbmJzcDsmbmJzcDsgTlNIJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxwb2xpY3kmbmJzcDsm bmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh ay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxGdW5jdGlvbnwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfHNlbGVjdGlvbnw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDoj RkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwgQ29tcG9uZW50Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MztQ YXRoJm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBEZWMuJm5ic3A7Jm5ic3A7IHxV cGRhdGUgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSW5zZXJ0IHwg UmVtb3ZlIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfFNlcnZpY2UgfENv bnRleHR8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCBJbmRleCZuYnNwOyB8SGVhZGVyIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i cmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0t LS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tJiM0 MzstLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i cmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsg JiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk LWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58Q2xhc3NpZmllciZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4x NXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m IzQzOy0tLS0tLS0tLS0tLS0tLSAmIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0t LSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLSYjNDM7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4x NXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58 U2VydmljZSBGdW5jdGlvbnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnxGb3J3YXJkZXIo U0ZGKSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0 O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQz Oy0tLS0tLS0tLS0tLS0tLSAmIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYj NDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0 O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58U2Vy dmljZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsgJiM0MzsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij58RnVuY3Rpb24mbmJzcDsgKFNGKSZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3 b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLS0tLS0tLSAmIzQz Oy0tLS0tLS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0t LS0mIzQzOy0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3 b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58U0ZDIFByb3h5Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7LS0tLS0t LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0t LS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEZpZ3VyZSA4OiBOU0ggQWN0aW9uIGFuZCBSb2xlIE1hcHBpbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkFuIFNGIGNvdWxkIHJlY2VpdmUgYW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIGFuZCBy ZWNsYXNzaWZ5IGl0IHRvIGEgZGlmZmVyZW50IFNQSSBhbmQgU0ksIHJpZ2h0PyBTbyB3aGVuIGEg U0YgcmVjZWl2ZXMgYSBOU0ggcGFja2V0IHdpdGggU0kgPSAxIHRoYXQgZG9lcw0KIG5vdCBuZWNl c3NhcmlseSBtZWFucyBhIG5vbiB2YWxpZCBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCB0 aGF0IGNhbiBldmVuIHdvcmsgZm9yIFNJPTAsIHNpbmNlIHlvdSBkZWNyZW1lbnQgdGhlIFNJIGlu IHRoZSBlZ3Jlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5G YWJyaWNpbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi PiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RG9sZ2Fub3csIEFuZHJl dyAoTm9raWEgLSBTRyk8YnI+DQo8Yj5TZW50OjwvYj4gcXVpbnRhLWZlaXJhLCA5IGRlIGZldmVy ZWlybyBkZSAyMDE3IDAxOjUxPGJyPg0KPGI+VG86PC9iPiBEYXZlIERvbHNvbjsgRXJpYyBDIFJv c2VuOyBKYW1lcyBOIEd1aWNoYXJkOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNm Y0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIE5TSCBTZXJ2aWNl IEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJQVCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPkkgYXNzdW1lZCB0aGF0IGlmIHdlIGdldCB2YWx1ZSAxIHdlIHByb2Nlc3MgdGhlbiBm b3J3YXJkIHdpdGhvdXQgTlNIIGhlYWRlciAoaS5lLikgdGhpcyBpcyB0aGUgbGFzdCBTRiBwcm9j ZXNzaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ U28gd2l0aCB0aGF0IGFzc3VtcHRpb24sIGEgbW9yZSBleHBsaWNpdCB0ZXh0IHdvdWxkIGJlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+QW4gU0Ygb3Ig U0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3Jl bWVudCB0aGUgU0kgYnkgMSBhZnRlciBwZXJmb3JtaW5nIGFsbCByZXF1aXJlZCBsb2NhbCBwcm9j ZXNzaW5nIGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUNCiBwYWNrZXQgdG8gdGhlIG5leHQgU0ZG LiBJZiB0aGUgcmVzdWx0aW5nIFNJIGlzIDAsIHRoZSBTRiBNVVNUIHJlbW92ZSB0aGUgTlNIIGhl YWRlciBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnNmYyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9u IGJlaGFsZiBvZiBEYXZlIERvbHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRkb2xzb25Ac2FuZHZp bmUuY29tIj5kZG9sc29uQHNhbmR2aW5lLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRo dXJzZGF5LCBGZWJydWFyeSA5LCAyMDE3IGF0IDI6MDQgQU08YnI+DQo8Yj5UbzogPC9iPkVyaWMg Um9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplcm9zZW5AanVuaXBlci5uZXQiPmVyb3NlbkBqdW5p cGVyLm5ldDwvYT4mZ3Q7LCBKYW1lcyBOIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFt ZXMubi5ndWljaGFyZEBodWF3ZWkuY29tIj5qYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb208L2E+ Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERl Y3JlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkVyaWMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JIHdhcyBuZXZlciBxdWl0ZSBoYXBweSB3aXRoIHRoZSBvdXRjb21lIHRoYXQgbmVpdGhlciAw IG5vciAxIGlzIGEgdmFsaWQgU0kuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4oQmVjYXVzZSBpZiByZWNlaXZlZCB3aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRlY3Jl bWVudGVkIGFuZCBkaXNjYXJkZWQuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2YWx1ZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SSBndWVzcyBJ4oCZbSBpbnRlcmVzdGVkIHRvIGtub3cgaWYgdGhhdCBp cyBpbXBvcnRhbnQgdG8gb3RoZXIgaW1wbGVtZW50ZXJzLCBvciBpZiB0aGF0IHdhcyBldmVuIHRo ZSBpbnRlbnRpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LURhdmU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gc2ZjIFs8YSBocmVm PSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgQyBSb3Nlbjxicj4NCjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3IDExOjUzIEFNPGJyPg0KPGI+VG86PC9iPiBK YW1lcyBOIEd1aWNoYXJkOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBE ZWNyZW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCk9u IDIvNy8yMDE3IDI6MjQgUE0sIEphbWVzIE4gR3VpY2hhcmQgd3JvdGU6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpBIHJlcXVlc3Qgd2Fz IG1hZGUgdG8gYmUgbW9yZSBzcGVjaWZpYyBhbmQgdXBkYXRlIHRoZSB0ZXh0IGFzIGZvbGxvd3M6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NCuKAnFNlcnZpY2UgaW5kZXggTVVTVCBiZSBkZWNyZW1lbnRlZCA8Yj5ieSBhIHZh bHVlIG9mIDE8L2I+IGJ5IFNlcnZpY2UgRnVuY3Rpb25zIG9yIGJ5IFNGQyBQcm94eSBub2RlcyBh ZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZpY2VzIOKApuKAnTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxicj4N CkEgY291cGxlIG9mIG9ic2VydmF0aW9uczo8YnI+DQo8YnI+DQotIFRoZSB0ZXJtICZxdW90O1NG QyBQcm94eSBub2RlJnF1b3Q7IGlzIG5vdCBkZWZpbmVkIGluIGVpdGhlciB0aGUgTlNIIGRyYWZ0 IG9yIGluIFJGQyA3NjY1LiZuYnNwOyBJIHRoaW5rIHRoZSBpbnRlbnRpb24gaGVyZSBpcyB0byBz YXkgJnF1b3Q7U0ZDIFByb3h5JnF1b3Q7Ljxicj4NCjxicj4NCi0gSXMgdGhlIGludGVudGlvbiB0 aGF0IHRoZSBTSSByZW1haW4gdW5jaGFuZ2VkIHdoaWxlIHRoZSBTRiBpcyBvcGVyYXRpbmcgb24g dGhlIHBhY2tldCwgb3IgaXMgdGhlIGludGVudGlvbiBvbmx5IHRoYXQgdGhlIFNJIGJlIGRlY3Jl bWVudGVkIGJlZm9yZSB0aGUgcGFja2V0IGlzIGRlbGl2ZXJlZCBieSB0aGUgU0Ygb3IgU0ZDIFBy b3h5IHRvIGFuIFNGRj8NCjxicj4NCjxicj4NCkknZCBzdWdnZXN0IGVpdGhlcjo8YnI+DQo8YnI+ DQomcXVvdDtBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQg cGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBw YWNrZXQgdG8gdGhlIG5leHQgU0ZGJnF1b3Q7PGJyPg0KPGJyPg0Kb3I8YnI+DQo8YnI+DQomcXVv dDtBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0 IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQg dG8gdGhlIG5leHQgU0ZGLCBidXQgbm90IHVudGlsIHRoZSBTRiBoYXMgZmluaXNoZWQgYWxsIGl0 cyBvdGhlciBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQmcXVvdDs8YnI+DQo8YnI+DQpkZXBlbmRp bmcgdXBvbiB3aGljaCBpcyBpbnRlbmRlZC48YnI+DQo8YnI+DQpJIHRoaW5rIGFuIGltcGxpY2F0 aW9uIG9mIHRoZXNlIHByb2NlZHVyZXMgaXMgdGhhdCBhbiBTSSB2YWx1ZSBvZiAxIGlzIG5vdCB2 YWxpZC4mbmJzcDsgSWYgYW4gU0YgZ2V0cyBhbiBOU0ggcGFja2V0IHdpdGggYW4gU0kgb2YgMSwg dGhlIFNGIHdpbGwgZGVjcmVtZW50IHRoZSBTSSAoc2V0dGluZyBpdCB0byAwKSwgc2VuZCB0aGUg cGFja2V0IHRvIGFuIFNGRiwgYW5kIHRoZSBTRkYgd2lsbCBkaXNjYXJkIGl0LCBiZWNhdXNlIDAg aXMgYW4gaW52YWxpZCBTSQ0KIHZhbHVlLiZuYnNwOyBJcyB0aGF0IHRoZSBpbnRlbnRpb24/PGJy Pg0KPGJyPg0KVGhlIGRyYWZ0IG1ha2VzIGl0IGNsZWFyICh3ZWxsLCBzb3J0IG9mKSB0aGF0IGFu IFNGRiBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCB3aXRoIGFuIFNJIG9mIDAsIGJ1dCBkb2VzIG5v dCBzZWVtIHRvIHNheSB0aGF0IGFuIFNGIG9yIFNGQyBQcm94eSBzaG91bGQgZGlzY2FyZCBhIHBh Y2tldCBpdCByZWNlaXZlcyB3aXRoIGFuIFNJIG9mIDAuJm5ic3A7IEl0IHdvdWxkIHByb2JhYmx5 IGJlIGEgZ29vZCBpZGVhIHRvIHNheSB0aGF0Ljxicj4NCjxicj4NClNvbWUgdGV4dCBpbiB0aGUg ZHJhZnQgKGUuZy4sIHNlY3Rpb24gNy4xKSBzdGF0ZXMgdGhhbiBhbiBTRkYgc2hvdWxkIGRpc2Nh cmQgYSBwYWNrZXQgd2l0aCBhbiBTSSBvZiB6ZXJvLCBidXQgb3RoZXIgdGV4dCBpbiB0aGUgZHJh ZnQgKGUuZy4sIHNlY3Rpb24gMy4zKSBvbmx5IHNheXMgdGhhdCBhbiBTRkYgc2hvdWxkIGxvZyBh biBlcnJvciBpZiBpdCBzZWVzIGFuIFNJIG9mIHplcm8uJm5ic3A7IEl0J3MgcHJvYmFibHkgYmVz dCB0byBjaGFuZ2UgdGhlIHRleHQNCiBpbiAzLjMuIHRvIHNheSAmcXVvdDtTSE9VTEQgZ2VuZXJh dGUgYW4gZXJyb3IvbG9nIG1lc3NhZ2UgYW5kIE1VU1QgZGlzY2FyZCB0aGUgcGFja2V0JnF1b3Q7 LCBvciBzb21ldGhpbmcgc2ltaWxhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB68F0SJCEML701CHMchina_-- From nobody Thu Feb 9 09:28:26 2017 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 3F027129C28 for ; Thu, 9 Feb 2017 09:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01, 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 c9_0jj3b1c7i for ; Thu, 9 Feb 2017 09:28:21 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661D3129485 for ; Thu, 9 Feb 2017 09:28:21 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 9 Feb 2017 12:28:19 -0500 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 12:28:19 -0500 From: Dave Dolson To: James N Guichard , Fabricio Ferraz , "Dolganow, Andrew (Nokia - SG)" , Eric C Rosen , "sfc@ietf.org" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA3q0iAAAgj/lAAHXyRAAAH1qCQAAPaRoAAAM/fAAAAeleAAAmxtlA= Date: Thu, 9 Feb 2017 17:28:19 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9870504746wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:28:24 -0000 --_000_E8355113905631478EFF04F5AA706E9870504746wtlexchp1sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IGNsZWFyIG9uIHdoeSB0aGlzIGlzIGJyb2tlbiwgb3Igd2h5IHRoaXMgcmVzdHJp Y3Rpb24gaXMgbWFkZS4NCkkgYWdyZWUgaXQgc2hvdWxkIG5vdCBiZSBzZW50IHRvIGFuIFNGLCBi dXQgYW4gU0ZGIGNvdWxkIG1hcCBhbiBTSSBvZiB6ZXJvIGludG8gYSBwYXRoIHRlcm1pbmF0aW9u Lg0KSS5lLiwgdGhlIGxhc3QgU0YgaW4gYSBwYXRoIGNvdWxkIGRlY3JlbWVudCBTSSBmcm9tIDEg dG8gMCwgYW5kIHRoZSBTRkYgY291bGQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNoYWluLg0KDQoNCkZy b206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFtZXMg TiBHdWljaGFyZA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAyMDE3IDEyOjAyIFBNDQpU bzogRmFicmljaW8gRmVycmF6OyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRGF2ZSBE b2xzb247IEVyaWMgQyBSb3Nlbjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gTlNI IFNlcnZpY2UgSW5kZXggRGVjcmVtZW50DQoNCk5vdCBleGFjdGx5LiBTZWN0aW9uIDMuMyBzcGVj aWZpZXMg4oCcVGhlIHZhbHVlIHplcm8gZm9yIFNJIGlzIG5vdCB2YWxpZCBhbmQgaW5kaWNhdGVz IGEgYnJva2VuIFNGQyBvciBtYWxmdW5jdGlvbmluZyBTRuKAnSAuLiBJbiBvdGhlciB3b3JkcyBh biBTRiBzaG91bGQgbmV2ZXIgcmVjZWl2ZSBhbiBOU0ggcGFja2V0IHdpdGggU0kgPSAwLiBOb3Rl IHRoYXQgaWYgdGhpcyBoYXBwZW5lZCB0aGVuIGVpdGhlciBhKSBhIGNsYXNzaWZpZXIgc2V0IHRo ZSBTSSBpbmNvcnJlY3RseSwgb3IgYikgYSByZS1jbGFzc2lmaWVyIHNldCB0aGUgU0kgaW5jb3Jy ZWN0bHksIG9yIGMpIGFuIHVwc3RyZWFtIFNGIHNldCB0aGUgU0kgaW5jb3JyZWN0bHk7IGFsbCBv ZiB0aGVzZSBjYXNlcyBzaG91bGQgYmUgY2F1Z2h0IGJ5IHRoZSBTRkYgd2hvc2Ugam9iIGl0IGlz IHRvIGRpc2NhcmQgTlNIIHBhY2tldHMgd2l0aCBTSSA9IDAuDQoNCkppbQ0KDQpGcm9tOiBGYWJy aWNpbyBGZXJyYXogW21haWx0bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdF0NClNlbnQ6IFRo dXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAxMTo0OSBBTQ0KVG86IEphbWVzIE4gR3VpY2hhcmQg PGphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbT47IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0g U0cpIDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPjsgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2Fu ZHZpbmUuY29tPjsgRXJpYyBDIFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ+OyBzZmNAaWV0Zi5v cmcNClN1YmplY3Q6IFJFOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQNCg0KSGkg SmltLA0KVGhhbmtzLg0KDQpPbmUgbW9yZSBxdWVzdGlvbiBhYm91dCB0aGUgU0kuDQoNClNlY3Rp b24gMyBzdGF0ZXMgdGhhdDoNCg0KU2VydmljZSBJbmRleCAoU0kpOiBwcm92aWRlcyBsb2NhdGlv biB3aXRoaW4gdGhlIFNGUC4gVGhlIGluaXRpYWwgY2xhc3NpZmllciBNVVNUIHNldCB0aGUgYXBw cm9wcmlhdGUgU0kgdmFsdWUgZm9yIGEgZ2l2ZW4gY2xhc3NpZmljYXRpb24gcmVzdWx0LiBUaGUg aW5pdGlhbCBTSSB2YWx1ZSBTSE9VTEQgZGVmYXVsdCB0byAyNTUuIEhvd2V2ZXIsIHRoZSBjbGFz c2lmaWVyIE1VU1QgYWxsb3cgY29uZmlndXJhdGlvbiBvZiBvdGhlciBTSSB2YWx1ZXMuDQpTZXJ2 aWNlIEluZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgYnkgU2VydmljZSBGdW5jdGlvbnMgb3IgYnkg U0ZDIFByb3h5IG5vZGVzIGFmdGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQgc2VydmljZXMgYW5kIHRo ZSBuZXcgZGVjcmVtZW50ZWQgU0kgdmFsdWUgTVVTVCBiZSB1c2VkIGluIHRoZSBlZ3Jlc3MgTlNI IHBhY2tldC4NClRoZSBpbml0aWFsIENsYXNzaWZpZXIgTVVTVCBzZW5kIHRoZSBwYWNrZXQgdG8g dGhlIGZpcnN0IFNGRiBpbiB0aGUgaWRlbnRpZmllZCBTRlAgZm9yIGZvcndhcmRpbmcgYWxvbmcg YW4gU0ZQLg0KSWYgcmUtY2xhc3NpZmljYXRpb24gb2NjdXJzLCBhbmQgdGhhdCByZS1jbGFzc2lm aWNhdGlvbiByZXN1bHRzIGluIGEgbmV3IFNQSSwgdGhlIChyZSljbGFzc2lmaWVyIGlzLCBpbiBl ZmZlY3QsIHRoZSBpbml0aWFsIGNsYXNzaWZpZXIgZm9yIHRoZSByZXN1bHRhbnQgU1BJLg0KDQpU aHVzOg0KDQphKSAgICAgIEluaXRpYWwgU0kgdmFsdWUgc2hvdWxkIGJlIDI1NSBidXQgb3RoZXIg dmFsdWVzIGNhbiBiZSBjb25maWd1cmVkIGJ5IHRoZSBjbGFzc2lmaWVyLg0KDQpiKSAgICAgIFNG IGRlY3JlbWVudHMgdGhlIFNJIHZhbHVlIG9uIHRoZSBlZ3Jlc3MgTlNIIHBhY2tldA0KDQpjKSAg ICAgICBJZiByZS1jbGFzc2lmaWNhdGlvbiBvY2N1cnMgd2l0aCBuZXcgU1BJLCB0aGUgcmUtY2xh c3NpZmllciBpcyB0aGUgaW5pdGlhbCBjbGFzc2lmaWVyLCBzbyBieSAgYSksIFNJIHNob3VsZCBi ZSBhZ2FpbiAyNTUgb3Igb3RoZXIgdmFsdWUNCg0KU28gYW55IFNJIHZhbHVlIGNhbiBiZSByZWNl aXZlIGJ5IGFuIFNGLCBldmVuIDEgb3IgMCBiZWNhdXNlOg0KDQrDqCBJZiBTST0xIGFuZCB0aGVy ZSBpcyBubyByZS1jbGFzc2lmaWNhdGlvbiwgdGhlIGVncmVzcyBOU0ggd2lsbCBoYXZlIFNJPTAN Cg0Kw6ggSWYgU0k9MCBhbmQgdGhlcmUgaXMgcmUtY2xhc3NpZmljYXRpb24gd2l0aCBuZXcgU1BJ LCB0aGUgZWdyZXNzIE5TSCB3aWxsIGhhdmUgYSBuZXcgU1BJIGFuZCBhIFNJPSAyNTUgb3Igb3Ro ZXIgdmFsdWUsIGFzIHN0YXRlZCBpbiBhKS4NCg0Kw6ggSWYgU0k9MCBhbmQgdGhlcmUgaXMgbm8g cmUtY2xhc3NpZmljYXRpb24gdGhlIFNGIHNob3VsZCBkaXNjYXJkIHRoZSBwYWNrZXQNCg0KQWxz byBhbiBTRkYgc2hvdWxkIGZvcndhcmQvaGFuZGxlIHBhY2tldHMgd2l0aCBOU0ggd2l0aCBTST0x IG9yIFNJPTAuDQoNCkRvIHlvdSBhZ3JlZT8NCg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFtZXMgTiBHdWljaGFyZA0KU2VudDogcXVp bnRhLWZlaXJhLCA5IGRlIGZldmVyZWlybyBkZSAyMDE3IDE2OjI1DQpUbzogRmFicmljaW8gRmVy cmF6OyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRGF2ZSBEb2xzb247IEVyaWMgQyBS b3Nlbjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Nm Y10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50DQoNCkhpIEZhYnJpY2lvLA0KDQpXZWxjb21l IQ0KDQpZZXMsIHJlbW92YWwgb2YgTlNIIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBhbiBTRkYg b3IgYSByZS1jbGFzc2lmaWVyIChzZWN0aW9uIDQsIGJ1bGxldCBwb2ludCAxIGxheXMgdGhpcyBv dXQpLiBXaXRoIHRoZSBjdXJyZW50IGFyY2hpdGVjdHVyZSB0aGUgU0YgZG9lcyBub3QgY2FyZSB3 aGF0IFNJIHZhbHVlIGl0IGdldHMsIGl0IGp1c3QgbmVlZHMgdG8gd29ycnkgYWJvdXQgZGVjcmVt ZW50aW5nIGl0LCBhbmQgbGVhdmUgaXQgdXAgdG8gdGhlIFNGRiB0byBldmFsdWF0ZSB0aGUgU0kg dmFsdWUgYW5kIGFzc29jaWF0ZWQgYWN0aW9uLg0KDQpKaW0NCg0KRnJvbTogRmFicmljaW8gRmVy cmF6IFttYWlsdG86ZmFicmljaW8tZmVycmF6QHRlbGVjb20ucHRdDQpTZW50OiBUaHVyc2RheSwg RmVicnVhcnkgMDksIDIwMTcgNzoxMyBBTQ0KVG86IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0g U0cpIDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPG1haWx0bzphbmRyZXcuZG9sZ2Fub3dAbm9r aWEuY29tPj47IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbTxtYWlsdG86ZGRvbHNv bkBzYW5kdmluZS5jb20+PjsgRXJpYyBDIFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ8bWFpbHRv OmVyb3NlbkBqdW5pcGVyLm5ldD4+OyBKYW1lcyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJk QGh1YXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbT4+OyBzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc2ZjXSBOU0ggU2Vydmlj ZSBJbmRleCBEZWNyZW1lbnQNCg0KSGkgYWxsLA0KSeKAmW0gbmV3IGhlcmUgKGp1c3QgcmVhZCB0 aGUgZHJhZnQgbGFzdCB3ZWVrKSBidXQgYWNjb3JkaW5nIHRvIGNoYXB0ZXIgNCAoY2hlY2sgZmln dXJlIDggZm9yIGV4YW1wbGUpLCBhbiBTRiBpcyBub3QgYWxsb3dlZCB0byBpbnNlcnQgb3IgcmVt b3ZlIE5TSC4gVGhlIHJlbW92YWwgb2YgTlNIIGlzIHJlcG9uc2FiaWxpdHkgb2YgdGhlIFNTRiwg cmlnaHQ/DQoNCiAgRmlndXJlIDggbWFwcyBlYWNoIG9mIHRoZSBmb3VyIGFjdGlvbnMgYWJvdmUg dG8gdGhlIGNvbXBvbmVudHMgaW4gdGhlDQogICBTRkMgYXJjaGl0ZWN0dXJlIHRoYXQgY2FuIHBl cmZvcm0gaXQuDQoNCistLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rDQp8ICAgICAgICAgICAgICAgIHwgIEluc2VydCAg ICAgICAgIHxTZWxlY3QgfCAgIFVwZGF0ZSAgICAgICB8U2VydmljZSAgfA0KfCAgICAgICAgICAg ICAgICB8ICBvciByZW1vdmUgTlNIICB8U2VydmljZXwgICAgTlNIICAgICAgICAgfHBvbGljeSAg IHwNCnwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfEZ1bmN0aW9ufCAgICAgICAg ICAgICAgIHxzZWxlY3Rpb258DQp8IENvbXBvbmVudCAgICAgICstLS0tLS0tLSstLS0tLS0tLStQ YXRoICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgfA0KfCAgICAgICAgICAgICAgICB8ICAg ICAgICB8ICAgICAgICB8ICAgICAgIHwgRGVjLiAgIHxVcGRhdGUgfCAgICAgICAgIHwNCnwgICAg ICAgICAgICAgICAgfCBJbnNlcnQgfCBSZW1vdmUgfCAgICAgICB8U2VydmljZSB8Q29udGV4dHwg ICAgICAgICB8DQp8ICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCBJ bmRleCAgfEhlYWRlciB8ICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0t LS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsNCnwgICAgICAgICAgICAg ICAgfCAgICsgICAgfCAgICsgICAgfCAgICAgICB8ICAgICAgICB8ICAgKyAgIHwgICAgICAgICB8 DQp8Q2xhc3NpZmllciAgICAgIHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICAgfCAg ICAgICB8ICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0tLSArLS0tLS0tLS0rLS0tLS0tLS0rLS0t LS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsNCnxTZXJ2aWNlIEZ1bmN0aW9ufCAgICAg ICAgfCAgICsgICAgfCAgKyAgICB8ICAgICAgICB8ICAgICAgIHwgICAgICAgICB8DQp8Rm9yd2Fy ZGVyKFNGRikgIHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAg ICAgICAgfA0KKy0tLS0tLS0tLS0tLS0tLSArLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0t LS0tLSstLS0tLS0tKy0tLS0tLS0tLSsNCnxTZXJ2aWNlICAgICAgICAgfCAgICAgICAgfCAgICAg ICAgfCAgICAgICB8ICAgKyAgICB8ICAgKyAgIHwgICArICAgICB8DQp8RnVuY3Rpb24gIChTRikg IHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICAgfA0K Ky0tLS0tLS0tLS0tLS0tLSArLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0t LS0tKy0tLS0tLS0tLSsNCnxTRkMgUHJveHkgICAgICAgfCAgICsgICAgfCAgICsgICAgfCAgICAg ICB8ICAgKyAgICB8ICAgICAgIHwgICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tKw0KDQogICAgICAg ICAgICAgICAgICAgRmlndXJlIDg6IE5TSCBBY3Rpb24gYW5kIFJvbGUgTWFwcGluZw0KDQoNCkFu IFNGIGNvdWxkIHJlY2VpdmUgYW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIGFuZCByZWNs YXNzaWZ5IGl0IHRvIGEgZGlmZmVyZW50IFNQSSBhbmQgU0ksIHJpZ2h0PyBTbyB3aGVuIGEgU0Yg cmVjZWl2ZXMgYSBOU0ggcGFja2V0IHdpdGggU0kgPSAxIHRoYXQgZG9lcyBub3QgbmVjZXNzYXJp bHkgbWVhbnMgYSBub24gdmFsaWQgcGFja2V0Lg0KQW5kIHRoYXQgY2FuIGV2ZW4gd29yayBmb3Ig U0k9MCwgc2luY2UgeW91IGRlY3JlbWVudCB0aGUgU0kgaW4gdGhlIGVncmVzcy4NCg0KRmFicmlj aW8NCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpDQpTZW50OiBxdWludGEtZmVpcmEsIDkg ZGUgZmV2ZXJlaXJvIGRlIDIwMTcgMDE6NTENClRvOiBEYXZlIERvbHNvbjsgRXJpYyBDIFJvc2Vu OyBKYW1lcyBOIEd1aWNoYXJkOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQNCg0KSSBhc3N1bWVk IHRoYXQgaWYgd2UgZ2V0IHZhbHVlIDEgd2UgcHJvY2VzcyB0aGVuIGZvcndhcmQgd2l0aG91dCBO U0ggaGVhZGVyIChpLmUuKSB0aGlzIGlzIHRoZSBsYXN0IFNGIHByb2Nlc3NpbmcuDQoNClNvIHdp dGggdGhhdCBhc3N1bXB0aW9uLCBhIG1vcmUgZXhwbGljaXQgdGV4dCB3b3VsZCBiZToNCg0KQW4g U0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNU IGRlY3JlbWVudCB0aGUgU0kgYnkgMSBhZnRlciBwZXJmb3JtaW5nIGFsbCByZXF1aXJlZCBsb2Nh bCBwcm9jZXNzaW5nIGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0 IFNGRi4gSWYgdGhlIHJlc3VsdGluZyBTSSBpcyAwLCB0aGUgU0YgTVVTVCByZW1vdmUgdGhlIE5T SCBoZWFkZXIgYmVmb3JlIGZvcndhcmRpbmcgdGhlIHBhY2tldC4NCg0KQW5kcmV3DQpGcm9tOiBz ZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xz b25Ac2FuZHZpbmUuY29tPj4NCkRhdGU6IFRodXJzZGF5LCBGZWJydWFyeSA5LCAyMDE3IGF0IDI6 MDQgQU0NClRvOiBFcmljIFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ8bWFpbHRvOmVyb3NlbkBq dW5pcGVyLm5ldD4+LCBKYW1lcyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5j b208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbT4+LCAic2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudA0KDQpFcmljLA0K SSB3YXMgbmV2ZXIgcXVpdGUgaGFwcHkgd2l0aCB0aGUgb3V0Y29tZSB0aGF0IG5laXRoZXIgMCBu b3IgMSBpcyBhIHZhbGlkIFNJLg0KKEJlY2F1c2UgaWYgcmVjZWl2ZWQgd2l0aCB2YWx1ZSBvZiAx LCBpdCBpcyBkZWNyZW1lbnRlZCBhbmQgZGlzY2FyZGVkLikNCg0KSXQgc2VlbXMgdG8gd2FzdGUg YW4gaW5kZXggdmFsdWUuDQoNCkkgZ3Vlc3MgSeKAmW0gaW50ZXJlc3RlZCB0byBrbm93IGlmIHRo YXQgaXMgaW1wb3J0YW50IHRvIG90aGVyIGltcGxlbWVudGVycywgb3IgaWYgdGhhdCB3YXMgZXZl biB0aGUgaW50ZW50aW9uPw0KDQoNCi1EYXZlDQoNCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgQyBSb3Nlbg0KU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAwOCwgMjAxNyAxMTo1MyBBTQ0KVG86IEphbWVzIE4gR3VpY2hhcmQ7IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIE5TSCBT ZXJ2aWNlIEluZGV4IERlY3JlbWVudA0KDQpPbiAyLzcvMjAxNyAyOjI0IFBNLCBKYW1lcyBOIEd1 aWNoYXJkIHdyb3RlOg0KQSByZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUgc3BlY2lmaWMgYW5k IHVwZGF0ZSB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KDQrigJxTZXJ2aWNlIGluZGV4IE1VU1QgYmUg ZGVjcmVtZW50ZWQgYnkgYSB2YWx1ZSBvZiAxIGJ5IFNlcnZpY2UgRnVuY3Rpb25zIG9yIGJ5IFNG QyBQcm94eSBub2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZpY2VzIOKApuKAnQ0K DQpBIGNvdXBsZSBvZiBvYnNlcnZhdGlvbnM6DQoNCi0gVGhlIHRlcm0gIlNGQyBQcm94eSBub2Rl IiBpcyBub3QgZGVmaW5lZCBpbiBlaXRoZXIgdGhlIE5TSCBkcmFmdCBvciBpbiBSRkMgNzY2NS4g IEkgdGhpbmsgdGhlIGludGVudGlvbiBoZXJlIGlzIHRvIHNheSAiU0ZDIFByb3h5Ii4NCg0KLSBJ cyB0aGUgaW50ZW50aW9uIHRoYXQgdGhlIFNJIHJlbWFpbiB1bmNoYW5nZWQgd2hpbGUgdGhlIFNG IGlzIG9wZXJhdGluZyBvbiB0aGUgcGFja2V0LCBvciBpcyB0aGUgaW50ZW50aW9uIG9ubHkgdGhh dCB0aGUgU0kgYmUgZGVjcmVtZW50ZWQgYmVmb3JlIHRoZSBwYWNrZXQgaXMgZGVsaXZlcmVkIGJ5 IHRoZSBTRiBvciBTRkMgUHJveHkgdG8gYW4gU0ZGPw0KDQpJJ2Qgc3VnZ2VzdCBlaXRoZXI6DQoN CiJBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0 IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQg dG8gdGhlIG5leHQgU0ZGIg0KDQpvcg0KDQoiQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBh biBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBiZWZv cmUgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRiwgYnV0IG5vdCB1bnRpbCB0 aGUgU0YgaGFzIGZpbmlzaGVkIGFsbCBpdHMgb3RoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0 Ig0KDQpkZXBlbmRpbmcgdXBvbiB3aGljaCBpcyBpbnRlbmRlZC4NCg0KSSB0aGluayBhbiBpbXBs aWNhdGlvbiBvZiB0aGVzZSBwcm9jZWR1cmVzIGlzIHRoYXQgYW4gU0kgdmFsdWUgb2YgMSBpcyBu b3QgdmFsaWQuICBJZiBhbiBTRiBnZXRzIGFuIE5TSCBwYWNrZXQgd2l0aCBhbiBTSSBvZiAxLCB0 aGUgU0Ygd2lsbCBkZWNyZW1lbnQgdGhlIFNJIChzZXR0aW5nIGl0IHRvIDApLCBzZW5kIHRoZSBw YWNrZXQgdG8gYW4gU0ZGLCBhbmQgdGhlIFNGRiB3aWxsIGRpc2NhcmQgaXQsIGJlY2F1c2UgMCBp cyBhbiBpbnZhbGlkIFNJIHZhbHVlLiAgSXMgdGhhdCB0aGUgaW50ZW50aW9uPw0KDQpUaGUgZHJh ZnQgbWFrZXMgaXQgY2xlYXIgKHdlbGwsIHNvcnQgb2YpIHRoYXQgYW4gU0ZGIHNob3VsZCBkaXNj YXJkIGEgcGFja2V0IHdpdGggYW4gU0kgb2YgMCwgYnV0IGRvZXMgbm90IHNlZW0gdG8gc2F5IHRo YXQgYW4gU0Ygb3IgU0ZDIFByb3h5IHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IGl0IHJlY2VpdmVz IHdpdGggYW4gU0kgb2YgMC4gIEl0IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIHNh eSB0aGF0Lg0KDQpTb21lIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0aW9uIDcuMSkgc3Rh dGVzIHRoYW4gYW4gU0ZGIHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IHdpdGggYW4gU0kgb2YgemVy bywgYnV0IG90aGVyIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0aW9uIDMuMykgb25seSBz YXlzIHRoYXQgYW4gU0ZGIHNob3VsZCBsb2cgYW4gZXJyb3IgaWYgaXQgc2VlcyBhbiBTSSBvZiB6 ZXJvLiAgSXQncyBwcm9iYWJseSBiZXN0IHRvIGNoYW5nZSB0aGUgdGV4dCBpbiAzLjMuIHRvIHNh eSAiU0hPVUxEIGdlbmVyYXRlIGFuIGVycm9yL2xvZyBtZXNzYWdlIGFuZCBNVVNUIGRpc2NhcmQg dGhlIHBhY2tldCIsIG9yIHNvbWV0aGluZyBzaW1pbGFyLg0K --_000_E8355113905631478EFF04F5AA706E9870504746wtlexchp1sandvi_ 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 Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBh cmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE5Mjg5MTU4NTsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6OTk4MTU3NDUwIDEzNTY1OTU0MyAx MzU2NTk1NDUgMTM1NjU5NTQ3IDEzNTY1OTUzNSAxMzU2NTk1NDUgMTM1NjU5NTQ3IDEzNTY1OTUz NSAxMzU2NTk1NDUgMTM1NjU5NTQ3O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9w OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxDQoJ e21zby1saXN0LWlkOjE5MjIxMzU1NjM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE4MjcxNzk2OTAgLTEyNTc3MjQ4MDYgMTM1NjU5NTIzIDEzNTY1OTUy NSAxMzU2NTk1MjEgMTM1NjU5NTIzIDEzNTY1OTUyNSAxMzU2NTk1MjEgMTM1NjU5NTIzIDEzNTY1 OTUyNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+DqDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SeKAmW0gbm90IGNsZWFyIG9uIHdoeSB0aGlzIGlzIGJyb2tlbiwgb3Igd2h5IHRoaXMgcmVz dHJpY3Rpb24gaXMgbWFkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSBp dCBzaG91bGQgbm90IGJlIHNlbnQgdG8gYW4gU0YsIGJ1dCBhbiBTRkYgY291bGQgbWFwIGFuIFNJ IG9mIHplcm8gaW50byBhIHBhdGggdGVybWluYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkuZS4sIHRoZSBsYXN0IFNGIGluIGEgcGF0aCBjb3VsZCBkZWNyZW1lbnQgU0kgZnJv bSAxIHRvIDAsIGFuZCB0aGUgU0ZGIGNvdWxkIHRoZW4gdGVybWluYXRlIHRoZSBjaGFpbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYW1lcyBOIEd1aWNoYXJkPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAxMjowMiBQTTxicj4NCjxiPlRvOjwv Yj4gRmFicmljaW8gRmVycmF6OyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRGF2ZSBE b2xzb247IEVyaWMgQyBSb3Nlbjsgc2ZjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Tm90IGV4YWN0bHkuIFNlY3Rpb24gMy4zIHNwZWNpZmllcyDigJxUaGUgdmFs dWUgemVybyBmb3IgU0kgaXMgbm90IHZhbGlkIGFuZCBpbmRpY2F0ZXMgYSBicm9rZW4gU0ZDIG9y IG1hbGZ1bmN0aW9uaW5nIFNG4oCdIC4uIEluIG90aGVyIHdvcmRzIGFuIFNGIHNob3VsZCBuZXZl cg0KIHJlY2VpdmUgYW4gTlNIIHBhY2tldCB3aXRoIFNJID0gMC4gTm90ZSB0aGF0IGlmIHRoaXMg aGFwcGVuZWQgdGhlbiBlaXRoZXIgYSkgYSBjbGFzc2lmaWVyIHNldCB0aGUgU0kgaW5jb3JyZWN0 bHksIG9yIGIpIGEgcmUtY2xhc3NpZmllciBzZXQgdGhlIFNJIGluY29ycmVjdGx5LCBvciBjKSBh biB1cHN0cmVhbSBTRiBzZXQgdGhlIFNJIGluY29ycmVjdGx5OyBhbGwgb2YgdGhlc2UgY2FzZXMg c2hvdWxkIGJlIGNhdWdodCBieSB0aGUgU0ZGIHdob3NlDQogam9iIGl0IGlzIHRvIGRpc2NhcmQg TlNIIHBhY2tldHMgd2l0aCBTSSA9IDAuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmltPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij4gRmFicmljaW8gRmVycmF6IFttYWlsdG86ZmFicmljaW8tZmVycmF6QHRlbGVj b20ucHRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAyMDE3IDEx OjQ5IEFNPGJyPg0KPGI+VG86PC9iPiBKYW1lcyBOIEd1aWNoYXJkICZsdDtqYW1lcy5uLmd1aWNo YXJkQGh1YXdlaS5jb20mZ3Q7OyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKSAmbHQ7YW5k cmV3LmRvbGdhbm93QG5va2lhLmNvbSZndDs7IERhdmUgRG9sc29uICZsdDtkZG9sc29uQHNhbmR2 aW5lLmNvbSZndDs7IEVyaWMgQyBSb3NlbiAmbHQ7ZXJvc2VuQGp1bmlwZXIubmV0Jmd0Ozsgc2Zj QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRl eCBEZWNyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSmltLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUgbW9yZSBxdWVz dGlvbiBhYm91dCB0aGUgU0kuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMyBzdGF0ZXMgdGhhdDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VydmljZSBJbmRleCAoU0kpOiBwcm92aWRlcyBsb2NhdGlv biB3aXRoaW4gdGhlIFNGUC4gVGhlIGluaXRpYWwgY2xhc3NpZmllciBNVVNUIHNldCB0aGUgYXBw cm9wcmlhdGUgU0kgdmFsdWUgZm9yIGEgZ2l2ZW4gY2xhc3NpZmljYXRpb24gcmVzdWx0LiBUaGUg aW5pdGlhbCBTSSB2YWx1ZSBTSE9VTEQgZGVmYXVsdCB0byAyNTUuIEhvd2V2ZXIsIHRoZSBjbGFz c2lmaWVyIE1VU1QgYWxsb3cgY29uZmlndXJhdGlvbg0KIG9mIG90aGVyIFNJIHZhbHVlcy4gPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXJ2aWNlIEluZGV4IE1VU1QgYmUg ZGVjcmVtZW50ZWQgYnkgU2VydmljZSBGdW5jdGlvbnMgb3IgYnkgU0ZDIFByb3h5IG5vZGVzIGFm dGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQgc2VydmljZXMgYW5kIHRoZSBuZXcgZGVjcmVtZW50ZWQg U0kgdmFsdWUgTVVTVCBiZSB1c2VkIGluIHRoZSBlZ3Jlc3MgTlNIIHBhY2tldC4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGluaXRpYWwgQ2xhc3NpZmllciBNVVNU IHNlbmQgdGhlIHBhY2tldCB0byB0aGUgZmlyc3QgU0ZGIGluIHRoZSBpZGVudGlmaWVkIFNGUCBm b3IgZm9yd2FyZGluZyBhbG9uZyBhbiBTRlAuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklmIHJlLWNsYXNzaWZpY2F0aW9uIG9jY3VycywgYW5kIHRoYXQgcmUtY2xhc3Np ZmljYXRpb24gcmVzdWx0cyBpbiBhIG5ldyBTUEksIHRoZSAocmUpY2xhc3NpZmllciBpcywgaW4g ZWZmZWN0LCB0aGUgaW5pdGlhbCBjbGFzc2lmaWVyIGZvciB0aGUgcmVzdWx0YW50IFNQSS48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaHVzOg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkluaXRpYWwgU0kgdmFsdWUgc2hvdWxkIGJlIDI1NSBidXQgb3RoZXIg dmFsdWVzIGNhbiBiZSBjb25maWd1cmVkIGJ5IHRoZSBjbGFzc2lmaWVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Yik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5TRiBkZWNyZW1lbnRzIHRoZSBTSSB2YWx1ZSBvbiB0aGUgZWdyZXNzIE5TSCBwYWNrZXQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SWYgcmUtY2xhc3NpZmljYXRpb24gb2NjdXJzIHdpdGggbmV3IFNQ SSwgdGhlIHJlLWNsYXNzaWZpZXIgaXMgdGhlIGluaXRpYWwgY2xhc3NpZmllciwgc28gYnkgJm5i c3A7YSksIFNJIHNob3VsZCBiZSBhZ2FpbiAyNTUgb3Igb3RoZXIgdmFsdWUNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ U28gYW55IFNJIHZhbHVlIGNhbiBiZSByZWNlaXZlIGJ5IGFuIFNGLCBldmVuIDEgb3IgMCBiZWNh dXNlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w6g8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPg0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JZiBTST0xIGFuZCB0aGVyZSBpcyBubyByZS1jbGFzc2lmaWNhdGlvbiwg dGhlIGVncmVzcyBOU0ggd2lsbCBoYXZlIFNJPTA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMSBsZXZlbDEgbGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOoPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4NCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgU0k9MCBhbmQgdGhlcmUg aXMgcmUtY2xhc3NpZmljYXRpb24gd2l0aCBuZXcgU1BJLCB0aGUgZWdyZXNzIE5TSCB3aWxsIGhh dmUgYSBuZXcgU1BJIGFuZCBhIFNJPSAyNTUgb3Igb3RoZXIgdmFsdWUsIGFzIHN0YXRlZCBpbiBh KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOoPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4NCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SWYgU0k9MCBhbmQgdGhlcmUgaXMgbm8gcmUtY2xhc3NpZmljYXRpb24gdGhl IFNGIHNob3VsZCBkaXNjYXJkIHRoZSBwYWNrZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28gYW4gU0ZGIHNob3Vs ZCBmb3J3YXJkL2hhbmRsZSBwYWNrZXRzIHdpdGggTlNIIHdpdGggU0k9MSBvciBTST0wLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+RG8geW91IGFncmVlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IHNmYyBbPGEg aHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYW1lcyBOIEd1aWNoYXJkPGJyPg0KPGI+ U2VudDo8L2I+IHF1aW50YS1mZWlyYSwgOSBkZSBmZXZlcmVpcm8gZGUgMjAxNyAxNjoyNTxicj4N CjxiPlRvOjwvYj4gRmFicmljaW8gRmVycmF6OyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNH KTsgRGF2ZSBEb2xzb247IEVyaWMgQyBSb3NlbjsNCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIE5TSCBT ZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJQVCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEZhYnJpY2lvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2VsY29tZSE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlllcywgcmVtb3ZhbCBvZiBOU0ggaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGFuIFNG RiBvciBhIHJlLWNsYXNzaWZpZXIgKHNlY3Rpb24gNCwgYnVsbGV0IHBvaW50IDEgbGF5cyB0aGlz IG91dCkuIFdpdGggdGhlIGN1cnJlbnQgYXJjaGl0ZWN0dXJlIHRoZSBTRiBkb2VzDQogbm90IGNh cmUgd2hhdCBTSSB2YWx1ZSBpdCBnZXRzLCBpdCBqdXN0IG5lZWRzIHRvIHdvcnJ5IGFib3V0IGRl Y3JlbWVudGluZyBpdCwgYW5kIGxlYXZlIGl0IHVwIHRvIHRoZSBTRkYgdG8gZXZhbHVhdGUgdGhl IFNJIHZhbHVlIGFuZCBhc3NvY2lhdGVkIGFjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkppbTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEZhYnJpY2lvIEZl cnJheiBbPGEgaHJlZj0ibWFpbHRvOmZhYnJpY2lvLWZlcnJhekB0ZWxlY29tLnB0Ij5tYWlsdG86 ZmFicmljaW8tZmVycmF6QHRlbGVjb20ucHQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBGZWJydWFyeSAwOSwgMjAxNyA3OjEzIEFNPGJyPg0KPGI+VG86PC9iPiBEb2xnYW5vdywg QW5kcmV3IChOb2tpYSAtIFNHKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJldy5kb2xnYW5vd0Bu b2tpYS5jb20iPmFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb208L2E+Jmd0OzsgRGF2ZSBEb2xzb24g Jmx0OzxhIGhyZWY9Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+ZGRvbHNvbkBzYW5kdmlu ZS5jb208L2E+Jmd0OzsgRXJpYyBDIFJvc2VuICZsdDs8YSBocmVmPSJtYWlsdG86ZXJvc2VuQGp1 bmlwZXIubmV0Ij5lcm9zZW5AanVuaXBlci5uZXQ8L2E+Jmd0OzsNCiBKYW1lcyBOIEd1aWNoYXJk ICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tIj5qYW1lcy5u Lmd1aWNoYXJkQGh1YXdlaS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtzZmNdIE5TSCBT ZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJQVCIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKA mW0gbmV3IGhlcmUgKGp1c3QgcmVhZCB0aGUgZHJhZnQgbGFzdCB3ZWVrKSBidXQgYWNjb3JkaW5n IHRvIGNoYXB0ZXIgNCAoY2hlY2sgZmlndXJlIDggZm9yIGV4YW1wbGUpLCBhbiBTRiBpcyBub3Qg YWxsb3dlZCB0byBpbnNlcnQgb3IgcmVtb3ZlIE5TSC4gVGhlIHJlbW92YWwNCiBvZiBOU0ggaXMg cmVwb25zYWJpbGl0eSBvZiB0aGUgU1NGLCByaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo3LjBwdCA3LjBwdCA3LjBwdCA3LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDoj RkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBGaWd1cmUgOCBt YXBzIGVhY2ggb2YgdGhlIGZvdXIgYWN0aW9ucyBhYm92ZSB0byB0aGUgY29tcG9uZW50cyBpbiB0 aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBTRkMgYXJjaGl0ZWN0dXJlIHRoYXQgY2FuIHBlcmZv cm0gaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1 O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7LS0tLS0tLS0tLS0tLS0tJiM0 MzstLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQz Oy0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy ZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsgSW5zZXJ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHxTZWxlY3QgfCZuYnNwOyZuYnNwOyBVcGRhdGUmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfFNlcnZpY2UmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IG9yIHJlbW92ZSBOU0gmbmJzcDsgfFNlcnZp Y2V8Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5TSCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8cG9saWN5Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFj a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8RnVuY3Rpb258Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxzZWxlY3Rp b258PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs bCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij58IENvbXBvbmVudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tLSYjNDM7UGF0aCZuYnNwOyZuYnNwOyAmIzQzOy0tLS0t LS0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwgRGVjLiZuYnNwOyZuYnNwOyB8VXBkYXRlIHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5k OiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IEluc2VydCB8IFJlbW92ZSB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxTZXJ2aWNlIHxDb250ZXh0fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6 I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSW5kZXgmbmJzcDsgfEhlYWRlciB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3 LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MzstLS0t LS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3 LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAmIzQzOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+fENsYXNzaWZpZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29y ZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzstLS0tLS0tLS0tLS0tLS0gJiM0Mzst LS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0t JiM0MzstLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29y ZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fFNlcnZpY2UgRnVuY3Rpb258Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgJiM0MzsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij58Rm9yd2FyZGVyKFNGRikmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i cmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzstLS0tLS0tLS0tLS0tLS0gJiM0MzstLS0t LS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tJiM0 MzstLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i cmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fFNlcnZpY2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyAmIzQz OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDti YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fEZ1bmN0 aW9uJm5ic3A7IChTRikmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+JiM0MzstLS0tLS0tLS0tLS0tLS0gJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQz Oy0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0mIzQzOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+fFNGQyBQcm94eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgJiM0MzsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0 MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0t LS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZG REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUgODogTlNIIEFjdGlvbiBhbmQg Um9sZSBNYXBwaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BbiBTRiBjb3VsZCByZWNlaXZlIGFuIE5TSCBwYWNrZXQgd2l0aCBhbiBTSSBv ZiAxLCBhbmQgcmVjbGFzc2lmeSBpdCB0byBhIGRpZmZlcmVudCBTUEkgYW5kIFNJLCByaWdodD8g U28gd2hlbiBhIFNGIHJlY2VpdmVzIGEgTlNIIHBhY2tldCB3aXRoIFNJID0gMSB0aGF0IGRvZXMN CiBub3QgbmVjZXNzYXJpbHkgbWVhbnMgYSBub24gdmFsaWQgcGFja2V0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5BbmQgdGhhdCBjYW4gZXZlbiB3b3JrIGZvciBTST0wLCBzaW5jZSB5 b3UgZGVjcmVtZW50IHRoZSBTSSBpbiB0aGUgZWdyZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmFicmljaW88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gc2ZjIFs8YSBocmVmPSJtYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpPGJyPg0K PGI+U2VudDo8L2I+IHF1aW50YS1mZWlyYSwgOSBkZSBmZXZlcmVpcm8gZGUgMjAxNyAwMTo1MTxi cj4NCjxiPlRvOjwvYj4gRGF2ZSBEb2xzb247IEVyaWMgQyBSb3NlbjsgSmFtZXMgTiBHdWljaGFy ZDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iUFQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5J IGFzc3VtZWQgdGhhdCBpZiB3ZSBnZXQgdmFsdWUgMSB3ZSBwcm9jZXNzIHRoZW4gZm9yd2FyZCB3 aXRob3V0IE5TSCBoZWFkZXIgKGkuZS4pIHRoaXMgaXMgdGhlIGxhc3QgU0YgcHJvY2Vzc2luZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOndpbmRvd3RleHQiPlNvIHdpdGggdGhhdCBhc3N1bXB0aW9uLCBhIG1vcmUgZXhwbGljaXQg dGV4dCB3b3VsZCBiZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkFuIFNGIG9yIFNGQyBQcm94eSByZWNlaXZp bmcgYW4gTlNILWVuY2Fwc3VsYXRlZCBwYWNrZXQgTVVTVCBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEg YWZ0ZXIgcGVyZm9ybWluZyBhbGwgcmVxdWlyZWQgbG9jYWwgcHJvY2Vzc2luZyBhbmQgYmVmb3Jl IGZvcndhcmRpbmcgdGhlDQogcGFja2V0IHRvIHRoZSBuZXh0IFNGRi4gSWYgdGhlIHJlc3VsdGlu ZyBTSSBpcyAwLCB0aGUgU0YgTVVTVCByZW1vdmUgdGhlIE5TSCBoZWFkZXIgYmVmb3JlIGZvcndh cmRpbmcgdGhlIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5zZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+ c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGF2ZSBEb2xzb24gJmx0 OzxhIGhyZWY9Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+ZGRvbHNvbkBzYW5kdmluZS5j b208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgRmVicnVhcnkgOSwgMjAxNyBh dCAyOjA0IEFNPGJyPg0KPGI+VG86IDwvYj5FcmljIFJvc2VuICZsdDs8YSBocmVmPSJtYWlsdG86 ZXJvc2VuQGp1bmlwZXIubmV0Ij5lcm9zZW5AanVuaXBlci5uZXQ8L2E+Jmd0OywgSmFtZXMgTiBH dWljaGFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbSI+ amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Fcmlj LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSB3YXMgbmV2ZXIgcXVpdGUgaGFwcHkgd2l0aCB0aGUgb3V0Y29tZSB0aGF0IG5laXRoZXIgMCBu b3IgMSBpcyBhIHZhbGlkIFNJLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+KEJlY2F1c2UgaWYgcmVjZWl2ZWQgd2l0aCB2YWx1ZSBvZiAxLCBp dCBpcyBkZWNyZW1lbnRlZCBhbmQgZGlzY2FyZGVkLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgc2VlbXMgdG8gd2FzdGUgYW4g aW5kZXggdmFsdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgZ3Vlc3MgSeKAmW0gaW50ZXJlc3RlZCB0byBrbm93IGlmIHRoYXQg aXMgaW1wb3J0YW50IHRvIG90aGVyIGltcGxlbWVudGVycywgb3IgaWYgdGhhdCB3YXMgZXZlbiB0 aGUgaW50ZW50aW9uPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1EYXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5FcmljIEMgUm9zZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJy dWFyeSAwOCwgMjAxNyAxMTo1MyBBTTxicj4NCjxiPlRvOjwvYj4gSmFtZXMgTiBHdWljaGFyZDsg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQpPbiAyLzcvMjAxNyAyOjI0IFBN LCBKYW1lcyBOIEd1aWNoYXJkIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KQSByZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUg c3BlY2lmaWMgYW5kIHVwZGF0ZSB0aGUgdGV4dCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQrigJxTZXJ2 aWNlIGluZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgPGI+YnkgYSB2YWx1ZSBvZiAxPC9iPiBieSBT ZXJ2aWNlIEZ1bmN0aW9ucyBvciBieSBTRkMgUHJveHkgbm9kZXMgYWZ0ZXIgcGVyZm9ybWluZyBy ZXF1aXJlZCBzZXJ2aWNlcyDigKbigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQo8YnI+DQpBIGNvdXBsZSBvZiBvYnNl cnZhdGlvbnM6PGJyPg0KPGJyPg0KLSBUaGUgdGVybSAmcXVvdDtTRkMgUHJveHkgbm9kZSZxdW90 OyBpcyBub3QgZGVmaW5lZCBpbiBlaXRoZXIgdGhlIE5TSCBkcmFmdCBvciBpbiBSRkMgNzY2NS4m bmJzcDsgSSB0aGluayB0aGUgaW50ZW50aW9uIGhlcmUgaXMgdG8gc2F5ICZxdW90O1NGQyBQcm94 eSZxdW90Oy48YnI+DQo8YnI+DQotIElzIHRoZSBpbnRlbnRpb24gdGhhdCB0aGUgU0kgcmVtYWlu IHVuY2hhbmdlZCB3aGlsZSB0aGUgU0YgaXMgb3BlcmF0aW5nIG9uIHRoZSBwYWNrZXQsIG9yIGlz IHRoZSBpbnRlbnRpb24gb25seSB0aGF0IHRoZSBTSSBiZSBkZWNyZW1lbnRlZCBiZWZvcmUgdGhl IHBhY2tldCBpcyBkZWxpdmVyZWQgYnkgdGhlIFNGIG9yIFNGQyBQcm94eSB0byBhbiBTRkY/DQo8 YnI+DQo8YnI+DQpJJ2Qgc3VnZ2VzdCBlaXRoZXI6PGJyPg0KPGJyPg0KJnF1b3Q7QW4gU0Ygb3Ig U0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3Jl bWVudCB0aGUgU0kgYnkgMSBiZWZvcmUgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0 IFNGRiZxdW90Ozxicj4NCjxicj4NCm9yPGJyPg0KPGJyPg0KJnF1b3Q7QW4gU0Ygb3IgU0ZDIFBy b3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0 aGUgU0kgYnkgMSBiZWZvcmUgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRiwg YnV0IG5vdCB1bnRpbCB0aGUgU0YgaGFzIGZpbmlzaGVkIGFsbCBpdHMgb3RoZXIgcHJvY2Vzc2lu ZyBvZiB0aGUgcGFja2V0JnF1b3Q7PGJyPg0KPGJyPg0KZGVwZW5kaW5nIHVwb24gd2hpY2ggaXMg aW50ZW5kZWQuPGJyPg0KPGJyPg0KSSB0aGluayBhbiBpbXBsaWNhdGlvbiBvZiB0aGVzZSBwcm9j ZWR1cmVzIGlzIHRoYXQgYW4gU0kgdmFsdWUgb2YgMSBpcyBub3QgdmFsaWQuJm5ic3A7IElmIGFu IFNGIGdldHMgYW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIHRoZSBTRiB3aWxsIGRlY3Jl bWVudCB0aGUgU0kgKHNldHRpbmcgaXQgdG8gMCksIHNlbmQgdGhlIHBhY2tldCB0byBhbiBTRkYs IGFuZCB0aGUgU0ZGIHdpbGwgZGlzY2FyZCBpdCwgYmVjYXVzZSAwIGlzIGFuIGludmFsaWQgU0kN CiB2YWx1ZS4mbmJzcDsgSXMgdGhhdCB0aGUgaW50ZW50aW9uPzxicj4NCjxicj4NClRoZSBkcmFm dCBtYWtlcyBpdCBjbGVhciAod2VsbCwgc29ydCBvZikgdGhhdCBhbiBTRkYgc2hvdWxkIGRpc2Nh cmQgYSBwYWNrZXQgd2l0aCBhbiBTSSBvZiAwLCBidXQgZG9lcyBub3Qgc2VlbSB0byBzYXkgdGhh dCBhbiBTRiBvciBTRkMgUHJveHkgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQgaXQgcmVjZWl2ZXMg d2l0aCBhbiBTSSBvZiAwLiZuYnNwOyBJdCB3b3VsZCBwcm9iYWJseSBiZSBhIGdvb2QgaWRlYSB0 byBzYXkgdGhhdC48YnI+DQo8YnI+DQpTb21lIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0 aW9uIDcuMSkgc3RhdGVzIHRoYW4gYW4gU0ZGIHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IHdpdGgg YW4gU0kgb2YgemVybywgYnV0IG90aGVyIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0aW9u IDMuMykgb25seSBzYXlzIHRoYXQgYW4gU0ZGIHNob3VsZCBsb2cgYW4gZXJyb3IgaWYgaXQgc2Vl cyBhbiBTSSBvZiB6ZXJvLiZuYnNwOyBJdCdzIHByb2JhYmx5IGJlc3QgdG8gY2hhbmdlIHRoZSB0 ZXh0DQogaW4gMy4zLiB0byBzYXkgJnF1b3Q7U0hPVUxEIGdlbmVyYXRlIGFuIGVycm9yL2xvZyBt ZXNzYWdlIGFuZCBNVVNUIGRpc2NhcmQgdGhlIHBhY2tldCZxdW90Oywgb3Igc29tZXRoaW5nIHNp bWlsYXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E8355113905631478EFF04F5AA706E9870504746wtlexchp1sandvi_-- From nobody Thu Feb 9 09:42:40 2017 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 92F5F129C22 for ; Thu, 9 Feb 2017 09:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 tP2zhV5erguw for ; Thu, 9 Feb 2017 09:42:36 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5851129422 for ; Thu, 9 Feb 2017 09:42:35 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 09:42:35 -0800 From: Ron Parker To: Dave Dolson Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkAAeZjIw//6oW4D//33gww== Date: Thu, 9 Feb 2017 17:42:34 +0000 Message-ID: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_28DFB214A1B94D60AE3B3B72CBE4E22Caffirmednetworkscom_" MIME-Version: 1.0 Archived-At: Cc: Eric C Rosen , "sfc@ietf.org" , "Dolganow, Andrew \(Nokia - SG\)" , James N Guichard , Fabricio Ferraz Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:42:38 -0000 --_000_28DFB214A1B94D60AE3B3B72CBE4E22Caffirmednetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable agree. On Feb 9, 2017, at 12:28 PM, Dave Dolson > wrote: I=92m not clear on why this is broken, or why this restriction is made. I agree it should not be sent to an SF, but an SFF could map an SI of zero = into a path termination. I.e., the last SF in a path could decrement SI from 1 to 0, and the SFF cou= ld then terminate the chain. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of James N Guichard Sent: Thursday, February 09, 2017 12:02 PM To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eric C Ros= en; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement Not exactly. Section 3.3 specifies =93The value zero for SI is not valid an= d indicates a broken SFC or malfunctioning SF=94 .. In other words an SF sh= ould never receive an NSH packet with SI =3D 0. Note that if this happened = then either a) a classifier set the SI incorrectly, or b) a re-classifier s= et the SI incorrectly, or c) an upstream SF set the SI incorrectly; all of = these cases should be caught by the SFF whose job it is to discard NSH pack= ets with SI =3D 0. Jim From: Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] Sent: Thursday, February 09, 2017 11:49 AM To: James N Guichard >; Dolganow, Andrew (Nokia - SG) >; Dave Dolson >; Eric C Rosen >; sfc@ietf.org Subject: RE: [sfc] NSH Service Index Decrement Hi Jim, Thanks. One more question about the SI. Section 3 states that: Service Index (SI): provides location within the SFP. The initial classifie= r MUST set the appropriate SI value for a given classification result. The = initial SI value SHOULD default to 255. However, the classifier MUST allow = configuration of other SI values. Service Index MUST be decremented by Service Functions or by SFC Proxy node= s after performing required services and the new decremented SI value MUST = be used in the egress NSH packet. The initial Classifier MUST send the packet to the first SFF in the identif= ied SFP for forwarding along an SFP. If re-classification occurs, and that re-classification results in a new SP= I, the (re)classifier is, in effect, the initial classifier for the resulta= nt SPI. Thus: a) Initial SI value should be 255 but other values can be configured b= y the classifier. b) SF decrements the SI value on the egress NSH packet c) If re-classification occurs with new SPI, the re-classifier is the= initial classifier, so by a), SI should be again 255 or other value So any SI value can be receive by an SF, even 1 or 0 because: =E8 If SI=3D1 and there is no re-classification, the egress NSH will have S= I=3D0 =E8 If SI=3D0 and there is re-classification with new SPI, the egress NSH w= ill have a new SPI and a SI=3D 255 or other value, as stated in a). =E8 If SI=3D0 and there is no re-classification the SF should discard the p= acket Also an SFF should forward/handle packets with NSH with SI=3D1 or SI=3D0. Do you agree? From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of James N Guichard Sent: quinta-feira, 9 de fevereiro de 2017 16:25 To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eric C Ros= en; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement Hi Fabricio, Welcome! Yes, removal of NSH is the responsibility of an SFF or a re-classifier (sec= tion 4, bullet point 1 lays this out). With the current architecture the SF= does not care what SI value it gets, it just needs to worry about decremen= ting it, and leave it up to the SFF to evaluate the SI value and associated= action. Jim From: Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] Sent: Thursday, February 09, 2017 7:13 AM To: Dolganow, Andrew (Nokia - SG) >; Dave Dolson >; Eric C Rosen >; J= ames N Guichard >; sfc@ietf.org Subject: RE: [sfc] NSH Service Index Decrement Hi all, I=92m new here (just read the draft last week) but according to chapter 4 (= check figure 8 for example), an SF is not allowed to insert or remove NSH. = The removal of NSH is reponsability of the SSF, right? Figure 8 maps each of the four actions above to the components in the SFC architecture that can perform it. +---------------+------------------+-------+----------------+---------+ | | Insert |Select | Update |Service | | | or remove NSH |Service| NSH |policy | | | |Function| |selection| | Component +--------+--------+Path +----------------+ | | | | | | Dec. |Update | | | | Insert | Remove | |Service |Context| | | | | | | Index |Header | | +----------------+--------+--------+-------+--------+-------+---------+ | | + | + | | | + | | |Classifier | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service Function| | + | + | | | | |Forwarder(SFF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service | | | | + | + | + | |Function (SF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |SFC Proxy | + | + | | + | | | +----------------+--------+--------+-------+--------+-------+---------+ Figure 8: NSH Action and Role Mapping An SF could receive an NSH packet with an SI of 1, and reclassify it to a d= ifferent SPI and SI, right? So when a SF receives a NSH packet with SI =3D = 1 that does not necessarily means a non valid packet. And that can even work for SI=3D0, since you decrement the SI in the egress= . Fabricio From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Noki= a - SG) Sent: quinta-feira, 9 de fevereiro de 2017 01:51 To: Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement I assumed that if we get value 1 we process then forward without NSH header= (i.e.) this is the last SF processing. So with that assumption, a more explicit text would be: An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the = SI by 1 after performing all required local processing and before forwardin= g the packet to the next SFF. If the resulting SI is 0, the SF MUST remove = the NSH header before forwarding the packet. Andrew From: sfc > on behalf of = Dave Dolson > Date: Thursday, February 9, 2017 at 2:04 AM To: Eric Rosen >, James N Gui= chard >, "s= fc@ietf.org" > Subject: Re: [sfc] NSH Service Index Decrement Eric, I was never quite happy with the outcome that neither 0 nor 1 is a valid SI= . (Because if received with value of 1, it is decremented and discarded.) It seems to waste an index value. I guess I=92m interested to know if that is important to other implementers= , or if that was even the intention? -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Wednesday, February 08, 2017 11:53 AM To: James N Guichard; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement On 2/7/2017 2:24 PM, James N Guichard wrote: A request was made to be more specific and update the text as follows: =93Service index MUST be decremented by a value of 1 by Service Functions o= r by SFC Proxy nodes after performing required services =85=94 A couple of observations: - The term "SFC Proxy node" is not defined in either the NSH draft or in RF= C 7665. I think the intention here is to say "SFC Proxy". - Is the intention that the SI remain unchanged while the SF is operating o= n the packet, or is the intention only that the SI be decremented before th= e packet is delivered by the SF or SFC Proxy to an SFF? I'd suggest either: "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the= SI by 1 before delivering the packet to the next SFF" or "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the= SI by 1 before delivering the packet to the next SFF, but not until the SF= has finished all its other processing of the packet" depending upon which is intended. I think an implication of these procedures is that an SI value of 1 is not = valid. If an SF gets an NSH packet with an SI of 1, the SF will decrement = the SI (setting it to 0), send the packet to an SFF, and the SFF will disca= rd it, because 0 is an invalid SI value. Is that the intention? The draft makes it clear (well, sort of) that an SFF should discard a packe= t with an SI of 0, but does not seem to say that an SF or SFC Proxy should = discard a packet it receives with an SI of 0. It would probably be a good = idea to say that. Some text in the draft (e.g., section 7.1) states than an SFF should discar= d a packet with an SI of zero, but other text in the draft (e.g., section 3= .3) only says that an SFF should log an error if it sees an SI of zero. It= 's probably best to change the text in 3.3. to say "SHOULD generate an erro= r/log message and MUST discard the packet", or something similar. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_28DFB214A1B94D60AE3B3B72CBE4E22Caffirmednetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
agree.

I=92m not clear on why th= is is broken, or why this restriction is made.

I agree it should not be = sent to an SF, but an SFF could map an SI of zero into a path termination.<= o:p>

I.e., the last SF in a pa= th could decrement SI from 1 to 0, and the SFF could then terminate the cha= in.

 <= /p>

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org] On Behalf Of James N Guichard
Sent: Thursday, February 09, 2017 12:02 PM
To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eri= c C Rosen; sfc@ietf.org
Subject: Re: [sfc] NSH Service Index Decrement

 

Not exactly. Section 3.3 = specifies =93The value zero for SI is not valid and indicates a broken SFC = or malfunctioning SF=94 .. In other words an SF should never receive an NSH packet with SI =3D 0. Note that if this happened then eithe= r a) a classifier set the SI incorrectly, or b) a re-classifier set the SI = incorrectly, or c) an upstream SF set the SI incorrectly; all of these case= s should be caught by the SFF whose job it is to discard NSH packets with SI =3D 0.

 <= /p>

Jim

 

From: Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt]
Sent: Thursday, February 09, 2017 11:49 AM
To: James N Guichard <james.n.guichard@huawei.com>; Dolganow, Andrew (Nokia - SG) <= andrew.dolganow@nokia.com&= gt;; Dave Dolson <ddolson@sandvi= ne.com>; Eric C Rosen <erosen@juniper.net<= /a>>; sfc@ietf.org
Subject: RE: [sfc] NSH Service Index Decrement

 

Hi Jim,=

Thanks.=

 <= /p>

One more question about t= he SI.

 <= /p>

Section 3 states that:

 <= /p>

Service Index (SI): provides location within the SFP= . The initial classifier MUST set the appropriate SI value for a given clas= sification result. The initial SI value SHOULD default to 255. However, the= classifier MUST allow configuration of other SI values.

Service Index MUST be decremented by Service Functio= ns or by SFC Proxy nodes after performing required services and the new dec= remented SI value MUST be used in the egress NSH packet.

The initial Classifier MUST send the packet to the f= irst SFF in the identified SFP for forwarding along an SFP.

If re-classification occurs, and that re-classificat= ion results in a new SPI, the (re)classifier is, in effect, the initial cla= ssifier for the resultant SPI.=

 <= /p>

Thus:

a)&= nbsp;     Initial SI va= lue should be 255 but other values can be configured by the classifier.

b)&= nbsp;     SF decrements= the SI value on the egress NSH packet

c)&= nbsp;      If re-classif= ication occurs with new SPI, the re-classifier is the initial classifier, s= o by  a), SI should be again 255 or other value

 <= /p>

So any SI value can be re= ceive by an SF, even 1 or 0 because:

=E8 If SI=3D1 and= there is no re-classification, the egress NSH will have SI=3D0<= /span>

=E8 If SI=3D0 and= there is re-classification with new SPI, the egress NSH will have a new SP= I and a SI=3D 255 or other value, as stated in a).

=E8 If SI=3D0 and= there is no re-classification the SF should discard the packet<= /span>

 <= /p>

Also an SFF should forwar= d/handle packets with NSH with SI=3D1 or SI=3D0.

 <= /p>

Do you agree?<= /span>

 <= /p>

 <= /p>

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org] On Behalf Of James N Guichard
Sent: quinta-feira, 9 de fevereiro de 2017 16:25
To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eri= c C Rosen; sfc@ietf.org
Subject: Re: [sfc] NSH Service Index Decrement

 

Hi Fabricio,

 <= /p>

Welcome!

 <= /p>

Yes, removal of NSH is th= e responsibility of an SFF or a re-classifier (section 4, bullet point 1 la= ys this out). With the current architecture the SF does not care what SI value it gets, it just needs to worry about decrementing = it, and leave it up to the SFF to evaluate the SI value and associated acti= on.

 <= /p>

Jim

 <= /p>

From: Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt]
Sent: Thursday, February 09, 2017 7:13 AM
To: Dolganow, Andrew (Nokia - SG) <andrew.dolganow@nokia.com>; Dave Dolson <ddolson@sandvine.com>; Eric C Rosen= <erosen@juniper.net>; James N Guichard <james.= n.guichard@huawei.com>; sfc@ietf.org
Subject: RE: [sfc] NSH Service Index Decrement

 

Hi all,<= /o:p>

I=92m new here (just read= the draft last week) but according to chapter 4 (check figure 8 for exampl= e), an SF is not allowed to insert or remove NSH. The removal of NSH is reponsability of the SSF, right?

 <= /p>

  = Figure 8 maps each of the four actions above to the components in the<= /o:p>

 &= nbsp; SFC architecture that can perform it.

&n= bsp;

+--= -------------+------------------+-------+----------------+-= --------+

| =             &nb= sp;  |  Insert         |S= elect |   Update       |Service&nbs= p; |

| =             &nb= sp;  |  or remove NSH  |Service|    NSH =         |policy   |=

| =             &nb= sp;  |          &nbs= p;      |Function|     &n= bsp;         |selection|=

| Compo= nent      +--------+--------+Path = ;  +----------------+       = ;  |

| =             &nb= sp;  |        |   &n= bsp;    |       | Dec. &n= bsp; |Update |         |=

| =             &nb= sp;  | Insert | Remove |       |Service = |Context|         |

| =             &nb= sp;  |        |   &n= bsp;    |       | Index  = |Header |         |

+--= --------------+--------+--------+-------+--------+-----= --+---------+

| =             &nb= sp;  |   +    |   + &n= bsp;  |       |    &= nbsp;   |   +   |    =      |

|Classi= fier      |      &nb= sp; |        |    &n= bsp;  |        |   &= nbsp;   |         |<= /o:p>

+--= ------------- +--------+--------+-------+--------+-----= --+---------+

|Servic= e Function|        |   +&n= bsp;   |  +    |    &= nbsp;   |       |   =       |

|Forwar= der(SFF)  |        |  &nb= sp;     |       | &n= bsp;      |       |&= nbsp;        |

+--= ------------- +--------+--------+-------+--------+-----= --+---------+

|Servic= e         |    =     |        |  &nbs= p;    |   +    | &nbs= p; +   |   +     |

|Functi= on  (SF)  |        | &nbs= p;      |       |&nb= sp;       |     &nbs= p; |         |

+--= ------------- +--------+--------+-------+--------+-----= --+---------+

|SFC Pr= oxy       |   +  &nbs= p; |   +    |     &nb= sp; |   +    |     &n= bsp; |         |<= /p>

+--= --------------+--------+--------+-------+--------+-----= --+---------+

&n= bsp;

 &= nbsp;           &nbs= p;     Figure 8: NSH Action and Role Mapping=

 <= /p>

 <= /p>

An SF could receive an NS= H packet with an SI of 1, and reclassify it to a different SPI and SI, righ= t? So when a SF receives a NSH packet with SI =3D 1 that does not necessarily means a non valid packet.

And that can even work fo= r SI=3D0, since you decrement the SI in the egress.

 <= /p>

Fabricio

 <= /p>

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Nokia - SG)
Sent: quinta-feira, 9 de fevereiro de 2017 01:51
To: Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org
Subject: Re: [sfc] NSH Service Index Decrement

 

I assumed that if we g= et value 1 we process then forward without NSH header (i.e.) this is the la= st SF processing.

 

So with that assumptio= n, a more explicit text would be:

 

An SF or SFC Proxy rec= eiving an NSH-encapsulated packet MUST decrement the SI by 1 after performi= ng all required local processing and before forwarding the packet to the next SFF. If the resulting SI is 0, the SF MUST remove the N= SH header before forwarding the packet.

 

Andrew

From: sfc <sfc-bounces@ietf.org= > on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Thursday, February 9, 2017 at 2:04 AM
To: Eric Rosen <erosen@juni= per.net>, James N Guichard <james.n.guichard@huawei.com>, "sfc@ietf.org" <sfc@ie= tf.org>
Subject: Re: [sfc] NSH Service Index Decrement

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric C Rosen
Sent: Wednesday, February 08, 2017 11:53 AM
To: James N Guichard; sfc@ietf.org
Subject: Re: [sfc] NSH Service Index Decrement

 

On 2/7/2017 2:24 PM, James N Guichard wrote:

A request was made to be more specific and update the text as follows:=

 

=93Service index MUST be decremented by a value of 1 by Service Func= tions or by SFC Proxy nodes after performing required services =85=94<= /o:p>


A couple of observations:

- The term "SFC Proxy node" is not defined in either the NSH draf= t or in RFC 7665.  I think the intention here is to say "SFC Prox= y".

- Is the intention that the SI remain unchanged while the SF is operating o= n the packet, or is the intention only that the SI be decremented before th= e packet is delivered by the SF or SFC Proxy to an SFF?

I'd suggest either:

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decremen= t the SI by 1 before delivering the packet to the next SFF"

or

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decremen= t the SI by 1 before delivering the packet to the next SFF, but not until t= he SF has finished all its other processing of the packet"

depending upon which is intended.

I think an implication of these procedures is that an SI value of 1 is not = valid.  If an SF gets an NSH packet with an SI of 1, the SF will decre= ment the SI (setting it to 0), send the packet to an SFF, and the SFF will = discard it, because 0 is an invalid SI value.  Is that the intention?

The draft makes it clear (well, sort of) that an SFF should discard a packe= t with an SI of 0, but does not seem to say that an SF or SFC Proxy should = discard a packet it receives with an SI of 0.  It would probably be a = good idea to say that.

Some text in the draft (e.g., section 7.1) states than an SFF should discar= d a packet with an SI of zero, but other text in the draft (e.g., section 3= .3) only says that an SFF should log an error if it sees an SI of zero.&nbs= p; It's probably best to change the text in 3.3. to say "SHOULD generate an error/log message and MUST discard= the packet", or something similar.

--_000_28DFB214A1B94D60AE3B3B72CBE4E22Caffirmednetworkscom_-- From nobody Thu Feb 9 09:58:13 2017 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 7BADF129C33 for ; Thu, 9 Feb 2017 09:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Z75hCCQQVLE2 for ; Thu, 9 Feb 2017 09:58:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF9C129C34 for ; Thu, 9 Feb 2017 09:58:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGD39103; Thu, 09 Feb 2017 17:58:01 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 9 Feb 2017 17:58:00 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Thu, 9 Feb 2017 09:57:55 -0800 From: James N Guichard To: Ron Parker , Dave Dolson Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkAAeZjIw//6oW4D//33gw////yNA Date: Thu, 9 Feb 2017 17:57:54 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> , <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> In-Reply-To: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.249] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB69AESJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.589CADAA.0237, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a70407c9a835e72958c2c0bc1d89c9e Archived-At: Cc: "sfc@ietf.org" , Eric C Rosen , "Dolganow, Andrew \(Nokia - SG\)" , Fabricio Ferraz Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:58:09 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB69AESJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This mechanism has been in the document for the past x years and is not dis= similar to what a router will do with a packet whose TTL =3D 0 e.g. somethi= ng broke, drop the packet and tell someone you did that. Jim From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, February 09, 2017 12:43 PM To: Dave Dolson Cc: James N Guichard ; Fabricio Ferraz ; Dolganow, Andrew (Nokia - SG) ; Eric C Rosen ; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement agree. On Feb 9, 2017, at 12:28 PM, Dave Dolson > wrote: I'm not clear on why this is broken, or why this restriction is made. I agree it should not be sent to an SF, but an SFF could map an SI of zero = into a path termination. I.e., the last SF in a path could decrement SI from 1 to 0, and the SFF cou= ld then terminate the chain. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of James N Guichard Sent: Thursday, February 09, 2017 12:02 PM To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eric C Ros= en; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement Not exactly. Section 3.3 specifies "The value zero for SI is not valid and = indicates a broken SFC or malfunctioning SF" .. In other words an SF should= never receive an NSH packet with SI =3D 0. Note that if this happened then= either a) a classifier set the SI incorrectly, or b) a re-classifier set t= he SI incorrectly, or c) an upstream SF set the SI incorrectly; all of thes= e cases should be caught by the SFF whose job it is to discard NSH packets = with SI =3D 0. Jim From: Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] Sent: Thursday, February 09, 2017 11:49 AM To: James N Guichard >; Dolganow, Andrew (Nokia - SG) >; Dave Dolson >; Eric C Rosen >; sfc@ietf.org Subject: RE: [sfc] NSH Service Index Decrement Hi Jim, Thanks. One more question about the SI. Section 3 states that: Service Index (SI): provides location within the SFP. The initial classifie= r MUST set the appropriate SI value for a given classification result. The = initial SI value SHOULD default to 255. However, the classifier MUST allow = configuration of other SI values. Service Index MUST be decremented by Service Functions or by SFC Proxy node= s after performing required services and the new decremented SI value MUST = be used in the egress NSH packet. The initial Classifier MUST send the packet to the first SFF in the identif= ied SFP for forwarding along an SFP. If re-classification occurs, and that re-classification results in a new SP= I, the (re)classifier is, in effect, the initial classifier for the resulta= nt SPI. Thus: a) Initial SI value should be 255 but other values can be configured b= y the classifier. b) SF decrements the SI value on the egress NSH packet c) If re-classification occurs with new SPI, the re-classifier is the = initial classifier, so by a), SI should be again 255 or other value So any SI value can be receive by an SF, even 1 or 0 because: ? If SI=3D1 and there is no re-classification, the egress NSH will have SI= =3D0 ? If SI=3D0 and there is re-classification with new SPI, the egress NSH wil= l have a new SPI and a SI=3D 255 or other value, as stated in a). ? If SI=3D0 and there is no re-classification the SF should discard the pac= ket Also an SFF should forward/handle packets with NSH with SI=3D1 or SI=3D0. Do you agree? From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of James N Guichard Sent: quinta-feira, 9 de fevereiro de 2017 16:25 To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eric C Ros= en; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement Hi Fabricio, Welcome! Yes, removal of NSH is the responsibility of an SFF or a re-classifier (sec= tion 4, bullet point 1 lays this out). With the current architecture the SF= does not care what SI value it gets, it just needs to worry about decremen= ting it, and leave it up to the SFF to evaluate the SI value and associated= action. Jim From: Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] Sent: Thursday, February 09, 2017 7:13 AM To: Dolganow, Andrew (Nokia - SG) >; Dave Dolson >; Eric C Rosen >; J= ames N Guichard >; sfc@ietf.org Subject: RE: [sfc] NSH Service Index Decrement Hi all, I'm new here (just read the draft last week) but according to chapter 4 (ch= eck figure 8 for example), an SF is not allowed to insert or remove NSH. Th= e removal of NSH is reponsability of the SSF, right? Figure 8 maps each of the four actions above to the components in the SFC architecture that can perform it. +---------------+------------------+-------+----------------+---------+ | | Insert |Select | Update |Service | | | or remove NSH |Service| NSH |policy | | | |Function| |selection| | Component +--------+--------+Path +----------------+ | | | | | | Dec. |Update | | | | Insert | Remove | |Service |Context| | | | | | | Index |Header | | +----------------+--------+--------+-------+--------+-------+---------+ | | + | + | | | + | | |Classifier | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service Function| | + | + | | | | |Forwarder(SFF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service | | | | + | + | + | |Function (SF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |SFC Proxy | + | + | | + | | | +----------------+--------+--------+-------+--------+-------+---------+ Figure 8: NSH Action and Role Mapping An SF could receive an NSH packet with an SI of 1, and reclassify it to a d= ifferent SPI and SI, right? So when a SF receives a NSH packet with SI =3D = 1 that does not necessarily means a non valid packet. And that can even work for SI=3D0, since you decrement the SI in the egress= . Fabricio From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Noki= a - SG) Sent: quinta-feira, 9 de fevereiro de 2017 01:51 To: Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement I assumed that if we get value 1 we process then forward without NSH header= (i.e.) this is the last SF processing. So with that assumption, a more explicit text would be: An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the = SI by 1 after performing all required local processing and before forwardin= g the packet to the next SFF. If the resulting SI is 0, the SF MUST remove = the NSH header before forwarding the packet. Andrew From: sfc > on behalf of = Dave Dolson > Date: Thursday, February 9, 2017 at 2:04 AM To: Eric Rosen >, James N Gui= chard >, "s= fc@ietf.org" > Subject: Re: [sfc] NSH Service Index Decrement Eric, I was never quite happy with the outcome that neither 0 nor 1 is a valid SI= . (Because if received with value of 1, it is decremented and discarded.) It seems to waste an index value. I guess I'm interested to know if that is important to other implementers, = or if that was even the intention? -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Wednesday, February 08, 2017 11:53 AM To: James N Guichard; sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement On 2/7/2017 2:24 PM, James N Guichard wrote: A request was made to be more specific and update the text as follows: "Service index MUST be decremented by a value of 1 by Service Functions or = by SFC Proxy nodes after performing required services ..." A couple of observations: - The term "SFC Proxy node" is not defined in either the NSH draft or in RF= C 7665. I think the intention here is to say "SFC Proxy". - Is the intention that the SI remain unchanged while the SF is operating o= n the packet, or is the intention only that the SI be decremented before th= e packet is delivered by the SF or SFC Proxy to an SFF? I'd suggest either: "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the= SI by 1 before delivering the packet to the next SFF" or "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement the= SI by 1 before delivering the packet to the next SFF, but not until the SF= has finished all its other processing of the packet" depending upon which is intended. I think an implication of these procedures is that an SI value of 1 is not = valid. If an SF gets an NSH packet with an SI of 1, the SF will decrement = the SI (setting it to 0), send the packet to an SFF, and the SFF will disca= rd it, because 0 is an invalid SI value. Is that the intention? The draft makes it clear (well, sort of) that an SFF should discard a packe= t with an SI of 0, but does not seem to say that an SF or SFC Proxy should = discard a packet it receives with an SI of 0. It would probably be a good = idea to say that. Some text in the draft (e.g., section 7.1) states than an SFF should discar= d a packet with an SI of zero, but other text in the draft (e.g., section 3= .3) only says that an SFF should log an error if it sees an SI of zero. It= 's probably best to change the text in 3.3. to say "SHOULD generate an erro= r/log message and MUST discard the packet", or something similar. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB69AESJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This mechanism has been in the docume= nt for the past x years and is not dissimilar to what a router will do with= a packet whose TTL =3D 0 e.g. something broke, drop the packet and tell someone you did that.

 

Jim

&nbs= p;

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Thursday, February 09, 2017 12:43 PM
To: Dave Dolson <ddolson@sandvine.com>
Cc: James N Guichard <james.n.guichard@huawei.com>; Fabricio F= erraz <fabricio-ferraz@telecom.pt>; Dolganow, Andrew (Nokia - SG) <= ;andrew.dolganow@nokia.com>; Eric C Rosen <erosen@juniper.net>; sf= c@ietf.org
Subject: Re: [sfc] NSH Service Index Decrement

 

agree.


On Feb 9, 2017, at 12:28 PM, Dave Dolson <ddolson@sandvine.com> wrote:

I’m not clear on why this is br= oken, or why this restriction is made.

I agree it should not be sent to an S= F, but an SFF could map an SI of zero into a path termination.<= /o:p>

I.e., the last SF in a path could dec= rement SI from 1 to 0, and the SFF could then terminate the chain.

 

 

From: sfc [mailto:sfc-bounces@ie= tf.org] On Behalf Of James N Guichard
Sent: Thursday, February 09, 2017 12:02 PM
To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eri= c C Rosen; sfc@ietf.org
Subject: Re: [sfc] NSH Service Index Decrement

 

Not exactly. Section 3.3 specifies &#= 8220;The value zero for SI is not valid and indicates a broken SFC or malfu= nctioning SF” .. In other words an SF should never receive an NSH packet with SI =3D 0. Note that if this happened then either a) a c= lassifier set the SI incorrectly, or b) a re-classifier set the SI incorrec= tly, or c) an upstream SF set the SI incorrectly; all of these cases should= be caught by the SFF whose job it is to discard NSH packets with SI =3D 0.

 

Jim

 

From: Fabricio Ferraz [<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= mailto:fabricio-ferraz@telecom.pt]
Sent: Thursday, February 09, 2017 11:49 AM
To: James N Guichard <james.n.guichard@huawei.com>; Dolganow, Andrew (Nokia - SG) <andrew.dolganow@nokia.com>; Dave Dolson <ddolson@sa= ndvine.com>; Eric C Rosen <erosen@juniper.net>; sfc@ietf.org
Subject: RE: [sfc] NSH Service Index Decrement

 

Hi Jim,

Thanks.

 

One more question about the SI.

 

Section 3 states that:

 

Service Index (SI): provides location within the SFP= . The initial classifier MUST set the appropriate SI value for a given clas= sification result. The initial SI value SHOULD default to 255. However, the= classifier MUST allow configuration of other SI values.

Service Index MUST be decremented by Service Functio= ns or by SFC Proxy nodes after performing required services and the new dec= remented SI value MUST be used in the egress NSH packet.

The initial Classifier MUST send the packet to the f= irst SFF in the identified SFP for forwarding along an SFP.

If re-classification occurs, and that re-classificat= ion results in a new SPI, the (re)classifier is, in effect, the initial cla= ssifier for the resultant SPI.

 

Thus:

a)      Initial SI value should be 255 but o= ther values can be configured by the classifier.

b)      SF decrements the SI value on the eg= ress NSH packet

c)      If re-classification occurs with new= SPI, the re-classifier is the initial classifier, so by  a), SI shoul= d be again 255 or other value

 

So any SI value can be receive by an = SF, even 1 or 0 because:

? If SI=3D1 and there is no re-= classification, the egress NSH will have SI=3D0

? If SI=3D0 and there is re-cla= ssification with new SPI, the egress NSH will have a new SPI and a SI=3D 25= 5 or other value, as stated in a).

? If SI=3D0 and there is no re-= classification the SF should discard the packet

 

Also an SFF should forward/handle pac= kets with NSH with SI=3D1 or SI=3D0.

 

Do you agree?

 

 

 

From: sfc [mailto:sfc-bounces@ie= tf.org] On Behalf Of James N Guichard
Sent: quinta-feira, 9 de fevereiro de 2017 16:25
To: Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; Eri= c C Rosen; sfc@ietf.org
Subject: Re: [sfc] NSH Service Index Decrement

 

Hi Fabricio,

 

Welcome!

 

Yes, removal of NSH is the responsibi= lity of an SFF or a re-classifier (section 4, bullet point 1 lays this out)= . With the current architecture the SF does not care what SI value it gets, it just needs to worry about decrementing it, = and leave it up to the SFF to evaluate the SI value and associated action.<= /span>

 

Jim

 

From: Fabricio Ferraz [<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= mailto:fabricio-ferraz@telecom.pt]
Sent: Thursday, February 09, 2017 7:13 AM
To: Dolganow, Andrew (Nokia - SG) <andrew.dolganow@nokia.comddolson@sa= ndvine.com>; Eric C Rosen <erosen@juniper.net>; James N Guichard <james.n.guichard@huawei.com>; sfc@ietf.org
Subject: RE: [sfc] NSH Service Index Decrement

 

Hi all,=

I’m new here (just read the dra= ft last week) but according to chapter 4 (check figure 8 for example), an S= F is not allowed to insert or remove NSH. The removal of NSH is reponsability of the SSF, right?

 

  = Figure 8 maps each of the four actions above to the components in the

 &= nbsp; SFC architecture that can perform it.

 <= /span>

+--= -------------+------------------+-------+----------------+-= --------+

| =             &nb= sp;  |  Insert         |S= elect |   Update       |Service&nbs= p; |

| =             &nb= sp;  |  or remove NSH  |Service|    NSH =         |policy   |

| =             &nb= sp;  |          &nbs= p;      |Function|     &n= bsp;         |selection|

| Compo= nent      +--------+--------+Path = ;  +----------------+       = ;  |

| =             &nb= sp;  |        |   &n= bsp;    |       | Dec. &n= bsp; |Update |         |

| =             &nb= sp;  | Insert | Remove |       |Service = |Context|         |

| =             &nb= sp;  |        |   &n= bsp;    |       | Index  = |Header |         |

+--= --------------+--------+--------+-------+--------+-----= --+---------+

| =             &nb= sp;  |   +    |   + &n= bsp;  |       |    &= nbsp;   |   +   |    =      |

|Classi= fier      |      &nb= sp; |        |    &n= bsp;  |        |   &= nbsp;   |         |

+--= ------------- +--------+--------+-------+--------+-----= --+---------+

|Servic= e Function|        |   +&n= bsp;   |  +    |    &= nbsp;   |       |   =       |

|Forwar= der(SFF)  |        |  &nb= sp;     |       | &n= bsp;      |       |&= nbsp;        |

+--= ------------- +--------+--------+-------+--------+-----= --+---------+

|Servic= e         |    =     |        |  &nbs= p;    |   +    | &nbs= p; +   |   +     |

|Functi= on  (SF)  |        | &nbs= p;      |       |&nb= sp;       |     &nbs= p; |         |

+--= ------------- +--------+--------+-------+--------+-----= --+---------+

|SFC Pr= oxy       |   +  &nbs= p; |   +    |     &nb= sp; |   +    |     &n= bsp; |         |<= /p>

+--= --------------+--------+--------+-------+--------+-----= --+---------+

 <= /span>

 &= nbsp;           &nbs= p;     Figure 8: NSH Action and Role Mapping

 

 

An SF could receive an NSH packet wit= h an SI of 1, and reclassify it to a different SPI and SI, right? So when a= SF receives a NSH packet with SI =3D 1 that does not necessarily means a non valid packet.

And that can even work for SI=3D0, si= nce you decrement the SI in the egress.

 

Fabricio

 

 

From: sfc [mailto:sfc-bounces@ie= tf.org] On Behalf Of Dolganow, Andrew (Nokia - SG)
Sent: quinta-feira, 9 de fevereiro de 2017 01:51
To: Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org
Subject: Re: [sfc] NSH Service Index Decrement

 

I assumed that if we get value 1 w= e process then forward without NSH header (i.e.) this is the last SF proces= sing.

 

So with that assumption, a more ex= plicit text would be:

 

An SF or SFC Proxy receiving an NS= H-encapsulated packet MUST decrement the SI by 1 after performing all requi= red local processing and before forwarding the packet to the next SFF. If the resulting SI is 0, the SF MUST remove the N= SH header before forwarding the packet.

 

Andrew

From: sfc &= lt;sfc-bounces@ietf.org> on behalf of Dave Dol= son <ddolson@sandvine.com>
Date: Thursday, February 9, 2017 at 2:04 AM
To: Eric Rosen <erosen@juniper.net>, J= ames N Guichard <<= span style=3D"font-family:"Calibri",sans-serif">james.n.guichard@= huawei.com>, "sfc@ietf.org" <sfc@= ietf.org>
Subject: Re: [sfc] NSH Service Index Decrement

 

Eric,

I was neve= r quite happy with the outcome that neither 0 nor 1 is a valid SI.

(Because i= f received with value of 1, it is decremented and discarded.)

 

It seems t= o waste an index value.

 

I guess I&= #8217;m interested to know if that is important to other implementers, or i= f that was even the intention?

 

 

-Dave

 

 

 

From:= sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric C Rosen
Sent: Wednesday, February 08, 2017 11:53 AM
To: James N Guichard; sfc@iet= f.org
Subject: Re: [sfc] NSH Service Index Decrement

 

On 2/7/2017 2:24 PM, James N Guichard wrote:

A request was made to be more specific and update the text as follows:=

 

“Service index MUST be decremented by a value of 1 by Service = Functions or by SFC Proxy nodes after performing required services …&= #8221;


A couple of observations:

- The term "SFC Proxy node" is not defined in either the NSH draf= t or in RFC 7665.  I think the intention here is to say "SFC Prox= y".

- Is the intention that the SI remain unchanged while the SF is operating o= n the packet, or is the intention only that the SI be decremented before th= e packet is delivered by the SF or SFC Proxy to an SFF?

I'd suggest either:

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decremen= t the SI by 1 before delivering the packet to the next SFF"

or

"An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decremen= t the SI by 1 before delivering the packet to the next SFF, but not until t= he SF has finished all its other processing of the packet"

depending upon which is intended.

I think an implication of these procedures is that an SI value of 1 is not = valid.  If an SF gets an NSH packet with an SI of 1, the SF will decre= ment the SI (setting it to 0), send the packet to an SFF, and the SFF will = discard it, because 0 is an invalid SI value.  Is that the intention?

The draft makes it clear (well, sort of) that an SFF should discard a packe= t with an SI of 0, but does not seem to say that an SF or SFC Proxy should = discard a packet it receives with an SI of 0.  It would probably be a = good idea to say that.

Some text in the draft (e.g., section 7.1) states than an SFF should discar= d a packet with an SI of zero, but other text in the draft (e.g., section 3= .3) only says that an SFF should log an error if it sees an SI of zero.&nbs= p; It's probably best to change the text in 3.3. to say "SHOULD generate an error/log message and MUST discard= the packet", or something similar.

___________________= ____________________________
sfc mailing list
sfc@ietf.org
https://www.ie= tf.org/mailman/listinfo/sfc=

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB69AESJCEML701CHMchina_-- From nobody Thu Feb 9 11:34:16 2017 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 B6F22129C6E for ; Thu, 9 Feb 2017 11:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 VUi3AsT7fBzc for ; Thu, 9 Feb 2017 11:34:12 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0117.outbound.protection.outlook.com [104.47.36.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE59129C71 for ; Thu, 9 Feb 2017 11:34:12 -0800 (PST) Received: from AT5PR84MB0305.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.27) by AT5PR84MB0306.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 9 Feb 2017 19:34:10 +0000 Received: from AT5PR84MB0305.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.27]) by AT5PR84MB0305.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.27]) with mapi id 15.01.0888.026; Thu, 9 Feb 2017 19:34:10 +0000 From: "Fedyk, Don" To: Dave Dolson , James N Guichard , Fabricio Ferraz , "Dolganow, Andrew (Nokia - SG)" , Eric C Rosen , "sfc@ietf.org" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAAtMROAAAJ/QoAAEEWfAAAVt+wAAAjUqIAAAM/fAAAAelaAAADoKYAABA85AA== Date: Thu, 9 Feb 2017 19:34:10 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> 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=don.fedyk@hpe.com; x-originating-ip: [173.76.164.142] x-ms-office365-filtering-correlation-id: 93d41ea8-16b8-44fb-7be5-08d451229f34 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AT5PR84MB0306; x-microsoft-exchange-diagnostics: 1; AT5PR84MB0306; 7:b2vSPoA2Fw8FX1ZJ/AgobVMaiXxz8C8Gz716HY7P+fWl+f1p+sWtnuHL5Qnd8EMMZDCQMBpjXw3w6aeIu2d8Gk7IErerMrPlEvySNem7fHLeWLsq9b3BOx1QdqBkXBzJQHThxvYJvjAqlk04OZyfVmTn/R5fWUlyrhQP0jKceNRbxhliCWa1ZL9U71BHTKepsLdX774ye3RpwK8Z51UwcV4uWSjW+XS+8UtdQiLNEYK/coaSlPvj6c/pqO7nlsA+XLeFowpch5PbE/U1ZL8YAaRBc0PDBJGzRA00ARj5hWDMpHA2QxK4hfi+n/lGz5niKmFBALstcI8ZSgCsJ0hd/ZtKhd2n/ADzTFQSoJqTLcGFeFwdkZBAsHCWLv/ex3Jt8eLH5WTERlFxsehC4nfUxjSL9mHHQSHvNvVmSWqrTfAvLlnQAFAJvCgTqwscl5ux9nZL4Bur6w31q880SIi+E3ttKtEZHu7k/rFIflkJnKr9zIvTdLmdAfULo7KTFabAAutNf08fwlaA5DITvMPF/Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(82608151540597)(21748063052155)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(6072148); SRVR:AT5PR84MB0306; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0306; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(199003)(53754006)(189002)(377454003)(24454002)(38730400002)(122556002)(8936002)(9686003)(8666007)(2950100002)(55016002)(54896002)(6306002)(2900100001)(53946003)(229853002)(5660300001)(2501003)(81156014)(8676002)(66066001)(236005)(93886004)(81166006)(6436002)(6506006)(7696004)(77096006)(53936002)(6246003)(53546003)(31430400001)(3846002)(3660700001)(6116002)(2906002)(3280700002)(1941001)(790700001)(105586002)(106356001)(189998001)(74316002)(68736007)(86362001)(33656002)(92566002)(97736004)(7736002)(101416001)(76176999)(102836003)(54356999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0306; H:AT5PR84MB0305.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AT5PR84MB0305CA9317AB0AC7AADE3746F6450AT5PR84MB0305NAMP_" MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2017 19:34:10.6746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0306 Archived-At: Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:34:16 -0000 --_000_AT5PR84MB0305CA9317AB0AC7AADE3746F6450AT5PR84MB0305NAMP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBub3cgdGhhdCB0aGVyZSBpcyBhIGRpc3RpbmN0IFRUTCB0aGUgU0kgdGV4dCBjYW4g YmUgcmVsYXhlZCBhIGJpdC4gIFRoZSBTSSB3YXMgc2VydmluZyBtdWx0aSBwdXJwb3NlcyBwcmV2 aW91c2x5LiAgQ2hhaW5zIHNob3VsZCBiZSBhYmxlIHRvIG9wZXJhdGUgbm9ybWFsbHkgb24gYW55 IHZhbHVlIHJldHVybmVkIGZyb20gYW4gU0YgaW5jbHVkaW5nIDAuICBBdCB0aGUgU0ZGIHRoZSBs b29rdXAgb2YgU0lEL1NJIGhhcyB0byBiZSB2YWxpZC4NCg0KQ2hlZXJzDQpEb24NCg0KRnJvbTog c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIERvbHNv bg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAyMDE3IDEyOjI4IFBNDQpUbzogSmFtZXMg TiBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPjsgRmFicmljaW8gRmVycmF6 IDxmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdD47IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0g U0cpIDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPjsgRXJpYyBDIFJvc2VuIDxlcm9zZW5AanVu aXBlci5uZXQ+OyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJ bmRleCBEZWNyZW1lbnQNCg0KSeKAmW0gbm90IGNsZWFyIG9uIHdoeSB0aGlzIGlzIGJyb2tlbiwg b3Igd2h5IHRoaXMgcmVzdHJpY3Rpb24gaXMgbWFkZS4NCkkgYWdyZWUgaXQgc2hvdWxkIG5vdCBi ZSBzZW50IHRvIGFuIFNGLCBidXQgYW4gU0ZGIGNvdWxkIG1hcCBhbiBTSSBvZiB6ZXJvIGludG8g YSBwYXRoIHRlcm1pbmF0aW9uLg0KSS5lLiwgdGhlIGxhc3QgU0YgaW4gYSBwYXRoIGNvdWxkIGRl Y3JlbWVudCBTSSBmcm9tIDEgdG8gMCwgYW5kIHRoZSBTRkYgY291bGQgdGhlbiB0ZXJtaW5hdGUg dGhlIGNoYWluLg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSmFtZXMgTiBHdWljaGFyZA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA5 LCAyMDE3IDEyOjAyIFBNDQpUbzogRmFicmljaW8gRmVycmF6OyBEb2xnYW5vdywgQW5kcmV3IChO b2tpYSAtIFNHKTsgRGF2ZSBEb2xzb247IEVyaWMgQyBSb3Nlbjsgc2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVj cmVtZW50DQoNCk5vdCBleGFjdGx5LiBTZWN0aW9uIDMuMyBzcGVjaWZpZXMg4oCcVGhlIHZhbHVl IHplcm8gZm9yIFNJIGlzIG5vdCB2YWxpZCBhbmQgaW5kaWNhdGVzIGEgYnJva2VuIFNGQyBvciBt YWxmdW5jdGlvbmluZyBTRuKAnSAuLiBJbiBvdGhlciB3b3JkcyBhbiBTRiBzaG91bGQgbmV2ZXIg cmVjZWl2ZSBhbiBOU0ggcGFja2V0IHdpdGggU0kgPSAwLiBOb3RlIHRoYXQgaWYgdGhpcyBoYXBw ZW5lZCB0aGVuIGVpdGhlciBhKSBhIGNsYXNzaWZpZXIgc2V0IHRoZSBTSSBpbmNvcnJlY3RseSwg b3IgYikgYSByZS1jbGFzc2lmaWVyIHNldCB0aGUgU0kgaW5jb3JyZWN0bHksIG9yIGMpIGFuIHVw c3RyZWFtIFNGIHNldCB0aGUgU0kgaW5jb3JyZWN0bHk7IGFsbCBvZiB0aGVzZSBjYXNlcyBzaG91 bGQgYmUgY2F1Z2h0IGJ5IHRoZSBTRkYgd2hvc2Ugam9iIGl0IGlzIHRvIGRpc2NhcmQgTlNIIHBh Y2tldHMgd2l0aCBTSSA9IDAuDQoNCkppbQ0KDQpGcm9tOiBGYWJyaWNpbyBGZXJyYXogW21haWx0 bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdF0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAw OSwgMjAxNyAxMTo0OSBBTQ0KVG86IEphbWVzIE4gR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRA aHVhd2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPj47IERvbGdhbm93 LCBBbmRyZXcgKE5va2lhIC0gU0cpIDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPG1haWx0bzph bmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPj47IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5l LmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+PjsgRXJpYyBDIFJvc2VuIDxlcm9zZW5A anVuaXBlci5uZXQ8bWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5ldD4+OyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBE ZWNyZW1lbnQNCg0KSGkgSmltLA0KVGhhbmtzLg0KDQpPbmUgbW9yZSBxdWVzdGlvbiBhYm91dCB0 aGUgU0kuDQoNClNlY3Rpb24gMyBzdGF0ZXMgdGhhdDoNCg0KU2VydmljZSBJbmRleCAoU0kpOiBw cm92aWRlcyBsb2NhdGlvbiB3aXRoaW4gdGhlIFNGUC4gVGhlIGluaXRpYWwgY2xhc3NpZmllciBN VVNUIHNldCB0aGUgYXBwcm9wcmlhdGUgU0kgdmFsdWUgZm9yIGEgZ2l2ZW4gY2xhc3NpZmljYXRp b24gcmVzdWx0LiBUaGUgaW5pdGlhbCBTSSB2YWx1ZSBTSE9VTEQgZGVmYXVsdCB0byAyNTUuIEhv d2V2ZXIsIHRoZSBjbGFzc2lmaWVyIE1VU1QgYWxsb3cgY29uZmlndXJhdGlvbiBvZiBvdGhlciBT SSB2YWx1ZXMuDQpTZXJ2aWNlIEluZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgYnkgU2VydmljZSBG dW5jdGlvbnMgb3IgYnkgU0ZDIFByb3h5IG5vZGVzIGFmdGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQg c2VydmljZXMgYW5kIHRoZSBuZXcgZGVjcmVtZW50ZWQgU0kgdmFsdWUgTVVTVCBiZSB1c2VkIGlu IHRoZSBlZ3Jlc3MgTlNIIHBhY2tldC4NClRoZSBpbml0aWFsIENsYXNzaWZpZXIgTVVTVCBzZW5k IHRoZSBwYWNrZXQgdG8gdGhlIGZpcnN0IFNGRiBpbiB0aGUgaWRlbnRpZmllZCBTRlAgZm9yIGZv cndhcmRpbmcgYWxvbmcgYW4gU0ZQLg0KSWYgcmUtY2xhc3NpZmljYXRpb24gb2NjdXJzLCBhbmQg dGhhdCByZS1jbGFzc2lmaWNhdGlvbiByZXN1bHRzIGluIGEgbmV3IFNQSSwgdGhlIChyZSljbGFz c2lmaWVyIGlzLCBpbiBlZmZlY3QsIHRoZSBpbml0aWFsIGNsYXNzaWZpZXIgZm9yIHRoZSByZXN1 bHRhbnQgU1BJLg0KDQpUaHVzOg0KDQphKSAgICAgIEluaXRpYWwgU0kgdmFsdWUgc2hvdWxkIGJl IDI1NSBidXQgb3RoZXIgdmFsdWVzIGNhbiBiZSBjb25maWd1cmVkIGJ5IHRoZSBjbGFzc2lmaWVy Lg0KDQpiKSAgICAgIFNGIGRlY3JlbWVudHMgdGhlIFNJIHZhbHVlIG9uIHRoZSBlZ3Jlc3MgTlNI IHBhY2tldA0KDQpjKSAgICAgICBJZiByZS1jbGFzc2lmaWNhdGlvbiBvY2N1cnMgd2l0aCBuZXcg U1BJLCB0aGUgcmUtY2xhc3NpZmllciBpcyB0aGUgaW5pdGlhbCBjbGFzc2lmaWVyLCBzbyBieSAg YSksIFNJIHNob3VsZCBiZSBhZ2FpbiAyNTUgb3Igb3RoZXIgdmFsdWUNCg0KU28gYW55IFNJIHZh bHVlIGNhbiBiZSByZWNlaXZlIGJ5IGFuIFNGLCBldmVuIDEgb3IgMCBiZWNhdXNlOg0KDQrDqCBJ ZiBTST0xIGFuZCB0aGVyZSBpcyBubyByZS1jbGFzc2lmaWNhdGlvbiwgdGhlIGVncmVzcyBOU0gg d2lsbCBoYXZlIFNJPTANCg0Kw6ggSWYgU0k9MCBhbmQgdGhlcmUgaXMgcmUtY2xhc3NpZmljYXRp b24gd2l0aCBuZXcgU1BJLCB0aGUgZWdyZXNzIE5TSCB3aWxsIGhhdmUgYSBuZXcgU1BJIGFuZCBh IFNJPSAyNTUgb3Igb3RoZXIgdmFsdWUsIGFzIHN0YXRlZCBpbiBhKS4NCg0Kw6ggSWYgU0k9MCBh bmQgdGhlcmUgaXMgbm8gcmUtY2xhc3NpZmljYXRpb24gdGhlIFNGIHNob3VsZCBkaXNjYXJkIHRo ZSBwYWNrZXQNCg0KQWxzbyBhbiBTRkYgc2hvdWxkIGZvcndhcmQvaGFuZGxlIHBhY2tldHMgd2l0 aCBOU0ggd2l0aCBTST0xIG9yIFNJPTAuDQoNCkRvIHlvdSBhZ3JlZT8NCg0KDQoNCkZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFtZXMgTiBHdWlj aGFyZA0KU2VudDogcXVpbnRhLWZlaXJhLCA5IGRlIGZldmVyZWlybyBkZSAyMDE3IDE2OjI1DQpU bzogRmFicmljaW8gRmVycmF6OyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRGF2ZSBE b2xzb247IEVyaWMgQyBSb3Nlbjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50DQoNCkhpIEZhYnJp Y2lvLA0KDQpXZWxjb21lIQ0KDQpZZXMsIHJlbW92YWwgb2YgTlNIIGlzIHRoZSByZXNwb25zaWJp bGl0eSBvZiBhbiBTRkYgb3IgYSByZS1jbGFzc2lmaWVyIChzZWN0aW9uIDQsIGJ1bGxldCBwb2lu dCAxIGxheXMgdGhpcyBvdXQpLiBXaXRoIHRoZSBjdXJyZW50IGFyY2hpdGVjdHVyZSB0aGUgU0Yg ZG9lcyBub3QgY2FyZSB3aGF0IFNJIHZhbHVlIGl0IGdldHMsIGl0IGp1c3QgbmVlZHMgdG8gd29y cnkgYWJvdXQgZGVjcmVtZW50aW5nIGl0LCBhbmQgbGVhdmUgaXQgdXAgdG8gdGhlIFNGRiB0byBl dmFsdWF0ZSB0aGUgU0kgdmFsdWUgYW5kIGFzc29jaWF0ZWQgYWN0aW9uLg0KDQpKaW0NCg0KRnJv bTogRmFicmljaW8gRmVycmF6IFttYWlsdG86ZmFicmljaW8tZmVycmF6QHRlbGVjb20ucHRdDQpT ZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDksIDIwMTcgNzoxMyBBTQ0KVG86IERvbGdhbm93LCBB bmRyZXcgKE5va2lhIC0gU0cpIDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPG1haWx0bzphbmRy ZXcuZG9sZ2Fub3dAbm9raWEuY29tPj47IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNv bTxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+PjsgRXJpYyBDIFJvc2VuIDxlcm9zZW5AanVu aXBlci5uZXQ8bWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5ldD4+OyBKYW1lcyBOIEd1aWNoYXJkIDxq YW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2Vp LmNvbT4+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBb c2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQNCg0KSGkgYWxsLA0KSeKAmW0gbmV3IGhl cmUgKGp1c3QgcmVhZCB0aGUgZHJhZnQgbGFzdCB3ZWVrKSBidXQgYWNjb3JkaW5nIHRvIGNoYXB0 ZXIgNCAoY2hlY2sgZmlndXJlIDggZm9yIGV4YW1wbGUpLCBhbiBTRiBpcyBub3QgYWxsb3dlZCB0 byBpbnNlcnQgb3IgcmVtb3ZlIE5TSC4gVGhlIHJlbW92YWwgb2YgTlNIIGlzIHJlcG9uc2FiaWxp dHkgb2YgdGhlIFNTRiwgcmlnaHQ/DQoNCiAgRmlndXJlIDggbWFwcyBlYWNoIG9mIHRoZSBmb3Vy IGFjdGlvbnMgYWJvdmUgdG8gdGhlIGNvbXBvbmVudHMgaW4gdGhlDQogICBTRkMgYXJjaGl0ZWN0 dXJlIHRoYXQgY2FuIHBlcmZvcm0gaXQuDQoNCistLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rDQp8ICAgICAgICAgICAg ICAgIHwgIEluc2VydCAgICAgICAgIHxTZWxlY3QgfCAgIFVwZGF0ZSAgICAgICB8U2VydmljZSAg fA0KfCAgICAgICAgICAgICAgICB8ICBvciByZW1vdmUgTlNIICB8U2VydmljZXwgICAgTlNIICAg ICAgICAgfHBvbGljeSAgIHwNCnwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfEZ1 bmN0aW9ufCAgICAgICAgICAgICAgIHxzZWxlY3Rpb258DQp8IENvbXBvbmVudCAgICAgICstLS0t LS0tLSstLS0tLS0tLStQYXRoICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgfA0KfCAgICAg ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICB8ICAgICAgIHwgRGVjLiAgIHxVcGRhdGUgfCAg ICAgICAgIHwNCnwgICAgICAgICAgICAgICAgfCBJbnNlcnQgfCBSZW1vdmUgfCAgICAgICB8U2Vy dmljZSB8Q29udGV4dHwgICAgICAgICB8DQp8ICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAg ICAgIHwgICAgICAgfCBJbmRleCAgfEhlYWRlciB8ICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsN CnwgICAgICAgICAgICAgICAgfCAgICsgICAgfCAgICsgICAgfCAgICAgICB8ICAgICAgICB8ICAg KyAgIHwgICAgICAgICB8DQp8Q2xhc3NpZmllciAgICAgIHwgICAgICAgIHwgICAgICAgIHwgICAg ICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0tLSArLS0tLS0t LS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsNCnxTZXJ2aWNl IEZ1bmN0aW9ufCAgICAgICAgfCAgICsgICAgfCAgKyAgICB8ICAgICAgICB8ICAgICAgIHwgICAg ICAgICB8DQp8Rm9yd2FyZGVyKFNGRikgIHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAg ICAgfCAgICAgICB8ICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0tLSArLS0tLS0tLS0rLS0tLS0t LS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsNCnxTZXJ2aWNlICAgICAgICAg fCAgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgKyAgICB8ICAgKyAgIHwgICArICAgICB8DQp8 RnVuY3Rpb24gIChTRikgIHwgICAgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICAgfCAgICAg ICB8ICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0tLSArLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0t LSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsNCnxTRkMgUHJveHkgICAgICAgfCAgICsgICAg fCAgICsgICAgfCAgICAgICB8ICAgKyAgICB8ICAgICAgIHwgICAgICAgICB8DQorLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0t LS0tKw0KDQogICAgICAgICAgICAgICAgICAgRmlndXJlIDg6IE5TSCBBY3Rpb24gYW5kIFJvbGUg TWFwcGluZw0KDQoNCkFuIFNGIGNvdWxkIHJlY2VpdmUgYW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJ IG9mIDEsIGFuZCByZWNsYXNzaWZ5IGl0IHRvIGEgZGlmZmVyZW50IFNQSSBhbmQgU0ksIHJpZ2h0 PyBTbyB3aGVuIGEgU0YgcmVjZWl2ZXMgYSBOU0ggcGFja2V0IHdpdGggU0kgPSAxIHRoYXQgZG9l cyBub3QgbmVjZXNzYXJpbHkgbWVhbnMgYSBub24gdmFsaWQgcGFja2V0Lg0KQW5kIHRoYXQgY2Fu IGV2ZW4gd29yayBmb3IgU0k9MCwgc2luY2UgeW91IGRlY3JlbWVudCB0aGUgU0kgaW4gdGhlIGVn cmVzcy4NCg0KRmFicmljaW8NCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpDQpTZW50OiBx dWludGEtZmVpcmEsIDkgZGUgZmV2ZXJlaXJvIGRlIDIwMTcgMDE6NTENClRvOiBEYXZlIERvbHNv bjsgRXJpYyBDIFJvc2VuOyBKYW1lcyBOIEd1aWNoYXJkOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1l bnQNCg0KSSBhc3N1bWVkIHRoYXQgaWYgd2UgZ2V0IHZhbHVlIDEgd2UgcHJvY2VzcyB0aGVuIGZv cndhcmQgd2l0aG91dCBOU0ggaGVhZGVyIChpLmUuKSB0aGlzIGlzIHRoZSBsYXN0IFNGIHByb2Nl c3NpbmcuDQoNClNvIHdpdGggdGhhdCBhc3N1bXB0aW9uLCBhIG1vcmUgZXhwbGljaXQgdGV4dCB3 b3VsZCBiZToNCg0KQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxh dGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0aGUgU0kgYnkgMSBhZnRlciBwZXJmb3JtaW5nIGFs bCByZXF1aXJlZCBsb2NhbCBwcm9jZXNzaW5nIGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFj a2V0IHRvIHRoZSBuZXh0IFNGRi4gSWYgdGhlIHJlc3VsdGluZyBTSSBpcyAwLCB0aGUgU0YgTVVT VCByZW1vdmUgdGhlIE5TSCBoZWFkZXIgYmVmb3JlIGZvcndhcmRpbmcgdGhlIHBhY2tldC4NCg0K QW5kcmV3DQpGcm9tOiBzZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5j b208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4NCkRhdGU6IFRodXJzZGF5LCBGZWJydWFy eSA5LCAyMDE3IGF0IDI6MDQgQU0NClRvOiBFcmljIFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ8 bWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5ldD4+LCBKYW1lcyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1 aWNoYXJkQGh1YXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbT4+LCAi c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3Jl bWVudA0KDQpFcmljLA0KSSB3YXMgbmV2ZXIgcXVpdGUgaGFwcHkgd2l0aCB0aGUgb3V0Y29tZSB0 aGF0IG5laXRoZXIgMCBub3IgMSBpcyBhIHZhbGlkIFNJLg0KKEJlY2F1c2UgaWYgcmVjZWl2ZWQg d2l0aCB2YWx1ZSBvZiAxLCBpdCBpcyBkZWNyZW1lbnRlZCBhbmQgZGlzY2FyZGVkLikNCg0KSXQg c2VlbXMgdG8gd2FzdGUgYW4gaW5kZXggdmFsdWUuDQoNCkkgZ3Vlc3MgSeKAmW0gaW50ZXJlc3Rl ZCB0byBrbm93IGlmIHRoYXQgaXMgaW1wb3J0YW50IHRvIG90aGVyIGltcGxlbWVudGVycywgb3Ig aWYgdGhhdCB3YXMgZXZlbiB0aGUgaW50ZW50aW9uPw0KDQoNCi1EYXZlDQoNCg0KDQpGcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgQyBSb3Nl bg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyAxMTo1MyBBTQ0KVG86IEphbWVz IE4gR3VpY2hhcmQ7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudA0KDQpPbiAyLzcvMjAxNyAyOjI0 IFBNLCBKYW1lcyBOIEd1aWNoYXJkIHdyb3RlOg0KQSByZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1v cmUgc3BlY2lmaWMgYW5kIHVwZGF0ZSB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KDQrigJxTZXJ2aWNl IGluZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgYnkgYSB2YWx1ZSBvZiAxIGJ5IFNlcnZpY2UgRnVu Y3Rpb25zIG9yIGJ5IFNGQyBQcm94eSBub2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNl cnZpY2VzIOKApuKAnQ0KDQpBIGNvdXBsZSBvZiBvYnNlcnZhdGlvbnM6DQoNCi0gVGhlIHRlcm0g IlNGQyBQcm94eSBub2RlIiBpcyBub3QgZGVmaW5lZCBpbiBlaXRoZXIgdGhlIE5TSCBkcmFmdCBv ciBpbiBSRkMgNzY2NS4gIEkgdGhpbmsgdGhlIGludGVudGlvbiBoZXJlIGlzIHRvIHNheSAiU0ZD IFByb3h5Ii4NCg0KLSBJcyB0aGUgaW50ZW50aW9uIHRoYXQgdGhlIFNJIHJlbWFpbiB1bmNoYW5n ZWQgd2hpbGUgdGhlIFNGIGlzIG9wZXJhdGluZyBvbiB0aGUgcGFja2V0LCBvciBpcyB0aGUgaW50 ZW50aW9uIG9ubHkgdGhhdCB0aGUgU0kgYmUgZGVjcmVtZW50ZWQgYmVmb3JlIHRoZSBwYWNrZXQg aXMgZGVsaXZlcmVkIGJ5IHRoZSBTRiBvciBTRkMgUHJveHkgdG8gYW4gU0ZGPw0KDQpJJ2Qgc3Vn Z2VzdCBlaXRoZXI6DQoNCiJBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNh cHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVtZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVy aW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGIg0KDQpvcg0KDQoiQW4gU0Ygb3IgU0ZDIFBy b3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUIGRlY3JlbWVudCB0 aGUgU0kgYnkgMSBiZWZvcmUgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRiwg YnV0IG5vdCB1bnRpbCB0aGUgU0YgaGFzIGZpbmlzaGVkIGFsbCBpdHMgb3RoZXIgcHJvY2Vzc2lu ZyBvZiB0aGUgcGFja2V0Ig0KDQpkZXBlbmRpbmcgdXBvbiB3aGljaCBpcyBpbnRlbmRlZC4NCg0K SSB0aGluayBhbiBpbXBsaWNhdGlvbiBvZiB0aGVzZSBwcm9jZWR1cmVzIGlzIHRoYXQgYW4gU0kg dmFsdWUgb2YgMSBpcyBub3QgdmFsaWQuICBJZiBhbiBTRiBnZXRzIGFuIE5TSCBwYWNrZXQgd2l0 aCBhbiBTSSBvZiAxLCB0aGUgU0Ygd2lsbCBkZWNyZW1lbnQgdGhlIFNJIChzZXR0aW5nIGl0IHRv IDApLCBzZW5kIHRoZSBwYWNrZXQgdG8gYW4gU0ZGLCBhbmQgdGhlIFNGRiB3aWxsIGRpc2NhcmQg aXQsIGJlY2F1c2UgMCBpcyBhbiBpbnZhbGlkIFNJIHZhbHVlLiAgSXMgdGhhdCB0aGUgaW50ZW50 aW9uPw0KDQpUaGUgZHJhZnQgbWFrZXMgaXQgY2xlYXIgKHdlbGwsIHNvcnQgb2YpIHRoYXQgYW4g U0ZGIHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IHdpdGggYW4gU0kgb2YgMCwgYnV0IGRvZXMgbm90 IHNlZW0gdG8gc2F5IHRoYXQgYW4gU0Ygb3IgU0ZDIFByb3h5IHNob3VsZCBkaXNjYXJkIGEgcGFj a2V0IGl0IHJlY2VpdmVzIHdpdGggYW4gU0kgb2YgMC4gIEl0IHdvdWxkIHByb2JhYmx5IGJlIGEg Z29vZCBpZGVhIHRvIHNheSB0aGF0Lg0KDQpTb21lIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBz ZWN0aW9uIDcuMSkgc3RhdGVzIHRoYW4gYW4gU0ZGIHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IHdp dGggYW4gU0kgb2YgemVybywgYnV0IG90aGVyIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0 aW9uIDMuMykgb25seSBzYXlzIHRoYXQgYW4gU0ZGIHNob3VsZCBsb2cgYW4gZXJyb3IgaWYgaXQg c2VlcyBhbiBTSSBvZiB6ZXJvLiAgSXQncyBwcm9iYWJseSBiZXN0IHRvIGNoYW5nZSB0aGUgdGV4 dCBpbiAzLjMuIHRvIHNheSAiU0hPVUxEIGdlbmVyYXRlIGFuIGVycm9yL2xvZyBtZXNzYWdlIGFu ZCBNVVNUIGRpc2NhcmQgdGhlIHBhY2tldCIsIG9yIHNvbWV0aGluZyBzaW1pbGFyLg0K --_000_AT5PR84MB0305CA9317AB0AC7AADE3746F6450AT5PR84MB0305NAMP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNr O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjE5Mjg5MTU4NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6OTk4MTU3NDUwIDEzNTY1OTU0MyAxMzU2NTk1NDUgMTM1NjU5NTQ3IDEzNTY1OTUzNSAx MzU2NTk1NDUgMTM1NjU5NTQ3IDEzNTY1OTUzNSAxMzU2NTk1NDUgMTM1NjU5NTQ3O30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE5MjIxMzU1NjM7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MjcxNzk2OTAgLTEy NTc3MjQ4MDYgMTM1NjU5NTIzIDEzNTY1OTUyNSAxMzU2NTk1MjEgMTM1NjU5NTIzIDEzNTY1OTUy NSAxMzU2NTk1MjEgMTM1NjU5NTIzIDEzNTY1OTUyNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DqDsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBub3cgdGhhdCB0aGVyZSBpcyBhIGRpc3RpbmN0IFRU TCB0aGUgU0kgdGV4dCBjYW4gYmUgcmVsYXhlZCBhIGJpdC4gJm5ic3A7VGhlIFNJIHdhcyBzZXJ2 aW5nIG11bHRpIHB1cnBvc2VzIHByZXZpb3VzbHkuICZuYnNwO0NoYWlucyBzaG91bGQgYmUgYWJs ZSB0byBvcGVyYXRlIG5vcm1hbGx5DQogb24gYW55IHZhbHVlIHJldHVybmVkIGZyb20gYW4gU0Yg aW5jbHVkaW5nIDAuJm5ic3A7IEF0IHRoZSBTRkYgdGhlIGxvb2t1cCBvZiBTSUQvU0kgaGFzIHRv IGJlIHZhbGlkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5D aGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RG9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkRhdmUgRG9sc29uPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBG ZWJydWFyeSAwOSwgMjAxNyAxMjoyOCBQTTxicj4NCjxiPlRvOjwvYj4gSmFtZXMgTiBHdWljaGFy ZCAmbHQ7amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tJmd0OzsgRmFicmljaW8gRmVycmF6ICZs dDtmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdCZndDs7IERvbGdhbm93LCBBbmRyZXcgKE5va2lh IC0gU0cpICZsdDthbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tJmd0OzsgRXJpYyBDIFJvc2VuICZs dDtlcm9zZW5AanVuaXBlci5uZXQmZ3Q7OyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5J4oCZbSBub3QgY2xlYXIgb24gd2h5IHRoaXMgaXMgYnJva2VuLCBvciB3aHkgdGhpcyBy ZXN0cmljdGlvbiBpcyBtYWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIGl0IHNob3VsZCBu b3QgYmUgc2VudCB0byBhbiBTRiwgYnV0IGFuIFNGRiBjb3VsZCBtYXAgYW4gU0kgb2YgemVybyBp bnRvIGEgcGF0aCB0ZXJtaW5hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SS5lLiwgdGhlIGxhc3Qg U0YgaW4gYSBwYXRoIGNvdWxkIGRlY3JlbWVudCBTSSBmcm9tIDEgdG8gMCwgYW5kIHRoZSBTRkYg Y291bGQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNoYWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkphbWVzIE4gR3VpY2hhcmQ8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDA5 LCAyMDE3IDEyOjAyIFBNPGJyPg0KPGI+VG86PC9iPiBGYWJyaWNpbyBGZXJyYXo7IERvbGdhbm93 LCBBbmRyZXcgKE5va2lhIC0gU0cpOyBEYXZlIERvbHNvbjsgRXJpYyBDIFJvc2VuOw0KPGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPk5vdCBleGFjdGx5LiBTZWN0aW9uIDMuMyBzcGVjaWZpZXMg4oCcVGhlIHZhbHVlIHpl cm8gZm9yIFNJIGlzIG5vdCB2YWxpZCBhbmQgaW5kaWNhdGVzIGEgYnJva2VuIFNGQyBvciBtYWxm dW5jdGlvbmluZyBTRuKAnSAuLiBJbiBvdGhlciB3b3JkcyBhbiBTRiBzaG91bGQgbmV2ZXIgcmVj ZWl2ZQ0KIGFuIE5TSCBwYWNrZXQgd2l0aCBTSSA9IDAuIE5vdGUgdGhhdCBpZiB0aGlzIGhhcHBl bmVkIHRoZW4gZWl0aGVyIGEpIGEgY2xhc3NpZmllciBzZXQgdGhlIFNJIGluY29ycmVjdGx5LCBv ciBiKSBhIHJlLWNsYXNzaWZpZXIgc2V0IHRoZSBTSSBpbmNvcnJlY3RseSwgb3IgYykgYW4gdXBz dHJlYW0gU0Ygc2V0IHRoZSBTSSBpbmNvcnJlY3RseTsgYWxsIG9mIHRoZXNlIGNhc2VzIHNob3Vs ZCBiZSBjYXVnaHQgYnkgdGhlIFNGRiB3aG9zZSBqb2IgaXQNCiBpcyB0byBkaXNjYXJkIE5TSCBw YWNrZXRzIHdpdGggU0kgPSAwLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkppbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+IEZhYnJpY2lvIEZlcnJheiBbPGEgaHJlZj0ibWFpbHRvOmZhYnJpY2lvLWZlcnJhekB0ZWxl Y29tLnB0Ij5tYWlsdG86ZmFicmljaW8tZmVycmF6QHRlbGVjb20ucHQ8L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAxMTo0OSBBTTxicj4NCjxiPlRv OjwvYj4gSmFtZXMgTiBHdWljaGFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbWVzLm4uZ3VpY2hh cmRAaHVhd2VpLmNvbSI+amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPC9hPiZndDs7IERvbGdh bm93LCBBbmRyZXcgKE5va2lhIC0gU0cpICZsdDs8YSBocmVmPSJtYWlsdG86YW5kcmV3LmRvbGdh bm93QG5va2lhLmNvbSI+YW5kcmV3LmRvbGdhbm93QG5va2lhLmNvbTwvYT4mZ3Q7OyBEYXZlIERv bHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tIj5kZG9sc29uQHNh bmR2aW5lLmNvbTwvYT4mZ3Q7Ow0KIEVyaWMgQyBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVy b3NlbkBqdW5pcGVyLm5ldCI+ZXJvc2VuQGp1bmlwZXIubmV0PC9hPiZndDs7IDxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhpIEppbSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T25lIG1vcmUgcXVlc3Rpb24gYWJvdXQgdGhlIFNJLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDMgc3Rh dGVzIHRoYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlcnZpY2UgSW5kZXggKFNJKTogcHJvdmlkZXMgbG9jYXRp b24gd2l0aGluIHRoZSBTRlAuIFRoZSBpbml0aWFsIGNsYXNzaWZpZXIgTVVTVCBzZXQgdGhlIGFw cHJvcHJpYXRlIFNJIHZhbHVlIGZvciBhIGdpdmVuIGNsYXNzaWZpY2F0aW9uIHJlc3VsdC4gVGhl IGluaXRpYWwgU0kgdmFsdWUgU0hPVUxEIGRlZmF1bHQgdG8gMjU1LiBIb3dldmVyLCB0aGUgY2xh c3NpZmllciBNVVNUIGFsbG93IGNvbmZpZ3VyYXRpb24NCiBvZiBvdGhlciBTSSB2YWx1ZXMuIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VydmljZSBJbmRleCBNVVNUIGJl IGRlY3JlbWVudGVkIGJ5IFNlcnZpY2UgRnVuY3Rpb25zIG9yIGJ5IFNGQyBQcm94eSBub2RlcyBh ZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZpY2VzIGFuZCB0aGUgbmV3IGRlY3JlbWVudGVk IFNJIHZhbHVlIE1VU1QgYmUgdXNlZCBpbiB0aGUgZWdyZXNzIE5TSCBwYWNrZXQuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpbml0aWFsIENsYXNzaWZpZXIgTVVT VCBzZW5kIHRoZSBwYWNrZXQgdG8gdGhlIGZpcnN0IFNGRiBpbiB0aGUgaWRlbnRpZmllZCBTRlAg Zm9yIGZvcndhcmRpbmcgYWxvbmcgYW4gU0ZQLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiByZS1jbGFzc2lmaWNhdGlvbiBvY2N1cnMsIGFuZCB0aGF0IHJlLWNsYXNz aWZpY2F0aW9uIHJlc3VsdHMgaW4gYSBuZXcgU1BJLCB0aGUgKHJlKWNsYXNzaWZpZXIgaXMsIGlu IGVmZmVjdCwgdGhlIGluaXRpYWwgY2xhc3NpZmllciBmb3IgdGhlIHJlc3VsdGFudCBTUEkuPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGh1czoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxl dmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YSk8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5Jbml0aWFsIFNJIHZhbHVlIHNob3VsZCBiZSAyNTUgYnV0IG90aGVyIHZh bHVlcyBjYW4gYmUgY29uZmlndXJlZCBieSB0aGUgY2xhc3NpZmllci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIp PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U0YgZGVjcmVtZW50cyB0aGUgU0kgdmFs dWUgb24gdGhlIGVncmVzcyBOU0ggcGFja2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5jKTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHJlLWNsYXNzaWZpY2F0aW9uIG9jY3VycyB3aXRo IG5ldyBTUEksIHRoZSByZS1jbGFzc2lmaWVyIGlzIHRoZSBpbml0aWFsIGNsYXNzaWZpZXIsIHNv IGJ5ICZuYnNwO2EpLCBTSSBzaG91bGQgYmUgYWdhaW4gMjU1IG9yIG90aGVyIHZhbHVlDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvIGFueSBTSSB2YWx1ZSBj YW4gYmUgcmVjZWl2ZSBieSBhbiBTRiwgZXZlbiAxIG9yIDAgYmVjYXVzZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOoPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4NCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgU0k9MSBhbmQgdGhl cmUgaXMgbm8gcmUtY2xhc3NpZmljYXRpb24sIHRoZSBlZ3Jlc3MgTlNIIHdpbGwgaGF2ZSBTST0w PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldpbmdk aW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DqDxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklm IFNJPTAgYW5kIHRoZXJlIGlzIHJlLWNsYXNzaWZpY2F0aW9uIHdpdGggbmV3IFNQSSwgdGhlIGVn cmVzcyBOU0ggd2lsbCBoYXZlIGEgbmV3IFNQSSBhbmQgYSBTST0gMjU1IG9yIG90aGVyIHZhbHVl LCBhcyBzdGF0ZWQgaW4gYSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7DqDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPklmIFNJPTAgYW5kIHRoZXJlIGlzIG5vIHJlLWNsYXNzaWZpY2F0aW9u IHRoZSBTRiBzaG91bGQgZGlzY2FyZCB0aGUgcGFja2V0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5BbHNvIGFuIFNGRiBzaG91bGQgZm9yd2FyZC9oYW5kbGUgcGFj a2V0cyB3aXRoIE5TSCB3aXRoIFNJPTEgb3IgU0k9MC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkRvIHlvdSBhZ3JlZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi PiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFtZXMgTiBHdWljaGFy ZDxicj4NCjxiPlNlbnQ6PC9iPiBxdWludGEtZmVpcmEsIDkgZGUgZmV2ZXJlaXJvIGRlIDIwMTcg MTY6MjU8YnI+DQo8Yj5Ubzo8L2I+IEZhYnJpY2lvIEZlcnJhejsgRG9sZ2Fub3csIEFuZHJldyAo Tm9raWEgLSBTRyk7IERhdmUgRG9sc29uOyBFcmljIEMgUm9zZW47DQo8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb c2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUFQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBGYWJyaWNpbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPldlbGNvbWUhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5ZZXMsIHJlbW92YWwgb2YgTlNIIGlzIHRoZSByZXNwb25zaWJpbGl0eSBv ZiBhbiBTRkYgb3IgYSByZS1jbGFzc2lmaWVyIChzZWN0aW9uIDQsIGJ1bGxldCBwb2ludCAxIGxh eXMgdGhpcyBvdXQpLiBXaXRoIHRoZSBjdXJyZW50IGFyY2hpdGVjdHVyZSB0aGUgU0YgZG9lcyBu b3QNCiBjYXJlIHdoYXQgU0kgdmFsdWUgaXQgZ2V0cywgaXQganVzdCBuZWVkcyB0byB3b3JyeSBh Ym91dCBkZWNyZW1lbnRpbmcgaXQsIGFuZCBsZWF2ZSBpdCB1cCB0byB0aGUgU0ZGIHRvIGV2YWx1 YXRlIHRoZSBTSSB2YWx1ZSBhbmQgYXNzb2NpYXRlZCBhY3Rpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBGYWJyaWNp byBGZXJyYXogWzxhIGhyZWY9Im1haWx0bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdCI+bWFp bHRvOmZhYnJpY2lvLWZlcnJhekB0ZWxlY29tLnB0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgRmVicnVhcnkgMDksIDIwMTcgNzoxMyBBTTxicj4NCjxiPlRvOjwvYj4gRG9sZ2Fu b3csIEFuZHJldyAoTm9raWEgLSBTRykgJmx0OzxhIGhyZWY9Im1haWx0bzphbmRyZXcuZG9sZ2Fu b3dAbm9raWEuY29tIj5hbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPC9hPiZndDs7IERhdmUgRG9s c29uICZsdDs8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20iPmRkb2xzb25Ac2Fu ZHZpbmUuY29tPC9hPiZndDs7IEVyaWMgQyBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyb3Nl bkBqdW5pcGVyLm5ldCI+ZXJvc2VuQGp1bmlwZXIubmV0PC9hPiZndDs7DQogSmFtZXMgTiBHdWlj aGFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbSI+amFt ZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc2ZjXSBO U0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUFQiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPknigJltIG5ldyBoZXJlIChqdXN0IHJl YWQgdGhlIGRyYWZ0IGxhc3Qgd2VlaykgYnV0IGFjY29yZGluZyB0byBjaGFwdGVyIDQgKGNoZWNr IGZpZ3VyZSA4IGZvciBleGFtcGxlKSwgYW4gU0YgaXMgbm90IGFsbG93ZWQgdG8gaW5zZXJ0IG9y IHJlbW92ZSBOU0guIFRoZSByZW1vdmFsDQogb2YgTlNIIGlzIHJlcG9uc2FiaWxpdHkgb2YgdGhl IFNTRiwgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6Ny4wcHQg Ny4wcHQgNy4wcHQgNy4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsgRmlndXJlIDggbWFwcyBlYWNoIG9mIHRoZSBmb3VyIGFjdGlvbnMgYWJv dmUgdG8gdGhlIGNvbXBvbmVudHMgaW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZG RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgU0ZDIGFy Y2hpdGVjdHVyZSB0aGF0IGNhbiBwZXJmb3JtIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5k OiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mIzQzOy0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0t JiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDti YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IEluc2VydCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8U2VsZWN0IHwmbmJzcDsmbmJzcDsg VXBkYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxTZXJ2aWNlJm5ic3A7 IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBv ciByZW1vdmUgTlNIJm5ic3A7IHxTZXJ2aWNlfCZuYnNwOyZuYnNwOyZuYnNwOyBOU0gmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfHBvbGljeSZuYnNwOyZu YnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfEZ1bmN0aW9ufCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8c2VsZWN0aW9ufDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNG RkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCBDb21wb25lbnQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzO1Bh dGgmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IERlYy4mbmJzcDsmbmJzcDsgfFVw ZGF0ZSB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBJbnNlcnQgfCBS ZW1vdmUgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8U2VydmljZSB8Q29u dGV4dHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuMTVwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IEluZGV4Jm5ic3A7IHxIZWFkZXIgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy ZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQz Oy0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy ZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAm IzQzOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyAmIzQzOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt YnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnxDbGFzc2lmaWVyJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1 cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYj NDM7LS0tLS0tLS0tLS0tLS0tICYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0t JiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1 cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnxT ZXJ2aWNlIEZ1bmN0aW9ufCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fEZvcndhcmRlcihT RkYpJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7 YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7 LS0tLS0tLS0tLS0tLS0tICYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tJiM0 MzstLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7 YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnxTZXJ2 aWNlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3wmbmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyAmIzQzOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJl YWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPnxGdW5jdGlvbiZuYnNwOyAoU0YpJm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv cmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7LS0tLS0tLS0tLS0tLS0tICYjNDM7 LS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0t LSYjNDM7LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjE1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv cmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnxTRkMgUHJveHkmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzstLS0tLS0t LS0tLS0tLS0tJiM0MzstLS0tLS0tLSYjNDM7LS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0t LS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuMTVwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny4xNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg RmlndXJlIDg6IE5TSCBBY3Rpb24gYW5kIFJvbGUgTWFwcGluZzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QW4gU0YgY291bGQgcmVjZWl2ZSBhbiBOU0ggcGFja2V0IHdpdGggYW4gU0kgb2YgMSwgYW5kIHJl Y2xhc3NpZnkgaXQgdG8gYSBkaWZmZXJlbnQgU1BJIGFuZCBTSSwgcmlnaHQ/IFNvIHdoZW4gYSBT RiByZWNlaXZlcyBhIE5TSCBwYWNrZXQgd2l0aCBTSSA9IDEgdGhhdCBkb2VzDQogbm90IG5lY2Vz c2FyaWx5IG1lYW5zIGEgbm9uIHZhbGlkIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kIHRo YXQgY2FuIGV2ZW4gd29yayBmb3IgU0k9MCwgc2luY2UgeW91IGRlY3JlbWVudCB0aGUgU0kgaW4g dGhlIGVncmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZh YnJpY2lvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Eb2xnYW5vdywgQW5kcmV3 IChOb2tpYSAtIFNHKTxicj4NCjxiPlNlbnQ6PC9iPiBxdWludGEtZmVpcmEsIDkgZGUgZmV2ZXJl aXJvIGRlIDIwMTcgMDE6NTE8YnI+DQo8Yj5Ubzo8L2I+IERhdmUgRG9sc29uOyBFcmljIEMgUm9z ZW47IEphbWVzIE4gR3VpY2hhcmQ7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2Zj QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gTlNIIFNlcnZpY2Ug SW5kZXggRGVjcmVtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlBUIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+SSBhc3N1bWVkIHRoYXQgaWYgd2UgZ2V0IHZhbHVlIDEgd2UgcHJvY2VzcyB0aGVuIGZv cndhcmQgd2l0aG91dCBOU0ggaGVhZGVyIChpLmUuKSB0aGlzIGlzIHRoZSBsYXN0IFNGIHByb2Nl c3NpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5T byB3aXRoIHRoYXQgYXNzdW1wdGlvbiwgYSBtb3JlIGV4cGxpY2l0IHRleHQgd291bGQgYmU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5BbiBTRiBvciBT RkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QgZGVjcmVt ZW50IHRoZSBTSSBieSAxIGFmdGVyIHBlcmZvcm1pbmcgYWxsIHJlcXVpcmVkIGxvY2FsIHByb2Nl c3NpbmcgYW5kIGJlZm9yZSBmb3J3YXJkaW5nIHRoZQ0KIHBhY2tldCB0byB0aGUgbmV4dCBTRkYu IElmIHRoZSByZXN1bHRpbmcgU0kgaXMgMCwgdGhlIFNGIE1VU1QgcmVtb3ZlIHRoZSBOU0ggaGVh ZGVyIGJlZm9yZSBmb3J3YXJkaW5nIHRoZSBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5BbmRyZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+c2ZjICZsdDs8YSBocmVmPSJtYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24g YmVoYWxmIG9mIERhdmUgRG9sc29uICZsdDs8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5kdmlu ZS5jb20iPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1 cnNkYXksIEZlYnJ1YXJ5IDksIDIwMTcgYXQgMjowNCBBTTxicj4NCjxiPlRvOiA8L2I+RXJpYyBS b3NlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5ldCI+ZXJvc2VuQGp1bmlw ZXIubmV0PC9hPiZndDssIEphbWVzIE4gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1l cy5uLmd1aWNoYXJkQGh1YXdlaS5jb20iPmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVj cmVtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+RXJpYyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pkkgd2FzIG5ldmVyIHF1aXRlIGhhcHB5IHdpdGggdGhlIG91dGNvbWUgdGhhdCBuZWl0aGVyIDAg bm9yIDEgaXMgYSB2YWxpZCBTSS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPihCZWNhdXNlIGlmIHJlY2VpdmVkIHdpdGggdmFsdWUgb2YgMSwgaXQgaXMgZGVjcmVt ZW50ZWQgYW5kIGRpc2NhcmRlZC4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pkl0IHNlZW1zIHRvIHdhc3RlIGFuIGluZGV4IHZhbHVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5JIGd1ZXNzIEnigJltIGludGVyZXN0ZWQgdG8ga25vdyBpZiB0aGF0IGlz IGltcG9ydGFudCB0byBvdGhlciBpbXBsZW1lbnRlcnMsIG9yIGlmIHRoYXQgd2FzIGV2ZW4gdGhl IGludGVudGlvbj88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tRGF2ZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBzZmMgWzxhIGhyZWY9 Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBDIFJvc2VuPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTcgMTE6NTMgQU08YnI+DQo8Yj5Ubzo8L2I+IEph bWVzIE4gR3VpY2hhcmQ7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERl Y3JlbWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KT24g Mi83LzIwMTcgMjoyNCBQTSwgSmFtZXMgTiBHdWljaGFyZCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkEgcmVxdWVzdCB3YXMg bWFkZSB0byBiZSBtb3JlIHNwZWNpZmljIGFuZCB1cGRhdGUgdGhlIHRleHQgYXMgZm9sbG93czo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4iPg0K4oCcU2VydmljZSBpbmRleCBNVVNUIGJlIGRlY3JlbWVudGVkIDxiPmJ5IGEgdmFs dWUgb2YgMTwvYj4gYnkgU2VydmljZSBGdW5jdGlvbnMgb3IgYnkgU0ZDIFByb3h5IG5vZGVzIGFm dGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQgc2VydmljZXMg4oCm4oCdPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KPGJyPg0K QSBjb3VwbGUgb2Ygb2JzZXJ2YXRpb25zOjxicj4NCjxicj4NCi0gVGhlIHRlcm0gJnF1b3Q7U0ZD IFByb3h5IG5vZGUmcXVvdDsgaXMgbm90IGRlZmluZWQgaW4gZWl0aGVyIHRoZSBOU0ggZHJhZnQg b3IgaW4gUkZDIDc2NjUuJm5ic3A7IEkgdGhpbmsgdGhlIGludGVudGlvbiBoZXJlIGlzIHRvIHNh eSAmcXVvdDtTRkMgUHJveHkmcXVvdDsuPGJyPg0KPGJyPg0KLSBJcyB0aGUgaW50ZW50aW9uIHRo YXQgdGhlIFNJIHJlbWFpbiB1bmNoYW5nZWQgd2hpbGUgdGhlIFNGIGlzIG9wZXJhdGluZyBvbiB0 aGUgcGFja2V0LCBvciBpcyB0aGUgaW50ZW50aW9uIG9ubHkgdGhhdCB0aGUgU0kgYmUgZGVjcmVt ZW50ZWQgYmVmb3JlIHRoZSBwYWNrZXQgaXMgZGVsaXZlcmVkIGJ5IHRoZSBTRiBvciBTRkMgUHJv eHkgdG8gYW4gU0ZGPw0KPGJyPg0KPGJyPg0KSSdkIHN1Z2dlc3QgZWl0aGVyOjxicj4NCjxicj4N CiZxdW90O0FuIFNGIG9yIFNGQyBQcm94eSByZWNlaXZpbmcgYW4gTlNILWVuY2Fwc3VsYXRlZCBw YWNrZXQgTVVTVCBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEgYmVmb3JlIGRlbGl2ZXJpbmcgdGhlIHBh Y2tldCB0byB0aGUgbmV4dCBTRkYmcXVvdDs8YnI+DQo8YnI+DQpvcjxicj4NCjxicj4NCiZxdW90 O0FuIFNGIG9yIFNGQyBQcm94eSByZWNlaXZpbmcgYW4gTlNILWVuY2Fwc3VsYXRlZCBwYWNrZXQg TVVTVCBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEgYmVmb3JlIGRlbGl2ZXJpbmcgdGhlIHBhY2tldCB0 byB0aGUgbmV4dCBTRkYsIGJ1dCBub3QgdW50aWwgdGhlIFNGIGhhcyBmaW5pc2hlZCBhbGwgaXRz IG90aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBhY2tldCZxdW90Ozxicj4NCjxicj4NCmRlcGVuZGlu ZyB1cG9uIHdoaWNoIGlzIGludGVuZGVkLjxicj4NCjxicj4NCkkgdGhpbmsgYW4gaW1wbGljYXRp b24gb2YgdGhlc2UgcHJvY2VkdXJlcyBpcyB0aGF0IGFuIFNJIHZhbHVlIG9mIDEgaXMgbm90IHZh bGlkLiZuYnNwOyBJZiBhbiBTRiBnZXRzIGFuIE5TSCBwYWNrZXQgd2l0aCBhbiBTSSBvZiAxLCB0 aGUgU0Ygd2lsbCBkZWNyZW1lbnQgdGhlIFNJIChzZXR0aW5nIGl0IHRvIDApLCBzZW5kIHRoZSBw YWNrZXQgdG8gYW4gU0ZGLCBhbmQgdGhlIFNGRiB3aWxsIGRpc2NhcmQgaXQsIGJlY2F1c2UgMCBp cyBhbiBpbnZhbGlkIFNJDQogdmFsdWUuJm5ic3A7IElzIHRoYXQgdGhlIGludGVudGlvbj88YnI+ DQo8YnI+DQpUaGUgZHJhZnQgbWFrZXMgaXQgY2xlYXIgKHdlbGwsIHNvcnQgb2YpIHRoYXQgYW4g U0ZGIHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IHdpdGggYW4gU0kgb2YgMCwgYnV0IGRvZXMgbm90 IHNlZW0gdG8gc2F5IHRoYXQgYW4gU0Ygb3IgU0ZDIFByb3h5IHNob3VsZCBkaXNjYXJkIGEgcGFj a2V0IGl0IHJlY2VpdmVzIHdpdGggYW4gU0kgb2YgMC4mbmJzcDsgSXQgd291bGQgcHJvYmFibHkg YmUgYSBnb29kIGlkZWEgdG8gc2F5IHRoYXQuPGJyPg0KPGJyPg0KU29tZSB0ZXh0IGluIHRoZSBk cmFmdCAoZS5nLiwgc2VjdGlvbiA3LjEpIHN0YXRlcyB0aGFuIGFuIFNGRiBzaG91bGQgZGlzY2Fy ZCBhIHBhY2tldCB3aXRoIGFuIFNJIG9mIHplcm8sIGJ1dCBvdGhlciB0ZXh0IGluIHRoZSBkcmFm dCAoZS5nLiwgc2VjdGlvbiAzLjMpIG9ubHkgc2F5cyB0aGF0IGFuIFNGRiBzaG91bGQgbG9nIGFu IGVycm9yIGlmIGl0IHNlZXMgYW4gU0kgb2YgemVyby4mbmJzcDsgSXQncyBwcm9iYWJseSBiZXN0 IHRvIGNoYW5nZSB0aGUgdGV4dA0KIGluIDMuMy4gdG8gc2F5ICZxdW90O1NIT1VMRCBnZW5lcmF0 ZSBhbiBlcnJvci9sb2cgbWVzc2FnZSBhbmQgTVVTVCBkaXNjYXJkIHRoZSBwYWNrZXQmcXVvdDss IG9yIHNvbWV0aGluZyBzaW1pbGFyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_AT5PR84MB0305CA9317AB0AC7AADE3746F6450AT5PR84MB0305NAMP_-- From nobody Thu Feb 9 11:53:49 2017 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 B54F61294F4 for ; Thu, 9 Feb 2017 11:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 oNJIWARBQn9q for ; Thu, 9 Feb 2017 11:53:46 -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 6ADDF129450 for ; Thu, 9 Feb 2017 11:53:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3AE277E0A03; Thu, 9 Feb 2017 11:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486670026; bh=hKxz4IHlks/DxD7GL9S3idobLb4QyIAWJ2fL/C0xRz4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Xu79IHYs8S2gKttSWKN2XrpIApBBxVDxdw5wv2KXrsT603ew6lvh3mACX1DqE/JhH kBnEExaxbd2r8nbDyul1YcI8h+vAhDlHXYY4d4GOY73I+BfiVQcbqhNYonFewnn1Cu Z8W/z52I18WRQGzAGCvqG5zZfR5Tf7h7u/XMnZJo= 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 204277E0021; Thu, 9 Feb 2017 11:53:45 -0800 (PST) To: Ron Parker , Dave Dolson References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> From: "Joel M. Halpern" Message-ID: <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> Date: Thu, 9 Feb 2017 14:53:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Fabricio Ferraz , James N Guichard , "sfc@ietf.org" , Eric C Rosen , "Dolganow, Andrew \(Nokia - SG\)" Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:53:49 -0000 From my perspective as an individual participant in this work, declaring that 0 must be dropped is a matter of robustness. if we allow 0 to be processed for exit at an SFF, then a mis-configured SFF could easily continue processing such a packet. Now, it is true that TTL will eventually drop it, but that is an expensive fallback. More importantly, presumably the next entitiy down the incorrect path would drop it for a 255 SI. But at that point we are getting the error in the wrong place, making it harder to diagnose and repair. Yours, Joel On 2/9/17 12:42 PM, Ron Parker wrote: > agree. > > On Feb 9, 2017, at 12:28 PM, Dave Dolson > wrote: > >> I’m not clear on why this is broken, or why this restriction is made. >> >> I agree it should not be sent to an SF, but an SFF could map an SI of >> zero into a path termination. >> >> I.e., the last SF in a path could decrement SI from 1 to 0, and the >> SFF could then terminate the chain. >> >> >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N Guichard >> *Sent:* Thursday, February 09, 2017 12:02 PM >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; >> Eric C Rosen; sfc@ietf.org >> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> >> >> Not exactly. Section 3.3 specifies “The value zero for SI is not valid >> and indicates a broken SFC or malfunctioning SF” .. In other words an >> SF should never receive an NSH packet with SI = 0. Note that if this >> happened then either a) a classifier set the SI incorrectly, or b) a >> re-classifier set the SI incorrectly, or c) an upstream SF set the SI >> incorrectly; all of these cases should be caught by the SFF whose job >> it is to discard NSH packets with SI = 0. >> >> >> >> Jim >> >> >> >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >> *Sent:* Thursday, February 09, 2017 11:49 AM >> *To:* James N Guichard > >; Dolganow, Andrew (Nokia - SG) >> >; Dave >> Dolson >; Eric C >> Rosen >; sfc@ietf.org >> >> *Subject:* RE: [sfc] NSH Service Index Decrement >> >> >> >> Hi Jim, >> >> Thanks. >> >> >> >> One more question about the SI. >> >> >> >> Section 3 states that: >> >> >> >> Service Index (SI): provides location within the SFP. The initial >> classifier MUST set the appropriate SI value for a given >> classification result. The initial SI value SHOULD default to 255. >> However, the classifier MUST allow configuration of other SI values. >> >> Service Index MUST be decremented by Service Functions or by SFC Proxy >> nodes after performing required services and the new decremented SI >> value MUST be used in the egress NSH packet. >> >> The initial Classifier MUST send the packet to the first SFF in the >> identified SFP for forwarding along an SFP. >> >> If re-classification occurs, and that re-classification results in a >> new SPI, the (re)classifier is, in effect, the initial classifier for >> the resultant SPI. >> >> >> >> Thus: >> >> a) Initial SI value should be 255 but other values can be >> configured by the classifier. >> >> b) SF decrements the SI value on the egress NSH packet >> >> c) If re-classification occurs with new SPI, the re-classifier >> is the initial classifier, so by a), SI should be again 255 or other >> value >> >> >> >> So any SI value can be receive by an SF, even 1 or 0 because: >> >> èIf SI=1 and there is no re-classification, the egress NSH will have SI=0 >> >> èIf SI=0 and there is re-classification with new SPI, the egress NSH >> will have a new SPI and a SI= 255 or other value, as stated in a). >> >> èIf SI=0 and there is no re-classification the SF should discard the >> packet >> >> >> >> Also an SFF should forward/handle packets with NSH with SI=1 or SI=0. >> >> >> >> Do you agree? >> >> >> >> >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N Guichard >> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; >> Eric C Rosen; sfc@ietf.org >> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> >> >> Hi Fabricio, >> >> >> >> Welcome! >> >> >> >> Yes, removal of NSH is the responsibility of an SFF or a re-classifier >> (section 4, bullet point 1 lays this out). With the current >> architecture the SF does not care what SI value it gets, it just needs >> to worry about decrementing it, and leave it up to the SFF to evaluate >> the SI value and associated action. >> >> >> >> Jim >> >> >> >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >> *Sent:* Thursday, February 09, 2017 7:13 AM >> *To:* Dolganow, Andrew (Nokia - SG) > >; Dave Dolson > >; Eric C Rosen > >; James N Guichard >> >; >> sfc@ietf.org >> *Subject:* RE: [sfc] NSH Service Index Decrement >> >> >> >> Hi all, >> >> I’m new here (just read the draft last week) but according to chapter >> 4 (check figure 8 for example), an SF is not allowed to insert or >> remove NSH. The removal of NSH is reponsability of the SSF, right? >> >> >> >> Figure 8 maps each of the four actions above to the components in the >> >> SFC architecture that can perform it. >> >> >> >> +---------------+------------------+-------+----------------+---------+ >> >> | | Insert |Select | Update |Service | >> >> | | or remove NSH |Service| NSH |policy | >> >> | | |Function| |selection| >> >> | Component +--------+--------+Path +----------------+ | >> >> | | | | | Dec. |Update | | >> >> | | Insert | Remove | |Service |Context| | >> >> | | | | | Index |Header | | >> >> +----------------+--------+--------+-------+--------+-------+---------+ >> >> | | + | + | | | + | | >> >> |Classifier | | | | | | | >> >> +--------------- +--------+--------+-------+--------+-------+---------+ >> >> |Service Function| | + | + | | | | >> >> |Forwarder(SFF) | | | | | | | >> >> +--------------- +--------+--------+-------+--------+-------+---------+ >> >> |Service | | | | + | + | + | >> >> |Function (SF) | | | | | | | >> >> +--------------- +--------+--------+-------+--------+-------+---------+ >> >> |SFC Proxy | + | + | | + | | | >> >> +----------------+--------+--------+-------+--------+-------+---------+ >> >> >> >> Figure 8: NSH Action and Role Mapping >> >> >> >> >> >> An SF could receive an NSH packet with an SI of 1, and reclassify it >> to a different SPI and SI, right? So when a SF receives a NSH packet >> with SI = 1 that does not necessarily means a non valid packet. >> >> And that can even work for SI=0, since you decrement the SI in the egress. >> >> >> >> Fabricio >> >> >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, >> Andrew (Nokia - SG) >> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 >> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org >> >> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> >> >> I assumed that if we get value 1 we process then forward without NSH >> header (i.e.) this is the last SF processing. >> >> >> >> So with that assumption, a more explicit text would be: >> >> >> >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement >> the SI by 1 after performing all required local processing and before >> forwarding the packet to the next SFF. If the resulting SI is 0, the >> SF MUST remove the NSH header before forwarding the packet. >> >> >> >> Andrew >> >> *From: *sfc > on >> behalf of Dave Dolson > >> *Date: *Thursday, February 9, 2017 at 2:04 AM >> *To: *Eric Rosen >, >> James N Guichard > >, "sfc@ietf.org >> " > >> *Subject: *Re: [sfc] NSH Service Index Decrement >> >> >> >> Eric, >> >> I was never quite happy with the outcome that neither 0 nor 1 is a >> valid SI. >> >> (Because if received with value of 1, it is decremented and discarded.) >> >> >> >> It seems to waste an index value. >> >> >> >> I guess I’m interested to know if that is important to other >> implementers, or if that was even the intention? >> >> >> >> >> >> -Dave >> >> >> >> >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C Rosen >> *Sent:* Wednesday, February 08, 2017 11:53 AM >> *To:* James N Guichard; sfc@ietf.org >> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> >> >> On 2/7/2017 2:24 PM, James N Guichard wrote: >> >> A request was made to be more specific and update the text as follows: >> >> >> >> “Service index MUST be decremented *by a value of 1* by Service >> Functions or by SFC Proxy nodes after performing required services …” >> >> >> A couple of observations: >> >> - The term "SFC Proxy node" is not defined in either the NSH draft or >> in RFC 7665. I think the intention here is to say "SFC Proxy". >> >> - Is the intention that the SI remain unchanged while the SF is >> operating on the packet, or is the intention only that the SI be >> decremented before the packet is delivered by the SF or SFC Proxy to >> an SFF? >> >> I'd suggest either: >> >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >> decrement the SI by 1 before delivering the packet to the next SFF" >> >> or >> >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >> decrement the SI by 1 before delivering the packet to the next SFF, >> but not until the SF has finished all its other processing of the packet" >> >> depending upon which is intended. >> >> I think an implication of these procedures is that an SI value of 1 is >> not valid. If an SF gets an NSH packet with an SI of 1, the SF will >> decrement the SI (setting it to 0), send the packet to an SFF, and the >> SFF will discard it, because 0 is an invalid SI value. Is that the >> intention? >> >> The draft makes it clear (well, sort of) that an SFF should discard a >> packet with an SI of 0, but does not seem to say that an SF or SFC >> Proxy should discard a packet it receives with an SI of 0. It would >> probably be a good idea to say that. >> >> Some text in the draft (e.g., section 7.1) states than an SFF should >> discard a packet with an SI of zero, but other text in the draft >> (e.g., section 3.3) only says that an SFF should log an error if it >> sees an SI of zero. It's probably best to change the text in 3.3. to >> say "SHOULD generate an error/log message and MUST discard the >> packet", or something similar. >> >> _______________________________________________ >> 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 Thu Feb 9 12:38:48 2017 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 7A65B12706D for ; Thu, 9 Feb 2017 12:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9YZ_FL3FqaL for ; Thu, 9 Feb 2017 12:38:43 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0139.outbound.protection.outlook.com [104.47.41.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679EF129452 for ; Thu, 9 Feb 2017 12:38:43 -0800 (PST) Received: from AT5PR84MB0305.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.27) by AT5PR84MB0308.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 9 Feb 2017 20:38:41 +0000 Received: from AT5PR84MB0305.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.27]) by AT5PR84MB0305.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.27]) with mapi id 15.01.0888.026; Thu, 9 Feb 2017 20:38:41 +0000 From: "Fedyk, Don" To: "Joel M. Halpern" , Ron Parker , Dave Dolson Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAAtMROAAAJ/QoAAEEWfAAAVt+wAAAjUqIAAAM/fAAAAelaAAADoKYAAAH9oAAAElLkAAABDLHA= Date: Thu, 9 Feb 2017 20:38:41 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> In-Reply-To: <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> 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=don.fedyk@hpe.com; x-originating-ip: [173.76.164.142] x-ms-office365-filtering-correlation-id: 0ab270b0-3709-40cb-c060-08d4512ba24a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AT5PR84MB0308; x-microsoft-exchange-diagnostics: 1; AT5PR84MB0308; 7:ZrajfzO8B2tHIz+9K0rjP7wqHEh2s9QAYcyxYIR1+1iQ+HMIE+pOF5G/E6KDSBMWf3NIwERzDnT2rFoGYbJ+xQpEzA9pcXj8MjRSTLEOqKGkiRvEOrVWYB9XvvkSmwiFC5dWY3vZkzJJcgadhBHLSvzQurbiHxX94gmVjC3gnwFbYKfYNdYEkVskNtkqHAlKM349Bh1j+qBjIIexdbBncDE/O1NVyZ29wb0TugcgTDIf+rrda6QdGezaNLbyxRhQ0WWQqAS855lcqKZBGEIRsyg4TmjlRvO3p9ySAyvAlzJprEo44Asy81yfX1HsDdQpS5kIxEbVG0bTpPGwnW3JPLClrzWJ7KZwINnVaEmKZH+G/kXp06hSwH1UtQEMppT4AwxqE6o3ztQpRT/QozvFq6rdSB/mQK/XB/papM/4B+l5CnBtbvmBmoiKsUKUASqvVFMryINt+T4BGpvN0WdNLH5qq6c7X8CW1Z2P38uFSH/qs7e672L1A+fPNcKCWxZT8Oxvh8lAEEuKnDeq8eGomw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(82608151540597)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:AT5PR84MB0308; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0308; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39860400002)(39850400002)(39840400002)(24454002)(13464003)(53754006)(199003)(377454003)(189002)(7736002)(6116002)(7696004)(2906002)(3280700002)(8676002)(92566002)(2900100001)(5660300001)(38730400002)(102836003)(4326007)(2950100002)(50986999)(3846002)(101416001)(54356999)(3660700001)(76176999)(53546003)(8936002)(97736004)(86362001)(53936002)(6246003)(31430400001)(189998001)(81166006)(81156014)(305945005)(68736007)(74316002)(106356001)(33656002)(229853002)(105586002)(55016002)(122556002)(66066001)(93886004)(6306002)(9686003)(6436002)(8666007)(6506006)(77096006)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0308; H:AT5PR84MB0305.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2017 20:38:41.1171 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0308 Archived-At: Cc: Eric C Rosen , "Dolganow, Andrew \(Nokia - SG\)" , "sfc@ietf.org" , James N Guichard , Fabricio Ferraz Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 20:38:46 -0000 Hi Joel I think the question is can an SF return an SI =3D 0 and then the SFF look = up an SID/SI=3D0 and do something useful? Certainly after SI =3D 0 now at an SFF, forwarding on the packet to another= SF with SI=3D 0 is not useful but is protected at the SF. (also there is n= o rolling over to 255 at an SF).=20 Somehow I think we got caught up on a corner case. I'd expect very few cha= ins ever to be hitting SI =3D 0 if they start at SI =3D 255. But the quest= ion remains is SI =3D 0 a legal return value?=20 Cheers Don=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, February 09, 2017 2:54 PM > To: Ron Parker ; Dave Dolson > > Cc: Fabricio Ferraz ; James N Guichard > ; sfc@ietf.org; Eric C Rosen > ; Dolganow, Andrew (Nokia - SG) > > Subject: Re: [sfc] NSH Service Index Decrement >=20 > From my perspective as an individual participant in this work, declaring= that 0 > must be dropped is a matter of robustness. >=20 > if we allow 0 to be processed for exit at an SFF, then a mis-configured S= FF could > easily continue processing such a packet. Now, it is true that TTL will > eventually drop it, but that is an expensive fallback. >=20 > More importantly, presumably the next entitiy down the incorrect path wou= ld > drop it for a 255 SI. But at that point we are getting the error in the = wrong > place, making it harder to diagnose and repair. >=20 > Yours, > Joel >=20 > On 2/9/17 12:42 PM, Ron Parker wrote: > > agree. > > > > On Feb 9, 2017, at 12:28 PM, Dave Dolson > > wrote: > > > >> I'm not clear on why this is broken, or why this restriction is made. > >> > >> I agree it should not be sent to an SF, but an SFF could map an SI of > >> zero into a path termination. > >> > >> I.e., the last SF in a path could decrement SI from 1 to 0, and the > >> SFF could then terminate the chain. > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N > >> Guichard > >> *Sent:* Thursday, February 09, 2017 12:02 PM > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; > >> Eric C Rosen; sfc@ietf.org > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Not exactly. Section 3.3 specifies "The value zero for SI is not > >> valid and indicates a broken SFC or malfunctioning SF" .. In other > >> words an SF should never receive an NSH packet with SI =3D 0. Note tha= t > >> if this happened then either a) a classifier set the SI incorrectly, > >> or b) a re-classifier set the SI incorrectly, or c) an upstream SF > >> set the SI incorrectly; all of these cases should be caught by the > >> SFF whose job it is to discard NSH packets with SI =3D 0. > >> > >> > >> > >> Jim > >> > >> > >> > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >> *Sent:* Thursday, February 09, 2017 11:49 AM > >> *To:* James N Guichard >> >; Dolganow, Andrew (Nokia - SG) > >> >; > Dave > >> Dolson >; Eric C > >> Rosen >; sfc@ietf.org > >> > >> *Subject:* RE: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Hi Jim, > >> > >> Thanks. > >> > >> > >> > >> One more question about the SI. > >> > >> > >> > >> Section 3 states that: > >> > >> > >> > >> Service Index (SI): provides location within the SFP. The initial > >> classifier MUST set the appropriate SI value for a given > >> classification result. The initial SI value SHOULD default to 255. > >> However, the classifier MUST allow configuration of other SI values. > >> > >> Service Index MUST be decremented by Service Functions or by SFC > >> Proxy nodes after performing required services and the new > >> decremented SI value MUST be used in the egress NSH packet. > >> > >> The initial Classifier MUST send the packet to the first SFF in the > >> identified SFP for forwarding along an SFP. > >> > >> If re-classification occurs, and that re-classification results in a > >> new SPI, the (re)classifier is, in effect, the initial classifier for > >> the resultant SPI. > >> > >> > >> > >> Thus: > >> > >> a) Initial SI value should be 255 but other values can be > >> configured by the classifier. > >> > >> b) SF decrements the SI value on the egress NSH packet > >> > >> c) If re-classification occurs with new SPI, the re-classifier > >> is the initial classifier, so by a), SI should be again 255 or other > >> value > >> > >> > >> > >> So any SI value can be receive by an SF, even 1 or 0 because: > >> > >> =E8If SI=3D1 and there is no re-classification, the egress NSH will ha= ve > >> SI=3D0 > >> > >> =E8If SI=3D0 and there is re-classification with new SPI, the egress N= SH > >> will have a new SPI and a SI=3D 255 or other value, as stated in a). > >> > >> =E8If SI=3D0 and there is no re-classification the SF should discard t= he > >> packet > >> > >> > >> > >> Also an SFF should forward/handle packets with NSH with SI=3D1 or SI= =3D0. > >> > >> > >> > >> Do you agree? > >> > >> > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N > >> Guichard > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; > >> Eric C Rosen; sfc@ietf.org > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Hi Fabricio, > >> > >> > >> > >> Welcome! > >> > >> > >> > >> Yes, removal of NSH is the responsibility of an SFF or a > >> re-classifier (section 4, bullet point 1 lays this out). With the > >> current architecture the SF does not care what SI value it gets, it > >> just needs to worry about decrementing it, and leave it up to the SFF > >> to evaluate the SI value and associated action. > >> > >> > >> > >> Jim > >> > >> > >> > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >> *Sent:* Thursday, February 09, 2017 7:13 AM > >> *To:* Dolganow, Andrew (Nokia - SG) >> >; Dave Dolson > >> >; Eric C Rosen > >> >; James N Guichard > >> >; > >> sfc@ietf.org > >> *Subject:* RE: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Hi all, > >> > >> I'm new here (just read the draft last week) but according to chapter > >> 4 (check figure 8 for example), an SF is not allowed to insert or > >> remove NSH. The removal of NSH is reponsability of the SSF, right? > >> > >> > >> > >> Figure 8 maps each of the four actions above to the components in > >> the > >> > >> SFC architecture that can perform it. > >> > >> > >> > >> +---------------+------------------+-------+----------------+---------= + > >> > >> | | Insert |Select | Update |Service = | > >> > >> | | or remove NSH |Service| NSH |policy = | > >> > >> | | |Function| |selection= | > >> > >> | Component +--------+--------+Path +----------------+ = | > >> > >> | | | | | Dec. |Update | = | > >> > >> | | Insert | Remove | |Service |Context| = | > >> > >> | | | | | Index |Header | = | > >> > >> +----------------+--------+--------+-------+--------+-------+---------= + > >> > >> | | + | + | | | + | = | > >> > >> |Classifier | | | | | | = | > >> > >> +--------------- > >> ++--------+--------+-------+--------+-------+---------+ > >> > >> |Service Function| | + | + | | | = | > >> > >> |Forwarder(SFF) | | | | | | = | > >> > >> +--------------- > >> ++--------+--------+-------+--------+-------+---------+ > >> > >> |Service | | | | + | + | + = | > >> > >> |Function (SF) | | | | | | = | > >> > >> +--------------- > >> ++--------+--------+-------+--------+-------+---------+ > >> > >> |SFC Proxy | + | + | | + | | = | > >> > >> +----------------+--------+--------+-------+--------+-------+---------= + > >> > >> > >> > >> Figure 8: NSH Action and Role Mapping > >> > >> > >> > >> > >> > >> An SF could receive an NSH packet with an SI of 1, and reclassify it > >> to a different SPI and SI, right? So when a SF receives a NSH packet > >> with SI =3D 1 that does not necessarily means a non valid packet. > >> > >> And that can even work for SI=3D0, since you decrement the SI in the e= gress. > >> > >> > >> > >> Fabricio > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, > >> Andrew (Nokia - SG) > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > >> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org > >> > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> I assumed that if we get value 1 we process then forward without NSH > >> header (i.e.) this is the last SF processing. > >> > >> > >> > >> So with that assumption, a more explicit text would be: > >> > >> > >> > >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >> decrement the SI by 1 after performing all required local processing > >> and before forwarding the packet to the next SFF. If the resulting SI > >> is 0, the SF MUST remove the NSH header before forwarding the packet. > >> > >> > >> > >> Andrew > >> > >> *From: *sfc > on > >> behalf of Dave Dolson >> > > >> *Date: *Thursday, February 9, 2017 at 2:04 AM > >> *To: *Eric Rosen >, > >> James N Guichard >> >, "sfc@ietf.org > >> " > > >> *Subject: *Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Eric, > >> > >> I was never quite happy with the outcome that neither 0 nor 1 is a > >> valid SI. > >> > >> (Because if received with value of 1, it is decremented and > >> discarded.) > >> > >> > >> > >> It seems to waste an index value. > >> > >> > >> > >> I guess I'm interested to know if that is important to other > >> implementers, or if that was even the intention? > >> > >> > >> > >> > >> > >> -Dave > >> > >> > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C Rosen > >> *Sent:* Wednesday, February 08, 2017 11:53 AM > >> *To:* James N Guichard; sfc@ietf.org > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> On 2/7/2017 2:24 PM, James N Guichard wrote: > >> > >> A request was made to be more specific and update the text as follows: > >> > >> > >> > >> "Service index MUST be decremented *by a value of 1* by Service > >> Functions or by SFC Proxy nodes after performing required services ." > >> > >> > >> A couple of observations: > >> > >> - The term "SFC Proxy node" is not defined in either the NSH draft or > >> in RFC 7665. I think the intention here is to say "SFC Proxy". > >> > >> - Is the intention that the SI remain unchanged while the SF is > >> operating on the packet, or is the intention only that the SI be > >> decremented before the packet is delivered by the SF or SFC Proxy to > >> an SFF? > >> > >> I'd suggest either: > >> > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >> decrement the SI by 1 before delivering the packet to the next SFF" > >> > >> or > >> > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >> decrement the SI by 1 before delivering the packet to the next SFF, > >> but not until the SF has finished all its other processing of the pack= et" > >> > >> depending upon which is intended. > >> > >> I think an implication of these procedures is that an SI value of 1 > >> is not valid. If an SF gets an NSH packet with an SI of 1, the SF > >> will decrement the SI (setting it to 0), send the packet to an SFF, > >> and the SFF will discard it, because 0 is an invalid SI value. Is > >> that the intention? > >> > >> The draft makes it clear (well, sort of) that an SFF should discard a > >> packet with an SI of 0, but does not seem to say that an SF or SFC > >> Proxy should discard a packet it receives with an SI of 0. It would > >> probably be a good idea to say that. > >> > >> Some text in the draft (e.g., section 7.1) states than an SFF should > >> discard a packet with an SI of zero, but other text in the draft > >> (e.g., section 3.3) only says that an SFF should log an error if it > >> sees an SI of zero. It's probably best to change the text in 3.3. to > >> say "SHOULD generate an error/log message and MUST discard the > >> packet", or something similar. > >> > >> _______________________________________________ > >> 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 > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 9 12:58:27 2017 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 E13E5129481 for ; Thu, 9 Feb 2017 12:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 JdQF-i-D6s_v for ; Thu, 9 Feb 2017 12:58:22 -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 4B65A126D74 for ; Thu, 9 Feb 2017 12:58:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 32F419402B0; Thu, 9 Feb 2017 12:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486673902; bh=POUn8Zu5/ckSQsgbDvpqOJQcXL4uBzofIjNyl4Zje/Q=; h=Date:Subject:From:To:Cc:From; b=E3Ru3Jv4w9OYSMMZvSFiAQY4JA4LePyxP5Qq1FbHJ75qcSuq1QQWZbAsAtRCL3LQt cfUCxXZCA8ie6sJ5BQ93D8NDKmtTbXeJlQGQG/LY/RL7kZIJ+UoZp0BOzyfWhuKNN6 +cwJRaifsr6cxuT7sG7h3822lrj8m4MACVrR8HJE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.136.114.201] (75.145.205-198-BusName-sterling.va.richmond.hfc.comcastbusiness.net [75.145.205.198]) (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 3B36B1C06D1; Thu, 9 Feb 2017 12:58:21 -0800 (PST) Date: Thu, 09 Feb 2017 15:58:19 -0500 Message-ID: <7x7vnqut9b6ij0oll99806f6.1486673899780@email.android.com> Importance: normal From: "jmh.direct" To: "Fedyk, Don" , "Joel M. Halpern" , Ron Parker , Dave Dolson MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_637570712146890" Archived-At: Cc: Eric C Rosen , "Dolganow, Andrew \(Nokia - SG\)" , "sfc@ietf.org" , James N Guichard , Fabricio Ferraz Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 20:58:26 -0000 ----_com.samsung.android.email_637570712146890 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TGVnYWw/IMKgU3VyZS4gwqBUaGUgU0YgaGFzIGRvbmUgaXQncyBqb2IgcmlnaHQuVGhlIFNGRiB3 aWxsIHRoZW4gZGlzY2FyZCB0aGUgcGFja2V0LiDCoFVubGVzcyB0aGVyZSBpcyBhIHJlY2xhc3Np ZmllZCBiZXR3ZWVuIHRoZSBTRiBhbmQgdGhlIFNGRi4KQWxsb3dpbmcgYW4gU0ZGIHRvIHNlcnZl IGFzIGVncmVzcyBmb3IgYSBwYWNrZXQgd2l0aCBTSSAwIHJlcXVpcmVzIG1vcmUgY29tcGxleCBj aGVja2luZyBhbmQgaXMgbGVzcyByb2J1c3QuIMKgU3VyZSwgaXQgY2FuIGJlIG1hZGUgdG8gd29y ay4gwqBJcyB0aGVyZSBhIHJlYWwgbmVlZCB0byBhbGxvdyBpdD8KWW91cnMsSm9lbAoKClNlbnQg dmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQmVCA0RyBMVEUgc21hcnRwaG9uZQot LS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogIkZlZHlrLCBEb24iIDxkb24u ZmVkeWtAaHBlLmNvbT4gRGF0ZTogMi85LzE3ICAxNTozOCAgKEdNVC0wNTowMCkgVG86ICJKb2Vs IE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiwgUm9uIFBhcmtlciA8Um9uX1Bhcmtl ckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4sIERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNv bT4gQ2M6IEZhYnJpY2lvIEZlcnJheiA8ZmFicmljaW8tZmVycmF6QHRlbGVjb20ucHQ+LCBKYW1l cyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20+LCBzZmNAaWV0Zi5vcmcs IEVyaWMgQyBSb3NlbiA8ZXJvc2VuQGp1bmlwZXIubmV0PiwgIkRvbGdhbm93LCBBbmRyZXcgKE5v a2lhIC0gU0cpIiA8YW5kcmV3LmRvbGdhbm93QG5va2lhLmNvbT4gU3ViamVjdDogUkU6IFtzZmNd IE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudCAKSGkgSm9lbAoKSSB0aGluayB0aGUgcXVlc3Rp b24gaXMgY2FuIGFuIFNGIHJldHVybiBhbiBTSSA9IDAgYW5kIHRoZW4gdGhlIFNGRiBsb29rIHVw IGFuIFNJRC9TST0wIGFuZCBkbyBzb21ldGhpbmcgdXNlZnVsPwpDZXJ0YWlubHkgYWZ0ZXIgU0kg PSAwIG5vdyBhdCBhbiBTRkYsIGZvcndhcmRpbmcgb24gdGhlIHBhY2tldCB0byBhbm90aGVyIFNG IHdpdGggU0k9IDAgaXMgbm90IHVzZWZ1bCBidXQgaXMgcHJvdGVjdGVkIGF0IHRoZSBTRi4gKGFs c28gdGhlcmUgaXMgbm8gcm9sbGluZyBvdmVyIHRvIDI1NSBhdCBhbiBTRikuIApTb21laG93IEkg dGhpbmsgd2UgZ290IGNhdWdodCB1cCBvbiBhIGNvcm5lciBjYXNlLsKgIEknZCBleHBlY3QgdmVy eSBmZXcgY2hhaW5zIGV2ZXIgdG8gYmUgaGl0dGluZyBTSSA9IDAgaWYgdGhleSBzdGFydCBhdCBT SSA9IDI1NS7CoCBCdXQgdGhlIHF1ZXN0aW9uIHJlbWFpbnMgaXMgU0kgPSAwIGEgbGVnYWwgcmV0 dXJuIHZhbHVlPyAKCkNoZWVycwpEb24gCgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4g RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2Vs IE0uIEhhbHBlcm4KPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDksIDIwMTcgMjo1NCBQTQo+ IFRvOiBSb24gUGFya2VyIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPjsgRGF2ZSBE b2xzb24KPiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+Cj4gQ2M6IEZhYnJpY2lvIEZlcnJheiA8ZmFi cmljaW8tZmVycmF6QHRlbGVjb20ucHQ+OyBKYW1lcyBOIEd1aWNoYXJkCj4gPGphbWVzLm4uZ3Vp Y2hhcmRAaHVhd2VpLmNvbT47IHNmY0BpZXRmLm9yZzsgRXJpYyBDIFJvc2VuCj4gPGVyb3NlbkBq dW5pcGVyLm5ldD47IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpCj4gPGFuZHJldy5kb2xn YW5vd0Bub2tpYS5jb20+Cj4gU3ViamVjdDogUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERl Y3JlbWVudAo+IAo+wqAgRnJvbSBteSBwZXJzcGVjdGl2ZSBhcyBhbiBpbmRpdmlkdWFsIHBhcnRp Y2lwYW50IGluIHRoaXMgd29yaywgZGVjbGFyaW5nIHRoYXQgMAo+IG11c3QgYmUgZHJvcHBlZCBp cyBhIG1hdHRlciBvZiByb2J1c3RuZXNzLgo+IAo+IGlmIHdlIGFsbG93IDAgdG8gYmUgcHJvY2Vz c2VkIGZvciBleGl0IGF0IGFuIFNGRiwgdGhlbiBhIG1pcy1jb25maWd1cmVkIFNGRiBjb3VsZAo+ IGVhc2lseSBjb250aW51ZSBwcm9jZXNzaW5nIHN1Y2ggYSBwYWNrZXQuwqAgTm93LCBpdCBpcyB0 cnVlIHRoYXQgVFRMIHdpbGwKPiBldmVudHVhbGx5IGRyb3AgaXQsIGJ1dCB0aGF0IGlzIGFuIGV4 cGVuc2l2ZSBmYWxsYmFjay4KPiAKPiBNb3JlIGltcG9ydGFudGx5LCBwcmVzdW1hYmx5IHRoZSBu ZXh0IGVudGl0aXkgZG93biB0aGUgaW5jb3JyZWN0IHBhdGggd291bGQKPiBkcm9wIGl0IGZvciBh IDI1NSBTSS7CoCBCdXQgYXQgdGhhdCBwb2ludCB3ZSBhcmUgZ2V0dGluZyB0aGUgZXJyb3IgaW4g dGhlIHdyb25nCj4gcGxhY2UsIG1ha2luZyBpdCBoYXJkZXIgdG8gZGlhZ25vc2UgYW5kIHJlcGFp ci4KPiAKPiBZb3VycywKPiBKb2VsCj4gCj4gT24gMi85LzE3IDEyOjQyIFBNLCBSb24gUGFya2Vy IHdyb3RlOgo+ID4gYWdyZWUuCj4gPgo+ID4gT24gRmViIDksIDIwMTcsIGF0IDEyOjI4IFBNLCBE YXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20KPiA+IDxtYWlsdG86ZGRvbHNvbkBzYW5k dmluZS5jb20+PiB3cm90ZToKPiA+Cj4gPj4gSSdtIG5vdCBjbGVhciBvbiB3aHkgdGhpcyBpcyBi cm9rZW4sIG9yIHdoeSB0aGlzIHJlc3RyaWN0aW9uIGlzIG1hZGUuCj4gPj4KPiA+PiBJIGFncmVl IGl0IHNob3VsZCBub3QgYmUgc2VudCB0byBhbiBTRiwgYnV0IGFuIFNGRiBjb3VsZCBtYXAgYW4g U0kgb2YKPiA+PiB6ZXJvIGludG8gYSBwYXRoIHRlcm1pbmF0aW9uLgo+ID4+Cj4gPj4gSS5lLiwg dGhlIGxhc3QgU0YgaW4gYSBwYXRoIGNvdWxkIGRlY3JlbWVudCBTSSBmcm9tIDEgdG8gMCwgYW5k IHRoZQo+ID4+IFNGRiBjb3VsZCB0aGVuIHRlcm1pbmF0ZSB0aGUgY2hhaW4uCj4gPj4KPiA+Pgo+ ID4+Cj4gPj4KPiA+Pgo+ID4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gKk9uIEJlaGFsZiBPZiAqSmFtZXMgTgo+ID4+IEd1aWNoYXJkCj4gPj4gKlNlbnQ6KiBUaHVy c2RheSwgRmVicnVhcnkgMDksIDIwMTcgMTI6MDIgUE0KPiA+PiAqVG86KiBGYWJyaWNpbyBGZXJy YXo7IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpOyBEYXZlIERvbHNvbjsKPiA+PiBFcmlj IEMgUm9zZW47IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4KPiA+PiAqU3ViamVj dDoqIFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQKPiA+Pgo+ID4+Cj4gPj4K PiA+PiBOb3QgZXhhY3RseS4gU2VjdGlvbiAzLjMgc3BlY2lmaWVzICJUaGUgdmFsdWUgemVybyBm b3IgU0kgaXMgbm90Cj4gPj4gdmFsaWQgYW5kIGluZGljYXRlcyBhIGJyb2tlbiBTRkMgb3IgbWFs ZnVuY3Rpb25pbmcgU0YiIC4uIEluIG90aGVyCj4gPj4gd29yZHMgYW4gU0Ygc2hvdWxkIG5ldmVy IHJlY2VpdmUgYW4gTlNIIHBhY2tldCB3aXRoIFNJID0gMC4gTm90ZSB0aGF0Cj4gPj4gaWYgdGhp cyBoYXBwZW5lZCB0aGVuIGVpdGhlciBhKSBhIGNsYXNzaWZpZXIgc2V0IHRoZSBTSSBpbmNvcnJl Y3RseSwKPiA+PiBvciBiKSBhIHJlLWNsYXNzaWZpZXIgc2V0IHRoZSBTSSBpbmNvcnJlY3RseSwg b3IgYykgYW4gdXBzdHJlYW0gU0YKPiA+PiBzZXQgdGhlIFNJIGluY29ycmVjdGx5OyBhbGwgb2Yg dGhlc2UgY2FzZXMgc2hvdWxkIGJlIGNhdWdodCBieSB0aGUKPiA+PiBTRkYgd2hvc2Ugam9iIGl0 IGlzIHRvIGRpc2NhcmQgTlNIIHBhY2tldHMgd2l0aCBTSSA9IDAuCj4gPj4KPiA+Pgo+ID4+Cj4g Pj4gSmltCj4gPj4KPiA+Pgo+ID4+Cj4gPj4gKkZyb206KkZhYnJpY2lvIEZlcnJheiBbbWFpbHRv OmZhYnJpY2lvLWZlcnJhekB0ZWxlY29tLnB0XQo+ID4+ICpTZW50OiogVGh1cnNkYXksIEZlYnJ1 YXJ5IDA5LCAyMDE3IDExOjQ5IEFNCj4gPj4gKlRvOiogSmFtZXMgTiBHdWljaGFyZCA8amFtZXMu bi5ndWljaGFyZEBodWF3ZWkuY29tCj4gPj4gPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGh1YXdl aS5jb20+PjsgRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRykKPiA+PiA8YW5kcmV3LmRvbGdh bm93QG5va2lhLmNvbSA8bWFpbHRvOmFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+PjsKPiBEYXZl Cj4gPj4gRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbSA8bWFpbHRvOmRkb2xzb25Ac2FuZHZp bmUuY29tPj47IEVyaWMgQwo+ID4+IFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQgPG1haWx0bzpl cm9zZW5AanVuaXBlci5uZXQ+Pjsgc2ZjQGlldGYub3JnCj4gPj4gPG1haWx0bzpzZmNAaWV0Zi5v cmc+Cj4gPj4gKlN1YmplY3Q6KiBSRTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50 Cj4gPj4KPiA+Pgo+ID4+Cj4gPj4gSGkgSmltLAo+ID4+Cj4gPj4gVGhhbmtzLgo+ID4+Cj4gPj4K PiA+Pgo+ID4+IE9uZSBtb3JlIHF1ZXN0aW9uIGFib3V0IHRoZSBTSS4KPiA+Pgo+ID4+Cj4gPj4K PiA+PiBTZWN0aW9uIDMgc3RhdGVzIHRoYXQ6Cj4gPj4KPiA+Pgo+ID4+Cj4gPj4gU2VydmljZSBJ bmRleCAoU0kpOiBwcm92aWRlcyBsb2NhdGlvbiB3aXRoaW4gdGhlIFNGUC4gVGhlIGluaXRpYWwK PiA+PiBjbGFzc2lmaWVyIE1VU1Qgc2V0IHRoZSBhcHByb3ByaWF0ZSBTSSB2YWx1ZSBmb3IgYSBn aXZlbgo+ID4+IGNsYXNzaWZpY2F0aW9uIHJlc3VsdC4gVGhlIGluaXRpYWwgU0kgdmFsdWUgU0hP VUxEIGRlZmF1bHQgdG8gMjU1Lgo+ID4+IEhvd2V2ZXIsIHRoZSBjbGFzc2lmaWVyIE1VU1QgYWxs b3cgY29uZmlndXJhdGlvbiBvZiBvdGhlciBTSSB2YWx1ZXMuCj4gPj4KPiA+PiBTZXJ2aWNlIElu ZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgYnkgU2VydmljZSBGdW5jdGlvbnMgb3IgYnkgU0ZDCj4g Pj4gUHJveHkgbm9kZXMgYWZ0ZXIgcGVyZm9ybWluZyByZXF1aXJlZCBzZXJ2aWNlcyBhbmQgdGhl IG5ldwo+ID4+IGRlY3JlbWVudGVkIFNJIHZhbHVlIE1VU1QgYmUgdXNlZCBpbiB0aGUgZWdyZXNz IE5TSCBwYWNrZXQuCj4gPj4KPiA+PiBUaGUgaW5pdGlhbCBDbGFzc2lmaWVyIE1VU1Qgc2VuZCB0 aGUgcGFja2V0IHRvIHRoZSBmaXJzdCBTRkYgaW4gdGhlCj4gPj4gaWRlbnRpZmllZCBTRlAgZm9y IGZvcndhcmRpbmcgYWxvbmcgYW4gU0ZQLgo+ID4+Cj4gPj4gSWYgcmUtY2xhc3NpZmljYXRpb24g b2NjdXJzLCBhbmQgdGhhdCByZS1jbGFzc2lmaWNhdGlvbiByZXN1bHRzIGluIGEKPiA+PiBuZXcg U1BJLCB0aGUgKHJlKWNsYXNzaWZpZXIgaXMsIGluIGVmZmVjdCwgdGhlIGluaXRpYWwgY2xhc3Np ZmllciBmb3IKPiA+PiB0aGUgcmVzdWx0YW50IFNQSS4KPiA+Pgo+ID4+Cj4gPj4KPiA+PiBUaHVz Ogo+ID4+Cj4gPj4gYSnCoMKgwqDCoMKgIEluaXRpYWwgU0kgdmFsdWUgc2hvdWxkIGJlIDI1NSBi dXQgb3RoZXIgdmFsdWVzIGNhbiBiZQo+ID4+IGNvbmZpZ3VyZWQgYnkgdGhlIGNsYXNzaWZpZXIu Cj4gPj4KPiA+PiBiKcKgwqDCoMKgwqAgU0YgZGVjcmVtZW50cyB0aGUgU0kgdmFsdWUgb24gdGhl IGVncmVzcyBOU0ggcGFja2V0Cj4gPj4KPiA+PiBjKcKgwqDCoMKgwqDCoCBJZiByZS1jbGFzc2lm aWNhdGlvbiBvY2N1cnMgd2l0aCBuZXcgU1BJLCB0aGUgcmUtY2xhc3NpZmllcgo+ID4+IGlzIHRo ZSBpbml0aWFsIGNsYXNzaWZpZXIsIHNvIGJ5wqAgYSksIFNJIHNob3VsZCBiZSBhZ2FpbiAyNTUg b3Igb3RoZXIKPiA+PiB2YWx1ZQo+ID4+Cj4gPj4KPiA+Pgo+ID4+IFNvIGFueSBTSSB2YWx1ZSBj YW4gYmUgcmVjZWl2ZSBieSBhbiBTRiwgZXZlbiAxIG9yIDAgYmVjYXVzZToKPiA+Pgo+ID4+IMOo SWYgU0k9MSBhbmQgdGhlcmUgaXMgbm8gcmUtY2xhc3NpZmljYXRpb24sIHRoZSBlZ3Jlc3MgTlNI IHdpbGwgaGF2ZQo+ID4+IFNJPTAKPiA+Pgo+ID4+IMOoSWYgU0k9MCBhbmQgdGhlcmUgaXMgcmUt Y2xhc3NpZmljYXRpb24gd2l0aCBuZXcgU1BJLCB0aGUgZWdyZXNzIE5TSAo+ID4+IHdpbGwgaGF2 ZSBhIG5ldyBTUEkgYW5kIGEgU0k9IDI1NSBvciBvdGhlciB2YWx1ZSwgYXMgc3RhdGVkIGluIGEp Lgo+ID4+Cj4gPj4gw6hJZiBTST0wIGFuZCB0aGVyZSBpcyBubyByZS1jbGFzc2lmaWNhdGlvbiB0 aGUgU0Ygc2hvdWxkIGRpc2NhcmQgdGhlCj4gPj4gcGFja2V0Cj4gPj4KPiA+Pgo+ID4+Cj4gPj4g QWxzbyBhbiBTRkYgc2hvdWxkIGZvcndhcmQvaGFuZGxlIHBhY2tldHMgd2l0aCBOU0ggd2l0aCBT ST0xIG9yIFNJPTAuCj4gPj4KPiA+Pgo+ID4+Cj4gPj4gRG8geW91IGFncmVlPwo+ID4+Cj4gPj4K PiA+Pgo+ID4+Cj4gPj4KPiA+Pgo+ID4+Cj4gPj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpKYW1lcyBOCj4gPj4gR3VpY2hhcmQKPiA+PiAq U2VudDoqIHF1aW50YS1mZWlyYSwgOSBkZSBmZXZlcmVpcm8gZGUgMjAxNyAxNjoyNQo+ID4+ICpU bzoqIEZhYnJpY2lvIEZlcnJhejsgRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRyk7IERhdmUg RG9sc29uOwo+ID4+IEVyaWMgQyBSb3Nlbjsgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYu b3JnPgo+ID4+ICpTdWJqZWN0OiogUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVu dAo+ID4+Cj4gPj4KPiA+Pgo+ID4+IEhpIEZhYnJpY2lvLAo+ID4+Cj4gPj4KPiA+Pgo+ID4+IFdl bGNvbWUhCj4gPj4KPiA+Pgo+ID4+Cj4gPj4gWWVzLCByZW1vdmFsIG9mIE5TSCBpcyB0aGUgcmVz cG9uc2liaWxpdHkgb2YgYW4gU0ZGIG9yIGEKPiA+PiByZS1jbGFzc2lmaWVyIChzZWN0aW9uIDQs IGJ1bGxldCBwb2ludCAxIGxheXMgdGhpcyBvdXQpLiBXaXRoIHRoZQo+ID4+IGN1cnJlbnQgYXJj aGl0ZWN0dXJlIHRoZSBTRiBkb2VzIG5vdCBjYXJlIHdoYXQgU0kgdmFsdWUgaXQgZ2V0cywgaXQK PiA+PiBqdXN0IG5lZWRzIHRvIHdvcnJ5IGFib3V0IGRlY3JlbWVudGluZyBpdCwgYW5kIGxlYXZl IGl0IHVwIHRvIHRoZSBTRkYKPiA+PiB0byBldmFsdWF0ZSB0aGUgU0kgdmFsdWUgYW5kIGFzc29j aWF0ZWQgYWN0aW9uLgo+ID4+Cj4gPj4KPiA+Pgo+ID4+IEppbQo+ID4+Cj4gPj4KPiA+Pgo+ID4+ ICpGcm9tOipGYWJyaWNpbyBGZXJyYXogW21haWx0bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5w dF0KPiA+PiAqU2VudDoqIFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyA3OjEzIEFNCj4gPj4g KlRvOiogRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRykgPGFuZHJldy5kb2xnYW5vd0Bub2tp YS5jb20KPiA+PiA8bWFpbHRvOmFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+PjsgRGF2ZSBEb2xz b24KPiA+PiA8ZGRvbHNvbkBzYW5kdmluZS5jb20gPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNv bT4+OyBFcmljIEMgUm9zZW4KPiA+PiA8ZXJvc2VuQGp1bmlwZXIubmV0IDxtYWlsdG86ZXJvc2Vu QGp1bmlwZXIubmV0Pj47IEphbWVzIE4gR3VpY2hhcmQKPiA+PiA8amFtZXMubi5ndWljaGFyZEBo dWF3ZWkuY29tIDxtYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPj47Cj4gPj4gc2Zj QGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPgo+ID4+ICpTdWJqZWN0OiogUkU6IFtzZmNd IE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudAo+ID4+Cj4gPj4KPiA+Pgo+ID4+IEhpIGFsbCwK PiA+Pgo+ID4+IEknbSBuZXcgaGVyZSAoanVzdCByZWFkIHRoZSBkcmFmdCBsYXN0IHdlZWspIGJ1 dCBhY2NvcmRpbmcgdG8gY2hhcHRlcgo+ID4+IDQgKGNoZWNrIGZpZ3VyZSA4IGZvciBleGFtcGxl KSwgYW4gU0YgaXMgbm90IGFsbG93ZWQgdG8gaW5zZXJ0IG9yCj4gPj4gcmVtb3ZlIE5TSC4gVGhl IHJlbW92YWwgb2YgTlNIIGlzIHJlcG9uc2FiaWxpdHkgb2YgdGhlIFNTRiwgcmlnaHQ/Cj4gPj4K PiA+Pgo+ID4+Cj4gPj7CoMKgIEZpZ3VyZSA4IG1hcHMgZWFjaCBvZiB0aGUgZm91ciBhY3Rpb25z IGFib3ZlIHRvIHRoZSBjb21wb25lbnRzIGluCj4gPj4gdGhlCj4gPj4KPiA+PsKgwqDCoCBTRkMg YXJjaGl0ZWN0dXJlIHRoYXQgY2FuIHBlcmZvcm0gaXQuCj4gPj4KPiA+Pgo+ID4+Cj4gPj4gKy0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLSsKPiA+Pgo+ID4+IHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKg IEluc2VydMKgwqDCoMKgwqDCoMKgwqAgfFNlbGVjdCB8wqDCoCBVcGRhdGXCoMKgwqDCoMKgwqAg fFNlcnZpY2XCoCB8Cj4gPj4KPiA+PiB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzC oCBvciByZW1vdmUgTlNIwqAgfFNlcnZpY2V8wqDCoMKgIE5TSMKgwqDCoMKgwqDCoMKgwqAgfHBv bGljecKgwqAgfAo+ID4+Cj4gPj4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfEZ1bmN0aW9ufMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfHNlbGVjdGlvbnwKPiA+Pgo+ID4+IHwgQ29tcG9uZW50wqDCoMKgwqDCoCAr LS0tLS0tLS0rLS0tLS0tLS0rUGF0aMKgwqAgKy0tLS0tLS0tLS0tLS0tLS0rwqDCoMKgwqDCoMKg wqDCoCB8Cj4gPj4KPiA+PiB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDC oMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoCB8IERlYy7CoMKgIHxVcGRhdGUg fMKgwqDCoMKgwqDCoMKgwqAgfAo+ID4+Cj4gPj4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCB8IEluc2VydCB8IFJlbW92ZSB8wqDCoMKgwqDCoMKgIHxTZXJ2aWNlIHxDb250ZXh0fMKg wqDCoMKgwqDCoMKgwqAgfAo+ID4+Cj4gPj4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqAgfCBJbmRleMKg IHxIZWFkZXIgfMKgwqDCoMKgwqDCoMKgwqAgfAo+ID4+Cj4gPj4gKy0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsKPiA+ Pgo+ID4+IHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqAgK8KgwqDCoCB8wqDC oCArwqDCoMKgIHzCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgICvCoMKgIHzCoMKg wqDCoMKgwqDCoMKgIHwKPiA+Pgo+ID4+IHxDbGFzc2lmaWVywqDCoMKgwqDCoCB8wqDCoMKgwqDC oMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKg wqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqAgfAo+ID4+Cj4gPj4gKy0tLS0tLS0tLS0tLS0tLQo+ ID4+ICsrLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0t LSsKPiA+Pgo+ID4+IHxTZXJ2aWNlIEZ1bmN0aW9ufMKgwqDCoMKgwqDCoMKgIHzCoMKgICvCoMKg wqAgfMKgICvCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDC oMKgwqAgfAo+ID4+Cj4gPj4gfEZvcndhcmRlcihTRkYpwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKg wqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgIHzC oMKgwqDCoMKgwqDCoMKgIHwKPiA+Pgo+ID4+ICstLS0tLS0tLS0tLS0tLS0KPiA+PiArKy0tLS0t LS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0rCj4gPj4KPiA+ PiB8U2VydmljZcKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDC oCB8wqDCoMKgwqDCoMKgIHzCoMKgICvCoMKgwqAgfMKgwqAgK8KgwqAgfMKgwqAgK8KgwqDCoMKg IHwKPiA+Pgo+ID4+IHxGdW5jdGlvbsKgIChTRinCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKg wqDCoMKgIHzCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqAgfMKgwqDC oMKgwqDCoMKgwqAgfAo+ID4+Cj4gPj4gKy0tLS0tLS0tLS0tLS0tLQo+ID4+ICsrLS0tLS0tLS0r LS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsKPiA+Pgo+ID4+IHxT RkMgUHJveHnCoMKgwqDCoMKgwqAgfMKgwqAgK8KgwqDCoCB8wqDCoCArwqDCoMKgIHzCoMKgwqDC oMKgwqAgfMKgwqAgK8KgwqDCoCB8wqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIHwKPiA+ Pgo+ID4+ICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0t LS0rLS0tLS0tLSstLS0tLS0tLS0rCj4gPj4KPiA+Pgo+ID4+Cj4gPj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBGaWd1cmUgODogTlNIIEFjdGlvbiBhbmQgUm9sZSBNYXBw aW5nCj4gPj4KPiA+Pgo+ID4+Cj4gPj4KPiA+Pgo+ID4+IEFuIFNGIGNvdWxkIHJlY2VpdmUgYW4g TlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIGFuZCByZWNsYXNzaWZ5IGl0Cj4gPj4gdG8gYSBk aWZmZXJlbnQgU1BJIGFuZCBTSSwgcmlnaHQ/IFNvIHdoZW4gYSBTRiByZWNlaXZlcyBhIE5TSCBw YWNrZXQKPiA+PiB3aXRoIFNJID0gMSB0aGF0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1lYW5zIGEg bm9uIHZhbGlkIHBhY2tldC4KPiA+Pgo+ID4+IEFuZCB0aGF0IGNhbiBldmVuIHdvcmsgZm9yIFNJ PTAsIHNpbmNlIHlvdSBkZWNyZW1lbnQgdGhlIFNJIGluIHRoZSBlZ3Jlc3MuCj4gPj4KPiA+Pgo+ ID4+Cj4gPj4gRmFicmljaW8KPiA+Pgo+ID4+Cj4gPj4KPiA+Pgo+ID4+Cj4gPj4gKkZyb206KnNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpEb2xnYW5vdywK PiA+PiBBbmRyZXcgKE5va2lhIC0gU0cpCj4gPj4gKlNlbnQ6KiBxdWludGEtZmVpcmEsIDkgZGUg ZmV2ZXJlaXJvIGRlIDIwMTcgMDE6NTEKPiA+PiAqVG86KiBEYXZlIERvbHNvbjsgRXJpYyBDIFJv c2VuOyBKYW1lcyBOIEd1aWNoYXJkOyBzZmNAaWV0Zi5vcmcKPiA+PiA8bWFpbHRvOnNmY0BpZXRm Lm9yZz4KPiA+PiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1l bnQKPiA+Pgo+ID4+Cj4gPj4KPiA+PiBJIGFzc3VtZWQgdGhhdCBpZiB3ZSBnZXQgdmFsdWUgMSB3 ZSBwcm9jZXNzIHRoZW4gZm9yd2FyZCB3aXRob3V0IE5TSAo+ID4+IGhlYWRlciAoaS5lLikgdGhp cyBpcyB0aGUgbGFzdCBTRiBwcm9jZXNzaW5nLgo+ID4+Cj4gPj4KPiA+Pgo+ID4+IFNvIHdpdGgg dGhhdCBhc3N1bXB0aW9uLCBhIG1vcmUgZXhwbGljaXQgdGV4dCB3b3VsZCBiZToKPiA+Pgo+ID4+ Cj4gPj4KPiA+PiBBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0 ZWQgcGFja2V0IE1VU1QKPiA+PiBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEgYWZ0ZXIgcGVyZm9ybWlu ZyBhbGwgcmVxdWlyZWQgbG9jYWwgcHJvY2Vzc2luZwo+ID4+IGFuZCBiZWZvcmUgZm9yd2FyZGlu ZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRi4gSWYgdGhlIHJlc3VsdGluZyBTSQo+ID4+IGlz IDAsIHRoZSBTRiBNVVNUIHJlbW92ZSB0aGUgTlNIIGhlYWRlciBiZWZvcmUgZm9yd2FyZGluZyB0 aGUgcGFja2V0Lgo+ID4+Cj4gPj4KPiA+Pgo+ID4+IEFuZHJldwo+ID4+Cj4gPj4gKkZyb206ICpz ZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBv bgo+ID4+IGJlaGFsZiBvZiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20KPiA+PiA8 bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4KPiA+PiAqRGF0ZTogKlRodXJzZGF5LCBGZWJy dWFyeSA5LCAyMDE3IGF0IDI6MDQgQU0KPiA+PiAqVG86ICpFcmljIFJvc2VuIDxlcm9zZW5AanVu aXBlci5uZXQgPG1haWx0bzplcm9zZW5AanVuaXBlci5uZXQ+PiwKPiA+PiBKYW1lcyBOIEd1aWNo YXJkIDxqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20KPiA+PiA8bWFpbHRvOmphbWVzLm4uZ3Vp Y2hhcmRAaHVhd2VpLmNvbT4+LCAic2ZjQGlldGYub3JnCj4gPj4gPG1haWx0bzpzZmNAaWV0Zi5v cmc+IiA8c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPj4KPiA+PiAqU3ViamVjdDog KlJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQKPiA+Pgo+ID4+Cj4gPj4KPiA+ PiBFcmljLAo+ID4+Cj4gPj4gSSB3YXMgbmV2ZXIgcXVpdGUgaGFwcHkgd2l0aCB0aGUgb3V0Y29t ZSB0aGF0IG5laXRoZXIgMCBub3IgMSBpcyBhCj4gPj4gdmFsaWQgU0kuCj4gPj4KPiA+PiAoQmVj YXVzZSBpZiByZWNlaXZlZCB3aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRlY3JlbWVudGVkIGFuZAo+ ID4+IGRpc2NhcmRlZC4pCj4gPj4KPiA+Pgo+ID4+Cj4gPj4gSXQgc2VlbXMgdG8gd2FzdGUgYW4g aW5kZXggdmFsdWUuCj4gPj4KPiA+Pgo+ID4+Cj4gPj4gSSBndWVzcyBJJ20gaW50ZXJlc3RlZCB0 byBrbm93IGlmIHRoYXQgaXMgaW1wb3J0YW50IHRvIG90aGVyCj4gPj4gaW1wbGVtZW50ZXJzLCBv ciBpZiB0aGF0IHdhcyBldmVuIHRoZSBpbnRlbnRpb24/Cj4gPj4KPiA+Pgo+ID4+Cj4gPj4KPiA+ Pgo+ID4+IC1EYXZlCj4gPj4KPiA+Pgo+ID4+Cj4gPj4KPiA+Pgo+ID4+Cj4gPj4KPiA+PiAqRnJv bToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkVyaWMg QyBSb3Nlbgo+ID4+ICpTZW50OiogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyAxMTo1MyBB TQo+ID4+ICpUbzoqIEphbWVzIE4gR3VpY2hhcmQ7IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4KPiA+PiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNy ZW1lbnQKPiA+Pgo+ID4+Cj4gPj4KPiA+PiBPbiAyLzcvMjAxNyAyOjI0IFBNLCBKYW1lcyBOIEd1 aWNoYXJkIHdyb3RlOgo+ID4+Cj4gPj4gQSByZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUgc3Bl Y2lmaWMgYW5kIHVwZGF0ZSB0aGUgdGV4dCBhcyBmb2xsb3dzOgo+ID4+Cj4gPj4KPiA+Pgo+ID4+ ICJTZXJ2aWNlIGluZGV4IE1VU1QgYmUgZGVjcmVtZW50ZWQgKmJ5IGEgdmFsdWUgb2YgMSogYnkg U2VydmljZQo+ID4+IEZ1bmN0aW9ucyBvciBieSBTRkMgUHJveHkgbm9kZXMgYWZ0ZXIgcGVyZm9y bWluZyByZXF1aXJlZCBzZXJ2aWNlcyAuIgo+ID4+Cj4gPj4KPiA+PiBBIGNvdXBsZSBvZiBvYnNl cnZhdGlvbnM6Cj4gPj4KPiA+PiAtIFRoZSB0ZXJtICJTRkMgUHJveHkgbm9kZSIgaXMgbm90IGRl ZmluZWQgaW4gZWl0aGVyIHRoZSBOU0ggZHJhZnQgb3IKPiA+PiBpbiBSRkMgNzY2NS7CoCBJIHRo aW5rIHRoZSBpbnRlbnRpb24gaGVyZSBpcyB0byBzYXkgIlNGQyBQcm94eSIuCj4gPj4KPiA+PiAt IElzIHRoZSBpbnRlbnRpb24gdGhhdCB0aGUgU0kgcmVtYWluIHVuY2hhbmdlZCB3aGlsZSB0aGUg U0YgaXMKPiA+PiBvcGVyYXRpbmcgb24gdGhlIHBhY2tldCwgb3IgaXMgdGhlIGludGVudGlvbiBv bmx5IHRoYXQgdGhlIFNJIGJlCj4gPj4gZGVjcmVtZW50ZWQgYmVmb3JlIHRoZSBwYWNrZXQgaXMg ZGVsaXZlcmVkIGJ5IHRoZSBTRiBvciBTRkMgUHJveHkgdG8KPiA+PiBhbiBTRkY/Cj4gPj4KPiA+ PiBJJ2Qgc3VnZ2VzdCBlaXRoZXI6Cj4gPj4KPiA+PiAiQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2Vp dmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUCj4gPj4gZGVjcmVtZW50IHRoZSBT SSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQgU0ZGIgo+ID4+ Cj4gPj4gb3IKPiA+Pgo+ID4+ICJBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1l bmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QKPiA+PiBkZWNyZW1lbnQgdGhlIFNJIGJ5IDEgYmVmb3Jl IGRlbGl2ZXJpbmcgdGhlIHBhY2tldCB0byB0aGUgbmV4dCBTRkYsCj4gPj4gYnV0IG5vdCB1bnRp bCB0aGUgU0YgaGFzIGZpbmlzaGVkIGFsbCBpdHMgb3RoZXIgcHJvY2Vzc2luZyBvZiB0aGUgcGFj a2V0Igo+ID4+Cj4gPj4gZGVwZW5kaW5nIHVwb24gd2hpY2ggaXMgaW50ZW5kZWQuCj4gPj4KPiA+ PiBJIHRoaW5rIGFuIGltcGxpY2F0aW9uIG9mIHRoZXNlIHByb2NlZHVyZXMgaXMgdGhhdCBhbiBT SSB2YWx1ZSBvZiAxCj4gPj4gaXMgbm90IHZhbGlkLsKgIElmIGFuIFNGIGdldHMgYW4gTlNIIHBh Y2tldCB3aXRoIGFuIFNJIG9mIDEsIHRoZSBTRgo+ID4+IHdpbGwgZGVjcmVtZW50IHRoZSBTSSAo c2V0dGluZyBpdCB0byAwKSwgc2VuZCB0aGUgcGFja2V0IHRvIGFuIFNGRiwKPiA+PiBhbmQgdGhl IFNGRiB3aWxsIGRpc2NhcmQgaXQsIGJlY2F1c2UgMCBpcyBhbiBpbnZhbGlkIFNJIHZhbHVlLsKg IElzCj4gPj4gdGhhdCB0aGUgaW50ZW50aW9uPwo+ID4+Cj4gPj4gVGhlIGRyYWZ0IG1ha2VzIGl0 IGNsZWFyICh3ZWxsLCBzb3J0IG9mKSB0aGF0IGFuIFNGRiBzaG91bGQgZGlzY2FyZCBhCj4gPj4g cGFja2V0IHdpdGggYW4gU0kgb2YgMCwgYnV0IGRvZXMgbm90IHNlZW0gdG8gc2F5IHRoYXQgYW4g U0Ygb3IgU0ZDCj4gPj4gUHJveHkgc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQgaXQgcmVjZWl2ZXMg d2l0aCBhbiBTSSBvZiAwLsKgIEl0IHdvdWxkCj4gPj4gcHJvYmFibHkgYmUgYSBnb29kIGlkZWEg dG8gc2F5IHRoYXQuCj4gPj4KPiA+PiBTb21lIHRleHQgaW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0 aW9uIDcuMSkgc3RhdGVzIHRoYW4gYW4gU0ZGIHNob3VsZAo+ID4+IGRpc2NhcmQgYSBwYWNrZXQg d2l0aCBhbiBTSSBvZiB6ZXJvLCBidXQgb3RoZXIgdGV4dCBpbiB0aGUgZHJhZnQKPiA+PiAoZS5n Liwgc2VjdGlvbiAzLjMpIG9ubHkgc2F5cyB0aGF0IGFuIFNGRiBzaG91bGQgbG9nIGFuIGVycm9y IGlmIGl0Cj4gPj4gc2VlcyBhbiBTSSBvZiB6ZXJvLsKgIEl0J3MgcHJvYmFibHkgYmVzdCB0byBj aGFuZ2UgdGhlIHRleHQgaW4gMy4zLiB0bwo+ID4+IHNheSAiU0hPVUxEIGdlbmVyYXRlIGFuIGVy cm9yL2xvZyBtZXNzYWdlIGFuZCBNVVNUIGRpc2NhcmQgdGhlCj4gPj4gcGFja2V0Iiwgb3Igc29t ZXRoaW5nIHNpbWlsYXIuCj4gPj4KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+ID4+IHNmYyBtYWlsaW5nIGxpc3QKPiA+PiBzZmNAaWV0Zi5vcmcg PG1haWx0bzpzZmNAaWV0Zi5vcmc+Cj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMKPiA+Cj4gPgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPiA+IHNmYyBtYWlsaW5nIGxpc3QKPiA+IHNmY0BpZXRmLm9yZwo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMKPiA+Cj4gCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBzZmMgbWFpbGluZyBs aXN0Cj4gc2ZjQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMK ----_com.samsung.android.email_637570712146890 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkxlZ2FsPyAmbmJzcDtTdXJl LiAmbmJzcDtUaGUgU0YgaGFzIGRvbmUgaXQncyBqb2IgcmlnaHQuPC9kaXY+PGRpdj5UaGUgU0ZG IHdpbGwgdGhlbiBkaXNjYXJkIHRoZSBwYWNrZXQuICZuYnNwO1VubGVzcyB0aGVyZSBpcyBhIHJl Y2xhc3NpZmllZCBiZXR3ZWVuIHRoZSBTRiBhbmQgdGhlIFNGRi48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PkFsbG93aW5nIGFuIFNGRiB0byBzZXJ2ZSBhcyBlZ3Jlc3MgZm9yIGEgcGFja2V0IHdp dGggU0kgMCByZXF1aXJlcyBtb3JlIGNvbXBsZXggY2hlY2tpbmcgYW5kIGlzIGxlc3Mgcm9idXN0 LiAmbmJzcDtTdXJlLCBpdCBjYW4gYmUgbWFkZSB0byB3b3JrLiAmbmJzcDtJcyB0aGVyZSBhIHJl YWwgbmVlZCB0byBhbGxvdyBpdD88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PllvdXJzLDwvZGl2 PjxkaXY+Sm9lbDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1 JTtjb2xvcjojNTc1NzU3IiBkaXI9ImF1dG8iPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBT wq4gNiwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdp bmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rp dj48ZGl2PkZyb206ICJGZWR5aywgRG9uIiAmbHQ7ZG9uLmZlZHlrQGhwZS5jb20mZ3Q7IDwvZGl2 PjxkaXY+RGF0ZTogMi85LzE3ICAxNTozOCAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5UbzogIkpv ZWwgTS4gSGFscGVybiIgJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7LCBSb24gUGFya2VyICZs dDtSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJmd0OywgRGF2ZSBEb2xzb24gJmx0O2Rk b2xzb25Ac2FuZHZpbmUuY29tJmd0OyA8L2Rpdj48ZGl2PkNjOiBGYWJyaWNpbyBGZXJyYXogJmx0 O2ZhYnJpY2lvLWZlcnJhekB0ZWxlY29tLnB0Jmd0OywgSmFtZXMgTiBHdWljaGFyZCAmbHQ7amFt ZXMubi5ndWljaGFyZEBodWF3ZWkuY29tJmd0Oywgc2ZjQGlldGYub3JnLCBFcmljIEMgUm9zZW4g Jmx0O2Vyb3NlbkBqdW5pcGVyLm5ldCZndDssICJEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNH KSIgJmx0O2FuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20mZ3Q7IDwvZGl2PjxkaXY+U3ViamVjdDog UkU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudCA8L2Rpdj48ZGl2Pjxicj48L2Rp dj48L2Rpdj5IaSBKb2VsPGJyPjxicj5JIHRoaW5rIHRoZSBxdWVzdGlvbiBpcyBjYW4gYW4gU0Yg cmV0dXJuIGFuIFNJID0gMCBhbmQgdGhlbiB0aGUgU0ZGIGxvb2sgdXAgYW4gU0lEL1NJPTAgYW5k IGRvIHNvbWV0aGluZyB1c2VmdWw/PGJyPkNlcnRhaW5seSBhZnRlciBTSSA9IDAgbm93IGF0IGFu IFNGRiwgZm9yd2FyZGluZyBvbiB0aGUgcGFja2V0IHRvIGFub3RoZXIgU0Ygd2l0aCBTST0gMCBp cyBub3QgdXNlZnVsIGJ1dCBpcyBwcm90ZWN0ZWQgYXQgdGhlIFNGLiAoYWxzbyB0aGVyZSBpcyBu byByb2xsaW5nIG92ZXIgdG8gMjU1IGF0IGFuIFNGKS4gPGJyPlNvbWVob3cgSSB0aGluayB3ZSBn b3QgY2F1Z2h0IHVwIG9uIGEgY29ybmVyIGNhc2UuJm5ic3A7IEknZCBleHBlY3QgdmVyeSBmZXcg Y2hhaW5zIGV2ZXIgdG8gYmUgaGl0dGluZyBTSSA9IDAgaWYgdGhleSBzdGFydCBhdCBTSSA9IDI1 NS4mbmJzcDsgQnV0IHRoZSBxdWVzdGlvbiByZW1haW5zIGlzIFNJID0gMCBhIGxlZ2FsIHJldHVy biB2YWx1ZT8gPGJyPjxicj5DaGVlcnM8YnI+RG9uIDxicj48YnI+Jmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuPGJyPiZndDsgU2VudDogVGh1cnNkYXks IEZlYnJ1YXJ5IDA5LCAyMDE3IDI6NTQgUE08YnI+Jmd0OyBUbzogUm9uIFBhcmtlciAmbHQ7Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSZndDs7IERhdmUgRG9sc29uPGJyPiZndDsgJmx0 O2Rkb2xzb25Ac2FuZHZpbmUuY29tJmd0Ozxicj4mZ3Q7IENjOiBGYWJyaWNpbyBGZXJyYXogJmx0 O2ZhYnJpY2lvLWZlcnJhekB0ZWxlY29tLnB0Jmd0OzsgSmFtZXMgTiBHdWljaGFyZDxicj4mZ3Q7 ICZsdDtqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20mZ3Q7OyBzZmNAaWV0Zi5vcmc7IEVyaWMg QyBSb3Nlbjxicj4mZ3Q7ICZsdDtlcm9zZW5AanVuaXBlci5uZXQmZ3Q7OyBEb2xnYW5vdywgQW5k cmV3IChOb2tpYSAtIFNHKTxicj4mZ3Q7ICZsdDthbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tJmd0 Ozxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8 YnI+Jmd0OyA8YnI+Jmd0OyZuYnNwOyBGcm9tIG15IHBlcnNwZWN0aXZlIGFzIGFuIGluZGl2aWR1 YWwgcGFydGljaXBhbnQgaW4gdGhpcyB3b3JrLCBkZWNsYXJpbmcgdGhhdCAwPGJyPiZndDsgbXVz dCBiZSBkcm9wcGVkIGlzIGEgbWF0dGVyIG9mIHJvYnVzdG5lc3MuPGJyPiZndDsgPGJyPiZndDsg aWYgd2UgYWxsb3cgMCB0byBiZSBwcm9jZXNzZWQgZm9yIGV4aXQgYXQgYW4gU0ZGLCB0aGVuIGEg bWlzLWNvbmZpZ3VyZWQgU0ZGIGNvdWxkPGJyPiZndDsgZWFzaWx5IGNvbnRpbnVlIHByb2Nlc3Np bmcgc3VjaCBhIHBhY2tldC4mbmJzcDsgTm93LCBpdCBpcyB0cnVlIHRoYXQgVFRMIHdpbGw8YnI+ Jmd0OyBldmVudHVhbGx5IGRyb3AgaXQsIGJ1dCB0aGF0IGlzIGFuIGV4cGVuc2l2ZSBmYWxsYmFj ay48YnI+Jmd0OyA8YnI+Jmd0OyBNb3JlIGltcG9ydGFudGx5LCBwcmVzdW1hYmx5IHRoZSBuZXh0 IGVudGl0aXkgZG93biB0aGUgaW5jb3JyZWN0IHBhdGggd291bGQ8YnI+Jmd0OyBkcm9wIGl0IGZv ciBhIDI1NSBTSS4mbmJzcDsgQnV0IGF0IHRoYXQgcG9pbnQgd2UgYXJlIGdldHRpbmcgdGhlIGVy cm9yIGluIHRoZSB3cm9uZzxicj4mZ3Q7IHBsYWNlLCBtYWtpbmcgaXQgaGFyZGVyIHRvIGRpYWdu b3NlIGFuZCByZXBhaXIuPGJyPiZndDsgPGJyPiZndDsgWW91cnMsPGJyPiZndDsgSm9lbDxicj4m Z3Q7IDxicj4mZ3Q7IE9uIDIvOS8xNyAxMjo0MiBQTSwgUm9uIFBhcmtlciB3cm90ZTo8YnI+Jmd0 OyAmZ3Q7IGFncmVlLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IE9uIEZlYiA5LCAyMDE3LCBh dCAxMjoyOCBQTSwgRGF2ZSBEb2xzb24gJmx0O2Rkb2xzb25Ac2FuZHZpbmUuY29tPGJyPiZndDsg Jmd0OyAmbHQ7bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tJmd0OyZndDsgd3JvdGU6PGJyPiZn dDsgJmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEknbSBub3QgY2xlYXIgb24gd2h5IHRoaXMgaXMgYnJv a2VuLCBvciB3aHkgdGhpcyByZXN0cmljdGlvbiBpcyBtYWRlLjxicj4mZ3Q7ICZndDsmZ3Q7PGJy PiZndDsgJmd0OyZndDsgSSBhZ3JlZSBpdCBzaG91bGQgbm90IGJlIHNlbnQgdG8gYW4gU0YsIGJ1 dCBhbiBTRkYgY291bGQgbWFwIGFuIFNJIG9mPGJyPiZndDsgJmd0OyZndDsgemVybyBpbnRvIGEg cGF0aCB0ZXJtaW5hdGlvbi48YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEkuZS4s IHRoZSBsYXN0IFNGIGluIGEgcGF0aCBjb3VsZCBkZWNyZW1lbnQgU0kgZnJvbSAxIHRvIDAsIGFu ZCB0aGU8YnI+Jmd0OyAmZ3Q7Jmd0OyBTRkYgY291bGQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNoYWlu Ljxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4m Z3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyAqRnJvbToqc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkphbWVzIE48YnI+ Jmd0OyAmZ3Q7Jmd0OyBHdWljaGFyZDxicj4mZ3Q7ICZndDsmZ3Q7ICpTZW50OiogVGh1cnNkYXks IEZlYnJ1YXJ5IDA5LCAyMDE3IDEyOjAyIFBNPGJyPiZndDsgJmd0OyZndDsgKlRvOiogRmFicmlj aW8gRmVycmF6OyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRGF2ZSBEb2xzb247PGJy PiZndDsgJmd0OyZndDsgRXJpYyBDIFJvc2VuOyBzZmNAaWV0Zi5vcmcgJmx0O21haWx0bzpzZmNA aWV0Zi5vcmcmZ3Q7PGJyPiZndDsgJmd0OyZndDsgKlN1YmplY3Q6KiBSZTogW3NmY10gTlNIIFNl cnZpY2UgSW5kZXggRGVjcmVtZW50PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgTm90IGV4YWN0bHkuIFNlY3Rpb24gMy4z IHNwZWNpZmllcyAiVGhlIHZhbHVlIHplcm8gZm9yIFNJIGlzIG5vdDxicj4mZ3Q7ICZndDsmZ3Q7 IHZhbGlkIGFuZCBpbmRpY2F0ZXMgYSBicm9rZW4gU0ZDIG9yIG1hbGZ1bmN0aW9uaW5nIFNGIiAu LiBJbiBvdGhlcjxicj4mZ3Q7ICZndDsmZ3Q7IHdvcmRzIGFuIFNGIHNob3VsZCBuZXZlciByZWNl aXZlIGFuIE5TSCBwYWNrZXQgd2l0aCBTSSA9IDAuIE5vdGUgdGhhdDxicj4mZ3Q7ICZndDsmZ3Q7 IGlmIHRoaXMgaGFwcGVuZWQgdGhlbiBlaXRoZXIgYSkgYSBjbGFzc2lmaWVyIHNldCB0aGUgU0kg aW5jb3JyZWN0bHksPGJyPiZndDsgJmd0OyZndDsgb3IgYikgYSByZS1jbGFzc2lmaWVyIHNldCB0 aGUgU0kgaW5jb3JyZWN0bHksIG9yIGMpIGFuIHVwc3RyZWFtIFNGPGJyPiZndDsgJmd0OyZndDsg c2V0IHRoZSBTSSBpbmNvcnJlY3RseTsgYWxsIG9mIHRoZXNlIGNhc2VzIHNob3VsZCBiZSBjYXVn aHQgYnkgdGhlPGJyPiZndDsgJmd0OyZndDsgU0ZGIHdob3NlIGpvYiBpdCBpcyB0byBkaXNjYXJk IE5TSCBwYWNrZXRzIHdpdGggU0kgPSAwLjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZn dDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEppbTxicj4mZ3Q7ICZndDsmZ3Q7 PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7ICpGcm9t OipGYWJyaWNpbyBGZXJyYXogW21haWx0bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdF08YnI+ Jmd0OyAmZ3Q7Jmd0OyAqU2VudDoqIFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAxMTo0OSBB TTxicj4mZ3Q7ICZndDsmZ3Q7ICpUbzoqIEphbWVzIE4gR3VpY2hhcmQgJmx0O2phbWVzLm4uZ3Vp Y2hhcmRAaHVhd2VpLmNvbTxicj4mZ3Q7ICZndDsmZ3Q7ICZsdDttYWlsdG86amFtZXMubi5ndWlj aGFyZEBodWF3ZWkuY29tJmd0OyZndDs7IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpPGJy PiZndDsgJmd0OyZndDsgJmx0O2FuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20gJmx0O21haWx0bzph bmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tJmd0OyZndDs7PGJyPiZndDsgRGF2ZTxicj4mZ3Q7ICZn dDsmZ3Q7IERvbHNvbiAmbHQ7ZGRvbHNvbkBzYW5kdmluZS5jb20gJmx0O21haWx0bzpkZG9sc29u QHNhbmR2aW5lLmNvbSZndDsmZ3Q7OyBFcmljIEM8YnI+Jmd0OyAmZ3Q7Jmd0OyBSb3NlbiAmbHQ7 ZXJvc2VuQGp1bmlwZXIubmV0ICZsdDttYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0Jmd0OyZndDs7 IHNmY0BpZXRmLm9yZzxicj4mZ3Q7ICZndDsmZ3Q7ICZsdDttYWlsdG86c2ZjQGlldGYub3JnJmd0 Ozxicj4mZ3Q7ICZndDsmZ3Q7ICpTdWJqZWN0OiogUkU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4 IERlY3JlbWVudDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEhpIEppbSw8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7IFRoYW5rcy48YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBPbmUgbW9yZSBxdWVzdGlvbiBhYm91dCB0aGUgU0ku PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDsgU2VjdGlvbiAzIHN0YXRlcyB0aGF0Ojxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IFNlcnZpY2UgSW5k ZXggKFNJKTogcHJvdmlkZXMgbG9jYXRpb24gd2l0aGluIHRoZSBTRlAuIFRoZSBpbml0aWFsPGJy PiZndDsgJmd0OyZndDsgY2xhc3NpZmllciBNVVNUIHNldCB0aGUgYXBwcm9wcmlhdGUgU0kgdmFs dWUgZm9yIGEgZ2l2ZW48YnI+Jmd0OyAmZ3Q7Jmd0OyBjbGFzc2lmaWNhdGlvbiByZXN1bHQuIFRo ZSBpbml0aWFsIFNJIHZhbHVlIFNIT1VMRCBkZWZhdWx0IHRvIDI1NS48YnI+Jmd0OyAmZ3Q7Jmd0 OyBIb3dldmVyLCB0aGUgY2xhc3NpZmllciBNVVNUIGFsbG93IGNvbmZpZ3VyYXRpb24gb2Ygb3Ro ZXIgU0kgdmFsdWVzLjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgU2VydmljZSBJ bmRleCBNVVNUIGJlIGRlY3JlbWVudGVkIGJ5IFNlcnZpY2UgRnVuY3Rpb25zIG9yIGJ5IFNGQzxi cj4mZ3Q7ICZndDsmZ3Q7IFByb3h5IG5vZGVzIGFmdGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQgc2Vy dmljZXMgYW5kIHRoZSBuZXc8YnI+Jmd0OyAmZ3Q7Jmd0OyBkZWNyZW1lbnRlZCBTSSB2YWx1ZSBN VVNUIGJlIHVzZWQgaW4gdGhlIGVncmVzcyBOU0ggcGFja2V0Ljxicj4mZ3Q7ICZndDsmZ3Q7PGJy PiZndDsgJmd0OyZndDsgVGhlIGluaXRpYWwgQ2xhc3NpZmllciBNVVNUIHNlbmQgdGhlIHBhY2tl dCB0byB0aGUgZmlyc3QgU0ZGIGluIHRoZTxicj4mZ3Q7ICZndDsmZ3Q7IGlkZW50aWZpZWQgU0ZQ IGZvciBmb3J3YXJkaW5nIGFsb25nIGFuIFNGUC48YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7IElmIHJlLWNsYXNzaWZpY2F0aW9uIG9jY3VycywgYW5kIHRoYXQgcmUtY2xhc3NpZmlj YXRpb24gcmVzdWx0cyBpbiBhPGJyPiZndDsgJmd0OyZndDsgbmV3IFNQSSwgdGhlIChyZSljbGFz c2lmaWVyIGlzLCBpbiBlZmZlY3QsIHRoZSBpbml0aWFsIGNsYXNzaWZpZXIgZm9yPGJyPiZndDsg Jmd0OyZndDsgdGhlIHJlc3VsdGFudCBTUEkuPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgVGh1czo8YnI+Jmd0OyAmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IGEpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElu aXRpYWwgU0kgdmFsdWUgc2hvdWxkIGJlIDI1NSBidXQgb3RoZXIgdmFsdWVzIGNhbiBiZTxicj4m Z3Q7ICZndDsmZ3Q7IGNvbmZpZ3VyZWQgYnkgdGhlIGNsYXNzaWZpZXIuPGJyPiZndDsgJmd0OyZn dDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBiKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTRiBk ZWNyZW1lbnRzIHRoZSBTSSB2YWx1ZSBvbiB0aGUgZWdyZXNzIE5TSCBwYWNrZXQ8YnI+Jmd0OyAm Z3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IGMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IElmIHJlLWNsYXNzaWZpY2F0aW9uIG9jY3VycyB3aXRoIG5ldyBTUEksIHRoZSByZS1j bGFzc2lmaWVyPGJyPiZndDsgJmd0OyZndDsgaXMgdGhlIGluaXRpYWwgY2xhc3NpZmllciwgc28g YnkmbmJzcDsgYSksIFNJIHNob3VsZCBiZSBhZ2FpbiAyNTUgb3Igb3RoZXI8YnI+Jmd0OyAmZ3Q7 Jmd0OyB2YWx1ZTxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IFNvIGFueSBTSSB2YWx1ZSBjYW4gYmUgcmVjZWl2ZSBieSBh biBTRiwgZXZlbiAxIG9yIDAgYmVjYXVzZTo8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsm Z3Q7IMOoSWYgU0k9MSBhbmQgdGhlcmUgaXMgbm8gcmUtY2xhc3NpZmljYXRpb24sIHRoZSBlZ3Jl c3MgTlNIIHdpbGwgaGF2ZTxicj4mZ3Q7ICZndDsmZ3Q7IFNJPTA8YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7IMOoSWYgU0k9MCBhbmQgdGhlcmUgaXMgcmUtY2xhc3NpZmljYXRpb24g d2l0aCBuZXcgU1BJLCB0aGUgZWdyZXNzIE5TSDxicj4mZ3Q7ICZndDsmZ3Q7IHdpbGwgaGF2ZSBh IG5ldyBTUEkgYW5kIGEgU0k9IDI1NSBvciBvdGhlciB2YWx1ZSwgYXMgc3RhdGVkIGluIGEpLjxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgw6hJZiBTST0wIGFuZCB0aGVyZSBpcyBu byByZS1jbGFzc2lmaWNhdGlvbiB0aGUgU0Ygc2hvdWxkIGRpc2NhcmQgdGhlPGJyPiZndDsgJmd0 OyZndDsgcGFja2V0PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgQWxzbyBhbiBTRkYgc2hvdWxkIGZvcndhcmQvaGFuZGxl IHBhY2tldHMgd2l0aCBOU0ggd2l0aCBTST0xIG9yIFNJPTAuPGJyPiZndDsgJmd0OyZndDs8YnI+ Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgRG8geW91IGFn cmVlPzxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpKYW1lcyBOPGJyPiZndDsgJmd0OyZndDsgR3VpY2hh cmQ8YnI+Jmd0OyAmZ3Q7Jmd0OyAqU2VudDoqIHF1aW50YS1mZWlyYSwgOSBkZSBmZXZlcmVpcm8g ZGUgMjAxNyAxNjoyNTxicj4mZ3Q7ICZndDsmZ3Q7ICpUbzoqIEZhYnJpY2lvIEZlcnJhejsgRG9s Z2Fub3csIEFuZHJldyAoTm9raWEgLSBTRyk7IERhdmUgRG9sc29uOzxicj4mZ3Q7ICZndDsmZ3Q7 IEVyaWMgQyBSb3Nlbjsgc2ZjQGlldGYub3JnICZsdDttYWlsdG86c2ZjQGlldGYub3JnJmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7ICpTdWJqZWN0OiogUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERl Y3JlbWVudDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0 Ozxicj4mZ3Q7ICZndDsmZ3Q7IEhpIEZhYnJpY2lvLDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IFdlbGNvbWUhPGJyPiZn dDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsgWWVzLCByZW1vdmFsIG9mIE5TSCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgYW4gU0ZG IG9yIGE8YnI+Jmd0OyAmZ3Q7Jmd0OyByZS1jbGFzc2lmaWVyIChzZWN0aW9uIDQsIGJ1bGxldCBw b2ludCAxIGxheXMgdGhpcyBvdXQpLiBXaXRoIHRoZTxicj4mZ3Q7ICZndDsmZ3Q7IGN1cnJlbnQg YXJjaGl0ZWN0dXJlIHRoZSBTRiBkb2VzIG5vdCBjYXJlIHdoYXQgU0kgdmFsdWUgaXQgZ2V0cywg aXQ8YnI+Jmd0OyAmZ3Q7Jmd0OyBqdXN0IG5lZWRzIHRvIHdvcnJ5IGFib3V0IGRlY3JlbWVudGlu ZyBpdCwgYW5kIGxlYXZlIGl0IHVwIHRvIHRoZSBTRkY8YnI+Jmd0OyAmZ3Q7Jmd0OyB0byBldmFs dWF0ZSB0aGUgU0kgdmFsdWUgYW5kIGFzc29jaWF0ZWQgYWN0aW9uLjxicj4mZ3Q7ICZndDsmZ3Q7 PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEppbTxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7ICpGcm9tOipGYWJyaWNpbyBGZXJyYXogW21haWx0bzpmYWJyaWNpby1mZXJyYXpA dGVsZWNvbS5wdF08YnI+Jmd0OyAmZ3Q7Jmd0OyAqU2VudDoqIFRodXJzZGF5LCBGZWJydWFyeSAw OSwgMjAxNyA3OjEzIEFNPGJyPiZndDsgJmd0OyZndDsgKlRvOiogRG9sZ2Fub3csIEFuZHJldyAo Tm9raWEgLSBTRykgJmx0O2FuZHJldy5kb2xnYW5vd0Bub2tpYS5jb208YnI+Jmd0OyAmZ3Q7Jmd0 OyAmbHQ7bWFpbHRvOmFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20mZ3Q7Jmd0OzsgRGF2ZSBEb2xz b248YnI+Jmd0OyAmZ3Q7Jmd0OyAmbHQ7ZGRvbHNvbkBzYW5kdmluZS5jb20gJmx0O21haWx0bzpk ZG9sc29uQHNhbmR2aW5lLmNvbSZndDsmZ3Q7OyBFcmljIEMgUm9zZW48YnI+Jmd0OyAmZ3Q7Jmd0 OyAmbHQ7ZXJvc2VuQGp1bmlwZXIubmV0ICZsdDttYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0Jmd0 OyZndDs7IEphbWVzIE4gR3VpY2hhcmQ8YnI+Jmd0OyAmZ3Q7Jmd0OyAmbHQ7amFtZXMubi5ndWlj aGFyZEBodWF3ZWkuY29tICZsdDttYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tJmd0 OyZndDs7PGJyPiZndDsgJmd0OyZndDsgc2ZjQGlldGYub3JnICZsdDttYWlsdG86c2ZjQGlldGYu b3JnJmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7ICpTdWJqZWN0OiogUkU6IFtzZmNdIE5TSCBTZXJ2aWNl IEluZGV4IERlY3JlbWVudDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0 OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEhpIGFsbCw8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4m Z3Q7ICZndDsmZ3Q7IEknbSBuZXcgaGVyZSAoanVzdCByZWFkIHRoZSBkcmFmdCBsYXN0IHdlZWsp IGJ1dCBhY2NvcmRpbmcgdG8gY2hhcHRlcjxicj4mZ3Q7ICZndDsmZ3Q7IDQgKGNoZWNrIGZpZ3Vy ZSA4IGZvciBleGFtcGxlKSwgYW4gU0YgaXMgbm90IGFsbG93ZWQgdG8gaW5zZXJ0IG9yPGJyPiZn dDsgJmd0OyZndDsgcmVtb3ZlIE5TSC4gVGhlIHJlbW92YWwgb2YgTlNIIGlzIHJlcG9uc2FiaWxp dHkgb2YgdGhlIFNTRiwgcmlnaHQ/PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmbmJzcDsmbmJzcDsgRmlndXJlIDggbWFw cyBlYWNoIG9mIHRoZSBmb3VyIGFjdGlvbnMgYWJvdmUgdG8gdGhlIGNvbXBvbmVudHMgaW48YnI+ Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFNGQyBhcmNoaXRlY3R1cmUgdGhhdCBjYW4gcGVyZm9ybSBpdC48YnI+Jmd0 OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7 Jmd0OyArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tKzxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IEluc2VydCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8U2VsZWN0IHwmbmJzcDsmbmJz cDsgVXBkYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxTZXJ2aWNlJm5i c3A7IHw8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBvciByZW1vdmUgTlNIJm5ic3A7IHxTZXJ2aWNlfCZu YnNwOyZuYnNwOyZuYnNwOyBOU0gmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfHBvbGljeSZuYnNwOyZuYnNwOyB8PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0 OyAmZ3Q7Jmd0OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfEZ1bmN0aW9ufCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8c2VsZWN0aW9ufDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsg fCBDb21wb25lbnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0tLS0tLS0tKy0tLS0t LS0tK1BhdGgmbmJzcDsmbmJzcDsgKy0tLS0tLS0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCBEZWMuJm5ic3A7Jm5ic3A7IHxVcGRhdGUgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSW5zZXJ0IHwgUmVtb3ZlIHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfFNlcnZpY2UgfENvbnRleHR8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8YnI+Jmd0OyAmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCBJbmRleCZuYnNwOyB8SGVhZGVyIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0t LSstLS0tLS0tKy0tLS0tLS0tLSs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgKyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDsgfENsYXNzaWZpZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsgKy0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7ICZndDsmZ3Q7ICsrLS0tLS0tLS0rLS0tLS0t LS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7IHxTZXJ2aWNlIEZ1bmN0aW9ufCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyArJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8YnI+Jmd0OyAmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IHxGb3J3YXJkZXIoU0ZGKSZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyArLS0t LS0tLS0tLS0tLS0tPGJyPiZndDsgJmd0OyZndDsgKystLS0tLS0tLSstLS0tLS0tLSstLS0tLS0t Ky0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tKzxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsgfFNlcnZpY2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsgKyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgfEZ1bmN0aW9uJm5ic3A7 IChTRikmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4mZ3Q7ICZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDsgKy0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7ICZndDsmZ3Q7ICsr LS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSs8YnI+ Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IHxTRkMgUHJveHkmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsgKyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgKyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsg Ky0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0t LS0tKy0tLS0tLS0tLSs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUgODogTlNIIEFjdGlvbiBhbmQgUm9sZSBN YXBwaW5nPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7 PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEFuIFNG IGNvdWxkIHJlY2VpdmUgYW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIGFuZCByZWNsYXNz aWZ5IGl0PGJyPiZndDsgJmd0OyZndDsgdG8gYSBkaWZmZXJlbnQgU1BJIGFuZCBTSSwgcmlnaHQ/ IFNvIHdoZW4gYSBTRiByZWNlaXZlcyBhIE5TSCBwYWNrZXQ8YnI+Jmd0OyAmZ3Q7Jmd0OyB3aXRo IFNJID0gMSB0aGF0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1lYW5zIGEgbm9uIHZhbGlkIHBhY2tl dC48YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IEFuZCB0aGF0IGNhbiBldmVuIHdv cmsgZm9yIFNJPTAsIHNpbmNlIHlvdSBkZWNyZW1lbnQgdGhlIFNJIGluIHRoZSBlZ3Jlc3MuPGJy PiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDsgRmFicmljaW88YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsgKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxm IE9mICpEb2xnYW5vdyw8YnI+Jmd0OyAmZ3Q7Jmd0OyBBbmRyZXcgKE5va2lhIC0gU0cpPGJyPiZn dDsgJmd0OyZndDsgKlNlbnQ6KiBxdWludGEtZmVpcmEsIDkgZGUgZmV2ZXJlaXJvIGRlIDIwMTcg MDE6NTE8YnI+Jmd0OyAmZ3Q7Jmd0OyAqVG86KiBEYXZlIERvbHNvbjsgRXJpYyBDIFJvc2VuOyBK YW1lcyBOIEd1aWNoYXJkOyBzZmNAaWV0Zi5vcmc8YnI+Jmd0OyAmZ3Q7Jmd0OyAmbHQ7bWFpbHRv OnNmY0BpZXRmLm9yZyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyAqU3ViamVjdDoqIFJlOiBbc2ZjXSBO U0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBJIGFzc3VtZWQgdGhhdCBpZiB3 ZSBnZXQgdmFsdWUgMSB3ZSBwcm9jZXNzIHRoZW4gZm9yd2FyZCB3aXRob3V0IE5TSDxicj4mZ3Q7 ICZndDsmZ3Q7IGhlYWRlciAoaS5lLikgdGhpcyBpcyB0aGUgbGFzdCBTRiBwcm9jZXNzaW5nLjxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7IFNvIHdpdGggdGhhdCBhc3N1bXB0aW9uLCBhIG1vcmUgZXhwbGljaXQgdGV4dCB3 b3VsZCBiZTo8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZn dDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBBbiBTRiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1l bmNhcHN1bGF0ZWQgcGFja2V0IE1VU1Q8YnI+Jmd0OyAmZ3Q7Jmd0OyBkZWNyZW1lbnQgdGhlIFNJ IGJ5IDEgYWZ0ZXIgcGVyZm9ybWluZyBhbGwgcmVxdWlyZWQgbG9jYWwgcHJvY2Vzc2luZzxicj4m Z3Q7ICZndDsmZ3Q7IGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0 IFNGRi4gSWYgdGhlIHJlc3VsdGluZyBTSTxicj4mZ3Q7ICZndDsmZ3Q7IGlzIDAsIHRoZSBTRiBN VVNUIHJlbW92ZSB0aGUgTlNIIGhlYWRlciBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFja2V0Ljxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7IEFuZHJldzxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgKkZyb206 ICpzZmMgJmx0O3NmYy1ib3VuY2VzQGlldGYub3JnICZsdDttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7Jmd0OyBvbjxicj4mZ3Q7ICZndDsmZ3Q7IGJlaGFsZiBvZiBEYXZlIERvbHNvbiAm bHQ7ZGRvbHNvbkBzYW5kdmluZS5jb208YnI+Jmd0OyAmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOmRkb2xz b25Ac2FuZHZpbmUuY29tJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyAqRGF0ZTogKlRodXJzZGF5 LCBGZWJydWFyeSA5LCAyMDE3IGF0IDI6MDQgQU08YnI+Jmd0OyAmZ3Q7Jmd0OyAqVG86ICpFcmlj IFJvc2VuICZsdDtlcm9zZW5AanVuaXBlci5uZXQgJmx0O21haWx0bzplcm9zZW5AanVuaXBlci5u ZXQmZ3Q7Jmd0Oyw8YnI+Jmd0OyAmZ3Q7Jmd0OyBKYW1lcyBOIEd1aWNoYXJkICZsdDtqYW1lcy5u Lmd1aWNoYXJkQGh1YXdlaS5jb208YnI+Jmd0OyAmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOmphbWVzLm4u Z3VpY2hhcmRAaHVhd2VpLmNvbSZndDsmZ3Q7LCAic2ZjQGlldGYub3JnPGJyPiZndDsgJmd0OyZn dDsgJmx0O21haWx0bzpzZmNAaWV0Zi5vcmcmZ3Q7IiAmbHQ7c2ZjQGlldGYub3JnICZsdDttYWls dG86c2ZjQGlldGYub3JnJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyAqU3ViamVjdDogKlJlOiBb c2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBFcmljLDxicj4mZ3Q7 ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgSSB3YXMgbmV2ZXIgcXVpdGUgaGFwcHkgd2l0aCB0 aGUgb3V0Y29tZSB0aGF0IG5laXRoZXIgMCBub3IgMSBpcyBhPGJyPiZndDsgJmd0OyZndDsgdmFs aWQgU0kuPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyAoQmVjYXVzZSBpZiByZWNl aXZlZCB3aXRoIHZhbHVlIG9mIDEsIGl0IGlzIGRlY3JlbWVudGVkIGFuZDxicj4mZ3Q7ICZndDsm Z3Q7IGRpc2NhcmRlZC4pPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgSXQgc2VlbXMgdG8gd2FzdGUgYW4gaW5kZXggdmFs dWUuPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJy PiZndDsgJmd0OyZndDsgSSBndWVzcyBJJ20gaW50ZXJlc3RlZCB0byBrbm93IGlmIHRoYXQgaXMg aW1wb3J0YW50IHRvIG90aGVyPGJyPiZndDsgJmd0OyZndDsgaW1wbGVtZW50ZXJzLCBvciBpZiB0 aGF0IHdhcyBldmVuIHRoZSBpbnRlbnRpb24/PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7IC1EYXZlPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyAqRnJvbToqc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkVyaWMgQyBSb3Nlbjxi cj4mZ3Q7ICZndDsmZ3Q7ICpTZW50OiogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyAxMTo1 MyBBTTxicj4mZ3Q7ICZndDsmZ3Q7ICpUbzoqIEphbWVzIE4gR3VpY2hhcmQ7IHNmY0BpZXRmLm9y ZyAmbHQ7bWFpbHRvOnNmY0BpZXRmLm9yZyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyAqU3ViamVjdDoq IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBPbiAyLzcv MjAxNyAyOjI0IFBNLCBKYW1lcyBOIEd1aWNoYXJkIHdyb3RlOjxicj4mZ3Q7ICZndDsmZ3Q7PGJy PiZndDsgJmd0OyZndDsgQSByZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUgc3BlY2lmaWMgYW5k IHVwZGF0ZSB0aGUgdGV4dCBhcyBmb2xsb3dzOjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7ICJTZXJ2aWNlIGluZGV4IE1V U1QgYmUgZGVjcmVtZW50ZWQgKmJ5IGEgdmFsdWUgb2YgMSogYnkgU2VydmljZTxicj4mZ3Q7ICZn dDsmZ3Q7IEZ1bmN0aW9ucyBvciBieSBTRkMgUHJveHkgbm9kZXMgYWZ0ZXIgcGVyZm9ybWluZyBy ZXF1aXJlZCBzZXJ2aWNlcyAuIjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+ Jmd0OyAmZ3Q7Jmd0OyBBIGNvdXBsZSBvZiBvYnNlcnZhdGlvbnM6PGJyPiZndDsgJmd0OyZndDs8 YnI+Jmd0OyAmZ3Q7Jmd0OyAtIFRoZSB0ZXJtICJTRkMgUHJveHkgbm9kZSIgaXMgbm90IGRlZmlu ZWQgaW4gZWl0aGVyIHRoZSBOU0ggZHJhZnQgb3I8YnI+Jmd0OyAmZ3Q7Jmd0OyBpbiBSRkMgNzY2 NS4mbmJzcDsgSSB0aGluayB0aGUgaW50ZW50aW9uIGhlcmUgaXMgdG8gc2F5ICJTRkMgUHJveHki Ljxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgLSBJcyB0aGUgaW50ZW50aW9uIHRo YXQgdGhlIFNJIHJlbWFpbiB1bmNoYW5nZWQgd2hpbGUgdGhlIFNGIGlzPGJyPiZndDsgJmd0OyZn dDsgb3BlcmF0aW5nIG9uIHRoZSBwYWNrZXQsIG9yIGlzIHRoZSBpbnRlbnRpb24gb25seSB0aGF0 IHRoZSBTSSBiZTxicj4mZ3Q7ICZndDsmZ3Q7IGRlY3JlbWVudGVkIGJlZm9yZSB0aGUgcGFja2V0 IGlzIGRlbGl2ZXJlZCBieSB0aGUgU0Ygb3IgU0ZDIFByb3h5IHRvPGJyPiZndDsgJmd0OyZndDsg YW4gU0ZGPzxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgSSdkIHN1Z2dlc3QgZWl0 aGVyOjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgIkFuIFNGIG9yIFNGQyBQcm94 eSByZWNlaXZpbmcgYW4gTlNILWVuY2Fwc3VsYXRlZCBwYWNrZXQgTVVTVDxicj4mZ3Q7ICZndDsm Z3Q7IGRlY3JlbWVudCB0aGUgU0kgYnkgMSBiZWZvcmUgZGVsaXZlcmluZyB0aGUgcGFja2V0IHRv IHRoZSBuZXh0IFNGRiI8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IG9yPGJyPiZn dDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyAiQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2Vpdmlu ZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUPGJyPiZndDsgJmd0OyZndDsgZGVjcmVt ZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNrZXQgdG8gdGhlIG5leHQg U0ZGLDxicj4mZ3Q7ICZndDsmZ3Q7IGJ1dCBub3QgdW50aWwgdGhlIFNGIGhhcyBmaW5pc2hlZCBh bGwgaXRzIG90aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBhY2tldCI8YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7IGRlcGVuZGluZyB1cG9uIHdoaWNoIGlzIGludGVuZGVkLjxicj4mZ3Q7 ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgSSB0aGluayBhbiBpbXBsaWNhdGlvbiBvZiB0aGVz ZSBwcm9jZWR1cmVzIGlzIHRoYXQgYW4gU0kgdmFsdWUgb2YgMTxicj4mZ3Q7ICZndDsmZ3Q7IGlz IG5vdCB2YWxpZC4mbmJzcDsgSWYgYW4gU0YgZ2V0cyBhbiBOU0ggcGFja2V0IHdpdGggYW4gU0kg b2YgMSwgdGhlIFNGPGJyPiZndDsgJmd0OyZndDsgd2lsbCBkZWNyZW1lbnQgdGhlIFNJIChzZXR0 aW5nIGl0IHRvIDApLCBzZW5kIHRoZSBwYWNrZXQgdG8gYW4gU0ZGLDxicj4mZ3Q7ICZndDsmZ3Q7 IGFuZCB0aGUgU0ZGIHdpbGwgZGlzY2FyZCBpdCwgYmVjYXVzZSAwIGlzIGFuIGludmFsaWQgU0kg dmFsdWUuJm5ic3A7IElzPGJyPiZndDsgJmd0OyZndDsgdGhhdCB0aGUgaW50ZW50aW9uPzxicj4m Z3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgVGhlIGRyYWZ0IG1ha2VzIGl0IGNsZWFyICh3 ZWxsLCBzb3J0IG9mKSB0aGF0IGFuIFNGRiBzaG91bGQgZGlzY2FyZCBhPGJyPiZndDsgJmd0OyZn dDsgcGFja2V0IHdpdGggYW4gU0kgb2YgMCwgYnV0IGRvZXMgbm90IHNlZW0gdG8gc2F5IHRoYXQg YW4gU0Ygb3IgU0ZDPGJyPiZndDsgJmd0OyZndDsgUHJveHkgc2hvdWxkIGRpc2NhcmQgYSBwYWNr ZXQgaXQgcmVjZWl2ZXMgd2l0aCBhbiBTSSBvZiAwLiZuYnNwOyBJdCB3b3VsZDxicj4mZ3Q7ICZn dDsmZ3Q7IHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIHNheSB0aGF0Ljxicj4mZ3Q7ICZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDsgU29tZSB0ZXh0IGluIHRoZSBkcmFmdCAoZS5nLiwgc2VjdGlv biA3LjEpIHN0YXRlcyB0aGFuIGFuIFNGRiBzaG91bGQ8YnI+Jmd0OyAmZ3Q7Jmd0OyBkaXNjYXJk IGEgcGFja2V0IHdpdGggYW4gU0kgb2YgemVybywgYnV0IG90aGVyIHRleHQgaW4gdGhlIGRyYWZ0 PGJyPiZndDsgJmd0OyZndDsgKGUuZy4sIHNlY3Rpb24gMy4zKSBvbmx5IHNheXMgdGhhdCBhbiBT RkYgc2hvdWxkIGxvZyBhbiBlcnJvciBpZiBpdDxicj4mZ3Q7ICZndDsmZ3Q7IHNlZXMgYW4gU0kg b2YgemVyby4mbmJzcDsgSXQncyBwcm9iYWJseSBiZXN0IHRvIGNoYW5nZSB0aGUgdGV4dCBpbiAz LjMuIHRvPGJyPiZndDsgJmd0OyZndDsgc2F5ICJTSE9VTEQgZ2VuZXJhdGUgYW4gZXJyb3IvbG9n IG1lc3NhZ2UgYW5kIE1VU1QgZGlzY2FyZCB0aGU8YnI+Jmd0OyAmZ3Q7Jmd0OyBwYWNrZXQiLCBv ciBzb21ldGhpbmcgc2ltaWxhci48YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJmd0 OyZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsmZ3Q7IHNmY0BpZXRmLm9yZyAmbHQ7 bWFpbHRvOnNmY0BpZXRmLm9yZyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7PGJyPiZn dDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4mZ3Q7ICZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsgc2ZjQGlldGYub3JnPGJy PiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxicj4m Z3Q7ICZndDs8YnI+Jmd0OyA8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4mZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBzZmNAaWV0 Zi5vcmc8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxi cj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_637570712146890-- From nobody Thu Feb 9 13:00:28 2017 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 47CFD12950B for ; Thu, 9 Feb 2017 13:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, 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 483AwSWY_2H6 for ; Thu, 9 Feb 2017 13:00:25 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02AC12940D for ; Thu, 9 Feb 2017 13:00:24 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 16:00:23 -0500 From: Dave Dolson To: "Joel M. Halpern" , Ron Parker Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA3q0iAAAgj/lAAHXyRAAAH1qCQAAPaRoAAAM/fAAAAeleAAAmxtlD//72uAIAAJKYAgABEBwA= Date: Thu, 9 Feb 2017 21:00:22 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> In-Reply-To: <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Fabricio Ferraz , James N Guichard , "sfc@ietf.org" , Eric C Rosen , "Dolganow, Andrew \(Nokia - SG\)" Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:00:27 -0000 Discussing misconfigured SFFs is a straw-man argument. Once one starts tryi= ng to anticipate down-stream devices being misconfigured, one can invent a = lot of silly requirements. >From an aesthetic point of view, I think it's bad that there are two SI val= ues (0 and 1) that cannot be used. The real requirement, IMO, is that no device decrements 0 and forwards NSH. Since only SFs decrement SI, only SFs need to do this check. And any discussion about buggy SFs... well there is a lot of bad stuff that= bugs can cause. -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Thursday, February 09, 2017 2:54 PM To: Ron Parker; Dave Dolson Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); James N Guic= hard; Fabricio Ferraz Subject: Re: [sfc] NSH Service Index Decrement From my perspective as an individual participant in this work,=20 declaring that 0 must be dropped is a matter of robustness. if we allow 0 to be processed for exit at an SFF, then a mis-configured=20 SFF could easily continue processing such a packet. Now, it is true=20 that TTL will eventually drop it, but that is an expensive fallback. More importantly, presumably the next entitiy down the incorrect path=20 would drop it for a 255 SI. But at that point we are getting the error=20 in the wrong place, making it harder to diagnose and repair. Yours, Joel On 2/9/17 12:42 PM, Ron Parker wrote: > agree. > > On Feb 9, 2017, at 12:28 PM, Dave Dolson > wrote: > >> I'm not clear on why this is broken, or why this restriction is made. >> >> I agree it should not be sent to an SF, but an SFF could map an SI of >> zero into a path termination. >> >> I.e., the last SF in a path could decrement SI from 1 to 0, and the >> SFF could then terminate the chain. >> >> >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N Guichard >> *Sent:* Thursday, February 09, 2017 12:02 PM >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; >> Eric C Rosen; sfc@ietf.org >> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> >> >> Not exactly. Section 3.3 specifies "The value zero for SI is not valid >> and indicates a broken SFC or malfunctioning SF" .. In other words an >> SF should never receive an NSH packet with SI =3D 0. Note that if this >> happened then either a) a classifier set the SI incorrectly, or b) a >> re-classifier set the SI incorrectly, or c) an upstream SF set the SI >> incorrectly; all of these cases should be caught by the SFF whose job >> it is to discard NSH packets with SI =3D 0. >> >> >> >> Jim >> >> >> >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >> *Sent:* Thursday, February 09, 2017 11:49 AM >> *To:* James N Guichard > >; Dolganow, Andrew (Nokia - SG) >> >; Dave >> Dolson >; Eric C >> Rosen >; sfc@ietf.org >> >> *Subject:* RE: [sfc] NSH Service Index Decrement >> >> >> >> Hi Jim, >> >> Thanks. >> >> >> >> One more question about the SI. >> >> >> >> Section 3 states that: >> >> >> >> Service Index (SI): provides location within the SFP. The initial >> classifier MUST set the appropriate SI value for a given >> classification result. The initial SI value SHOULD default to 255. >> However, the classifier MUST allow configuration of other SI values. >> >> Service Index MUST be decremented by Service Functions or by SFC Proxy >> nodes after performing required services and the new decremented SI >> value MUST be used in the egress NSH packet. >> >> The initial Classifier MUST send the packet to the first SFF in the >> identified SFP for forwarding along an SFP. >> >> If re-classification occurs, and that re-classification results in a >> new SPI, the (re)classifier is, in effect, the initial classifier for >> the resultant SPI. >> >> >> >> Thus: >> >> a) Initial SI value should be 255 but other values can be >> configured by the classifier. >> >> b) SF decrements the SI value on the egress NSH packet >> >> c) If re-classification occurs with new SPI, the re-classifier >> is the initial classifier, so by a), SI should be again 255 or other >> value >> >> >> >> So any SI value can be receive by an SF, even 1 or 0 because: >> >> =E8If SI=3D1 and there is no re-classification, the egress NSH will have= SI=3D0 >> >> =E8If SI=3D0 and there is re-classification with new SPI, the egress NSH >> will have a new SPI and a SI=3D 255 or other value, as stated in a). >> >> =E8If SI=3D0 and there is no re-classification the SF should discard the >> packet >> >> >> >> Also an SFF should forward/handle packets with NSH with SI=3D1 or SI=3D0= . >> >> >> >> Do you agree? >> >> >> >> >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N Guichard >> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; >> Eric C Rosen; sfc@ietf.org >> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> >> >> Hi Fabricio, >> >> >> >> Welcome! >> >> >> >> Yes, removal of NSH is the responsibility of an SFF or a re-classifier >> (section 4, bullet point 1 lays this out). With the current >> architecture the SF does not care what SI value it gets, it just needs >> to worry about decrementing it, and leave it up to the SFF to evaluate >> the SI value and associated action. >> >> >> >> Jim >> >> >> >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >> *Sent:* Thursday, February 09, 2017 7:13 AM >> *To:* Dolganow, Andrew (Nokia - SG) > >; Dave Dolson > >; Eric C Rosen > >; James N Guichard >> >; >> sfc@ietf.org >> *Subject:* RE: [sfc] NSH Service Index Decrement >> >> >> >> Hi all, >> >> I'm new here (just read the draft last week) but according to chapter >> 4 (check figure 8 for example), an SF is not allowed to insert or >> remove NSH. The removal of NSH is reponsability of the SSF, right? >> >> >> >> Figure 8 maps each of the four actions above to the components in the >> >> SFC architecture that can perform it. >> >> >> >> +---------------+------------------+-------+----------------+---------+ >> >> | | Insert |Select | Update |Service | >> >> | | or remove NSH |Service| NSH |policy | >> >> | | |Function| |selection| >> >> | Component +--------+--------+Path +----------------+ | >> >> | | | | | Dec. |Update | | >> >> | | Insert | Remove | |Service |Context| | >> >> | | | | | Index |Header | | >> >> +----------------+--------+--------+-------+--------+-------+---------+ >> >> | | + | + | | | + | | >> >> |Classifier | | | | | | | >> >> +--------------- +--------+--------+-------+--------+-------+---------+ >> >> |Service Function| | + | + | | | | >> >> |Forwarder(SFF) | | | | | | | >> >> +--------------- +--------+--------+-------+--------+-------+---------+ >> >> |Service | | | | + | + | + | >> >> |Function (SF) | | | | | | | >> >> +--------------- +--------+--------+-------+--------+-------+---------+ >> >> |SFC Proxy | + | + | | + | | | >> >> +----------------+--------+--------+-------+--------+-------+---------+ >> >> >> >> Figure 8: NSH Action and Role Mapping >> >> >> >> >> >> An SF could receive an NSH packet with an SI of 1, and reclassify it >> to a different SPI and SI, right? So when a SF receives a NSH packet >> with SI =3D 1 that does not necessarily means a non valid packet. >> >> And that can even work for SI=3D0, since you decrement the SI in the egr= ess. >> >> >> >> Fabricio >> >> >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, >> Andrew (Nokia - SG) >> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 >> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org >> >> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> >> >> I assumed that if we get value 1 we process then forward without NSH >> header (i.e.) this is the last SF processing. >> >> >> >> So with that assumption, a more explicit text would be: >> >> >> >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement >> the SI by 1 after performing all required local processing and before >> forwarding the packet to the next SFF. If the resulting SI is 0, the >> SF MUST remove the NSH header before forwarding the packet. >> >> >> >> Andrew >> >> *From: *sfc > on >> behalf of Dave Dolson > >> *Date: *Thursday, February 9, 2017 at 2:04 AM >> *To: *Eric Rosen >, >> James N Guichard > >, "sfc@ietf.org >> " > >> *Subject: *Re: [sfc] NSH Service Index Decrement >> >> >> >> Eric, >> >> I was never quite happy with the outcome that neither 0 nor 1 is a >> valid SI. >> >> (Because if received with value of 1, it is decremented and discarded.) >> >> >> >> It seems to waste an index value. >> >> >> >> I guess I'm interested to know if that is important to other >> implementers, or if that was even the intention? >> >> >> >> >> >> -Dave >> >> >> >> >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C Rosen >> *Sent:* Wednesday, February 08, 2017 11:53 AM >> *To:* James N Guichard; sfc@ietf.org >> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> >> >> On 2/7/2017 2:24 PM, James N Guichard wrote: >> >> A request was made to be more specific and update the text as follows: >> >> >> >> "Service index MUST be decremented *by a value of 1* by Service >> Functions or by SFC Proxy nodes after performing required services ." >> >> >> A couple of observations: >> >> - The term "SFC Proxy node" is not defined in either the NSH draft or >> in RFC 7665. I think the intention here is to say "SFC Proxy". >> >> - Is the intention that the SI remain unchanged while the SF is >> operating on the packet, or is the intention only that the SI be >> decremented before the packet is delivered by the SF or SFC Proxy to >> an SFF? >> >> I'd suggest either: >> >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >> decrement the SI by 1 before delivering the packet to the next SFF" >> >> or >> >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >> decrement the SI by 1 before delivering the packet to the next SFF, >> but not until the SF has finished all its other processing of the packet= " >> >> depending upon which is intended. >> >> I think an implication of these procedures is that an SI value of 1 is >> not valid. If an SF gets an NSH packet with an SI of 1, the SF will >> decrement the SI (setting it to 0), send the packet to an SFF, and the >> SFF will discard it, because 0 is an invalid SI value. Is that the >> intention? >> >> The draft makes it clear (well, sort of) that an SFF should discard a >> packet with an SI of 0, but does not seem to say that an SF or SFC >> Proxy should discard a packet it receives with an SI of 0. It would >> probably be a good idea to say that. >> >> Some text in the draft (e.g., section 7.1) states than an SFF should >> discard a packet with an SI of zero, but other text in the draft >> (e.g., section 3.3) only says that an SFF should log an error if it >> sees an SI of zero. It's probably best to change the text in 3.3. to >> say "SHOULD generate an error/log message and MUST discard the >> packet", or something similar. >> >> _______________________________________________ >> 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 Thu Feb 9 23:43:36 2017 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 14EC712A01C for ; Thu, 9 Feb 2017 23:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 8LeAv3nn7XNK for ; Thu, 9 Feb 2017 23:43:33 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 7CDF012A037 for ; Thu, 9 Feb 2017 23:43:33 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s186so30852686qkb.1 for ; Thu, 09 Feb 2017 23:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=bAawSxopk3405mT3VfZjj/RaKrgXx1jSw75JWrETRoQ=; b=rOu3zeSNaVCi1uljED73ebMFA1ozYeQ0p/w6IH6FA6r6yunIIlu9pIwLZweJ0P6wQM cKDLSqctjBN8N7pcZkBXx8v6js8Qg6e7bInb7suWHx4SJeuyuKQI+RMKvYXSBP/nivvH pOX74lRLiHGTHDP3vNuYo91TWjDzMCAKRFhgz0oP9EGeMPtgUQx5qT1FlDAtgKsv680X Xlj0Yxi4HZ3YzBwSqjl/gsSptTcTQN/WTI791C/JuQidUgXi0IH+/hapD4UIgSiLSB71 FZwdDEboRwFIerA58IL6YG/EhTMjKMb155CPzwpW1A8OdLt3ovaref/VyRTOc8GMl0n7 u8mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=bAawSxopk3405mT3VfZjj/RaKrgXx1jSw75JWrETRoQ=; b=nr4ZvcYDQPCQZOmwDSAQzU4I2cCiCLuNnYJCUi380q/G8s3EF+oM9vyxODC/4Ie2TZ YB/IvysgEhMTs/302luaiqtECiqRb3lG+Ulsq6RiTL4NYo3RV75bvypmnHxNylpJla/f YrQLBQDcfACZLcIAykiFK+OhGg3mYVmksIyu3R3ZhOcu5qA5udMFcSMyksZFM/4+sbyv Hn0xNG7j8WIR7KBmoS16FcMb/oUCDLhW6VUc5LSyUnvE/n1bEl08i3SssRpe8cgFTHQY 44gFSvEyXNH9Zcx0ofZENpzdpbMCGFFFMyhUqkU2dDl10Ok9VRbWqF7Cap7khCM/BvRc LMOw== X-Gm-Message-State: AMke39nGCtLAnI4lDkGHsF1F1tXPJYQZpzkq4LWPmtdfKLN302CHJKaF2hV2lyrj8QZJHi3pP5B3qrf7e2rHDg== X-Received: by 10.55.144.4 with SMTP id s4mr6830317qkd.101.1486712612588; Thu, 09 Feb 2017 23:43:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.11 with HTTP; Thu, 9 Feb 2017 23:43:32 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?2b7ZiNuM2Kcg2K7Ys9ix2YjbjNin2YYg2K/Zh9qp2LHYr9uMIFBvdXlhIEtob3NyYXZpYW4gRA==?= =?UTF-8?B?ZWhrb3JkaQ==?= Date: Fri, 10 Feb 2017 11:13:32 +0330 Message-ID: To: sfc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c057a7028162e054828413f Archived-At: Subject: [sfc] Fwd: Help Me! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 07:43:35 -0000 --94eb2c057a7028162e054828413f Content-Type: text/plain; charset=UTF-8 Hello Dear Prof.! I am a PHD student and my thesis is about service function chaining and i need a complete list of service function types. How can i get this list? Please help me. Thank you. Best Regards. PHD Student of Islamic Azad University Yazd Branch Faculty Member of Islamic Azad University Shahrekord Branch Home Page: http://iaushk.ac.ir/part/pages.aspx?id=74&pid=1 Google Citation : http://scholar.google.com/citations?user=ZXfOfdQAAAAJ&hl=en Work Phone: 03833361000 - 403 Cell Phone:09132800436 --94eb2c057a7028162e054828413f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Dear Prof.!
I am a PHD student an= d my thesis is about service function chaining and i need a complete list o= f service function types. How can i get this list? Please help me.
Thank you.
Best Regards.

PHD Student of Islamic Azad University Yazd Branch
= Faculty Member of Islamic Azad University Shahrekor= d Branch
Home Page:

--94eb2c057a7028162e054828413f-- From nobody Fri Feb 10 06:17:02 2017 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 E39741297CA for ; Fri, 10 Feb 2017 06:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 eJZv9zLkvN4R for ; Fri, 10 Feb 2017 06:16:57 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACE0129965 for ; Fri, 10 Feb 2017 06:16:55 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1AEGH84016452; Fri, 10 Feb 2017 14:16:17 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1AEGBHW016351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2017 14:16:14 GMT From: "Adrian Farrel" To: "'Dave Dolson'" , "'Joel M. Halpern'" , "'Ron Parker'" References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> In-Reply-To: Date: Fri, 10 Feb 2017 14:16:10 -0000 Message-ID: <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHoYgY6PCVGpHJ8su3f5ejQO2dmKAIvwOccAgx3iLoAvuXz6QHh04WVAzglJZACFiSEIwEdT5qdAIUzmAMCaf1/yQGATjGeAl0zdESgleEx8A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22876.007 X-TM-AS-Result: No--22.838-10.0-31-10 X-imss-scan-details: No--22.838-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkDUaFx23KkikSlrosmS0SOApPZLm8rbDqKGdD5D0Silt5af w+DzG8f3s8tZrwRBjQXoYs61+fJc5NtOvGMWsAX3QpxiLlDD9FVQLBvX11RpSWHaXGR9wawUKPY q+PY4aehpqCJ85/SyBaZlQCeqsRDkfruvMY+uFQFIRA38P/dwbrfoYZ/CMuhl2nVuImEjI1HyC9 xIpUJKQp8lGcKXa/kz/wDkrCcTa5YDStbE6JofTpVRzPxemJL0moKXVHfiMM/IXwWZDwrVt4Rjb 6q99slJxlRJ8spTeygzPgQ6xcktrrUd2R7XKvn3A9lly13c/gEkKs3LoBtQleOxOq7LQlGLfsXj 6HQ7ImgwSJCWRFBkHdbDnR9yJLm4gODgSxfzY5yaVoAi2I40/UKzuF0egUUDsow+EYWy6L+G0xr fKr0fl5Juj05Xh1XarLrHx8shLho25Mb4M8J09vVFR4sC8dPyEtdrY/Wb3fPxxaAXDrCnswe0jl RIZ0jupijGtm75xl5Wz2eiIuWGmuUv8ayIKAgLfKmN9+B2Aw+FXSyuOiq3H4Sud44w9uOaO6MSX 7i8zf+N4jR8euxc6opgZhu1vxyDBb95QfAlOsj0hv/rD7WVZGSNw0miEcKrWPGsG0pj4dMwfXHH Xt4W1Ejxx83tKaNU7BusN1dw7H37JRM8lnRNU01Wvi92YKnOtMSM1a+1JW/9Ez/5IpHqp+ud6f9 fnjr92tIVD0ndza+Hw6CApGkzG0KtkjlYA82d1QWGBM/v9tanp0KWJWIxTFmmz7LVVfOpuf9ilN Y1CXQscetG9epYw4ghjV0hcIsHOg4q4lJPNt+eAiCmPx4NwGNn8XPiALIb+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Cc: 'Eric C Rosen' , "'Dolganow, Andrew \(Nokia - SG\)'" , sfc@ietf.org, 'James N Guichard' , 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:17:00 -0000 Oh, you finally pushed me into this discussion, Dave. We're building a protocol. with a protocol, you cannot (must not) assume = good behavior from your neighbor. So if the SF touches the SI (which it does) we must define the edge = conditions.=20 If it is the SF's job to decrement the SI, then we must also define what = it does when SI=3D0 (otherwise, it will set SI to 0-1). If the SF is not allowed to decrement the SI below zero (which makes = sense) we must define what it must do. Since SFs are allowed to drop packets (indeed that is one of their main = jobs ;-) then this would be fine. All that would be left is to define whether they apply the test before = or after normal processing. As an aside, I agree with Don that TTL helps relax this a little, but = does not get us all the way there. Cheers, Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: 09 February 2017 21:00 > To: Joel M. Halpern; Ron Parker > Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C Rosen; = Dolganow, > Andrew (Nokia - SG) > Subject: Re: [sfc] NSH Service Index Decrement >=20 > Discussing misconfigured SFFs is a straw-man argument. Once one starts = trying to > anticipate down-stream devices being misconfigured, one can invent a = lot of silly > requirements. >=20 > >From an aesthetic point of view, I think it's bad that there are two = SI values (0 > and 1) that cannot be used. >=20 > The real requirement, IMO, is that no device decrements 0 and forwards = NSH. > Since only SFs decrement SI, only SFs need to do this check. >=20 > And any discussion about buggy SFs... well there is a lot of bad stuff = that bugs can > cause. >=20 >=20 >=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, February 09, 2017 2:54 PM > To: Ron Parker; Dave Dolson > Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); James N Guichard; > Fabricio Ferraz > Subject: Re: [sfc] NSH Service Index Decrement >=20 > From my perspective as an individual participant in this work, > declaring that 0 must be dropped is a matter of robustness. >=20 > if we allow 0 to be processed for exit at an SFF, then a = mis-configured > SFF could easily continue processing such a packet. Now, it is true > that TTL will eventually drop it, but that is an expensive fallback. >=20 > More importantly, presumably the next entitiy down the incorrect path > would drop it for a 255 SI. But at that point we are getting the = error > in the wrong place, making it harder to diagnose and repair. >=20 > Yours, > Joel >=20 > On 2/9/17 12:42 PM, Ron Parker wrote: > > agree. > > > > On Feb 9, 2017, at 12:28 PM, Dave Dolson > > wrote: > > > >> I'm not clear on why this is broken, or why this restriction is = made. > >> > >> I agree it should not be sent to an SF, but an SFF could map an SI = of > >> zero into a path termination. > >> > >> I.e., the last SF in a path could decrement SI from 1 to 0, and the > >> SFF could then terminate the chain. > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N = Guichard > >> *Sent:* Thursday, February 09, 2017 12:02 PM > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; > >> Eric C Rosen; sfc@ietf.org > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Not exactly. Section 3.3 specifies "The value zero for SI is not = valid > >> and indicates a broken SFC or malfunctioning SF" .. In other words = an > >> SF should never receive an NSH packet with SI =3D 0. Note that if = this > >> happened then either a) a classifier set the SI incorrectly, or b) = a > >> re-classifier set the SI incorrectly, or c) an upstream SF set the = SI > >> incorrectly; all of these cases should be caught by the SFF whose = job > >> it is to discard NSH packets with SI =3D 0. > >> > >> > >> > >> Jim > >> > >> > >> > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >> *Sent:* Thursday, February 09, 2017 11:49 AM > >> *To:* James N Guichard >> >; Dolganow, Andrew (Nokia - = SG) > >> >; > Dave > >> Dolson >; Eric C > >> Rosen >; = sfc@ietf.org > >> > >> *Subject:* RE: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Hi Jim, > >> > >> Thanks. > >> > >> > >> > >> One more question about the SI. > >> > >> > >> > >> Section 3 states that: > >> > >> > >> > >> Service Index (SI): provides location within the SFP. The initial > >> classifier MUST set the appropriate SI value for a given > >> classification result. The initial SI value SHOULD default to 255. > >> However, the classifier MUST allow configuration of other SI = values. > >> > >> Service Index MUST be decremented by Service Functions or by SFC = Proxy > >> nodes after performing required services and the new decremented SI > >> value MUST be used in the egress NSH packet. > >> > >> The initial Classifier MUST send the packet to the first SFF in the > >> identified SFP for forwarding along an SFP. > >> > >> If re-classification occurs, and that re-classification results in = a > >> new SPI, the (re)classifier is, in effect, the initial classifier = for > >> the resultant SPI. > >> > >> > >> > >> Thus: > >> > >> a) Initial SI value should be 255 but other values can be > >> configured by the classifier. > >> > >> b) SF decrements the SI value on the egress NSH packet > >> > >> c) If re-classification occurs with new SPI, the = re-classifier > >> is the initial classifier, so by a), SI should be again 255 or = other > >> value > >> > >> > >> > >> So any SI value can be receive by an SF, even 1 or 0 because: > >> > >> =E8If SI=3D1 and there is no re-classification, the egress NSH will = have SI=3D0 > >> > >> =E8If SI=3D0 and there is re-classification with new SPI, the = egress NSH > >> will have a new SPI and a SI=3D 255 or other value, as stated in = a). > >> > >> =E8If SI=3D0 and there is no re-classification the SF should = discard the > >> packet > >> > >> > >> > >> Also an SFF should forward/handle packets with NSH with SI=3D1 or = SI=3D0. > >> > >> > >> > >> Do you agree? > >> > >> > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N = Guichard > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; > >> Eric C Rosen; sfc@ietf.org > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Hi Fabricio, > >> > >> > >> > >> Welcome! > >> > >> > >> > >> Yes, removal of NSH is the responsibility of an SFF or a = re-classifier > >> (section 4, bullet point 1 lays this out). With the current > >> architecture the SF does not care what SI value it gets, it just = needs > >> to worry about decrementing it, and leave it up to the SFF to = evaluate > >> the SI value and associated action. > >> > >> > >> > >> Jim > >> > >> > >> > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >> *Sent:* Thursday, February 09, 2017 7:13 AM > >> *To:* Dolganow, Andrew (Nokia - SG) >> >; Dave Dolson > >> >; Eric C Rosen >> >; James N Guichard > >> >; > >> sfc@ietf.org > >> *Subject:* RE: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Hi all, > >> > >> I'm new here (just read the draft last week) but according to = chapter > >> 4 (check figure 8 for example), an SF is not allowed to insert or > >> remove NSH. The removal of NSH is reponsability of the SSF, right? > >> > >> > >> > >> Figure 8 maps each of the four actions above to the components in = the > >> > >> SFC architecture that can perform it. > >> > >> > >> > >> = +---------------+------------------+-------+----------------+---------+ > >> > >> | | Insert |Select | Update = |Service | > >> > >> | | or remove NSH |Service| NSH |policy = | > >> > >> | | |Function| = |selection| > >> > >> | Component +--------+--------+Path +----------------+ = | > >> > >> | | | | | Dec. |Update | = | > >> > >> | | Insert | Remove | |Service |Context| = | > >> > >> | | | | | Index |Header | = | > >> > >> = +----------------+--------+--------+-------+--------+-------+---------+ > >> > >> | | + | + | | | + | = | > >> > >> |Classifier | | | | | | = | > >> > >> +--------------- = +--------+--------+-------+--------+-------+---------+ > >> > >> |Service Function| | + | + | | | = | > >> > >> |Forwarder(SFF) | | | | | | = | > >> > >> +--------------- = +--------+--------+-------+--------+-------+---------+ > >> > >> |Service | | | | + | + | + = | > >> > >> |Function (SF) | | | | | | = | > >> > >> +--------------- = +--------+--------+-------+--------+-------+---------+ > >> > >> |SFC Proxy | + | + | | + | | = | > >> > >> = +----------------+--------+--------+-------+--------+-------+---------+ > >> > >> > >> > >> Figure 8: NSH Action and Role Mapping > >> > >> > >> > >> > >> > >> An SF could receive an NSH packet with an SI of 1, and reclassify = it > >> to a different SPI and SI, right? So when a SF receives a NSH = packet > >> with SI =3D 1 that does not necessarily means a non valid packet. > >> > >> And that can even work for SI=3D0, since you decrement the SI in = the egress. > >> > >> > >> > >> Fabricio > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, > >> Andrew (Nokia - SG) > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > >> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org > >> > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> I assumed that if we get value 1 we process then forward without = NSH > >> header (i.e.) this is the last SF processing. > >> > >> > >> > >> So with that assumption, a more explicit text would be: > >> > >> > >> > >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST = decrement > >> the SI by 1 after performing all required local processing and = before > >> forwarding the packet to the next SFF. If the resulting SI is 0, = the > >> SF MUST remove the NSH header before forwarding the packet. > >> > >> > >> > >> Andrew > >> > >> *From: *sfc > on > >> behalf of Dave Dolson > > >> *Date: *Thursday, February 9, 2017 at 2:04 AM > >> *To: *Eric Rosen >, > >> James N Guichard >> >, "sfc@ietf.org > >> " > > >> *Subject: *Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Eric, > >> > >> I was never quite happy with the outcome that neither 0 nor 1 is a > >> valid SI. > >> > >> (Because if received with value of 1, it is decremented and = discarded.) > >> > >> > >> > >> It seems to waste an index value. > >> > >> > >> > >> I guess I'm interested to know if that is important to other > >> implementers, or if that was even the intention? > >> > >> > >> > >> > >> > >> -Dave > >> > >> > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C = Rosen > >> *Sent:* Wednesday, February 08, 2017 11:53 AM > >> *To:* James N Guichard; sfc@ietf.org > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> On 2/7/2017 2:24 PM, James N Guichard wrote: > >> > >> A request was made to be more specific and update the text as = follows: > >> > >> > >> > >> "Service index MUST be decremented *by a value of 1* by Service > >> Functions or by SFC Proxy nodes after performing required services = ." > >> > >> > >> A couple of observations: > >> > >> - The term "SFC Proxy node" is not defined in either the NSH draft = or > >> in RFC 7665. I think the intention here is to say "SFC Proxy". > >> > >> - Is the intention that the SI remain unchanged while the SF is > >> operating on the packet, or is the intention only that the SI be > >> decremented before the packet is delivered by the SF or SFC Proxy = to > >> an SFF? > >> > >> I'd suggest either: > >> > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >> decrement the SI by 1 before delivering the packet to the next SFF" > >> > >> or > >> > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >> decrement the SI by 1 before delivering the packet to the next SFF, > >> but not until the SF has finished all its other processing of the = packet" > >> > >> depending upon which is intended. > >> > >> I think an implication of these procedures is that an SI value of 1 = is > >> not valid. If an SF gets an NSH packet with an SI of 1, the SF = will > >> decrement the SI (setting it to 0), send the packet to an SFF, and = the > >> SFF will discard it, because 0 is an invalid SI value. Is that the > >> intention? > >> > >> The draft makes it clear (well, sort of) that an SFF should discard = a > >> packet with an SI of 0, but does not seem to say that an SF or SFC > >> Proxy should discard a packet it receives with an SI of 0. It = would > >> probably be a good idea to say that. > >> > >> Some text in the draft (e.g., section 7.1) states than an SFF = should > >> discard a packet with an SI of zero, but other text in the draft > >> (e.g., section 3.3) only says that an SFF should log an error if it > >> sees an SI of zero. It's probably best to change the text in 3.3. = to > >> say "SHOULD generate an error/log message and MUST discard the > >> packet", or something similar. > >> > >> _______________________________________________ > >> 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 > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 10 14:26:11 2017 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 C8BE9129CB6 for ; Fri, 10 Feb 2017 14:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 ygz0FMG22a_h for ; Fri, 10 Feb 2017 14:26:07 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF35129C95 for ; Fri, 10 Feb 2017 14:26:07 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 17:26:05 -0500 From: Dave Dolson To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , 'Ron Parker' Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA3q0iAAAgj/lAAHXyRAAAH1qCQAAPaRoAAAM/fAAAAeleAAAmxtlD//72uAIAAJKYAgABEBwCAAO/9AP//z6Ig Date: Fri, 10 Feb 2017 22:26:04 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> In-Reply-To: <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , 'James N Guichard' , "'Dolganow, Andrew \(Nokia - SG\)'" , 'Eric C Rosen' , 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 22:26:09 -0000 Adrian, I think I agree with everything you said. But you did not suggest whether or not you think that SI=3D0 should be vali= d on the wire. I'm saying it could work, if the next hop is a path terminus. If I understand Joel correctly, he says we shouldn't send SI=3D0 in case t= he next hop blindly decrements it. --> this seems to mean SI=3D1 cannot be used except at the terminus or when= the SF is expected to drop all packets. So I think this is an unnecessary seat belt, trying to anticipate bugs in d= own-stream devices. I realize the current language has been there a long time, and if it is imp= ortant to anyone then it should remain. Nonetheless, I think devices could safely handle SI=3D0 on the wire without= breaking anything. But I'm not pushing for a change, since the current behavior seems importan= t to some. -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, February 10, 2017 9:16 AM To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; 'James N= Guichard'; 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement Oh, you finally pushed me into this discussion, Dave. We're building a protocol. with a protocol, you cannot (must not) assume go= od behavior from your neighbor. So if the SF touches the SI (which it does) we must define the edge conditi= ons.=20 If it is the SF's job to decrement the SI, then we must also define what it= does when SI=3D0 (otherwise, it will set SI to 0-1). If the SF is not allowed to decrement the SI below zero (which makes sense)= we must define what it must do. Since SFs are allowed to drop packets (indeed that is one of their main job= s ;-) then this would be fine. All that would be left is to define whether they apply the test before or a= fter normal processing. As an aside, I agree with Don that TTL helps relax this a little, but does = not get us all the way there. Cheers, Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: 09 February 2017 21:00 > To: Joel M. Halpern; Ron Parker > Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C Rosen; Dolgan= ow, > Andrew (Nokia - SG) > Subject: Re: [sfc] NSH Service Index Decrement >=20 > Discussing misconfigured SFFs is a straw-man argument. Once one starts tr= ying to > anticipate down-stream devices being misconfigured, one can invent a lot = of silly > requirements. >=20 > >From an aesthetic point of view, I think it's bad that there are two SI values (0 > and 1) that cannot be used. >=20 > The real requirement, IMO, is that no device decrements 0 and forwards NS= H. > Since only SFs decrement SI, only SFs need to do this check. >=20 > And any discussion about buggy SFs... well there is a lot of bad stuff th= at bugs can > cause. >=20 >=20 >=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, February 09, 2017 2:54 PM > To: Ron Parker; Dave Dolson > Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); James N Guichard; > Fabricio Ferraz > Subject: Re: [sfc] NSH Service Index Decrement >=20 > From my perspective as an individual participant in this work, > declaring that 0 must be dropped is a matter of robustness. >=20 > if we allow 0 to be processed for exit at an SFF, then a mis-configured > SFF could easily continue processing such a packet. Now, it is true > that TTL will eventually drop it, but that is an expensive fallback. >=20 > More importantly, presumably the next entitiy down the incorrect path > would drop it for a 255 SI. But at that point we are getting the error > in the wrong place, making it harder to diagnose and repair. >=20 > Yours, > Joel >=20 > On 2/9/17 12:42 PM, Ron Parker wrote: > > agree. > > > > On Feb 9, 2017, at 12:28 PM, Dave Dolson > > wrote: > > > >> I'm not clear on why this is broken, or why this restriction is made. > >> > >> I agree it should not be sent to an SF, but an SFF could map an SI of > >> zero into a path termination. > >> > >> I.e., the last SF in a path could decrement SI from 1 to 0, and the > >> SFF could then terminate the chain. > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N Guicha= rd > >> *Sent:* Thursday, February 09, 2017 12:02 PM > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; > >> Eric C Rosen; sfc@ietf.org > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Not exactly. Section 3.3 specifies "The value zero for SI is not valid > >> and indicates a broken SFC or malfunctioning SF" .. In other words an > >> SF should never receive an NSH packet with SI =3D 0. Note that if this > >> happened then either a) a classifier set the SI incorrectly, or b) a > >> re-classifier set the SI incorrectly, or c) an upstream SF set the SI > >> incorrectly; all of these cases should be caught by the SFF whose job > >> it is to discard NSH packets with SI =3D 0. > >> > >> > >> > >> Jim > >> > >> > >> > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >> *Sent:* Thursday, February 09, 2017 11:49 AM > >> *To:* James N Guichard >> >; Dolganow, Andrew (Nokia - SG) > >> >; > Dave > >> Dolson >; Eric C > >> Rosen >; sfc@ietf.org > >> > >> *Subject:* RE: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Hi Jim, > >> > >> Thanks. > >> > >> > >> > >> One more question about the SI. > >> > >> > >> > >> Section 3 states that: > >> > >> > >> > >> Service Index (SI): provides location within the SFP. The initial > >> classifier MUST set the appropriate SI value for a given > >> classification result. The initial SI value SHOULD default to 255. > >> However, the classifier MUST allow configuration of other SI values. > >> > >> Service Index MUST be decremented by Service Functions or by SFC Proxy > >> nodes after performing required services and the new decremented SI > >> value MUST be used in the egress NSH packet. > >> > >> The initial Classifier MUST send the packet to the first SFF in the > >> identified SFP for forwarding along an SFP. > >> > >> If re-classification occurs, and that re-classification results in a > >> new SPI, the (re)classifier is, in effect, the initial classifier for > >> the resultant SPI. > >> > >> > >> > >> Thus: > >> > >> a) Initial SI value should be 255 but other values can be > >> configured by the classifier. > >> > >> b) SF decrements the SI value on the egress NSH packet > >> > >> c) If re-classification occurs with new SPI, the re-classifier > >> is the initial classifier, so by a), SI should be again 255 or other > >> value > >> > >> > >> > >> So any SI value can be receive by an SF, even 1 or 0 because: > >> > >> =E8If SI=3D1 and there is no re-classification, the egress NSH will ha= ve SI=3D0 > >> > >> =E8If SI=3D0 and there is re-classification with new SPI, the egress N= SH > >> will have a new SPI and a SI=3D 255 or other value, as stated in a). > >> > >> =E8If SI=3D0 and there is no re-classification the SF should discard t= he > >> packet > >> > >> > >> > >> Also an SFF should forward/handle packets with NSH with SI=3D1 or SI= =3D0. > >> > >> > >> > >> Do you agree? > >> > >> > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N Guicha= rd > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; > >> Eric C Rosen; sfc@ietf.org > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Hi Fabricio, > >> > >> > >> > >> Welcome! > >> > >> > >> > >> Yes, removal of NSH is the responsibility of an SFF or a re-classifier > >> (section 4, bullet point 1 lays this out). With the current > >> architecture the SF does not care what SI value it gets, it just needs > >> to worry about decrementing it, and leave it up to the SFF to evaluate > >> the SI value and associated action. > >> > >> > >> > >> Jim > >> > >> > >> > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >> *Sent:* Thursday, February 09, 2017 7:13 AM > >> *To:* Dolganow, Andrew (Nokia - SG) >> >; Dave Dolson > >> >; Eric C Rosen >> >; James N Guichard > >> >; > >> sfc@ietf.org > >> *Subject:* RE: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Hi all, > >> > >> I'm new here (just read the draft last week) but according to chapter > >> 4 (check figure 8 for example), an SF is not allowed to insert or > >> remove NSH. The removal of NSH is reponsability of the SSF, right? > >> > >> > >> > >> Figure 8 maps each of the four actions above to the components in th= e > >> > >> SFC architecture that can perform it. > >> > >> > >> > >> +---------------+------------------+-------+----------------+---------= + > >> > >> | | Insert |Select | Update |Service = | > >> > >> | | or remove NSH |Service| NSH |policy = | > >> > >> | | |Function| |selection= | > >> > >> | Component +--------+--------+Path +----------------+ = | > >> > >> | | | | | Dec. |Update | = | > >> > >> | | Insert | Remove | |Service |Context| = | > >> > >> | | | | | Index |Header | = | > >> > >> +----------------+--------+--------+-------+--------+-------+---------= + > >> > >> | | + | + | | | + | = | > >> > >> |Classifier | | | | | | = | > >> > >> +--------------- +--------+--------+-------+--------+-------+---------= + > >> > >> |Service Function| | + | + | | | = | > >> > >> |Forwarder(SFF) | | | | | | = | > >> > >> +--------------- +--------+--------+-------+--------+-------+---------= + > >> > >> |Service | | | | + | + | + = | > >> > >> |Function (SF) | | | | | | = | > >> > >> +--------------- +--------+--------+-------+--------+-------+---------= + > >> > >> |SFC Proxy | + | + | | + | | = | > >> > >> +----------------+--------+--------+-------+--------+-------+---------= + > >> > >> > >> > >> Figure 8: NSH Action and Role Mapping > >> > >> > >> > >> > >> > >> An SF could receive an NSH packet with an SI of 1, and reclassify it > >> to a different SPI and SI, right? So when a SF receives a NSH packet > >> with SI =3D 1 that does not necessarily means a non valid packet. > >> > >> And that can even work for SI=3D0, since you decrement the SI in the e= gress. > >> > >> > >> > >> Fabricio > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, > >> Andrew (Nokia - SG) > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > >> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org > >> > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> I assumed that if we get value 1 we process then forward without NSH > >> header (i.e.) this is the last SF processing. > >> > >> > >> > >> So with that assumption, a more explicit text would be: > >> > >> > >> > >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST decrement > >> the SI by 1 after performing all required local processing and before > >> forwarding the packet to the next SFF. If the resulting SI is 0, the > >> SF MUST remove the NSH header before forwarding the packet. > >> > >> > >> > >> Andrew > >> > >> *From: *sfc > on > >> behalf of Dave Dolson > > >> *Date: *Thursday, February 9, 2017 at 2:04 AM > >> *To: *Eric Rosen >, > >> James N Guichard >> >, "sfc@ietf.org > >> " > > >> *Subject: *Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> Eric, > >> > >> I was never quite happy with the outcome that neither 0 nor 1 is a > >> valid SI. > >> > >> (Because if received with value of 1, it is decremented and discarded.= ) > >> > >> > >> > >> It seems to waste an index value. > >> > >> > >> > >> I guess I'm interested to know if that is important to other > >> implementers, or if that was even the intention? > >> > >> > >> > >> > >> > >> -Dave > >> > >> > >> > >> > >> > >> > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C Rosen > >> *Sent:* Wednesday, February 08, 2017 11:53 AM > >> *To:* James N Guichard; sfc@ietf.org > >> *Subject:* Re: [sfc] NSH Service Index Decrement > >> > >> > >> > >> On 2/7/2017 2:24 PM, James N Guichard wrote: > >> > >> A request was made to be more specific and update the text as follows: > >> > >> > >> > >> "Service index MUST be decremented *by a value of 1* by Service > >> Functions or by SFC Proxy nodes after performing required services ." > >> > >> > >> A couple of observations: > >> > >> - The term "SFC Proxy node" is not defined in either the NSH draft or > >> in RFC 7665. I think the intention here is to say "SFC Proxy". > >> > >> - Is the intention that the SI remain unchanged while the SF is > >> operating on the packet, or is the intention only that the SI be > >> decremented before the packet is delivered by the SF or SFC Proxy to > >> an SFF? > >> > >> I'd suggest either: > >> > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >> decrement the SI by 1 before delivering the packet to the next SFF" > >> > >> or > >> > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >> decrement the SI by 1 before delivering the packet to the next SFF, > >> but not until the SF has finished all its other processing of the pack= et" > >> > >> depending upon which is intended. > >> > >> I think an implication of these procedures is that an SI value of 1 is > >> not valid. If an SF gets an NSH packet with an SI of 1, the SF will > >> decrement the SI (setting it to 0), send the packet to an SFF, and the > >> SFF will discard it, because 0 is an invalid SI value. Is that the > >> intention? > >> > >> The draft makes it clear (well, sort of) that an SFF should discard a > >> packet with an SI of 0, but does not seem to say that an SF or SFC > >> Proxy should discard a packet it receives with an SI of 0. It would > >> probably be a good idea to say that. > >> > >> Some text in the draft (e.g., section 7.1) states than an SFF should > >> discard a packet with an SI of zero, but other text in the draft > >> (e.g., section 3.3) only says that an SFF should log an error if it > >> sees an SI of zero. It's probably best to change the text in 3.3. to > >> say "SHOULD generate an error/log message and MUST discard the > >> packet", or something similar. > >> > >> _______________________________________________ > >> 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 > > >=20 > _______________________________________________ > 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 Sat Feb 11 08:35:35 2017 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 7C72812999B for ; Sat, 11 Feb 2017 08:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Bh8YsR1NWyyn for ; Sat, 11 Feb 2017 08:35:30 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EE11299A5 for ; Sat, 11 Feb 2017 08:35:29 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1BGZEoj015105; Sat, 11 Feb 2017 16:35:14 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1BGYG9b014618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Feb 2017 16:34:19 GMT From: "Adrian Farrel" To: "'Dave Dolson'" , "'Joel M. Halpern'" , "'Ron Parker'" References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> In-Reply-To: Date: Sat, 11 Feb 2017 16:34:13 -0000 Message-ID: <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHoYgY6PCVGpHJ8su3f5ejQO2dmKAIvwOccAgx3iLoAvuXz6QHh04WVAzglJZACFiSEIwEdT5qdAIUzmAMCaf1/yQGATjGeAl0zdEQCPzPO+wHoN6HvoHZc4UA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22880.001 X-TM-AS-Result: No--25.926-10.0-31-10 X-imss-scan-details: No--25.926-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtHRhEyb9f1sjuLdprnA5EQR6Jj6zYvfFATYWrp179pohhch drJv3xSnDYFYDnrNzRHvtz37g23iTY4u/jRKGvdJliwpJdZauwep8u/TGEilnORmz46Q29bDbkn 3xR5v5YzmNZ9/A96drIJc8Wq3RD3AFD3JSuCj3OBoMLOoNHsM9rd2noO4P7rALraGNlLRahhRnX K6Gty1M9FGUitsKxBq/L8z/Umqq0v1Ht3BefL9t521GZGE81yGGSqdEmeD/nWTMTaQzhvoesUOt 6MQjmDgO1yqr9ePf+Z0wYWIMUF1GXOAMSqhBqB66ivQ8oO6nULL0ev0kxsIkwQ1GIp3iMkzkKbV KhmQLFNvgkneme+Cc9fExB5dOJF+Qf9HervnKxzAJnGRMfFxyUNtJmIgIBFJauHKE5Laxl9Hq1N Wihv9eGY3CAhRDZ97vcWRCcoyafBqmLL8gk3wAoxVBvj1jbcjBcCEAZkHsGdiZCTkFQiKcNLQxt Z8WmAAkSqH+Kc9BkKtVkE9lsgUSWshUcIcH/7pkEo3TadHJjDEGBoHKd3a+Vvym/gvSH4ijDgWS lWnSNe0wSlQXuSmJoaU3UCHk7q3Gj8XjDB40G4R7kPXQyW0tn4rryovYbmmfTR2kOonlIGG0xrf Kr0fl5Juj05Xh1XarLrHx8shLho25Mb4M8J09vVFR4sC8dPyEtdrY/Wb3fPxxaAXDrCnswe0jlR IZ0jupijGtm75xl5Wz2eiIuWGmuUv8ayIKAgLfKmN9+B2Aw+FXSyuOiq3H4Sud44w9uOaO6MSX7 i8zf+N4jR8euxc6opgZhu1vxyDBb95QfAlOsieAiCmPx4NwGNn8XPiALIbooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: Cc: sfc@ietf.org, 'James N Guichard' , "'Dolganow, Andrew \(Nokia - SG\)'" , 'Eric C Rosen' , 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 16:35:33 -0000 I hate to do my impersonation of Eric, but... "On the wire" is the crunch. Some have said that there must be no visible difference between the = three case: - on the wire between SFF and SF - on the wire between SF and SFF - on the wire between SFF and SFF If this holds then you are correct that sending SI=3D1 in the first case = requires the SF to do more than a simple decrement (although decrement and = discard is hardly painful). And it means that SI=3D1 is a dubious value in an SFP. On the other hand, we appear to be clear about an SF that strips the NSH = and forwards the traffic as native : this is currently forbidden. So there = is no alternative for an SF receiving SI=3D1 except to discard the packet. Now, does that mean that an SFF should never send a packet with SI=3D1? = Well, possibly it is OK for a few specialist SFs intended to sit at the end of = the chain and be a bit bucket with analysis. But, for most SFs there would = be no point. Maybe (just maybe) we should stop letting the tail wag the dog! That is, = let's decide on the functional behavior we want to see and then design the = protocol to match. Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 10 February 2017 22:26 > To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; = 'James N > Guichard'; 'Fabricio Ferraz' > Subject: RE: [sfc] NSH Service Index Decrement >=20 > Adrian, > I think I agree with everything you said. > But you did not suggest whether or not you think that SI=3D0 should be = valid on the > wire. > I'm saying it could work, if the next hop is a path terminus. >=20 > If I understand Joel correctly, he says we shouldn't send SI=3D0 in = case the next > hop blindly decrements it. > --> this seems to mean SI=3D1 cannot be used except at the terminus or = when the > SF is expected to drop all packets. > So I think this is an unnecessary seat belt, trying to anticipate bugs = in down- > stream devices. >=20 > I realize the current language has been there a long time, and if it = is important to > anyone then it should remain. > Nonetheless, I think devices could safely handle SI=3D0 on the wire = without > breaking anything. >=20 > But I'm not pushing for a change, since the current behavior seems = important to > some. >=20 > -Dave >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, February 10, 2017 9:16 AM > To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; = 'James N > Guichard'; 'Fabricio Ferraz' > Subject: Re: [sfc] NSH Service Index Decrement >=20 > Oh, you finally pushed me into this discussion, Dave. >=20 > We're building a protocol. with a protocol, you cannot (must not) = assume good > behavior from your neighbor. >=20 > So if the SF touches the SI (which it does) we must define the edge conditions. > If it is the SF's job to decrement the SI, then we must also define = what it does > when SI=3D0 (otherwise, it will set SI to 0-1). > If the SF is not allowed to decrement the SI below zero (which makes = sense) we > must define what it must do. > Since SFs are allowed to drop packets (indeed that is one of their = main jobs ;-) > then this would be fine. > All that would be left is to define whether they apply the test before = or after > normal processing. >=20 > As an aside, I agree with Don that TTL helps relax this a little, but = does not > get us all the way there. >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: 09 February 2017 21:00 > > To: Joel M. Halpern; Ron Parker > > Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C Rosen; = Dolganow, > > Andrew (Nokia - SG) > > Subject: Re: [sfc] NSH Service Index Decrement > > > > Discussing misconfigured SFFs is a straw-man argument. Once one = starts trying > to > > anticipate down-stream devices being misconfigured, one can invent a = lot of > silly > > requirements. > > > > >From an aesthetic point of view, I think it's bad that there are = two SI > values (0 > > and 1) that cannot be used. > > > > The real requirement, IMO, is that no device decrements 0 and = forwards NSH. > > Since only SFs decrement SI, only SFs need to do this check. > > > > And any discussion about buggy SFs... well there is a lot of bad = stuff that > bugs can > > cause. > > > > > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Thursday, February 09, 2017 2:54 PM > > To: Ron Parker; Dave Dolson > > Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); James = N > Guichard; > > Fabricio Ferraz > > Subject: Re: [sfc] NSH Service Index Decrement > > > > From my perspective as an individual participant in this work, > > declaring that 0 must be dropped is a matter of robustness. > > > > if we allow 0 to be processed for exit at an SFF, then a = mis-configured > > SFF could easily continue processing such a packet. Now, it is true > > that TTL will eventually drop it, but that is an expensive fallback. > > > > More importantly, presumably the next entitiy down the incorrect = path > > would drop it for a 255 SI. But at that point we are getting the = error > > in the wrong place, making it harder to diagnose and repair. > > > > Yours, > > Joel > > > > On 2/9/17 12:42 PM, Ron Parker wrote: > > > agree. > > > > > > On Feb 9, 2017, at 12:28 PM, Dave Dolson > > > wrote: > > > > > >> I'm not clear on why this is broken, or why this restriction is = made. > > >> > > >> I agree it should not be sent to an SF, but an SFF could map an = SI of > > >> zero into a path termination. > > >> > > >> I.e., the last SF in a path could decrement SI from 1 to 0, and = the > > >> SFF could then terminate the chain. > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N = Guichard > > >> *Sent:* Thursday, February 09, 2017 12:02 PM > > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave = Dolson; > > >> Eric C Rosen; sfc@ietf.org > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Not exactly. Section 3.3 specifies "The value zero for SI is not = valid > > >> and indicates a broken SFC or malfunctioning SF" .. In other = words an > > >> SF should never receive an NSH packet with SI =3D 0. Note that if = this > > >> happened then either a) a classifier set the SI incorrectly, or = b) a > > >> re-classifier set the SI incorrectly, or c) an upstream SF set = the SI > > >> incorrectly; all of these cases should be caught by the SFF whose = job > > >> it is to discard NSH packets with SI =3D 0. > > >> > > >> > > >> > > >> Jim > > >> > > >> > > >> > > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >> *Sent:* Thursday, February 09, 2017 11:49 AM > > >> *To:* James N Guichard > >> >; Dolganow, Andrew (Nokia - = SG) > > >> >; > > Dave > > >> Dolson >; Eric = C > > >> Rosen >; = sfc@ietf.org > > >> > > >> *Subject:* RE: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Hi Jim, > > >> > > >> Thanks. > > >> > > >> > > >> > > >> One more question about the SI. > > >> > > >> > > >> > > >> Section 3 states that: > > >> > > >> > > >> > > >> Service Index (SI): provides location within the SFP. The initial > > >> classifier MUST set the appropriate SI value for a given > > >> classification result. The initial SI value SHOULD default to = 255. > > >> However, the classifier MUST allow configuration of other SI = values. > > >> > > >> Service Index MUST be decremented by Service Functions or by SFC = Proxy > > >> nodes after performing required services and the new decremented = SI > > >> value MUST be used in the egress NSH packet. > > >> > > >> The initial Classifier MUST send the packet to the first SFF in = the > > >> identified SFP for forwarding along an SFP. > > >> > > >> If re-classification occurs, and that re-classification results = in a > > >> new SPI, the (re)classifier is, in effect, the initial classifier = for > > >> the resultant SPI. > > >> > > >> > > >> > > >> Thus: > > >> > > >> a) Initial SI value should be 255 but other values can be > > >> configured by the classifier. > > >> > > >> b) SF decrements the SI value on the egress NSH packet > > >> > > >> c) If re-classification occurs with new SPI, the = re-classifier > > >> is the initial classifier, so by a), SI should be again 255 or = other > > >> value > > >> > > >> > > >> > > >> So any SI value can be receive by an SF, even 1 or 0 because: > > >> > > >> =E8If SI=3D1 and there is no re-classification, the egress NSH = will have SI=3D0 > > >> > > >> =E8If SI=3D0 and there is re-classification with new SPI, the = egress NSH > > >> will have a new SPI and a SI=3D 255 or other value, as stated in = a). > > >> > > >> =E8If SI=3D0 and there is no re-classification the SF should = discard the > > >> packet > > >> > > >> > > >> > > >> Also an SFF should forward/handle packets with NSH with SI=3D1 or = SI=3D0. > > >> > > >> > > >> > > >> Do you agree? > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N = Guichard > > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave = Dolson; > > >> Eric C Rosen; sfc@ietf.org > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Hi Fabricio, > > >> > > >> > > >> > > >> Welcome! > > >> > > >> > > >> > > >> Yes, removal of NSH is the responsibility of an SFF or a = re-classifier > > >> (section 4, bullet point 1 lays this out). With the current > > >> architecture the SF does not care what SI value it gets, it just = needs > > >> to worry about decrementing it, and leave it up to the SFF to = evaluate > > >> the SI value and associated action. > > >> > > >> > > >> > > >> Jim > > >> > > >> > > >> > > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >> *Sent:* Thursday, February 09, 2017 7:13 AM > > >> *To:* Dolganow, Andrew (Nokia - SG) > >> >; Dave Dolson > > > >> >; Eric C Rosen > >> >; James N Guichard > > >> >; > > >> sfc@ietf.org > > >> *Subject:* RE: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Hi all, > > >> > > >> I'm new here (just read the draft last week) but according to = chapter > > >> 4 (check figure 8 for example), an SF is not allowed to insert or > > >> remove NSH. The removal of NSH is reponsability of the SSF, = right? > > >> > > >> > > >> > > >> Figure 8 maps each of the four actions above to the components = in the > > >> > > >> SFC architecture that can perform it. > > >> > > >> > > >> > > >> = +---------------+------------------+-------+----------------+---------+ > > >> > > >> | | Insert |Select | Update = |Service | > > >> > > >> | | or remove NSH |Service| NSH = |policy | > > >> > > >> | | |Function| = |selection| > > >> > > >> | Component +--------+--------+Path +----------------+ = | > > >> > > >> | | | | | Dec. |Update | = | > > >> > > >> | | Insert | Remove | |Service |Context| = | > > >> > > >> | | | | | Index |Header | = | > > >> > > >> = +----------------+--------+--------+-------+--------+-------+---------+ > > >> > > >> | | + | + | | | + | = | > > >> > > >> |Classifier | | | | | | = | > > >> > > >> +--------------- = +--------+--------+-------+--------+-------+---------+ > > >> > > >> |Service Function| | + | + | | | = | > > >> > > >> |Forwarder(SFF) | | | | | | = | > > >> > > >> +--------------- = +--------+--------+-------+--------+-------+---------+ > > >> > > >> |Service | | | | + | + | + = | > > >> > > >> |Function (SF) | | | | | | = | > > >> > > >> +--------------- = +--------+--------+-------+--------+-------+---------+ > > >> > > >> |SFC Proxy | + | + | | + | | = | > > >> > > >> = +----------------+--------+--------+-------+--------+-------+---------+ > > >> > > >> > > >> > > >> Figure 8: NSH Action and Role Mapping > > >> > > >> > > >> > > >> > > >> > > >> An SF could receive an NSH packet with an SI of 1, and reclassify = it > > >> to a different SPI and SI, right? So when a SF receives a NSH = packet > > >> with SI =3D 1 that does not necessarily means a non valid packet. > > >> > > >> And that can even work for SI=3D0, since you decrement the SI in = the egress. > > >> > > >> > > >> > > >> Fabricio > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, > > >> Andrew (Nokia - SG) > > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > > >> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org > > >> > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> I assumed that if we get value 1 we process then forward without = NSH > > >> header (i.e.) this is the last SF processing. > > >> > > >> > > >> > > >> So with that assumption, a more explicit text would be: > > >> > > >> > > >> > > >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST = decrement > > >> the SI by 1 after performing all required local processing and = before > > >> forwarding the packet to the next SFF. If the resulting SI is 0, = the > > >> SF MUST remove the NSH header before forwarding the packet. > > >> > > >> > > >> > > >> Andrew > > >> > > >> *From: *sfc > = on > > >> behalf of Dave Dolson > > > > >> *Date: *Thursday, February 9, 2017 at 2:04 AM > > >> *To: *Eric Rosen >, > > >> James N Guichard > >> >, "sfc@ietf.org > > >> " > > > >> *Subject: *Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Eric, > > >> > > >> I was never quite happy with the outcome that neither 0 nor 1 is = a > > >> valid SI. > > >> > > >> (Because if received with value of 1, it is decremented and = discarded.) > > >> > > >> > > >> > > >> It seems to waste an index value. > > >> > > >> > > >> > > >> I guess I'm interested to know if that is important to other > > >> implementers, or if that was even the intention? > > >> > > >> > > >> > > >> > > >> > > >> -Dave > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C = Rosen > > >> *Sent:* Wednesday, February 08, 2017 11:53 AM > > >> *To:* James N Guichard; sfc@ietf.org > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> On 2/7/2017 2:24 PM, James N Guichard wrote: > > >> > > >> A request was made to be more specific and update the text as = follows: > > >> > > >> > > >> > > >> "Service index MUST be decremented *by a value of 1* by Service > > >> Functions or by SFC Proxy nodes after performing required = services ." > > >> > > >> > > >> A couple of observations: > > >> > > >> - The term "SFC Proxy node" is not defined in either the NSH = draft or > > >> in RFC 7665. I think the intention here is to say "SFC Proxy". > > >> > > >> - Is the intention that the SI remain unchanged while the SF is > > >> operating on the packet, or is the intention only that the SI be > > >> decremented before the packet is delivered by the SF or SFC Proxy = to > > >> an SFF? > > >> > > >> I'd suggest either: > > >> > > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > >> decrement the SI by 1 before delivering the packet to the next = SFF" > > >> > > >> or > > >> > > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > >> decrement the SI by 1 before delivering the packet to the next = SFF, > > >> but not until the SF has finished all its other processing of the = packet" > > >> > > >> depending upon which is intended. > > >> > > >> I think an implication of these procedures is that an SI value of = 1 is > > >> not valid. If an SF gets an NSH packet with an SI of 1, the SF = will > > >> decrement the SI (setting it to 0), send the packet to an SFF, = and the > > >> SFF will discard it, because 0 is an invalid SI value. Is that = the > > >> intention? > > >> > > >> The draft makes it clear (well, sort of) that an SFF should = discard a > > >> packet with an SI of 0, but does not seem to say that an SF or = SFC > > >> Proxy should discard a packet it receives with an SI of 0. It = would > > >> probably be a good idea to say that. > > >> > > >> Some text in the draft (e.g., section 7.1) states than an SFF = should > > >> discard a packet with an SI of zero, but other text in the draft > > >> (e.g., section 3.3) only says that an SFF should log an error if = it > > >> sees an SI of zero. It's probably best to change the text in = 3.3. to > > >> say "SHOULD generate an error/log message and MUST discard the > > >> packet", or something similar. > > >> > > >> _______________________________________________ > > >> 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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Feb 11 08:55:13 2017 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 E708E1299F0 for ; Sat, 11 Feb 2017 08:55:11 -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, 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 nG0y5OtoJikE for ; Sat, 11 Feb 2017 08:55:08 -0800 (PST) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5370512941A for ; Sat, 11 Feb 2017 08:55:08 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0319.002; Sat, 11 Feb 2017 08:55:07 -0800 From: Ron Parker To: "adrian@olddog.co.uk" , 'Dave Dolson' , "'Joel M. Halpern'" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkAAeZjIw//6oW4D//33gw4AAqsEAgAASngCAASFmAIAAiOAAgAEwB4CAAIMaAA== Date: Sat, 11 Feb 2017 16:55:06 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> In-Reply-To: <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [100.0.27.181] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , 'James N Guichard' , "'Dolganow, Andrew \(Nokia - SG\)'" , 'Eric C Rosen' , 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 16:55:12 -0000 Hi, Adrian. Not the original topic, per se, but wrt your comment: * On the other hand, we appear to be clear about an SF that strips the NSH = and forwards the traffic as native : this is currently forbidden. I'm wondering how to reconcile this to a transparent HTTP Proxy that does n= ot preserve the original source-IP? Does this mean that it is mandatory f= or such an SF to also be a classifier so it can self-classify its own relat= ed flows (i.e., using its own visible IP addresses)? From SFF perspectiv= e, it would look like all packets on the access side are dropped in the ups= tream direction and injected by the SF in the downstream direction. On th= e Internet side, it would look like all packets are injected by the SF in t= he upstream direction and dropped in the downstream direction. Thanks for any clarification. Ron -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Saturday, February 11, 2017 11:34 AM To: 'Dave Dolson' ; 'Joel M. Halpern' ; Ron Parker Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - SG)' ; sfc@ietf.org; 'James N Guichard' ; 'Fabricio Ferraz' Subject: RE: [sfc] NSH Service Index Decrement I hate to do my impersonation of Eric, but... "On the wire" is the crunch. Some have said that there must be no visible difference between the three c= ase: - on the wire between SFF and SF - on the wire between SF and SFF - on the wire between SFF and SFF If this holds then you are correct that sending SI=3D1 in the first case re= quires the SF to do more than a simple decrement (although decrement and di= scard is hardly painful). And it means that SI=3D1 is a dubious value in an= SFP. On the other hand, we appear to be clear about an SF that strips the NSH an= d forwards the traffic as native : this is currently forbidden. So there is= no alternative for an SF receiving SI=3D1 except to discard the packet. Now, does that mean that an SFF should never send a packet with SI=3D1? Wel= l, possibly it is OK for a few specialist SFs intended to sit at the end of= the chain and be a bit bucket with analysis. But, for most SFs there would= be no point. Maybe (just maybe) we should stop letting the tail wag the dog! That is, le= t's decide on the functional behavior we want to see and then design the pr= otocol to match. Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 10 February 2017 22:26 > To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;=20 > 'James N Guichard'; 'Fabricio Ferraz' > Subject: RE: [sfc] NSH Service Index Decrement >=20 > Adrian, > I think I agree with everything you said. > But you did not suggest whether or not you think that SI=3D0 should be=20 > valid on the > wire. > I'm saying it could work, if the next hop is a path terminus. >=20 > If I understand Joel correctly, he says we shouldn't send SI=3D0 in=20 > case the next > hop blindly decrements it. > --> this seems to mean SI=3D1 cannot be used except at the terminus or=20 > --> when the > SF is expected to drop all packets. > So I think this is an unnecessary seat belt, trying to anticipate bugs=20 > in down- > stream devices. >=20 > I realize the current language has been there a long time, and if it=20 > is important to > anyone then it should remain. > Nonetheless, I think devices could safely handle SI=3D0 on the wire=20 > without breaking anything. >=20 > But I'm not pushing for a change, since the current behavior seems=20 > important to > some. >=20 > -Dave >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, February 10, 2017 9:16 AM > To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;=20 > 'James N Guichard'; 'Fabricio Ferraz' > Subject: Re: [sfc] NSH Service Index Decrement >=20 > Oh, you finally pushed me into this discussion, Dave. >=20 > We're building a protocol. with a protocol, you cannot (must not)=20 > assume good behavior from your neighbor. >=20 > So if the SF touches the SI (which it does) we must define the edge conditions. > If it is the SF's job to decrement the SI, then we must also define=20 > what it does > when SI=3D0 (otherwise, it will set SI to 0-1). > If the SF is not allowed to decrement the SI below zero (which makes=20 > sense) we must define what it must do. > Since SFs are allowed to drop packets (indeed that is one of their=20 > main jobs ;-) > then this would be fine. > All that would be left is to define whether they apply the test before=20 > or after > normal processing. >=20 > As an aside, I agree with Don that TTL helps relax this a little, but=20 > does not get us all the way there. >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: 09 February 2017 21:00 > > To: Joel M. Halpern; Ron Parker > > Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C Rosen;=20 > > Dolganow, Andrew (Nokia - SG) > > Subject: Re: [sfc] NSH Service Index Decrement > > > > Discussing misconfigured SFFs is a straw-man argument. Once one=20 > > starts trying > to > > anticipate down-stream devices being misconfigured, one can invent a=20 > > lot of > silly > > requirements. > > > > >From an aesthetic point of view, I think it's bad that there are=20 > > >two SI > values (0 > > and 1) that cannot be used. > > > > The real requirement, IMO, is that no device decrements 0 and forwards = NSH. > > Since only SFs decrement SI, only SFs need to do this check. > > > > And any discussion about buggy SFs... well there is a lot of bad=20 > > stuff that > bugs can > > cause. > > > > > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Thursday, February 09, 2017 2:54 PM > > To: Ron Parker; Dave Dolson > > Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); James=20 > > N > Guichard; > > Fabricio Ferraz > > Subject: Re: [sfc] NSH Service Index Decrement > > > > From my perspective as an individual participant in this work,=20 > > declaring that 0 must be dropped is a matter of robustness. > > > > if we allow 0 to be processed for exit at an SFF, then a=20 > > mis-configured SFF could easily continue processing such a packet. =20 > > Now, it is true that TTL will eventually drop it, but that is an expens= ive fallback. > > > > More importantly, presumably the next entitiy down the incorrect=20 > > path would drop it for a 255 SI. But at that point we are getting=20 > > the error in the wrong place, making it harder to diagnose and repair. > > > > Yours, > > Joel > > > > On 2/9/17 12:42 PM, Ron Parker wrote: > > > agree. > > > > > > On Feb 9, 2017, at 12:28 PM, Dave Dolson > > > wrote: > > > > > >> I'm not clear on why this is broken, or why this restriction is made= . > > >> > > >> I agree it should not be sent to an SF, but an SFF could map an=20 > > >> SI of zero into a path termination. > > >> > > >> I.e., the last SF in a path could decrement SI from 1 to 0, and=20 > > >> the SFF could then terminate the chain. > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N=20 > > >> Guichard > > >> *Sent:* Thursday, February 09, 2017 12:02 PM > > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave=20 > > >> Dolson; Eric C Rosen; sfc@ietf.org > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Not exactly. Section 3.3 specifies "The value zero for SI is not=20 > > >> valid and indicates a broken SFC or malfunctioning SF" .. In=20 > > >> other words an SF should never receive an NSH packet with SI =3D 0.= =20 > > >> Note that if this happened then either a) a classifier set the SI=20 > > >> incorrectly, or b) a re-classifier set the SI incorrectly, or c)=20 > > >> an upstream SF set the SI incorrectly; all of these cases should=20 > > >> be caught by the SFF whose job it is to discard NSH packets with SI = =3D 0. > > >> > > >> > > >> > > >> Jim > > >> > > >> > > >> > > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >> *Sent:* Thursday, February 09, 2017 11:49 AM > > >> *To:* James N Guichard > >> >; Dolganow, Andrew (Nokia -=20 > > >> SG) > >> >; > > Dave > > >> Dolson >; Eric=20 > > >> C Rosen >;=20 > > >> sfc@ietf.org > > >> *Subject:* RE: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Hi Jim, > > >> > > >> Thanks. > > >> > > >> > > >> > > >> One more question about the SI. > > >> > > >> > > >> > > >> Section 3 states that: > > >> > > >> > > >> > > >> Service Index (SI): provides location within the SFP. The initial=20 > > >> classifier MUST set the appropriate SI value for a given=20 > > >> classification result. The initial SI value SHOULD default to 255. > > >> However, the classifier MUST allow configuration of other SI values. > > >> > > >> Service Index MUST be decremented by Service Functions or by SFC=20 > > >> Proxy nodes after performing required services and the new=20 > > >> decremented SI value MUST be used in the egress NSH packet. > > >> > > >> The initial Classifier MUST send the packet to the first SFF in=20 > > >> the identified SFP for forwarding along an SFP. > > >> > > >> If re-classification occurs, and that re-classification results=20 > > >> in a new SPI, the (re)classifier is, in effect, the initial=20 > > >> classifier for the resultant SPI. > > >> > > >> > > >> > > >> Thus: > > >> > > >> a) Initial SI value should be 255 but other values can be > > >> configured by the classifier. > > >> > > >> b) SF decrements the SI value on the egress NSH packet > > >> > > >> c) If re-classification occurs with new SPI, the re-classifier > > >> is the initial classifier, so by a), SI should be again 255 or=20 > > >> other value > > >> > > >> > > >> > > >> So any SI value can be receive by an SF, even 1 or 0 because: > > >> > > >> =E8If SI=3D1 and there is no re-classification, the egress NSH will= =20 > > >> have SI=3D0 > > >> > > >> =E8If SI=3D0 and there is re-classification with new SPI, the egress= =20 > > >> NSH will have a new SPI and a SI=3D 255 or other value, as stated in= a). > > >> > > >> =E8If SI=3D0 and there is no re-classification the SF should discard= =20 > > >> the packet > > >> > > >> > > >> > > >> Also an SFF should forward/handle packets with NSH with SI=3D1 or SI= =3D0. > > >> > > >> > > >> > > >> Do you agree? > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N=20 > > >> Guichard > > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave=20 > > >> Dolson; Eric C Rosen; sfc@ietf.org > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Hi Fabricio, > > >> > > >> > > >> > > >> Welcome! > > >> > > >> > > >> > > >> Yes, removal of NSH is the responsibility of an SFF or a=20 > > >> re-classifier (section 4, bullet point 1 lays this out). With the=20 > > >> current architecture the SF does not care what SI value it gets,=20 > > >> it just needs to worry about decrementing it, and leave it up to=20 > > >> the SFF to evaluate the SI value and associated action. > > >> > > >> > > >> > > >> Jim > > >> > > >> > > >> > > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >> *Sent:* Thursday, February 09, 2017 7:13 AM > > >> *To:* Dolganow, Andrew (Nokia - SG) > >> >; Dave Dolson > > > >> >; Eric C Rosen > >> >; James N Guichard=20 > > >> >; > > >> sfc@ietf.org > > >> *Subject:* RE: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Hi all, > > >> > > >> I'm new here (just read the draft last week) but according to=20 > > >> chapter > > >> 4 (check figure 8 for example), an SF is not allowed to insert or=20 > > >> remove NSH. The removal of NSH is reponsability of the SSF, right? > > >> > > >> > > >> > > >> Figure 8 maps each of the four actions above to the components=20 > > >> in the > > >> > > >> SFC architecture that can perform it. > > >> > > >> > > >> > > >> +---------------+------------------+-------+----------------+-------= --+ > > >> > > >> | | Insert |Select | Update |Service= | > > >> > > >> | | or remove NSH |Service| NSH |policy = | > > >> > > >> | | |Function| |selecti= on| > > >> > > >> | Component +--------+--------+Path +----------------+ = | > > >> > > >> | | | | | Dec. |Update | = | > > >> > > >> | | Insert | Remove | |Service |Context| = | > > >> > > >> | | | | | Index |Header | = | > > >> > > >> +----------------+--------+--------+-------+--------+-------+-------= --+ > > >> > > >> | | + | + | | | + | = | > > >> > > >> |Classifier | | | | | | = | > > >> > > >> +---------------=20 > > >> ++--------+--------+-------+--------+-------+---------+ > > >> > > >> |Service Function| | + | + | | | = | > > >> > > >> |Forwarder(SFF) | | | | | | = | > > >> > > >> +---------------=20 > > >> ++--------+--------+-------+--------+-------+---------+ > > >> > > >> |Service | | | | + | + | + = | > > >> > > >> |Function (SF) | | | | | | = | > > >> > > >> +---------------=20 > > >> ++--------+--------+-------+--------+-------+---------+ > > >> > > >> |SFC Proxy | + | + | | + | | = | > > >> > > >> +----------------+--------+--------+-------+--------+-------+-------= --+ > > >> > > >> > > >> > > >> Figure 8: NSH Action and Role Mapping > > >> > > >> > > >> > > >> > > >> > > >> An SF could receive an NSH packet with an SI of 1, and reclassify=20 > > >> it to a different SPI and SI, right? So when a SF receives a NSH=20 > > >> packet with SI =3D 1 that does not necessarily means a non valid pac= ket. > > >> > > >> And that can even work for SI=3D0, since you decrement the SI in=20 > > >> the egress. > > >> > > >> > > >> > > >> Fabricio > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow,=20 > > >> Andrew (Nokia - SG) > > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > > >> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org=20 > > >> > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> I assumed that if we get value 1 we process then forward without=20 > > >> NSH header (i.e.) this is the last SF processing. > > >> > > >> > > >> > > >> So with that assumption, a more explicit text would be: > > >> > > >> > > >> > > >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST=20 > > >> decrement the SI by 1 after performing all required local=20 > > >> processing and before forwarding the packet to the next SFF. If=20 > > >> the resulting SI is 0, the SF MUST remove the NSH header before forw= arding the packet. > > >> > > >> > > >> > > >> Andrew > > >> > > >> *From: *sfc >=20 > > >> on behalf of Dave Dolson > > > > >> *Date: *Thursday, February 9, 2017 at 2:04 AM > > >> *To: *Eric Rosen > >> >, James N Guichard=20 > > >> > >> >, "sfc@ietf.org=20 > > >> " > > > >> *Subject: *Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Eric, > > >> > > >> I was never quite happy with the outcome that neither 0 nor 1 is=20 > > >> a valid SI. > > >> > > >> (Because if received with value of 1, it is decremented and=20 > > >> discarded.) > > >> > > >> > > >> > > >> It seems to waste an index value. > > >> > > >> > > >> > > >> I guess I'm interested to know if that is important to other=20 > > >> implementers, or if that was even the intention? > > >> > > >> > > >> > > >> > > >> > > >> -Dave > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C=20 > > >> Rosen > > >> *Sent:* Wednesday, February 08, 2017 11:53 AM > > >> *To:* James N Guichard; sfc@ietf.org > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> On 2/7/2017 2:24 PM, James N Guichard wrote: > > >> > > >> A request was made to be more specific and update the text as follow= s: > > >> > > >> > > >> > > >> "Service index MUST be decremented *by a value of 1* by Service=20 > > >> Functions or by SFC Proxy nodes after performing required services .= " > > >> > > >> > > >> A couple of observations: > > >> > > >> - The term "SFC Proxy node" is not defined in either the NSH=20 > > >> draft or in RFC 7665. I think the intention here is to say "SFC Pro= xy". > > >> > > >> - Is the intention that the SI remain unchanged while the SF is=20 > > >> operating on the packet, or is the intention only that the SI be=20 > > >> decremented before the packet is delivered by the SF or SFC Proxy=20 > > >> to an SFF? > > >> > > >> I'd suggest either: > > >> > > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST=20 > > >> decrement the SI by 1 before delivering the packet to the next SFF" > > >> > > >> or > > >> > > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST=20 > > >> decrement the SI by 1 before delivering the packet to the next=20 > > >> SFF, but not until the SF has finished all its other processing of t= he packet" > > >> > > >> depending upon which is intended. > > >> > > >> I think an implication of these procedures is that an SI value of=20 > > >> 1 is not valid. If an SF gets an NSH packet with an SI of 1, the=20 > > >> SF will decrement the SI (setting it to 0), send the packet to an=20 > > >> SFF, and the SFF will discard it, because 0 is an invalid SI=20 > > >> value. Is that the intention? > > >> > > >> The draft makes it clear (well, sort of) that an SFF should=20 > > >> discard a packet with an SI of 0, but does not seem to say that=20 > > >> an SF or SFC Proxy should discard a packet it receives with an SI=20 > > >> of 0. It would probably be a good idea to say that. > > >> > > >> Some text in the draft (e.g., section 7.1) states than an SFF=20 > > >> should discard a packet with an SI of zero, but other text in the=20 > > >> draft (e.g., section 3.3) only says that an SFF should log an=20 > > >> error if it sees an SI of zero. It's probably best to change the=20 > > >> text in 3.3. to say "SHOULD generate an error/log message and=20 > > >> MUST discard the packet", or something similar. > > >> > > >> _______________________________________________ > > >> sfc mailing list > > >> sfc@ietf.org =20 > > >> 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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Feb 11 09:22:16 2017 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 A5C79129A12 for ; Sat, 11 Feb 2017 09:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8V0q0hic9si for ; Sat, 11 Feb 2017 09:22:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE997129A0A for ; Sat, 11 Feb 2017 09:22:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGG10406; Sat, 11 Feb 2017 17:22:03 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 11 Feb 2017 17:22:00 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Sat, 11 Feb 2017 09:21:55 -0800 From: James N Guichard To: "adrian@olddog.co.uk" , "'Dave Dolson'" , "'Joel M. Halpern'" , "'Ron Parker'" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkAAeZjIw//6oW4D//33gw4AAqsEAgAASngCAASFmAIAAiOAAgAEwB4CAAHsfAA== Date: Sat, 11 Feb 2017 17:21:54 +0000 Message-ID: References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> In-Reply-To: <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.589F483C.00E5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a70407c9a835e72958c2c0bc1d89c9e Archived-At: Cc: "sfc@ietf.org" , "'Dolganow, Andrew \(Nokia - SG\)'" , 'Eric C Rosen' , 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 17:22:15 -0000 After all the back and forth of this thread I am still struggling to see wh= at the problem is; maybe someone can clearly articulate it. The current NSH= specification only talks about SI =3D 0 and the fact that this is invalid = and an SFF should drop the packet. There is no mention of SI =3D 1. As far = as I can tell, aside from a buggy SFF, an SF should never receive a packet = with SI =3D 0 as the preceding SFF will have dropped the packet. Of course = an SF could receive a packet with SI =3D 1, decrement it to 0, and then the= receiving SFF would drop the packet; even in this case one could argue thi= s is a misconfigured control plane as the receiving SFF is unable to termin= ate the SFP and forward the packet. Jim -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Saturday, February 11, 2017 11:34 AM To: 'Dave Dolson' ; 'Joel M. Halpern' ; 'Ron Parker' Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - SG)' ; sfc@ietf.org; James N Guichard ; 'Fabricio Ferraz' Subject: RE: [sfc] NSH Service Index Decrement I hate to do my impersonation of Eric, but... "On the wire" is the crunch. Some have said that there must be no visible difference between the three c= ase: - on the wire between SFF and SF - on the wire between SF and SFF - on the wire between SFF and SFF If this holds then you are correct that sending SI=3D1 in the first case re= quires the SF to do more than a simple decrement (although decrement and di= scard is hardly painful). And it means that SI=3D1 is a dubious value in an= SFP. On the other hand, we appear to be clear about an SF that strips the NSH an= d forwards the traffic as native : this is currently forbidden. So there is= no alternative for an SF receiving SI=3D1 except to discard the packet. Now, does that mean that an SFF should never send a packet with SI=3D1? Wel= l, possibly it is OK for a few specialist SFs intended to sit at the end of= the chain and be a bit bucket with analysis. But, for most SFs there would= be no point. Maybe (just maybe) we should stop letting the tail wag the dog! That is, le= t's decide on the functional behavior we want to see and then design the pr= otocol to match. Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 10 February 2017 22:26 > To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;=20 > 'James N Guichard'; 'Fabricio Ferraz' > Subject: RE: [sfc] NSH Service Index Decrement >=20 > Adrian, > I think I agree with everything you said. > But you did not suggest whether or not you think that SI=3D0 should be=20 > valid on the > wire. > I'm saying it could work, if the next hop is a path terminus. >=20 > If I understand Joel correctly, he says we shouldn't send SI=3D0 in=20 > case the next > hop blindly decrements it. > --> this seems to mean SI=3D1 cannot be used except at the terminus or=20 > --> when the > SF is expected to drop all packets. > So I think this is an unnecessary seat belt, trying to anticipate bugs=20 > in down- > stream devices. >=20 > I realize the current language has been there a long time, and if it=20 > is important to > anyone then it should remain. > Nonetheless, I think devices could safely handle SI=3D0 on the wire=20 > without breaking anything. >=20 > But I'm not pushing for a change, since the current behavior seems=20 > important to > some. >=20 > -Dave >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, February 10, 2017 9:16 AM > To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;=20 > 'James N Guichard'; 'Fabricio Ferraz' > Subject: Re: [sfc] NSH Service Index Decrement >=20 > Oh, you finally pushed me into this discussion, Dave. >=20 > We're building a protocol. with a protocol, you cannot (must not)=20 > assume good behavior from your neighbor. >=20 > So if the SF touches the SI (which it does) we must define the edge conditions. > If it is the SF's job to decrement the SI, then we must also define=20 > what it does > when SI=3D0 (otherwise, it will set SI to 0-1). > If the SF is not allowed to decrement the SI below zero (which makes=20 > sense) we must define what it must do. > Since SFs are allowed to drop packets (indeed that is one of their=20 > main jobs ;-) > then this would be fine. > All that would be left is to define whether they apply the test before=20 > or after > normal processing. >=20 > As an aside, I agree with Don that TTL helps relax this a little, but=20 > does not get us all the way there. >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: 09 February 2017 21:00 > > To: Joel M. Halpern; Ron Parker > > Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C Rosen;=20 > > Dolganow, Andrew (Nokia - SG) > > Subject: Re: [sfc] NSH Service Index Decrement > > > > Discussing misconfigured SFFs is a straw-man argument. Once one=20 > > starts trying > to > > anticipate down-stream devices being misconfigured, one can invent a=20 > > lot of > silly > > requirements. > > > > >From an aesthetic point of view, I think it's bad that there are=20 > > >two SI > values (0 > > and 1) that cannot be used. > > > > The real requirement, IMO, is that no device decrements 0 and forwards = NSH. > > Since only SFs decrement SI, only SFs need to do this check. > > > > And any discussion about buggy SFs... well there is a lot of bad=20 > > stuff that > bugs can > > cause. > > > > > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Thursday, February 09, 2017 2:54 PM > > To: Ron Parker; Dave Dolson > > Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); James=20 > > N > Guichard; > > Fabricio Ferraz > > Subject: Re: [sfc] NSH Service Index Decrement > > > > From my perspective as an individual participant in this work,=20 > > declaring that 0 must be dropped is a matter of robustness. > > > > if we allow 0 to be processed for exit at an SFF, then a=20 > > mis-configured SFF could easily continue processing such a packet. =20 > > Now, it is true that TTL will eventually drop it, but that is an expens= ive fallback. > > > > More importantly, presumably the next entitiy down the incorrect=20 > > path would drop it for a 255 SI. But at that point we are getting=20 > > the error in the wrong place, making it harder to diagnose and repair. > > > > Yours, > > Joel > > > > On 2/9/17 12:42 PM, Ron Parker wrote: > > > agree. > > > > > > On Feb 9, 2017, at 12:28 PM, Dave Dolson > > > wrote: > > > > > >> I'm not clear on why this is broken, or why this restriction is made= . > > >> > > >> I agree it should not be sent to an SF, but an SFF could map an=20 > > >> SI of zero into a path termination. > > >> > > >> I.e., the last SF in a path could decrement SI from 1 to 0, and=20 > > >> the SFF could then terminate the chain. > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N=20 > > >> Guichard > > >> *Sent:* Thursday, February 09, 2017 12:02 PM > > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave=20 > > >> Dolson; Eric C Rosen; sfc@ietf.org > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Not exactly. Section 3.3 specifies "The value zero for SI is not=20 > > >> valid and indicates a broken SFC or malfunctioning SF" .. In=20 > > >> other words an SF should never receive an NSH packet with SI =3D 0.= =20 > > >> Note that if this happened then either a) a classifier set the SI=20 > > >> incorrectly, or b) a re-classifier set the SI incorrectly, or c)=20 > > >> an upstream SF set the SI incorrectly; all of these cases should=20 > > >> be caught by the SFF whose job it is to discard NSH packets with SI = =3D 0. > > >> > > >> > > >> > > >> Jim > > >> > > >> > > >> > > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >> *Sent:* Thursday, February 09, 2017 11:49 AM > > >> *To:* James N Guichard > >> >; Dolganow, Andrew (Nokia -=20 > > >> SG) > >> >; > > Dave > > >> Dolson >; Eric=20 > > >> C Rosen >;=20 > > >> sfc@ietf.org > > >> *Subject:* RE: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Hi Jim, > > >> > > >> Thanks. > > >> > > >> > > >> > > >> One more question about the SI. > > >> > > >> > > >> > > >> Section 3 states that: > > >> > > >> > > >> > > >> Service Index (SI): provides location within the SFP. The initial=20 > > >> classifier MUST set the appropriate SI value for a given=20 > > >> classification result. The initial SI value SHOULD default to 255. > > >> However, the classifier MUST allow configuration of other SI values. > > >> > > >> Service Index MUST be decremented by Service Functions or by SFC=20 > > >> Proxy nodes after performing required services and the new=20 > > >> decremented SI value MUST be used in the egress NSH packet. > > >> > > >> The initial Classifier MUST send the packet to the first SFF in=20 > > >> the identified SFP for forwarding along an SFP. > > >> > > >> If re-classification occurs, and that re-classification results=20 > > >> in a new SPI, the (re)classifier is, in effect, the initial=20 > > >> classifier for the resultant SPI. > > >> > > >> > > >> > > >> Thus: > > >> > > >> a) Initial SI value should be 255 but other values can be > > >> configured by the classifier. > > >> > > >> b) SF decrements the SI value on the egress NSH packet > > >> > > >> c) If re-classification occurs with new SPI, the re-classifier > > >> is the initial classifier, so by a), SI should be again 255 or=20 > > >> other value > > >> > > >> > > >> > > >> So any SI value can be receive by an SF, even 1 or 0 because: > > >> > > >> =E8If SI=3D1 and there is no re-classification, the egress NSH will= =20 > > >> have SI=3D0 > > >> > > >> =E8If SI=3D0 and there is re-classification with new SPI, the egress= =20 > > >> NSH will have a new SPI and a SI=3D 255 or other value, as stated in= a). > > >> > > >> =E8If SI=3D0 and there is no re-classification the SF should discard= =20 > > >> the packet > > >> > > >> > > >> > > >> Also an SFF should forward/handle packets with NSH with SI=3D1 or SI= =3D0. > > >> > > >> > > >> > > >> Do you agree? > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N=20 > > >> Guichard > > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave=20 > > >> Dolson; Eric C Rosen; sfc@ietf.org > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Hi Fabricio, > > >> > > >> > > >> > > >> Welcome! > > >> > > >> > > >> > > >> Yes, removal of NSH is the responsibility of an SFF or a=20 > > >> re-classifier (section 4, bullet point 1 lays this out). With the=20 > > >> current architecture the SF does not care what SI value it gets,=20 > > >> it just needs to worry about decrementing it, and leave it up to=20 > > >> the SFF to evaluate the SI value and associated action. > > >> > > >> > > >> > > >> Jim > > >> > > >> > > >> > > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >> *Sent:* Thursday, February 09, 2017 7:13 AM > > >> *To:* Dolganow, Andrew (Nokia - SG) > >> >; Dave Dolson > > > >> >; Eric C Rosen > >> >; James N Guichard=20 > > >> >; > > >> sfc@ietf.org > > >> *Subject:* RE: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Hi all, > > >> > > >> I'm new here (just read the draft last week) but according to=20 > > >> chapter > > >> 4 (check figure 8 for example), an SF is not allowed to insert or=20 > > >> remove NSH. The removal of NSH is reponsability of the SSF, right? > > >> > > >> > > >> > > >> Figure 8 maps each of the four actions above to the components=20 > > >> in the > > >> > > >> SFC architecture that can perform it. > > >> > > >> > > >> > > >> +---------------+------------------+-------+----------------+-------= --+ > > >> > > >> | | Insert |Select | Update |Service= | > > >> > > >> | | or remove NSH |Service| NSH |policy = | > > >> > > >> | | |Function| |selecti= on| > > >> > > >> | Component +--------+--------+Path +----------------+ = | > > >> > > >> | | | | | Dec. |Update | = | > > >> > > >> | | Insert | Remove | |Service |Context| = | > > >> > > >> | | | | | Index |Header | = | > > >> > > >> +----------------+--------+--------+-------+--------+-------+-------= --+ > > >> > > >> | | + | + | | | + | = | > > >> > > >> |Classifier | | | | | | = | > > >> > > >> +---------------=20 > > >> ++--------+--------+-------+--------+-------+---------+ > > >> > > >> |Service Function| | + | + | | | = | > > >> > > >> |Forwarder(SFF) | | | | | | = | > > >> > > >> +---------------=20 > > >> ++--------+--------+-------+--------+-------+---------+ > > >> > > >> |Service | | | | + | + | + = | > > >> > > >> |Function (SF) | | | | | | = | > > >> > > >> +---------------=20 > > >> ++--------+--------+-------+--------+-------+---------+ > > >> > > >> |SFC Proxy | + | + | | + | | = | > > >> > > >> +----------------+--------+--------+-------+--------+-------+-------= --+ > > >> > > >> > > >> > > >> Figure 8: NSH Action and Role Mapping > > >> > > >> > > >> > > >> > > >> > > >> An SF could receive an NSH packet with an SI of 1, and reclassify=20 > > >> it to a different SPI and SI, right? So when a SF receives a NSH=20 > > >> packet with SI =3D 1 that does not necessarily means a non valid pac= ket. > > >> > > >> And that can even work for SI=3D0, since you decrement the SI in=20 > > >> the egress. > > >> > > >> > > >> > > >> Fabricio > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow,=20 > > >> Andrew (Nokia - SG) > > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > > >> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org=20 > > >> > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> I assumed that if we get value 1 we process then forward without=20 > > >> NSH header (i.e.) this is the last SF processing. > > >> > > >> > > >> > > >> So with that assumption, a more explicit text would be: > > >> > > >> > > >> > > >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST=20 > > >> decrement the SI by 1 after performing all required local=20 > > >> processing and before forwarding the packet to the next SFF. If=20 > > >> the resulting SI is 0, the SF MUST remove the NSH header before forw= arding the packet. > > >> > > >> > > >> > > >> Andrew > > >> > > >> *From: *sfc >=20 > > >> on behalf of Dave Dolson > > > > >> *Date: *Thursday, February 9, 2017 at 2:04 AM > > >> *To: *Eric Rosen > >> >, James N Guichard=20 > > >> > >> >, "sfc@ietf.org=20 > > >> " > > > >> *Subject: *Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> Eric, > > >> > > >> I was never quite happy with the outcome that neither 0 nor 1 is=20 > > >> a valid SI. > > >> > > >> (Because if received with value of 1, it is decremented and=20 > > >> discarded.) > > >> > > >> > > >> > > >> It seems to waste an index value. > > >> > > >> > > >> > > >> I guess I'm interested to know if that is important to other=20 > > >> implementers, or if that was even the intention? > > >> > > >> > > >> > > >> > > >> > > >> -Dave > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C=20 > > >> Rosen > > >> *Sent:* Wednesday, February 08, 2017 11:53 AM > > >> *To:* James N Guichard; sfc@ietf.org > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > >> > > >> > > >> > > >> On 2/7/2017 2:24 PM, James N Guichard wrote: > > >> > > >> A request was made to be more specific and update the text as follow= s: > > >> > > >> > > >> > > >> "Service index MUST be decremented *by a value of 1* by Service=20 > > >> Functions or by SFC Proxy nodes after performing required services .= " > > >> > > >> > > >> A couple of observations: > > >> > > >> - The term "SFC Proxy node" is not defined in either the NSH=20 > > >> draft or in RFC 7665. I think the intention here is to say "SFC Pro= xy". > > >> > > >> - Is the intention that the SI remain unchanged while the SF is=20 > > >> operating on the packet, or is the intention only that the SI be=20 > > >> decremented before the packet is delivered by the SF or SFC Proxy=20 > > >> to an SFF? > > >> > > >> I'd suggest either: > > >> > > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST=20 > > >> decrement the SI by 1 before delivering the packet to the next SFF" > > >> > > >> or > > >> > > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST=20 > > >> decrement the SI by 1 before delivering the packet to the next=20 > > >> SFF, but not until the SF has finished all its other processing of t= he packet" > > >> > > >> depending upon which is intended. > > >> > > >> I think an implication of these procedures is that an SI value of=20 > > >> 1 is not valid. If an SF gets an NSH packet with an SI of 1, the=20 > > >> SF will decrement the SI (setting it to 0), send the packet to an=20 > > >> SFF, and the SFF will discard it, because 0 is an invalid SI=20 > > >> value. Is that the intention? > > >> > > >> The draft makes it clear (well, sort of) that an SFF should=20 > > >> discard a packet with an SI of 0, but does not seem to say that=20 > > >> an SF or SFC Proxy should discard a packet it receives with an SI=20 > > >> of 0. It would probably be a good idea to say that. > > >> > > >> Some text in the draft (e.g., section 7.1) states than an SFF=20 > > >> should discard a packet with an SI of zero, but other text in the=20 > > >> draft (e.g., section 3.3) only says that an SFF should log an=20 > > >> error if it sees an SI of zero. It's probably best to change the=20 > > >> text in 3.3. to say "SHOULD generate an error/log message and=20 > > >> MUST discard the packet", or something similar. > > >> > > >> _______________________________________________ > > >> sfc mailing list > > >> sfc@ietf.org =20 > > >> 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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Feb 11 09:31:28 2017 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 B9953129A1B for ; Sat, 11 Feb 2017 09:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 UvZx0HP_01L9 for ; Sat, 11 Feb 2017 09:31: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 255F51293D6 for ; Sat, 11 Feb 2017 09:31:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0C66E4600A3; Sat, 11 Feb 2017 09:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486834284; bh=8IDn2VqEW3slM0sjJb1x+A4oqjxpW272iC7b024O5vk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dEfIvh7BBno0xBtQzXXlTNLx1wMtoZmkrlznFby6iAmXMthtwPYZA8ABWvBMBfNoB Q9P3gRVnPePmAoxhd/rZFTAW16yAPc2tC2rV8+/4p/L/V2w8tSIxNiJJsPQLCulVWM 7/bkDUOdlvaPWzFS751/gzCzua6f8uKb0JBanz8E= 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 92FA31C0D95; Sat, 11 Feb 2017 09:31:22 -0800 (PST) To: Ron Parker , "adrian@olddog.co.uk" , 'Dave Dolson' References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> Date: Sat, 11 Feb 2017 12:31:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" , 'James N Guichard' , "'Dolganow, Andrew \(Nokia - SG\)'" , 'Eric C Rosen' , 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 17:31:27 -0000 Personally, what you describe sounds like a quite reasonable case where a packet arrive at the SF with an SI of 1 will produce exactly the desired behavior. Which suggests, to my limited view, that the current text works fine. Yours, Joel On 2/11/17 11:55 AM, Ron Parker wrote: > Hi, Adrian. > > Not the original topic, per se, but wrt your comment: > > * On the other hand, we appear to be clear about an SF that strips the NSH and forwards the traffic as native : this is currently forbidden. > > I'm wondering how to reconcile this to a transparent HTTP Proxy that does not preserve the original source-IP? Does this mean that it is mandatory for such an SF to also be a classifier so it can self-classify its own related flows (i.e., using its own visible IP addresses)? From SFF perspective, it would look like all packets on the access side are dropped in the upstream direction and injected by the SF in the downstream direction. On the Internet side, it would look like all packets are injected by the SF in the upstream direction and dropped in the downstream direction. > > Thanks for any clarification. > > Ron > > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Saturday, February 11, 2017 11:34 AM > To: 'Dave Dolson' ; 'Joel M. Halpern' ; Ron Parker > Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - SG)' ; sfc@ietf.org; 'James N Guichard' ; 'Fabricio Ferraz' > Subject: RE: [sfc] NSH Service Index Decrement > > I hate to do my impersonation of Eric, but... > > "On the wire" is the crunch. > > Some have said that there must be no visible difference between the three case: > - on the wire between SFF and SF > - on the wire between SF and SFF > - on the wire between SFF and SFF > > If this holds then you are correct that sending SI=1 in the first case requires the SF to do more than a simple decrement (although decrement and discard is hardly painful). And it means that SI=1 is a dubious value in an SFP. > > On the other hand, we appear to be clear about an SF that strips the NSH and forwards the traffic as native : this is currently forbidden. So there is no alternative for an SF receiving SI=1 except to discard the packet. > > Now, does that mean that an SFF should never send a packet with SI=1? Well, possibly it is OK for a few specialist SFs intended to sit at the end of the chain and be a bit bucket with analysis. But, for most SFs there would be no point. > > Maybe (just maybe) we should stop letting the tail wag the dog! That is, let's decide on the functional behavior we want to see and then design the protocol to match. > > Adrian > >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: 10 February 2017 22:26 >> To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' >> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; >> 'James N Guichard'; 'Fabricio Ferraz' >> Subject: RE: [sfc] NSH Service Index Decrement >> >> Adrian, >> I think I agree with everything you said. >> But you did not suggest whether or not you think that SI=0 should be >> valid on > the >> wire. >> I'm saying it could work, if the next hop is a path terminus. >> >> If I understand Joel correctly, he says we shouldn't send SI=0 in >> case the > next >> hop blindly decrements it. >> --> this seems to mean SI=1 cannot be used except at the terminus or >> --> when the >> SF is expected to drop all packets. >> So I think this is an unnecessary seat belt, trying to anticipate bugs >> in > down- >> stream devices. >> >> I realize the current language has been there a long time, and if it >> is > important to >> anyone then it should remain. >> Nonetheless, I think devices could safely handle SI=0 on the wire >> without breaking anything. >> >> But I'm not pushing for a change, since the current behavior seems >> important > to >> some. >> >> -Dave >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel >> Sent: Friday, February 10, 2017 9:16 AM >> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' >> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; >> 'James N Guichard'; 'Fabricio Ferraz' >> Subject: Re: [sfc] NSH Service Index Decrement >> >> Oh, you finally pushed me into this discussion, Dave. >> >> We're building a protocol. with a protocol, you cannot (must not) >> assume good behavior from your neighbor. >> >> So if the SF touches the SI (which it does) we must define the edge > conditions. >> If it is the SF's job to decrement the SI, then we must also define >> what it > does >> when SI=0 (otherwise, it will set SI to 0-1). >> If the SF is not allowed to decrement the SI below zero (which makes >> sense) we must define what it must do. >> Since SFs are allowed to drop packets (indeed that is one of their >> main jobs > ;-) >> then this would be fine. >> All that would be left is to define whether they apply the test before >> or > after >> normal processing. >> >> As an aside, I agree with Don that TTL helps relax this a little, but >> does not get us all the way there. >> >> Cheers, >> Adrian >> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: 09 February 2017 21:00 >>> To: Joel M. Halpern; Ron Parker >>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C Rosen; >>> Dolganow, Andrew (Nokia - SG) >>> Subject: Re: [sfc] NSH Service Index Decrement >>> >>> Discussing misconfigured SFFs is a straw-man argument. Once one >>> starts > trying >> to >>> anticipate down-stream devices being misconfigured, one can invent a >>> lot of >> silly >>> requirements. >>> >>> >From an aesthetic point of view, I think it's bad that there are >>>> two SI >> values (0 >>> and 1) that cannot be used. >>> >>> The real requirement, IMO, is that no device decrements 0 and forwards NSH. >>> Since only SFs decrement SI, only SFs need to do this check. >>> >>> And any discussion about buggy SFs... well there is a lot of bad >>> stuff that >> bugs can >>> cause. >>> >>> >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Thursday, February 09, 2017 2:54 PM >>> To: Ron Parker; Dave Dolson >>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); James >>> N >> Guichard; >>> Fabricio Ferraz >>> Subject: Re: [sfc] NSH Service Index Decrement >>> >>> From my perspective as an individual participant in this work, >>> declaring that 0 must be dropped is a matter of robustness. >>> >>> if we allow 0 to be processed for exit at an SFF, then a >>> mis-configured SFF could easily continue processing such a packet. >>> Now, it is true that TTL will eventually drop it, but that is an expensive fallback. >>> >>> More importantly, presumably the next entitiy down the incorrect >>> path would drop it for a 255 SI. But at that point we are getting >>> the error in the wrong place, making it harder to diagnose and repair. >>> >>> Yours, >>> Joel >>> >>> On 2/9/17 12:42 PM, Ron Parker wrote: >>>> agree. >>>> >>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson >>> > wrote: >>>> >>>>> I'm not clear on why this is broken, or why this restriction is made. >>>>> >>>>> I agree it should not be sent to an SF, but an SFF could map an >>>>> SI of zero into a path termination. >>>>> >>>>> I.e., the last SF in a path could decrement SI from 1 to 0, and >>>>> the SFF could then terminate the chain. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N >>>>> Guichard >>>>> *Sent:* Thursday, February 09, 2017 12:02 PM >>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave >>>>> Dolson; Eric C Rosen; sfc@ietf.org >>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Not exactly. Section 3.3 specifies "The value zero for SI is not >>>>> valid and indicates a broken SFC or malfunctioning SF" .. In >>>>> other words an SF should never receive an NSH packet with SI = 0. >>>>> Note that if this happened then either a) a classifier set the SI >>>>> incorrectly, or b) a re-classifier set the SI incorrectly, or c) >>>>> an upstream SF set the SI incorrectly; all of these cases should >>>>> be caught by the SFF whose job it is to discard NSH packets with SI = 0. >>>>> >>>>> >>>>> >>>>> Jim >>>>> >>>>> >>>>> >>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >>>>> *Sent:* Thursday, February 09, 2017 11:49 AM >>>>> *To:* James N Guichard >>>> >; Dolganow, Andrew (Nokia - >>>>> SG) >>>> >; >>> Dave >>>>> Dolson >; Eric >>>>> C Rosen >; >>>>> sfc@ietf.org >>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Hi Jim, >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> One more question about the SI. >>>>> >>>>> >>>>> >>>>> Section 3 states that: >>>>> >>>>> >>>>> >>>>> Service Index (SI): provides location within the SFP. The initial >>>>> classifier MUST set the appropriate SI value for a given >>>>> classification result. The initial SI value SHOULD default to 255. >>>>> However, the classifier MUST allow configuration of other SI values. >>>>> >>>>> Service Index MUST be decremented by Service Functions or by SFC >>>>> Proxy nodes after performing required services and the new >>>>> decremented SI value MUST be used in the egress NSH packet. >>>>> >>>>> The initial Classifier MUST send the packet to the first SFF in >>>>> the identified SFP for forwarding along an SFP. >>>>> >>>>> If re-classification occurs, and that re-classification results >>>>> in a new SPI, the (re)classifier is, in effect, the initial >>>>> classifier for the resultant SPI. >>>>> >>>>> >>>>> >>>>> Thus: >>>>> >>>>> a) Initial SI value should be 255 but other values can be >>>>> configured by the classifier. >>>>> >>>>> b) SF decrements the SI value on the egress NSH packet >>>>> >>>>> c) If re-classification occurs with new SPI, the re-classifier >>>>> is the initial classifier, so by a), SI should be again 255 or >>>>> other value >>>>> >>>>> >>>>> >>>>> So any SI value can be receive by an SF, even 1 or 0 because: >>>>> >>>>> èIf SI=1 and there is no re-classification, the egress NSH will >>>>> have SI=0 >>>>> >>>>> èIf SI=0 and there is re-classification with new SPI, the egress >>>>> NSH will have a new SPI and a SI= 255 or other value, as stated in a). >>>>> >>>>> èIf SI=0 and there is no re-classification the SF should discard >>>>> the packet >>>>> >>>>> >>>>> >>>>> Also an SFF should forward/handle packets with NSH with SI=1 or SI=0. >>>>> >>>>> >>>>> >>>>> Do you agree? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N >>>>> Guichard >>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 >>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave >>>>> Dolson; Eric C Rosen; sfc@ietf.org >>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Hi Fabricio, >>>>> >>>>> >>>>> >>>>> Welcome! >>>>> >>>>> >>>>> >>>>> Yes, removal of NSH is the responsibility of an SFF or a >>>>> re-classifier (section 4, bullet point 1 lays this out). With the >>>>> current architecture the SF does not care what SI value it gets, >>>>> it just needs to worry about decrementing it, and leave it up to >>>>> the SFF to evaluate the SI value and associated action. >>>>> >>>>> >>>>> >>>>> Jim >>>>> >>>>> >>>>> >>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >>>>> *Sent:* Thursday, February 09, 2017 7:13 AM >>>>> *To:* Dolganow, Andrew (Nokia - SG) >>>> >; Dave Dolson >>> >>>> >; Eric C Rosen >>>> >; James N Guichard >>>>> > >; >>>>> sfc@ietf.org >>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> I'm new here (just read the draft last week) but according to >>>>> chapter >>>>> 4 (check figure 8 for example), an SF is not allowed to insert or >>>>> remove NSH. The removal of NSH is reponsability of the SSF, right? >>>>> >>>>> >>>>> >>>>> Figure 8 maps each of the four actions above to the components >>>>> in the >>>>> >>>>> SFC architecture that can perform it. >>>>> >>>>> >>>>> >>>>> +---------------+------------------+-------+----------------+---------+ >>>>> >>>>> | | Insert |Select | Update |Service | >>>>> >>>>> | | or remove NSH |Service| NSH |policy | >>>>> >>>>> | | |Function| |selection| >>>>> >>>>> | Component +--------+--------+Path +----------------+ | >>>>> >>>>> | | | | | Dec. |Update | | >>>>> >>>>> | | Insert | Remove | |Service |Context| | >>>>> >>>>> | | | | | Index |Header | | >>>>> >>>>> +----------------+--------+--------+-------+--------+-------+---------+ >>>>> >>>>> | | + | + | | | + | | >>>>> >>>>> |Classifier | | | | | | | >>>>> >>>>> +--------------- >>>>> ++--------+--------+-------+--------+-------+---------+ >>>>> >>>>> |Service Function| | + | + | | | | >>>>> >>>>> |Forwarder(SFF) | | | | | | | >>>>> >>>>> +--------------- >>>>> ++--------+--------+-------+--------+-------+---------+ >>>>> >>>>> |Service | | | | + | + | + | >>>>> >>>>> |Function (SF) | | | | | | | >>>>> >>>>> +--------------- >>>>> ++--------+--------+-------+--------+-------+---------+ >>>>> >>>>> |SFC Proxy | + | + | | + | | | >>>>> >>>>> +----------------+--------+--------+-------+--------+-------+---------+ >>>>> >>>>> >>>>> >>>>> Figure 8: NSH Action and Role Mapping >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> An SF could receive an NSH packet with an SI of 1, and reclassify >>>>> it to a different SPI and SI, right? So when a SF receives a NSH >>>>> packet with SI = 1 that does not necessarily means a non valid packet. >>>>> >>>>> And that can even work for SI=0, since you decrement the SI in >>>>> the > egress. >>>>> >>>>> >>>>> >>>>> Fabricio >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, >>>>> Andrew (Nokia - SG) >>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 >>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org >>>>> >>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> I assumed that if we get value 1 we process then forward without >>>>> NSH header (i.e.) this is the last SF processing. >>>>> >>>>> >>>>> >>>>> So with that assumption, a more explicit text would be: >>>>> >>>>> >>>>> >>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >>>>> decrement the SI by 1 after performing all required local >>>>> processing and before forwarding the packet to the next SFF. If >>>>> the resulting SI is 0, the SF MUST remove the NSH header before forwarding the packet. >>>>> >>>>> >>>>> >>>>> Andrew >>>>> >>>>> *From: *sfc > >>>>> on behalf of Dave Dolson >> > >>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM >>>>> *To: *Eric Rosen >>>> >, James N Guichard >>>>> >>>> >, "sfc@ietf.org >>>>> " > >>>>> *Subject: *Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Eric, >>>>> >>>>> I was never quite happy with the outcome that neither 0 nor 1 is >>>>> a valid SI. >>>>> >>>>> (Because if received with value of 1, it is decremented and >>>>> discarded.) >>>>> >>>>> >>>>> >>>>> It seems to waste an index value. >>>>> >>>>> >>>>> >>>>> I guess I'm interested to know if that is important to other >>>>> implementers, or if that was even the intention? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -Dave >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C >>>>> Rosen >>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM >>>>> *To:* James N Guichard; sfc@ietf.org >>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: >>>>> >>>>> A request was made to be more specific and update the text as follows: >>>>> >>>>> >>>>> >>>>> "Service index MUST be decremented *by a value of 1* by Service >>>>> Functions or by SFC Proxy nodes after performing required services ." >>>>> >>>>> >>>>> A couple of observations: >>>>> >>>>> - The term "SFC Proxy node" is not defined in either the NSH >>>>> draft or in RFC 7665. I think the intention here is to say "SFC Proxy". >>>>> >>>>> - Is the intention that the SI remain unchanged while the SF is >>>>> operating on the packet, or is the intention only that the SI be >>>>> decremented before the packet is delivered by the SF or SFC Proxy >>>>> to an SFF? >>>>> >>>>> I'd suggest either: >>>>> >>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >>>>> decrement the SI by 1 before delivering the packet to the next SFF" >>>>> >>>>> or >>>>> >>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >>>>> decrement the SI by 1 before delivering the packet to the next >>>>> SFF, but not until the SF has finished all its other processing of the packet" >>>>> >>>>> depending upon which is intended. >>>>> >>>>> I think an implication of these procedures is that an SI value of >>>>> 1 is not valid. If an SF gets an NSH packet with an SI of 1, the >>>>> SF will decrement the SI (setting it to 0), send the packet to an >>>>> SFF, and the SFF will discard it, because 0 is an invalid SI >>>>> value. Is that the intention? >>>>> >>>>> The draft makes it clear (well, sort of) that an SFF should >>>>> discard a packet with an SI of 0, but does not seem to say that >>>>> an SF or SFC Proxy should discard a packet it receives with an SI >>>>> of 0. It would probably be a good idea to say that. >>>>> >>>>> Some text in the draft (e.g., section 7.1) states than an SFF >>>>> should discard a packet with an SI of zero, but other text in the >>>>> draft (e.g., section 3.3) only says that an SFF should log an >>>>> error if it sees an SI of zero. It's probably best to change the >>>>> text in 3.3. to say "SHOULD generate an error/log message and >>>>> MUST discard the packet", or something similar. >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Sat Feb 11 09:51:19 2017 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 D541E129A20 for ; Sat, 11 Feb 2017 09:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QnrR10goevVN for ; Sat, 11 Feb 2017 09:51:14 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A94129A2E for ; Sat, 11 Feb 2017 09:51:13 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1BHotbX013459; Sat, 11 Feb 2017 17:50:55 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1BHon0Y013424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Feb 2017 17:50:52 GMT From: "Adrian Farrel" To: "'James N Guichard'" , "'Dave Dolson'" , "'Joel M. Halpern'" , "'Ron Parker'" References: <5f63d44a-5455-fc4b-888c-e6d099263ec6@juniper.net> <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> In-Reply-To: Date: Sat, 11 Feb 2017 17:50:50 -0000 Message-ID: <0d8401d2848f$648b0d70$2da12850$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHoYgY6PCVGpHJ8su3f5ejQO2dmKAIvwOccAgx3iLoAvuXz6QHh04WVAzglJZACFiSEIwEdT5qdAIUzmAMCaf1/yQGATjGeAl0zdEQCPzPO+wHoN6HvAlAqSBsB4cS1b6BU5OGQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22880.001 X-TM-AS-Result: No--24.928-10.0-31-10 X-imss-scan-details: No--24.928-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtHYfPOPCpnfAnlMlWV+Ir67E+VNlwE+VkWjFcKTkDI9jPhT 6/pHvNpJ4X88r37rqLXSb2rt42A3uVtFsD8r+sfMzNY33yIEF4bs36/It7hLR8xzM8CbVIFIrFF ZWwCZJMiVzzMoRq0KUV88doC4WsZaSbc8Wi8YbVvFW296Y1uTJ3H9gj5nlAmSdEG7y+D7o5B/PC dgwnhGbTZhXG6YzizDGG8DKjYDFV9L6TLH/glcpQPZZctd3P4B6Jj6zYvfFATAKUWiGHYUurSeP 3F8zgSUH9S92mo2wOdKzBoVliQMywMMOsgWbt/8BBmRlS94Ztv3EiKJ4hMlqJ6fSoF3Lt+MzweV 0QFHsGVdkTVFfeDqgFUqOCK0c4/r0RCs70uuPqFDU5wIS9P5tyDPOgHqOrGCDYbe/PyX8gT0ZtJ JqrR/gwA5PAWD5aIUF+K/pZ5jfCpIGJIfj527f2/+RwWenb0Yh8Ytn75ClDMujyxRHwe+HE8LYU 9lieOwHVBcT6AmVceETtQ0aLTs2KZ1ky5DSWMhkE7MrqaPYs3WSrKtwxqWpSwGmAksjl8C0L7cs 30w5ray40Fma/LQ2ZYyGGzMlT4ZsMkDYVIIPZZGWpKGpvfmnv8YfrCdHgPmSYPLE090cxctzOBW sTM6oNtfW9iQcKCEWrb1MzA3JCqLzf3TiDDiuY6MisxJraxHCI3p+Ju8mqoA6s2mIXI3kLYm0mX BV8eWgo5UF61u7aJdhC1HVFzf7L53jMaG12305gCHftmwEMJT4DtiSkMnWCgsSBGgZaWOBde3D5 RDQVMQUKDamXLK1rLYmq9Q8i6B3m/fxXhNXRKeAiCmPx4NwGNn8XPiALIbooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: Cc: sfc@ietf.org, "'Dolganow, Andrew \(Nokia - SG\)'" , 'Eric C Rosen' , 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 17:51:18 -0000 Yes, there is something "misconfigured". If the SFF sends a packet to an SF with SI=3D1 we know that the packet = will come back (barring reclassification onto another SFP) with SI=3D0 and be = discarded. So there is very little valuable function that an SF can apply with = SI=3D1. It is OK if this is the case (just a waste of 1 in 255 SI values, but = who can conceive of a chain of 255 SFs?). And if it is the case then: - Let's paint it red - Let's clarify that it is OK for an SF to send a packet with SI=3D0 (currently, IIRC, it sounds like the SF should not do that) A > -----Original Message----- > From: James N Guichard [mailto:james.n.guichard@huawei.com] > Sent: 11 February 2017 17:22 > To: adrian@olddog.co.uk; 'Dave Dolson'; 'Joel M. Halpern'; 'Ron = Parker' > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; = 'Fabricio Ferraz' > Subject: RE: [sfc] NSH Service Index Decrement >=20 > After all the back and forth of this thread I am still struggling to = see what the > problem is; maybe someone can clearly articulate it. The current NSH > specification only talks about SI =3D 0 and the fact that this is = invalid and an SFF > should drop the packet. There is no mention of SI =3D 1. As far as I = can tell, aside > from a buggy SFF, an SF should never receive a packet with SI =3D 0 as = the > preceding SFF will have dropped the packet. Of course an SF could = receive a > packet with SI =3D 1, decrement it to 0, and then the receiving SFF = would drop the > packet; even in this case one could argue this is a misconfigured = control plane as > the receiving SFF is unable to terminate the SFP and forward the = packet. >=20 > Jim >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Saturday, February 11, 2017 11:34 AM > To: 'Dave Dolson' ; 'Joel M. Halpern' > ; 'Ron Parker' > Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - = SG)' > ; sfc@ietf.org; James N Guichard > ; 'Fabricio Ferraz' = > Subject: RE: [sfc] NSH Service Index Decrement >=20 > I hate to do my impersonation of Eric, but... >=20 > "On the wire" is the crunch. >=20 > Some have said that there must be no visible difference between the = three case: > - on the wire between SFF and SF > - on the wire between SF and SFF > - on the wire between SFF and SFF >=20 > If this holds then you are correct that sending SI=3D1 in the first = case requires the SF > to do more than a simple decrement (although decrement and discard is = hardly > painful). And it means that SI=3D1 is a dubious value in an SFP. >=20 > On the other hand, we appear to be clear about an SF that strips the = NSH and > forwards the traffic as native : this is currently forbidden. So there = is no > alternative for an SF receiving SI=3D1 except to discard the packet. >=20 > Now, does that mean that an SFF should never send a packet with = SI=3D1? Well, > possibly it is OK for a few specialist SFs intended to sit at the end = of the chain and > be a bit bucket with analysis. But, for most SFs there would be no = point. >=20 > Maybe (just maybe) we should stop letting the tail wag the dog! That = is, let's > decide on the functional behavior we want to see and then design the = protocol > to match. >=20 > Adrian >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 10 February 2017 22:26 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; > > 'James N Guichard'; 'Fabricio Ferraz' > > Subject: RE: [sfc] NSH Service Index Decrement > > > > Adrian, > > I think I agree with everything you said. > > But you did not suggest whether or not you think that SI=3D0 should = be > > valid on > the > > wire. > > I'm saying it could work, if the next hop is a path terminus. > > > > If I understand Joel correctly, he says we shouldn't send SI=3D0 in > > case the > next > > hop blindly decrements it. > > --> this seems to mean SI=3D1 cannot be used except at the terminus = or > > --> when the > > SF is expected to drop all packets. > > So I think this is an unnecessary seat belt, trying to anticipate = bugs > > in > down- > > stream devices. > > > > I realize the current language has been there a long time, and if it > > is > important to > > anyone then it should remain. > > Nonetheless, I think devices could safely handle SI=3D0 on the wire > > without breaking anything. > > > > But I'm not pushing for a change, since the current behavior seems > > important > to > > some. > > > > -Dave > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Friday, February 10, 2017 9:16 AM > > To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; > > 'James N Guichard'; 'Fabricio Ferraz' > > Subject: Re: [sfc] NSH Service Index Decrement > > > > Oh, you finally pushed me into this discussion, Dave. > > > > We're building a protocol. with a protocol, you cannot (must not) > > assume good behavior from your neighbor. > > > > So if the SF touches the SI (which it does) we must define the edge > conditions. > > If it is the SF's job to decrement the SI, then we must also define > > what it > does > > when SI=3D0 (otherwise, it will set SI to 0-1). > > If the SF is not allowed to decrement the SI below zero (which makes > > sense) we must define what it must do. > > Since SFs are allowed to drop packets (indeed that is one of their > > main jobs > ;-) > > then this would be fine. > > All that would be left is to define whether they apply the test = before > > or > after > > normal processing. > > > > As an aside, I agree with Don that TTL helps relax this a little, = but > > does not get us all the way there. > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > > Sent: 09 February 2017 21:00 > > > To: Joel M. Halpern; Ron Parker > > > Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C Rosen; > > > Dolganow, Andrew (Nokia - SG) > > > Subject: Re: [sfc] NSH Service Index Decrement > > > > > > Discussing misconfigured SFFs is a straw-man argument. Once one > > > starts > trying > > to > > > anticipate down-stream devices being misconfigured, one can invent = a > > > lot of > > silly > > > requirements. > > > > > > >From an aesthetic point of view, I think it's bad that there are > > > >two SI > > values (0 > > > and 1) that cannot be used. > > > > > > The real requirement, IMO, is that no device decrements 0 and = forwards NSH. > > > Since only SFs decrement SI, only SFs need to do this check. > > > > > > And any discussion about buggy SFs... well there is a lot of bad > > > stuff that > > bugs can > > > cause. > > > > > > > > > > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > > Sent: Thursday, February 09, 2017 2:54 PM > > > To: Ron Parker; Dave Dolson > > > Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); = James > > > N > > Guichard; > > > Fabricio Ferraz > > > Subject: Re: [sfc] NSH Service Index Decrement > > > > > > From my perspective as an individual participant in this work, > > > declaring that 0 must be dropped is a matter of robustness. > > > > > > if we allow 0 to be processed for exit at an SFF, then a > > > mis-configured SFF could easily continue processing such a packet. > > > Now, it is true that TTL will eventually drop it, but that is an = expensive fallback. > > > > > > More importantly, presumably the next entitiy down the incorrect > > > path would drop it for a 255 SI. But at that point we are getting > > > the error in the wrong place, making it harder to diagnose and = repair. > > > > > > Yours, > > > Joel > > > > > > On 2/9/17 12:42 PM, Ron Parker wrote: > > > > agree. > > > > > > > > On Feb 9, 2017, at 12:28 PM, Dave Dolson > > > > wrote: > > > > > > > >> I'm not clear on why this is broken, or why this restriction is = made. > > > >> > > > >> I agree it should not be sent to an SF, but an SFF could map an > > > >> SI of zero into a path termination. > > > >> > > > >> I.e., the last SF in a path could decrement SI from 1 to 0, and > > > >> the SFF could then terminate the chain. > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N > > > >> Guichard > > > >> *Sent:* Thursday, February 09, 2017 12:02 PM > > > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave > > > >> Dolson; Eric C Rosen; sfc@ietf.org > > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > > >> > > > >> > > > >> > > > >> Not exactly. Section 3.3 specifies "The value zero for SI is = not > > > >> valid and indicates a broken SFC or malfunctioning SF" .. In > > > >> other words an SF should never receive an NSH packet with SI = =3D 0. > > > >> Note that if this happened then either a) a classifier set the = SI > > > >> incorrectly, or b) a re-classifier set the SI incorrectly, or = c) > > > >> an upstream SF set the SI incorrectly; all of these cases = should > > > >> be caught by the SFF whose job it is to discard NSH packets = with SI =3D 0. > > > >> > > > >> > > > >> > > > >> Jim > > > >> > > > >> > > > >> > > > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > > >> *Sent:* Thursday, February 09, 2017 11:49 AM > > > >> *To:* James N Guichard > > >> >; Dolganow, Andrew (Nokia = - > > > >> SG) > > >> >; > > > Dave > > > >> Dolson >; = Eric > > > >> C Rosen >; > > > >> sfc@ietf.org > > > >> *Subject:* RE: [sfc] NSH Service Index Decrement > > > >> > > > >> > > > >> > > > >> Hi Jim, > > > >> > > > >> Thanks. > > > >> > > > >> > > > >> > > > >> One more question about the SI. > > > >> > > > >> > > > >> > > > >> Section 3 states that: > > > >> > > > >> > > > >> > > > >> Service Index (SI): provides location within the SFP. The = initial > > > >> classifier MUST set the appropriate SI value for a given > > > >> classification result. The initial SI value SHOULD default to = 255. > > > >> However, the classifier MUST allow configuration of other SI = values. > > > >> > > > >> Service Index MUST be decremented by Service Functions or by = SFC > > > >> Proxy nodes after performing required services and the new > > > >> decremented SI value MUST be used in the egress NSH packet. > > > >> > > > >> The initial Classifier MUST send the packet to the first SFF in > > > >> the identified SFP for forwarding along an SFP. > > > >> > > > >> If re-classification occurs, and that re-classification results > > > >> in a new SPI, the (re)classifier is, in effect, the initial > > > >> classifier for the resultant SPI. > > > >> > > > >> > > > >> > > > >> Thus: > > > >> > > > >> a) Initial SI value should be 255 but other values can be > > > >> configured by the classifier. > > > >> > > > >> b) SF decrements the SI value on the egress NSH packet > > > >> > > > >> c) If re-classification occurs with new SPI, the = re-classifier > > > >> is the initial classifier, so by a), SI should be again 255 or > > > >> other value > > > >> > > > >> > > > >> > > > >> So any SI value can be receive by an SF, even 1 or 0 because: > > > >> > > > >> =E8If SI=3D1 and there is no re-classification, the egress NSH = will > > > >> have SI=3D0 > > > >> > > > >> =E8If SI=3D0 and there is re-classification with new SPI, the = egress > > > >> NSH will have a new SPI and a SI=3D 255 or other value, as = stated in a). > > > >> > > > >> =E8If SI=3D0 and there is no re-classification the SF should = discard > > > >> the packet > > > >> > > > >> > > > >> > > > >> Also an SFF should forward/handle packets with NSH with SI=3D1 = or SI=3D0. > > > >> > > > >> > > > >> > > > >> Do you agree? > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N > > > >> Guichard > > > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > > > >> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave > > > >> Dolson; Eric C Rosen; sfc@ietf.org > > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > > >> > > > >> > > > >> > > > >> Hi Fabricio, > > > >> > > > >> > > > >> > > > >> Welcome! > > > >> > > > >> > > > >> > > > >> Yes, removal of NSH is the responsibility of an SFF or a > > > >> re-classifier (section 4, bullet point 1 lays this out). With = the > > > >> current architecture the SF does not care what SI value it = gets, > > > >> it just needs to worry about decrementing it, and leave it up = to > > > >> the SFF to evaluate the SI value and associated action. > > > >> > > > >> > > > >> > > > >> Jim > > > >> > > > >> > > > >> > > > >> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > > >> *Sent:* Thursday, February 09, 2017 7:13 AM > > > >> *To:* Dolganow, Andrew (Nokia - SG) > > >> >; Dave Dolson > > > > > >> >; Eric C Rosen = > > >> >; James N Guichard > > > >> > >; > > > >> sfc@ietf.org > > > >> *Subject:* RE: [sfc] NSH Service Index Decrement > > > >> > > > >> > > > >> > > > >> Hi all, > > > >> > > > >> I'm new here (just read the draft last week) but according to > > > >> chapter > > > >> 4 (check figure 8 for example), an SF is not allowed to insert = or > > > >> remove NSH. The removal of NSH is reponsability of the SSF, = right? > > > >> > > > >> > > > >> > > > >> Figure 8 maps each of the four actions above to the = components > > > >> in the > > > >> > > > >> SFC architecture that can perform it. > > > >> > > > >> > > > >> > > > >> = +---------------+------------------+-------+----------------+---------+ > > > >> > > > >> | | Insert |Select | Update = |Service | > > > >> > > > >> | | or remove NSH |Service| NSH = |policy | > > > >> > > > >> | | |Function| = |selection| > > > >> > > > >> | Component +--------+--------+Path +----------------+ = | > > > >> > > > >> | | | | | Dec. |Update | = | > > > >> > > > >> | | Insert | Remove | |Service |Context| = | > > > >> > > > >> | | | | | Index |Header | = | > > > >> > > > >> = +----------------+--------+--------+-------+--------+-------+---------+ > > > >> > > > >> | | + | + | | | + | = | > > > >> > > > >> |Classifier | | | | | | = | > > > >> > > > >> +--------------- > > > >> ++--------+--------+-------+--------+-------+---------+ > > > >> > > > >> |Service Function| | + | + | | | = | > > > >> > > > >> |Forwarder(SFF) | | | | | | = | > > > >> > > > >> +--------------- > > > >> ++--------+--------+-------+--------+-------+---------+ > > > >> > > > >> |Service | | | | + | + | = + | > > > >> > > > >> |Function (SF) | | | | | | = | > > > >> > > > >> +--------------- > > > >> ++--------+--------+-------+--------+-------+---------+ > > > >> > > > >> |SFC Proxy | + | + | | + | | = | > > > >> > > > >> = +----------------+--------+--------+-------+--------+-------+---------+ > > > >> > > > >> > > > >> > > > >> Figure 8: NSH Action and Role Mapping > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> An SF could receive an NSH packet with an SI of 1, and = reclassify > > > >> it to a different SPI and SI, right? So when a SF receives a = NSH > > > >> packet with SI =3D 1 that does not necessarily means a non = valid packet. > > > >> > > > >> And that can even work for SI=3D0, since you decrement the SI = in > > > >> the > egress. > > > >> > > > >> > > > >> > > > >> Fabricio > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of = *Dolganow, > > > >> Andrew (Nokia - SG) > > > >> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > > > >> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org > > > >> > > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > > >> > > > >> > > > >> > > > >> I assumed that if we get value 1 we process then forward = without > > > >> NSH header (i.e.) this is the last SF processing. > > > >> > > > >> > > > >> > > > >> So with that assumption, a more explicit text would be: > > > >> > > > >> > > > >> > > > >> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > > >> decrement the SI by 1 after performing all required local > > > >> processing and before forwarding the packet to the next SFF. If > > > >> the resulting SI is 0, the SF MUST remove the NSH header before > forwarding the packet. > > > >> > > > >> > > > >> > > > >> Andrew > > > >> > > > >> *From: *sfc > > > > >> on behalf of Dave Dolson > > > > > > >> *Date: *Thursday, February 9, 2017 at 2:04 AM > > > >> *To: *Eric Rosen > > >> >, James N Guichard > > > >> > > >> >, "sfc@ietf.org > > > >> " > > > > >> *Subject: *Re: [sfc] NSH Service Index Decrement > > > >> > > > >> > > > >> > > > >> Eric, > > > >> > > > >> I was never quite happy with the outcome that neither 0 nor 1 = is > > > >> a valid SI. > > > >> > > > >> (Because if received with value of 1, it is decremented and > > > >> discarded.) > > > >> > > > >> > > > >> > > > >> It seems to waste an index value. > > > >> > > > >> > > > >> > > > >> I guess I'm interested to know if that is important to other > > > >> implementers, or if that was even the intention? > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> -Dave > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C > > > >> Rosen > > > >> *Sent:* Wednesday, February 08, 2017 11:53 AM > > > >> *To:* James N Guichard; sfc@ietf.org > > > >> *Subject:* Re: [sfc] NSH Service Index Decrement > > > >> > > > >> > > > >> > > > >> On 2/7/2017 2:24 PM, James N Guichard wrote: > > > >> > > > >> A request was made to be more specific and update the text as = follows: > > > >> > > > >> > > > >> > > > >> "Service index MUST be decremented *by a value of 1* by Service > > > >> Functions or by SFC Proxy nodes after performing required = services ." > > > >> > > > >> > > > >> A couple of observations: > > > >> > > > >> - The term "SFC Proxy node" is not defined in either the NSH > > > >> draft or in RFC 7665. I think the intention here is to say = "SFC Proxy". > > > >> > > > >> - Is the intention that the SI remain unchanged while the SF is > > > >> operating on the packet, or is the intention only that the SI = be > > > >> decremented before the packet is delivered by the SF or SFC = Proxy > > > >> to an SFF? > > > >> > > > >> I'd suggest either: > > > >> > > > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > > >> decrement the SI by 1 before delivering the packet to the next = SFF" > > > >> > > > >> or > > > >> > > > >> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > > >> decrement the SI by 1 before delivering the packet to the next > > > >> SFF, but not until the SF has finished all its other processing = of the packet" > > > >> > > > >> depending upon which is intended. > > > >> > > > >> I think an implication of these procedures is that an SI value = of > > > >> 1 is not valid. If an SF gets an NSH packet with an SI of 1, = the > > > >> SF will decrement the SI (setting it to 0), send the packet to = an > > > >> SFF, and the SFF will discard it, because 0 is an invalid SI > > > >> value. Is that the intention? > > > >> > > > >> The draft makes it clear (well, sort of) that an SFF should > > > >> discard a packet with an SI of 0, but does not seem to say that > > > >> an SF or SFC Proxy should discard a packet it receives with an = SI > > > >> of 0. It would probably be a good idea to say that. > > > >> > > > >> Some text in the draft (e.g., section 7.1) states than an SFF > > > >> should discard a packet with an SI of zero, but other text in = the > > > >> draft (e.g., section 3.3) only says that an SFF should log an > > > >> error if it sees an SI of zero. It's probably best to change = the > > > >> text in 3.3. to say "SHOULD generate an error/log message and > > > >> MUST discard the packet", or something similar. > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Feb 11 09:59:55 2017 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 7E7F41296C4 for ; Sat, 11 Feb 2017 09:59:53 -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, 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 fGy7UCQlOtXr for ; Sat, 11 Feb 2017 09:59:51 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C71E129A2E for ; Sat, 11 Feb 2017 09:59:51 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0319.002; Sat, 11 Feb 2017 09:59:50 -0800 From: Ron Parker To: "Joel M. Halpern" , "adrian@olddog.co.uk" , 'Dave Dolson' Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkAAeZjIw//6oW4D//33gw4AAqsEAgAASngCAASFmAIAAiOAAgAEwB4CAAIMaAP//jNyAgAB+Z8A= Date: Sat, 11 Feb 2017 17:59:49 +0000 Message-ID: References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> In-Reply-To: <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [100.0.27.181] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , 'James N Guichard' , "'Dolganow, Andrew \(Nokia - SG\)'" , 'Eric C Rosen' , 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 17:59:53 -0000 Hi, Joel. Does your comment pertain to my somewhat off topic question which was relat= ed to one of Adrian's tangential issues, or to Adrian's original SF=3D1 top= ic? Thanks. Ron -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Saturday, February 11, 2017 12:31 PM To: Ron Parker ; adrian@olddog.co.uk; 'Dav= e Dolson' Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - SG)' ; sfc@ietf.org; 'James N Guichard' ; 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement Personally, what you describe sounds like a quite reasonable case where a p= acket arrive at the SF with an SI of 1 will produce exactly the desired beh= avior. Which suggests, to my limited view, that the current text works fine. Yours, Joel On 2/11/17 11:55 AM, Ron Parker wrote: > Hi, Adrian. > > Not the original topic, per se, but wrt your comment: > > * On the other hand, we appear to be clear about an SF that strips the NS= H and forwards the traffic as native : this is currently forbidden. > > I'm wondering how to reconcile this to a transparent HTTP Proxy that does= not preserve the original source-IP? Does this mean that it is mandatory= for such an SF to also be a classifier so it can self-classify its own rel= ated flows (i.e., using its own visible IP addresses)? From SFF perspect= ive, it would look like all packets on the access side are dropped in the u= pstream direction and injected by the SF in the downstream direction. On = the Internet side, it would look like all packets are injected by the SF in= the upstream direction and dropped in the downstream direction. > > Thanks for any clarification. > > Ron > > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Saturday, February 11, 2017 11:34 AM > To: 'Dave Dolson' ; 'Joel M. Halpern'=20 > ; Ron Parker > Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia -=20 > SG)' ; sfc@ietf.org; 'James N Guichard'=20 > ; 'Fabricio Ferraz'=20 > > Subject: RE: [sfc] NSH Service Index Decrement > > I hate to do my impersonation of Eric, but... > > "On the wire" is the crunch. > > Some have said that there must be no visible difference between the three= case: > - on the wire between SFF and SF > - on the wire between SF and SFF > - on the wire between SFF and SFF > > If this holds then you are correct that sending SI=3D1 in the first case = requires the SF to do more than a simple decrement (although decrement and = discard is hardly painful). And it means that SI=3D1 is a dubious value in = an SFP. > > On the other hand, we appear to be clear about an SF that strips the NSH = and forwards the traffic as native : this is currently forbidden. So there = is no alternative for an SF receiving SI=3D1 except to discard the packet. > > Now, does that mean that an SFF should never send a packet with SI=3D1? W= ell, possibly it is OK for a few specialist SFs intended to sit at the end = of the chain and be a bit bucket with analysis. But, for most SFs there wou= ld be no point. > > Maybe (just maybe) we should stop letting the tail wag the dog! That is, = let's decide on the functional behavior we want to see and then design the = protocol to match. > > Adrian > >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: 10 February 2017 22:26 >> To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' >> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;=20 >> 'James N Guichard'; 'Fabricio Ferraz' >> Subject: RE: [sfc] NSH Service Index Decrement >> >> Adrian, >> I think I agree with everything you said. >> But you did not suggest whether or not you think that SI=3D0 should be=20 >> valid on > the >> wire. >> I'm saying it could work, if the next hop is a path terminus. >> >> If I understand Joel correctly, he says we shouldn't send SI=3D0 in=20 >> case the > next >> hop blindly decrements it. >> --> this seems to mean SI=3D1 cannot be used except at the terminus or=20 >> --> when the >> SF is expected to drop all packets. >> So I think this is an unnecessary seat belt, trying to anticipate=20 >> bugs in > down- >> stream devices. >> >> I realize the current language has been there a long time, and if it=20 >> is > important to >> anyone then it should remain. >> Nonetheless, I think devices could safely handle SI=3D0 on the wire=20 >> without breaking anything. >> >> But I'm not pushing for a change, since the current behavior seems=20 >> important > to >> some. >> >> -Dave >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel >> Sent: Friday, February 10, 2017 9:16 AM >> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' >> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;=20 >> 'James N Guichard'; 'Fabricio Ferraz' >> Subject: Re: [sfc] NSH Service Index Decrement >> >> Oh, you finally pushed me into this discussion, Dave. >> >> We're building a protocol. with a protocol, you cannot (must not)=20 >> assume good behavior from your neighbor. >> >> So if the SF touches the SI (which it does) we must define the edge > conditions. >> If it is the SF's job to decrement the SI, then we must also define=20 >> what it > does >> when SI=3D0 (otherwise, it will set SI to 0-1). >> If the SF is not allowed to decrement the SI below zero (which makes >> sense) we must define what it must do. >> Since SFs are allowed to drop packets (indeed that is one of their=20 >> main jobs > ;-) >> then this would be fine. >> All that would be left is to define whether they apply the test=20 >> before or > after >> normal processing. >> >> As an aside, I agree with Don that TTL helps relax this a little, but=20 >> does not get us all the way there. >> >> Cheers, >> Adrian >> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: 09 February 2017 21:00 >>> To: Joel M. Halpern; Ron Parker >>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C Rosen;=20 >>> Dolganow, Andrew (Nokia - SG) >>> Subject: Re: [sfc] NSH Service Index Decrement >>> >>> Discussing misconfigured SFFs is a straw-man argument. Once one=20 >>> starts > trying >> to >>> anticipate down-stream devices being misconfigured, one can invent a=20 >>> lot of >> silly >>> requirements. >>> >>> >From an aesthetic point of view, I think it's bad that there are >>>> two SI >> values (0 >>> and 1) that cannot be used. >>> >>> The real requirement, IMO, is that no device decrements 0 and forwards = NSH. >>> Since only SFs decrement SI, only SFs need to do this check. >>> >>> And any discussion about buggy SFs... well there is a lot of bad=20 >>> stuff that >> bugs can >>> cause. >>> >>> >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Thursday, February 09, 2017 2:54 PM >>> To: Ron Parker; Dave Dolson >>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); James=20 >>> N >> Guichard; >>> Fabricio Ferraz >>> Subject: Re: [sfc] NSH Service Index Decrement >>> >>> From my perspective as an individual participant in this work,=20 >>> declaring that 0 must be dropped is a matter of robustness. >>> >>> if we allow 0 to be processed for exit at an SFF, then a=20 >>> mis-configured SFF could easily continue processing such a packet. >>> Now, it is true that TTL will eventually drop it, but that is an expens= ive fallback. >>> >>> More importantly, presumably the next entitiy down the incorrect=20 >>> path would drop it for a 255 SI. But at that point we are getting=20 >>> the error in the wrong place, making it harder to diagnose and repair. >>> >>> Yours, >>> Joel >>> >>> On 2/9/17 12:42 PM, Ron Parker wrote: >>>> agree. >>>> >>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson >>> > wrote: >>>> >>>>> I'm not clear on why this is broken, or why this restriction is made. >>>>> >>>>> I agree it should not be sent to an SF, but an SFF could map an SI=20 >>>>> of zero into a path termination. >>>>> >>>>> I.e., the last SF in a path could decrement SI from 1 to 0, and=20 >>>>> the SFF could then terminate the chain. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N=20 >>>>> Guichard >>>>> *Sent:* Thursday, February 09, 2017 12:02 PM >>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson;=20 >>>>> Eric C Rosen; sfc@ietf.org >>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Not exactly. Section 3.3 specifies "The value zero for SI is not=20 >>>>> valid and indicates a broken SFC or malfunctioning SF" .. In other=20 >>>>> words an SF should never receive an NSH packet with SI =3D 0. >>>>> Note that if this happened then either a) a classifier set the SI=20 >>>>> incorrectly, or b) a re-classifier set the SI incorrectly, or c)=20 >>>>> an upstream SF set the SI incorrectly; all of these cases should=20 >>>>> be caught by the SFF whose job it is to discard NSH packets with SI = =3D 0. >>>>> >>>>> >>>>> >>>>> Jim >>>>> >>>>> >>>>> >>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >>>>> *Sent:* Thursday, February 09, 2017 11:49 AM >>>>> *To:* James N Guichard >>>> >; Dolganow, Andrew (Nokia - >>>>> SG) >>>> >; >>> Dave >>>>> Dolson >; Eric=20 >>>>> C Rosen >;=20 >>>>> sfc@ietf.org >>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Hi Jim, >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> One more question about the SI. >>>>> >>>>> >>>>> >>>>> Section 3 states that: >>>>> >>>>> >>>>> >>>>> Service Index (SI): provides location within the SFP. The initial=20 >>>>> classifier MUST set the appropriate SI value for a given=20 >>>>> classification result. The initial SI value SHOULD default to 255. >>>>> However, the classifier MUST allow configuration of other SI values. >>>>> >>>>> Service Index MUST be decremented by Service Functions or by SFC=20 >>>>> Proxy nodes after performing required services and the new=20 >>>>> decremented SI value MUST be used in the egress NSH packet. >>>>> >>>>> The initial Classifier MUST send the packet to the first SFF in=20 >>>>> the identified SFP for forwarding along an SFP. >>>>> >>>>> If re-classification occurs, and that re-classification results in=20 >>>>> a new SPI, the (re)classifier is, in effect, the initial=20 >>>>> classifier for the resultant SPI. >>>>> >>>>> >>>>> >>>>> Thus: >>>>> >>>>> a) Initial SI value should be 255 but other values can be >>>>> configured by the classifier. >>>>> >>>>> b) SF decrements the SI value on the egress NSH packet >>>>> >>>>> c) If re-classification occurs with new SPI, the re-classifier >>>>> is the initial classifier, so by a), SI should be again 255 or=20 >>>>> other value >>>>> >>>>> >>>>> >>>>> So any SI value can be receive by an SF, even 1 or 0 because: >>>>> >>>>> =E8If SI=3D1 and there is no re-classification, the egress NSH will=20 >>>>> have SI=3D0 >>>>> >>>>> =E8If SI=3D0 and there is re-classification with new SPI, the egress= =20 >>>>> NSH will have a new SPI and a SI=3D 255 or other value, as stated in = a). >>>>> >>>>> =E8If SI=3D0 and there is no re-classification the SF should discard= =20 >>>>> the packet >>>>> >>>>> >>>>> >>>>> Also an SFF should forward/handle packets with NSH with SI=3D1 or SI= =3D0. >>>>> >>>>> >>>>> >>>>> Do you agree? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N=20 >>>>> Guichard >>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 >>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson;=20 >>>>> Eric C Rosen; sfc@ietf.org >>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Hi Fabricio, >>>>> >>>>> >>>>> >>>>> Welcome! >>>>> >>>>> >>>>> >>>>> Yes, removal of NSH is the responsibility of an SFF or a=20 >>>>> re-classifier (section 4, bullet point 1 lays this out). With the=20 >>>>> current architecture the SF does not care what SI value it gets,=20 >>>>> it just needs to worry about decrementing it, and leave it up to=20 >>>>> the SFF to evaluate the SI value and associated action. >>>>> >>>>> >>>>> >>>>> Jim >>>>> >>>>> >>>>> >>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >>>>> *Sent:* Thursday, February 09, 2017 7:13 AM >>>>> *To:* Dolganow, Andrew (Nokia - SG) >>>> >; Dave Dolson >>> >>>> >; Eric C Rosen >>>> >; James N Guichard=20 >>>>> > >; >>>>> sfc@ietf.org >>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> I'm new here (just read the draft last week) but according to=20 >>>>> chapter >>>>> 4 (check figure 8 for example), an SF is not allowed to insert or=20 >>>>> remove NSH. The removal of NSH is reponsability of the SSF, right? >>>>> >>>>> >>>>> >>>>> Figure 8 maps each of the four actions above to the components=20 >>>>> in the >>>>> >>>>> SFC architecture that can perform it. >>>>> >>>>> >>>>> >>>>> +---------------+------------------+-------+----------------+--------= -+ >>>>> >>>>> | | Insert |Select | Update |Service = | >>>>> >>>>> | | or remove NSH |Service| NSH |policy = | >>>>> >>>>> | | |Function| |selectio= n| >>>>> >>>>> | Component +--------+--------+Path +----------------+ = | >>>>> >>>>> | | | | | Dec. |Update | = | >>>>> >>>>> | | Insert | Remove | |Service |Context| = | >>>>> >>>>> | | | | | Index |Header | = | >>>>> >>>>> +----------------+--------+--------+-------+--------+-------+--------= -+ >>>>> >>>>> | | + | + | | | + | = | >>>>> >>>>> |Classifier | | | | | | = | >>>>> >>>>> +--------------- >>>>> ++--------+--------+-------+--------+-------+---------+ >>>>> >>>>> |Service Function| | + | + | | | = | >>>>> >>>>> |Forwarder(SFF) | | | | | | = | >>>>> >>>>> +--------------- >>>>> ++--------+--------+-------+--------+-------+---------+ >>>>> >>>>> |Service | | | | + | + | + = | >>>>> >>>>> |Function (SF) | | | | | | = | >>>>> >>>>> +--------------- >>>>> ++--------+--------+-------+--------+-------+---------+ >>>>> >>>>> |SFC Proxy | + | + | | + | | = | >>>>> >>>>> +----------------+--------+--------+-------+--------+-------+--------= -+ >>>>> >>>>> >>>>> >>>>> Figure 8: NSH Action and Role Mapping >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> An SF could receive an NSH packet with an SI of 1, and reclassify=20 >>>>> it to a different SPI and SI, right? So when a SF receives a NSH=20 >>>>> packet with SI =3D 1 that does not necessarily means a non valid pack= et. >>>>> >>>>> And that can even work for SI=3D0, since you decrement the SI in the > egress. >>>>> >>>>> >>>>> >>>>> Fabricio >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, >>>>> Andrew (Nokia - SG) >>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 >>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org >>>>> >>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> I assumed that if we get value 1 we process then forward without >>>>> NSH header (i.e.) this is the last SF processing. >>>>> >>>>> >>>>> >>>>> So with that assumption, a more explicit text would be: >>>>> >>>>> >>>>> >>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >>>>> decrement the SI by 1 after performing all required local >>>>> processing and before forwarding the packet to the next SFF. If >>>>> the resulting SI is 0, the SF MUST remove the NSH header before forwa= rding the packet. >>>>> >>>>> >>>>> >>>>> Andrew >>>>> >>>>> *From: *sfc > >>>>> on behalf of Dave Dolson >> > >>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM >>>>> *To: *Eric Rosen >>>> >, James N Guichard >>>>> >>>> >, "sfc@ietf.org >>>>> " > >>>>> *Subject: *Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> Eric, >>>>> >>>>> I was never quite happy with the outcome that neither 0 nor 1 is >>>>> a valid SI. >>>>> >>>>> (Because if received with value of 1, it is decremented and >>>>> discarded.) >>>>> >>>>> >>>>> >>>>> It seems to waste an index value. >>>>> >>>>> >>>>> >>>>> I guess I'm interested to know if that is important to other >>>>> implementers, or if that was even the intention? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -Dave >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C >>>>> Rosen >>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM >>>>> *To:* James N Guichard; sfc@ietf.org >>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>> >>>>> >>>>> >>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: >>>>> >>>>> A request was made to be more specific and update the text as follows= : >>>>> >>>>> >>>>> >>>>> "Service index MUST be decremented *by a value of 1* by Service >>>>> Functions or by SFC Proxy nodes after performing required services ." >>>>> >>>>> >>>>> A couple of observations: >>>>> >>>>> - The term "SFC Proxy node" is not defined in either the NSH >>>>> draft or in RFC 7665. I think the intention here is to say "SFC Prox= y". >>>>> >>>>> - Is the intention that the SI remain unchanged while the SF is >>>>> operating on the packet, or is the intention only that the SI be >>>>> decremented before the packet is delivered by the SF or SFC Proxy >>>>> to an SFF? >>>>> >>>>> I'd suggest either: >>>>> >>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >>>>> decrement the SI by 1 before delivering the packet to the next SFF" >>>>> >>>>> or >>>>> >>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >>>>> decrement the SI by 1 before delivering the packet to the next >>>>> SFF, but not until the SF has finished all its other processing of th= e packet" >>>>> >>>>> depending upon which is intended. >>>>> >>>>> I think an implication of these procedures is that an SI value of >>>>> 1 is not valid. If an SF gets an NSH packet with an SI of 1, the >>>>> SF will decrement the SI (setting it to 0), send the packet to an >>>>> SFF, and the SFF will discard it, because 0 is an invalid SI >>>>> value. Is that the intention? >>>>> >>>>> The draft makes it clear (well, sort of) that an SFF should >>>>> discard a packet with an SI of 0, but does not seem to say that >>>>> an SF or SFC Proxy should discard a packet it receives with an SI >>>>> of 0. It would probably be a good idea to say that. >>>>> >>>>> Some text in the draft (e.g., section 7.1) states than an SFF >>>>> should discard a packet with an SI of zero, but other text in the >>>>> draft (e.g., section 3.3) only says that an SFF should log an >>>>> error if it sees an SI of zero. It's probably best to change the >>>>> text in 3.3. to say "SHOULD generate an error/log message and >>>>> MUST discard the packet", or something similar. >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Sat Feb 11 10:07:38 2017 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 9211B129A34 for ; Sat, 11 Feb 2017 10:07:36 -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_HELO_PASS=-0.001, 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 Zg8LmEBfEKTE for ; Sat, 11 Feb 2017 10:07:33 -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 A4785129A33 for ; Sat, 11 Feb 2017 10:07:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8C9EB24066E; Sat, 11 Feb 2017 10:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486836453; bh=kusDVbN5A4TAdnDgXnOlYp309lvhEupGdLBmOjB3Piw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=N83UKm2RSspRS7u2Lte8yvf4jsnX+J/eY70bAYdNFOGXEJFInpOuZbW2L/l5RDZ+L 8Y31M436txmJn7+T1r5ShM1wnNfJ4b4WPGebp8NMs150Y81kMLmzNRY//TS+cM8JP6 0YegTVyNXSLN7OmoMDcGi0c29bxUoKdWm9jhl3CU= 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 7E110240655; Sat, 11 Feb 2017 10:07:32 -0800 (PST) To: Ron Parker , "adrian@olddog.co.uk" , 'Dave Dolson' References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> Date: Sat, 11 Feb 2017 13:07:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" , 'James N Guichard' , "'Dolganow, Andrew \(Nokia - SG\)'" , 'Eric C Rosen' , 'Fabricio Ferraz' Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 18:07:36 -0000 I was commenting, in personal hat, about the issue of whether there was some sort of problem with the impact of the current description on SI=1 packets arriving at an SF. It seems to me that your example shows that such an effect is sometimes useul. It will also sometimes produce packet drops by the SFF, when the SF does not terminate the packet. Okay, so be it. It is not even clear there is anything, in Adrian's phrase, to paint red here. Yours, Joel On 2/11/17 12:59 PM, Ron Parker wrote: > Hi, Joel. > > Does your comment pertain to my somewhat off topic question which was related to one of Adrian's tangential issues, or to Adrian's original SF=1 topic? > > Thanks. > > Ron > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Saturday, February 11, 2017 12:31 PM > To: Ron Parker ; adrian@olddog.co.uk; 'Dave Dolson' > Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - SG)' ; sfc@ietf.org; 'James N Guichard' ; 'Fabricio Ferraz' > Subject: Re: [sfc] NSH Service Index Decrement > > Personally, what you describe sounds like a quite reasonable case where a packet arrive at the SF with an SI of 1 will produce exactly the desired behavior. > > Which suggests, to my limited view, that the current text works fine. > > Yours, > Joel > > On 2/11/17 11:55 AM, Ron Parker wrote: >> Hi, Adrian. >> >> Not the original topic, per se, but wrt your comment: >> >> * On the other hand, we appear to be clear about an SF that strips the NSH and forwards the traffic as native : this is currently forbidden. >> >> I'm wondering how to reconcile this to a transparent HTTP Proxy that does not preserve the original source-IP? Does this mean that it is mandatory for such an SF to also be a classifier so it can self-classify its own related flows (i.e., using its own visible IP addresses)? From SFF perspective, it would look like all packets on the access side are dropped in the upstream direction and injected by the SF in the downstream direction. On the Internet side, it would look like all packets are injected by the SF in the upstream direction and dropped in the downstream direction. >> >> Thanks for any clarification. >> >> Ron >> >> >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Saturday, February 11, 2017 11:34 AM >> To: 'Dave Dolson' ; 'Joel M. Halpern' >> ; Ron Parker >> Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - >> SG)' ; sfc@ietf.org; 'James N Guichard' >> ; 'Fabricio Ferraz' >> >> Subject: RE: [sfc] NSH Service Index Decrement >> >> I hate to do my impersonation of Eric, but... >> >> "On the wire" is the crunch. >> >> Some have said that there must be no visible difference between the three case: >> - on the wire between SFF and SF >> - on the wire between SF and SFF >> - on the wire between SFF and SFF >> >> If this holds then you are correct that sending SI=1 in the first case requires the SF to do more than a simple decrement (although decrement and discard is hardly painful). And it means that SI=1 is a dubious value in an SFP. >> >> On the other hand, we appear to be clear about an SF that strips the NSH and forwards the traffic as native : this is currently forbidden. So there is no alternative for an SF receiving SI=1 except to discard the packet. >> >> Now, does that mean that an SFF should never send a packet with SI=1? Well, possibly it is OK for a few specialist SFs intended to sit at the end of the chain and be a bit bucket with analysis. But, for most SFs there would be no point. >> >> Maybe (just maybe) we should stop letting the tail wag the dog! That is, let's decide on the functional behavior we want to see and then design the protocol to match. >> >> Adrian >> >>> -----Original Message----- >>> From: Dave Dolson [mailto:ddolson@sandvine.com] >>> Sent: 10 February 2017 22:26 >>> To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; >>> 'James N Guichard'; 'Fabricio Ferraz' >>> Subject: RE: [sfc] NSH Service Index Decrement >>> >>> Adrian, >>> I think I agree with everything you said. >>> But you did not suggest whether or not you think that SI=0 should be >>> valid on >> the >>> wire. >>> I'm saying it could work, if the next hop is a path terminus. >>> >>> If I understand Joel correctly, he says we shouldn't send SI=0 in >>> case the >> next >>> hop blindly decrements it. >>> --> this seems to mean SI=1 cannot be used except at the terminus or >>> --> when the >>> SF is expected to drop all packets. >>> So I think this is an unnecessary seat belt, trying to anticipate >>> bugs in >> down- >>> stream devices. >>> >>> I realize the current language has been there a long time, and if it >>> is >> important to >>> anyone then it should remain. >>> Nonetheless, I think devices could safely handle SI=0 on the wire >>> without breaking anything. >>> >>> But I'm not pushing for a change, since the current behavior seems >>> important >> to >>> some. >>> >>> -Dave >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel >>> Sent: Friday, February 10, 2017 9:16 AM >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; >>> 'James N Guichard'; 'Fabricio Ferraz' >>> Subject: Re: [sfc] NSH Service Index Decrement >>> >>> Oh, you finally pushed me into this discussion, Dave. >>> >>> We're building a protocol. with a protocol, you cannot (must not) >>> assume good behavior from your neighbor. >>> >>> So if the SF touches the SI (which it does) we must define the edge >> conditions. >>> If it is the SF's job to decrement the SI, then we must also define >>> what it >> does >>> when SI=0 (otherwise, it will set SI to 0-1). >>> If the SF is not allowed to decrement the SI below zero (which makes >>> sense) we must define what it must do. >>> Since SFs are allowed to drop packets (indeed that is one of their >>> main jobs >> ;-) >>> then this would be fine. >>> All that would be left is to define whether they apply the test >>> before or >> after >>> normal processing. >>> >>> As an aside, I agree with Don that TTL helps relax this a little, but >>> does not get us all the way there. >>> >>> Cheers, >>> Adrian >>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>>> Sent: 09 February 2017 21:00 >>>> To: Joel M. Halpern; Ron Parker >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C Rosen; >>>> Dolganow, Andrew (Nokia - SG) >>>> Subject: Re: [sfc] NSH Service Index Decrement >>>> >>>> Discussing misconfigured SFFs is a straw-man argument. Once one >>>> starts >> trying >>> to >>>> anticipate down-stream devices being misconfigured, one can invent a >>>> lot of >>> silly >>>> requirements. >>>> >>>> >From an aesthetic point of view, I think it's bad that there are >>>>> two SI >>> values (0 >>>> and 1) that cannot be used. >>>> >>>> The real requirement, IMO, is that no device decrements 0 and forwards NSH. >>>> Since only SFs decrement SI, only SFs need to do this check. >>>> >>>> And any discussion about buggy SFs... well there is a lot of bad >>>> stuff that >>> bugs can >>>> cause. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Thursday, February 09, 2017 2:54 PM >>>> To: Ron Parker; Dave Dolson >>>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); James >>>> N >>> Guichard; >>>> Fabricio Ferraz >>>> Subject: Re: [sfc] NSH Service Index Decrement >>>> >>>> From my perspective as an individual participant in this work, >>>> declaring that 0 must be dropped is a matter of robustness. >>>> >>>> if we allow 0 to be processed for exit at an SFF, then a >>>> mis-configured SFF could easily continue processing such a packet. >>>> Now, it is true that TTL will eventually drop it, but that is an expensive fallback. >>>> >>>> More importantly, presumably the next entitiy down the incorrect >>>> path would drop it for a 255 SI. But at that point we are getting >>>> the error in the wrong place, making it harder to diagnose and repair. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/9/17 12:42 PM, Ron Parker wrote: >>>>> agree. >>>>> >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson >>>> > wrote: >>>>> >>>>>> I'm not clear on why this is broken, or why this restriction is made. >>>>>> >>>>>> I agree it should not be sent to an SF, but an SFF could map an SI >>>>>> of zero into a path termination. >>>>>> >>>>>> I.e., the last SF in a path could decrement SI from 1 to 0, and >>>>>> the SFF could then terminate the chain. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N >>>>>> Guichard >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; >>>>>> Eric C Rosen; sfc@ietf.org >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>>> >>>>>> >>>>>> >>>>>> Not exactly. Section 3.3 specifies "The value zero for SI is not >>>>>> valid and indicates a broken SFC or malfunctioning SF" .. In other >>>>>> words an SF should never receive an NSH packet with SI = 0. >>>>>> Note that if this happened then either a) a classifier set the SI >>>>>> incorrectly, or b) a re-classifier set the SI incorrectly, or c) >>>>>> an upstream SF set the SI incorrectly; all of these cases should >>>>>> be caught by the SFF whose job it is to discard NSH packets with SI = 0. >>>>>> >>>>>> >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM >>>>>> *To:* James N Guichard >>>>> >; Dolganow, Andrew (Nokia - >>>>>> SG) >>>>> >; >>>> Dave >>>>>> Dolson >; Eric >>>>>> C Rosen >; >>>>>> sfc@ietf.org >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >>>>>> >>>>>> >>>>>> >>>>>> Hi Jim, >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> >>>>>> One more question about the SI. >>>>>> >>>>>> >>>>>> >>>>>> Section 3 states that: >>>>>> >>>>>> >>>>>> >>>>>> Service Index (SI): provides location within the SFP. The initial >>>>>> classifier MUST set the appropriate SI value for a given >>>>>> classification result. The initial SI value SHOULD default to 255. >>>>>> However, the classifier MUST allow configuration of other SI values. >>>>>> >>>>>> Service Index MUST be decremented by Service Functions or by SFC >>>>>> Proxy nodes after performing required services and the new >>>>>> decremented SI value MUST be used in the egress NSH packet. >>>>>> >>>>>> The initial Classifier MUST send the packet to the first SFF in >>>>>> the identified SFP for forwarding along an SFP. >>>>>> >>>>>> If re-classification occurs, and that re-classification results in >>>>>> a new SPI, the (re)classifier is, in effect, the initial >>>>>> classifier for the resultant SPI. >>>>>> >>>>>> >>>>>> >>>>>> Thus: >>>>>> >>>>>> a) Initial SI value should be 255 but other values can be >>>>>> configured by the classifier. >>>>>> >>>>>> b) SF decrements the SI value on the egress NSH packet >>>>>> >>>>>> c) If re-classification occurs with new SPI, the re-classifier >>>>>> is the initial classifier, so by a), SI should be again 255 or >>>>>> other value >>>>>> >>>>>> >>>>>> >>>>>> So any SI value can be receive by an SF, even 1 or 0 because: >>>>>> >>>>>> èIf SI=1 and there is no re-classification, the egress NSH will >>>>>> have SI=0 >>>>>> >>>>>> èIf SI=0 and there is re-classification with new SPI, the egress >>>>>> NSH will have a new SPI and a SI= 255 or other value, as stated in a). >>>>>> >>>>>> èIf SI=0 and there is no re-classification the SF should discard >>>>>> the packet >>>>>> >>>>>> >>>>>> >>>>>> Also an SFF should forward/handle packets with NSH with SI=1 or SI=0. >>>>>> >>>>>> >>>>>> >>>>>> Do you agree? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N >>>>>> Guichard >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave Dolson; >>>>>> Eric C Rosen; sfc@ietf.org >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>>> >>>>>> >>>>>> >>>>>> Hi Fabricio, >>>>>> >>>>>> >>>>>> >>>>>> Welcome! >>>>>> >>>>>> >>>>>> >>>>>> Yes, removal of NSH is the responsibility of an SFF or a >>>>>> re-classifier (section 4, bullet point 1 lays this out). With the >>>>>> current architecture the SF does not care what SI value it gets, >>>>>> it just needs to worry about decrementing it, and leave it up to >>>>>> the SFF to evaluate the SI value and associated action. >>>>>> >>>>>> >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] >>>>>> *Sent:* Thursday, February 09, 2017 7:13 AM >>>>>> *To:* Dolganow, Andrew (Nokia - SG) >>>>> >; Dave Dolson >>>> >>>>> >; Eric C Rosen >>>>> >; James N Guichard >>>>>> >> >; >>>>>> sfc@ietf.org >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >>>>>> >>>>>> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm new here (just read the draft last week) but according to >>>>>> chapter >>>>>> 4 (check figure 8 for example), an SF is not allowed to insert or >>>>>> remove NSH. The removal of NSH is reponsability of the SSF, right? >>>>>> >>>>>> >>>>>> >>>>>> Figure 8 maps each of the four actions above to the components >>>>>> in the >>>>>> >>>>>> SFC architecture that can perform it. >>>>>> >>>>>> >>>>>> >>>>>> +---------------+------------------+-------+----------------+---------+ >>>>>> >>>>>> | | Insert |Select | Update |Service | >>>>>> >>>>>> | | or remove NSH |Service| NSH |policy | >>>>>> >>>>>> | | |Function| |selection| >>>>>> >>>>>> | Component +--------+--------+Path +----------------+ | >>>>>> >>>>>> | | | | | Dec. |Update | | >>>>>> >>>>>> | | Insert | Remove | |Service |Context| | >>>>>> >>>>>> | | | | | Index |Header | | >>>>>> >>>>>> +----------------+--------+--------+-------+--------+-------+---------+ >>>>>> >>>>>> | | + | + | | | + | | >>>>>> >>>>>> |Classifier | | | | | | | >>>>>> >>>>>> +--------------- >>>>>> ++--------+--------+-------+--------+-------+---------+ >>>>>> >>>>>> |Service Function| | + | + | | | | >>>>>> >>>>>> |Forwarder(SFF) | | | | | | | >>>>>> >>>>>> +--------------- >>>>>> ++--------+--------+-------+--------+-------+---------+ >>>>>> >>>>>> |Service | | | | + | + | + | >>>>>> >>>>>> |Function (SF) | | | | | | | >>>>>> >>>>>> +--------------- >>>>>> ++--------+--------+-------+--------+-------+---------+ >>>>>> >>>>>> |SFC Proxy | + | + | | + | | | >>>>>> >>>>>> +----------------+--------+--------+-------+--------+-------+---------+ >>>>>> >>>>>> >>>>>> >>>>>> Figure 8: NSH Action and Role Mapping >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> An SF could receive an NSH packet with an SI of 1, and reclassify >>>>>> it to a different SPI and SI, right? So when a SF receives a NSH >>>>>> packet with SI = 1 that does not necessarily means a non valid packet. >>>>>> >>>>>> And that can even work for SI=0, since you decrement the SI in the >> egress. >>>>>> >>>>>> >>>>>> >>>>>> Fabricio >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dolganow, >>>>>> Andrew (Nokia - SG) >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org >>>>>> >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>>> >>>>>> >>>>>> >>>>>> I assumed that if we get value 1 we process then forward without >>>>>> NSH header (i.e.) this is the last SF processing. >>>>>> >>>>>> >>>>>> >>>>>> So with that assumption, a more explicit text would be: >>>>>> >>>>>> >>>>>> >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >>>>>> decrement the SI by 1 after performing all required local >>>>>> processing and before forwarding the packet to the next SFF. If >>>>>> the resulting SI is 0, the SF MUST remove the NSH header before forwarding the packet. >>>>>> >>>>>> >>>>>> >>>>>> Andrew >>>>>> >>>>>> *From: *sfc > >>>>>> on behalf of Dave Dolson >>> > >>>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM >>>>>> *To: *Eric Rosen >>>>> >, James N Guichard >>>>>> >>>>> >, "sfc@ietf.org >>>>>> " > >>>>>> *Subject: *Re: [sfc] NSH Service Index Decrement >>>>>> >>>>>> >>>>>> >>>>>> Eric, >>>>>> >>>>>> I was never quite happy with the outcome that neither 0 nor 1 is >>>>>> a valid SI. >>>>>> >>>>>> (Because if received with value of 1, it is decremented and >>>>>> discarded.) >>>>>> >>>>>> >>>>>> >>>>>> It seems to waste an index value. >>>>>> >>>>>> >>>>>> >>>>>> I guess I'm interested to know if that is important to other >>>>>> implementers, or if that was even the intention? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C >>>>>> Rosen >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM >>>>>> *To:* James N Guichard; sfc@ietf.org >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>>>> >>>>>> >>>>>> >>>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: >>>>>> >>>>>> A request was made to be more specific and update the text as follows: >>>>>> >>>>>> >>>>>> >>>>>> "Service index MUST be decremented *by a value of 1* by Service >>>>>> Functions or by SFC Proxy nodes after performing required services ." >>>>>> >>>>>> >>>>>> A couple of observations: >>>>>> >>>>>> - The term "SFC Proxy node" is not defined in either the NSH >>>>>> draft or in RFC 7665. I think the intention here is to say "SFC Proxy". >>>>>> >>>>>> - Is the intention that the SI remain unchanged while the SF is >>>>>> operating on the packet, or is the intention only that the SI be >>>>>> decremented before the packet is delivered by the SF or SFC Proxy >>>>>> to an SFF? >>>>>> >>>>>> I'd suggest either: >>>>>> >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >>>>>> decrement the SI by 1 before delivering the packet to the next SFF" >>>>>> >>>>>> or >>>>>> >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST >>>>>> decrement the SI by 1 before delivering the packet to the next >>>>>> SFF, but not until the SF has finished all its other processing of the packet" >>>>>> >>>>>> depending upon which is intended. >>>>>> >>>>>> I think an implication of these procedures is that an SI value of >>>>>> 1 is not valid. If an SF gets an NSH packet with an SI of 1, the >>>>>> SF will decrement the SI (setting it to 0), send the packet to an >>>>>> SFF, and the SFF will discard it, because 0 is an invalid SI >>>>>> value. Is that the intention? >>>>>> >>>>>> The draft makes it clear (well, sort of) that an SFF should >>>>>> discard a packet with an SI of 0, but does not seem to say that >>>>>> an SF or SFC Proxy should discard a packet it receives with an SI >>>>>> of 0. It would probably be a good idea to say that. >>>>>> >>>>>> Some text in the draft (e.g., section 7.1) states than an SFF >>>>>> should discard a packet with an SI of zero, but other text in the >>>>>> draft (e.g., section 3.3) only says that an SFF should log an >>>>>> error if it sees an SI of zero. It's probably best to change the >>>>>> text in 3.3. to say "SHOULD generate an error/log message and >>>>>> MUST discard the packet", or something similar. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> > From nobody Sat Feb 11 14:35:53 2017 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 D1FC11294A9 for ; Sat, 11 Feb 2017 14:35:52 -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, 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 3k9MPsqnSD9l for ; Sat, 11 Feb 2017 14:35:49 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5F71293E9 for ; Sat, 11 Feb 2017 14:35:48 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1BMZhB4011463; Sat, 11 Feb 2017 22:35:43 GMT Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1BMZaEW011378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Feb 2017 22:35:41 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , "'Ron Parker'" References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> In-Reply-To: <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> Date: Sat, 11 Feb 2017 22:35:34 -0000 Message-ID: <0da701d284b7$2d115d40$873417c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHoYgY6PCVGpHJ8su3f5ejQO2dmKAM4JSWQAhYkhCMBHU+anQCFM5gDAmn9f8kBgE4xngJdM3REAj8zzvsB6Deh7wJQKkgbAo860icBexanZwFah2BmATjK/hagZjgykA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22880.003 X-TM-AS-Result: No--28.817-10.0-31-10 X-imss-scan-details: No--28.817-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtFUO3zzgy+7kIxVBvj1jbcj6Jj6zYvfFASjW0dPTeQGSSU7 43HF3fJ1iSQjy3ULNtuEepLbI+P7qLNFdXOVxOU0+z2c4lioPkg00EW1UQZMfVOmuHC2zOGYVMU 4b+eMC7qw6C/crbkfafXJWa4mud7gEZG6oCaQzfbY5KPiokD1BlsChor7BLiNDYbe/PyX8gQkqK kmBHHWQ3VX7TCv5oc0Nbr8C6zBJEBkJIFXpUIuNZpWgCLYjjT9EtdrY/Wb3fNGrRj9faLVBCAuD y6S9KFvzQ2zxNL6qw9dB3yEUbPuBqMR3guZ65sFq0reih3E9rGp8u/TGEilnH3hz57t9YhwP6oE tFD/y1eZBgqAuvN9COK9VvS8IPRnKgsbwct+M19Q1o+KC+IpHyPclXBzQ1O22qqh/6B8PpGos9s l9zeekRP9EsBIQczmVx7NpoHLKugiDrsceLMV4Wgws6g0ewz2GSqdEmeD/nWTMTaQzhvoeprXEN q9aJxM6SbnJ4iyEwB2yRJ7GQDa22pphDjoYgdDU+OjsPhIWDhkBDPLxNH5BhZ50KsQddqXTakPH +NO07HYeC0T8aHtCiDgAgUZciiAQyNrw2ay5caDSLwqgARqiFAsG9fXVGlJSI7wNf2EvtENglBs 2cTdnXD4f/5oTgtq747pJRuETOlGpu6xOWqZa5BKN02nRyYw7h2RrsKOiu3gb8WBYTcHTPBUq5J suvxSlo2CXKh1Du0DTO7t0MJ81U7YDfWPiC7G58dk5sbwmyheBoX6ocFAsuzKYenbqbY44yXKVM bo6LQI0P7e1yDUuSYZP4JD7us6tJieP4rjvdmeAiCmPx4NwGNn8XPiALIbooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 22:35:53 -0000 Joel, The -10 version of NSH says The value zero for SI is not valid and indicates a broken SFC or malfunctioning SF. You are saying that the latter of these is not true. I can't tell whether the former is really true or, perhaps, represents a = discard tail of an SFC where some (but not all) packets are reclassified per = Ron. Like I said: > Let's clarify that it is OK for an SF to send a packet with SI=3D0 Then (of course) it is also OK for an SFF to receive SI=3D0, but I think = the existing "discard" text covers that case. Adrian > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 11 February 2017 18:08 > To: Ron Parker; adrian@olddog.co.uk; 'Dave Dolson' > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; = 'James N > Guichard'; 'Fabricio Ferraz' > Subject: Re: [sfc] NSH Service Index Decrement >=20 > I was commenting, in personal hat, about the issue of whether there = was > some sort of problem with the impact of the current description on = SI=3D1 > packets arriving at an SF. It seems to me that your example shows = that > such an effect is sometimes useul. > It will also sometimes produce packet drops by the SFF, when the SF = does > not terminate the packet. Okay, so be it. > It is not even clear there is anything, in Adrian's phrase, to paint = red > here. >=20 > Yours, > Joel >=20 > On 2/11/17 12:59 PM, Ron Parker wrote: > > Hi, Joel. > > > > Does your comment pertain to my somewhat off topic question which = was > related to one of Adrian's tangential issues, or to Adrian's original = SF=3D1 topic? > > > > Thanks. > > > > Ron > > > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Saturday, February 11, 2017 12:31 PM > > To: Ron Parker ; = adrian@olddog.co.uk; > 'Dave Dolson' > > Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - = SG)' > ; sfc@ietf.org; 'James N Guichard' > ; 'Fabricio Ferraz' = > > Subject: Re: [sfc] NSH Service Index Decrement > > > > Personally, what you describe sounds like a quite reasonable case = where a > packet arrive at the SF with an SI of 1 will produce exactly the = desired behavior. > > > > Which suggests, to my limited view, that the current text works = fine. > > > > Yours, > > Joel > > > > On 2/11/17 11:55 AM, Ron Parker wrote: > >> Hi, Adrian. > >> > >> Not the original topic, per se, but wrt your comment: > >> > >> * On the other hand, we appear to be clear about an SF that strips = the NSH > and forwards the traffic as native : this is currently forbidden. > >> > >> I'm wondering how to reconcile this to a transparent HTTP Proxy = that does not > preserve the original source-IP? Does this mean that it is mandatory = for such an > SF to also be a classifier so it can self-classify its own related = flows (i.e., using its > own visible IP addresses)? From SFF perspective, it would look like = all packets > on the access side are dropped in the upstream direction and injected = by the SF > in the downstream direction. On the Internet side, it would look = like all packets > are injected by the SF in the upstream direction and dropped in the = downstream > direction. > >> > >> Thanks for any clarification. > >> > >> Ron > >> > >> > >> > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: Saturday, February 11, 2017 11:34 AM > >> To: 'Dave Dolson' ; 'Joel M. Halpern' > >> ; Ron Parker > >> Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - > >> SG)' ; sfc@ietf.org; 'James N Guichard' > >> ; 'Fabricio Ferraz' > >> > >> Subject: RE: [sfc] NSH Service Index Decrement > >> > >> I hate to do my impersonation of Eric, but... > >> > >> "On the wire" is the crunch. > >> > >> Some have said that there must be no visible difference between the = three > case: > >> - on the wire between SFF and SF > >> - on the wire between SF and SFF > >> - on the wire between SFF and SFF > >> > >> If this holds then you are correct that sending SI=3D1 in the first = case requires > the SF to do more than a simple decrement (although decrement and = discard is > hardly painful). And it means that SI=3D1 is a dubious value in an = SFP. > >> > >> On the other hand, we appear to be clear about an SF that strips = the NSH and > forwards the traffic as native : this is currently forbidden. So there = is no > alternative for an SF receiving SI=3D1 except to discard the packet. > >> > >> Now, does that mean that an SFF should never send a packet with = SI=3D1? Well, > possibly it is OK for a few specialist SFs intended to sit at the end = of the chain and > be a bit bucket with analysis. But, for most SFs there would be no = point. > >> > >> Maybe (just maybe) we should stop letting the tail wag the dog! = That is, let's > decide on the functional behavior we want to see and then design the = protocol > to match. > >> > >> Adrian > >> > >>> -----Original Message----- > >>> From: Dave Dolson [mailto:ddolson@sandvine.com] > >>> Sent: 10 February 2017 22:26 > >>> To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; > >>> 'James N Guichard'; 'Fabricio Ferraz' > >>> Subject: RE: [sfc] NSH Service Index Decrement > >>> > >>> Adrian, > >>> I think I agree with everything you said. > >>> But you did not suggest whether or not you think that SI=3D0 = should be > >>> valid on > >> the > >>> wire. > >>> I'm saying it could work, if the next hop is a path terminus. > >>> > >>> If I understand Joel correctly, he says we shouldn't send SI=3D0 = in > >>> case the > >> next > >>> hop blindly decrements it. > >>> --> this seems to mean SI=3D1 cannot be used except at the = terminus or > >>> --> when the > >>> SF is expected to drop all packets. > >>> So I think this is an unnecessary seat belt, trying to anticipate > >>> bugs in > >> down- > >>> stream devices. > >>> > >>> I realize the current language has been there a long time, and if = it > >>> is > >> important to > >>> anyone then it should remain. > >>> Nonetheless, I think devices could safely handle SI=3D0 on the = wire > >>> without breaking anything. > >>> > >>> But I'm not pushing for a change, since the current behavior seems > >>> important > >> to > >>> some. > >>> > >>> -Dave > >>> > >>> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > >>> Sent: Friday, February 10, 2017 9:16 AM > >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; > >>> 'James N Guichard'; 'Fabricio Ferraz' > >>> Subject: Re: [sfc] NSH Service Index Decrement > >>> > >>> Oh, you finally pushed me into this discussion, Dave. > >>> > >>> We're building a protocol. with a protocol, you cannot (must not) > >>> assume good behavior from your neighbor. > >>> > >>> So if the SF touches the SI (which it does) we must define the = edge > >> conditions. > >>> If it is the SF's job to decrement the SI, then we must also = define > >>> what it > >> does > >>> when SI=3D0 (otherwise, it will set SI to 0-1). > >>> If the SF is not allowed to decrement the SI below zero (which = makes > >>> sense) we must define what it must do. > >>> Since SFs are allowed to drop packets (indeed that is one of their > >>> main jobs > >> ;-) > >>> then this would be fine. > >>> All that would be left is to define whether they apply the test > >>> before or > >> after > >>> normal processing. > >>> > >>> As an aside, I agree with Don that TTL helps relax this a little, = but > >>> does not get us all the way there. > >>> > >>> Cheers, > >>> Adrian > >>> > >>>> -----Original Message----- > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > >>>> Sent: 09 February 2017 21:00 > >>>> To: Joel M. Halpern; Ron Parker > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C = Rosen; > >>>> Dolganow, Andrew (Nokia - SG) > >>>> Subject: Re: [sfc] NSH Service Index Decrement > >>>> > >>>> Discussing misconfigured SFFs is a straw-man argument. Once one > >>>> starts > >> trying > >>> to > >>>> anticipate down-stream devices being misconfigured, one can = invent a > >>>> lot of > >>> silly > >>>> requirements. > >>>> > >>>> >From an aesthetic point of view, I think it's bad that there are > >>>>> two SI > >>> values (0 > >>>> and 1) that cannot be used. > >>>> > >>>> The real requirement, IMO, is that no device decrements 0 and = forwards > NSH. > >>>> Since only SFs decrement SI, only SFs need to do this check. > >>>> > >>>> And any discussion about buggy SFs... well there is a lot of bad > >>>> stuff that > >>> bugs can > >>>> cause. > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>> Sent: Thursday, February 09, 2017 2:54 PM > >>>> To: Ron Parker; Dave Dolson > >>>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); = James > >>>> N > >>> Guichard; > >>>> Fabricio Ferraz > >>>> Subject: Re: [sfc] NSH Service Index Decrement > >>>> > >>>> From my perspective as an individual participant in this work, > >>>> declaring that 0 must be dropped is a matter of robustness. > >>>> > >>>> if we allow 0 to be processed for exit at an SFF, then a > >>>> mis-configured SFF could easily continue processing such a = packet. > >>>> Now, it is true that TTL will eventually drop it, but that is an expensive > fallback. > >>>> > >>>> More importantly, presumably the next entitiy down the incorrect > >>>> path would drop it for a 255 SI. But at that point we are = getting > >>>> the error in the wrong place, making it harder to diagnose and = repair. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 2/9/17 12:42 PM, Ron Parker wrote: > >>>>> agree. > >>>>> > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson >>>>> > wrote: > >>>>> > >>>>>> I'm not clear on why this is broken, or why this restriction is = made. > >>>>>> > >>>>>> I agree it should not be sent to an SF, but an SFF could map an = SI > >>>>>> of zero into a path termination. > >>>>>> > >>>>>> I.e., the last SF in a path could decrement SI from 1 to 0, and > >>>>>> the SFF could then terminate the chain. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N > >>>>>> Guichard > >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave = Dolson; > >>>>>> Eric C Rosen; sfc@ietf.org > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Not exactly. Section 3.3 specifies "The value zero for SI is = not > >>>>>> valid and indicates a broken SFC or malfunctioning SF" .. In = other > >>>>>> words an SF should never receive an NSH packet with SI =3D 0. > >>>>>> Note that if this happened then either a) a classifier set the = SI > >>>>>> incorrectly, or b) a re-classifier set the SI incorrectly, or = c) > >>>>>> an upstream SF set the SI incorrectly; all of these cases = should > >>>>>> be caught by the SFF whose job it is to discard NSH packets = with SI =3D 0. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Jim > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM > >>>>>> *To:* James N Guichard >>>>>> >; Dolganow, Andrew (Nokia = - > >>>>>> SG) >>>>>> >; > >>>> Dave > >>>>>> Dolson >; = Eric > >>>>>> C Rosen >; > >>>>>> sfc@ietf.org > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi Jim, > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> > >>>>>> > >>>>>> One more question about the SI. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Section 3 states that: > >>>>>> > >>>>>> > >>>>>> > >>>>>> Service Index (SI): provides location within the SFP. The = initial > >>>>>> classifier MUST set the appropriate SI value for a given > >>>>>> classification result. The initial SI value SHOULD default to = 255. > >>>>>> However, the classifier MUST allow configuration of other SI = values. > >>>>>> > >>>>>> Service Index MUST be decremented by Service Functions or by = SFC > >>>>>> Proxy nodes after performing required services and the new > >>>>>> decremented SI value MUST be used in the egress NSH packet. > >>>>>> > >>>>>> The initial Classifier MUST send the packet to the first SFF in > >>>>>> the identified SFP for forwarding along an SFP. > >>>>>> > >>>>>> If re-classification occurs, and that re-classification results = in > >>>>>> a new SPI, the (re)classifier is, in effect, the initial > >>>>>> classifier for the resultant SPI. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thus: > >>>>>> > >>>>>> a) Initial SI value should be 255 but other values can be > >>>>>> configured by the classifier. > >>>>>> > >>>>>> b) SF decrements the SI value on the egress NSH packet > >>>>>> > >>>>>> c) If re-classification occurs with new SPI, the = re-classifier > >>>>>> is the initial classifier, so by a), SI should be again 255 or > >>>>>> other value > >>>>>> > >>>>>> > >>>>>> > >>>>>> So any SI value can be receive by an SF, even 1 or 0 because: > >>>>>> > >>>>>> =E8If SI=3D1 and there is no re-classification, the egress NSH = will > >>>>>> have SI=3D0 > >>>>>> > >>>>>> =E8If SI=3D0 and there is re-classification with new SPI, the = egress > >>>>>> NSH will have a new SPI and a SI=3D 255 or other value, as = stated in a). > >>>>>> > >>>>>> =E8If SI=3D0 and there is no re-classification the SF should = discard > >>>>>> the packet > >>>>>> > >>>>>> > >>>>>> > >>>>>> Also an SFF should forward/handle packets with NSH with SI=3D1 = or SI=3D0. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Do you agree? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N > >>>>>> Guichard > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave = Dolson; > >>>>>> Eric C Rosen; sfc@ietf.org > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi Fabricio, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Welcome! > >>>>>> > >>>>>> > >>>>>> > >>>>>> Yes, removal of NSH is the responsibility of an SFF or a > >>>>>> re-classifier (section 4, bullet point 1 lays this out). With = the > >>>>>> current architecture the SF does not care what SI value it = gets, > >>>>>> it just needs to worry about decrementing it, and leave it up = to > >>>>>> the SFF to evaluate the SI value and associated action. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Jim > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >>>>>> *Sent:* Thursday, February 09, 2017 7:13 AM > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) >>>>>> >; Dave Dolson > >>>> >>>>>> >; Eric C Rosen = >>>>>> >; James N Guichard > >>>>>> >>> >; > >>>>>> sfc@ietf.org > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I'm new here (just read the draft last week) but according to > >>>>>> chapter > >>>>>> 4 (check figure 8 for example), an SF is not allowed to insert = or > >>>>>> remove NSH. The removal of NSH is reponsability of the SSF, = right? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Figure 8 maps each of the four actions above to the = components > >>>>>> in the > >>>>>> > >>>>>> SFC architecture that can perform it. > >>>>>> > >>>>>> > >>>>>> > >>>>>> = +---------------+------------------+-------+----------------+---------+ > >>>>>> > >>>>>> | | Insert |Select | Update = |Service | > >>>>>> > >>>>>> | | or remove NSH |Service| NSH = |policy | > >>>>>> > >>>>>> | | |Function| = |selection| > >>>>>> > >>>>>> | Component +--------+--------+Path +----------------+ = | > >>>>>> > >>>>>> | | | | | Dec. |Update | = | > >>>>>> > >>>>>> | | Insert | Remove | |Service |Context| = | > >>>>>> > >>>>>> | | | | | Index |Header | = | > >>>>>> > >>>>>> = +----------------+--------+--------+-------+--------+-------+---------+ > >>>>>> > >>>>>> | | + | + | | | + | = | > >>>>>> > >>>>>> |Classifier | | | | | | = | > >>>>>> > >>>>>> +--------------- > >>>>>> ++--------+--------+-------+--------+-------+---------+ > >>>>>> > >>>>>> |Service Function| | + | + | | | = | > >>>>>> > >>>>>> |Forwarder(SFF) | | | | | | = | > >>>>>> > >>>>>> +--------------- > >>>>>> ++--------+--------+-------+--------+-------+---------+ > >>>>>> > >>>>>> |Service | | | | + | + | = + | > >>>>>> > >>>>>> |Function (SF) | | | | | | = | > >>>>>> > >>>>>> +--------------- > >>>>>> ++--------+--------+-------+--------+-------+---------+ > >>>>>> > >>>>>> |SFC Proxy | + | + | | + | | = | > >>>>>> > >>>>>> = +----------------+--------+--------+-------+--------+-------+---------+ > >>>>>> > >>>>>> > >>>>>> > >>>>>> Figure 8: NSH Action and Role Mapping > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> An SF could receive an NSH packet with an SI of 1, and = reclassify > >>>>>> it to a different SPI and SI, right? So when a SF receives a = NSH > >>>>>> packet with SI =3D 1 that does not necessarily means a non = valid packet. > >>>>>> > >>>>>> And that can even work for SI=3D0, since you decrement the SI = in the > >> egress. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Fabricio > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of = *Dolganow, > >>>>>> Andrew (Nokia - SG) > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org > >>>>>> > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> I assumed that if we get value 1 we process then forward = without > >>>>>> NSH header (i.e.) this is the last SF processing. > >>>>>> > >>>>>> > >>>>>> > >>>>>> So with that assumption, a more explicit text would be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >>>>>> decrement the SI by 1 after performing all required local > >>>>>> processing and before forwarding the packet to the next SFF. If > >>>>>> the resulting SI is 0, the SF MUST remove the NSH header before > forwarding the packet. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Andrew > >>>>>> > >>>>>> *From: *sfc > > >>>>>> on behalf of Dave Dolson >>>> > > >>>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM > >>>>>> *To: *Eric Rosen >>>>>> >, James N Guichard > >>>>>> >>>>>> >, "sfc@ietf.org > >>>>>> " > > >>>>>> *Subject: *Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Eric, > >>>>>> > >>>>>> I was never quite happy with the outcome that neither 0 nor 1 = is > >>>>>> a valid SI. > >>>>>> > >>>>>> (Because if received with value of 1, it is decremented and > >>>>>> discarded.) > >>>>>> > >>>>>> > >>>>>> > >>>>>> It seems to waste an index value. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I guess I'm interested to know if that is important to other > >>>>>> implementers, or if that was even the intention? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -Dave > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C > >>>>>> Rosen > >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM > >>>>>> *To:* James N Guichard; sfc@ietf.org > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: > >>>>>> > >>>>>> A request was made to be more specific and update the text as = follows: > >>>>>> > >>>>>> > >>>>>> > >>>>>> "Service index MUST be decremented *by a value of 1* by Service > >>>>>> Functions or by SFC Proxy nodes after performing required = services ." > >>>>>> > >>>>>> > >>>>>> A couple of observations: > >>>>>> > >>>>>> - The term "SFC Proxy node" is not defined in either the NSH > >>>>>> draft or in RFC 7665. I think the intention here is to say = "SFC Proxy". > >>>>>> > >>>>>> - Is the intention that the SI remain unchanged while the SF is > >>>>>> operating on the packet, or is the intention only that the SI = be > >>>>>> decremented before the packet is delivered by the SF or SFC = Proxy > >>>>>> to an SFF? > >>>>>> > >>>>>> I'd suggest either: > >>>>>> > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >>>>>> decrement the SI by 1 before delivering the packet to the next = SFF" > >>>>>> > >>>>>> or > >>>>>> > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > >>>>>> decrement the SI by 1 before delivering the packet to the next > >>>>>> SFF, but not until the SF has finished all its other processing = of the > packet" > >>>>>> > >>>>>> depending upon which is intended. > >>>>>> > >>>>>> I think an implication of these procedures is that an SI value = of > >>>>>> 1 is not valid. If an SF gets an NSH packet with an SI of 1, = the > >>>>>> SF will decrement the SI (setting it to 0), send the packet to = an > >>>>>> SFF, and the SFF will discard it, because 0 is an invalid SI > >>>>>> value. Is that the intention? > >>>>>> > >>>>>> The draft makes it clear (well, sort of) that an SFF should > >>>>>> discard a packet with an SI of 0, but does not seem to say that > >>>>>> an SF or SFC Proxy should discard a packet it receives with an = SI > >>>>>> of 0. It would probably be a good idea to say that. > >>>>>> > >>>>>> Some text in the draft (e.g., section 7.1) states than an SFF > >>>>>> should discard a packet with an SI of zero, but other text in = the > >>>>>> draft (e.g., section 3.3) only says that an SFF should log an > >>>>>> error if it sees an SI of zero. It's probably best to change = the > >>>>>> text in 3.3. to say "SHOULD generate an error/log message and > >>>>>> MUST discard the packet", or something similar. > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >> > > From nobody Sat Feb 11 14:45:14 2017 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 E148312944B for ; Sat, 11 Feb 2017 14:45:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 9OpyhKO4OrKA for ; Sat, 11 Feb 2017 14:45:09 -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 76735129476 for ; Sat, 11 Feb 2017 14:45:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47938240954; Sat, 11 Feb 2017 14:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486853109; bh=eixD4e/edYzzBxjue/nTP5hchr59eQFN9g/LDa9WEBA=; h=Date:Subject:From:To:Cc:From; b=jrTLMkqAGznCBrT01//AadKGJMqap1j2d4UEpMQAESfboMhKNasjK4YZolSiIW+Z5 kvyFXalkX4KIbgklQjOEQSk+Jtplti8FsNgfndyMuxSQWkpOkm7qXb+Jms21mG0TFl eatRzx0xkZUwTzbTEBzqSLVRQ476HZFdv2ysV+tc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.220.0.93] (mobile-166-171-057-093.mycingular.net [166.171.57.93]) (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 0442D2406F2; Sat, 11 Feb 2017 14:45:07 -0800 (PST) Date: Sat, 11 Feb 2017 17:45:04 -0500 Message-ID: Importance: normal From: "jmh.direct" To: adrian@olddog.co.uk, "'Joel M. Halpern'" , 'Ron Parker' MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_2009828933707010" Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 22:45:13 -0000 ----_com.samsung.android.email_2009828933707010 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhvc2UgY2xhcmlmaWNhdGlvbnMgc2VlbSBhY2N1cmF0ZSBhbmQgdXNlZnVsIHRvIG1lLiDCoApZ b3VycyxKb2VsCgoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFPCriA2LCBhbiBBVCZUIDRH IExURSBzbWFydHBob25lCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBB ZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiBEYXRlOiAyLzExLzE3ICAxNzozNSAg KEdNVC0wNTowMCkgVG86ICInSm9lbCBNLiBIYWxwZXJuJyIgPGptaEBqb2VsaGFscGVybi5jb20+ LCAnUm9uIFBhcmtlcicgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IENjOiBzZmNA aWV0Zi5vcmcgU3ViamVjdDogUkU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudCAK Sm9lbCwKClRoZSAtMTAgdmVyc2lvbiBvZiBOU0ggc2F5cwoKwqDCoCBUaGUKwqDCoCB2YWx1ZSB6 ZXJvIGZvciBTSSBpcyBub3QgdmFsaWQgYW5kIGluZGljYXRlcyBhIGJyb2tlbiBTRkMgb3IKwqDC oCBtYWxmdW5jdGlvbmluZyBTRi4KCllvdSBhcmUgc2F5aW5nIHRoYXQgdGhlIGxhdHRlciBvZiB0 aGVzZSBpcyBub3QgdHJ1ZS4KSSBjYW4ndCB0ZWxsIHdoZXRoZXIgdGhlIGZvcm1lciBpcyByZWFs bHkgdHJ1ZSBvciwgcGVyaGFwcywgcmVwcmVzZW50cyBhIGRpc2NhcmQKdGFpbCBvZiBhbiBTRkMg d2hlcmUgc29tZSAoYnV0IG5vdCBhbGwpIHBhY2tldHMgYXJlIHJlY2xhc3NpZmllZCBwZXIgUm9u LgoKTGlrZSBJIHNhaWQ6Cgo+IExldCdzIGNsYXJpZnkgdGhhdCBpdCBpcyBPSyBmb3IgYW4gU0Yg dG8gc2VuZCBhIHBhY2tldCB3aXRoIFNJPTAKClRoZW4gKG9mIGNvdXJzZSkgaXQgaXMgYWxzbyBP SyBmb3IgYW4gU0ZGIHRvIHJlY2VpdmUgU0k9MCwgYnV0IEkgdGhpbmsgdGhlCmV4aXN0aW5nICJk aXNjYXJkIiB0ZXh0IGNvdmVycyB0aGF0IGNhc2UuCgpBZHJpYW4KCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0KPiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tXQo+IFNlbnQ6IDExIEZlYnJ1YXJ5IDIwMTcgMTg6MDgKPiBUbzogUm9uIFBhcmtlcjsg YWRyaWFuQG9sZGRvZy5jby51azsgJ0RhdmUgRG9sc29uJwo+IENjOiAnRXJpYyBDIFJvc2VuJzsg J0RvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpJzsgc2ZjQGlldGYub3JnOyAnSmFtZXMgTgo+ IEd1aWNoYXJkJzsgJ0ZhYnJpY2lvIEZlcnJheicKPiBTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNl cnZpY2UgSW5kZXggRGVjcmVtZW50Cj4gCj4gSSB3YXMgY29tbWVudGluZywgaW4gcGVyc29uYWwg aGF0LCBhYm91dCB0aGUgaXNzdWUgb2Ygd2hldGhlciB0aGVyZSB3YXMKPiBzb21lIHNvcnQgb2Yg cHJvYmxlbSB3aXRoIHRoZSBpbXBhY3Qgb2YgdGhlIGN1cnJlbnQgZGVzY3JpcHRpb24gb24gU0k9 MQo+IHBhY2tldHMgYXJyaXZpbmcgYXQgYW4gU0YuwqAgSXQgc2VlbXMgdG8gbWUgdGhhdCB5b3Vy IGV4YW1wbGUgc2hvd3MgdGhhdAo+IHN1Y2ggYW4gZWZmZWN0IGlzIHNvbWV0aW1lcyB1c2V1bC4K PiBJdCB3aWxsIGFsc28gc29tZXRpbWVzIHByb2R1Y2UgcGFja2V0IGRyb3BzIGJ5IHRoZSBTRkYs IHdoZW4gdGhlIFNGIGRvZXMKPiBub3QgdGVybWluYXRlIHRoZSBwYWNrZXQuwqAgT2theSwgc28g YmUgaXQuCj4gSXQgaXMgbm90IGV2ZW4gY2xlYXIgdGhlcmUgaXMgYW55dGhpbmcsIGluIEFkcmlh bidzIHBocmFzZSwgdG8gcGFpbnQgcmVkCj4gaGVyZS4KPiAKPiBZb3VycywKPiBKb2VsCj4gCj4g T24gMi8xMS8xNyAxMjo1OSBQTSwgUm9uIFBhcmtlciB3cm90ZToKPiA+IEhpLCBKb2VsLgo+ID4K PiA+IERvZXMgeW91ciBjb21tZW50IHBlcnRhaW4gdG8gbXkgc29tZXdoYXQgb2ZmIHRvcGljIHF1 ZXN0aW9uIHdoaWNoIHdhcwo+IHJlbGF0ZWQgdG8gb25lIG9mIEFkcmlhbidzIHRhbmdlbnRpYWwg aXNzdWVzLCBvciB0byBBZHJpYW4ncyBvcmlnaW5hbCBTRj0xCnRvcGljPwo+ID4KPiA+IFRoYW5r cy4KPiA+Cj4gPsKgwqDCoCBSb24KPiA+Cj4gPgo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0KPiA+IEZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21d Cj4gPiBTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMTEsIDIwMTcgMTI6MzEgUE0KPiA+IFRvOiBS b24gUGFya2VyIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPjsgYWRyaWFuQG9sZGRv Zy5jby51azsKPiAnRGF2ZSBEb2xzb24nIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4KPiA+IENjOiAn RXJpYyBDIFJvc2VuJyA8ZXJvc2VuQGp1bmlwZXIubmV0PjsgJ0RvbGdhbm93LCBBbmRyZXcgKE5v a2lhIC0gU0cpJwo+IDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPjsgc2ZjQGlldGYub3JnOyAn SmFtZXMgTiBHdWljaGFyZCcKPiA8amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPjsgJ0ZhYnJp Y2lvIEZlcnJheicgPGZhYnJpY2lvLWZlcnJhekB0ZWxlY29tLnB0Pgo+ID4gU3ViamVjdDogUmU6 IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudAo+ID4KPiA+IFBlcnNvbmFsbHksIHdo YXQgeW91IGRlc2NyaWJlIHNvdW5kcyBsaWtlIGEgcXVpdGUgcmVhc29uYWJsZSBjYXNlIHdoZXJl IGEKPiBwYWNrZXQgYXJyaXZlIGF0IHRoZSBTRiB3aXRoIGFuIFNJIG9mIDEgd2lsbCBwcm9kdWNl IGV4YWN0bHkgdGhlIGRlc2lyZWQKYmVoYXZpb3IuCj4gPgo+ID4gV2hpY2ggc3VnZ2VzdHMsIHRv IG15IGxpbWl0ZWQgdmlldywgdGhhdCB0aGUgY3VycmVudCB0ZXh0IHdvcmtzIGZpbmUuCj4gPgo+ ID4gWW91cnMsCj4gPiBKb2VsCj4gPgo+ID4gT24gMi8xMS8xNyAxMTo1NSBBTSwgUm9uIFBhcmtl ciB3cm90ZToKPiA+PiBIaSwgQWRyaWFuLgo+ID4+Cj4gPj4gTm90IHRoZSBvcmlnaW5hbCB0b3Bp YywgcGVyIHNlLCBidXQgd3J0IHlvdXIgY29tbWVudDoKPiA+Pgo+ID4+ICogT24gdGhlIG90aGVy IGhhbmQsIHdlIGFwcGVhciB0byBiZSBjbGVhciBhYm91dCBhbiBTRiB0aGF0IHN0cmlwcyB0aGUg TlNICj4gYW5kIGZvcndhcmRzIHRoZSB0cmFmZmljIGFzIG5hdGl2ZSA6IHRoaXMgaXMgY3VycmVu dGx5IGZvcmJpZGRlbi4KPiA+Pgo+ID4+IEknbSB3b25kZXJpbmcgaG93IHRvIHJlY29uY2lsZSB0 aGlzIHRvIGEgdHJhbnNwYXJlbnQgSFRUUCBQcm94eSB0aGF0IGRvZXMKbm90Cj4gcHJlc2VydmUg dGhlIG9yaWdpbmFsIHNvdXJjZS1JUD/CoMKgIERvZXMgdGhpcyBtZWFuIHRoYXQgaXQgaXMgbWFu ZGF0b3J5IGZvcgpzdWNoIGFuCj4gU0YgdG8gYWxzbyBiZSBhIGNsYXNzaWZpZXIgc28gaXQgY2Fu IHNlbGYtY2xhc3NpZnkgaXRzIG93biByZWxhdGVkIGZsb3dzCihpLmUuLCB1c2luZyBpdHMKPiBv d24gdmlzaWJsZSBJUCBhZGRyZXNzZXMpP8KgwqDCoCBGcm9tIFNGRiBwZXJzcGVjdGl2ZSwgaXQg d291bGQgbG9vayBsaWtlIGFsbApwYWNrZXRzCj4gb24gdGhlIGFjY2VzcyBzaWRlIGFyZSBkcm9w cGVkIGluIHRoZSB1cHN0cmVhbSBkaXJlY3Rpb24gYW5kIGluamVjdGVkIGJ5IHRoZQpTRgo+IGlu IHRoZSBkb3duc3RyZWFtIGRpcmVjdGlvbi7CoMKgIE9uIHRoZSBJbnRlcm5ldCBzaWRlLCBpdCB3 b3VsZCBsb29rIGxpa2UgYWxsCnBhY2tldHMKPiBhcmUgaW5qZWN0ZWQgYnkgdGhlIFNGIGluIHRo ZSB1cHN0cmVhbSBkaXJlY3Rpb24gYW5kIGRyb3BwZWQgaW4gdGhlIGRvd25zdHJlYW0KPiBkaXJl Y3Rpb24uCj4gPj4KPiA+PiBUaGFua3MgZm9yIGFueSBjbGFyaWZpY2F0aW9uLgo+ID4+Cj4gPj7C oMKgwqAgUm9uCj4gPj4KPiA+Pgo+ID4+Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0K PiA+PiBGcm9tOiBBZHJpYW4gRmFycmVsIFttYWlsdG86YWRyaWFuQG9sZGRvZy5jby51a10KPiA+ PiBTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMTEsIDIwMTcgMTE6MzQgQU0KPiA+PiBUbzogJ0Rh dmUgRG9sc29uJyA8ZGRvbHNvbkBzYW5kdmluZS5jb20+OyAnSm9lbCBNLiBIYWxwZXJuJwo+ID4+ IDxqbWhAam9lbGhhbHBlcm4uY29tPjsgUm9uIFBhcmtlciA8Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbT4KPiA+PiBDYzogJ0VyaWMgQyBSb3NlbicgPGVyb3NlbkBqdW5pcGVyLm5ldD47 ICdEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtCj4gPj4gU0cpJyA8YW5kcmV3LmRvbGdhbm93QG5v a2lhLmNvbT47IHNmY0BpZXRmLm9yZzsgJ0phbWVzIE4gR3VpY2hhcmQnCj4gPj4gPGphbWVzLm4u Z3VpY2hhcmRAaHVhd2VpLmNvbT47ICdGYWJyaWNpbyBGZXJyYXonCj4gPj4gPGZhYnJpY2lvLWZl cnJhekB0ZWxlY29tLnB0Pgo+ID4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRl eCBEZWNyZW1lbnQKPiA+Pgo+ID4+IEkgaGF0ZSB0byBkbyBteSBpbXBlcnNvbmF0aW9uIG9mIEVy aWMsIGJ1dC4uLgo+ID4+Cj4gPj4gIk9uIHRoZSB3aXJlIiBpcyB0aGUgY3J1bmNoLgo+ID4+Cj4g Pj4gU29tZSBoYXZlIHNhaWQgdGhhdCB0aGVyZSBtdXN0IGJlIG5vIHZpc2libGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIHRoZSB0aHJlZQo+IGNhc2U6Cj4gPj4gLSBvbiB0aGUgd2lyZSBiZXR3ZWVuIFNG RiBhbmQgU0YKPiA+PiAtIG9uIHRoZSB3aXJlIGJldHdlZW4gU0YgYW5kIFNGRgo+ID4+IC0gb24g dGhlIHdpcmUgYmV0d2VlbiBTRkYgYW5kIFNGRgo+ID4+Cj4gPj4gSWYgdGhpcyBob2xkcyB0aGVu IHlvdSBhcmUgY29ycmVjdCB0aGF0IHNlbmRpbmcgU0k9MSBpbiB0aGUgZmlyc3QgY2FzZQpyZXF1 aXJlcwo+IHRoZSBTRiB0byBkbyBtb3JlIHRoYW4gYSBzaW1wbGUgZGVjcmVtZW50IChhbHRob3Vn aCBkZWNyZW1lbnQgYW5kIGRpc2NhcmQgaXMKPiBoYXJkbHkgcGFpbmZ1bCkuIEFuZCBpdCBtZWFu cyB0aGF0IFNJPTEgaXMgYSBkdWJpb3VzIHZhbHVlIGluIGFuIFNGUC4KPiA+Pgo+ID4+IE9uIHRo ZSBvdGhlciBoYW5kLCB3ZSBhcHBlYXIgdG8gYmUgY2xlYXIgYWJvdXQgYW4gU0YgdGhhdCBzdHJp cHMgdGhlIE5TSAphbmQKPiBmb3J3YXJkcyB0aGUgdHJhZmZpYyBhcyBuYXRpdmUgOiB0aGlzIGlz IGN1cnJlbnRseSBmb3JiaWRkZW4uIFNvIHRoZXJlIGlzIG5vCj4gYWx0ZXJuYXRpdmUgZm9yIGFu IFNGIHJlY2VpdmluZyBTST0xIGV4Y2VwdCB0byBkaXNjYXJkIHRoZSBwYWNrZXQuCj4gPj4KPiA+ PiBOb3csIGRvZXMgdGhhdCBtZWFuIHRoYXQgYW4gU0ZGIHNob3VsZCBuZXZlciBzZW5kIGEgcGFj a2V0IHdpdGggU0k9MT8gV2VsbCwKPiBwb3NzaWJseSBpdCBpcyBPSyBmb3IgYSBmZXcgc3BlY2lh bGlzdCBTRnMgaW50ZW5kZWQgdG8gc2l0IGF0IHRoZSBlbmQgb2YgdGhlCmNoYWluIGFuZAo+IGJl IGEgYml0IGJ1Y2tldCB3aXRoIGFuYWx5c2lzLiBCdXQsIGZvciBtb3N0IFNGcyB0aGVyZSB3b3Vs ZCBiZSBubyBwb2ludC4KPiA+Pgo+ID4+IE1heWJlIChqdXN0IG1heWJlKSB3ZSBzaG91bGQgc3Rv cCBsZXR0aW5nIHRoZSB0YWlsIHdhZyB0aGUgZG9nISBUaGF0IGlzLApsZXQncwo+IGRlY2lkZSBv biB0aGUgZnVuY3Rpb25hbCBiZWhhdmlvciB3ZSB3YW50IHRvIHNlZSBhbmQgdGhlbiBkZXNpZ24g dGhlIHByb3RvY29sCj4gdG8gbWF0Y2guCj4gPj4KPiA+PiBBZHJpYW4KPiA+Pgo+ID4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4+PiBGcm9tOiBEYXZlIERvbHNvbiBbbWFpbHRvOmRk b2xzb25Ac2FuZHZpbmUuY29tXQo+ID4+PiBTZW50OiAxMCBGZWJydWFyeSAyMDE3IDIyOjI2Cj4g Pj4+IFRvOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyAnSm9lbCBNLiBIYWxwZXJuJzsgJ1JvbiBQYXJr ZXInCj4gPj4+IENjOiAnRXJpYyBDIFJvc2VuJzsgJ0RvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0g U0cpJzsgc2ZjQGlldGYub3JnOwo+ID4+PiAnSmFtZXMgTiBHdWljaGFyZCc7ICdGYWJyaWNpbyBG ZXJyYXonCj4gPj4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1l bnQKPiA+Pj4KPiA+Pj4gQWRyaWFuLAo+ID4+PiBJIHRoaW5rIEkgYWdyZWUgd2l0aCBldmVyeXRo aW5nIHlvdSBzYWlkLgo+ID4+PiBCdXQgeW91IGRpZCBub3Qgc3VnZ2VzdCB3aGV0aGVyIG9yIG5v dCB5b3UgdGhpbmsgdGhhdCBTST0wIHNob3VsZCBiZQo+ID4+PiB2YWxpZCBvbgo+ID4+IHRoZQo+ ID4+PiB3aXJlLgo+ID4+PiBJJ20gc2F5aW5nIGl0IGNvdWxkIHdvcmssIGlmIHRoZSBuZXh0IGhv cCBpcyBhIHBhdGggdGVybWludXMuCj4gPj4+Cj4gPj4+IElmIEkgdW5kZXJzdGFuZCBKb2VsIGNv cnJlY3RseSwgaGUgc2F5cyB3ZSBzaG91bGRuJ3Qgc2VuZCBTST0wwqAgaW4KPiA+Pj4gY2FzZSB0 aGUKPiA+PiBuZXh0Cj4gPj4+IGhvcCBibGluZGx5IGRlY3JlbWVudHMgaXQuCj4gPj4+IC0tPiB0 aGlzIHNlZW1zIHRvIG1lYW4gU0k9MSBjYW5ub3QgYmUgdXNlZCBleGNlcHQgYXQgdGhlIHRlcm1p bnVzIG9yCj4gPj4+IC0tPiB3aGVuIHRoZQo+ID4+PiBTRiBpcyBleHBlY3RlZCB0byBkcm9wIGFs bCBwYWNrZXRzLgo+ID4+PiBTbyBJIHRoaW5rIHRoaXMgaXMgYW4gdW5uZWNlc3Nhcnkgc2VhdCBi ZWx0LCB0cnlpbmcgdG8gYW50aWNpcGF0ZQo+ID4+PiBidWdzIGluCj4gPj4gZG93bi0KPiA+Pj4g c3RyZWFtIGRldmljZXMuCj4gPj4+Cj4gPj4+IEkgcmVhbGl6ZSB0aGUgY3VycmVudCBsYW5ndWFn ZSBoYXMgYmVlbiB0aGVyZSBhIGxvbmcgdGltZSwgYW5kIGlmIGl0Cj4gPj4+IGlzCj4gPj4gaW1w b3J0YW50IHRvCj4gPj4+IGFueW9uZSB0aGVuIGl0IHNob3VsZCByZW1haW4uCj4gPj4+IE5vbmV0 aGVsZXNzLCBJIHRoaW5rIGRldmljZXMgY291bGQgc2FmZWx5IGhhbmRsZSBTST0wIG9uIHRoZSB3 aXJlCj4gPj4+IHdpdGhvdXQgYnJlYWtpbmcgYW55dGhpbmcuCj4gPj4+Cj4gPj4+IEJ1dCBJJ20g bm90IHB1c2hpbmcgZm9yIGEgY2hhbmdlLCBzaW5jZSB0aGUgY3VycmVudCBiZWhhdmlvciBzZWVt cwo+ID4+PiBpbXBvcnRhbnQKPiA+PiB0bwo+ID4+PiBzb21lLgo+ID4+Pgo+ID4+PiAtRGF2ZQo+ ID4+Pgo+ID4+Pgo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4+PiBGcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJy ZWwKPiA+Pj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAxMCwgMjAxNyA5OjE2IEFNCj4gPj4+IFRv OiBEYXZlIERvbHNvbjsgJ0pvZWwgTS4gSGFscGVybic7ICdSb24gUGFya2VyJwo+ID4+PiBDYzog J0VyaWMgQyBSb3Nlbic7ICdEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKSc7IHNmY0BpZXRm Lm9yZzsKPiA+Pj4gJ0phbWVzIE4gR3VpY2hhcmQnOyAnRmFicmljaW8gRmVycmF6Jwo+ID4+PiBT dWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50Cj4gPj4+Cj4gPj4+ IE9oLCB5b3UgZmluYWxseSBwdXNoZWQgbWUgaW50byB0aGlzIGRpc2N1c3Npb24sIERhdmUuCj4g Pj4+Cj4gPj4+IFdlJ3JlIGJ1aWxkaW5nIGEgcHJvdG9jb2wuIHdpdGggYSBwcm90b2NvbCwgeW91 IGNhbm5vdCAobXVzdCBub3QpCj4gPj4+IGFzc3VtZSBnb29kIGJlaGF2aW9yIGZyb20geW91ciBu ZWlnaGJvci4KPiA+Pj4KPiA+Pj4gU28gaWYgdGhlIFNGIHRvdWNoZXMgdGhlIFNJICh3aGljaCBp dCBkb2VzKSB3ZSBtdXN0IGRlZmluZSB0aGUgZWRnZQo+ID4+IGNvbmRpdGlvbnMuCj4gPj4+IElm IGl0IGlzIHRoZSBTRidzIGpvYiB0byBkZWNyZW1lbnQgdGhlIFNJLCB0aGVuIHdlIG11c3QgYWxz byBkZWZpbmUKPiA+Pj4gd2hhdCBpdAo+ID4+IGRvZXMKPiA+Pj4gd2hlbiBTST0wIChvdGhlcndp c2UsIGl0IHdpbGwgc2V0IFNJIHRvIDAtMSkuCj4gPj4+IElmIHRoZSBTRiBpcyBub3QgYWxsb3dl ZCB0byBkZWNyZW1lbnQgdGhlIFNJIGJlbG93IHplcm8gKHdoaWNoIG1ha2VzCj4gPj4+IHNlbnNl KSB3ZSBtdXN0IGRlZmluZSB3aGF0IGl0IG11c3QgZG8uCj4gPj4+IFNpbmNlIFNGcyBhcmUgYWxs b3dlZCB0byBkcm9wIHBhY2tldHMgKGluZGVlZCB0aGF0IGlzIG9uZSBvZiB0aGVpcgo+ID4+PiBt YWluIGpvYnMKPiA+PiA7LSkKPiA+Pj4gdGhlbiB0aGlzIHdvdWxkIGJlIGZpbmUuCj4gPj4+IEFs bCB0aGF0IHdvdWxkIGJlIGxlZnQgaXMgdG8gZGVmaW5lIHdoZXRoZXIgdGhleSBhcHBseSB0aGUg dGVzdAo+ID4+PiBiZWZvcmUgb3IKPiA+PiBhZnRlcgo+ID4+PiBub3JtYWwgcHJvY2Vzc2luZy4K PiA+Pj4KPiA+Pj4gQXMgYW4gYXNpZGUsIEkgYWdyZWUgd2l0aCBEb24gdGhhdCBUVEwgaGVscHMg cmVsYXggdGhpcyBhIGxpdHRsZSwgYnV0Cj4gPj4+IGRvZXMgbm90IGdldCB1cyBhbGwgdGhlIHdh eSB0aGVyZS4KPiA+Pj4KPiA+Pj4gQ2hlZXJzLAo+ID4+PiBBZHJpYW4KPiA+Pj4KPiA+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPj4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUgRG9sc29uCj4gPj4+PiBTZW50OiAwOSBG ZWJydWFyeSAyMDE3IDIxOjAwCj4gPj4+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2Vy Cj4gPj4+PiBDYzogRmFicmljaW8gRmVycmF6OyBKYW1lcyBOIEd1aWNoYXJkOyBzZmNAaWV0Zi5v cmc7IEVyaWMgQyBSb3NlbjsKPiA+Pj4+IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpCj4g Pj4+PiBTdWJqZWN0OiBSZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50Cj4gPj4+ Pgo+ID4+Pj4gRGlzY3Vzc2luZyBtaXNjb25maWd1cmVkIFNGRnMgaXMgYSBzdHJhdy1tYW4gYXJn dW1lbnQuIE9uY2Ugb25lCj4gPj4+PiBzdGFydHMKPiA+PiB0cnlpbmcKPiA+Pj4gdG8KPiA+Pj4+ IGFudGljaXBhdGUgZG93bi1zdHJlYW0gZGV2aWNlcyBiZWluZyBtaXNjb25maWd1cmVkLCBvbmUg Y2FuIGludmVudCBhCj4gPj4+PiBsb3Qgb2YKPiA+Pj4gc2lsbHkKPiA+Pj4+IHJlcXVpcmVtZW50 cy4KPiA+Pj4+Cj4gPj4+PiA+RnJvbSBhbiBhZXN0aGV0aWMgcG9pbnQgb2YgdmlldywgSSB0aGlu ayBpdCdzIGJhZCB0aGF0IHRoZXJlIGFyZQo+ID4+Pj4+IHR3byBTSQo+ID4+PiB2YWx1ZXMgKDAK PiA+Pj4+IGFuZCAxKSB0aGF0IGNhbm5vdCBiZSB1c2VkLgo+ID4+Pj4KPiA+Pj4+IFRoZSByZWFs IHJlcXVpcmVtZW50LCBJTU8sIGlzIHRoYXQgbm8gZGV2aWNlIGRlY3JlbWVudHMgMCBhbmQgZm9y d2FyZHMKPiBOU0guCj4gPj4+PiBTaW5jZSBvbmx5IFNGcyBkZWNyZW1lbnQgU0ksIG9ubHkgU0Zz IG5lZWQgdG8gZG8gdGhpcyBjaGVjay4KPiA+Pj4+Cj4gPj4+PiBBbmQgYW55IGRpc2N1c3Npb24g YWJvdXQgYnVnZ3kgU0ZzLi4uIHdlbGwgdGhlcmUgaXMgYSBsb3Qgb2YgYmFkCj4gPj4+PiBzdHVm ZiB0aGF0Cj4gPj4+IGJ1Z3MgY2FuCj4gPj4+PiBjYXVzZS4KPiA+Pj4+Cj4gPj4+Pgo+ID4+Pj4K PiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPj4+PiBGcm9tOiBKb2VsIE0uIEhh bHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQo+ID4+Pj4gU2VudDogVGh1cnNkYXks IEZlYnJ1YXJ5IDA5LCAyMDE3IDI6NTQgUE0KPiA+Pj4+IFRvOiBSb24gUGFya2VyOyBEYXZlIERv bHNvbgo+ID4+Pj4gQ2M6IEVyaWMgQyBSb3Nlbjsgc2ZjQGlldGYub3JnOyBEb2xnYW5vdywgQW5k cmV3IChOb2tpYSAtIFNHKTsgSmFtZXMKPiA+Pj4+IE4KPiA+Pj4gR3VpY2hhcmQ7Cj4gPj4+PiBG YWJyaWNpbyBGZXJyYXoKPiA+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRl eCBEZWNyZW1lbnQKPiA+Pj4+Cj4gPj4+PsKgIEZyb20gbXkgcGVyc3BlY3RpdmUgYXMgYW4gaW5k aXZpZHVhbCBwYXJ0aWNpcGFudCBpbiB0aGlzIHdvcmssCj4gPj4+PiBkZWNsYXJpbmcgdGhhdCAw IG11c3QgYmUgZHJvcHBlZCBpcyBhIG1hdHRlciBvZiByb2J1c3RuZXNzLgo+ID4+Pj4KPiA+Pj4+ IGlmIHdlIGFsbG93IDAgdG8gYmUgcHJvY2Vzc2VkIGZvciBleGl0IGF0IGFuIFNGRiwgdGhlbiBh Cj4gPj4+PiBtaXMtY29uZmlndXJlZCBTRkYgY291bGQgZWFzaWx5IGNvbnRpbnVlIHByb2Nlc3Np bmcgc3VjaCBhIHBhY2tldC4KPiA+Pj4+IE5vdywgaXQgaXMgdHJ1ZSB0aGF0IFRUTCB3aWxsIGV2 ZW50dWFsbHkgZHJvcCBpdCwgYnV0IHRoYXQgaXMgYW4KZXhwZW5zaXZlCj4gZmFsbGJhY2suCj4g Pj4+Pgo+ID4+Pj4gTW9yZSBpbXBvcnRhbnRseSwgcHJlc3VtYWJseSB0aGUgbmV4dCBlbnRpdGl5 IGRvd24gdGhlIGluY29ycmVjdAo+ID4+Pj4gcGF0aCB3b3VsZCBkcm9wIGl0IGZvciBhIDI1NSBT SS7CoCBCdXQgYXQgdGhhdCBwb2ludCB3ZSBhcmUgZ2V0dGluZwo+ID4+Pj4gdGhlIGVycm9yIGlu IHRoZSB3cm9uZyBwbGFjZSwgbWFraW5nIGl0IGhhcmRlciB0byBkaWFnbm9zZSBhbmQgcmVwYWly Lgo+ID4+Pj4KPiA+Pj4+IFlvdXJzLAo+ID4+Pj4gSm9lbAo+ID4+Pj4KPiA+Pj4+IE9uIDIvOS8x NyAxMjo0MiBQTSwgUm9uIFBhcmtlciB3cm90ZToKPiA+Pj4+PiBhZ3JlZS4KPiA+Pj4+Pgo+ID4+ Pj4+IE9uIEZlYiA5LCAyMDE3LCBhdCAxMjoyOCBQTSwgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2Fu ZHZpbmUuY29tCj4gPj4+Pj4gPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+IHdyb3RlOgo+ ID4+Pj4+Cj4gPj4+Pj4+IEknbSBub3QgY2xlYXIgb24gd2h5IHRoaXMgaXMgYnJva2VuLCBvciB3 aHkgdGhpcyByZXN0cmljdGlvbiBpcyBtYWRlLgo+ID4+Pj4+Pgo+ID4+Pj4+PiBJIGFncmVlIGl0 IHNob3VsZCBub3QgYmUgc2VudCB0byBhbiBTRiwgYnV0IGFuIFNGRiBjb3VsZCBtYXAgYW4gU0kK PiA+Pj4+Pj4gb2YgemVybyBpbnRvIGEgcGF0aCB0ZXJtaW5hdGlvbi4KPiA+Pj4+Pj4KPiA+Pj4+ Pj4gSS5lLiwgdGhlIGxhc3QgU0YgaW4gYSBwYXRoIGNvdWxkIGRlY3JlbWVudCBTSSBmcm9tIDEg dG8gMCwgYW5kCj4gPj4+Pj4+IHRoZSBTRkYgY291bGQgdGhlbiB0ZXJtaW5hdGUgdGhlIGNoYWlu Lgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+PiAq RnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkph bWVzIE4KPiA+Pj4+Pj4gR3VpY2hhcmQKPiA+Pj4+Pj4gKlNlbnQ6KiBUaHVyc2RheSwgRmVicnVh cnkgMDksIDIwMTcgMTI6MDIgUE0KPiA+Pj4+Pj4gKlRvOiogRmFicmljaW8gRmVycmF6OyBEb2xn YW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRGF2ZSBEb2xzb247Cj4gPj4+Pj4+IEVyaWMgQyBS b3Nlbjsgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPgo+ID4+Pj4+PiAqU3ViamVj dDoqIFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQKPiA+Pj4+Pj4KPiA+Pj4+ Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gTm90IGV4YWN0bHkuIFNlY3Rpb24gMy4zIHNwZWNpZmllcyAi VGhlIHZhbHVlIHplcm8gZm9yIFNJIGlzIG5vdAo+ID4+Pj4+PiB2YWxpZCBhbmQgaW5kaWNhdGVz IGEgYnJva2VuIFNGQyBvciBtYWxmdW5jdGlvbmluZyBTRiIgLi4gSW4gb3RoZXIKPiA+Pj4+Pj4g d29yZHMgYW4gU0Ygc2hvdWxkIG5ldmVyIHJlY2VpdmUgYW4gTlNIIHBhY2tldCB3aXRoIFNJID0g MC4KPiA+Pj4+Pj4gTm90ZSB0aGF0IGlmIHRoaXMgaGFwcGVuZWQgdGhlbiBlaXRoZXIgYSkgYSBj bGFzc2lmaWVyIHNldCB0aGUgU0kKPiA+Pj4+Pj4gaW5jb3JyZWN0bHksIG9yIGIpIGEgcmUtY2xh c3NpZmllciBzZXQgdGhlIFNJIGluY29ycmVjdGx5LCBvciBjKQo+ID4+Pj4+PiBhbiB1cHN0cmVh bSBTRiBzZXQgdGhlIFNJIGluY29ycmVjdGx5OyBhbGwgb2YgdGhlc2UgY2FzZXMgc2hvdWxkCj4g Pj4+Pj4+IGJlIGNhdWdodCBieSB0aGUgU0ZGIHdob3NlIGpvYiBpdCBpcyB0byBkaXNjYXJkIE5T SCBwYWNrZXRzIHdpdGggU0kgPQowLgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+ PiBKaW0KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gKkZyb206KkZhYnJpY2lv IEZlcnJheiBbbWFpbHRvOmZhYnJpY2lvLWZlcnJhekB0ZWxlY29tLnB0XQo+ID4+Pj4+PiAqU2Vu dDoqIFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAxMTo0OSBBTQo+ID4+Pj4+PiAqVG86KiBK YW1lcyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20KPiA+Pj4+Pj4gPG1h aWx0bzpqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20+PjsgRG9sZ2Fub3csIEFuZHJldyAoTm9r aWEgLQo+ID4+Pj4+PiBTRykgPGFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20KPiA+Pj4+Pj4gPG1h aWx0bzphbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPj47Cj4gPj4+PiBEYXZlCj4gPj4+Pj4+IERv bHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20gPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+ OyBFcmljCj4gPj4+Pj4+IEMgUm9zZW4gPGVyb3NlbkBqdW5pcGVyLm5ldCA8bWFpbHRvOmVyb3Nl bkBqdW5pcGVyLm5ldD4+Owo+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5v cmc+Cj4gPj4+Pj4+ICpTdWJqZWN0OiogUkU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3Jl bWVudAo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+PiBIaSBKaW0sCj4gPj4+Pj4+ Cj4gPj4+Pj4+IFRoYW5rcy4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gT25l IG1vcmUgcXVlc3Rpb24gYWJvdXQgdGhlIFNJLgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ ID4+Pj4+PiBTZWN0aW9uIDMgc3RhdGVzIHRoYXQ6Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+ Cj4gPj4+Pj4+IFNlcnZpY2UgSW5kZXggKFNJKTogcHJvdmlkZXMgbG9jYXRpb24gd2l0aGluIHRo ZSBTRlAuIFRoZSBpbml0aWFsCj4gPj4+Pj4+IGNsYXNzaWZpZXIgTVVTVCBzZXQgdGhlIGFwcHJv cHJpYXRlIFNJIHZhbHVlIGZvciBhIGdpdmVuCj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uIHJlc3Vs dC4gVGhlIGluaXRpYWwgU0kgdmFsdWUgU0hPVUxEIGRlZmF1bHQgdG8gMjU1Lgo+ID4+Pj4+PiBI b3dldmVyLCB0aGUgY2xhc3NpZmllciBNVVNUIGFsbG93IGNvbmZpZ3VyYXRpb24gb2Ygb3RoZXIg U0kgdmFsdWVzLgo+ID4+Pj4+Pgo+ID4+Pj4+PiBTZXJ2aWNlIEluZGV4IE1VU1QgYmUgZGVjcmVt ZW50ZWQgYnkgU2VydmljZSBGdW5jdGlvbnMgb3IgYnkgU0ZDCj4gPj4+Pj4+IFByb3h5IG5vZGVz IGFmdGVyIHBlcmZvcm1pbmcgcmVxdWlyZWQgc2VydmljZXMgYW5kIHRoZSBuZXcKPiA+Pj4+Pj4g ZGVjcmVtZW50ZWQgU0kgdmFsdWUgTVVTVCBiZSB1c2VkIGluIHRoZSBlZ3Jlc3MgTlNIIHBhY2tl dC4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gVGhlIGluaXRpYWwgQ2xhc3NpZmllciBNVVNUIHNlbmQgdGhl IHBhY2tldCB0byB0aGUgZmlyc3QgU0ZGIGluCj4gPj4+Pj4+IHRoZSBpZGVudGlmaWVkIFNGUCBm b3IgZm9yd2FyZGluZyBhbG9uZyBhbiBTRlAuCj4gPj4+Pj4+Cj4gPj4+Pj4+IElmIHJlLWNsYXNz aWZpY2F0aW9uIG9jY3VycywgYW5kIHRoYXQgcmUtY2xhc3NpZmljYXRpb24gcmVzdWx0cyBpbgo+ ID4+Pj4+PiBhIG5ldyBTUEksIHRoZSAocmUpY2xhc3NpZmllciBpcywgaW4gZWZmZWN0LCB0aGUg aW5pdGlhbAo+ID4+Pj4+PiBjbGFzc2lmaWVyIGZvciB0aGUgcmVzdWx0YW50IFNQSS4KPiA+Pj4+ Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gVGh1czoKPiA+Pj4+Pj4KPiA+Pj4+Pj4gYSnC oMKgwqDCoMKgIEluaXRpYWwgU0kgdmFsdWUgc2hvdWxkIGJlIDI1NSBidXQgb3RoZXIgdmFsdWVz IGNhbiBiZQo+ID4+Pj4+PiBjb25maWd1cmVkIGJ5IHRoZSBjbGFzc2lmaWVyLgo+ID4+Pj4+Pgo+ ID4+Pj4+PiBiKcKgwqDCoMKgwqAgU0YgZGVjcmVtZW50cyB0aGUgU0kgdmFsdWUgb24gdGhlIGVn cmVzcyBOU0ggcGFja2V0Cj4gPj4+Pj4+Cj4gPj4+Pj4+IGMpwqDCoMKgwqDCoMKgIElmIHJlLWNs YXNzaWZpY2F0aW9uIG9jY3VycyB3aXRoIG5ldyBTUEksIHRoZSByZS1jbGFzc2lmaWVyCj4gPj4+ Pj4+IGlzIHRoZSBpbml0aWFsIGNsYXNzaWZpZXIsIHNvIGJ5wqAgYSksIFNJIHNob3VsZCBiZSBh Z2FpbiAyNTUgb3IKPiA+Pj4+Pj4gb3RoZXIgdmFsdWUKPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+ Pj4KPiA+Pj4+Pj4gU28gYW55IFNJIHZhbHVlIGNhbiBiZSByZWNlaXZlIGJ5IGFuIFNGLCBldmVu IDEgb3IgMCBiZWNhdXNlOgo+ID4+Pj4+Pgo+ID4+Pj4+PiDDqElmIFNJPTEgYW5kIHRoZXJlIGlz IG5vIHJlLWNsYXNzaWZpY2F0aW9uLCB0aGUgZWdyZXNzIE5TSCB3aWxsCj4gPj4+Pj4+IGhhdmUg U0k9MAo+ID4+Pj4+Pgo+ID4+Pj4+PiDDqElmIFNJPTAgYW5kIHRoZXJlIGlzIHJlLWNsYXNzaWZp Y2F0aW9uIHdpdGggbmV3IFNQSSwgdGhlIGVncmVzcwo+ID4+Pj4+PiBOU0ggd2lsbCBoYXZlIGEg bmV3IFNQSSBhbmQgYSBTST0gMjU1IG9yIG90aGVyIHZhbHVlLCBhcyBzdGF0ZWQgaW4gYSkuCj4g Pj4+Pj4+Cj4gPj4+Pj4+IMOoSWYgU0k9MCBhbmQgdGhlcmUgaXMgbm8gcmUtY2xhc3NpZmljYXRp b24gdGhlIFNGIHNob3VsZCBkaXNjYXJkCj4gPj4+Pj4+IHRoZSBwYWNrZXQKPiA+Pj4+Pj4KPiA+ Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gQWxzbyBhbiBTRkYgc2hvdWxkIGZvcndhcmQvaGFuZGxl IHBhY2tldHMgd2l0aCBOU0ggd2l0aCBTST0xIG9yIFNJPTAuCj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4g Pj4+Pj4+Cj4gPj4+Pj4+IERvIHlvdSBhZ3JlZT8KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4K PiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gKkZyb206KnNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpKYW1lcyBOCj4gPj4+ Pj4+IEd1aWNoYXJkCj4gPj4+Pj4+ICpTZW50OiogcXVpbnRhLWZlaXJhLCA5IGRlIGZldmVyZWly byBkZSAyMDE3IDE2OjI1Cj4gPj4+Pj4+ICpUbzoqIEZhYnJpY2lvIEZlcnJhejsgRG9sZ2Fub3cs IEFuZHJldyAoTm9raWEgLSBTRyk7IERhdmUgRG9sc29uOwo+ID4+Pj4+PiBFcmljIEMgUm9zZW47 IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4KPiA+Pj4+Pj4gKlN1YmplY3Q6KiBS ZTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4g Pj4+Pj4+Cj4gPj4+Pj4+IEhpIEZhYnJpY2lvLAo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ ID4+Pj4+PiBXZWxjb21lIQo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+PiBZZXMs IHJlbW92YWwgb2YgTlNIIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBhbiBTRkYgb3IgYQo+ID4+ Pj4+PiByZS1jbGFzc2lmaWVyIChzZWN0aW9uIDQsIGJ1bGxldCBwb2ludCAxIGxheXMgdGhpcyBv dXQpLiBXaXRoIHRoZQo+ID4+Pj4+PiBjdXJyZW50IGFyY2hpdGVjdHVyZSB0aGUgU0YgZG9lcyBu b3QgY2FyZSB3aGF0IFNJIHZhbHVlIGl0IGdldHMsCj4gPj4+Pj4+IGl0IGp1c3QgbmVlZHMgdG8g d29ycnkgYWJvdXQgZGVjcmVtZW50aW5nIGl0LCBhbmQgbGVhdmUgaXQgdXAgdG8KPiA+Pj4+Pj4g dGhlIFNGRiB0byBldmFsdWF0ZSB0aGUgU0kgdmFsdWUgYW5kIGFzc29jaWF0ZWQgYWN0aW9uLgo+ ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+PiBKaW0KPiA+Pj4+Pj4KPiA+Pj4+Pj4K PiA+Pj4+Pj4KPiA+Pj4+Pj4gKkZyb206KkZhYnJpY2lvIEZlcnJheiBbbWFpbHRvOmZhYnJpY2lv LWZlcnJhekB0ZWxlY29tLnB0XQo+ID4+Pj4+PiAqU2VudDoqIFRodXJzZGF5LCBGZWJydWFyeSAw OSwgMjAxNyA3OjEzIEFNCj4gPj4+Pj4+ICpUbzoqIERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0g U0cpIDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tCj4gPj4+Pj4+IDxtYWlsdG86YW5kcmV3LmRv bGdhbm93QG5va2lhLmNvbT4+OyBEYXZlIERvbHNvbgo+ID4+Pj4gPGRkb2xzb25Ac2FuZHZpbmUu Y29tCj4gPj4+Pj4+IDxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+PjsgRXJpYyBDIFJvc2Vu IDxlcm9zZW5AanVuaXBlci5uZXQKPiA+Pj4+Pj4gPG1haWx0bzplcm9zZW5AanVuaXBlci5uZXQ+ PjsgSmFtZXMgTiBHdWljaGFyZAo+ID4+Pj4+PiA8amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29t Cj4gPj4+IDxtYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPj47Cj4gPj4+Pj4+IHNm Y0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4KPiA+Pj4+Pj4gKlN1YmplY3Q6KiBSRTog W3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+ Pj4+Cj4gPj4+Pj4+IEhpIGFsbCwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gSSdtIG5ldyBoZXJlIChqdXN0 IHJlYWQgdGhlIGRyYWZ0IGxhc3Qgd2VlaykgYnV0IGFjY29yZGluZyB0bwo+ID4+Pj4+PiBjaGFw dGVyCj4gPj4+Pj4+IDQgKGNoZWNrIGZpZ3VyZSA4IGZvciBleGFtcGxlKSwgYW4gU0YgaXMgbm90 IGFsbG93ZWQgdG8gaW5zZXJ0IG9yCj4gPj4+Pj4+IHJlbW92ZSBOU0guIFRoZSByZW1vdmFsIG9m IE5TSCBpcyByZXBvbnNhYmlsaXR5IG9mIHRoZSBTU0YsIHJpZ2h0Pwo+ID4+Pj4+Pgo+ID4+Pj4+ Pgo+ID4+Pj4+Pgo+ID4+Pj4+PsKgwqAgRmlndXJlIDggbWFwcyBlYWNoIG9mIHRoZSBmb3VyIGFj dGlvbnMgYWJvdmUgdG8gdGhlIGNvbXBvbmVudHMKPiA+Pj4+Pj4gaW4gdGhlCj4gPj4+Pj4+Cj4g Pj4+Pj4+wqDCoMKgIFNGQyBhcmNoaXRlY3R1cmUgdGhhdCBjYW4gcGVyZm9ybSBpdC4KPiA+Pj4+ Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSsKPiA+Pj4+Pj4KPiA+ Pj4+Pj4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgSW5zZXJ0wqDCoMKgwqDC oMKgwqDCoCB8U2VsZWN0IHzCoMKgIFVwZGF0ZcKgwqDCoMKgwqDCoCB8U2VydmljZcKgIHwKPiA+ Pj4+Pj4KPiA+Pj4+Pj4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgb3IgcmVt b3ZlIE5TSMKgIHxTZXJ2aWNlfMKgwqDCoCBOU0jCoMKgwqDCoMKgwqDCoMKgIHxwb2xpY3nCoMKg IHwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfEZ1bmN0aW9ufMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfHNlbGVjdGlvbnwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gfCBDb21wb25lbnTCoMKg wqDCoMKgICstLS0tLS0tLSstLS0tLS0tLStQYXRowqDCoCArLS0tLS0tLS0tLS0tLS0tLSvCoMKg wqDCoMKgwqDCoMKgIHwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqAgfCBE ZWMuwqDCoCB8VXBkYXRlIHzCoMKgwqDCoMKgwqDCoMKgIHwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gfMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IEluc2VydCB8IFJlbW92ZSB8wqDCoMKgwqDC oMKgIHxTZXJ2aWNlIHxDb250ZXh0fMKgwqDCoMKgwqDCoMKgwqAgfAo+ID4+Pj4+Pgo+ID4+Pj4+ PiB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoCB8wqDCoMKg wqDCoMKgwqAgfMKgwqDCoMKgwqDCoCB8IEluZGV4wqAgfEhlYWRlciB8wqDCoMKgwqDCoMKgwqDC oCB8Cj4gPj4+Pj4+Cj4gPj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0t Ky0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0rCj4gPj4+Pj4+Cj4gPj4+Pj4+IHzC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqAgK8KgwqDCoCB8wqDCoCArwqDCoMKg IHzCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgICvCoMKgIHzCoMKgwqDCoMKgwqDC oMKgIHwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gfENsYXNzaWZpZXLCoMKgwqDCoMKgIHzCoMKgwqDCoMKg wqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDC oMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoCB8Cj4gPj4+Pj4+Cj4gPj4+Pj4+ICstLS0tLS0tLS0t LS0tLS0KPiA+Pj4+Pj4gKystLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0t LS0rLS0tLS0tLS0tKwo+ID4+Pj4+Pgo+ID4+Pj4+PiB8U2VydmljZSBGdW5jdGlvbnzCoMKgwqDC oMKgwqDCoCB8wqDCoCArwqDCoMKgIHzCoCArwqDCoMKgIHzCoMKgwqDCoMKgwqDCoCB8wqDCoMKg wqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIHwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gfEZvcndhcmRlcihT RkYpwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgIHzCoMKg wqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIHwKPiA+Pj4+Pj4KPiA+ Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLQo+ID4+Pj4+PiArKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0t LS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0rCj4gPj4+Pj4+Cj4gPj4+Pj4+IHxTZXJ2aWNl wqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDC oMKgwqAgfMKgwqAgK8KgwqDCoCB8wqDCoCArwqDCoCB8wqDCoCArwqDCoMKgwqAgfAo+ID4+Pj4+ Pgo+ID4+Pj4+PiB8RnVuY3Rpb27CoCAoU0YpwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKg wqDCoCB8wqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgIHzCoMKgwqDC oMKgwqDCoMKgIHwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLQo+ID4+Pj4+PiAr Ky0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0rCj4g Pj4+Pj4+Cj4gPj4+Pj4+IHxTRkMgUHJveHnCoMKgwqDCoMKgwqAgfMKgwqAgK8KgwqDCoCB8wqDC oCArwqDCoMKgIHzCoMKgwqDCoMKgwqAgfMKgwqAgK8KgwqDCoCB8wqDCoMKgwqDCoMKgIHzCoMKg wqDCoMKgwqDCoMKgIHwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLSsKPiA+Pj4+Pj4K PiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBGaWd1cmUgODogTlNIIEFjdGlvbiBhbmQgUm9sZSBNYXBwaW5nCj4gPj4+Pj4+Cj4g Pj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+IEFuIFNGIGNvdWxkIHJl Y2VpdmUgYW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIGFuZCByZWNsYXNzaWZ5Cj4gPj4+ Pj4+IGl0IHRvIGEgZGlmZmVyZW50IFNQSSBhbmQgU0ksIHJpZ2h0PyBTbyB3aGVuIGEgU0YgcmVj ZWl2ZXMgYSBOU0gKPiA+Pj4+Pj4gcGFja2V0IHdpdGggU0kgPSAxIHRoYXQgZG9lcyBub3QgbmVj ZXNzYXJpbHkgbWVhbnMgYSBub24gdmFsaWQgcGFja2V0Lgo+ID4+Pj4+Pgo+ID4+Pj4+PiBBbmQg dGhhdCBjYW4gZXZlbiB3b3JrIGZvciBTST0wLCBzaW5jZSB5b3UgZGVjcmVtZW50IHRoZSBTSSBp biB0aGUKPiA+PiBlZ3Jlc3MuCj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+IEZh YnJpY2lvCj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+ Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBP ZiAqRG9sZ2Fub3csCj4gPj4+Pj4+IEFuZHJldyAoTm9raWEgLSBTRykKPiA+Pj4+Pj4gKlNlbnQ6 KiBxdWludGEtZmVpcmEsIDkgZGUgZmV2ZXJlaXJvIGRlIDIwMTcgMDE6NTEKPiA+Pj4+Pj4gKlRv OiogRGF2ZSBEb2xzb247IEVyaWMgQyBSb3NlbjsgSmFtZXMgTiBHdWljaGFyZDsgc2ZjQGlldGYu b3JnCj4gPj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPgo+ID4+Pj4+PiAqU3ViamVjdDoqIFJl OiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQKPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+ Pj4+Pj4KPiA+Pj4+Pj4gSSBhc3N1bWVkIHRoYXQgaWYgd2UgZ2V0IHZhbHVlIDEgd2UgcHJvY2Vz cyB0aGVuIGZvcndhcmQgd2l0aG91dAo+ID4+Pj4+PiBOU0ggaGVhZGVyIChpLmUuKSB0aGlzIGlz IHRoZSBsYXN0IFNGIHByb2Nlc3NpbmcuCj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+Pj4+Cj4gPj4+ Pj4+IFNvIHdpdGggdGhhdCBhc3N1bXB0aW9uLCBhIG1vcmUgZXhwbGljaXQgdGV4dCB3b3VsZCBi ZToKPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gQW4gU0Ygb3IgU0ZDIFByb3h5 IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUCj4gPj4+Pj4+IGRlY3Jl bWVudCB0aGUgU0kgYnkgMSBhZnRlciBwZXJmb3JtaW5nIGFsbCByZXF1aXJlZCBsb2NhbAo+ID4+ Pj4+PiBwcm9jZXNzaW5nIGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUgcGFja2V0IHRvIHRoZSBu ZXh0IFNGRi4gSWYKPiA+Pj4+Pj4gdGhlIHJlc3VsdGluZyBTSSBpcyAwLCB0aGUgU0YgTVVTVCBy ZW1vdmUgdGhlIE5TSCBoZWFkZXIgYmVmb3JlCj4gZm9yd2FyZGluZyB0aGUgcGFja2V0Lgo+ID4+ Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+PiBBbmRyZXcKPiA+Pj4+Pj4KPiA+Pj4+Pj4g KkZyb206ICpzZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmc+Pgo+ID4+Pj4+PiBvbiBiZWhhbGYgb2YgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZp bmUuY29tCj4gPj4+PiA8bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4KPiA+Pj4+Pj4gKkRh dGU6ICpUaHVyc2RheSwgRmVicnVhcnkgOSwgMjAxNyBhdCAyOjA0IEFNCj4gPj4+Pj4+ICpUbzog KkVyaWMgUm9zZW4gPGVyb3NlbkBqdW5pcGVyLm5ldAo+ID4+Pj4+PiA8bWFpbHRvOmVyb3NlbkBq dW5pcGVyLm5ldD4+LCBKYW1lcyBOIEd1aWNoYXJkCj4gPj4+Pj4+IDxqYW1lcy5uLmd1aWNoYXJk QGh1YXdlaS5jb20KPiA+Pj4+Pj4gPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20+ PiwgInNmY0BpZXRmLm9yZwo+ID4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0 Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pgo+ID4+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2Zj XSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQKPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4K PiA+Pj4+Pj4gRXJpYywKPiA+Pj4+Pj4KPiA+Pj4+Pj4gSSB3YXMgbmV2ZXIgcXVpdGUgaGFwcHkg d2l0aCB0aGUgb3V0Y29tZSB0aGF0IG5laXRoZXIgMCBub3IgMSBpcwo+ID4+Pj4+PiBhIHZhbGlk IFNJLgo+ID4+Pj4+Pgo+ID4+Pj4+PiAoQmVjYXVzZSBpZiByZWNlaXZlZCB3aXRoIHZhbHVlIG9m IDEsIGl0IGlzIGRlY3JlbWVudGVkIGFuZAo+ID4+Pj4+PiBkaXNjYXJkZWQuKQo+ID4+Pj4+Pgo+ ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+PiBJdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2YWx1 ZS4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gSSBndWVzcyBJJ20gaW50ZXJl c3RlZCB0byBrbm93IGlmIHRoYXQgaXMgaW1wb3J0YW50IHRvIG90aGVyCj4gPj4+Pj4+IGltcGxl bWVudGVycywgb3IgaWYgdGhhdCB3YXMgZXZlbiB0aGUgaW50ZW50aW9uPwo+ID4+Pj4+Pgo+ID4+ Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+PiAtRGF2ZQo+ID4+Pj4+Pgo+ ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+ Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYg T2YgKkVyaWMgQwo+ID4+Pj4+PiBSb3Nlbgo+ID4+Pj4+PiAqU2VudDoqIFdlZG5lc2RheSwgRmVi cnVhcnkgMDgsIDIwMTcgMTE6NTMgQU0KPiA+Pj4+Pj4gKlRvOiogSmFtZXMgTiBHdWljaGFyZDsg c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPgo+ID4+Pj4+PiAqU3ViamVjdDoqIFJl OiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQKPiA+Pj4+Pj4KPiA+Pj4+Pj4KPiA+ Pj4+Pj4KPiA+Pj4+Pj4gT24gMi83LzIwMTcgMjoyNCBQTSwgSmFtZXMgTiBHdWljaGFyZCB3cm90 ZToKPiA+Pj4+Pj4KPiA+Pj4+Pj4gQSByZXF1ZXN0IHdhcyBtYWRlIHRvIGJlIG1vcmUgc3BlY2lm aWMgYW5kIHVwZGF0ZSB0aGUgdGV4dCBhcyBmb2xsb3dzOgo+ID4+Pj4+Pgo+ID4+Pj4+Pgo+ID4+ Pj4+Pgo+ID4+Pj4+PiAiU2VydmljZSBpbmRleCBNVVNUIGJlIGRlY3JlbWVudGVkICpieSBhIHZh bHVlIG9mIDEqIGJ5IFNlcnZpY2UKPiA+Pj4+Pj4gRnVuY3Rpb25zIG9yIGJ5IFNGQyBQcm94eSBu b2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNlcnZpY2VzIC4iCj4gPj4+Pj4+Cj4gPj4+ Pj4+Cj4gPj4+Pj4+IEEgY291cGxlIG9mIG9ic2VydmF0aW9uczoKPiA+Pj4+Pj4KPiA+Pj4+Pj4g LSBUaGUgdGVybSAiU0ZDIFByb3h5IG5vZGUiIGlzIG5vdCBkZWZpbmVkIGluIGVpdGhlciB0aGUg TlNICj4gPj4+Pj4+IGRyYWZ0IG9yIGluIFJGQyA3NjY1LsKgIEkgdGhpbmsgdGhlIGludGVudGlv biBoZXJlIGlzIHRvIHNheSAiU0ZDClByb3h5Ii4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gLSBJcyB0aGUg aW50ZW50aW9uIHRoYXQgdGhlIFNJIHJlbWFpbiB1bmNoYW5nZWQgd2hpbGUgdGhlIFNGIGlzCj4g Pj4+Pj4+IG9wZXJhdGluZyBvbiB0aGUgcGFja2V0LCBvciBpcyB0aGUgaW50ZW50aW9uIG9ubHkg dGhhdCB0aGUgU0kgYmUKPiA+Pj4+Pj4gZGVjcmVtZW50ZWQgYmVmb3JlIHRoZSBwYWNrZXQgaXMg ZGVsaXZlcmVkIGJ5IHRoZSBTRiBvciBTRkMgUHJveHkKPiA+Pj4+Pj4gdG8gYW4gU0ZGPwo+ID4+ Pj4+Pgo+ID4+Pj4+PiBJJ2Qgc3VnZ2VzdCBlaXRoZXI6Cj4gPj4+Pj4+Cj4gPj4+Pj4+ICJBbiBT RiBvciBTRkMgUHJveHkgcmVjZWl2aW5nIGFuIE5TSC1lbmNhcHN1bGF0ZWQgcGFja2V0IE1VU1QK PiA+Pj4+Pj4gZGVjcmVtZW50IHRoZSBTSSBieSAxIGJlZm9yZSBkZWxpdmVyaW5nIHRoZSBwYWNr ZXQgdG8gdGhlIG5leHQgU0ZGIgo+ID4+Pj4+Pgo+ID4+Pj4+PiBvcgo+ID4+Pj4+Pgo+ID4+Pj4+ PiAiQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tl dCBNVVNUCj4gPj4+Pj4+IGRlY3JlbWVudCB0aGUgU0kgYnkgMSBiZWZvcmUgZGVsaXZlcmluZyB0 aGUgcGFja2V0IHRvIHRoZSBuZXh0Cj4gPj4+Pj4+IFNGRiwgYnV0IG5vdCB1bnRpbCB0aGUgU0Yg aGFzIGZpbmlzaGVkIGFsbCBpdHMgb3RoZXIgcHJvY2Vzc2luZyBvZiB0aGUKPiBwYWNrZXQiCj4g Pj4+Pj4+Cj4gPj4+Pj4+IGRlcGVuZGluZyB1cG9uIHdoaWNoIGlzIGludGVuZGVkLgo+ID4+Pj4+ Pgo+ID4+Pj4+PiBJIHRoaW5rIGFuIGltcGxpY2F0aW9uIG9mIHRoZXNlIHByb2NlZHVyZXMgaXMg dGhhdCBhbiBTSSB2YWx1ZSBvZgo+ID4+Pj4+PiAxIGlzIG5vdCB2YWxpZC7CoCBJZiBhbiBTRiBn ZXRzIGFuIE5TSCBwYWNrZXQgd2l0aCBhbiBTSSBvZiAxLCB0aGUKPiA+Pj4+Pj4gU0Ygd2lsbCBk ZWNyZW1lbnQgdGhlIFNJIChzZXR0aW5nIGl0IHRvIDApLCBzZW5kIHRoZSBwYWNrZXQgdG8gYW4K PiA+Pj4+Pj4gU0ZGLCBhbmQgdGhlIFNGRiB3aWxsIGRpc2NhcmQgaXQsIGJlY2F1c2UgMCBpcyBh biBpbnZhbGlkIFNJCj4gPj4+Pj4+IHZhbHVlLsKgIElzIHRoYXQgdGhlIGludGVudGlvbj8KPiA+ Pj4+Pj4KPiA+Pj4+Pj4gVGhlIGRyYWZ0IG1ha2VzIGl0IGNsZWFyICh3ZWxsLCBzb3J0IG9mKSB0 aGF0IGFuIFNGRiBzaG91bGQKPiA+Pj4+Pj4gZGlzY2FyZCBhIHBhY2tldCB3aXRoIGFuIFNJIG9m IDAsIGJ1dCBkb2VzIG5vdCBzZWVtIHRvIHNheSB0aGF0Cj4gPj4+Pj4+IGFuIFNGIG9yIFNGQyBQ cm94eSBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCBpdCByZWNlaXZlcyB3aXRoIGFuIFNJCj4gPj4+ Pj4+IG9mIDAuwqAgSXQgd291bGQgcHJvYmFibHkgYmUgYSBnb29kIGlkZWEgdG8gc2F5IHRoYXQu Cj4gPj4+Pj4+Cj4gPj4+Pj4+IFNvbWUgdGV4dCBpbiB0aGUgZHJhZnQgKGUuZy4sIHNlY3Rpb24g Ny4xKSBzdGF0ZXMgdGhhbiBhbiBTRkYKPiA+Pj4+Pj4gc2hvdWxkIGRpc2NhcmQgYSBwYWNrZXQg d2l0aCBhbiBTSSBvZiB6ZXJvLCBidXQgb3RoZXIgdGV4dCBpbiB0aGUKPiA+Pj4+Pj4gZHJhZnQg KGUuZy4sIHNlY3Rpb24gMy4zKSBvbmx5IHNheXMgdGhhdCBhbiBTRkYgc2hvdWxkIGxvZyBhbgo+ ID4+Pj4+PiBlcnJvciBpZiBpdCBzZWVzIGFuIFNJIG9mIHplcm8uwqAgSXQncyBwcm9iYWJseSBi ZXN0IHRvIGNoYW5nZSB0aGUKPiA+Pj4+Pj4gdGV4dCBpbiAzLjMuIHRvIHNheSAiU0hPVUxEIGdl bmVyYXRlIGFuIGVycm9yL2xvZyBtZXNzYWdlIGFuZAo+ID4+Pj4+PiBNVVNUIGRpc2NhcmQgdGhl IHBhY2tldCIsIG9yIHNvbWV0aGluZyBzaW1pbGFyLgo+ID4+Pj4+Pgo+ID4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4+Pj4+PiBzZmMgbWFp bGluZyBsaXN0Cj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4KPiA+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMKPiA+Pj4+Pgo+ ID4+Pj4+Cj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiA+Pj4+PiBzZmMgbWFpbGluZyBsaXN0Cj4gPj4+Pj4gc2ZjQGlldGYub3JnCj4gPj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMKPiA+Pj4+Pgo+ID4+ Pj4KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gPj4+PiBzZmMgbWFpbGluZyBsaXN0Cj4gPj4+PiBzZmNAaWV0Zi5vcmcKPiA+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjCj4gPj4+Cj4gPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPj4+IHNmYyBtYWlsaW5n IGxpc3QKPiA+Pj4gc2ZjQGlldGYub3JnCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjCj4gPj4KPiA+Cgo= ----_com.samsung.android.email_2009828933707010 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlRob3NlIGNsYXJpZmljYXRp b25zIHNlZW0gYWNjdXJhdGUgYW5kIHVzZWZ1bCB0byBtZS4gJm5ic3A7PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5Zb3Vycyw8L2Rpdj48ZGl2PkpvZWw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPjxk aXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyIgZGlyPSJhdXRvIj5TZW50IHZp YSB0aGUgU2Ftc3VuZyBHYWxheHkgU8KuIDYsIGFuIEFUJmFtcDtUIDRHIExURSBzbWFydHBob25l PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29s b3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5h bCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBBZHJpYW4gRmFycmVsICZsdDthZHJp YW5Ab2xkZG9nLmNvLnVrJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDIvMTEvMTcgIDE3OjM1ICAoR01U LTA1OjAwKSA8L2Rpdj48ZGl2PlRvOiAiJ0pvZWwgTS4gSGFscGVybiciICZsdDtqbWhAam9lbGhh bHBlcm4uY29tJmd0OywgJ1JvbiBQYXJrZXInICZsdDtSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tJmd0OyA8L2Rpdj48ZGl2PkNjOiBzZmNAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0 OiBSRTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50IDwvZGl2PjxkaXY+PGJyPjwv ZGl2PjwvZGl2PkpvZWwsPGJyPjxicj5UaGUgLTEwIHZlcnNpb24gb2YgTlNIIHNheXM8YnI+PGJy PiZuYnNwOyZuYnNwOyBUaGU8YnI+Jm5ic3A7Jm5ic3A7IHZhbHVlIHplcm8gZm9yIFNJIGlzIG5v dCB2YWxpZCBhbmQgaW5kaWNhdGVzIGEgYnJva2VuIFNGQyBvcjxicj4mbmJzcDsmbmJzcDsgbWFs ZnVuY3Rpb25pbmcgU0YuPGJyPjxicj5Zb3UgYXJlIHNheWluZyB0aGF0IHRoZSBsYXR0ZXIgb2Yg dGhlc2UgaXMgbm90IHRydWUuPGJyPkkgY2FuJ3QgdGVsbCB3aGV0aGVyIHRoZSBmb3JtZXIgaXMg cmVhbGx5IHRydWUgb3IsIHBlcmhhcHMsIHJlcHJlc2VudHMgYSBkaXNjYXJkPGJyPnRhaWwgb2Yg YW4gU0ZDIHdoZXJlIHNvbWUgKGJ1dCBub3QgYWxsKSBwYWNrZXRzIGFyZSByZWNsYXNzaWZpZWQg cGVyIFJvbi48YnI+PGJyPkxpa2UgSSBzYWlkOjxicj48YnI+Jmd0OyBMZXQncyBjbGFyaWZ5IHRo YXQgaXQgaXMgT0sgZm9yIGFuIFNGIHRvIHNlbmQgYSBwYWNrZXQgd2l0aCBTST0wPGJyPjxicj5U aGVuIChvZiBjb3Vyc2UpIGl0IGlzIGFsc28gT0sgZm9yIGFuIFNGRiB0byByZWNlaXZlIFNJPTAs IGJ1dCBJIHRoaW5rIHRoZTxicj5leGlzdGluZyAiZGlzY2FyZCIgdGV4dCBjb3ZlcnMgdGhhdCBj YXNlLjxicj48YnI+QWRyaWFuPGJyPjxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPiZndDsgRnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bV08YnI+Jmd0OyBTZW50OiAxMSBGZWJydWFyeSAyMDE3IDE4OjA4PGJyPiZndDsgVG86IFJvbiBQ YXJrZXI7IGFkcmlhbkBvbGRkb2cuY28udWs7ICdEYXZlIERvbHNvbic8YnI+Jmd0OyBDYzogJ0Vy aWMgQyBSb3Nlbic7ICdEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKSc7IHNmY0BpZXRmLm9y ZzsgJ0phbWVzIE48YnI+Jmd0OyBHdWljaGFyZCc7ICdGYWJyaWNpbyBGZXJyYXonPGJyPiZndDsg U3ViamVjdDogUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudDxicj4mZ3Q7IDxi cj4mZ3Q7IEkgd2FzIGNvbW1lbnRpbmcsIGluIHBlcnNvbmFsIGhhdCwgYWJvdXQgdGhlIGlzc3Vl IG9mIHdoZXRoZXIgdGhlcmUgd2FzPGJyPiZndDsgc29tZSBzb3J0IG9mIHByb2JsZW0gd2l0aCB0 aGUgaW1wYWN0IG9mIHRoZSBjdXJyZW50IGRlc2NyaXB0aW9uIG9uIFNJPTE8YnI+Jmd0OyBwYWNr ZXRzIGFycml2aW5nIGF0IGFuIFNGLiZuYnNwOyBJdCBzZWVtcyB0byBtZSB0aGF0IHlvdXIgZXhh bXBsZSBzaG93cyB0aGF0PGJyPiZndDsgc3VjaCBhbiBlZmZlY3QgaXMgc29tZXRpbWVzIHVzZXVs Ljxicj4mZ3Q7IEl0IHdpbGwgYWxzbyBzb21ldGltZXMgcHJvZHVjZSBwYWNrZXQgZHJvcHMgYnkg dGhlIFNGRiwgd2hlbiB0aGUgU0YgZG9lczxicj4mZ3Q7IG5vdCB0ZXJtaW5hdGUgdGhlIHBhY2tl dC4mbmJzcDsgT2theSwgc28gYmUgaXQuPGJyPiZndDsgSXQgaXMgbm90IGV2ZW4gY2xlYXIgdGhl cmUgaXMgYW55dGhpbmcsIGluIEFkcmlhbidzIHBocmFzZSwgdG8gcGFpbnQgcmVkPGJyPiZndDsg aGVyZS48YnI+Jmd0OyA8YnI+Jmd0OyBZb3Vycyw8YnI+Jmd0OyBKb2VsPGJyPiZndDsgPGJyPiZn dDsgT24gMi8xMS8xNyAxMjo1OSBQTSwgUm9uIFBhcmtlciB3cm90ZTo8YnI+Jmd0OyAmZ3Q7IEhp LCBKb2VsLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IERvZXMgeW91ciBjb21tZW50IHBlcnRh aW4gdG8gbXkgc29tZXdoYXQgb2ZmIHRvcGljIHF1ZXN0aW9uIHdoaWNoIHdhczxicj4mZ3Q7IHJl bGF0ZWQgdG8gb25lIG9mIEFkcmlhbidzIHRhbmdlbnRpYWwgaXNzdWVzLCBvciB0byBBZHJpYW4n cyBvcmlnaW5hbCBTRj0xPGJyPnRvcGljPzxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFRoYW5r cy48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBSb248YnI+Jmd0 OyAmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+Jmd0OyAmZ3Q7IEZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb21dPGJyPiZndDsgJmd0OyBTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMTEsIDIwMTcg MTI6MzEgUE08YnI+Jmd0OyAmZ3Q7IFRvOiBSb24gUGFya2VyICZsdDtSb25fUGFya2VyQGFmZmly bWVkbmV0d29ya3MuY29tJmd0OzsgYWRyaWFuQG9sZGRvZy5jby51azs8YnI+Jmd0OyAnRGF2ZSBE b2xzb24nICZsdDtkZG9sc29uQHNhbmR2aW5lLmNvbSZndDs8YnI+Jmd0OyAmZ3Q7IENjOiAnRXJp YyBDIFJvc2VuJyAmbHQ7ZXJvc2VuQGp1bmlwZXIubmV0Jmd0OzsgJ0RvbGdhbm93LCBBbmRyZXcg KE5va2lhIC0gU0cpJzxicj4mZ3Q7ICZsdDthbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tJmd0Ozsg c2ZjQGlldGYub3JnOyAnSmFtZXMgTiBHdWljaGFyZCc8YnI+Jmd0OyAmbHQ7amFtZXMubi5ndWlj aGFyZEBodWF3ZWkuY29tJmd0OzsgJ0ZhYnJpY2lvIEZlcnJheicgJmx0O2ZhYnJpY2lvLWZlcnJh ekB0ZWxlY29tLnB0Jmd0Ozxicj4mZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtzZmNdIE5TSCBTZXJ2 aWNlIEluZGV4IERlY3JlbWVudDxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFBlcnNvbmFsbHks IHdoYXQgeW91IGRlc2NyaWJlIHNvdW5kcyBsaWtlIGEgcXVpdGUgcmVhc29uYWJsZSBjYXNlIHdo ZXJlIGE8YnI+Jmd0OyBwYWNrZXQgYXJyaXZlIGF0IHRoZSBTRiB3aXRoIGFuIFNJIG9mIDEgd2ls bCBwcm9kdWNlIGV4YWN0bHkgdGhlIGRlc2lyZWQ8YnI+YmVoYXZpb3IuPGJyPiZndDsgJmd0Ozxi cj4mZ3Q7ICZndDsgV2hpY2ggc3VnZ2VzdHMsIHRvIG15IGxpbWl0ZWQgdmlldywgdGhhdCB0aGUg Y3VycmVudCB0ZXh0IHdvcmtzIGZpbmUuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgWW91cnMs PGJyPiZndDsgJmd0OyBKb2VsPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgT24gMi8xMS8xNyAx MTo1NSBBTSwgUm9uIFBhcmtlciB3cm90ZTo8YnI+Jmd0OyAmZ3Q7Jmd0OyBIaSwgQWRyaWFuLjxi cj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgTm90IHRoZSBvcmlnaW5hbCB0b3BpYywg cGVyIHNlLCBidXQgd3J0IHlvdXIgY29tbWVudDo8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7ICogT24gdGhlIG90aGVyIGhhbmQsIHdlIGFwcGVhciB0byBiZSBjbGVhciBhYm91dCBh biBTRiB0aGF0IHN0cmlwcyB0aGUgTlNIPGJyPiZndDsgYW5kIGZvcndhcmRzIHRoZSB0cmFmZmlj IGFzIG5hdGl2ZSA6IHRoaXMgaXMgY3VycmVudGx5IGZvcmJpZGRlbi48YnI+Jmd0OyAmZ3Q7Jmd0 Ozxicj4mZ3Q7ICZndDsmZ3Q7IEknbSB3b25kZXJpbmcgaG93IHRvIHJlY29uY2lsZSB0aGlzIHRv IGEgdHJhbnNwYXJlbnQgSFRUUCBQcm94eSB0aGF0IGRvZXM8YnI+bm90PGJyPiZndDsgcHJlc2Vy dmUgdGhlIG9yaWdpbmFsIHNvdXJjZS1JUD8mbmJzcDsmbmJzcDsgRG9lcyB0aGlzIG1lYW4gdGhh dCBpdCBpcyBtYW5kYXRvcnkgZm9yPGJyPnN1Y2ggYW48YnI+Jmd0OyBTRiB0byBhbHNvIGJlIGEg Y2xhc3NpZmllciBzbyBpdCBjYW4gc2VsZi1jbGFzc2lmeSBpdHMgb3duIHJlbGF0ZWQgZmxvd3M8 YnI+KGkuZS4sIHVzaW5nIGl0czxicj4mZ3Q7IG93biB2aXNpYmxlIElQIGFkZHJlc3Nlcyk/Jm5i c3A7Jm5ic3A7Jm5ic3A7IEZyb20gU0ZGIHBlcnNwZWN0aXZlLCBpdCB3b3VsZCBsb29rIGxpa2Ug YWxsPGJyPnBhY2tldHM8YnI+Jmd0OyBvbiB0aGUgYWNjZXNzIHNpZGUgYXJlIGRyb3BwZWQgaW4g dGhlIHVwc3RyZWFtIGRpcmVjdGlvbiBhbmQgaW5qZWN0ZWQgYnkgdGhlPGJyPlNGPGJyPiZndDsg aW4gdGhlIGRvd25zdHJlYW0gZGlyZWN0aW9uLiZuYnNwOyZuYnNwOyBPbiB0aGUgSW50ZXJuZXQg c2lkZSwgaXQgd291bGQgbG9vayBsaWtlIGFsbDxicj5wYWNrZXRzPGJyPiZndDsgYXJlIGluamVj dGVkIGJ5IHRoZSBTRiBpbiB0aGUgdXBzdHJlYW0gZGlyZWN0aW9uIGFuZCBkcm9wcGVkIGluIHRo ZSBkb3duc3RyZWFtPGJyPiZndDsgZGlyZWN0aW9uLjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDsgVGhhbmtzIGZvciBhbnkgY2xhcmlmaWNhdGlvbi48YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbjxicj4mZ3Q7ICZndDsmZ3Q7PGJy PiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsgJmd0OyZndDsgRnJvbTogQWRyaWFuIEZhcnJlbCBb bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWtdPGJyPiZndDsgJmd0OyZndDsgU2VudDogU2F0dXJk YXksIEZlYnJ1YXJ5IDExLCAyMDE3IDExOjM0IEFNPGJyPiZndDsgJmd0OyZndDsgVG86ICdEYXZl IERvbHNvbicgJmx0O2Rkb2xzb25Ac2FuZHZpbmUuY29tJmd0OzsgJ0pvZWwgTS4gSGFscGVybic8 YnI+Jmd0OyAmZ3Q7Jmd0OyAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7IFJvbiBQYXJrZXIg Jmx0O1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20mZ3Q7PGJyPiZndDsgJmd0OyZndDsg Q2M6ICdFcmljIEMgUm9zZW4nICZsdDtlcm9zZW5AanVuaXBlci5uZXQmZ3Q7OyAnRG9sZ2Fub3cs IEFuZHJldyAoTm9raWEgLTxicj4mZ3Q7ICZndDsmZ3Q7IFNHKScgJmx0O2FuZHJldy5kb2xnYW5v d0Bub2tpYS5jb20mZ3Q7OyBzZmNAaWV0Zi5vcmc7ICdKYW1lcyBOIEd1aWNoYXJkJzxicj4mZ3Q7 ICZndDsmZ3Q7ICZsdDtqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20mZ3Q7OyAnRmFicmljaW8g RmVycmF6Jzxicj4mZ3Q7ICZndDsmZ3Q7ICZsdDtmYWJyaWNpby1mZXJyYXpAdGVsZWNvbS5wdCZn dDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogW3NmY10gTlNIIFNlcnZpY2UgSW5kZXgg RGVjcmVtZW50PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBJIGhhdGUgdG8gZG8g bXkgaW1wZXJzb25hdGlvbiBvZiBFcmljLCBidXQuLi48YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7ICJPbiB0aGUgd2lyZSIgaXMgdGhlIGNydW5jaC48YnI+Jmd0OyAmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7IFNvbWUgaGF2ZSBzYWlkIHRoYXQgdGhlcmUgbXVzdCBiZSBubyB2aXNp YmxlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdGhyZWU8YnI+Jmd0OyBjYXNlOjxicj4mZ3Q7ICZn dDsmZ3Q7IC0gb24gdGhlIHdpcmUgYmV0d2VlbiBTRkYgYW5kIFNGPGJyPiZndDsgJmd0OyZndDsg LSBvbiB0aGUgd2lyZSBiZXR3ZWVuIFNGIGFuZCBTRkY8YnI+Jmd0OyAmZ3Q7Jmd0OyAtIG9uIHRo ZSB3aXJlIGJldHdlZW4gU0ZGIGFuZCBTRkY8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsm Z3Q7IElmIHRoaXMgaG9sZHMgdGhlbiB5b3UgYXJlIGNvcnJlY3QgdGhhdCBzZW5kaW5nIFNJPTEg aW4gdGhlIGZpcnN0IGNhc2U8YnI+cmVxdWlyZXM8YnI+Jmd0OyB0aGUgU0YgdG8gZG8gbW9yZSB0 aGFuIGEgc2ltcGxlIGRlY3JlbWVudCAoYWx0aG91Z2ggZGVjcmVtZW50IGFuZCBkaXNjYXJkIGlz PGJyPiZndDsgaGFyZGx5IHBhaW5mdWwpLiBBbmQgaXQgbWVhbnMgdGhhdCBTST0xIGlzIGEgZHVi aW91cyB2YWx1ZSBpbiBhbiBTRlAuPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBP biB0aGUgb3RoZXIgaGFuZCwgd2UgYXBwZWFyIHRvIGJlIGNsZWFyIGFib3V0IGFuIFNGIHRoYXQg c3RyaXBzIHRoZSBOU0g8YnI+YW5kPGJyPiZndDsgZm9yd2FyZHMgdGhlIHRyYWZmaWMgYXMgbmF0 aXZlIDogdGhpcyBpcyBjdXJyZW50bHkgZm9yYmlkZGVuLiBTbyB0aGVyZSBpcyBubzxicj4mZ3Q7 IGFsdGVybmF0aXZlIGZvciBhbiBTRiByZWNlaXZpbmcgU0k9MSBleGNlcHQgdG8gZGlzY2FyZCB0 aGUgcGFja2V0Ljxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgTm93LCBkb2VzIHRo YXQgbWVhbiB0aGF0IGFuIFNGRiBzaG91bGQgbmV2ZXIgc2VuZCBhIHBhY2tldCB3aXRoIFNJPTE/ IFdlbGwsPGJyPiZndDsgcG9zc2libHkgaXQgaXMgT0sgZm9yIGEgZmV3IHNwZWNpYWxpc3QgU0Zz IGludGVuZGVkIHRvIHNpdCBhdCB0aGUgZW5kIG9mIHRoZTxicj5jaGFpbiBhbmQ8YnI+Jmd0OyBi ZSBhIGJpdCBidWNrZXQgd2l0aCBhbmFseXNpcy4gQnV0LCBmb3IgbW9zdCBTRnMgdGhlcmUgd291 bGQgYmUgbm8gcG9pbnQuPGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBNYXliZSAo anVzdCBtYXliZSkgd2Ugc2hvdWxkIHN0b3AgbGV0dGluZyB0aGUgdGFpbCB3YWcgdGhlIGRvZyEg VGhhdCBpcyw8YnI+bGV0J3M8YnI+Jmd0OyBkZWNpZGUgb24gdGhlIGZ1bmN0aW9uYWwgYmVoYXZp b3Igd2Ugd2FudCB0byBzZWUgYW5kIHRoZW4gZGVzaWduIHRoZSBwcm90b2NvbDxicj4mZ3Q7IHRv IG1hdGNoLjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsgQWRyaWFuPGJyPiZndDsg Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgRnJvbTogRGF2ZSBEb2xzb24gW21haWx0bzpkZG9sc29uQHNh bmR2aW5lLmNvbV08YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogMTAgRmVicnVhcnkgMjAxNyAy MjoyNjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUbzogYWRyaWFuQG9sZGRvZy5jby51azsgJ0pvZWwg TS4gSGFscGVybic7ICdSb24gUGFya2VyJzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBDYzogJ0VyaWMg QyBSb3Nlbic7ICdEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKSc7IHNmY0BpZXRmLm9yZzs8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgJ0phbWVzIE4gR3VpY2hhcmQnOyAnRmFicmljaW8gRmVycmF6 Jzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogW3NmY10gTlNIIFNlcnZpY2UgSW5k ZXggRGVjcmVtZW50PGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7IEFk cmlhbiw8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSSB0aGluayBJIGFncmVlIHdpdGggZXZlcnl0aGlu ZyB5b3Ugc2FpZC48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgQnV0IHlvdSBkaWQgbm90IHN1Z2dlc3Qg d2hldGhlciBvciBub3QgeW91IHRoaW5rIHRoYXQgU0k9MCBzaG91bGQgYmU8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsgdmFsaWQgb248YnI+Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsgd2lyZS48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSSdtIHNheWluZyBpdCBjb3VsZCB3b3JrLCBp ZiB0aGUgbmV4dCBob3AgaXMgYSBwYXRoIHRlcm1pbnVzLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBJZiBJIHVuZGVyc3RhbmQgSm9lbCBjb3JyZWN0bHksIGhlIHNh eXMgd2Ugc2hvdWxkbid0IHNlbmQgU0k9MCZuYnNwOyBpbjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBj YXNlIHRoZTxicj4mZ3Q7ICZndDsmZ3Q7IG5leHQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgaG9wIGJs aW5kbHkgZGVjcmVtZW50cyBpdC48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgLS0mZ3Q7IHRoaXMgc2Vl bXMgdG8gbWVhbiBTST0xIGNhbm5vdCBiZSB1c2VkIGV4Y2VwdCBhdCB0aGUgdGVybWludXMgb3I8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgLS0mZ3Q7IHdoZW4gdGhlPGJyPiZndDsgJmd0OyZndDsmZ3Q7 IFNGIGlzIGV4cGVjdGVkIHRvIGRyb3AgYWxsIHBhY2tldHMuPGJyPiZndDsgJmd0OyZndDsmZ3Q7 IFNvIEkgdGhpbmsgdGhpcyBpcyBhbiB1bm5lY2Vzc2FyeSBzZWF0IGJlbHQsIHRyeWluZyB0byBh bnRpY2lwYXRlPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGJ1Z3MgaW48YnI+Jmd0OyAmZ3Q7Jmd0OyBk b3duLTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBzdHJlYW0gZGV2aWNlcy48YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSSByZWFsaXplIHRoZSBjdXJyZW50IGxhbmd1YWdl IGhhcyBiZWVuIHRoZXJlIGEgbG9uZyB0aW1lLCBhbmQgaWYgaXQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsgaXM8YnI+Jmd0OyAmZ3Q7Jmd0OyBpbXBvcnRhbnQgdG88YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsg YW55b25lIHRoZW4gaXQgc2hvdWxkIHJlbWFpbi48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgTm9uZXRo ZWxlc3MsIEkgdGhpbmsgZGV2aWNlcyBjb3VsZCBzYWZlbHkgaGFuZGxlIFNJPTAgb24gdGhlIHdp cmU8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgd2l0aG91dCBicmVha2luZyBhbnl0aGluZy48YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgQnV0IEknbSBub3QgcHVzaGluZyBm b3IgYSBjaGFuZ2UsIHNpbmNlIHRoZSBjdXJyZW50IGJlaGF2aW9yIHNlZW1zPGJyPiZndDsgJmd0 OyZndDsmZ3Q7IGltcG9ydGFudDxicj4mZ3Q7ICZndDsmZ3Q7IHRvPGJyPiZndDsgJmd0OyZndDsm Z3Q7IHNvbWUuPGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7IC1EYXZl PGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZn dDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsgJmd0OyZndDsmZ3Q7IEZy b206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFu IEZhcnJlbDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDEwLCAy MDE3IDk6MTYgQU08YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgVG86IERhdmUgRG9sc29uOyAnSm9lbCBN LiBIYWxwZXJuJzsgJ1JvbiBQYXJrZXInPGJyPiZndDsgJmd0OyZndDsmZ3Q7IENjOiAnRXJpYyBD IFJvc2VuJzsgJ0RvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpJzsgc2ZjQGlldGYub3JnOzxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyAnSmFtZXMgTiBHdWljaGFyZCc7ICdGYWJyaWNpbyBGZXJyYXon PGJyPiZndDsgJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRl eCBEZWNyZW1lbnQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgT2gs IHlvdSBmaW5hbGx5IHB1c2hlZCBtZSBpbnRvIHRoaXMgZGlzY3Vzc2lvbiwgRGF2ZS48YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgV2UncmUgYnVpbGRpbmcgYSBwcm90 b2NvbC4gd2l0aCBhIHByb3RvY29sLCB5b3UgY2Fubm90IChtdXN0IG5vdCk8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsgYXNzdW1lIGdvb2QgYmVoYXZpb3IgZnJvbSB5b3VyIG5laWdoYm9yLjxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBTbyBpZiB0aGUgU0YgdG91Y2hlcyB0 aGUgU0kgKHdoaWNoIGl0IGRvZXMpIHdlIG11c3QgZGVmaW5lIHRoZSBlZGdlPGJyPiZndDsgJmd0 OyZndDsgY29uZGl0aW9ucy48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSWYgaXQgaXMgdGhlIFNGJ3Mg am9iIHRvIGRlY3JlbWVudCB0aGUgU0ksIHRoZW4gd2UgbXVzdCBhbHNvIGRlZmluZTxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyB3aGF0IGl0PGJyPiZndDsgJmd0OyZndDsgZG9lczxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyB3aGVuIFNJPTAgKG90aGVyd2lzZSwgaXQgd2lsbCBzZXQgU0kgdG8gMC0xKS48YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsgSWYgdGhlIFNGIGlzIG5vdCBhbGxvd2VkIHRvIGRlY3JlbWVudCB0 aGUgU0kgYmVsb3cgemVybyAod2hpY2ggbWFrZXM8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgc2Vuc2Up IHdlIG11c3QgZGVmaW5lIHdoYXQgaXQgbXVzdCBkby48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgU2lu Y2UgU0ZzIGFyZSBhbGxvd2VkIHRvIGRyb3AgcGFja2V0cyAoaW5kZWVkIHRoYXQgaXMgb25lIG9m IHRoZWlyPGJyPiZndDsgJmd0OyZndDsmZ3Q7IG1haW4gam9iczxicj4mZ3Q7ICZndDsmZ3Q7IDst KTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGVuIHRoaXMgd291bGQgYmUgZmluZS48YnI+Jmd0OyAm Z3Q7Jmd0OyZndDsgQWxsIHRoYXQgd291bGQgYmUgbGVmdCBpcyB0byBkZWZpbmUgd2hldGhlciB0 aGV5IGFwcGx5IHRoZSB0ZXN0PGJyPiZndDsgJmd0OyZndDsmZ3Q7IGJlZm9yZSBvcjxicj4mZ3Q7 ICZndDsmZ3Q7IGFmdGVyPGJyPiZndDsgJmd0OyZndDsmZ3Q7IG5vcm1hbCBwcm9jZXNzaW5nLjxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBBcyBhbiBhc2lkZSwgSSBh Z3JlZSB3aXRoIERvbiB0aGF0IFRUTCBoZWxwcyByZWxheCB0aGlzIGEgbGl0dGxlLCBidXQ8YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsgZG9lcyBub3QgZ2V0IHVzIGFsbCB0aGUgd2F5IHRoZXJlLjxicj4m Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBDaGVlcnMsPGJyPiZndDsgJmd0 OyZndDsmZ3Q7IEFkcmlhbjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2 ZSBEb2xzb248YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IDA5IEZlYnJ1YXJ5IDIwMTcg MjE6MDA8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQ YXJrZXI8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IENjOiBGYWJyaWNpbyBGZXJyYXo7IEphbWVz IE4gR3VpY2hhcmQ7IHNmY0BpZXRmLm9yZzsgRXJpYyBDIFJvc2VuOzxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRyk8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBEaXNjdXNzaW5n IG1pc2NvbmZpZ3VyZWQgU0ZGcyBpcyBhIHN0cmF3LW1hbiBhcmd1bWVudC4gT25jZSBvbmU8YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHN0YXJ0czxicj4mZ3Q7ICZndDsmZ3Q7IHRyeWluZzxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyB0bzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYW50aWNpcGF0ZSBk b3duLXN0cmVhbSBkZXZpY2VzIGJlaW5nIG1pc2NvbmZpZ3VyZWQsIG9uZSBjYW4gaW52ZW50IGE8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGxvdCBvZjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBzaWxs eTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZW1lbnRzLjxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDtGcm9tIGFuIGFlc3RoZXRpYyBw b2ludCBvZiB2aWV3LCBJIHRoaW5rIGl0J3MgYmFkIHRoYXQgdGhlcmUgYXJlPGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdHdvIFNJPGJyPiZndDsgJmd0OyZndDsmZ3Q7IHZhbHVlcyAoMDxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYW5kIDEpIHRoYXQgY2Fubm90IGJlIHVzZWQuPGJyPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhlIHJlYWwgcmVx dWlyZW1lbnQsIElNTywgaXMgdGhhdCBubyBkZXZpY2UgZGVjcmVtZW50cyAwIGFuZCBmb3J3YXJk czxicj4mZ3Q7IE5TSC48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNpbmNlIG9ubHkgU0ZzIGRl Y3JlbWVudCBTSSwgb25seSBTRnMgbmVlZCB0byBkbyB0aGlzIGNoZWNrLjxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEFuZCBhbnkgZGlzY3Vzc2lvbiBh Ym91dCBidWdneSBTRnMuLi4gd2VsbCB0aGVyZSBpcyBhIGxvdCBvZiBiYWQ8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IHN0dWZmIHRoYXQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgYnVncyBjYW48YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNhdXNlLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IEZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5j b21dPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDks IDIwMTcgMjo1NCBQTTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVG86IFJvbiBQYXJrZXI7IERh dmUgRG9sc29uPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBDYzogRXJpYyBDIFJvc2VuOyBzZmNA aWV0Zi5vcmc7IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpOyBKYW1lczxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgTjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBHdWljaGFyZDs8YnI+Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IEZhYnJpY2lvIEZlcnJhejxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg U3ViamVjdDogUmU6IFtzZmNdIE5TSCBTZXJ2aWNlIEluZGV4IERlY3JlbWVudDxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IEZyb20gbXkgcGVy c3BlY3RpdmUgYXMgYW4gaW5kaXZpZHVhbCBwYXJ0aWNpcGFudCBpbiB0aGlzIHdvcmssPGJyPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBkZWNsYXJpbmcgdGhhdCAwIG11c3QgYmUgZHJvcHBlZCBpcyBh IG1hdHRlciBvZiByb2J1c3RuZXNzLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IGlmIHdlIGFsbG93IDAgdG8gYmUgcHJvY2Vzc2VkIGZvciBleGl0IGF0 IGFuIFNGRiwgdGhlbiBhPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBtaXMtY29uZmlndXJlZCBT RkYgY291bGQgZWFzaWx5IGNvbnRpbnVlIHByb2Nlc3Npbmcgc3VjaCBhIHBhY2tldC48YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE5vdywgaXQgaXMgdHJ1ZSB0aGF0IFRUTCB3aWxsIGV2ZW50dWFs bHkgZHJvcCBpdCwgYnV0IHRoYXQgaXMgYW48YnI+ZXhwZW5zaXZlPGJyPiZndDsgZmFsbGJhY2su PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgTW9yZSBp bXBvcnRhbnRseSwgcHJlc3VtYWJseSB0aGUgbmV4dCBlbnRpdGl5IGRvd24gdGhlIGluY29ycmVj dDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcGF0aCB3b3VsZCBkcm9wIGl0IGZvciBhIDI1NSBT SS4mbmJzcDsgQnV0IGF0IHRoYXQgcG9pbnQgd2UgYXJlIGdldHRpbmc8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IHRoZSBlcnJvciBpbiB0aGUgd3JvbmcgcGxhY2UsIG1ha2luZyBpdCBoYXJkZXIg dG8gZGlhZ25vc2UgYW5kIHJlcGFpci48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBZb3Vycyw8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEpvZWw8YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBPbiAyLzkvMTcg MTI6NDIgUE0sIFJvbiBQYXJrZXIgd3JvdGU6PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg YWdyZWUuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBPbiBGZWIgOSwgMjAxNywgYXQgMTI6MjggUE0sIERhdmUgRG9sc29uICZsdDtkZG9s c29uQHNhbmR2aW5lLmNvbTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDttYWlsdG86 ZGRvbHNvbkBzYW5kdmluZS5jb20mZ3Q7Jmd0OyB3cm90ZTo8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJJ20gbm90IGNsZWFyIG9u IHdoeSB0aGlzIGlzIGJyb2tlbiwgb3Igd2h5IHRoaXMgcmVzdHJpY3Rpb24gaXMgbWFkZS48YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSSBhZ3JlZSBpdCBzaG91bGQgbm90IGJlIHNlbnQgdG8gYW4gU0YsIGJ1dCBhbiBTRkYg Y291bGQgbWFwIGFuIFNJPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIHplcm8g aW50byBhIHBhdGggdGVybWluYXRpb24uPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkuZS4sIHRoZSBsYXN0IFNGIGluIGEg cGF0aCBjb3VsZCBkZWNyZW1lbnQgU0kgZnJvbSAxIHRvIDAsIGFuZDxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgU0ZGIGNvdWxkIHRoZW4gdGVybWluYXRlIHRoZSBjaGFpbi48 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpKYW1lcyBOPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEd1aWNoYXJkPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpTZW50 OiogVGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAyMDE3IDEyOjAyIFBNPGJyPiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICpUbzoqIEZhYnJpY2lvIEZlcnJhejsgRG9sZ2Fub3csIEFuZHJldyAo Tm9raWEgLSBTRyk7IERhdmUgRG9sc29uOzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBFcmljIEMgUm9zZW47IHNmY0BpZXRmLm9yZyAmbHQ7bWFpbHRvOnNmY0BpZXRmLm9yZyZndDs8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlN1YmplY3Q6KiBSZTogW3NmY10gTlNI IFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vdCBleGFjdGx5LiBT ZWN0aW9uIDMuMyBzcGVjaWZpZXMgIlRoZSB2YWx1ZSB6ZXJvIGZvciBTSSBpcyBub3Q8YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmFsaWQgYW5kIGluZGljYXRlcyBhIGJyb2tlbiBT RkMgb3IgbWFsZnVuY3Rpb25pbmcgU0YiIC4uIEluIG90aGVyPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHdvcmRzIGFuIFNGIHNob3VsZCBuZXZlciByZWNlaXZlIGFuIE5TSCBwYWNr ZXQgd2l0aCBTSSA9IDAuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vdGUgdGhh dCBpZiB0aGlzIGhhcHBlbmVkIHRoZW4gZWl0aGVyIGEpIGEgY2xhc3NpZmllciBzZXQgdGhlIFNJ PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluY29ycmVjdGx5LCBvciBiKSBhIHJl LWNsYXNzaWZpZXIgc2V0IHRoZSBTSSBpbmNvcnJlY3RseSwgb3IgYyk8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYW4gdXBzdHJlYW0gU0Ygc2V0IHRoZSBTSSBpbmNvcnJlY3RseTsg YWxsIG9mIHRoZXNlIGNhc2VzIHNob3VsZDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBiZSBjYXVnaHQgYnkgdGhlIFNGRiB3aG9zZSBqb2IgaXQgaXMgdG8gZGlzY2FyZCBOU0ggcGFj a2V0cyB3aXRoIFNJID08YnI+MC48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSmltPGJyPiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICpGcm9tOipGYWJyaWNpbyBGZXJyYXogW21haWx0bzpmYWJyaWNpby1mZXJyYXpAdGVsZWNv bS5wdF08YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlNlbnQ6KiBUaHVyc2RheSwg RmVicnVhcnkgMDksIDIwMTcgMTE6NDkgQU08YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgKlRvOiogSmFtZXMgTiBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29t PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDttYWlsdG86amFtZXMubi5ndWlj aGFyZEBodWF3ZWkuY29tJmd0OyZndDs7IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC08YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU0cpICZsdDthbmRyZXcuZG9sZ2Fub3dAbm9raWEu Y29tPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDttYWlsdG86YW5kcmV3LmRv bGdhbm93QG5va2lhLmNvbSZndDsmZ3Q7Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRGF2ZTxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEb2xzb24gJmx0O2Rkb2xzb25Ac2FuZHZp bmUuY29tICZsdDttYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20mZ3Q7Jmd0OzsgRXJpYzxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDIFJvc2VuICZsdDtlcm9zZW5AanVuaXBlci5u ZXQgJmx0O21haWx0bzplcm9zZW5AanVuaXBlci5uZXQmZ3Q7Jmd0Ozs8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgc2ZjQGlldGYub3JnICZsdDttYWlsdG86c2ZjQGlldGYub3JnJmd0 Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqU3ViamVjdDoqIFJFOiBbc2ZjXSBO U0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgSmltLDxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBUaGFua3MuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uZSBtb3JlIHF1ZXN0aW9uIGFib3V0IHRo ZSBTSS48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VjdGlvbiAzIHN0YXRlcyB0aGF0Ojxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTZXJ2aWNlIEluZGV4IChTSSk6IHByb3ZpZGVzIGxvY2F0aW9uIHdpdGhpbiB0aGUg U0ZQLiBUaGUgaW5pdGlhbDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGFzc2lm aWVyIE1VU1Qgc2V0IHRoZSBhcHByb3ByaWF0ZSBTSSB2YWx1ZSBmb3IgYSBnaXZlbjxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGFzc2lmaWNhdGlvbiByZXN1bHQuIFRoZSBpbml0 aWFsIFNJIHZhbHVlIFNIT1VMRCBkZWZhdWx0IHRvIDI1NS48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSG93ZXZlciwgdGhlIGNsYXNzaWZpZXIgTVVTVCBhbGxvdyBjb25maWd1cmF0 aW9uIG9mIG90aGVyIFNJIHZhbHVlcy48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VydmljZSBJbmRleCBNVVNUIGJlIGRl Y3JlbWVudGVkIGJ5IFNlcnZpY2UgRnVuY3Rpb25zIG9yIGJ5IFNGQzxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBQcm94eSBub2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVkIHNl cnZpY2VzIGFuZCB0aGUgbmV3PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRlY3Jl bWVudGVkIFNJIHZhbHVlIE1VU1QgYmUgdXNlZCBpbiB0aGUgZWdyZXNzIE5TSCBwYWNrZXQuPGJy PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRoZSBpbml0aWFsIENsYXNzaWZpZXIgTVVTVCBzZW5kIHRoZSBwYWNrZXQgdG8gdGhl IGZpcnN0IFNGRiBpbjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgaWRlbnRp ZmllZCBTRlAgZm9yIGZvcndhcmRpbmcgYWxvbmcgYW4gU0ZQLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiByZS1jbGFz c2lmaWNhdGlvbiBvY2N1cnMsIGFuZCB0aGF0IHJlLWNsYXNzaWZpY2F0aW9uIHJlc3VsdHMgaW48 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYSBuZXcgU1BJLCB0aGUgKHJlKWNsYXNz aWZpZXIgaXMsIGluIGVmZmVjdCwgdGhlIGluaXRpYWw8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgY2xhc3NpZmllciBmb3IgdGhlIHJlc3VsdGFudCBTUEkuPGJyPiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRodXM6PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGEpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluaXRp YWwgU0kgdmFsdWUgc2hvdWxkIGJlIDI1NSBidXQgb3RoZXIgdmFsdWVzIGNhbiBiZTxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25maWd1cmVkIGJ5IHRoZSBjbGFzc2lmaWVyLjxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBiKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTRiBkZWNyZW1lbnRzIHRo ZSBTSSB2YWx1ZSBvbiB0aGUgZWdyZXNzIE5TSCBwYWNrZXQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYykmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgcmUtY2xhc3NpZmljYXRpb24gb2NjdXJzIHdp dGggbmV3IFNQSSwgdGhlIHJlLWNsYXNzaWZpZXI8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgaXMgdGhlIGluaXRpYWwgY2xhc3NpZmllciwgc28gYnkmbmJzcDsgYSksIFNJIHNob3Vs ZCBiZSBhZ2FpbiAyNTUgb3I8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3RoZXIg dmFsdWU8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU28gYW55IFNJIHZhbHVlIGNhbiBiZSByZWNlaXZlIGJ5 IGFuIFNGLCBldmVuIDEgb3IgMCBiZWNhdXNlOjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyDDqElmIFNJPTEgYW5kIHRoZXJl IGlzIG5vIHJlLWNsYXNzaWZpY2F0aW9uLCB0aGUgZWdyZXNzIE5TSCB3aWxsPGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhhdmUgU0k9MDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyDDqElmIFNJPTAgYW5kIHRo ZXJlIGlzIHJlLWNsYXNzaWZpY2F0aW9uIHdpdGggbmV3IFNQSSwgdGhlIGVncmVzczxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOU0ggd2lsbCBoYXZlIGEgbmV3IFNQSSBhbmQgYSBT ST0gMjU1IG9yIG90aGVyIHZhbHVlLCBhcyBzdGF0ZWQgaW4gYSkuPGJyPiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IMOoSWYgU0k9 MCBhbmQgdGhlcmUgaXMgbm8gcmUtY2xhc3NpZmljYXRpb24gdGhlIFNGIHNob3VsZCBkaXNjYXJk PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBwYWNrZXQ8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgQWxzbyBhbiBTRkYgc2hvdWxkIGZvcndhcmQvaGFuZGxlIHBhY2tldHMgd2l0aCBOU0gg d2l0aCBTST0xIG9yIFNJPTAuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERvIHlvdSBhZ3JlZT88YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpKYW1lcyBOPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEd1aWNoYXJkPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpT ZW50OiogcXVpbnRhLWZlaXJhLCA5IGRlIGZldmVyZWlybyBkZSAyMDE3IDE2OjI1PGJyPiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpUbzoqIEZhYnJpY2lvIEZlcnJhejsgRG9sZ2Fub3cs IEFuZHJldyAoTm9raWEgLSBTRyk7IERhdmUgRG9sc29uOzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBFcmljIEMgUm9zZW47IHNmY0BpZXRmLm9yZyAmbHQ7bWFpbHRvOnNmY0BpZXRm Lm9yZyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlN1YmplY3Q6KiBSZTog W3NmY10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIEZh YnJpY2lvLDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXZWxjb21lITxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZZXMs IHJlbW92YWwgb2YgTlNIIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBhbiBTRkYgb3IgYTxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZS1jbGFzc2lmaWVyIChzZWN0aW9uIDQsIGJ1 bGxldCBwb2ludCAxIGxheXMgdGhpcyBvdXQpLiBXaXRoIHRoZTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBjdXJyZW50IGFyY2hpdGVjdHVyZSB0aGUgU0YgZG9lcyBub3QgY2FyZSB3 aGF0IFNJIHZhbHVlIGl0IGdldHMsPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGl0 IGp1c3QgbmVlZHMgdG8gd29ycnkgYWJvdXQgZGVjcmVtZW50aW5nIGl0LCBhbmQgbGVhdmUgaXQg dXAgdG88YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIFNGRiB0byBldmFsdWF0 ZSB0aGUgU0kgdmFsdWUgYW5kIGFzc29jaWF0ZWQgYWN0aW9uLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBK aW08YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkZyb206KkZhYnJpY2lvIEZlcnJheiBbbWFpbHRvOmZhYnJp Y2lvLWZlcnJhekB0ZWxlY29tLnB0XTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAq U2VudDoqIFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyA3OjEzIEFNPGJyPiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpUbzoqIERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpICZs dDthbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZsdDttYWlsdG86YW5kcmV3LmRvbGdhbm93QG5va2lhLmNvbSZndDsmZ3Q7OyBEYXZlIERv bHNvbjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmx0O2Rkb2xzb25Ac2FuZHZpbmUuY29tPGJy PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDttYWlsdG86ZGRvbHNvbkBzYW5kdmlu ZS5jb20mZ3Q7Jmd0OzsgRXJpYyBDIFJvc2VuICZsdDtlcm9zZW5AanVuaXBlci5uZXQ8YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O21haWx0bzplcm9zZW5AanVuaXBlci5uZXQm Z3Q7Jmd0OzsgSmFtZXMgTiBHdWljaGFyZDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAmbHQ7amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tPGJyPiZndDsgJmd0OyZndDsmZ3Q7ICZs dDttYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tJmd0OyZndDs7PGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNmY0BpZXRmLm9yZyAmbHQ7bWFpbHRvOnNmY0BpZXRmLm9y ZyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlN1YmplY3Q6KiBSRTogW3Nm Y10gTlNIIFNlcnZpY2UgSW5kZXggRGVjcmVtZW50PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIGFsbCw8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSSdtIG5ldyBoZXJlIChqdXN0IHJlYWQgdGhlIGRyYWZ0IGxhc3Qgd2VlaykgYnV0 IGFjY29yZGluZyB0bzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFwdGVyPGJy PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDQgKGNoZWNrIGZpZ3VyZSA4IGZvciBleGFt cGxlKSwgYW4gU0YgaXMgbm90IGFsbG93ZWQgdG8gaW5zZXJ0IG9yPGJyPiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHJlbW92ZSBOU0guIFRoZSByZW1vdmFsIG9mIE5TSCBpcyByZXBvbnNh YmlsaXR5IG9mIHRoZSBTU0YsIHJpZ2h0Pzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBG aWd1cmUgOCBtYXBzIGVhY2ggb2YgdGhlIGZvdXIgYWN0aW9ucyBhYm92ZSB0byB0aGUgY29tcG9u ZW50czxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiB0aGU8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgU0ZDIGFyY2hpdGVjdHVyZSB0aGF0IGNhbiBwZXJmb3JtIGl0Ljxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgSW5zZXJ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxTZWxlY3QgfCZuYnNwOyZuYnNwOyBVcGRhdGUmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfFNlcnZpY2UmbmJzcDsgfDxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgb3IgcmVtb3ZlIE5TSCZu YnNwOyB8U2VydmljZXwmbmJzcDsmbmJzcDsmbmJzcDsgTlNIJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxwb2xpY3kmbmJzcDsmbmJzcDsgfDxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfEZ1bmN0aW9ufCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8c2VsZWN0aW9ufDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB8IENvbXBvbmVudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyArLS0tLS0tLS0rLS0tLS0tLS0rUGF0aCZuYnNwOyZuYnNwOyArLS0tLS0tLS0tLS0t LS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwg RGVjLiZuYnNwOyZuYnNwOyB8VXBkYXRlIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwgSW5zZXJ0IHwgUmVtb3ZlIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfFNlcnZpY2UgfENvbnRleHR8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHw8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IEluZGV4Jm5ic3A7IHxIZWFkZXIgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICstLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0r PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyArJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgKyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB8 Q2xhc3NpZmllciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICstLS0tLS0tLS0tLS0tLS08YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgKystLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0rLS0tLS0tLS0tKzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB8U2VydmljZSBGdW5jdGlvbnwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsgKyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PGJy PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHxGb3J3YXJkZXIoU0ZGKSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICstLS0tLS0tLS0tLS0tLS08YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgKystLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0t LS0tKzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB8U2VydmljZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgKyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHxGdW5jdGlvbiZuYnNwOyAoU0YpJm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKy0tLS0tLS0tLS0tLS0tLTxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyArKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0r LS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0rPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHxTRkMgUHJveHkmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyArJm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsgKyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgKyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyArLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tKzxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBGaWd1cmUgODogTlNIIEFjdGlvbiBhbmQgUm9sZSBNYXBwaW5nPGJyPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFuIFNGIGNvdWxkIHJlY2VpdmUgYW4gTlNIIHBhY2tldCB3 aXRoIGFuIFNJIG9mIDEsIGFuZCByZWNsYXNzaWZ5PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGl0IHRvIGEgZGlmZmVyZW50IFNQSSBhbmQgU0ksIHJpZ2h0PyBTbyB3aGVuIGEgU0Yg cmVjZWl2ZXMgYSBOU0g8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFja2V0IHdp dGggU0kgPSAxIHRoYXQgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbnMgYSBub24gdmFsaWQgcGFj a2V0Ljxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBBbmQgdGhhdCBjYW4gZXZlbiB3b3JrIGZvciBTST0wLCBzaW5jZSB5b3Ug ZGVjcmVtZW50IHRoZSBTSSBpbiB0aGU8YnI+Jmd0OyAmZ3Q7Jmd0OyBlZ3Jlc3MuPGJyPiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEZhYnJpY2lvPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpGcm9tOipzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqRG9sZ2Fub3csPGJy PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFuZHJldyAoTm9raWEgLSBTRyk8YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlNlbnQ6KiBxdWludGEtZmVpcmEsIDkgZGUgZmV2 ZXJlaXJvIGRlIDIwMTcgMDE6NTE8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlRv OiogRGF2ZSBEb2xzb247IEVyaWMgQyBSb3NlbjsgSmFtZXMgTiBHdWljaGFyZDsgc2ZjQGlldGYu b3JnPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDttYWlsdG86c2ZjQGlldGYu b3JnJmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqU3ViamVjdDoqIFJlOiBb c2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBhc3N1 bWVkIHRoYXQgaWYgd2UgZ2V0IHZhbHVlIDEgd2UgcHJvY2VzcyB0aGVuIGZvcndhcmQgd2l0aG91 dDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOU0ggaGVhZGVyIChpLmUuKSB0aGlz IGlzIHRoZSBsYXN0IFNGIHByb2Nlc3NpbmcuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNvIHdpdGggdGhh dCBhc3N1bXB0aW9uLCBhIG1vcmUgZXhwbGljaXQgdGV4dCB3b3VsZCBiZTo8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgQW4gU0Ygb3IgU0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBh Y2tldCBNVVNUPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRlY3JlbWVudCB0aGUg U0kgYnkgMSBhZnRlciBwZXJmb3JtaW5nIGFsbCByZXF1aXJlZCBsb2NhbDxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm9jZXNzaW5nIGFuZCBiZWZvcmUgZm9yd2FyZGluZyB0aGUg cGFja2V0IHRvIHRoZSBuZXh0IFNGRi4gSWY8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdGhlIHJlc3VsdGluZyBTSSBpcyAwLCB0aGUgU0YgTVVTVCByZW1vdmUgdGhlIE5TSCBoZWFk ZXIgYmVmb3JlPGJyPiZndDsgZm9yd2FyZGluZyB0aGUgcGFja2V0Ljxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBBbmRyZXc8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgKkZyb206ICpzZmMgJmx0O3NmYy1ib3VuY2VzQGlldGYub3JnICZs dDttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBvbiBiZWhhbGYgb2YgRGF2ZSBEb2xzb24gJmx0O2Rkb2xzb25Ac2FuZHZp bmUuY29tPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOmRkb2xzb25Ac2FuZHZp bmUuY29tJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkRhdGU6ICpU aHVyc2RheSwgRmVicnVhcnkgOSwgMjAxNyBhdCAyOjA0IEFNPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICpUbzogKkVyaWMgUm9zZW4gJmx0O2Vyb3NlbkBqdW5pcGVyLm5ldDxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5l dCZndDsmZ3Q7LCBKYW1lcyBOIEd1aWNoYXJkPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZsdDtqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb208YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgJmx0O21haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb20mZ3Q7Jmd0 OywgInNmY0BpZXRmLm9yZzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7bWFp bHRvOnNmY0BpZXRmLm9yZyZndDsiICZsdDtzZmNAaWV0Zi5vcmcgJmx0O21haWx0bzpzZmNAaWV0 Zi5vcmcmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqU3ViamVjdDog KlJlOiBbc2ZjXSBOU0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg RXJpYyw8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSSB3YXMgbmV2ZXIgcXVpdGUgaGFwcHkgd2l0aCB0aGUgb3V0Y29tZSB0 aGF0IG5laXRoZXIgMCBub3IgMSBpczxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh IHZhbGlkIFNJLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoQmVjYXVzZSBpZiByZWNlaXZlZCB3aXRoIHZhbHVlIG9mIDEs IGl0IGlzIGRlY3JlbWVudGVkIGFuZDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBk aXNjYXJkZWQuKTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBzZWVtcyB0byB3YXN0ZSBhbiBpbmRleCB2 YWx1ZS48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBndWVzcyBJJ20gaW50ZXJlc3RlZCB0byBrbm93IGlm IHRoYXQgaXMgaW1wb3J0YW50IHRvIG90aGVyPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGltcGxlbWVudGVycywgb3IgaWYgdGhhdCB3YXMgZXZlbiB0aGUgaW50ZW50aW9uPzxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtRGF2ZTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhh bGYgT2YgKkVyaWMgQzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSb3Nlbjxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqU2VudDoqIFdlZG5lc2RheSwgRmVicnVhcnkg MDgsIDIwMTcgMTE6NTMgQU08YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlRvOiog SmFtZXMgTiBHdWljaGFyZDsgc2ZjQGlldGYub3JnICZsdDttYWlsdG86c2ZjQGlldGYub3JnJmd0 Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqU3ViamVjdDoqIFJlOiBbc2ZjXSBO U0ggU2VydmljZSBJbmRleCBEZWNyZW1lbnQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gMi83LzIwMTcg MjoyNCBQTSwgSmFtZXMgTiBHdWljaGFyZCB3cm90ZTo8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQSByZXF1ZXN0IHdhcyBt YWRlIHRvIGJlIG1vcmUgc3BlY2lmaWMgYW5kIHVwZGF0ZSB0aGUgdGV4dCBhcyBmb2xsb3dzOjxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAiU2VydmljZSBpbmRleCBNVVNUIGJlIGRlY3JlbWVudGVkICpieSBh IHZhbHVlIG9mIDEqIGJ5IFNlcnZpY2U8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg RnVuY3Rpb25zIG9yIGJ5IFNGQyBQcm94eSBub2RlcyBhZnRlciBwZXJmb3JtaW5nIHJlcXVpcmVk IHNlcnZpY2VzIC4iPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEEg Y291cGxlIG9mIG9ic2VydmF0aW9uczo8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLSBUaGUgdGVybSAiU0ZDIFByb3h5IG5v ZGUiIGlzIG5vdCBkZWZpbmVkIGluIGVpdGhlciB0aGUgTlNIPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGRyYWZ0IG9yIGluIFJGQyA3NjY1LiZuYnNwOyBJIHRoaW5rIHRoZSBpbnRl bnRpb24gaGVyZSBpcyB0byBzYXkgIlNGQzxicj5Qcm94eSIuPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gSXMgdGhlIGlu dGVudGlvbiB0aGF0IHRoZSBTSSByZW1haW4gdW5jaGFuZ2VkIHdoaWxlIHRoZSBTRiBpczxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvcGVyYXRpbmcgb24gdGhlIHBhY2tldCwgb3Ig aXMgdGhlIGludGVudGlvbiBvbmx5IHRoYXQgdGhlIFNJIGJlPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGRlY3JlbWVudGVkIGJlZm9yZSB0aGUgcGFja2V0IGlzIGRlbGl2ZXJlZCBi eSB0aGUgU0Ygb3IgU0ZDIFByb3h5PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRv IGFuIFNGRj88YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSSdkIHN1Z2dlc3QgZWl0aGVyOjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAiQW4gU0Ygb3Ig U0ZDIFByb3h5IHJlY2VpdmluZyBhbiBOU0gtZW5jYXBzdWxhdGVkIHBhY2tldCBNVVNUPGJyPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRlY3JlbWVudCB0aGUgU0kgYnkgMSBiZWZvcmUg ZGVsaXZlcmluZyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNGRiI8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3I8YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgIkFuIFNGIG9yIFNGQyBQcm94eSByZWNlaXZpbmcgYW4gTlNILWVuY2Fwc3VsYXRlZCBwYWNr ZXQgTVVTVDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZWNyZW1lbnQgdGhlIFNJ IGJ5IDEgYmVmb3JlIGRlbGl2ZXJpbmcgdGhlIHBhY2tldCB0byB0aGUgbmV4dDxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTRkYsIGJ1dCBub3QgdW50aWwgdGhlIFNGIGhhcyBmaW5p c2hlZCBhbGwgaXRzIG90aGVyIHByb2Nlc3Npbmcgb2YgdGhlPGJyPiZndDsgcGFja2V0Ijxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBkZXBlbmRpbmcgdXBvbiB3aGljaCBpcyBpbnRlbmRlZC48YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSB0aGluayBh biBpbXBsaWNhdGlvbiBvZiB0aGVzZSBwcm9jZWR1cmVzIGlzIHRoYXQgYW4gU0kgdmFsdWUgb2Y8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMSBpcyBub3QgdmFsaWQuJm5ic3A7IElm IGFuIFNGIGdldHMgYW4gTlNIIHBhY2tldCB3aXRoIGFuIFNJIG9mIDEsIHRoZTxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTRiB3aWxsIGRlY3JlbWVudCB0aGUgU0kgKHNldHRpbmcg aXQgdG8gMCksIHNlbmQgdGhlIHBhY2tldCB0byBhbjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTRkYsIGFuZCB0aGUgU0ZGIHdpbGwgZGlzY2FyZCBpdCwgYmVjYXVzZSAwIGlzIGFu IGludmFsaWQgU0k8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmFsdWUuJm5ic3A7 IElzIHRoYXQgdGhlIGludGVudGlvbj88YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGRyYWZ0IG1ha2VzIGl0IGNsZWFy ICh3ZWxsLCBzb3J0IG9mKSB0aGF0IGFuIFNGRiBzaG91bGQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgZGlzY2FyZCBhIHBhY2tldCB3aXRoIGFuIFNJIG9mIDAsIGJ1dCBkb2VzIG5v dCBzZWVtIHRvIHNheSB0aGF0PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuIFNG IG9yIFNGQyBQcm94eSBzaG91bGQgZGlzY2FyZCBhIHBhY2tldCBpdCByZWNlaXZlcyB3aXRoIGFu IFNJPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIDAuJm5ic3A7IEl0IHdvdWxk IHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRvIHNheSB0aGF0Ljxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTb21lIHRleHQg aW4gdGhlIGRyYWZ0IChlLmcuLCBzZWN0aW9uIDcuMSkgc3RhdGVzIHRoYW4gYW4gU0ZGPGJyPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNob3VsZCBkaXNjYXJkIGEgcGFja2V0IHdpdGgg YW4gU0kgb2YgemVybywgYnV0IG90aGVyIHRleHQgaW4gdGhlPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGRyYWZ0IChlLmcuLCBzZWN0aW9uIDMuMykgb25seSBzYXlzIHRoYXQgYW4g U0ZGIHNob3VsZCBsb2cgYW48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXJyb3Ig aWYgaXQgc2VlcyBhbiBTSSBvZiB6ZXJvLiZuYnNwOyBJdCdzIHByb2JhYmx5IGJlc3QgdG8gY2hh bmdlIHRoZTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0ZXh0IGluIDMuMy4gdG8g c2F5ICJTSE9VTEQgZ2VuZXJhdGUgYW4gZXJyb3IvbG9nIG1lc3NhZ2UgYW5kPGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1VU1QgZGlzY2FyZCB0aGUgcGFja2V0Iiwgb3Igc29tZXRo aW5nIHNpbWlsYXIuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNmYyBtYWlsaW5n IGxpc3Q8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2ZjQGlldGYub3JnICZsdDtt YWlsdG86c2ZjQGlldGYub3JnJmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZmNAaWV0Zi5vcmc8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IHNmY0BpZXRmLm9yZzxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyBzZmNAaWV0Zi5vcmc8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4m Z3Q7ICZndDs8YnI+PGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_2009828933707010-- From nobody Sat Feb 11 16:58:08 2017 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 DBA531294BB for ; Sat, 11 Feb 2017 16:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtCKwMF96jbV for ; Sat, 11 Feb 2017 16:58:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A793512949E for ; Sat, 11 Feb 2017 16:58:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGG43364; Sun, 12 Feb 2017 00:57:58 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 12 Feb 2017 00:57:57 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Sat, 11 Feb 2017 16:57:48 -0800 From: James N Guichard To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "'Ron Parker'" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkAAeZjIw//6oW4D//33gw4AAqsEAgAASngCAASFmAIAAiOAAgAEwB4CAAIMaAP//jNyAgAB+Z8D//4u0gAAJXKMAAAy7vQA= Date: Sun, 12 Feb 2017 00:57:48 +0000 Message-ID: References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> <0da701d284b7$2d115d40$873417c0$@olddog.co.uk> In-Reply-To: <0da701d284b7$2d115d40$873417c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.254] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.589FB316.0074, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a70407c9a835e72958c2c0bc1d89c9e Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 00:58:07 -0000 Hi Adrian, Inline (hat off opinion) .. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Saturday, February 11, 2017 5:36 PM To: 'Joel M. Halpern' ; 'Ron Parker' Cc: sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement Joel, The -10 version of NSH says The value zero for SI is not valid and indicates a broken SFC or malfunctioning SF. Jim> the above text is perhaps what is causing some confusion as it implies= an SI of 0 from an SF is invalid. May I suggest the following text as a re= placement for the above sentence: "The value zero for SI indicates a broken SFC. Packets received at an SFF w= ith an SI of zero MUST be discarded and the SFF SHOULD generate an error/lo= g message".=20 You are saying that the latter of these is not true. I can't tell whether the former is really true or, perhaps, represents a di= scard tail of an SFC where some (but not all) packets are reclassified per = Ron. Like I said: > Let's clarify that it is OK for an SF to send a packet with SI=3D0 Then (of course) it is also OK for an SFF to receive SI=3D0, but I think th= e existing "discard" text covers that case. Jim> from an SF yes but not from another SFF. However, in either case, a lo= okup on should cause the SFF to discard the packet. Hopefully= my above suggested text clarifies that. Adrian > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 11 February 2017 18:08 > To: Ron Parker; adrian@olddog.co.uk; 'Dave Dolson' > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;=20 > 'James N Guichard'; 'Fabricio Ferraz' > Subject: Re: [sfc] NSH Service Index Decrement >=20 > I was commenting, in personal hat, about the issue of whether there=20 > was some sort of problem with the impact of the current description on=20 > SI=3D1 packets arriving at an SF. It seems to me that your example=20 > shows that such an effect is sometimes useul. > It will also sometimes produce packet drops by the SFF, when the SF=20 > does not terminate the packet. Okay, so be it. > It is not even clear there is anything, in Adrian's phrase, to paint=20 > red here. >=20 > Yours, > Joel >=20 > On 2/11/17 12:59 PM, Ron Parker wrote: > > Hi, Joel. > > > > Does your comment pertain to my somewhat off topic question which=20 > > was > related to one of Adrian's tangential issues, or to Adrian's original=20 > SF=3D1 topic? > > > > Thanks. > > > > Ron > > > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Saturday, February 11, 2017 12:31 PM > > To: Ron Parker ;=20 > > adrian@olddog.co.uk; > 'Dave Dolson' > > Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - SG)= ' > ; sfc@ietf.org; 'James N Guichard' > ; 'Fabricio Ferraz'=20 > > > Subject: Re: [sfc] NSH Service Index Decrement > > > > Personally, what you describe sounds like a quite reasonable case=20 > > where a > packet arrive at the SF with an SI of 1 will produce exactly the=20 > desired behavior. > > > > Which suggests, to my limited view, that the current text works fine. > > > > Yours, > > Joel > > > > On 2/11/17 11:55 AM, Ron Parker wrote: > >> Hi, Adrian. > >> > >> Not the original topic, per se, but wrt your comment: > >> > >> * On the other hand, we appear to be clear about an SF that strips=20 > >> the NSH > and forwards the traffic as native : this is currently forbidden. > >> > >> I'm wondering how to reconcile this to a transparent HTTP Proxy=20 > >> that does not > preserve the original source-IP? Does this mean that it is mandatory fo= r such an > SF to also be a classifier so it can self-classify its own related=20 > flows (i.e., using its > own visible IP addresses)? From SFF perspective, it would look like al= l packets > on the access side are dropped in the upstream direction and injected=20 > by the SF > in the downstream direction. On the Internet side, it would look like a= ll packets > are injected by the SF in the upstream direction and dropped in the=20 > downstream direction. > >> > >> Thanks for any clarification. > >> > >> Ron > >> > >> > >> > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: Saturday, February 11, 2017 11:34 AM > >> To: 'Dave Dolson' ; 'Joel M. Halpern' > >> ; Ron Parker > >> Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia -=20 > >> SG)' ; sfc@ietf.org; 'James N Guichard' > >> ; 'Fabricio Ferraz' > >> > >> Subject: RE: [sfc] NSH Service Index Decrement > >> > >> I hate to do my impersonation of Eric, but... > >> > >> "On the wire" is the crunch. > >> > >> Some have said that there must be no visible difference between the=20 > >> three > case: > >> - on the wire between SFF and SF > >> - on the wire between SF and SFF > >> - on the wire between SFF and SFF > >> > >> If this holds then you are correct that sending SI=3D1 in the first=20 > >> case requires > the SF to do more than a simple decrement (although decrement and=20 > discard is hardly painful). And it means that SI=3D1 is a dubious value i= n an SFP. > >> > >> On the other hand, we appear to be clear about an SF that strips=20 > >> the NSH and > forwards the traffic as native : this is currently forbidden. So there=20 > is no alternative for an SF receiving SI=3D1 except to discard the packet= . > >> > >> Now, does that mean that an SFF should never send a packet with=20 > >> SI=3D1? Well, > possibly it is OK for a few specialist SFs intended to sit at the end=20 > of the chain and > be a bit bucket with analysis. But, for most SFs there would be no point. > >> > >> Maybe (just maybe) we should stop letting the tail wag the dog!=20 > >> That is, let's > decide on the functional behavior we want to see and then design the=20 > protocol to match. > >> > >> Adrian > >> > >>> -----Original Message----- > >>> From: Dave Dolson [mailto:ddolson@sandvine.com] > >>> Sent: 10 February 2017 22:26 > >>> To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;=20 > >>> 'James N Guichard'; 'Fabricio Ferraz' > >>> Subject: RE: [sfc] NSH Service Index Decrement > >>> > >>> Adrian, > >>> I think I agree with everything you said. > >>> But you did not suggest whether or not you think that SI=3D0 should=20 > >>> be valid on > >> the > >>> wire. > >>> I'm saying it could work, if the next hop is a path terminus. > >>> > >>> If I understand Joel correctly, he says we shouldn't send SI=3D0 in= =20 > >>> case the > >> next > >>> hop blindly decrements it. > >>> --> this seems to mean SI=3D1 cannot be used except at the terminus=20 > >>> --> or when the > >>> SF is expected to drop all packets. > >>> So I think this is an unnecessary seat belt, trying to anticipate=20 > >>> bugs in > >> down- > >>> stream devices. > >>> > >>> I realize the current language has been there a long time, and if=20 > >>> it is > >> important to > >>> anyone then it should remain. > >>> Nonetheless, I think devices could safely handle SI=3D0 on the wire=20 > >>> without breaking anything. > >>> > >>> But I'm not pushing for a change, since the current behavior seems=20 > >>> important > >> to > >>> some. > >>> > >>> -Dave > >>> > >>> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > >>> Sent: Friday, February 10, 2017 9:16 AM > >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;=20 > >>> 'James N Guichard'; 'Fabricio Ferraz' > >>> Subject: Re: [sfc] NSH Service Index Decrement > >>> > >>> Oh, you finally pushed me into this discussion, Dave. > >>> > >>> We're building a protocol. with a protocol, you cannot (must not)=20 > >>> assume good behavior from your neighbor. > >>> > >>> So if the SF touches the SI (which it does) we must define the=20 > >>> edge > >> conditions. > >>> If it is the SF's job to decrement the SI, then we must also=20 > >>> define what it > >> does > >>> when SI=3D0 (otherwise, it will set SI to 0-1). > >>> If the SF is not allowed to decrement the SI below zero (which=20 > >>> makes > >>> sense) we must define what it must do. > >>> Since SFs are allowed to drop packets (indeed that is one of their=20 > >>> main jobs > >> ;-) > >>> then this would be fine. > >>> All that would be left is to define whether they apply the test=20 > >>> before or > >> after > >>> normal processing. > >>> > >>> As an aside, I agree with Don that TTL helps relax this a little,=20 > >>> but does not get us all the way there. > >>> > >>> Cheers, > >>> Adrian > >>> > >>>> -----Original Message----- > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > >>>> Sent: 09 February 2017 21:00 > >>>> To: Joel M. Halpern; Ron Parker > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C=20 > >>>> Rosen; Dolganow, Andrew (Nokia - SG) > >>>> Subject: Re: [sfc] NSH Service Index Decrement > >>>> > >>>> Discussing misconfigured SFFs is a straw-man argument. Once one=20 > >>>> starts > >> trying > >>> to > >>>> anticipate down-stream devices being misconfigured, one can=20 > >>>> invent a lot of > >>> silly > >>>> requirements. > >>>> > >>>> >From an aesthetic point of view, I think it's bad that there are > >>>>> two SI > >>> values (0 > >>>> and 1) that cannot be used. > >>>> > >>>> The real requirement, IMO, is that no device decrements 0 and=20 > >>>> forwards > NSH. > >>>> Since only SFs decrement SI, only SFs need to do this check. > >>>> > >>>> And any discussion about buggy SFs... well there is a lot of bad=20 > >>>> stuff that > >>> bugs can > >>>> cause. > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>> Sent: Thursday, February 09, 2017 2:54 PM > >>>> To: Ron Parker; Dave Dolson > >>>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG);=20 > >>>> James N > >>> Guichard; > >>>> Fabricio Ferraz > >>>> Subject: Re: [sfc] NSH Service Index Decrement > >>>> > >>>> From my perspective as an individual participant in this work,=20 > >>>> declaring that 0 must be dropped is a matter of robustness. > >>>> > >>>> if we allow 0 to be processed for exit at an SFF, then a=20 > >>>> mis-configured SFF could easily continue processing such a packet. > >>>> Now, it is true that TTL will eventually drop it, but that is an expensive > fallback. > >>>> > >>>> More importantly, presumably the next entitiy down the incorrect=20 > >>>> path would drop it for a 255 SI. But at that point we are=20 > >>>> getting the error in the wrong place, making it harder to diagnose a= nd repair. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 2/9/17 12:42 PM, Ron Parker wrote: > >>>>> agree. > >>>>> > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson >>>>> > wrote: > >>>>> > >>>>>> I'm not clear on why this is broken, or why this restriction is ma= de. > >>>>>> > >>>>>> I agree it should not be sent to an SF, but an SFF could map an=20 > >>>>>> SI of zero into a path termination. > >>>>>> > >>>>>> I.e., the last SF in a path could decrement SI from 1 to 0, and=20 > >>>>>> the SFF could then terminate the chain. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N=20 > >>>>>> Guichard > >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave=20 > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Not exactly. Section 3.3 specifies "The value zero for SI is=20 > >>>>>> not valid and indicates a broken SFC or malfunctioning SF" ..=20 > >>>>>> In other words an SF should never receive an NSH packet with SI = =3D 0. > >>>>>> Note that if this happened then either a) a classifier set the=20 > >>>>>> SI incorrectly, or b) a re-classifier set the SI incorrectly,=20 > >>>>>> or c) an upstream SF set the SI incorrectly; all of these cases=20 > >>>>>> should be caught by the SFF whose job it is to discard NSH=20 > >>>>>> packets with SI =3D 0. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Jim > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM > >>>>>> *To:* James N Guichard >>>>>> >; Dolganow, Andrew (Nokia=20 > >>>>>> - > >>>>>> SG) >>>>>> >; > >>>> Dave > >>>>>> Dolson >;=20 > >>>>>> Eric C Rosen >;=20 > >>>>>> sfc@ietf.org > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi Jim, > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> > >>>>>> > >>>>>> One more question about the SI. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Section 3 states that: > >>>>>> > >>>>>> > >>>>>> > >>>>>> Service Index (SI): provides location within the SFP. The=20 > >>>>>> initial classifier MUST set the appropriate SI value for a=20 > >>>>>> given classification result. The initial SI value SHOULD default t= o 255. > >>>>>> However, the classifier MUST allow configuration of other SI value= s. > >>>>>> > >>>>>> Service Index MUST be decremented by Service Functions or by=20 > >>>>>> SFC Proxy nodes after performing required services and the new=20 > >>>>>> decremented SI value MUST be used in the egress NSH packet. > >>>>>> > >>>>>> The initial Classifier MUST send the packet to the first SFF in=20 > >>>>>> the identified SFP for forwarding along an SFP. > >>>>>> > >>>>>> If re-classification occurs, and that re-classification results=20 > >>>>>> in a new SPI, the (re)classifier is, in effect, the initial=20 > >>>>>> classifier for the resultant SPI. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thus: > >>>>>> > >>>>>> a) Initial SI value should be 255 but other values can be > >>>>>> configured by the classifier. > >>>>>> > >>>>>> b) SF decrements the SI value on the egress NSH packet > >>>>>> > >>>>>> c) If re-classification occurs with new SPI, the re-classifi= er > >>>>>> is the initial classifier, so by a), SI should be again 255 or=20 > >>>>>> other value > >>>>>> > >>>>>> > >>>>>> > >>>>>> So any SI value can be receive by an SF, even 1 or 0 because: > >>>>>> > >>>>>> =E8If SI=3D1 and there is no re-classification, the egress NSH wil= l=20 > >>>>>> have SI=3D0 > >>>>>> > >>>>>> =E8If SI=3D0 and there is re-classification with new SPI, the=20 > >>>>>> egress NSH will have a new SPI and a SI=3D 255 or other value, as = stated in a). > >>>>>> > >>>>>> =E8If SI=3D0 and there is no re-classification the SF should=20 > >>>>>> discard the packet > >>>>>> > >>>>>> > >>>>>> > >>>>>> Also an SFF should forward/handle packets with NSH with SI=3D1 or = SI=3D0. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Do you agree? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N=20 > >>>>>> Guichard > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave=20 > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi Fabricio, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Welcome! > >>>>>> > >>>>>> > >>>>>> > >>>>>> Yes, removal of NSH is the responsibility of an SFF or a=20 > >>>>>> re-classifier (section 4, bullet point 1 lays this out). With=20 > >>>>>> the current architecture the SF does not care what SI value it=20 > >>>>>> gets, it just needs to worry about decrementing it, and leave=20 > >>>>>> it up to the SFF to evaluate the SI value and associated action. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Jim > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > >>>>>> *Sent:* Thursday, February 09, 2017 7:13 AM > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) >>>>>> >; Dave Dolson > >>>> >>>>>> >; Eric C Rosen=20 > >>>>>> >; James N=20 > >>>>>> Guichard >>> >; > >>>>>> sfc@ietf.org > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I'm new here (just read the draft last week) but according to=20 > >>>>>> chapter > >>>>>> 4 (check figure 8 for example), an SF is not allowed to insert=20 > >>>>>> or remove NSH. The removal of NSH is reponsability of the SSF, rig= ht? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Figure 8 maps each of the four actions above to the=20 > >>>>>> components in the > >>>>>> > >>>>>> SFC architecture that can perform it. > >>>>>> > >>>>>> > >>>>>> > >>>>>> +---------------+------------------+-------+----------------+-----= ----+ > >>>>>> > >>>>>> | | Insert |Select | Update |Servi= ce | > >>>>>> > >>>>>> | | or remove NSH |Service| NSH |polic= y | > >>>>>> > >>>>>> | | |Function| |selec= tion| > >>>>>> > >>>>>> | Component +--------+--------+Path +----------------+ = | > >>>>>> > >>>>>> | | | | | Dec. |Update | = | > >>>>>> > >>>>>> | | Insert | Remove | |Service |Context| = | > >>>>>> > >>>>>> | | | | | Index |Header | = | > >>>>>> > >>>>>> +----------------+--------+--------+-------+--------+-------+-----= ----+ > >>>>>> > >>>>>> | | + | + | | | + | = | > >>>>>> > >>>>>> |Classifier | | | | | | = | > >>>>>> > >>>>>> +--------------- > >>>>>> ++--------+--------+-------+--------+-------+---------+ > >>>>>> > >>>>>> |Service Function| | + | + | | | = | > >>>>>> > >>>>>> |Forwarder(SFF) | | | | | | = | > >>>>>> > >>>>>> +--------------- > >>>>>> ++--------+--------+-------+--------+-------+---------+ > >>>>>> > >>>>>> |Service | | | | + | + | + = | > >>>>>> > >>>>>> |Function (SF) | | | | | | = | > >>>>>> > >>>>>> +--------------- > >>>>>> ++--------+--------+-------+--------+-------+---------+ > >>>>>> > >>>>>> |SFC Proxy | + | + | | + | | = | > >>>>>> > >>>>>> +----------------+--------+--------+-------+--------+-------+-----= ----+ > >>>>>> > >>>>>> > >>>>>> > >>>>>> Figure 8: NSH Action and Role Mapping > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> An SF could receive an NSH packet with an SI of 1, and=20 > >>>>>> reclassify it to a different SPI and SI, right? So when a SF=20 > >>>>>> receives a NSH packet with SI =3D 1 that does not necessarily mean= s a non valid packet. > >>>>>> > >>>>>> And that can even work for SI=3D0, since you decrement the SI in=20 > >>>>>> the > >> egress. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Fabricio > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of=20 > >>>>>> *Dolganow, Andrew (Nokia - SG) > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org=20 > >>>>>> > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> I assumed that if we get value 1 we process then forward=20 > >>>>>> without NSH header (i.e.) this is the last SF processing. > >>>>>> > >>>>>> > >>>>>> > >>>>>> So with that assumption, a more explicit text would be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST=20 > >>>>>> decrement the SI by 1 after performing all required local=20 > >>>>>> processing and before forwarding the packet to the next SFF. If=20 > >>>>>> the resulting SI is 0, the SF MUST remove the NSH header before > forwarding the packet. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Andrew > >>>>>> > >>>>>> *From: *sfc >>>>>> > on behalf of Dave Dolson=20 > >>>>>> >>>> > > >>>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM > >>>>>> *To: *Eric Rosen >>>>>> >, James N Guichard=20 > >>>>>> >>>>>> >, "sfc@ietf.org=20 > >>>>>> " > > >>>>>> *Subject: *Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> Eric, > >>>>>> > >>>>>> I was never quite happy with the outcome that neither 0 nor 1=20 > >>>>>> is a valid SI. > >>>>>> > >>>>>> (Because if received with value of 1, it is decremented and > >>>>>> discarded.) > >>>>>> > >>>>>> > >>>>>> > >>>>>> It seems to waste an index value. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I guess I'm interested to know if that is important to other=20 > >>>>>> implementers, or if that was even the intention? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -Dave > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C=20 > >>>>>> Rosen > >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM > >>>>>> *To:* James N Guichard; sfc@ietf.org > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: > >>>>>> > >>>>>> A request was made to be more specific and update the text as foll= ows: > >>>>>> > >>>>>> > >>>>>> > >>>>>> "Service index MUST be decremented *by a value of 1* by Service=20 > >>>>>> Functions or by SFC Proxy nodes after performing required services= ." > >>>>>> > >>>>>> > >>>>>> A couple of observations: > >>>>>> > >>>>>> - The term "SFC Proxy node" is not defined in either the NSH=20 > >>>>>> draft or in RFC 7665. I think the intention here is to say=20 > >>>>>> "SFC Proxy". > >>>>>> > >>>>>> - Is the intention that the SI remain unchanged while the SF is=20 > >>>>>> operating on the packet, or is the intention only that the SI=20 > >>>>>> be decremented before the packet is delivered by the SF or SFC=20 > >>>>>> Proxy to an SFF? > >>>>>> > >>>>>> I'd suggest either: > >>>>>> > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST=20 > >>>>>> decrement the SI by 1 before delivering the packet to the next SFF= " > >>>>>> > >>>>>> or > >>>>>> > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST=20 > >>>>>> decrement the SI by 1 before delivering the packet to the next=20 > >>>>>> SFF, but not until the SF has finished all its other processing=20 > >>>>>> of the > packet" > >>>>>> > >>>>>> depending upon which is intended. > >>>>>> > >>>>>> I think an implication of these procedures is that an SI value=20 > >>>>>> of > >>>>>> 1 is not valid. If an SF gets an NSH packet with an SI of 1,=20 > >>>>>> the SF will decrement the SI (setting it to 0), send the packet=20 > >>>>>> to an SFF, and the SFF will discard it, because 0 is an invalid=20 > >>>>>> SI value. Is that the intention? > >>>>>> > >>>>>> The draft makes it clear (well, sort of) that an SFF should=20 > >>>>>> discard a packet with an SI of 0, but does not seem to say that=20 > >>>>>> an SF or SFC Proxy should discard a packet it receives with an=20 > >>>>>> SI of 0. It would probably be a good idea to say that. > >>>>>> > >>>>>> Some text in the draft (e.g., section 7.1) states than an SFF=20 > >>>>>> should discard a packet with an SI of zero, but other text in=20 > >>>>>> the draft (e.g., section 3.3) only says that an SFF should log=20 > >>>>>> an error if it sees an SI of zero. It's probably best to=20 > >>>>>> change the text in 3.3. to say "SHOULD generate an error/log=20 > >>>>>> message and MUST discard the packet", or something similar. > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sfc mailing list > >>>>>> sfc@ietf.org =20 > >>>>>> 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 > >>> > >>> _______________________________________________ > >>> 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 Sun Feb 12 02:36:40 2017 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 7B70912948F for ; Sun, 12 Feb 2017 02:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 bC4fcaTibGVB for ; Sun, 12 Feb 2017 02:36:36 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77ABB129443 for ; Sun, 12 Feb 2017 02:36:35 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1CAaHZ5032367; Sun, 12 Feb 2017 10:36:17 GMT Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1CAaCFO032290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Feb 2017 10:36:15 GMT From: "Adrian Farrel" To: "'James N Guichard'" , "'Joel M. Halpern'" , "'Ron Parker'" References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> <0! da701d284b7$2d115d40$87 3417c0$@olddog.co.uk> In-Reply-To: Date: Sun, 12 Feb 2017 10:36:12 -0000 Message-ID: <0e0f01d2851b$d7323a10$8596ae30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHoYgY6PCVGpHJ8su3f5ejQO2dmKAM4JSWQAhYkhCMBHU+anQCFM5gDAmn9f8kBgE4xngJdM3REAj8zzvsB6Deh7wJQKkgbAo860icBexanZwFah2BmATjK/hYB/8mdwgItzVVdoEWZOCA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22880.006 X-TM-AS-Result: No--38.101-10.0-31-10 X-imss-scan-details: No--38.101-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wpmug812qIbzfkSt9GqmKVUs563fttA5Zhlb y9sTjxSinxPhm0dckhu/hY9PCOg+obFRE99Bhzw4Li5PDX0qWHo7pfSjRsD2Olvo8FSqar5SM2K CK/Wo3MMva3SVPKtvaclFFm7HZKbLwHoskkCsaklT46Ow+EhYOBtQeEi5kyeD0mAM2eipqlq8vg G4C4GxKU1i8No7236clMs9KzTYan751WNA1rE6t+J28KqpjndpTJDl9FKHbrndeAKnvBMxfNKmy J56Qa3ElI28/54JRT+ZTV/onKAmUAffi0zcbiljYR6QE8KYfsg00EW1UQZMfVOmuHC2zOGYegUm qfuWBCqrlNyrS95ralT7pLySGeP0MrjYlVK+7cBsG7r4Qh7N3JE+3DCX3uibgrAXgr/AjP1SImM 8cgendrGP5wb+1U2+ktsmv++ScuJL6TLH/glcpR47EGkpGeA9Vo4lwLFUdit/sUNganJerd9eg0 lscz7xgaqPpygdrwxe1AewcHbx90t93A/7wtYbOs0KXIfHD52usS9CiBzL8TDJ9a3KikGo4poPe F9HoP4dpZqJz3UQMeGdQvpfo18XiwgTsTW4icYc9jA4mLo8uYLsLasl5ROh550rfo9dgpbqYfM0 tIgPqQA5PAWD5aIUF+K/pZ5jfCpIGJIfj527f2/+RwWenb0YZAQzy8TR+QYWedCrEHXal02pDx/ jTtOx2HgtE/Gh7Qq7n8FYMjJ/f8H5qr3g6PrztLDu9qtqKeEFwIQBmQewZ2JkJOQVCIpw0tDG1n xaYACRKof4pz0GQq1WQT2WyBRJjuYAcQC2gcCeAiCmPx4NwGNn8XPiALIbooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 10:36:39 -0000 Thanks Jim, Your text works for me although I would prefer to delete the commentary = about a "broken SFC" as a specific example of how this might happen that is not = the only case (for example, a broken reclassifier can also cause this). So, can we settle on "Packets received at an SFF with an SI of zero MUST be discarded and the = SFF SHOULD generate an error/log message." BTW, I said >> Then (of course) it is also OK for an SFF to receive SI=3D0, but I = think the existing >> "discard" text covers that case. and you replied > from an SF yes but not from another SFF. and that (of course) has been a point of entertainment for some while. Since an SFF cannot tell the difference between a packet received from = an SFF and one from an SF we must document all cases alike. Fortunately, we're able to do so for this instance. A > -----Original Message----- > From: James N Guichard [mailto:james.n.guichard@huawei.com] > Sent: 12 February 2017 00:58 > To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > Cc: sfc@ietf.org > Subject: RE: [sfc] NSH Service Index Decrement >=20 > Hi Adrian, >=20 > Inline (hat off opinion) .. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Saturday, February 11, 2017 5:36 PM > To: 'Joel M. Halpern' ; 'Ron Parker' > > Cc: sfc@ietf.org > Subject: Re: [sfc] NSH Service Index Decrement >=20 > Joel, >=20 > The -10 version of NSH says >=20 > The > value zero for SI is not valid and indicates a broken SFC or > malfunctioning SF. >=20 > Jim> the above text is perhaps what is causing some confusion as it = implies an SI > of 0 from an SF is invalid. May I suggest the following text as a = replacement for > the above sentence: >=20 > "The value zero for SI indicates a broken SFC. Packets received at an = SFF with an > SI of zero MUST be discarded and the SFF SHOULD generate an error/log > message". >=20 > You are saying that the latter of these is not true. > I can't tell whether the former is really true or, perhaps, represents = a discard tail > of an SFC where some (but not all) packets are reclassified per Ron. >=20 > Like I said: >=20 > > Let's clarify that it is OK for an SF to send a packet with SI=3D0 >=20 > Then (of course) it is also OK for an SFF to receive SI=3D0, but I = think the existing > "discard" text covers that case. >=20 > Jim> from an SF yes but not from another SFF. However, in either case, = a lookup > on should cause the SFF to discard the packet. Hopefully = my above > suggested text clarifies that. >=20 > Adrian >=20 > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: 11 February 2017 18:08 > > To: Ron Parker; adrian@olddog.co.uk; 'Dave Dolson' > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; > > 'James N Guichard'; 'Fabricio Ferraz' > > Subject: Re: [sfc] NSH Service Index Decrement > > > > I was commenting, in personal hat, about the issue of whether there > > was some sort of problem with the impact of the current description = on > > SI=3D1 packets arriving at an SF. It seems to me that your example > > shows that such an effect is sometimes useul. > > It will also sometimes produce packet drops by the SFF, when the SF > > does not terminate the packet. Okay, so be it. > > It is not even clear there is anything, in Adrian's phrase, to paint > > red here. > > > > Yours, > > Joel > > > > On 2/11/17 12:59 PM, Ron Parker wrote: > > > Hi, Joel. > > > > > > Does your comment pertain to my somewhat off topic question which > > > was > > related to one of Adrian's tangential issues, or to Adrian's = original > > SF=3D1 > topic? > > > > > > Thanks. > > > > > > Ron > > > > > > > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > > Sent: Saturday, February 11, 2017 12:31 PM > > > To: Ron Parker ; > > > adrian@olddog.co.uk; > > 'Dave Dolson' > > > Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia = - SG)' > > ; sfc@ietf.org; 'James N Guichard' > > ; 'Fabricio Ferraz' > > > > > Subject: Re: [sfc] NSH Service Index Decrement > > > > > > Personally, what you describe sounds like a quite reasonable case > > > where a > > packet arrive at the SF with an SI of 1 will produce exactly the > > desired > behavior. > > > > > > Which suggests, to my limited view, that the current text works = fine. > > > > > > Yours, > > > Joel > > > > > > On 2/11/17 11:55 AM, Ron Parker wrote: > > >> Hi, Adrian. > > >> > > >> Not the original topic, per se, but wrt your comment: > > >> > > >> * On the other hand, we appear to be clear about an SF that = strips > > >> the NSH > > and forwards the traffic as native : this is currently forbidden. > > >> > > >> I'm wondering how to reconcile this to a transparent HTTP Proxy > > >> that does > not > > preserve the original source-IP? Does this mean that it is = mandatory for > such an > > SF to also be a classifier so it can self-classify its own related > > flows > (i.e., using its > > own visible IP addresses)? From SFF perspective, it would look = like all > packets > > on the access side are dropped in the upstream direction and = injected > > by the > SF > > in the downstream direction. On the Internet side, it would look = like all > packets > > are injected by the SF in the upstream direction and dropped in the > > downstream direction. > > >> > > >> Thanks for any clarification. > > >> > > >> Ron > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> Sent: Saturday, February 11, 2017 11:34 AM > > >> To: 'Dave Dolson' ; 'Joel M. Halpern' > > >> ; Ron Parker > > > >> Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia = - > > >> SG)' ; sfc@ietf.org; 'James N = Guichard' > > >> ; 'Fabricio Ferraz' > > >> > > >> Subject: RE: [sfc] NSH Service Index Decrement > > >> > > >> I hate to do my impersonation of Eric, but... > > >> > > >> "On the wire" is the crunch. > > >> > > >> Some have said that there must be no visible difference between = the > > >> three > > case: > > >> - on the wire between SFF and SF > > >> - on the wire between SF and SFF > > >> - on the wire between SFF and SFF > > >> > > >> If this holds then you are correct that sending SI=3D1 in the = first > > >> case > requires > > the SF to do more than a simple decrement (although decrement and > > discard is hardly painful). And it means that SI=3D1 is a dubious = value in an SFP. > > >> > > >> On the other hand, we appear to be clear about an SF that strips > > >> the NSH > and > > forwards the traffic as native : this is currently forbidden. So = there > > is no alternative for an SF receiving SI=3D1 except to discard the = packet. > > >> > > >> Now, does that mean that an SFF should never send a packet with > > >> SI=3D1? Well, > > possibly it is OK for a few specialist SFs intended to sit at the = end > > of the > chain and > > be a bit bucket with analysis. But, for most SFs there would be no = point. > > >> > > >> Maybe (just maybe) we should stop letting the tail wag the dog! > > >> That is, > let's > > decide on the functional behavior we want to see and then design the > > protocol to match. > > >> > > >> Adrian > > >> > > >>> -----Original Message----- > > >>> From: Dave Dolson [mailto:ddolson@sandvine.com] > > >>> Sent: 10 February 2017 22:26 > > >>> To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; = sfc@ietf.org; > > >>> 'James N Guichard'; 'Fabricio Ferraz' > > >>> Subject: RE: [sfc] NSH Service Index Decrement > > >>> > > >>> Adrian, > > >>> I think I agree with everything you said. > > >>> But you did not suggest whether or not you think that SI=3D0 = should > > >>> be valid on > > >> the > > >>> wire. > > >>> I'm saying it could work, if the next hop is a path terminus. > > >>> > > >>> If I understand Joel correctly, he says we shouldn't send SI=3D0 = in > > >>> case the > > >> next > > >>> hop blindly decrements it. > > >>> --> this seems to mean SI=3D1 cannot be used except at the = terminus > > >>> --> or when the > > >>> SF is expected to drop all packets. > > >>> So I think this is an unnecessary seat belt, trying to = anticipate > > >>> bugs in > > >> down- > > >>> stream devices. > > >>> > > >>> I realize the current language has been there a long time, and = if > > >>> it is > > >> important to > > >>> anyone then it should remain. > > >>> Nonetheless, I think devices could safely handle SI=3D0 on the = wire > > >>> without breaking anything. > > >>> > > >>> But I'm not pushing for a change, since the current behavior = seems > > >>> important > > >> to > > >>> some. > > >>> > > >>> -Dave > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian = Farrel > > >>> Sent: Friday, February 10, 2017 9:16 AM > > >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; = sfc@ietf.org; > > >>> 'James N Guichard'; 'Fabricio Ferraz' > > >>> Subject: Re: [sfc] NSH Service Index Decrement > > >>> > > >>> Oh, you finally pushed me into this discussion, Dave. > > >>> > > >>> We're building a protocol. with a protocol, you cannot (must = not) > > >>> assume good behavior from your neighbor. > > >>> > > >>> So if the SF touches the SI (which it does) we must define the > > >>> edge > > >> conditions. > > >>> If it is the SF's job to decrement the SI, then we must also > > >>> define what it > > >> does > > >>> when SI=3D0 (otherwise, it will set SI to 0-1). > > >>> If the SF is not allowed to decrement the SI below zero (which > > >>> makes > > >>> sense) we must define what it must do. > > >>> Since SFs are allowed to drop packets (indeed that is one of = their > > >>> main jobs > > >> ;-) > > >>> then this would be fine. > > >>> All that would be left is to define whether they apply the test > > >>> before or > > >> after > > >>> normal processing. > > >>> > > >>> As an aside, I agree with Don that TTL helps relax this a = little, > > >>> but does not get us all the way there. > > >>> > > >>> Cheers, > > >>> Adrian > > >>> > > >>>> -----Original Message----- > > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave = Dolson > > >>>> Sent: 09 February 2017 21:00 > > >>>> To: Joel M. Halpern; Ron Parker > > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C > > >>>> Rosen; Dolganow, Andrew (Nokia - SG) > > >>>> Subject: Re: [sfc] NSH Service Index Decrement > > >>>> > > >>>> Discussing misconfigured SFFs is a straw-man argument. Once one > > >>>> starts > > >> trying > > >>> to > > >>>> anticipate down-stream devices being misconfigured, one can > > >>>> invent a lot of > > >>> silly > > >>>> requirements. > > >>>> > > >>>> >From an aesthetic point of view, I think it's bad that there = are > > >>>>> two SI > > >>> values (0 > > >>>> and 1) that cannot be used. > > >>>> > > >>>> The real requirement, IMO, is that no device decrements 0 and > > >>>> forwards > > NSH. > > >>>> Since only SFs decrement SI, only SFs need to do this check. > > >>>> > > >>>> And any discussion about buggy SFs... well there is a lot of = bad > > >>>> stuff that > > >>> bugs can > > >>>> cause. > > >>>> > > >>>> > > >>>> > > >>>> -----Original Message----- > > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > >>>> Sent: Thursday, February 09, 2017 2:54 PM > > >>>> To: Ron Parker; Dave Dolson > > >>>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); > > >>>> James N > > >>> Guichard; > > >>>> Fabricio Ferraz > > >>>> Subject: Re: [sfc] NSH Service Index Decrement > > >>>> > > >>>> From my perspective as an individual participant in this work, > > >>>> declaring that 0 must be dropped is a matter of robustness. > > >>>> > > >>>> if we allow 0 to be processed for exit at an SFF, then a > > >>>> mis-configured SFF could easily continue processing such a = packet. > > >>>> Now, it is true that TTL will eventually drop it, but that is = an > expensive > > fallback. > > >>>> > > >>>> More importantly, presumably the next entitiy down the = incorrect > > >>>> path would drop it for a 255 SI. But at that point we are > > >>>> getting the error in the wrong place, making it harder to = diagnose and > repair. > > >>>> > > >>>> Yours, > > >>>> Joel > > >>>> > > >>>> On 2/9/17 12:42 PM, Ron Parker wrote: > > >>>>> agree. > > >>>>> > > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson > >>>>> > wrote: > > >>>>> > > >>>>>> I'm not clear on why this is broken, or why this restriction = is made. > > >>>>>> > > >>>>>> I agree it should not be sent to an SF, but an SFF could map = an > > >>>>>> SI of zero into a path termination. > > >>>>>> > > >>>>>> I.e., the last SF in a path could decrement SI from 1 to 0, = and > > >>>>>> the SFF could then terminate the chain. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James = N > > >>>>>> Guichard > > >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Not exactly. Section 3.3 specifies "The value zero for SI is > > >>>>>> not valid and indicates a broken SFC or malfunctioning SF" .. > > >>>>>> In other words an SF should never receive an NSH packet with = SI =3D 0. > > >>>>>> Note that if this happened then either a) a classifier set = the > > >>>>>> SI incorrectly, or b) a re-classifier set the SI incorrectly, > > >>>>>> or c) an upstream SF set the SI incorrectly; all of these = cases > > >>>>>> should be caught by the SFF whose job it is to discard NSH > > >>>>>> packets with SI =3D > 0. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Jim > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM > > >>>>>> *To:* James N Guichard > >>>>>> >; Dolganow, Andrew = (Nokia > > >>>>>> - > > >>>>>> SG) > >>>>>> >; > > >>>> Dave > > >>>>>> Dolson >; > > >>>>>> Eric C Rosen >; > > >>>>>> sfc@ietf.org > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Hi Jim, > > >>>>>> > > >>>>>> Thanks. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> One more question about the SI. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Section 3 states that: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Service Index (SI): provides location within the SFP. The > > >>>>>> initial classifier MUST set the appropriate SI value for a > > >>>>>> given classification result. The initial SI value SHOULD = default to 255. > > >>>>>> However, the classifier MUST allow configuration of other SI = values. > > >>>>>> > > >>>>>> Service Index MUST be decremented by Service Functions or by > > >>>>>> SFC Proxy nodes after performing required services and the = new > > >>>>>> decremented SI value MUST be used in the egress NSH packet. > > >>>>>> > > >>>>>> The initial Classifier MUST send the packet to the first SFF = in > > >>>>>> the identified SFP for forwarding along an SFP. > > >>>>>> > > >>>>>> If re-classification occurs, and that re-classification = results > > >>>>>> in a new SPI, the (re)classifier is, in effect, the initial > > >>>>>> classifier for the resultant SPI. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Thus: > > >>>>>> > > >>>>>> a) Initial SI value should be 255 but other values can = be > > >>>>>> configured by the classifier. > > >>>>>> > > >>>>>> b) SF decrements the SI value on the egress NSH packet > > >>>>>> > > >>>>>> c) If re-classification occurs with new SPI, the = re-classifier > > >>>>>> is the initial classifier, so by a), SI should be again 255 = or > > >>>>>> other value > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> So any SI value can be receive by an SF, even 1 or 0 because: > > >>>>>> > > >>>>>> =E8If SI=3D1 and there is no re-classification, the egress = NSH will > > >>>>>> have SI=3D0 > > >>>>>> > > >>>>>> =E8If SI=3D0 and there is re-classification with new SPI, the > > >>>>>> egress NSH will have a new SPI and a SI=3D 255 or other = value, as stated in > a). > > >>>>>> > > >>>>>> =E8If SI=3D0 and there is no re-classification the SF should > > >>>>>> discard the packet > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Also an SFF should forward/handle packets with NSH with = SI=3D1 or SI=3D0. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Do you agree? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James = N > > >>>>>> Guichard > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Hi Fabricio, > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Welcome! > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Yes, removal of NSH is the responsibility of an SFF or a > > >>>>>> re-classifier (section 4, bullet point 1 lays this out). With > > >>>>>> the current architecture the SF does not care what SI value = it > > >>>>>> gets, it just needs to worry about decrementing it, and leave > > >>>>>> it up to the SFF to evaluate the SI value and associated = action. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Jim > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >>>>>> *Sent:* Thursday, February 09, 2017 7:13 AM > > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) = > >>>>>> >; Dave Dolson > > >>>> > >>>>>> >; Eric C Rosen > > >>>>>> >; James N > > >>>>>> Guichard > >>> >; > > >>>>>> sfc@ietf.org > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Hi all, > > >>>>>> > > >>>>>> I'm new here (just read the draft last week) but according to > > >>>>>> chapter > > >>>>>> 4 (check figure 8 for example), an SF is not allowed to = insert > > >>>>>> or remove NSH. The removal of NSH is reponsability of the = SSF, right? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Figure 8 maps each of the four actions above to the > > >>>>>> components in the > > >>>>>> > > >>>>>> SFC architecture that can perform it. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> +---------------+------------------+-------+----------------+---------+ > > >>>>>> > > >>>>>> | | Insert |Select | Update = |Service | > > >>>>>> > > >>>>>> | | or remove NSH |Service| NSH = |policy | > > >>>>>> > > >>>>>> | | |Function| |selection| > > >>>>>> > > >>>>>> | Component +--------+--------+Path +----------------+ | > > >>>>>> > > >>>>>> | | | | | Dec. |Update | | > > >>>>>> > > >>>>>> | | Insert | Remove | |Service |Context| | > > >>>>>> > > >>>>>> | | | | | Index |Header | | > > >>>>>> > > >>>>>> +----------------+--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> | | + | + | | | + | | > > >>>>>> > > >>>>>> |Classifier | | | | | | | > > >>>>>> > > >>>>>> +--------------- > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> |Service Function| | + | + | | | | > > >>>>>> > > >>>>>> |Forwarder(SFF) | | | | | | | > > >>>>>> > > >>>>>> +--------------- > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> |Service | | | | + | + | = + | > > >>>>>> > > >>>>>> |Function (SF) | | | | | | | > > >>>>>> > > >>>>>> +--------------- > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> |SFC Proxy | + | + | | + | | | > > >>>>>> > > >>>>>> +----------------+--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Figure 8: NSH Action and Role Mapping > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> An SF could receive an NSH packet with an SI of 1, and > > >>>>>> reclassify it to a different SPI and SI, right? So when a SF > > >>>>>> receives a NSH packet with SI =3D 1 that does not necessarily = means a > non valid packet. > > >>>>>> > > >>>>>> And that can even work for SI=3D0, since you decrement the SI = in > > >>>>>> the > > >> egress. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Fabricio > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > > >>>>>> *Dolganow, Andrew (Nokia - SG) > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; = sfc@ietf.org > > >>>>>> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> I assumed that if we get value 1 we process then forward > > >>>>>> without NSH header (i.e.) this is the last SF processing. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> So with that assumption, a more explicit text would be: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > >>>>>> decrement the SI by 1 after performing all required local > > >>>>>> processing and before forwarding the packet to the next SFF. = If > > >>>>>> the resulting SI is 0, the SF MUST remove the NSH header = before > > forwarding the packet. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Andrew > > >>>>>> > > >>>>>> *From: *sfc > >>>>>> > on behalf of Dave Dolson > > >>>>>> > >>>> > > > >>>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM > > >>>>>> *To: *Eric Rosen > >>>>>> >, James N Guichard > > >>>>>> > >>>>>> >, "sfc@ietf.org > > >>>>>> " > > > >>>>>> *Subject: *Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Eric, > > >>>>>> > > >>>>>> I was never quite happy with the outcome that neither 0 nor 1 > > >>>>>> is a valid SI. > > >>>>>> > > >>>>>> (Because if received with value of 1, it is decremented and > > >>>>>> discarded.) > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> It seems to waste an index value. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> I guess I'm interested to know if that is important to other > > >>>>>> implementers, or if that was even the intention? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -Dave > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric = C > > >>>>>> Rosen > > >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM > > >>>>>> *To:* James N Guichard; sfc@ietf.org > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: > > >>>>>> > > >>>>>> A request was made to be more specific and update the text as > follows: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> "Service index MUST be decremented *by a value of 1* by = Service > > >>>>>> Functions or by SFC Proxy nodes after performing required = services ." > > >>>>>> > > >>>>>> > > >>>>>> A couple of observations: > > >>>>>> > > >>>>>> - The term "SFC Proxy node" is not defined in either the NSH > > >>>>>> draft or in RFC 7665. I think the intention here is to say > > >>>>>> "SFC > Proxy". > > >>>>>> > > >>>>>> - Is the intention that the SI remain unchanged while the SF = is > > >>>>>> operating on the packet, or is the intention only that the SI > > >>>>>> be decremented before the packet is delivered by the SF or = SFC > > >>>>>> Proxy to an SFF? > > >>>>>> > > >>>>>> I'd suggest either: > > >>>>>> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > >>>>>> decrement the SI by 1 before delivering the packet to the = next SFF" > > >>>>>> > > >>>>>> or > > >>>>>> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > >>>>>> decrement the SI by 1 before delivering the packet to the = next > > >>>>>> SFF, but not until the SF has finished all its other = processing > > >>>>>> of the > > packet" > > >>>>>> > > >>>>>> depending upon which is intended. > > >>>>>> > > >>>>>> I think an implication of these procedures is that an SI = value > > >>>>>> of > > >>>>>> 1 is not valid. If an SF gets an NSH packet with an SI of 1, > > >>>>>> the SF will decrement the SI (setting it to 0), send the = packet > > >>>>>> to an SFF, and the SFF will discard it, because 0 is an = invalid > > >>>>>> SI value. Is that the intention? > > >>>>>> > > >>>>>> The draft makes it clear (well, sort of) that an SFF should > > >>>>>> discard a packet with an SI of 0, but does not seem to say = that > > >>>>>> an SF or SFC Proxy should discard a packet it receives with = an > > >>>>>> SI of 0. It would probably be a good idea to say that. > > >>>>>> > > >>>>>> Some text in the draft (e.g., section 7.1) states than an SFF > > >>>>>> should discard a packet with an SI of zero, but other text in > > >>>>>> the draft (e.g., section 3.3) only says that an SFF should = log > > >>>>>> an error if it sees an SI of zero. It's probably best to > > >>>>>> change the text in 3.3. to say "SHOULD generate an error/log > > >>>>>> message and MUST discard the packet", or something similar. > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> 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 > > >>> > > >>> _______________________________________________ > > >>> sfc mailing list > > >>> sfc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sfc > > >> > > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Feb 12 06:07:30 2017 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 5AC9E12961D for ; Sun, 12 Feb 2017 06:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_LOW=-0.7, 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 9JE-amXg7JOj for ; Sun, 12 Feb 2017 06:07:24 -0800 (PST) Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com [IPv6:2607:f8b0:400c:c05::241]) (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 8A51C129613 for ; Sun, 12 Feb 2017 06:07:23 -0800 (PST) Received: by mail-vk0-x241.google.com with SMTP id n125so5906703vke.3 for ; Sun, 12 Feb 2017 06:07:23 -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=7d2z1kzkHYoQJ7eww5V9TiUcppO/OkKnibv3qv5reKA=; b=QmNE/1r15wa9TWwq2TRQpbnVDMwcuDGM2zLPrF1YIeYsgAIdGz1x16hQfGGsnXHEDv 6Qpt/uOL5+u9ltcmfjHI4amXtKWi2mhPZxAIob/hPrviGbuFRebrnX9uTLW6EwuaTM14 hw6Bs9hYaQVd1xCupwL09A/wdcNZEVquHfeC1+5VPH52NIrdXROloZYLGrFqm+oFGBUs imNkEbsyemo1hgSvg81ZXcx2WyPUsgbqellQYOKVlHqt/YWjfzT2KAbLGjNB60DDZEyK WdNJmXwJer/Q2M20jneAEV9TF2XBNxcnHxrmq4glaM3fn8K24xYUxpcjQ8HkdRAXkBim NW+A== 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=7d2z1kzkHYoQJ7eww5V9TiUcppO/OkKnibv3qv5reKA=; b=Jh5FeHgd/jQZx2LXsP+b/tZwVgMhLdukGihBqgjgSTbIgokKxJEOsGeNQrhvBuH9Jp IY9/HofIT1i5SWy4+cxee+FDUljqPJ6HmhB+tNLlpYdQ8HKWksy2UfLSddPFPr4rQNsn RtSzfUVteFokLwO25GQ0J2G5lHSzMu4onVkeKUebAbD2w3BtGhyqwpsSUK1p4hALkZsk Pybim9v8xxtIfB+w6seDd6QgVxlne9XZHyehrApBH9HHMs07hVSX1If6PbNF5pciQGOc AjBjBIfEMtllD8o2q+e4VNBUvsU+kSUx5CI5TLx9CB9j321PxKVnxZML8OWDDwklo66F zmJw== X-Gm-Message-State: AMke39kT24P3qYoaU0L56eQAAwaG9AlhyYOF4SHagbJ4Sv3sR8LXveC+PGPPseotIIStx/NsjVq4hT0Gfkil+A== X-Received: by 10.31.149.15 with SMTP id x15mr7876618vkd.130.1486908442315; Sun, 12 Feb 2017 06:07:22 -0800 (PST) MIME-Version: 1.0 References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> <0e0f01d2851b$d7323a10$8596ae30$@olddog.co.uk> In-Reply-To: <0e0f01d2851b$d7323a10$8596ae30$@olddog.co.uk> From: Jim Guichard Date: Sun, 12 Feb 2017 14:07:11 +0000 Message-ID: To: James N Guichard , "Joel M. Halpern" , Ron Parker , adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=001a114264d6848f4b054855d965 Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 14:07:28 -0000 --001a114264d6848f4b054855d965 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian, The point is an SFF does not need to distinguish between receipt of a packet from an SF or SFF; the suggested text is relevant to a device that forwards based on NSH and in this architecture only an SFF does that. Jim On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel wrote: > Thanks Jim, > > > > Your text works for me although I would prefer to delete the commentary > about a > > "broken SFC" as a specific example of how this might happen that is not > the only > > case (for example, a broken reclassifier can also cause this). > > > > So, can we settle on > > > > "Packets received at an SFF with an SI of zero MUST be discarded and the > SFF > > SHOULD generate an error/log message." > > > > BTW, I said > > >> Then (of course) it is also OK for an SFF to receive SI=3D0, but I thi= nk > the > > existing > > >> "discard" text covers that case. > > and you replied > > > from an SF yes but not from another SFF. > > and that (of course) has been a point of entertainment for some while. > > Since an SFF cannot tell the difference between a packet received from an > SFF > > and one from an SF we must document all cases alike. > > > > Fortunately, we're able to do so for this instance. > > > > A > > > > > > > > > > > -----Original Message----- > > > From: James N Guichard [mailto:james.n.guichard@huawei.com] > > > Sent: 12 February 2017 00:58 > > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > > > Cc: sfc@ietf.org > > > Subject: RE: [sfc] NSH Service Index Decrement > > > > > > Hi Adrian, > > > > > > Inline (hat off opinion) .. > > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > > Sent: Saturday, February 11, 2017 5:36 PM > > > To: 'Joel M. Halpern' ; 'Ron Parker' > > > > > > Cc: sfc@ietf.org > > > Subject: Re: [sfc] NSH Service Index Decrement > > > > > > Joel, > > > > > > The -10 version of NSH says > > > > > > The > > > value zero for SI is not valid and indicates a broken SFC or > > > malfunctioning SF. > > > > > > Jim> the above text is perhaps what is causing some confusion as it > implies an > > SI > > > of 0 from an SF is invalid. May I suggest the following text as a > replacement > > for > > > the above sentence: > > > > > > "The value zero for SI indicates a broken SFC. Packets received at an > SFF with > > an > > > SI of zero MUST be discarded and the SFF SHOULD generate an error/log > > > message". > > > > > > You are saying that the latter of these is not true. > > > I can't tell whether the former is really true or, perhaps, represents = a > > discard tail > > > of an SFC where some (but not all) packets are reclassified per Ron. > > > > > > Like I said: > > > > > > > Let's clarify that it is OK for an SF to send a packet with SI=3D0 > > > > > > Then (of course) it is also OK for an SFF to receive SI=3D0, but I thin= k > the > > existing > > > "discard" text covers that case. > > > > > > Jim> from an SF yes but not from another SFF. However, in either case, = a > > lookup > > > on should cause the SFF to discard the packet. Hopefully = my > above > > > suggested text clarifies that. > > > > > > Adrian > > > > > > > -----Original Message----- > > > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > > > Sent: 11 February 2017 18:08 > > > > To: Ron Parker; adrian@olddog.co.uk; 'Dave Dolson' > > > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; > > > > 'James N Guichard'; 'Fabricio Ferraz' > > > > Subject: Re: [sfc] NSH Service Index Decrement > > > > > > > > I was commenting, in personal hat, about the issue of whether there > > > > was some sort of problem with the impact of the current description o= n > > > > SI=3D1 packets arriving at an SF. It seems to me that your example > > > > shows that such an effect is sometimes useul. > > > > It will also sometimes produce packet drops by the SFF, when the SF > > > > does not terminate the packet. Okay, so be it. > > > > It is not even clear there is anything, in Adrian's phrase, to paint > > > > red here. > > > > > > > > Yours, > > > > Joel > > > > > > > > On 2/11/17 12:59 PM, Ron Parker wrote: > > > > > Hi, Joel. > > > > > > > > > > Does your comment pertain to my somewhat off topic question which > > > > > was > > > > related to one of Adrian's tangential issues, or to Adrian's original > > > > SF=3D1 > > > topic? > > > > > > > > > > Thanks. > > > > > > > > > > Ron > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > > > > Sent: Saturday, February 11, 2017 12:31 PM > > > > > To: Ron Parker ; > > > > > adrian@olddog.co.uk; > > > > 'Dave Dolson' > > > > > Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia - > SG)' > > > > ; sfc@ietf.org; 'James N Guichard' > > > > ; 'Fabricio Ferraz' > > > > > > > > > Subject: Re: [sfc] NSH Service Index Decrement > > > > > > > > > > Personally, what you describe sounds like a quite reasonable case > > > > > where a > > > > packet arrive at the SF with an SI of 1 will produce exactly the > > > > desired > > > behavior. > > > > > > > > > > Which suggests, to my limited view, that the current text works fin= e. > > > > > > > > > > Yours, > > > > > Joel > > > > > > > > > > On 2/11/17 11:55 AM, Ron Parker wrote: > > > > >> Hi, Adrian. > > > > >> > > > > >> Not the original topic, per se, but wrt your comment: > > > > >> > > > > >> * On the other hand, we appear to be clear about an SF that strips > > > > >> the NSH > > > > and forwards the traffic as native : this is currently forbidden. > > > > >> > > > > >> I'm wondering how to reconcile this to a transparent HTTP Proxy > > > > >> that does > > > not > > > > preserve the original source-IP? Does this mean that it is mandator= y > for > > > such an > > > > SF to also be a classifier so it can self-classify its own related > > > > flows > > > (i.e., using its > > > > own visible IP addresses)? From SFF perspective, it would look lik= e > all > > > packets > > > > on the access side are dropped in the upstream direction and injected > > > > by the > > > SF > > > > in the downstream direction. On the Internet side, it would look > like all > > > packets > > > > are injected by the SF in the upstream direction and dropped in the > > > > downstream direction. > > > > >> > > > > >> Thanks for any clarification. > > > > >> > > > > >> Ron > > > > >> > > > > >> > > > > >> > > > > >> -----Original Message----- > > > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > >> Sent: Saturday, February 11, 2017 11:34 AM > > > > >> To: 'Dave Dolson' ; 'Joel M. Halpern' > > > > >> ; Ron Parker > > > > > > > >> Cc: 'Eric C Rosen' ; 'Dolganow, Andrew (Nokia = - > > > > >> SG)' ; sfc@ietf.org; 'James N Guichard' > > > > >> ; 'Fabricio Ferraz' > > > > >> > > > > >> Subject: RE: [sfc] NSH Service Index Decrement > > > > >> > > > > >> I hate to do my impersonation of Eric, but... > > > > >> > > > > >> "On the wire" is the crunch. > > > > >> > > > > >> Some have said that there must be no visible difference between th= e > > > > >> three > > > > case: > > > > >> - on the wire between SFF and SF > > > > >> - on the wire between SF and SFF > > > > >> - on the wire between SFF and SFF > > > > >> > > > > >> If this holds then you are correct that sending SI=3D1 in the firs= t > > > > >> case > > > requires > > > > the SF to do more than a simple decrement (although decrement and > > > > discard is hardly painful). And it means that SI=3D1 is a dubious val= ue > in an > > SFP. > > > > >> > > > > >> On the other hand, we appear to be clear about an SF that strips > > > > >> the NSH > > > and > > > > forwards the traffic as native : this is currently forbidden. So ther= e > > > > is no alternative for an SF receiving SI=3D1 except to discard the > packet. > > > > >> > > > > >> Now, does that mean that an SFF should never send a packet with > > > > >> SI=3D1? Well, > > > > possibly it is OK for a few specialist SFs intended to sit at the end > > > > of the > > > chain and > > > > be a bit bucket with analysis. But, for most SFs there would be no > point. > > > > >> > > > > >> Maybe (just maybe) we should stop letting the tail wag the dog! > > > > >> That is, > > > let's > > > > decide on the functional behavior we want to see and then design the > > > > protocol to match. > > > > >> > > > > >> Adrian > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Dave Dolson [mailto:ddolson@sandvine.com] > > > > >>> Sent: 10 February 2017 22:26 > > > > >>> To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker' > > > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org= ; > > > > >>> 'James N Guichard'; 'Fabricio Ferraz' > > > > >>> Subject: RE: [sfc] NSH Service Index Decrement > > > > >>> > > > > >>> Adrian, > > > > >>> I think I agree with everything you said. > > > > >>> But you did not suggest whether or not you think that SI=3D0 shou= ld > > > > >>> be valid on > > > > >> the > > > > >>> wire. > > > > >>> I'm saying it could work, if the next hop is a path terminus. > > > > >>> > > > > >>> If I understand Joel correctly, he says we shouldn't send SI=3D0 = in > > > > >>> case the > > > > >> next > > > > >>> hop blindly decrements it. > > > > >>> --> this seems to mean SI=3D1 cannot be used except at the termin= us > > > > >>> --> or when the > > > > >>> SF is expected to drop all packets. > > > > >>> So I think this is an unnecessary seat belt, trying to anticipate > > > > >>> bugs in > > > > >> down- > > > > >>> stream devices. > > > > >>> > > > > >>> I realize the current language has been there a long time, and if > > > > >>> it is > > > > >> important to > > > > >>> anyone then it should remain. > > > > >>> Nonetheless, I think devices could safely handle SI=3D0 on the wi= re > > > > >>> without breaking anything. > > > > >>> > > > > >>> But I'm not pushing for a change, since the current behavior seem= s > > > > >>> important > > > > >> to > > > > >>> some. > > > > >>> > > > > >>> -Dave > > > > >>> > > > > >>> > > > > >>> -----Original Message----- > > > > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farre= l > > > > >>> Sent: Friday, February 10, 2017 9:16 AM > > > > >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > > > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org= ; > > > > >>> 'James N Guichard'; 'Fabricio Ferraz' > > > > >>> Subject: Re: [sfc] NSH Service Index Decrement > > > > >>> > > > > >>> Oh, you finally pushed me into this discussion, Dave. > > > > >>> > > > > >>> We're building a protocol. with a protocol, you cannot (must not) > > > > >>> assume good behavior from your neighbor. > > > > >>> > > > > >>> So if the SF touches the SI (which it does) we must define the > > > > >>> edge > > > > >> conditions. > > > > >>> If it is the SF's job to decrement the SI, then we must also > > > > >>> define what it > > > > >> does > > > > >>> when SI=3D0 (otherwise, it will set SI to 0-1). > > > > >>> If the SF is not allowed to decrement the SI below zero (which > > > > >>> makes > > > > >>> sense) we must define what it must do. > > > > >>> Since SFs are allowed to drop packets (indeed that is one of thei= r > > > > >>> main jobs > > > > >> ;-) > > > > >>> then this would be fine. > > > > >>> All that would be left is to define whether they apply the test > > > > >>> before or > > > > >> after > > > > >>> normal processing. > > > > >>> > > > > >>> As an aside, I agree with Don that TTL helps relax this a little, > > > > >>> but does not get us all the way there. > > > > >>> > > > > >>> Cheers, > > > > >>> Adrian > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > > > >>>> Sent: 09 February 2017 21:00 > > > > >>>> To: Joel M. Halpern; Ron Parker > > > > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C > > > > >>>> Rosen; Dolganow, Andrew (Nokia - SG) > > > > >>>> Subject: Re: [sfc] NSH Service Index Decrement > > > > >>>> > > > > >>>> Discussing misconfigured SFFs is a straw-man argument. Once one > > > > >>>> starts > > > > >> trying > > > > >>> to > > > > >>>> anticipate down-stream devices being misconfigured, one can > > > > >>>> invent a lot of > > > > >>> silly > > > > >>>> requirements. > > > > >>>> > > > > >>>> >From an aesthetic point of view, I think it's bad that there ar= e > > > > >>>>> two SI > > > > >>> values (0 > > > > >>>> and 1) that cannot be used. > > > > >>>> > > > > >>>> The real requirement, IMO, is that no device decrements 0 and > > > > >>>> forwards > > > > NSH. > > > > >>>> Since only SFs decrement SI, only SFs need to do this check. > > > > >>>> > > > > >>>> And any discussion about buggy SFs... well there is a lot of bad > > > > >>>> stuff that > > > > >>> bugs can > > > > >>>> cause. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> -----Original Message----- > > > > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > > > >>>> Sent: Thursday, February 09, 2017 2:54 PM > > > > >>>> To: Ron Parker; Dave Dolson > > > > >>>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG); > > > > >>>> James N > > > > >>> Guichard; > > > > >>>> Fabricio Ferraz > > > > >>>> Subject: Re: [sfc] NSH Service Index Decrement > > > > >>>> > > > > >>>> From my perspective as an individual participant in this work, > > > > >>>> declaring that 0 must be dropped is a matter of robustness. > > > > >>>> > > > > >>>> if we allow 0 to be processed for exit at an SFF, then a > > > > >>>> mis-configured SFF could easily continue processing such a packe= t. > > > > >>>> Now, it is true that TTL will eventually drop it, but that is an > > > expensive > > > > fallback. > > > > >>>> > > > > >>>> More importantly, presumably the next entitiy down the incorrect > > > > >>>> path would drop it for a 255 SI. But at that point we are > > > > >>>> getting the error in the wrong place, making it harder to > diagnose and > > > repair. > > > > >>>> > > > > >>>> Yours, > > > > >>>> Joel > > > > >>>> > > > > >>>> On 2/9/17 12:42 PM, Ron Parker wrote: > > > > >>>>> agree. > > > > >>>>> > > > > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson > > > >>>>> > wrote: > > > > >>>>> > > > > >>>>>> I'm not clear on why this is broken, or why this restriction i= s > made. > > > > >>>>>> > > > > >>>>>> I agree it should not be sent to an SF, but an SFF could map a= n > > > > >>>>>> SI of zero into a path termination. > > > > >>>>>> > > > > >>>>>> I.e., the last SF in a path could decrement SI from 1 to 0, an= d > > > > >>>>>> the SFF could then terminate the chain. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James = N > > > > >>>>>> Guichard > > > > >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM > > > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave > > > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > > > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Not exactly. Section 3.3 specifies "The value zero for SI is > > > > >>>>>> not valid and indicates a broken SFC or malfunctioning SF" .. > > > > >>>>>> In other words an SF should never receive an NSH packet with S= I > =3D 0. > > > > >>>>>> Note that if this happened then either a) a classifier set the > > > > >>>>>> SI incorrectly, or b) a re-classifier set the SI incorrectly, > > > > >>>>>> or c) an upstream SF set the SI incorrectly; all of these case= s > > > > >>>>>> should be caught by the SFF whose job it is to discard NSH > > > > >>>>>> packets with SI =3D > > > 0. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Jim > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > > > >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM > > > > >>>>>> *To:* James N Guichard > > > >>>>>> >; Dolganow, Andrew (Nokia > > > > >>>>>> - > > > > >>>>>> SG) > > > >>>>>> >; > > > > >>>> Dave > > > > >>>>>> Dolson >; > > > > >>>>>> Eric C Rosen >; > > > > >>>>>> sfc@ietf.org > > > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Hi Jim, > > > > >>>>>> > > > > >>>>>> Thanks. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> One more question about the SI. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Section 3 states that: > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Service Index (SI): provides location within the SFP. The > > > > >>>>>> initial classifier MUST set the appropriate SI value for a > > > > >>>>>> given classification result. The initial SI value SHOULD > default to > > 255. > > > > >>>>>> However, the classifier MUST allow configuration of other SI > values. > > > > >>>>>> > > > > >>>>>> Service Index MUST be decremented by Service Functions or by > > > > >>>>>> SFC Proxy nodes after performing required services and the new > > > > >>>>>> decremented SI value MUST be used in the egress NSH packet. > > > > >>>>>> > > > > >>>>>> The initial Classifier MUST send the packet to the first SFF i= n > > > > >>>>>> the identified SFP for forwarding along an SFP. > > > > >>>>>> > > > > >>>>>> If re-classification occurs, and that re-classification result= s > > > > >>>>>> in a new SPI, the (re)classifier is, in effect, the initial > > > > >>>>>> classifier for the resultant SPI. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Thus: > > > > >>>>>> > > > > >>>>>> a) Initial SI value should be 255 but other values can be > > > > >>>>>> configured by the classifier. > > > > >>>>>> > > > > >>>>>> b) SF decrements the SI value on the egress NSH packet > > > > >>>>>> > > > > >>>>>> c) If re-classification occurs with new SPI, the > re-classifier > > > > >>>>>> is the initial classifier, so by a), SI should be again 255 o= r > > > > >>>>>> other value > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> So any SI value can be receive by an SF, even 1 or 0 because: > > > > >>>>>> > > > > >>>>>> =C3=A8If SI=3D1 and there is no re-classification, the egress = NSH will > > > > >>>>>> have SI=3D0 > > > > >>>>>> > > > > >>>>>> =C3=A8If SI=3D0 and there is re-classification with new SPI, t= he > > > > >>>>>> egress NSH will have a new SPI and a SI=3D 255 or other value,= as > > stated in > > > a). > > > > >>>>>> > > > > >>>>>> =C3=A8If SI=3D0 and there is no re-classification the SF shoul= d > > > > >>>>>> discard the packet > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Also an SFF should forward/handle packets with NSH with SI=3D1= or > SI=3D0. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Do you agree? > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James = N > > > > >>>>>> Guichard > > > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > > > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave > > > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > > > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Hi Fabricio, > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Welcome! > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Yes, removal of NSH is the responsibility of an SFF or a > > > > >>>>>> re-classifier (section 4, bullet point 1 lays this out). With > > > > >>>>>> the current architecture the SF does not care what SI value it > > > > >>>>>> gets, it just needs to worry about decrementing it, and leave > > > > >>>>>> it up to the SFF to evaluate the SI value and associated actio= n. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Jim > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > > > >>>>>> *Sent:* Thursday, February 09, 2017 7:13 AM > > > > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) > > > >>>>>> >; Dave Dolson > > > > >>>> > > > >>>>>> >; Eric C Rosen > > > > >>>>>> >; James N > > > > >>>>>> Guichard > > > >>> >; > > > > >>>>>> sfc@ietf.org > > > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Hi all, > > > > >>>>>> > > > > >>>>>> I'm new here (just read the draft last week) but according to > > > > >>>>>> chapter > > > > >>>>>> 4 (check figure 8 for example), an SF is not allowed to insert > > > > >>>>>> or remove NSH. The removal of NSH is reponsability of the SSF, > right? > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Figure 8 maps each of the four actions above to the > > > > >>>>>> components in the > > > > >>>>>> > > > > >>>>>> SFC architecture that can perform it. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > +---------------+------------------+-------+----------------+---------+ > > > > >>>>>> > > > > >>>>>> | | Insert |Select | Update > |Service > > | > > > > >>>>>> > > > > >>>>>> | | or remove NSH |Service| NSH > |policy > > | > > > > >>>>>> > > > > >>>>>> | | |Function| > > |selection| > > > > >>>>>> > > > > >>>>>> | Component +--------+--------+Path +----------------+ > > | > > > > >>>>>> > > > > >>>>>> | | | | | Dec. |Update | > > | > > > > >>>>>> > > > > >>>>>> | | Insert | Remove | |Service |Context| > > | > > > > >>>>>> > > > > >>>>>> | | | | | Index |Header | > > | > > > > >>>>>> > > > > >>>>>> > > +----------------+--------+--------+-------+--------+-------+---------+ > > > > >>>>>> > > > > >>>>>> | | + | + | | | + | > > | > > > > >>>>>> > > > > >>>>>> |Classifier | | | | | | > > | > > > > >>>>>> > > > > >>>>>> +--------------- > > > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > > > >>>>>> > > > > >>>>>> |Service Function| | + | + | | | > > | > > > > >>>>>> > > > > >>>>>> |Forwarder(SFF) | | | | | | > > | > > > > >>>>>> > > > > >>>>>> +--------------- > > > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > > > >>>>>> > > > > >>>>>> |Service | | | | + | + | > + > > | > > > > >>>>>> > > > > >>>>>> |Function (SF) | | | | | | > > | > > > > >>>>>> > > > > >>>>>> +--------------- > > > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > > > >>>>>> > > > > >>>>>> |SFC Proxy | + | + | | + | | > > | > > > > >>>>>> > > > > >>>>>> > > +----------------+--------+--------+-------+--------+-------+---------+ > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Figure 8: NSH Action and Role Mapping > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> An SF could receive an NSH packet with an SI of 1, and > > > > >>>>>> reclassify it to a different SPI and SI, right? So when a SF > > > > >>>>>> receives a NSH packet with SI =3D 1 that does not necessarily > means a > > > non valid packet. > > > > >>>>>> > > > > >>>>>> And that can even work for SI=3D0, since you decrement the SI = in > > > > >>>>>> the > > > > >> egress. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Fabricio > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > > > > >>>>>> *Dolganow, Andrew (Nokia - SG) > > > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > > > > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.or= g > > > > >>>>>> > > > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> I assumed that if we get value 1 we process then forward > > > > >>>>>> without NSH header (i.e.) this is the last SF processing. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> So with that assumption, a more explicit text would be: > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > > > >>>>>> decrement the SI by 1 after performing all required local > > > > >>>>>> processing and before forwarding the packet to the next SFF. I= f > > > > >>>>>> the resulting SI is 0, the SF MUST remove the NSH header befor= e > > > > forwarding the packet. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Andrew > > > > >>>>>> > > > > >>>>>> *From: *sfc > > > >>>>>> > on behalf of Dave Dolson > > > > >>>>>> > > > >>>> > > > > > >>>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM > > > > >>>>>> *To: *Eric Rosen > > > >>>>>> >, James N Guichard > > > > >>>>>> > > > >>>>>> >, "sfc@ietf.org > > > > >>>>>> " > > > > > >>>>>> *Subject: *Re: [sfc] NSH Service Index Decrement > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Eric, > > > > >>>>>> > > > > >>>>>> I was never quite happy with the outcome that neither 0 nor 1 > > > > >>>>>> is a valid SI. > > > > >>>>>> > > > > >>>>>> (Because if received with value of 1, it is decremented and > > > > >>>>>> discarded.) > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> It seems to waste an index value. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> I guess I'm interested to know if that is important to other > > > > >>>>>> implementers, or if that was even the intention? > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> -Dave > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C > > > > >>>>>> Rosen > > > > >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM > > > > >>>>>> *To:* James N Guichard; sfc@ietf.org > > > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: > > > > >>>>>> > > > > >>>>>> A request was made to be more specific and update the text as > > > follows: > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> "Service index MUST be decremented *by a value of 1* by Servic= e > > > > >>>>>> Functions or by SFC Proxy nodes after performing required > services ." > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> A couple of observations: > > > > >>>>>> > > > > >>>>>> - The term "SFC Proxy node" is not defined in either the NSH > > > > >>>>>> draft or in RFC 7665. I think the intention here is to say > > > > >>>>>> "SFC > > > Proxy". > > > > >>>>>> > > > > >>>>>> - Is the intention that the SI remain unchanged while the SF i= s > > > > >>>>>> operating on the packet, or is the intention only that the SI > > > > >>>>>> be decremented before the packet is delivered by the SF or SFC > > > > >>>>>> Proxy to an SFF? > > > > >>>>>> > > > > >>>>>> I'd suggest either: > > > > >>>>>> > > > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > > > >>>>>> decrement the SI by 1 before delivering the packet to the next > SFF" > > > > >>>>>> > > > > >>>>>> or > > > > >>>>>> > > > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > > > >>>>>> decrement the SI by 1 before delivering the packet to the next > > > > >>>>>> SFF, but not until the SF has finished all its other processin= g > > > > >>>>>> of the > > > > packet" > > > > >>>>>> > > > > >>>>>> depending upon which is intended. > > > > >>>>>> > > > > >>>>>> I think an implication of these procedures is that an SI value > > > > >>>>>> of > > > > >>>>>> 1 is not valid. If an SF gets an NSH packet with an SI of 1, > > > > >>>>>> the SF will decrement the SI (setting it to 0), send the packe= t > > > > >>>>>> to an SFF, and the SFF will discard it, because 0 is an invali= d > > > > >>>>>> SI value. Is that the intention? > > > > >>>>>> > > > > >>>>>> The draft makes it clear (well, sort of) that an SFF should > > > > >>>>>> discard a packet with an SI of 0, but does not seem to say tha= t > > > > >>>>>> an SF or SFC Proxy should discard a packet it receives with an > > > > >>>>>> SI of 0. It would probably be a good idea to say that. > > > > >>>>>> > > > > >>>>>> Some text in the draft (e.g., section 7.1) states than an SFF > > > > >>>>>> should discard a packet with an SI of zero, but other text in > > > > >>>>>> the draft (e.g., section 3.3) only says that an SFF should log > > > > >>>>>> an error if it sees an SI of zero. It's probably best to > > > > >>>>>> change the text in 3.3. to say "SHOULD generate an error/log > > > > >>>>>> message and MUST discard the packet", or something similar. > > > > >>>>>> > > > > >>>>>> _______________________________________________ > > > > >>>>>> 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 > > > > >>> > > > > >>> _______________________________________________ > > > > >>> 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 > > --001a114264d6848f4b054855d965 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

The point is an SFF does not need = to distinguish between receipt of a packet from an SF or SFF; the suggested= text is relevant to a device that forwards based on NSH and in this archit= ecture only an SFF does that.

Jim
On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel <adrian@olddog.co.uk> wrote:
Thanks Jim,


Your text works for me although I would prefer to = delete the commentary about a

"broken SFC&q= uot; as a specific example of how this might happen that is not the only
case (for example, a broken reclassifier can also = cause this).



So, can= we settle on



"= Packets received at an SFF with an SI of zero MUST be discarded and the SFF=

SHOULD generate an error/log message."



BTW, I said

>> Then (of course) it is also OK for an SFF to recei= ve SI=3D0, but I think the

existing

>> "discard" text covers that case.

and you replied

> from an = SF yes but not from another SFF.

and that (of co= urse) has been a point of entertainment for some while.

Since an SFF cannot tell the difference between a packet received f= rom an SFF

and one from an SF we must document a= ll cases alike.



Fort= unately, we're able to do so for this instance.
=


A









> -----Original Message-----

> From: James N Guichard [mailto:james.n.guichard@huawe= i.com]

> Sent: 12 February 2017 00:58

> To: adrian@olddog.co.uk; 'Joel M. Ha= lpern'; 'Ron Parker'

> Cc: sfc@ietf.or= g

> Subject: RE: [sfc] NSH Service Index = Decrement

>

> H= i Adrian,

>

> I= nline (hat off opinion) ..

>

> -----Original Message-----

> = From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Saturday, February 11, 2017 5:36 PM
> To: 'Joel M. Halpern' <jmh@joelh= alpern.com>; 'Ron Parker'

> &l= t;Ron_Parker@affirmednetworks.com>

> Cc: sfc@ietf.org

> Subject: Re: [= sfc] NSH Service Index Decrement

>

> Joel,

>

> The -10 version of NSH says

&= gt;

>=C2=A0 =C2=A0 The

>=C2=A0 =C2=A0 value zero for SI is not valid and indicates a broke= n SFC or

>=C2=A0 =C2=A0 malfunctioning SF.
>

> Jim> the a= bove text is perhaps what is causing some confusion as it implies an

SI

> of 0 from an SF is = invalid. May I suggest the following text as a replacement

for

> the above sentence:

>

> "The value zer= o for SI indicates a broken SFC. Packets received at an SFF with

an

> SI of zero MUST be di= scarded and the SFF SHOULD generate an error/log
> message".

>

> You are saying that the latter of these is not true.

> I can't tell whether the former is really true or, = perhaps, represents a

discard tail

> of an SFC where some (but not all) packets are reclassif= ied per Ron.

>

>= ; Like I said:

>

&= gt; > Let's clarify that it is OK for an SF to send a packet with SI= =3D0

>

> Then (= of course) it is also OK for an SFF to receive SI=3D0, but I think the

existing

> "disca= rd" text covers that case.

>

> Jim> from an SF yes but not from another SFF. Howev= er, in either case, a

lookup

> on <SPI><SI=3D0> should cause the SFF to discard t= he packet. Hopefully my above

> suggested tex= t clarifies that.

>
> Adrian

>

&g= t; > -----Original Message-----

> > Fro= m: Joel M. Halpern [mailto:jmh@joelhalpern.com]

> > Sent: 11 February 2017 18:08

>= ; > To: Ron Parker; adrian@olddog.co.uk; 'Dave Dolson'

> > Cc: 'Eric C Rosen'; 'Dolganow= , Andrew (Nokia - SG)'; sfc@ietf.org;

> &g= t; 'James N Guichard'; 'Fabricio Ferraz'

> > Subject: Re: [sfc] NSH Service Index Decrement

> >

> > I was com= menting, in personal hat, about the issue of whether there

> > was some sort of problem with the impact of the curren= t description on

> > SI=3D1 packets arrivi= ng at an SF.=C2=A0 It seems to me that your example
=
> > shows that such an effect is sometimes useul.

> > It will also sometimes produce packet drops by the SF= F, when the SF

> > does not terminate the = packet.=C2=A0 Okay, so be it.

> > It is no= t even clear there is anything, in Adrian's phrase, to paint

> > red here.

> >=

> > Yours,

>= ; > Joel

> >
> > On 2/11/17 12:59 PM, Ron Parker wrote:
> > > Hi, Joel.

> > >

> > > Does your comment pertain to my somewha= t off topic question which

> > > was
> > related to one of Adrian's tangentia= l issues, or to Adrian's original

> > = SF=3D1

> topic?

&g= t; > >

> > > Thanks.

> > >

> > >=C2= =A0 =C2=A0 Ron

> > >

> > >

> > > -----Orig= inal Message-----

> > > From: Joel M. H= alpern [mailto:jmh@joelhalpern.com]

> &= gt; > Sent: Saturday, February 11, 2017 12:31 PM
=
> > > To: Ron Parker <Ron_Parker@affirmednetw= orks.com>;

> > > adrian@olddog= .co.uk;

> > 'Dave Dolson' <= ddolson@sandvine.com>

> > > C= c: 'Eric C Rosen' <erosen@juniper.net>; 'Dolganow,= Andrew (Nokia - SG)'

> > <andrew.dolganow@nokia.com>; sfc@ietf.org; 'James N Guichard= 9;

> > <james.n.guichard@huaw= ei.com>; 'Fabricio Ferraz'

> &= gt; <fabricio-ferraz@telecom.pt>
=
> > > Subject: Re: [sfc] NSH Service Index Decrement

> > >

> > >= Personally, what you describe sounds like a quite reasonable case

> > > where a

> &= gt; packet arrive at the SF with an SI of 1 will produce exactly the

> > desired

> beha= vior.

> > >

= > > > Which suggests, to my limited view, that the current text wo= rks fine.

> > >
=
> > > Yours,

> > > Joel
> > >

> >= ; > On 2/11/17 11:55 AM, Ron Parker wrote:

&g= t; > >> Hi, Adrian.

> > >><= br class=3D"gmail_msg">
> > >> Not the original topic, per s= e, but wrt your comment:

> > >>

> > >> * On the other hand, we appear to= be clear about an SF that strips

> > >= > the NSH

> > and forwards the traffic = as native : this is currently forbidden.

> &g= t; >>

> > >> I'm wondering= how to reconcile this to a transparent HTTP Proxy
<= br>> > >> that does

> not

> > preserve the original source-IP?=C2=A0 =C2=A0= Does this mean that it is mandatory for

> suc= h an

> > SF to also be a classifier so it = can self-classify its own related

> > flow= s

> (i.e., using its
<= br>> > own visible IP addresses)?=C2=A0 =C2=A0 From SFF perspective, = it would look like all

> packets

> > on the access side are dropped in the upstream dir= ection and injected

> > by the

> SF

> > in the downstr= eam direction.=C2=A0 =C2=A0On the Internet side, it would look like all

> packets

> > a= re injected by the SF in the upstream direction and dropped in the

> > downstream direction.
<= br>> > >>

> > >> Thanks = for any clarification.

> > >>

> > >>=C2=A0 =C2=A0 Ron

> > >>

> > >>
> > >>

>= ; > >> -----Original Message-----

> = > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk]

> > >> Sent: Saturday, February 11, 2017 1= 1:34 AM

> > >> To: 'Dave Dolson&= #39; <ddolson@sandvine.com>; 'Joel M. Halpern'

> > >> <jmh@joelhalpern.com>; R= on Parker

> <Ron_Parker@affi= rmednetworks.com>

> > >> Cc: = 'Eric C Rosen' <erosen@juniper.net>; 'Dolganow, Andr= ew (Nokia -

> > >> SG)' <andrew.dolganow@nokia.com>; sfc@ietf.org; 'James N Guichard&#= 39;

> > >> <james.n.gui= chard@huawei.com>; 'Fabricio Ferraz'
=
> > >> <fabricio-ferraz@telecom.pt>

> > >> Subject: RE: [sfc] NSH Service In= dex Decrement

> > >>

> > >> I hate to do my impersonation of Eric, but..= .

> > >>

= > > >> "On the wire" is the crunch.

> > >>

> > >> = Some have said that there must be no visible difference between the

> > >> three

>= ; > case:

> > >> - on the wire be= tween SFF and SF

> > >> - on the wir= e between SF and SFF

> > >> - on the= wire between SFF and SFF

> > >>

> > >> If this holds then you are corre= ct that sending SI=3D1 in the first

> > &g= t;> case

> requires

> > the SF to do more than a simple decrement (although decremen= t and

> > discard is hardly painful). And = it means that SI=3D1 is a dubious value in an

SF= P.

> > >>
> > >> On the other hand, we appear to be clear about an SF th= at strips

> > >> the NSH

> and

> > forwards the = traffic as native : this is currently forbidden. So there

> > is no alternative for an SF receiving SI=3D1 except to = discard the packet.

> > >>

> > >> Now, does that mean that an SFF shoul= d never send a packet with

> > >> SI= =3D1? Well,

> > possibly it is OK for a fe= w specialist SFs intended to sit at the end

>= > of the

> chain and

> > be a bit bucket with analysis. But, for most SFs there wou= ld be no point.

> > >>

> > >> Maybe (just maybe) we should stop letting = the tail wag the dog!

> > >> That is= ,

> let's

>= > decide on the functional behavior we want to see and then design the<= br class=3D"gmail_msg">
> > protocol to match.

> > >>

> > >> Ad= rian

> > >>
<= br>> > >>> -----Original Message-----

> > >>> From: Dave Dolson [mailto:ddolson@sandvine.c= om]

> > >>> Sent: 10 February= 2017 22:26

> > >>> To: adria= n@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker'

> > >>> Cc: 'Eric C Rosen'; '= ;Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;
<= br>> > >>> 'James N Guichard'; 'Fabricio Ferraz&= #39;

> > >>> Subject: RE: [sfc] N= SH Service Index Decrement

> > >>>= ;

> > >>> Adrian,

> > >>> I think I agree with everything you said= .

> > >>> But you did not suggest= whether or not you think that SI=3D0 should

>= ; > >>> be valid on

> > >&g= t; the

> > >>> wire.

> > >>> I'm saying it could work, if the = next hop is a path terminus.

> > >>&= gt;

> > >>> If I understand Joel = correctly, he says we shouldn't send SI=3D0=C2=A0 in

> > >>> case the

> &g= t; >> next

> > >>> hop blin= dly decrements it.

> > >>> -->= this seems to mean SI=3D1 cannot be used except at the terminus

> > >>> --> or when the

> > >>> SF is expected to drop all packets.

> > >>> So I think this is an unnece= ssary seat belt, trying to anticipate

> > = >>> bugs in

> > >> down-
> > >>> stream devices.

> > >>>

> >= >>> I realize the current language has been there a long time, an= d if

> > >>> it is

> > >> important to

>= ; > >>> anyone then it should remain.
> > >>> Nonetheless, I think devices could safely handle S= I=3D0 on the wire

> > >>> without= breaking anything.

> > >>>

> > >>> But I'm not pushing for a = change, since the current behavior seems

> &g= t; >>> important

> > >> to<= br class=3D"gmail_msg">
> > >>> some.

> > >>>

> > >>= ;> -Dave

> > >>>

> > >>>

> > &= gt;>> -----Original Message-----

> >= >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of A= drian Farrel

> > >>> Sent: Friday= , February 10, 2017 9:16 AM

> > >>&g= t; To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker'

> > >>> Cc: 'Eric C Rosen'; '= ;Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;
<= br>> > >>> 'James N Guichard'; 'Fabricio Ferraz&= #39;

> > >>> Subject: Re: [sfc] N= SH Service Index Decrement

> > >>>= ;

> > >>> Oh, you finally pushed = me into this discussion, Dave.

> > >>= ;>

> > >>> We're building = a protocol. with a protocol, you cannot (must not)
<= br>> > >>> assume good behavior from your neighbor.

> > >>>

> &= gt; >>> So if the SF touches the SI (which it does) we must define= the

> > >>> edge

> > >> conditions.

> = > >>> If it is the SF's job to decrement the SI, then we mu= st also

> > >>> define what it
> > >> does
> > >>> when SI=3D0 (otherwise, it will set SI to 0-1).

> > >>> If the SF is not allowed to = decrement the SI below zero (which

> > >= ;>> makes

> > >>> sense) we= must define what it must do.

> > >>= > Since SFs are allowed to drop packets (indeed that is one of their

> > >>> main jobs

> > >> ;-)

> > >&g= t;> then this would be fine.

> > >&g= t;> All that would be left is to define whether they apply the test

> > >>> before or

> > >> after

> > >&= gt;> normal processing.

> > >>>= ;

> > >>> As an aside, I agree wi= th Don that TTL helps relax this a little,

> = > >>> but does not get us all the way there.

> > >>>

> > >&g= t;> Cheers,

> > >>> Adrian

> > >>>

&= gt; > >>>> -----Original Message-----

> > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson

> > >>&= gt;> Sent: 09 February 2017 21:00

> > &= gt;>>> To: Joel M. Halpern; Ron Parker

= > > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org= ; Eric C

> > >>>> Rosen; D= olganow, Andrew (Nokia - SG)

> > >>&= gt;> Subject: Re: [sfc] NSH Service Index Decrement

> > >>>>

> > >= >>> Discussing misconfigured SFFs is a straw-man argument. Once on= e

> > >>>> starts

> > >> trying

> &g= t; >>> to

> > >>>> an= ticipate down-stream devices being misconfigured, one can

> > >>>> invent a lot of

> > >>> silly

> > >= >>> requirements.

> > >>>= ;>

> > >>>> >From an aes= thetic point of view, I think it's bad that there are

> > >>>>> two SI

= > > >>> values (0

> > >&= gt;>> and 1) that cannot be used.

> >= ; >>>>

> > >>>> Th= e real requirement, IMO, is that no device decrements 0 and

> > >>>> forwards

= > > NSH.

> > >>>> Since = only SFs decrement SI, only SFs need to do this check.

> > >>>>

> > >= >>> And any discussion about buggy SFs... well there is a lot of b= ad

> > >>>> stuff that

> > >>> bugs can
=
> > >>>> cause.

> > = >>>>

> > >>>>

> > >>>>
> > >>>> -----Original Message-----

> > >>>> From: Joel M. Halpern [mailto:jmh@joel= halpern.com]

> > >>>> Sent= : Thursday, February 09, 2017 2:54 PM

> > = >>>> To: Ron Parker; Dave Dolson

>= ; > >>>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (No= kia - SG);

> > >>>> James N
> > >>> Guichard;

> > >>>> Fabricio Ferraz

> > >>>> Subject: Re: [sfc] NSH Service Index Decrem= ent

> > >>>>

> > >>>>=C2=A0 From my perspective as an indivi= dual participant in this work,

> > >>= ;>> declaring that 0 must be dropped is a matter of robustness.

> > >>>>
> > >>>> if we allow 0 to be processed for exit at an SF= F, then a

> > >>>> mis-configu= red SFF could easily continue processing such a packet.

> > >>>> Now, it is true that TTL will eventually= drop it, but that is an

> expensive

> > fallback.

> >= >>>>

> > >>>> Mor= e importantly, presumably the next entitiy down the incorrect

> > >>>> path would drop it for a 255 SI.= =C2=A0 But at that point we are

> > >&g= t;>> getting the error in the wrong place, making it harder to diagno= se and

> repair.

&= gt; > >>>>

> > >>>= > Yours,

> > >>>> Joel

> > >>>>
> > >>>> On 2/9/17 12:42 PM, Ron Parker wrote:

> > >>>>> agree.

> > >>>>>

> >= ; >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson <ddol= son@sandvine.com

> > >>>>&= gt; <mailto:ddolson@sandvine.com>> wrote:

> > >>>>>

> &g= t; >>>>>> I'm not clear on why this is broken, or why= this restriction is made.

> > >>>= ;>>>

> > >>>>>>= I agree it should not be sent to an SF, but an SFF could map an

> > >>>>>> SI of zero into a pat= h termination.

> > >>>>>>= ;

> > >>>>>> I.e., the l= ast SF in a path could decrement SI from 1 to 0, and

> > >>>>>> the SFF could then terminate the ch= ain.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> &g= t; >>>>>>

> > >>&g= t;>>>

> > >>>>>>= ; *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N
> > >>>>>> Guichard

> > >>>>>> *Sent:* Thursday, F= ebruary 09, 2017 12:02 PM

> > >>>= >>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave

> > >>>>>> Dolson; Eric C R= osen; sfc@ietf.org <mailto:sfc@ietf.org>

>= ; > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decr= ement

> > >>>>>>

> > >>>>>>

> > >>>>>>

> &= gt; >>>>>> Not exactly. Section 3.3 specifies "The v= alue zero for SI is

> > >>>>&g= t;> not valid and indicates a broken SFC or malfunctioning SF" ..
> > >>>>>> In other words= an SF should never receive an NSH packet with SI =3D 0.

> > >>>>>> Note that if this happened then= either a) a classifier set the

> > >&g= t;>>>> SI incorrectly, or b) a re-classifier set the SI incorre= ctly,

> > >>>>>> or c) a= n upstream SF set the SI incorrectly; all of these cases

> > >>>>>> should be caught by the SFF who= se job it is to discard NSH

> > >>&g= t;>>> packets with SI =3D

> 0.

> > >>>>>>

> > >>>>>>

>= > >>>>>>

> > >>= ;>>>> Jim

> > >>>>= >>

> > >>>>>>

> > >>>>>>

> > >>>>>> *From:*Fabricio Ferraz [mailto= :fabricio-ferraz@telecom.pt]

>= > >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM=

> > >>>>>> *To:* James = N Guichard <james.n.guichard@huawei.com

> > >>>>>> <mailto:james.n.gu= ichard@huawei.com>>; Dolganow, Andrew (Nokia

> > >>>>>> -

>= > >>>>>> SG) <andrew.dolganow@nokia.com

> > >>>>>> <mailto:= andrew.dolganow@nokia.com>>;

&= gt; > >>>> Dave

> > >>= ;>>>> Dolson <ddolson@sandvine.com <mailto:ddo= lson@sandvine.com>>;

> > >>= ;>>>> Eric C Rosen <erosen@juniper.net <mailto:eros= en@juniper.net>>;

> > >>&g= t;>>> sfc@ietf.org <mailto:sfc@ietf.org>

> > >>>>>> *Subject:* RE: [sfc] NSH Service= Index Decrement

> > >>>>>&= gt;

> > >>>>>>

> > >>>>>>

> > >>>>>> Hi Jim,
> > >>>>>>

> > &g= t;>>>>> Thanks.

> > >>= ;>>>>

> > >>>>>= >

> > >>>>>>

> > >>>>>> One more question abo= ut the SI.

> > >>>>>>
> > >>>>>>

> > >>>>>>

&= gt; > >>>>>> Section 3 states that:

> > >>>>>>

>= > >>>>>>

> > >>= ;>>>>

> > >>>>>= > Service Index (SI): provides location within the SFP. The

> > >>>>>> initial classifier MUST s= et the appropriate SI value for a

> > >= >>>>> given classification result. The initial SI value SHOU= LD default to

255.

&g= t; > >>>>>> However, the classifier MUST allow configu= ration of other SI values.

> > >>>= ;>>>

> > >>>>>>= Service Index MUST be decremented by Service Functions or by

> > >>>>>> SFC Proxy nodes after perf= orming required services and the new

> > &= gt;>>>>> decremented SI value MUST be used in the egress NSH= packet.

> > >>>>>>

> > >>>>>> The initial Class= ifier MUST send the packet to the first SFF in

&= gt; > >>>>>> the identified SFP for forwarding along a= n SFP.

> > >>>>>>

> > >>>>>> If re-classificatio= n occurs, and that re-classification results

>= ; > >>>>>> in a new SPI, the (re)classifier is, in eff= ect, the initial

> > >>>>>&= gt; classifier for the resultant SPI.

> > = >>>>>>

> > >>>&= gt;>>

> > >>>>>>
> > >>>>>> Thus:

> > >>>>>>

> > >>>>>> a)=C2=A0 =C2=A0 =C2=A0 Initial SI = value should be 255 but other values can be

>= > >>>>>> configured by the classifier.

> > >>>>>>

= > > >>>>>> b)=C2=A0 =C2=A0 =C2=A0 SF decrements the= SI value on the egress NSH packet

> > >= ;>>>>>

> > >>>>= >> c)=C2=A0 =C2=A0 =C2=A0 =C2=A0If re-classification occurs with new = SPI, the re-classifier

> > >>>>= ;>> is the initial classifier, so by=C2=A0 a), SI should be again 255= or

> > >>>>>> other val= ue

> > >>>>>>

> > >>>>>>

> > >>>>>>

> &g= t; >>>>>> So any SI value can be receive by an SF, even 1= or 0 because:

> > >>>>>>= ;

> > >>>>>> =C3=A8If SI= =3D1 and there is no re-classification, the egress NSH will

> > >>>>>> have SI=3D0

> > >>>>>>

&g= t; > >>>>>> =C3=A8If SI=3D0 and there is re-classifica= tion with new SPI, the

> > >>>>= ;>> egress NSH will have a new SPI and a SI=3D 255 or other value, as=

stated in

> a).
> > >>>>>>

> > >>>>>> =C3=A8If SI=3D0 and there i= s no re-classification the SF should

> > &= gt;>>>>> discard the packet

> = > >>>>>>

> > >>= >>>>

> > >>>>>&= gt;

> > >>>>>> Also an S= FF should forward/handle packets with NSH with SI=3D1 or SI=3D0.

> > >>>>>>

> > >>>>>>

> &g= t; >>>>>>

> > >>&g= t;>>> Do you agree?

> > >>&= gt;>>>

> > >>>>>&g= t;

> > >>>>>>

> > >>>>>>

> > >>>>>>

> &g= t; >>>>>>

> > >>&g= t;>>>

> > >>>>>>= ; *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N
> > >>>>>> Guichard

> > >>>>>> *Sent:* quinta-feir= a, 9 de fevereiro de 2017 16:25

> > >&g= t;>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Da= ve

> > >>>>>> Dolson; Er= ic C Rosen; sfc@ietf.org <mailto:sfc@ietf.org>
<= br>> > >>>>>> *Subject:* Re: [sfc] NSH Service Inde= x Decrement

> > >>>>>>
> > >>>>>>

> > >>>>>>

= > > >>>>>> Hi Fabricio,

= > > >>>>>>

> > >= ;>>>>>

> > >>>>= >>

> > >>>>>> Welc= ome!

> > >>>>>>

> > >>>>>>

> > >>>>>>

> &g= t; >>>>>> Yes, removal of NSH is the responsibility of an= SFF or a

> > >>>>>> re-= classifier (section 4, bullet point 1 lays this out). With

> > >>>>>> the current architecture the = SF does not care what SI value it

> > >= >>>>> gets, it just needs to worry about decrementing it, an= d leave

> > >>>>>> it up= to the SFF to evaluate the SI value and associated action.

> > >>>>>>

&= gt; > >>>>>>

> > >= >>>>>

> > >>>>&= gt;> Jim

> > >>>>>>
> > >>>>>>

> > >>>>>>

= > > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt]

> > >= >>>>> *Sent:* Thursday, February 09, 2017 7:13 AM

> > >>>>>> *To:* Dolganow, Andre= w (Nokia - SG) <andrew.dolganow@nokia.com

> > >>>>>> <mailto:andrew.dolga= now@nokia.com>>; Dave Dolson

> >= >>>> <ddolson@sandvine.com
> > >>>>>> <mailto:ddolson@sandvine.com= >>; Eric C Rosen

> > >>>>= ;>> <erosen@juniper.net <mailto:erosen@juniper.net>= ;>; James N

> > >>>>>>= ; Guichard <james.n.guichard@huawei.com

> > >>> <mailto:james.n.guichard@huawe= i.com>>;

> > >>>>>= ;> sfc@ietf.org <mailto:sfc@ietf.org>

>= ; > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decr= ement

> > >>>>>>

> > >>>>>>

> > >>>>>>

> &= gt; >>>>>> Hi all,

> > &= gt;>>>>>

> > >>>&g= t;>> I'm new here (just read the draft last week) but according t= o

> > >>>>>> chapter

> > >>>>>> 4 (check figure = 8 for example), an SF is not allowed to insert

&= gt; > >>>>>> or remove NSH. The removal of NSH is repo= nsability of the SSF, right?

> > >>&= gt;>>>

> > >>>>>&g= t;

> > >>>>>>

> > >>>>>>=C2=A0 =C2=A0Figure 8 = maps each of the four actions above to the

> = > >>>>>> components in the

= > > >>>>>>

> > >= ;>>>>>=C2=A0 =C2=A0 SFC architecture that can perform it.
> > >>>>>>

> > >>>>>>

&= gt; > >>>>>>

> > >= >>>>>

+---------------+----------= --------+-------+----------------+---------+

>= ; > >>>>>>

> > >&g= t;>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 Insert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|Select |=C2=A0 =C2=A0Upda= te=C2=A0 =C2=A0 =C2=A0 =C2=A0|Service

|

> > >>>>>>

> > >>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 or remove NSH=C2=A0 |Service|=C2=A0 =C2=A0= NSH=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|policy

|<= br class=3D"gmail_msg">
> > >>>>>>

> > >>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|Function|

|selection|

> > >>>>>>

> > >>>>>> | Component=C2=A0 =C2=A0 =C2=A0= +--------+--------+Path=C2=A0 =C2=A0+----------------+

|

> > >>>>>>

> > >>>>>> |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0| Dec.=C2=A0 =C2=A0|Up= date |

|

> > &g= t;>>>>>

> > >>>>= ;>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Insert= | Remove |=C2=A0 =C2=A0 =C2=A0 =C2=A0|Service |Context|

|

> > >>>>>>
> > >>>>>> |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0| Index=C2=A0 |Header = |

|

> > >>= ;>>>>

> > >>>>>= >

+----------------+--------+--------+-------= +--------+-------+---------+

> > >>&= gt;>>>

> > >>>>>&g= t; |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0+= =C2=A0 =C2=A0 |=C2=A0 =C2=A0+=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0+=C2=A0 =C2=A0|

|

> > >>>>>>

> > >>>>>> |Classifier=C2=A0= =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|

|

> &g= t; >>>>>>

> > >>&g= t;>>> +---------------

> > >&g= t;>>>> ++--------+--------+-------+--------+-------+---------+<= br class=3D"gmail_msg">
> > >>>>>>

> > >>>>>> |Service Function|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0+=C2=A0 =C2=A0 |=C2=A0 +=C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|

|

> > >>>>>>
> > >>>>>> |Forwarder(SFF= )=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0|

|

> > >= >>>>>

> > >>>>&= gt;> +---------------

> > >>>&= gt;>> ++--------+--------+-------+--------+-------+---------+

> > >>>>>>

> > >>>>>> |Service=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+=C2=A0 =C2=A0 |=C2=A0 =C2=A0+=C2=A0 =C2= =A0|=C2=A0 =C2=A0+

|

= > > >>>>>>

> > >= ;>>>>> |Function=C2=A0 (SF)=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0= =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|

|
> > >>>>>>

> > >>>>>> +---------------

> > >>>>>> ++--------+--------+-= ------+--------+-------+---------+

> > >= ;>>>>>

> > >>>>= >> |SFC Proxy=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+=C2=A0 =C2=A0 = |=C2=A0 =C2=A0+=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+=C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|

|

> > >>>>>>

> > >>>>>>

+---= -------------+--------+--------+-------+--------+-------+---------+

> > >>>>>>

> > >>>>>>

> &= gt; >>>>>>

> > >>&= gt;>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Figure 8: NSH Action and Role Mapping
> > >>>>>>

> > &g= t;>>>>>

> > >>>>= ;>>

> > >>>>>>

> > >>>>>>

> > >>>>>> An SF could receive an NSH pa= cket with an SI of 1, and

> > >>>= >>> reclassify it to a different SPI and SI, right? So when a SF
> > >>>>>> receives a NSH= packet with SI =3D 1 that does not necessarily means a

> non valid packet.

> > >>= ;>>>>

> > >>>>>= > And that can even work for SI=3D0, since you decrement the SI in

> > >>>>>> the

> > >> egress.

> >= ; >>>>>>

> > >>>= ;>>>

> > >>>>>>=

> > >>>>>> Fabricio

> > >>>>>>

> > >>>>>>

&g= t; > >>>>>>

> > >&= gt;>>>>

> > >>>>&g= t;>

> > >>>>>> *From:= *sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of

> > >>>>>> *Dolganow, Andrew (Nokia - SG)
> > >>>>>> *Sent:* quinta= -feira, 9 de fevereiro de 2017 01:51

> > &= gt;>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; = sfc@i= etf.org

> > >>>>>> &= lt;mailto:sfc@ietf.org>

> > >>>= >>> *Subject:* Re: [sfc] NSH Service Index Decrement

> > >>>>>>
> > >>>>>>

> > &g= t;>>>>>

> > >>>>= ;>> I assumed that if we get value 1 we process then forward

> > >>>>>> without NSH header (i= .e.) this is the last SF processing.

> > &= gt;>>>>>

> > >>>&g= t;>>

> > >>>>>>
> > >>>>>> So with that as= sumption, a more explicit text would be:

> &g= t; >>>>>>

> > >>&g= t;>>>

> > >>>>>>= ;

> > >>>>>> An SF or SF= C Proxy receiving an NSH-encapsulated packet MUST
> > >>>>>> decrement the SI by 1 after performing= all required local

> > >>>>&g= t;> processing and before forwarding the packet to the next SFF. If

> > >>>>>> the resulting SI = is 0, the SF MUST remove the NSH header before

&= gt; > forwarding the packet.

> > >&g= t;>>>>

> > >>>>>= ;>

> > >>>>>>

> > >>>>>> Andrew

> > >>>>>>
> > >>>>>> *From: *sfc <sfc-bounces@ietf.org=

> > >>>>>> <mail= to:sfc-bounces@ietf.org>> on behalf of Dave Dolson

> > >>>>>> <ddolson@sandvine.= com

> > >>>> <mailto:ddolson@sandvine.com>>

> > >= >>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM

> > >>>>>> *To: *Eric Rosen <= erosen@juniper.net

> > >>>&g= t;>> <mailto:erosen@juniper.net>>, James N Guichard

> > >>>>>> <ja= mes.n.guichard@huawei.com

> > >>= >>>> <mailto:james.n.guichard@huawei.com>&g= t;, "sfc@ietf.org

> > >>>>= >> <mailto:sfc@ietf.org>" <sfc@ietf.org <mailto:sfc@ietf.or= g>>

> > >>>>>>= *Subject: *Re: [sfc] NSH Service Index Decrement
> > >>>>>>

> > &= gt;>>>>>

> > >>>&g= t;>>

> > >>>>>> Er= ic,

> > >>>>>>

> > >>>>>> I was never quite hap= py with the outcome that neither 0 nor 1

> &g= t; >>>>>> is a valid SI.

> = > >>>>>>

> > >>= >>>> (Because if received with value of 1, it is decremented an= d

> > >>>>>> discarded.)=

> > >>>>>>

> > >>>>>>
> > >>>>>>

> > &= gt;>>>>> It seems to waste an index value.

> > >>>>>>

>= ; > >>>>>>

> > >&g= t;>>>>

> > >>>>>= ;> I guess I'm interested to know if that is important to other

> > >>>>>> implementers, or = if that was even the intention?

> > >&g= t;>>>>

> > >>>>>= ;>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> &= gt; >>>>>> -Dave

> > >= ;>>>>>

> > >>>>= >>

> > >>>>>>

> > >>>>>>

> > >>>>>>

>= ; > >>>>>>

> > >&g= t;>>>>

> > >>>>>= ;> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C=

> > >>>>>> Rosen

> > >>>>>> *Sent:* Wednesday, = February 08, 2017 11:53 AM

> > >>>= ;>>> *To:* James N Guichard; sfc@ietf.org <mailto:sfc@ietf.org>= ;

> > >>>>>> *Subject:* = Re: [sfc] NSH Service Index Decrement

> > = >>>>>>

> > >>>&= gt;>>

> > >>>>>>
> > >>>>>> On 2/7/2017 2:= 24 PM, James N Guichard wrote:

> > >>= ;>>>>

> > >>>>>= > A request was made to be more specific and update the text as

> follows:

> > >&= gt;>>>>

> > >>>>&g= t;>

> > >>>>>>

> > >>>>>> "Service index= MUST be decremented *by a value of 1* by Service
> > >>>>>> Functions or by SFC Proxy nodes after = performing required services ."

> > &= gt;>>>>>

> > >>>&g= t;>>

> > >>>>>> A = couple of observations:

> > >>>&g= t;>>

> > >>>>>> - = The term "SFC Proxy node" is not defined in either the NSH

> > >>>>>> draft or in RFC 766= 5.=C2=A0 I think the intention here is to say

&g= t; > >>>>>> "SFC

> = Proxy".

> > >>>>>><= br class=3D"gmail_msg">
> > >>>>>> - Is the inte= ntion that the SI remain unchanged while the SF is
<= br>> > >>>>>> operating on the packet, or is the in= tention only that the SI

> > >>>&= gt;>> be decremented before the packet is delivered by the SF or SFC<= br class=3D"gmail_msg">
> > >>>>>> Proxy to an S= FF?

> > >>>>>>

> > >>>>>> I'd suggest eithe= r:

> > >>>>>>

> > >>>>>> "An SF or SFC Pr= oxy receiving an NSH-encapsulated packet MUST

&g= t; > >>>>>> decrement the SI by 1 before delivering th= e packet to the next SFF"

> > >>= ;>>>>

> > >>>>>= > or

> > >>>>>>

> > >>>>>> "An SF or SFC= Proxy receiving an NSH-encapsulated packet MUST
> > >>>>>> decrement the SI by 1 before delivering= the packet to the next

> > >>>&g= t;>> SFF, but not until the SF has finished all its other processing<= br class=3D"gmail_msg">
> > >>>>>> of the

> > packet"

>= > >>>>>>

> > >>= ;>>>> depending upon which is intended.
=
> > >>>>>>

> >= >>>>>> I think an implication of these procedures is tha= t an SI value

> > >>>>>>= of

> > >>>>>> 1 is not = valid.=C2=A0 If an SF gets an NSH packet with an SI of 1,

> > >>>>>> the SF will decrement the SI (= setting it to 0), send the packet

> > >= >>>>> to an SFF, and the SFF will discard it, because 0 is a= n invalid

> > >>>>>> SI = value.=C2=A0 Is that the intention?

> > &g= t;>>>>>

> > >>>>= ;>> The draft makes it clear (well, sort of) that an SFF should

> > >>>>>> discard a packet w= ith an SI of 0, but does not seem to say that

&g= t; > >>>>>> an SF or SFC Proxy should discard a packet= it receives with an

> > >>>>&= gt;> SI of 0.=C2=A0 It would probably be a good idea to say that.

> > >>>>>>

> > >>>>>> Some text in the draft (e.g., se= ction 7.1) states than an SFF

> > >>= >>>> should discard a packet with an SI of zero, but other text= in

> > >>>>>> the draft= (e.g., section 3.3) only says that an SFF should log

> > >>>>>> an error if it sees an SI of zero.= =C2=A0 It's probably best to

> > >&= gt;>>>> change the text in 3.3. to say "SHOULD generate an= error/log

> > >>>>>> me= ssage and MUST discard the packet", or something similar.

> > >>>>>>
> > >>>>>> ______________________________________= _________

> > >>>>>> sfc= mailing list

> > >>>>>>= sfc@= ietf.org <mailto:sfc@ietf.org>

> >= ; >>>>>> https://www.= ietf.org/mailman/listinfo/sfc

> > >= >>>>

> > >>>>><= br class=3D"gmail_msg">
> > >>>>> _________________= ______________________________

> > >>= ;>>> sfc mailing list

> > >>= ;>>> sfc@ietf.org

> > >>>= >> https://www.ietf.org/mailman/l= istinfo/sfc

> > >>>>>
> > >>>>

> > >>>> ___________________________________________= ____

> > >>>> sfc mailing list=

> > >>>> sfc@ietf.org

> > >>>> https://www.ietf.org/mailman/listinfo/sfc

> > >>>

> > >>&g= t; _______________________________________________
<= br>> > >>> sfc mailing list

> = > >>> sfc@ietf.org

> > >>= > https://www.ietf.org/mailman/listi= nfo/sfc

> > >>

> > >

>

> _______________________________________________

> sfc mailing list

> sfc@ietf.org=

> ht= tps://www.ietf.org/mailman/listinfo/sfc



_______________________________________________

sfc mailing list

sfc@ietf.org=

https:/= /www.ietf.org/mailman/listinfo/sfc

--001a114264d6848f4b054855d965-- From nobody Sun Feb 12 11:24:58 2017 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 5931E129A23 for ; Sun, 12 Feb 2017 11:24:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_3_b2dq5AZ6 for ; Sun, 12 Feb 2017 11:24:51 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FB1129A0A for ; Sun, 12 Feb 2017 11:24:51 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0319.002; Sun, 12 Feb 2017 11:24:50 -0800 From: Ron Parker To: Jim Guichard Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkAAeZjIw//6oW4D//33gw4AAqsEAgAASngCAASFmAIAAiOAAgAEwB4CAAIMaAP//jNyAgAB+Z8D//4u0gAAJXKMAAAy7vQAADG86AAAHXleAAAWrfRE= Date: Sun, 12 Feb 2017 19:24:50 +0000 Message-ID: References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> <0e0f01d2851b$d7323a10$8596ae30$@olddog.co.uk>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A2A658B1CB8B40799F2828D48A7B2126affirmednetworkscom_" MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" , "Joel M. Halpern" , "sfc@ietf.org" , James N Guichard Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:24:56 -0000 --_000_A2A658B1CB8B40799F2828D48A7B2126affirmednetworkscom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jim, I also consider the (re-)classifier to also make (an initial) forwarding de= cision based on NSH. Ron On Feb 12, 2017, at 9:07 AM, Jim Guichard > wrote: Hi Adrian, The point is an SFF does not need to distinguish between receipt of a packe= t from an SF or SFF; the suggested text is relevant to a device that forwar= ds based on NSH and in this architecture only an SFF does that. Jim On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel > wrote: Thanks Jim, Your text works for me although I would prefer to delete the commentary abo= ut a "broken SFC" as a specific example of how this might happen that is not the= only case (for example, a broken reclassifier can also cause this). So, can we settle on "Packets received at an SFF with an SI of zero MUST be discarded and the SF= F SHOULD generate an error/log message." BTW, I said >> Then (of course) it is also OK for an SFF to receive SI=3D0, but I think= the existing >> "discard" text covers that case. and you replied > from an SF yes but not from another SFF. and that (of course) has been a point of entertainment for some while. Since an SFF cannot tell the difference between a packet received from an S= FF and one from an SF we must document all cases alike. Fortunately, we're able to do so for this instance. A > -----Original Message----- > From: James N Guichard [mailto:james.n.guichard@huawei.com] > Sent: 12 February 2017 00:58 > To: adrian@olddog.co.uk; 'Joel M. Halpern'; '= Ron Parker' > Cc: sfc@ietf.org > Subject: RE: [sfc] NSH Service Index Decrement > > Hi Adrian, > > Inline (hat off opinion) .. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On B= ehalf Of Adrian Farrel > Sent: Saturday, February 11, 2017 5:36 PM > To: 'Joel M. Halpern' >; = 'Ron Parker' > > > Cc: sfc@ietf.org > Subject: Re: [sfc] NSH Service Index Decrement > > Joel, > > The -10 version of NSH says > > The > value zero for SI is not valid and indicates a broken SFC or > malfunctioning SF. > > Jim> the above text is perhaps what is causing some confusion as it impli= es an SI > of 0 from an SF is invalid. May I suggest the following text as a replace= ment for > the above sentence: > > "The value zero for SI indicates a broken SFC. Packets received at an SFF= with an > SI of zero MUST be discarded and the SFF SHOULD generate an error/log > message". > > You are saying that the latter of these is not true. > I can't tell whether the former is really true or, perhaps, represents a discard tail > of an SFC where some (but not all) packets are reclassified per Ron. > > Like I said: > > > Let's clarify that it is OK for an SF to send a packet with SI=3D0 > > Then (of course) it is also OK for an SFF to receive SI=3D0, but I think = the existing > "discard" text covers that case. > > Jim> from an SF yes but not from another SFF. However, in either case, a lookup > on should cause the SFF to discard the packet. Hopefully my= above > suggested text clarifies that. > > Adrian > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: 11 February 2017 18:08 > > To: Ron Parker; adrian@olddog.co.uk; 'Dave = Dolson' > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; > > 'James N Guichard'; 'Fabricio Ferraz' > > Subject: Re: [sfc] NSH Service Index Decrement > > > > I was commenting, in personal hat, about the issue of whether there > > was some sort of problem with the impact of the current description on > > SI=3D1 packets arriving at an SF. It seems to me that your example > > shows that such an effect is sometimes useul. > > It will also sometimes produce packet drops by the SFF, when the SF > > does not terminate the packet. Okay, so be it. > > It is not even clear there is anything, in Adrian's phrase, to paint > > red here. > > > > Yours, > > Joel > > > > On 2/11/17 12:59 PM, Ron Parker wrote: > > > Hi, Joel. > > > > > > Does your comment pertain to my somewhat off topic question which > > > was > > related to one of Adrian's tangential issues, or to Adrian's original > > SF=3D1 > topic? > > > > > > Thanks. > > > > > > Ron > > > > > > > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > > Sent: Saturday, February 11, 2017 12:31 PM > > > To: Ron Parker >; > > > adrian@olddog.co.uk; > > 'Dave Dolson' > > > > Cc: 'Eric C Rosen' >; '= Dolganow, Andrew (Nokia - SG)' > > >; sfc@ietf= .org; 'James N Guichard' > > >; 'Fab= ricio Ferraz' > > > > > > Subject: Re: [sfc] NSH Service Index Decrement > > > > > > Personally, what you describe sounds like a quite reasonable case > > > where a > > packet arrive at the SF with an SI of 1 will produce exactly the > > desired > behavior. > > > > > > Which suggests, to my limited view, that the current text works fine. > > > > > > Yours, > > > Joel > > > > > > On 2/11/17 11:55 AM, Ron Parker wrote: > > >> Hi, Adrian. > > >> > > >> Not the original topic, per se, but wrt your comment: > > >> > > >> * On the other hand, we appear to be clear about an SF that strips > > >> the NSH > > and forwards the traffic as native : this is currently forbidden. > > >> > > >> I'm wondering how to reconcile this to a transparent HTTP Proxy > > >> that does > not > > preserve the original source-IP? Does this mean that it is mandatory = for > such an > > SF to also be a classifier so it can self-classify its own related > > flows > (i.e., using its > > own visible IP addresses)? From SFF perspective, it would look like = all > packets > > on the access side are dropped in the upstream direction and injected > > by the > SF > > in the downstream direction. On the Internet side, it would look like= all > packets > > are injected by the SF in the upstream direction and dropped in the > > downstream direction. > > >> > > >> Thanks for any clarification. > > >> > > >> Ron > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> Sent: Saturday, February 11, 2017 11:34 AM > > >> To: 'Dave Dolson' = >; 'Joel M. Halpern' > > >> >; Ron Parker > > > > >> Cc: 'Eric C Rosen' >; = 'Dolganow, Andrew (Nokia - > > >> SG)' >; = sfc@ietf.org; 'James N Guichard' > > >> >; '= Fabricio Ferraz' > > >> > > > >> Subject: RE: [sfc] NSH Service Index Decrement > > >> > > >> I hate to do my impersonation of Eric, but... > > >> > > >> "On the wire" is the crunch. > > >> > > >> Some have said that there must be no visible difference between the > > >> three > > case: > > >> - on the wire between SFF and SF > > >> - on the wire between SF and SFF > > >> - on the wire between SFF and SFF > > >> > > >> If this holds then you are correct that sending SI=3D1 in the first > > >> case > requires > > the SF to do more than a simple decrement (although decrement and > > discard is hardly painful). And it means that SI=3D1 is a dubious value= in an SFP. > > >> > > >> On the other hand, we appear to be clear about an SF that strips > > >> the NSH > and > > forwards the traffic as native : this is currently forbidden. So there > > is no alternative for an SF receiving SI=3D1 except to discard the pack= et. > > >> > > >> Now, does that mean that an SFF should never send a packet with > > >> SI=3D1? Well, > > possibly it is OK for a few specialist SFs intended to sit at the end > > of the > chain and > > be a bit bucket with analysis. But, for most SFs there would be no poin= t. > > >> > > >> Maybe (just maybe) we should stop letting the tail wag the dog! > > >> That is, > let's > > decide on the functional behavior we want to see and then design the > > protocol to match. > > >> > > >> Adrian > > >> > > >>> -----Original Message----- > > >>> From: Dave Dolson [mailto:ddolson@sandvine.com] > > >>> Sent: 10 February 2017 22:26 > > >>> To: adrian@olddog.co.uk; 'Joel M. Halpe= rn'; 'Ron Parker' > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; > > >>> 'James N Guichard'; 'Fabricio Ferraz' > > >>> Subject: RE: [sfc] NSH Service Index Decrement > > >>> > > >>> Adrian, > > >>> I think I agree with everything you said. > > >>> But you did not suggest whether or not you think that SI=3D0 should > > >>> be valid on > > >> the > > >>> wire. > > >>> I'm saying it could work, if the next hop is a path terminus. > > >>> > > >>> If I understand Joel correctly, he says we shouldn't send SI=3D0 i= n > > >>> case the > > >> next > > >>> hop blindly decrements it. > > >>> --> this seems to mean SI=3D1 cannot be used except at the terminus > > >>> --> or when the > > >>> SF is expected to drop all packets. > > >>> So I think this is an unnecessary seat belt, trying to anticipate > > >>> bugs in > > >> down- > > >>> stream devices. > > >>> > > >>> I realize the current language has been there a long time, and if > > >>> it is > > >> important to > > >>> anyone then it should remain. > > >>> Nonetheless, I think devices could safely handle SI=3D0 on the wire > > >>> without breaking anything. > > >>> > > >>> But I'm not pushing for a change, since the current behavior seems > > >>> important > > >> to > > >>> some. > > >>> > > >>> -Dave > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: sfc [mailto:sfc-bounces@ietf.org= ] On Behalf Of Adrian Farrel > > >>> Sent: Friday, February 10, 2017 9:16 AM > > >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org; > > >>> 'James N Guichard'; 'Fabricio Ferraz' > > >>> Subject: Re: [sfc] NSH Service Index Decrement > > >>> > > >>> Oh, you finally pushed me into this discussion, Dave. > > >>> > > >>> We're building a protocol. with a protocol, you cannot (must not) > > >>> assume good behavior from your neighbor. > > >>> > > >>> So if the SF touches the SI (which it does) we must define the > > >>> edge > > >> conditions. > > >>> If it is the SF's job to decrement the SI, then we must also > > >>> define what it > > >> does > > >>> when SI=3D0 (otherwise, it will set SI to 0-1). > > >>> If the SF is not allowed to decrement the SI below zero (which > > >>> makes > > >>> sense) we must define what it must do. > > >>> Since SFs are allowed to drop packets (indeed that is one of their > > >>> main jobs > > >> ;-) > > >>> then this would be fine. > > >>> All that would be left is to define whether they apply the test > > >>> before or > > >> after > > >>> normal processing. > > >>> > > >>> As an aside, I agree with Don that TTL helps relax this a little, > > >>> but does not get us all the way there. > > >>> > > >>> Cheers, > > >>> Adrian > > >>> > > >>>> -----Original Message----- > > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > >>>> Sent: 09 February 2017 21:00 > > >>>> To: Joel M. Halpern; Ron Parker > > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C > > >>>> Rosen; Dolganow, Andrew (Nokia - SG) > > >>>> Subject: Re: [sfc] NSH Service Index Decrement > > >>>> > > >>>> Discussing misconfigured SFFs is a straw-man argument. Once one > > >>>> starts > > >> trying > > >>> to > > >>>> anticipate down-stream devices being misconfigured, one can > > >>>> invent a lot of > > >>> silly > > >>>> requirements. > > >>>> > > >>>> >From an aesthetic point of view, I think it's bad that there are > > >>>>> two SI > > >>> values (0 > > >>>> and 1) that cannot be used. > > >>>> > > >>>> The real requirement, IMO, is that no device decrements 0 and > > >>>> forwards > > NSH. > > >>>> Since only SFs decrement SI, only SFs need to do this check. > > >>>> > > >>>> And any discussion about buggy SFs... well there is a lot of bad > > >>>> stuff that > > >>> bugs can > > >>>> cause. > > >>>> > > >>>> > > >>>> > > >>>> -----Original Message----- > > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > >>>> Sent: Thursday, February 09, 2017 2:54 PM > > >>>> To: Ron Parker; Dave Dolson > > >>>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, And= rew (Nokia - SG); > > >>>> James N > > >>> Guichard; > > >>>> Fabricio Ferraz > > >>>> Subject: Re: [sfc] NSH Service Index Decrement > > >>>> > > >>>> From my perspective as an individual participant in this work, > > >>>> declaring that 0 must be dropped is a matter of robustness. > > >>>> > > >>>> if we allow 0 to be processed for exit at an SFF, then a > > >>>> mis-configured SFF could easily continue processing such a packet. > > >>>> Now, it is true that TTL will eventually drop it, but that is an > expensive > > fallback. > > >>>> > > >>>> More importantly, presumably the next entitiy down the incorrect > > >>>> path would drop it for a 255 SI. But at that point we are > > >>>> getting the error in the wrong place, making it harder to diagnose= and > repair. > > >>>> > > >>>> Yours, > > >>>> Joel > > >>>> > > >>>> On 2/9/17 12:42 PM, Ron Parker wrote: > > >>>>> agree. > > >>>>> > > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson > > >>>>> >> wrote= : > > >>>>> > > >>>>>> I'm not clear on why this is broken, or why this restriction is = made. > > >>>>>> > > >>>>>> I agree it should not be sent to an SF, but an SFF could map an > > >>>>>> SI of zero into a path termination. > > >>>>>> > > >>>>>> I.e., the last SF in a path could decrement SI from 1 to 0, and > > >>>>>> the SFF could then terminate the chain. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N > > >>>>>> Guichard > > >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Not exactly. Section 3.3 specifies "The value zero for SI is > > >>>>>> not valid and indicates a broken SFC or malfunctioning SF" .. > > >>>>>> In other words an SF should never receive an NSH packet with SI = =3D 0. > > >>>>>> Note that if this happened then either a) a classifier set the > > >>>>>> SI incorrectly, or b) a re-classifier set the SI incorrectly, > > >>>>>> or c) an upstream SF set the SI incorrectly; all of these cases > > >>>>>> should be caught by the SFF whose job it is to discard NSH > > >>>>>> packets with SI =3D > 0. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Jim > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM > > >>>>>> *To:* James N Guichard > > >>>>>> >>; Dolganow, Andrew (Nokia > > >>>>>> - > > >>>>>> SG) > > >>>>>> >>; > > >>>> Dave > > >>>>>> Dolson >>; > > >>>>>> Eric C Rosen >>; > > >>>>>> sfc@ietf.org > > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Hi Jim, > > >>>>>> > > >>>>>> Thanks. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> One more question about the SI. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Section 3 states that: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Service Index (SI): provides location within the SFP. The > > >>>>>> initial classifier MUST set the appropriate SI value for a > > >>>>>> given classification result. The initial SI value SHOULD default= to 255. > > >>>>>> However, the classifier MUST allow configuration of other SI val= ues. > > >>>>>> > > >>>>>> Service Index MUST be decremented by Service Functions or by > > >>>>>> SFC Proxy nodes after performing required services and the new > > >>>>>> decremented SI value MUST be used in the egress NSH packet. > > >>>>>> > > >>>>>> The initial Classifier MUST send the packet to the first SFF in > > >>>>>> the identified SFP for forwarding along an SFP. > > >>>>>> > > >>>>>> If re-classification occurs, and that re-classification results > > >>>>>> in a new SPI, the (re)classifier is, in effect, the initial > > >>>>>> classifier for the resultant SPI. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Thus: > > >>>>>> > > >>>>>> a) Initial SI value should be 255 but other values can be > > >>>>>> configured by the classifier. > > >>>>>> > > >>>>>> b) SF decrements the SI value on the egress NSH packet > > >>>>>> > > >>>>>> c) If re-classification occurs with new SPI, the re-classi= fier > > >>>>>> is the initial classifier, so by a), SI should be again 255 or > > >>>>>> other value > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> So any SI value can be receive by an SF, even 1 or 0 because: > > >>>>>> > > >>>>>> =E8If SI=3D1 and there is no re-classification, the egress NSH w= ill > > >>>>>> have SI=3D0 > > >>>>>> > > >>>>>> =E8If SI=3D0 and there is re-classification with new SPI, the > > >>>>>> egress NSH will have a new SPI and a SI=3D 255 or other value, a= s stated in > a). > > >>>>>> > > >>>>>> =E8If SI=3D0 and there is no re-classification the SF should > > >>>>>> discard the packet > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Also an SFF should forward/handle packets with NSH with SI=3D1 o= r SI=3D0. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Do you agree? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *James N > > >>>>>> Guichard > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Hi Fabricio, > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Welcome! > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Yes, removal of NSH is the responsibility of an SFF or a > > >>>>>> re-classifier (section 4, bullet point 1 lays this out). With > > >>>>>> the current architecture the SF does not care what SI value it > > >>>>>> gets, it just needs to worry about decrementing it, and leave > > >>>>>> it up to the SFF to evaluate the SI value and associated action. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Jim > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt] > > >>>>>> *Sent:* Thursday, February 09, 2017 7:13 AM > > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) > > >>>>>> >>; Dave Dolson > > >>>> > > >>>>>> >>; Eri= c C Rosen > > >>>>>> >>; James N > > >>>>>> Guichard > > >>> >>; > > >>>>>> sfc@ietf.org > > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Hi all, > > >>>>>> > > >>>>>> I'm new here (just read the draft last week) but according to > > >>>>>> chapter > > >>>>>> 4 (check figure 8 for example), an SF is not allowed to insert > > >>>>>> or remove NSH. The removal of NSH is reponsability of the SSF, r= ight? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Figure 8 maps each of the four actions above to the > > >>>>>> components in the > > >>>>>> > > >>>>>> SFC architecture that can perform it. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> +---------------+------------------+-------+----------------+---------+ > > >>>>>> > > >>>>>> | | Insert |Select | Update |Ser= vice | > > >>>>>> > > >>>>>> | | or remove NSH |Service| NSH |pol= icy | > > >>>>>> > > >>>>>> | | |Function| |selection| > > >>>>>> > > >>>>>> | Component +--------+--------+Path +----------------+ | > > >>>>>> > > >>>>>> | | | | | Dec. |Update | | > > >>>>>> > > >>>>>> | | Insert | Remove | |Service |Context| | > > >>>>>> > > >>>>>> | | | | | Index |Header | | > > >>>>>> > > >>>>>> +----------------+--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> | | + | + | | | + | | > > >>>>>> > > >>>>>> |Classifier | | | | | | | > > >>>>>> > > >>>>>> +--------------- > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> |Service Function| | + | + | | | | > > >>>>>> > > >>>>>> |Forwarder(SFF) | | | | | | | > > >>>>>> > > >>>>>> +--------------- > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> |Service | | | | + | + | = + | > > >>>>>> > > >>>>>> |Function (SF) | | | | | | | > > >>>>>> > > >>>>>> +--------------- > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> |SFC Proxy | + | + | | + | | | > > >>>>>> > > >>>>>> +----------------+--------+--------+-------+--------+-------+---------+ > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Figure 8: NSH Action and Role Mapping > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> An SF could receive an NSH packet with an SI of 1, and > > >>>>>> reclassify it to a different SPI and SI, right? So when a SF > > >>>>>> receives a NSH packet with SI =3D 1 that does not necessarily me= ans a > non valid packet. > > >>>>>> > > >>>>>> And that can even work for SI=3D0, since you decrement the SI in > > >>>>>> the > > >> egress. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Fabricio > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > > >>>>>> *Dolganow, Andrew (Nokia - SG) > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; sfc@ietf.org<= mailto:sfc@ietf.org> > > >>>>>> > > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> I assumed that if we get value 1 we process then forward > > >>>>>> without NSH header (i.e.) this is the last SF processing. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> So with that assumption, a more explicit text would be: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > >>>>>> decrement the SI by 1 after performing all required local > > >>>>>> processing and before forwarding the packet to the next SFF. If > > >>>>>> the resulting SI is 0, the SF MUST remove the NSH header before > > forwarding the packet. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Andrew > > >>>>>> > > >>>>>> *From: *sfc > > >>>>>> >> on b= ehalf of Dave Dolson > > >>>>>> > > >>>> >> > > >>>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM > > >>>>>> *To: *Eric Rosen > > >>>>>> >>, James N= Guichard > > >>>>>> > > >>>>>> >>, "sfc@ietf.org > > >>>>>> >" >> > > >>>>>> *Subject: *Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Eric, > > >>>>>> > > >>>>>> I was never quite happy with the outcome that neither 0 nor 1 > > >>>>>> is a valid SI. > > >>>>>> > > >>>>>> (Because if received with value of 1, it is decremented and > > >>>>>> discarded.) > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> It seems to waste an index value. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> I guess I'm interested to know if that is important to other > > >>>>>> implementers, or if that was even the intention? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -Dave > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric C > > >>>>>> Rosen > > >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM > > >>>>>> *To:* James N Guichard; sfc@ietf.org > > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: > > >>>>>> > > >>>>>> A request was made to be more specific and update the text as > follows: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> "Service index MUST be decremented *by a value of 1* by Service > > >>>>>> Functions or by SFC Proxy nodes after performing required servic= es ." > > >>>>>> > > >>>>>> > > >>>>>> A couple of observations: > > >>>>>> > > >>>>>> - The term "SFC Proxy node" is not defined in either the NSH > > >>>>>> draft or in RFC 7665. I think the intention here is to say > > >>>>>> "SFC > Proxy". > > >>>>>> > > >>>>>> - Is the intention that the SI remain unchanged while the SF is > > >>>>>> operating on the packet, or is the intention only that the SI > > >>>>>> be decremented before the packet is delivered by the SF or SFC > > >>>>>> Proxy to an SFF? > > >>>>>> > > >>>>>> I'd suggest either: > > >>>>>> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > >>>>>> decrement the SI by 1 before delivering the packet to the next S= FF" > > >>>>>> > > >>>>>> or > > >>>>>> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated packet MUST > > >>>>>> decrement the SI by 1 before delivering the packet to the next > > >>>>>> SFF, but not until the SF has finished all its other processing > > >>>>>> of the > > packet" > > >>>>>> > > >>>>>> depending upon which is intended. > > >>>>>> > > >>>>>> I think an implication of these procedures is that an SI value > > >>>>>> of > > >>>>>> 1 is not valid. If an SF gets an NSH packet with an SI of 1, > > >>>>>> the SF will decrement the SI (setting it to 0), send the packet > > >>>>>> to an SFF, and the SFF will discard it, because 0 is an invalid > > >>>>>> SI value. Is that the intention? > > >>>>>> > > >>>>>> The draft makes it clear (well, sort of) that an SFF should > > >>>>>> discard a packet with an SI of 0, but does not seem to say that > > >>>>>> an SF or SFC Proxy should discard a packet it receives with an > > >>>>>> SI of 0. It would probably be a good idea to say that. > > >>>>>> > > >>>>>> Some text in the draft (e.g., section 7.1) states than an SFF > > >>>>>> should discard a packet with an SI of zero, but other text in > > >>>>>> the draft (e.g., section 3.3) only says that an SFF should log > > >>>>>> an error if it sees an SI of zero. It's probably best to > > >>>>>> change the text in 3.3. to say "SHOULD generate an error/log > > >>>>>> message and MUST discard the packet", or something similar. > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> 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 > > >>> > > >>> _______________________________________________ > > >>> 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 --_000_A2A658B1CB8B40799F2828D48A7B2126affirmednetworkscom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jim,

I also consider the (re-)classifier to also make (an initial) forwardi= ng decision based on NSH.  

   Ron

On Feb 12, 2017, at 9:07 AM, Jim Guichard <jguichard1966@gmail.com> wrote:

Hi Adrian,

The point is an SFF does not need to distinguish between receipt of a = packet from an SF or SFF; the suggested text is relevant to a device that f= orwards based on NSH and in this architecture only an SFF does that.

Jim
On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel <adrian@olddog.co.uk> wrote:
Thanks Jim,



Your text works for me although I would prefer to delete the commentary abo= ut a

"broken SFC" as a specific example of how this might happen that = is not the only

case (for example, a broken reclassifier can also cause this).



So, can we settle on



"Packets received at an SFF with an SI of zero MUST be discarded and t= he SFF

SHOULD generate an error/log message."



BTW, I said

>> Then (of course) it is also OK for an SFF to receive SI=3D0, but I= think the

existing

>> "discard" text covers that case.

and you replied

> from an SF yes but not from another SFF.

and that (of course) has been a point of entertainment for some while.

Since an SFF cannot tell the difference between a packet received from an S= FF

and one from an SF we must document all cases alike.



Fortunately, we're able to do so for this instance.



A









> -----Original Message-----

> From: James N Guichard [mailto:james.n.guichard@huawei.com]

> Sent: 12 February 2017 00:58

> To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker'

> Cc: sfc@ietf.org

> Subject: RE: [sfc] NSH Service Index Decrement

>

> Hi Adrian,

>

> Inline (hat off opinion) ..

>

> -----Original Message-----

> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Far= rel

> Sent: Saturday, February 11, 2017 5:36 PM

> To: 'Joel M. Halpern' <jmh@joelhalpern.com>; 'Ron Parker'<= br class=3D"gmail_msg">
> <Ron_Parker@affirmednetworks.com>

> Cc: sfc@ietf.org

> Subject: Re: [sfc] NSH Service Index Decrement

>

> Joel,

>

> The -10 version of NSH says

>

>    The

>    value zero for SI is not valid and indicates a broken SFC= or

>    malfunctioning SF.

>

> Jim> the above text is perhaps what is causing some confusion as it= implies an

SI

> of 0 from an SF is invalid. May I suggest the following text as a repl= acement

for

> the above sentence:

>

> "The value zero for SI indicates a broken SFC. Packets received a= t an SFF with

an

> SI of zero MUST be discarded and the SFF SHOULD generate an error/log<= br class=3D"gmail_msg">
> message".

>

> You are saying that the latter of these is not true.

> I can't tell whether the former is really true or, perhaps, represents= a

discard tail

> of an SFC where some (but not all) packets are reclassified per Ron.
>

> Like I said:

>

> > Let's clarify that it is OK for an SF to send a packet with SI=3D= 0

>

> Then (of course) it is also OK for an SFF to receive SI=3D0, but I thi= nk the

existing

> "discard" text covers that case.

>

> Jim> from an SF yes but not from another SFF. However, in either ca= se, a

lookup

> on <SPI><SI=3D0> should cause the SFF to discard the packe= t. Hopefully my above

> suggested text clarifies that.

>

> Adrian

>

> > -----Original Message-----

> > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]

> > Sent: 11 February 2017 18:08

> > To: Ron Parker; adrian@olddog.co.uk; 'Dave Dolson'

> > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; sfc@ietf.org;

> > 'James N Guichard'; 'Fabricio Ferraz'

> > Subject: Re: [sfc] NSH Service Index Decrement

> >

> > I was commenting, in personal hat, about the issue of whether the= re

> > was some sort of problem with the impact of the current descripti= on on

> > SI=3D1 packets arriving at an SF.  It seems to me that your = example

> > shows that such an effect is sometimes useul.

> > It will also sometimes produce packet drops by the SFF, when the = SF

> > does not terminate the packet.  Okay, so be it.

> > It is not even clear there is anything, in Adrian's phrase, to pa= int

> > red here.

> >

> > Yours,

> > Joel

> >

> > On 2/11/17 12:59 PM, Ron Parker wrote:

> > > Hi, Joel.

> > >

> > > Does your comment pertain to my somewhat off topic question = which

> > > was

> > related to one of Adrian's tangential issues, or to Adrian's orig= inal

> > SF=3D1

> topic?

> > >

> > > Thanks.

> > >

> > >    Ron

> > >

> > >

> > > -----Original Message-----

> > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]

> > > Sent: Saturday, February 11, 2017 12:31 PM

> > > To: Ron Parker <Ron_Parker@affirmednetworks= .com>;

> > > adrian@olddog.co.uk;

> > 'Dave Dolson' <ddolson@sandvine.com>

> > > Cc: 'Eric C Rosen' <erosen@juniper.net>; 'Dolgano= w, Andrew (Nokia - SG)'

> > <andrew.dolganow@nokia.com>; sfc@i= etf.org; 'James N Guichard'

> > <james.n.guichard@huawei.com>; 'Fabricio Ferr= az'

> > <fabricio-ferraz@telecom.pt>

> > > Subject: Re: [sfc] NSH Service Index Decrement

> > >

> > > Personally, what you describe sounds like a quite reasonable= case

> > > where a

> > packet arrive at the SF with an SI of 1 will produce exactly the<= br class=3D"gmail_msg">
> > desired

> behavior.

> > >

> > > Which suggests, to my limited view, that the current text wo= rks fine.

> > >

> > > Yours,

> > > Joel

> > >

> > > On 2/11/17 11:55 AM, Ron Parker wrote:

> > >> Hi, Adrian.

> > >>

> > >> Not the original topic, per se, but wrt your comment:
> > >>

> > >> * On the other hand, we appear to be clear about an SF t= hat strips

> > >> the NSH

> > and forwards the traffic as native : this is currently forbidden.=

> > >>

> > >> I'm wondering how to reconcile this to a transparent HTT= P Proxy

> > >> that does

> not

> > preserve the original source-IP?   Does this mean that = it is mandatory for

> such an

> > SF to also be a classifier so it can self-classify its own relate= d

> > flows

> (i.e., using its

> > own visible IP addresses)?    From SFF perspective, it = would look like all

> packets

> > on the access side are dropped in the upstream direction and inje= cted

> > by the

> SF

> > in the downstream direction.   On the Internet side, it= would look like all

> packets

> > are injected by the SF in the upstream direction and dropped in t= he

> > downstream direction.

> > >>

> > >> Thanks for any clarification.

> > >>

> > >>    Ron

> > >>

> > >>

> > >>

> > >> -----Original Message-----

> > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > >> Sent: Saturday, February 11, 2017 11:34 AM

> > >> To: 'Dave Dolson' <ddolson@sandvine.com>; '= Joel M. Halpern'

> > >> <jmh@joelhalpern.com>; Ron Parker

> <Ron_Parker@affirmednetworks.com>

> > >> Cc: 'Eric C Rosen' <erosen@juniper.net>; 'Dol= ganow, Andrew (Nokia -

> > >> SG)' <andrew.dolganow@nokia.com>; sfc@i= etf.org; 'James N Guichard'

> > >> <james.n.guichard@huawei.com>; 'Fabr= icio Ferraz'

> > >> <fabricio-ferraz@telecom.pt>

> > >> Subject: RE: [sfc] NSH Service Index Decrement

> > >>

> > >> I hate to do my impersonation of Eric, but...

> > >>

> > >> "On the wire" is the crunch.

> > >>

> > >> Some have said that there must be no visible difference = between the

> > >> three

> > case:

> > >> - on the wire between SFF and SF

> > >> - on the wire between SF and SFF

> > >> - on the wire between SFF and SFF

> > >>

> > >> If this holds then you are correct that sending SI=3D1 i= n the first

> > >> case

> requires

> > the SF to do more than a simple decrement (although decrement and=

> > discard is hardly painful). And it means that SI=3D1 is a dubious= value in an

SFP.

> > >>

> > >> On the other hand, we appear to be clear about an SF tha= t strips

> > >> the NSH

> and

> > forwards the traffic as native : this is currently forbidden. So = there

> > is no alternative for an SF receiving SI=3D1 except to discard th= e packet.

> > >>

> > >> Now, does that mean that an SFF should never send a pack= et with

> > >> SI=3D1? Well,

> > possibly it is OK for a few specialist SFs intended to sit at the= end

> > of the

> chain and

> > be a bit bucket with analysis. But, for most SFs there would be n= o point.

> > >>

> > >> Maybe (just maybe) we should stop letting the tail wag t= he dog!

> > >> That is,

> let's

> > decide on the functional behavior we want to see and then design = the

> > protocol to match.

> > >>

> > >> Adrian

> > >>

> > >>> -----Original Message-----

> > >>> From: Dave Dolson [mailto:ddolson@sandvine.com]

> > >>> Sent: 10 February 2017 22:26

> > >>> To: adrian@olddog.co.uk; 'Joel M. Halpern'; 'Ron Parker'

> > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)';= sfc@ietf.org;

> > >>> 'James N Guichard'; 'Fabricio Ferraz'

> > >>> Subject: RE: [sfc] NSH Service Index Decrement

> > >>>

> > >>> Adrian,

> > >>> I think I agree with everything you said.

> > >>> But you did not suggest whether or not you think tha= t SI=3D0 should

> > >>> be valid on

> > >> the

> > >>> wire.

> > >>> I'm saying it could work, if the next hop is a path = terminus.

> > >>>

> > >>> If I understand Joel correctly, he says we shouldn't= send SI=3D0  in

> > >>> case the

> > >> next

> > >>> hop blindly decrements it.

> > >>> --> this seems to mean SI=3D1 cannot be used exce= pt at the terminus

> > >>> --> or when the

> > >>> SF is expected to drop all packets.

> > >>> So I think this is an unnecessary seat belt, trying = to anticipate

> > >>> bugs in

> > >> down-

> > >>> stream devices.

> > >>>

> > >>> I realize the current language has been there a long= time, and if

> > >>> it is

> > >> important to

> > >>> anyone then it should remain.

> > >>> Nonetheless, I think devices could safely handle SI= =3D0 on the wire

> > >>> without breaking anything.

> > >>>

> > >>> But I'm not pushing for a change, since the current = behavior seems

> > >>> important

> > >> to

> > >>> some.

> > >>>

> > >>> -Dave

> > >>>

> > >>>

> > >>> -----Original Message-----

> > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Be= half Of Adrian Farrel

> > >>> Sent: Friday, February 10, 2017 9:16 AM

> > >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker'

> > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)';= sfc@ietf.org;

> > >>> 'James N Guichard'; 'Fabricio Ferraz'

> > >>> Subject: Re: [sfc] NSH Service Index Decrement

> > >>>

> > >>> Oh, you finally pushed me into this discussion, Dave= .

> > >>>

> > >>> We're building a protocol. with a protocol, you cann= ot (must not)

> > >>> assume good behavior from your neighbor.

> > >>>

> > >>> So if the SF touches the SI (which it does) we must = define the

> > >>> edge

> > >> conditions.

> > >>> If it is the SF's job to decrement the SI, then we m= ust also

> > >>> define what it

> > >> does

> > >>> when SI=3D0 (otherwise, it will set SI to 0-1).

> > >>> If the SF is not allowed to decrement the SI below z= ero (which

> > >>> makes

> > >>> sense) we must define what it must do.

> > >>> Since SFs are allowed to drop packets (indeed that i= s one of their

> > >>> main jobs

> > >> ;-)

> > >>> then this would be fine.

> > >>> All that would be left is to define whether they app= ly the test

> > >>> before or

> > >> after

> > >>> normal processing.

> > >>>

> > >>> As an aside, I agree with Don that TTL helps relax t= his a little,

> > >>> but does not get us all the way there.

> > >>>

> > >>> Cheers,

> > >>> Adrian

> > >>>

> > >>>> -----Original Message-----

> > >>>> From: sfc [mailto:sfc-bounces@ietf.org] O= n Behalf Of Dave Dolson

> > >>>> Sent: 09 February 2017 21:00

> > >>>> To: Joel M. Halpern; Ron Parker

> > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org; Eric C

> > >>>> Rosen; Dolganow, Andrew (Nokia - SG)

> > >>>> Subject: Re: [sfc] NSH Service Index Decrement
> > >>>>

> > >>>> Discussing misconfigured SFFs is a straw-man arg= ument. Once one

> > >>>> starts

> > >> trying

> > >>> to

> > >>>> anticipate down-stream devices being misconfigur= ed, one can

> > >>>> invent a lot of

> > >>> silly

> > >>>> requirements.

> > >>>>

> > >>>> >From an aesthetic point of view, I think it'= s bad that there are

> > >>>>> two SI

> > >>> values (0

> > >>>> and 1) that cannot be used.

> > >>>>

> > >>>> The real requirement, IMO, is that no device dec= rements 0 and

> > >>>> forwards

> > NSH.

> > >>>> Since only SFs decrement SI, only SFs need to do= this check.

> > >>>>

> > >>>> And any discussion about buggy SFs... well there= is a lot of bad

> > >>>> stuff that

> > >>> bugs can

> > >>>> cause.

> > >>>>

> > >>>>

> > >>>>

> > >>>> -----Original Message-----

> > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.= com]

> > >>>> Sent: Thursday, February 09, 2017 2:54 PM

> > >>>> To: Ron Parker; Dave Dolson

> > >>>> Cc: Eric C Rosen; sfc@ietf.org; Dolganow, Andrew (Nokia - SG);

> > >>>> James N

> > >>> Guichard;

> > >>>> Fabricio Ferraz

> > >>>> Subject: Re: [sfc] NSH Service Index Decrement
> > >>>>

> > >>>>  From my perspective as an individual parti= cipant in this work,

> > >>>> declaring that 0 must be dropped is a matter of = robustness.

> > >>>>

> > >>>> if we allow 0 to be processed for exit at an SFF= , then a

> > >>>> mis-configured SFF could easily continue process= ing such a packet.

> > >>>> Now, it is true that TTL will eventually drop it= , but that is an

> expensive

> > fallback.

> > >>>>

> > >>>> More importantly, presumably the next entitiy do= wn the incorrect

> > >>>> path would drop it for a 255 SI.  But at th= at point we are

> > >>>> getting the error in the wrong place, making it = harder to diagnose and

> repair.

> > >>>>

> > >>>> Yours,

> > >>>> Joel

> > >>>>

> > >>>> On 2/9/17 12:42 PM, Ron Parker wrote:

> > >>>>> agree.

> > >>>>>

> > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson <= ;ddolson@sandvine.com

> > >>>>> <mailto:ddolson@sandvine.com>&g= t; wrote:

> > >>>>>

> > >>>>>> I'm not clear on why this is broken, or = why this restriction is made.

> > >>>>>>

> > >>>>>> I agree it should not be sent to an SF, = but an SFF could map an

> > >>>>>> SI of zero into a path termination.

> > >>>>>>

> > >>>>>> I.e., the last SF in a path could decrem= ent SI from 1 to 0, and

> > >>>>>> the SFF could then terminate the chain.<= br class=3D"gmail_msg">
> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.o= rg] *On Behalf Of *James N

> > >>>>>> Guichard

> > >>>>>> *Sent:* Thursday, February 09, 2017 12:0= 2 PM

> > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew = (Nokia - SG); Dave

> > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org <mailto:sfc@ietf.org>

> > >>>>>> *Subject:* Re: [sfc] NSH Service Index D= ecrement

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Not exactly. Section 3.3 specifies "= ;The value zero for SI is

> > >>>>>> not valid and indicates a broken SFC or = malfunctioning SF" ..

> > >>>>>> In other words an SF should never receiv= e an NSH packet with SI =3D 0.

> > >>>>>> Note that if this happened then either a= ) a classifier set the

> > >>>>>> SI incorrectly, or b) a re-classifier se= t the SI incorrectly,

> > >>>>>> or c) an upstream SF set the SI incorrec= tly; all of these cases

> > >>>>>> should be caught by the SFF whose job it= is to discard NSH

> > >>>>>> packets with SI =3D

> 0.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Jim

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt]

> > >>>>>> *Sent:* Thursday, February 09, 2017 11:4= 9 AM

> > >>>>>> *To:* James N Guichard <jam= es.n.guichard@huawei.com

> > >>>>>> <mailto:james.n.guichard@hu= awei.com>>; Dolganow, Andrew (Nokia

> > >>>>>> -

> > >>>>>> SG) <andrew.dolganow@nokia.co= m

> > >>>>>> <mailto:andrew.dolganow@nokia= .com>>;

> > >>>> Dave

> > >>>>>> Dolson <ddolson@sandvine.com &= lt;mailto:ddolson@sandvine.com>>;

> > >>>>>> Eric C Rosen <erosen@juniper.net= <mailto:erosen@juniper.net>>;

> > >>>>>> sfc@ietf.org <mailto:sfc@ietf.org>
> > >>>>>> *Subject:* RE: [sfc] NSH Service Index D= ecrement

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Hi Jim,

> > >>>>>>

> > >>>>>> Thanks.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> One more question about the SI.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Section 3 states that:

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Service Index (SI): provides location wi= thin the SFP. The

> > >>>>>> initial classifier MUST set the appropri= ate SI value for a

> > >>>>>> given classification result. The initial= SI value SHOULD default to

255.

> > >>>>>> However, the classifier MUST allow confi= guration of other SI values.

> > >>>>>>

> > >>>>>> Service Index MUST be decremented by Ser= vice Functions or by

> > >>>>>> SFC Proxy nodes after performing require= d services and the new

> > >>>>>> decremented SI value MUST be used in the= egress NSH packet.

> > >>>>>>

> > >>>>>> The initial Classifier MUST send the pac= ket to the first SFF in

> > >>>>>> the identified SFP for forwarding along = an SFP.

> > >>>>>>

> > >>>>>> If re-classification occurs, and that re= -classification results

> > >>>>>> in a new SPI, the (re)classifier is, in = effect, the initial

> > >>>>>> classifier for the resultant SPI.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Thus:

> > >>>>>>

> > >>>>>> a)      Initial SI value = should be 255 but other values can be

> > >>>>>> configured by the classifier.

> > >>>>>>

> > >>>>>> b)      SF decrements the= SI value on the egress NSH packet

> > >>>>>>

> > >>>>>> c)       If re-class= ification occurs with new SPI, the re-classifier

> > >>>>>> is the initial classifier, so by  a= ), SI should be again 255 or

> > >>>>>> other value

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> So any SI value can be receive by an SF,= even 1 or 0 because:

> > >>>>>>

> > >>>>>> =E8If SI=3D1 and there is no re-classifi= cation, the egress NSH will

> > >>>>>> have SI=3D0

> > >>>>>>

> > >>>>>> =E8If SI=3D0 and there is re-classificat= ion with new SPI, the

> > >>>>>> egress NSH will have a new SPI and a SI= =3D 255 or other value, as

stated in

> a).

> > >>>>>>

> > >>>>>> =E8If SI=3D0 and there is no re-classifi= cation the SF should

> > >>>>>> discard the packet

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Also an SFF should forward/handle packet= s with NSH with SI=3D1 or SI=3D0.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Do you agree?

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.o= rg] *On Behalf Of *James N

> > >>>>>> Guichard

> > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de = 2017 16:25

> > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew = (Nokia - SG); Dave

> > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org <mailto:sfc@ietf.org>

> > >>>>>> *Subject:* Re: [sfc] NSH Service Index D= ecrement

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Hi Fabricio,

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Welcome!

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Yes, removal of NSH is the responsibilit= y of an SFF or a

> > >>>>>> re-classifier (section 4, bullet point 1= lays this out). With

> > >>>>>> the current architecture the SF does not= care what SI value it

> > >>>>>> gets, it just needs to worry about decre= menting it, and leave

> > >>>>>> it up to the SFF to evaluate the SI valu= e and associated action.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Jim

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> *From:*Fabricio Ferraz [mailto:fabricio-ferraz@telecom.pt]

> > >>>>>> *Sent:* Thursday, February 09, 2017 7:13= AM

> > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) <= andrew.dolganow@nokia.com

> > >>>>>> <mailto:andrew.dolganow@nokia= .com>>; Dave Dolson

> > >>>> <ddolson@sandvine.com

> > >>>>>> <mailto:ddolson@sandvine.com&g= t;>; Eric C Rosen

> > >>>>>> <erosen@juniper.net <mailto:<= a href=3D"mailto:erosen@juniper.net" class=3D"gmail_msg" target=3D"_blank">= erosen@juniper.net>>; James N

> > >>>>>> Guichard <james.n.guichard@= huawei.com

> > >>> <mailto:james.n.guichard@huawei.com= >>;

> > >>>>>> sfc@ietf.org <mailto:sfc@ietf.org>
> > >>>>>> *Subject:* RE: [sfc] NSH Service Index D= ecrement

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Hi all,

> > >>>>>>

> > >>>>>> I'm new here (just read the draft last w= eek) but according to

> > >>>>>> chapter

> > >>>>>> 4 (check figure 8 for example), an SF is= not allowed to insert

> > >>>>>> or remove NSH. The removal of NSH is rep= onsability of the SSF, right?

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>   Figure 8 maps each of the fo= ur actions above to the

> > >>>>>> components in the

> > >>>>>>

> > >>>>>>    SFC architecture that can p= erform it.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

+---------------+------------------+-------+---------------= -+---------+

> > >>>>>>

> > >>>>>> |          &nbs= p;     |  Insert         |Select |&= nbsp;  Update       |Service

|

> > >>>>>>

> > >>>>>> |          &nbs= p;     |  or remove NSH  |Service|    NSH&nbs= p;        |policy

|

> > >>>>>>

> > >>>>>> |          &nbs= p;     |                &= nbsp;|Function|

|selection|

> > >>>>>>

> > >>>>>> | Component      +---= -----+--------+Path   +----------------+

|

> > >>>>>>

> > >>>>>> |          &nbs= p;     |        |        = |       | Dec.   |Update |

|

> > >>>>>>

> > >>>>>> |          &nbs= p;     | Insert | Remove |       |Service |Co= ntext|

|

> > >>>>>>

> > >>>>>> |          &nbs= p;     |        |        = |       | Index  |Header |

|

> > >>>>>>

> > >>>>>>

+----------------+--------+--------+-------+--------= 3;-------+---------+

> > >>>>>>

> > >>>>>> |          &nbs= p;     |   +    |   + =   |       |        |  &n= bsp;+   |

|

> > >>>>>>

> > >>>>>> |Classifier      |  =       |        |      &nb= sp;|        |       |

|

> > >>>>>>

> > >>>>>> +---------------

> > >>>>>> ++--------+--------+----= ---+--------+-------+---------+

> > >>>>>>

> > >>>>>> |Service Function|      &= nbsp; |   +    |  +    |  &= nbsp;     |       |

|

> > >>>>>>

> > >>>>>> |Forwarder(SFF)  |    &nb= sp;   |        |       | =       |       |

|

> > >>>>>>

> > >>>>>> +---------------

> > >>>>>> ++--------+--------+----= ---+--------+-------+---------+

> > >>>>>>

> > >>>>>> |Service        &nbs= p;|        |        |    =    |   +    |   +  &nb= sp;|   +

|

> > >>>>>>

> > >>>>>> |Function  (SF)  |   = ;     |        |       |&= nbsp;       |       |

|

> > >>>>>>

> > >>>>>> +---------------

> > >>>>>> ++--------+--------+----= ---+--------+-------+---------+

> > >>>>>>

> > >>>>>> |SFC Proxy       |&n= bsp;  +    |   +    |  &nbs= p;    |   +    |      &nbs= p;|

|

> > >>>>>>

> > >>>>>>

+----------------+--------+--------+-------+--------= 3;-------+---------+

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>           =         Figure 8: NSH Action and Role Mapping

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> An SF could receive an NSH packet with a= n SI of 1, and

> > >>>>>> reclassify it to a different SPI and SI,= right? So when a SF

> > >>>>>> receives a NSH packet with SI =3D 1 that= does not necessarily means a

> non valid packet.

> > >>>>>>

> > >>>>>> And that can even work for SI=3D0, since= you decrement the SI in

> > >>>>>> the

> > >> egress.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Fabricio

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.o= rg] *On Behalf Of

> > >>>>>> *Dolganow, Andrew (Nokia - SG)

> > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de = 2017 01:51

> > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N= Guichard; sfc@ietf.org

> > >>>>>> <mailto:sfc@ietf.org>

> > >>>>>> *Subject:* Re: [sfc] NSH Service Index D= ecrement

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> I assumed that if we get value 1 we proc= ess then forward

> > >>>>>> without NSH header (i.e.) this is the la= st SF processing.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> So with that assumption, a more explicit= text would be:

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> An SF or SFC Proxy receiving an NSH-enca= psulated packet MUST

> > >>>>>> decrement the SI by 1 after performing a= ll required local

> > >>>>>> processing and before forwarding the pac= ket to the next SFF. If

> > >>>>>> the resulting SI is 0, the SF MUST remov= e the NSH header before

> > forwarding the packet.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Andrew

> > >>>>>>

> > >>>>>> *From: *sfc <sfc-bounces@ietf.org<= /a>

> > >>>>>> <mailto:sfc-bounces@ietf.org&g= t;> on behalf of Dave Dolson

> > >>>>>> <ddolson@sandvine.com

> > >>>> <mailto:ddolson@sandvine.com>>
> > >>>>>> *Date: *Thursday, February 9, 2017 at 2:= 04 AM

> > >>>>>> *To: *Eric Rosen <erosen@juniper.net=

> > >>>>>> <mailto:erosen@juniper.net>&g= t;, James N Guichard

> > >>>>>> <james.n.guichard@huawei.co= m

> > >>>>>> <mailto:james.n.guichard@hu= awei.com>>, "sfc@ietf.org

> > >>>>>> <mailto:sfc@ietf.org>" <sfc@ietf= .org <mailto:sfc@ietf.org>>

> > >>>>>> *Subject: *Re: [sfc] NSH Service Index D= ecrement

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> Eric,

> > >>>>>>

> > >>>>>> I was never quite happy with the outcome= that neither 0 nor 1

> > >>>>>> is a valid SI.

> > >>>>>>

> > >>>>>> (Because if received with value of 1, it= is decremented and

> > >>>>>> discarded.)

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> It seems to waste an index value.

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> I guess I'm interested to know if that i= s important to other

> > >>>>>> implementers, or if that was even the in= tention?

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> -Dave

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.o= rg] *On Behalf Of *Eric C

> > >>>>>> Rosen

> > >>>>>> *Sent:* Wednesday, February 08, 2017 11:= 53 AM

> > >>>>>> *To:* James N Guichard; sfc@ietf.org <mailto:sfc@ietf.org>

> > >>>>>> *Subject:* Re: [sfc] NSH Service Index D= ecrement

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> On 2/7/2017 2:24 PM, James N Guichard wr= ote:

> > >>>>>>

> > >>>>>> A request was made to be more specific a= nd update the text as

> follows:

> > >>>>>>

> > >>>>>>

> > >>>>>>

> > >>>>>> "Service index MUST be decremented = *by a value of 1* by Service

> > >>>>>> Functions or by SFC Proxy nodes after pe= rforming required services ."

> > >>>>>>

> > >>>>>>

> > >>>>>> A couple of observations:

> > >>>>>>

> > >>>>>> - The term "SFC Proxy node" is= not defined in either the NSH

> > >>>>>> draft or in RFC 7665.  I think the = intention here is to say

> > >>>>>> "SFC

> Proxy".

> > >>>>>>

> > >>>>>> - Is the intention that the SI remain un= changed while the SF is

> > >>>>>> operating on the packet, or is the inten= tion only that the SI

> > >>>>>> be decremented before the packet is deli= vered by the SF or SFC

> > >>>>>> Proxy to an SFF?

> > >>>>>>

> > >>>>>> I'd suggest either:

> > >>>>>>

> > >>>>>> "An SF or SFC Proxy receiving an NS= H-encapsulated packet MUST

> > >>>>>> decrement the SI by 1 before delivering = the packet to the next SFF"

> > >>>>>>

> > >>>>>> or

> > >>>>>>

> > >>>>>> "An SF or SFC Proxy receiving an NS= H-encapsulated packet MUST

> > >>>>>> decrement the SI by 1 before delivering = the packet to the next

> > >>>>>> SFF, but not until the SF has finished a= ll its other processing

> > >>>>>> of the

> > packet"

> > >>>>>>

> > >>>>>> depending upon which is intended.

> > >>>>>>

> > >>>>>> I think an implication of these procedur= es is that an SI value

> > >>>>>> of

> > >>>>>> 1 is not valid.  If an SF gets an N= SH packet with an SI of 1,

> > >>>>>> the SF will decrement the SI (setting it= to 0), send the packet

> > >>>>>> to an SFF, and the SFF will discard it, = because 0 is an invalid

> > >>>>>> SI value.  Is that the intention?
> > >>>>>>

> > >>>>>> The draft makes it clear (well, sort of)= that an SFF should

> > >>>>>> discard a packet with an SI of 0, but do= es not seem to say that

> > >>>>>> an SF or SFC Proxy should discard a pack= et it receives with an

> > >>>>>> SI of 0.  It would probably be a go= od idea to say that.

> > >>>>>>

> > >>>>>> Some text in the draft (e.g., section 7.= 1) states than an SFF

> > >>>>>> should discard a packet with an SI of ze= ro, but other text in

> > >>>>>> the draft (e.g., section 3.3) only says = that an SFF should log

> > >>>>>> an error if it sees an SI of zero. = It's probably best to

> > >>>>>> change the text in 3.3. to say "SHO= ULD generate an error/log

> > >>>>>> message and MUST discard the packet"= ;, or something similar.

> > >>>>>>

> > >>>>>> ________________________________________= _______

> > >>>>>> sfc mailing list

> > >>>>>> sfc@ietf.org <mailto:sfc@ietf.org>
> > >>>>>> https://www.ietf.org/mailman/listinfo/sfc

> > >>>>>

> > >>>>>

> > >>>>> ____________________________________________= ___

> > >>>>> sfc mailing list

> > >>>>> sfc@ietf.org

> > >>>>> https://www.ietf.org/mailman/listinfo/sfc

> > >>>>>

> > >>>>

> > >>>> _______________________________________________<= br class=3D"gmail_msg">
> > >>>> 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



_______________________________________________

sfc mailing list

sfc@i= etf.org

https://www.ietf.org/mailman/listinfo/s= fc

--_000_A2A658B1CB8B40799F2828D48A7B2126affirmednetworkscom_-- From nobody Sun Feb 12 11:56:56 2017 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 8129F129B05 for ; Sun, 12 Feb 2017 11:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 DWdJKCcmbJNG for ; Sun, 12 Feb 2017 11:56:52 -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 3228F129B09 for ; Sun, 12 Feb 2017 11:56:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1B78C24099F; Sun, 12 Feb 2017 11:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1486929412; bh=EcCpeaSIUU+s27UN/KVxciuW4zsYehwZhlSQt+WDr34=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cJi8uLKKunsxAP1/ek/A/OoMlh4ZVqLkvTEOZMX/LWoDRMpdRSnBBK7g+BVVaquL4 mJMuhyYRjGrbnlZdY99Ij/VBQ1DASweXiZqU0LtnMMtCfpZl87egD4qPmNktrtmbIg I+X3dXq4Y2SrwuYcAT2rm2BiRxXG8n1whgc6Rs/U= 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 DD07D2406F2; Sun, 12 Feb 2017 11:56:50 -0800 (PST) To: Ron Parker , Jim Guichard References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> <0e0f01d2851b$d7323a10$8596ae30$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: <0ba5fd16-a4ab-c6db-6933-cbc519f153d7@joelhalpern.com> Date: Sun, 12 Feb 2017 14:56:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "adrian@olddog.co.uk" , "sfc@ietf.org" , James N Guichard Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:56:55 -0000 Ron, I am missing your point. There are a lot of ways to build a reclassifier. It can have a co-located SFF. The information that drives the new NSH header content can also specify the SFF to send the packet to. I suppose the reclassifier could do all of its job, then look up in a table (not one mandated by the spec) to decide where to sesnd the packet. However, any reclassifier which produces a packet with an SI of 0 is behaving pretty strangely. Since it is required to send the packet to an SFF, it is producing a packet knowing that the packet will be immediately dropped, and may produce an error message. Yours, Joel On 2/12/17 2:24 PM, Ron Parker wrote: > Jim, > > I also consider the (re-)classifier to also make (an initial) forwarding > decision based on NSH. > > Ron > > On Feb 12, 2017, at 9:07 AM, Jim Guichard > wrote: > >> Hi Adrian, >> >> The point is an SFF does not need to distinguish between receipt of a >> packet from an SF or SFF; the suggested text is relevant to a device >> that forwards based on NSH and in this architecture only an SFF does that. >> >> Jim >> On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel > > wrote: >> >> Thanks Jim, >> >> >> >> Your text works for me although I would prefer to delete the >> commentary about a >> >> "broken SFC" as a specific example of how this might happen that >> is not the only >> >> case (for example, a broken reclassifier can also cause this). >> >> >> >> So, can we settle on >> >> >> >> "Packets received at an SFF with an SI of zero MUST be discarded >> and the SFF >> >> SHOULD generate an error/log message." >> >> >> >> BTW, I said >> >> >> Then (of course) it is also OK for an SFF to receive SI=0, but >> I think the >> >> existing >> >> >> "discard" text covers that case. >> >> and you replied >> >> > from an SF yes but not from another SFF. >> >> and that (of course) has been a point of entertainment for some while. >> >> Since an SFF cannot tell the difference between a packet received >> from an SFF >> >> and one from an SF we must document all cases alike. >> >> >> >> Fortunately, we're able to do so for this instance. >> >> >> >> A >> >> >> >> >> >> >> >> >> >> > -----Original Message----- >> >> > From: James N Guichard [mailto:james.n.guichard@huawei.com >> ] >> >> > Sent: 12 February 2017 00:58 >> >> > To: adrian@olddog.co.uk ; 'Joel M. >> Halpern'; 'Ron Parker' >> >> > Cc: sfc@ietf.org >> >> > Subject: RE: [sfc] NSH Service Index Decrement >> >> > >> >> > Hi Adrian, >> >> > >> >> > Inline (hat off opinion) .. >> >> > >> >> > -----Original Message----- >> >> > From: sfc [mailto:sfc-bounces@ietf.org >> ] On Behalf Of Adrian Farrel >> >> > Sent: Saturday, February 11, 2017 5:36 PM >> >> > To: 'Joel M. Halpern' > >; 'Ron Parker' >> >> > > > >> >> > Cc: sfc@ietf.org >> >> > Subject: Re: [sfc] NSH Service Index Decrement >> >> > >> >> > Joel, >> >> > >> >> > The -10 version of NSH says >> >> > >> >> > The >> >> > value zero for SI is not valid and indicates a broken SFC or >> >> > malfunctioning SF. >> >> > >> >> > Jim> the above text is perhaps what is causing some confusion as >> it implies an >> >> SI >> >> > of 0 from an SF is invalid. May I suggest the following text as >> a replacement >> >> for >> >> > the above sentence: >> >> > >> >> > "The value zero for SI indicates a broken SFC. Packets received >> at an SFF with >> >> an >> >> > SI of zero MUST be discarded and the SFF SHOULD generate an >> error/log >> >> > message". >> >> > >> >> > You are saying that the latter of these is not true. >> >> > I can't tell whether the former is really true or, perhaps, >> represents a >> >> discard tail >> >> > of an SFC where some (but not all) packets are reclassified per Ron. >> >> > >> >> > Like I said: >> >> > >> >> > > Let's clarify that it is OK for an SF to send a packet with SI=0 >> >> > >> >> > Then (of course) it is also OK for an SFF to receive SI=0, but I >> think the >> >> existing >> >> > "discard" text covers that case. >> >> > >> >> > Jim> from an SF yes but not from another SFF. However, in either >> case, a >> >> lookup >> >> > on should cause the SFF to discard the packet. >> Hopefully my above >> >> > suggested text clarifies that. >> >> > >> >> > Adrian >> >> > >> >> > > -----Original Message----- >> >> > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com >> ] >> >> > > Sent: 11 February 2017 18:08 >> >> > > To: Ron Parker; adrian@olddog.co.uk >> ; 'Dave Dolson' >> >> > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; >> sfc@ietf.org ; >> >> > > 'James N Guichard'; 'Fabricio Ferraz' >> >> > > Subject: Re: [sfc] NSH Service Index Decrement >> >> > > >> >> > > I was commenting, in personal hat, about the issue of whether >> there >> >> > > was some sort of problem with the impact of the current >> description on >> >> > > SI=1 packets arriving at an SF. It seems to me that your example >> >> > > shows that such an effect is sometimes useul. >> >> > > It will also sometimes produce packet drops by the SFF, when >> the SF >> >> > > does not terminate the packet. Okay, so be it. >> >> > > It is not even clear there is anything, in Adrian's phrase, to >> paint >> >> > > red here. >> >> > > >> >> > > Yours, >> >> > > Joel >> >> > > >> >> > > On 2/11/17 12:59 PM, Ron Parker wrote: >> >> > > > Hi, Joel. >> >> > > > >> >> > > > Does your comment pertain to my somewhat off topic question >> which >> >> > > > was >> >> > > related to one of Adrian's tangential issues, or to Adrian's >> original >> >> > > SF=1 >> >> > topic? >> >> > > > >> >> > > > Thanks. >> >> > > > >> >> > > > Ron >> >> > > > >> >> > > > >> >> > > > -----Original Message----- >> >> > > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com >> ] >> >> > > > Sent: Saturday, February 11, 2017 12:31 PM >> >> > > > To: Ron Parker > >; >> >> > > > adrian@olddog.co.uk ; >> >> > > 'Dave Dolson' > >> >> > > > Cc: 'Eric C Rosen' > >; 'Dolganow, Andrew (Nokia - SG)' >> >> > > > >; sfc@ietf.org >> ; 'James N Guichard' >> >> > > > >; 'Fabricio Ferraz' >> >> > > > >> >> > > > Subject: Re: [sfc] NSH Service Index Decrement >> >> > > > >> >> > > > Personally, what you describe sounds like a quite reasonable >> case >> >> > > > where a >> >> > > packet arrive at the SF with an SI of 1 will produce exactly the >> >> > > desired >> >> > behavior. >> >> > > > >> >> > > > Which suggests, to my limited view, that the current text >> works fine. >> >> > > > >> >> > > > Yours, >> >> > > > Joel >> >> > > > >> >> > > > On 2/11/17 11:55 AM, Ron Parker wrote: >> >> > > >> Hi, Adrian. >> >> > > >> >> >> > > >> Not the original topic, per se, but wrt your comment: >> >> > > >> >> >> > > >> * On the other hand, we appear to be clear about an SF that >> strips >> >> > > >> the NSH >> >> > > and forwards the traffic as native : this is currently forbidden. >> >> > > >> >> >> > > >> I'm wondering how to reconcile this to a transparent HTTP Proxy >> >> > > >> that does >> >> > not >> >> > > preserve the original source-IP? Does this mean that it is >> mandatory for >> >> > such an >> >> > > SF to also be a classifier so it can self-classify its own related >> >> > > flows >> >> > (i.e., using its >> >> > > own visible IP addresses)? From SFF perspective, it would >> look like all >> >> > packets >> >> > > on the access side are dropped in the upstream direction and >> injected >> >> > > by the >> >> > SF >> >> > > in the downstream direction. On the Internet side, it would >> look like all >> >> > packets >> >> > > are injected by the SF in the upstream direction and dropped >> in the >> >> > > downstream direction. >> >> > > >> >> >> > > >> Thanks for any clarification. >> >> > > >> >> >> > > >> Ron >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> -----Original Message----- >> >> > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk >> ] >> >> > > >> Sent: Saturday, February 11, 2017 11:34 AM >> >> > > >> To: 'Dave Dolson' > >; 'Joel M. Halpern' >> >> > > >> >; Ron Parker >> >> > > > >> >> > > >> Cc: 'Eric C Rosen' > >; 'Dolganow, Andrew (Nokia - >> >> > > >> SG)' > >; sfc@ietf.org >> ; 'James N Guichard' >> >> > > >> > >; 'Fabricio Ferraz' >> >> > > >> > > >> >> > > >> Subject: RE: [sfc] NSH Service Index Decrement >> >> > > >> >> >> > > >> I hate to do my impersonation of Eric, but... >> >> > > >> >> >> > > >> "On the wire" is the crunch. >> >> > > >> >> >> > > >> Some have said that there must be no visible difference >> between the >> >> > > >> three >> >> > > case: >> >> > > >> - on the wire between SFF and SF >> >> > > >> - on the wire between SF and SFF >> >> > > >> - on the wire between SFF and SFF >> >> > > >> >> >> > > >> If this holds then you are correct that sending SI=1 in the >> first >> >> > > >> case >> >> > requires >> >> > > the SF to do more than a simple decrement (although decrement and >> >> > > discard is hardly painful). And it means that SI=1 is a >> dubious value in an >> >> SFP. >> >> > > >> >> >> > > >> On the other hand, we appear to be clear about an SF that >> strips >> >> > > >> the NSH >> >> > and >> >> > > forwards the traffic as native : this is currently forbidden. >> So there >> >> > > is no alternative for an SF receiving SI=1 except to discard >> the packet. >> >> > > >> >> >> > > >> Now, does that mean that an SFF should never send a packet with >> >> > > >> SI=1? Well, >> >> > > possibly it is OK for a few specialist SFs intended to sit at >> the end >> >> > > of the >> >> > chain and >> >> > > be a bit bucket with analysis. But, for most SFs there would >> be no point. >> >> > > >> >> >> > > >> Maybe (just maybe) we should stop letting the tail wag the dog! >> >> > > >> That is, >> >> > let's >> >> > > decide on the functional behavior we want to see and then >> design the >> >> > > protocol to match. >> >> > > >> >> >> > > >> Adrian >> >> > > >> >> >> > > >>> -----Original Message----- >> >> > > >>> From: Dave Dolson [mailto:ddolson@sandvine.com >> ] >> >> > > >>> Sent: 10 February 2017 22:26 >> >> > > >>> To: adrian@olddog.co.uk ; >> 'Joel M. Halpern'; 'Ron Parker' >> >> > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; >> sfc@ietf.org ; >> >> > > >>> 'James N Guichard'; 'Fabricio Ferraz' >> >> > > >>> Subject: RE: [sfc] NSH Service Index Decrement >> >> > > >>> >> >> > > >>> Adrian, >> >> > > >>> I think I agree with everything you said. >> >> > > >>> But you did not suggest whether or not you think that SI=0 >> should >> >> > > >>> be valid on >> >> > > >> the >> >> > > >>> wire. >> >> > > >>> I'm saying it could work, if the next hop is a path terminus. >> >> > > >>> >> >> > > >>> If I understand Joel correctly, he says we shouldn't send >> SI=0 in >> >> > > >>> case the >> >> > > >> next >> >> > > >>> hop blindly decrements it. >> >> > > >>> --> this seems to mean SI=1 cannot be used except at the >> terminus >> >> > > >>> --> or when the >> >> > > >>> SF is expected to drop all packets. >> >> > > >>> So I think this is an unnecessary seat belt, trying to >> anticipate >> >> > > >>> bugs in >> >> > > >> down- >> >> > > >>> stream devices. >> >> > > >>> >> >> > > >>> I realize the current language has been there a long time, >> and if >> >> > > >>> it is >> >> > > >> important to >> >> > > >>> anyone then it should remain. >> >> > > >>> Nonetheless, I think devices could safely handle SI=0 on >> the wire >> >> > > >>> without breaking anything. >> >> > > >>> >> >> > > >>> But I'm not pushing for a change, since the current >> behavior seems >> >> > > >>> important >> >> > > >> to >> >> > > >>> some. >> >> > > >>> >> >> > > >>> -Dave >> >> > > >>> >> >> > > >>> >> >> > > >>> -----Original Message----- >> >> > > >>> From: sfc [mailto:sfc-bounces@ietf.org >> ] On Behalf Of Adrian Farrel >> >> > > >>> Sent: Friday, February 10, 2017 9:16 AM >> >> > > >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' >> >> > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; >> sfc@ietf.org ; >> >> > > >>> 'James N Guichard'; 'Fabricio Ferraz' >> >> > > >>> Subject: Re: [sfc] NSH Service Index Decrement >> >> > > >>> >> >> > > >>> Oh, you finally pushed me into this discussion, Dave. >> >> > > >>> >> >> > > >>> We're building a protocol. with a protocol, you cannot >> (must not) >> >> > > >>> assume good behavior from your neighbor. >> >> > > >>> >> >> > > >>> So if the SF touches the SI (which it does) we must define the >> >> > > >>> edge >> >> > > >> conditions. >> >> > > >>> If it is the SF's job to decrement the SI, then we must also >> >> > > >>> define what it >> >> > > >> does >> >> > > >>> when SI=0 (otherwise, it will set SI to 0-1). >> >> > > >>> If the SF is not allowed to decrement the SI below zero (which >> >> > > >>> makes >> >> > > >>> sense) we must define what it must do. >> >> > > >>> Since SFs are allowed to drop packets (indeed that is one >> of their >> >> > > >>> main jobs >> >> > > >> ;-) >> >> > > >>> then this would be fine. >> >> > > >>> All that would be left is to define whether they apply the >> test >> >> > > >>> before or >> >> > > >> after >> >> > > >>> normal processing. >> >> > > >>> >> >> > > >>> As an aside, I agree with Don that TTL helps relax this a >> little, >> >> > > >>> but does not get us all the way there. >> >> > > >>> >> >> > > >>> Cheers, >> >> > > >>> Adrian >> >> > > >>> >> >> > > >>>> -----Original Message----- >> >> > > >>>> From: sfc [mailto:sfc-bounces@ietf.org >> ] On Behalf Of Dave Dolson >> >> > > >>>> Sent: 09 February 2017 21:00 >> >> > > >>>> To: Joel M. Halpern; Ron Parker >> >> > > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org >> ; Eric C >> >> > > >>>> Rosen; Dolganow, Andrew (Nokia - SG) >> >> > > >>>> Subject: Re: [sfc] NSH Service Index Decrement >> >> > > >>>> >> >> > > >>>> Discussing misconfigured SFFs is a straw-man argument. >> Once one >> >> > > >>>> starts >> >> > > >> trying >> >> > > >>> to >> >> > > >>>> anticipate down-stream devices being misconfigured, one can >> >> > > >>>> invent a lot of >> >> > > >>> silly >> >> > > >>>> requirements. >> >> > > >>>> >> >> > > >>>> >From an aesthetic point of view, I think it's bad that >> there are >> >> > > >>>>> two SI >> >> > > >>> values (0 >> >> > > >>>> and 1) that cannot be used. >> >> > > >>>> >> >> > > >>>> The real requirement, IMO, is that no device decrements 0 and >> >> > > >>>> forwards >> >> > > NSH. >> >> > > >>>> Since only SFs decrement SI, only SFs need to do this check. >> >> > > >>>> >> >> > > >>>> And any discussion about buggy SFs... well there is a lot >> of bad >> >> > > >>>> stuff that >> >> > > >>> bugs can >> >> > > >>>> cause. >> >> > > >>>> >> >> > > >>>> >> >> > > >>>> >> >> > > >>>> -----Original Message----- >> >> > > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >> ] >> >> > > >>>> Sent: Thursday, February 09, 2017 2:54 PM >> >> > > >>>> To: Ron Parker; Dave Dolson >> >> > > >>>> Cc: Eric C Rosen; sfc@ietf.org ; >> Dolganow, Andrew (Nokia - SG); >> >> > > >>>> James N >> >> > > >>> Guichard; >> >> > > >>>> Fabricio Ferraz >> >> > > >>>> Subject: Re: [sfc] NSH Service Index Decrement >> >> > > >>>> >> >> > > >>>> From my perspective as an individual participant in this >> work, >> >> > > >>>> declaring that 0 must be dropped is a matter of robustness. >> >> > > >>>> >> >> > > >>>> if we allow 0 to be processed for exit at an SFF, then a >> >> > > >>>> mis-configured SFF could easily continue processing such >> a packet. >> >> > > >>>> Now, it is true that TTL will eventually drop it, but >> that is an >> >> > expensive >> >> > > fallback. >> >> > > >>>> >> >> > > >>>> More importantly, presumably the next entitiy down the >> incorrect >> >> > > >>>> path would drop it for a 255 SI. But at that point we are >> >> > > >>>> getting the error in the wrong place, making it harder to >> diagnose and >> >> > repair. >> >> > > >>>> >> >> > > >>>> Yours, >> >> > > >>>> Joel >> >> > > >>>> >> >> > > >>>> On 2/9/17 12:42 PM, Ron Parker wrote: >> >> > > >>>>> agree. >> >> > > >>>>> >> >> > > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson >> >> >> > > >>>>> > >> wrote: >> >> > > >>>>> >> >> > > >>>>>> I'm not clear on why this is broken, or why this >> restriction is made. >> >> > > >>>>>> >> >> > > >>>>>> I agree it should not be sent to an SF, but an SFF >> could map an >> >> > > >>>>>> SI of zero into a path termination. >> >> > > >>>>>> >> >> > > >>>>>> I.e., the last SF in a path could decrement SI from 1 >> to 0, and >> >> > > >>>>>> the SFF could then terminate the chain. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org >> ] *On Behalf Of *James N >> >> > > >>>>>> Guichard >> >> > > >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM >> >> > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave >> >> > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org >> > >> >> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Not exactly. Section 3.3 specifies "The value zero for >> SI is >> >> > > >>>>>> not valid and indicates a broken SFC or malfunctioning >> SF" .. >> >> > > >>>>>> In other words an SF should never receive an NSH packet >> with SI = 0. >> >> > > >>>>>> Note that if this happened then either a) a classifier >> set the >> >> > > >>>>>> SI incorrectly, or b) a re-classifier set the SI >> incorrectly, >> >> > > >>>>>> or c) an upstream SF set the SI incorrectly; all of >> these cases >> >> > > >>>>>> should be caught by the SFF whose job it is to discard NSH >> >> > > >>>>>> packets with SI = >> >> > 0. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Jim >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> *From:*Fabricio Ferraz >> [mailto:fabricio-ferraz@telecom.pt >> ] >> >> > > >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM >> >> > > >>>>>> *To:* James N Guichard > >> >> > > >>>>>> > >>; Dolganow, Andrew (Nokia >> >> > > >>>>>> - >> >> > > >>>>>> SG) > >> >> > > >>>>>> > >>; >> >> > > >>>> Dave >> >> > > >>>>>> Dolson > > >>; >> >> > > >>>>>> Eric C Rosen > > >>; >> >> > > >>>>>> sfc@ietf.org > > >> >> > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Hi Jim, >> >> > > >>>>>> >> >> > > >>>>>> Thanks. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> One more question about the SI. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Section 3 states that: >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Service Index (SI): provides location within the SFP. The >> >> > > >>>>>> initial classifier MUST set the appropriate SI value for a >> >> > > >>>>>> given classification result. The initial SI value >> SHOULD default to >> >> 255. >> >> > > >>>>>> However, the classifier MUST allow configuration of >> other SI values. >> >> > > >>>>>> >> >> > > >>>>>> Service Index MUST be decremented by Service Functions >> or by >> >> > > >>>>>> SFC Proxy nodes after performing required services and >> the new >> >> > > >>>>>> decremented SI value MUST be used in the egress NSH packet. >> >> > > >>>>>> >> >> > > >>>>>> The initial Classifier MUST send the packet to the >> first SFF in >> >> > > >>>>>> the identified SFP for forwarding along an SFP. >> >> > > >>>>>> >> >> > > >>>>>> If re-classification occurs, and that re-classification >> results >> >> > > >>>>>> in a new SPI, the (re)classifier is, in effect, the initial >> >> > > >>>>>> classifier for the resultant SPI. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Thus: >> >> > > >>>>>> >> >> > > >>>>>> a) Initial SI value should be 255 but other values >> can be >> >> > > >>>>>> configured by the classifier. >> >> > > >>>>>> >> >> > > >>>>>> b) SF decrements the SI value on the egress NSH packet >> >> > > >>>>>> >> >> > > >>>>>> c) If re-classification occurs with new SPI, the >> re-classifier >> >> > > >>>>>> is the initial classifier, so by a), SI should be >> again 255 or >> >> > > >>>>>> other value >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> So any SI value can be receive by an SF, even 1 or 0 >> because: >> >> > > >>>>>> >> >> > > >>>>>> èIf SI=1 and there is no re-classification, the egress >> NSH will >> >> > > >>>>>> have SI=0 >> >> > > >>>>>> >> >> > > >>>>>> èIf SI=0 and there is re-classification with new SPI, the >> >> > > >>>>>> egress NSH will have a new SPI and a SI= 255 or other >> value, as >> >> stated in >> >> > a). >> >> > > >>>>>> >> >> > > >>>>>> èIf SI=0 and there is no re-classification the SF should >> >> > > >>>>>> discard the packet >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Also an SFF should forward/handle packets with NSH with >> SI=1 or SI=0. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Do you agree? >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org >> ] *On Behalf Of *James N >> >> > > >>>>>> Guichard >> >> > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 >> >> > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave >> >> > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org >> > >> >> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Hi Fabricio, >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Welcome! >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Yes, removal of NSH is the responsibility of an SFF or a >> >> > > >>>>>> re-classifier (section 4, bullet point 1 lays this >> out). With >> >> > > >>>>>> the current architecture the SF does not care what SI >> value it >> >> > > >>>>>> gets, it just needs to worry about decrementing it, and >> leave >> >> > > >>>>>> it up to the SFF to evaluate the SI value and >> associated action. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Jim >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> *From:*Fabricio Ferraz >> [mailto:fabricio-ferraz@telecom.pt >> ] >> >> > > >>>>>> *Sent:* Thursday, February 09, 2017 7:13 AM >> >> > > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) >> >> >> > > >>>>>> > >>; Dave Dolson >> >> > > >>>> >> >> > > >>>>>> > >>; Eric C Rosen >> >> > > >>>>>> >> >>; James N >> >> > > >>>>>> Guichard > >> >> > > >>> > >>; >> >> > > >>>>>> sfc@ietf.org > > >> >> > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Hi all, >> >> > > >>>>>> >> >> > > >>>>>> I'm new here (just read the draft last week) but >> according to >> >> > > >>>>>> chapter >> >> > > >>>>>> 4 (check figure 8 for example), an SF is not allowed to >> insert >> >> > > >>>>>> or remove NSH. The removal of NSH is reponsability of >> the SSF, right? >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Figure 8 maps each of the four actions above to the >> >> > > >>>>>> components in the >> >> > > >>>>>> >> >> > > >>>>>> SFC architecture that can perform it. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> +---------------+------------------+-------+----------------+---------+ >> >> > > >>>>>> >> >> > > >>>>>> | | Insert |Select | Update >> |Service >> >> | >> >> > > >>>>>> >> >> > > >>>>>> | | or remove NSH |Service| NSH >> |policy >> >> | >> >> > > >>>>>> >> >> > > >>>>>> | | |Function| >> >> |selection| >> >> > > >>>>>> >> >> > > >>>>>> | Component +--------+--------+Path >> +----------------+ >> >> | >> >> > > >>>>>> >> >> > > >>>>>> | | | | | Dec. >> |Update | >> >> | >> >> > > >>>>>> >> >> > > >>>>>> | | Insert | Remove | |Service >> |Context| >> >> | >> >> > > >>>>>> >> >> > > >>>>>> | | | | | Index >> |Header | >> >> | >> >> > > >>>>>> >> >> > > >>>>>> >> >> +----------------+--------+--------+-------+--------+-------+---------+ >> >> > > >>>>>> >> >> > > >>>>>> | | + | + | | | >> + | >> >> | >> >> > > >>>>>> >> >> > > >>>>>> |Classifier | | | | | >> | >> >> | >> >> > > >>>>>> >> >> > > >>>>>> +--------------- >> >> > > >>>>>> ++--------+--------+-------+--------+-------+---------+ >> >> > > >>>>>> >> >> > > >>>>>> |Service Function| | + | + | | >> | >> >> | >> >> > > >>>>>> >> >> > > >>>>>> |Forwarder(SFF) | | | | | >> | >> >> | >> >> > > >>>>>> >> >> > > >>>>>> +--------------- >> >> > > >>>>>> ++--------+--------+-------+--------+-------+---------+ >> >> > > >>>>>> >> >> > > >>>>>> |Service | | | | + | >> + | + >> >> | >> >> > > >>>>>> >> >> > > >>>>>> |Function (SF) | | | | | >> | >> >> | >> >> > > >>>>>> >> >> > > >>>>>> +--------------- >> >> > > >>>>>> ++--------+--------+-------+--------+-------+---------+ >> >> > > >>>>>> >> >> > > >>>>>> |SFC Proxy | + | + | | + | >> | >> >> | >> >> > > >>>>>> >> >> > > >>>>>> >> >> +----------------+--------+--------+-------+--------+-------+---------+ >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Figure 8: NSH Action and Role Mapping >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> An SF could receive an NSH packet with an SI of 1, and >> >> > > >>>>>> reclassify it to a different SPI and SI, right? So when >> a SF >> >> > > >>>>>> receives a NSH packet with SI = 1 that does not >> necessarily means a >> >> > non valid packet. >> >> > > >>>>>> >> >> > > >>>>>> And that can even work for SI=0, since you decrement >> the SI in >> >> > > >>>>>> the >> >> > > >> egress. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Fabricio >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org >> ] *On Behalf Of >> >> > > >>>>>> *Dolganow, Andrew (Nokia - SG) >> >> > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 >> >> > > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; >> sfc@ietf.org >> >> > > >>>>>> > >> >> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> I assumed that if we get value 1 we process then forward >> >> > > >>>>>> without NSH header (i.e.) this is the last SF processing. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> So with that assumption, a more explicit text would be: >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet >> MUST >> >> > > >>>>>> decrement the SI by 1 after performing all required local >> >> > > >>>>>> processing and before forwarding the packet to the next >> SFF. If >> >> > > >>>>>> the resulting SI is 0, the SF MUST remove the NSH >> header before >> >> > > forwarding the packet. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Andrew >> >> > > >>>>>> >> >> > > >>>>>> *From: *sfc > >> >> > > >>>>>> > >> on behalf of Dave Dolson >> >> > > >>>>>> >> >> > > >>>> >> >> >> > > >>>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM >> >> > > >>>>>> *To: *Eric Rosen > >> >> > > >>>>>> > >>, James N Guichard >> >> > > >>>>>> > >> >> > > >>>>>> > >>, "sfc@ietf.org >> >> >> > > >>>>>> >" >> > >> >> >> > > >>>>>> *Subject: *Re: [sfc] NSH Service Index Decrement >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> Eric, >> >> > > >>>>>> >> >> > > >>>>>> I was never quite happy with the outcome that neither 0 >> nor 1 >> >> > > >>>>>> is a valid SI. >> >> > > >>>>>> >> >> > > >>>>>> (Because if received with value of 1, it is decremented and >> >> > > >>>>>> discarded.) >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> It seems to waste an index value. >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> I guess I'm interested to know if that is important to >> other >> >> > > >>>>>> implementers, or if that was even the intention? >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> -Dave >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org >> ] *On Behalf Of *Eric C >> >> > > >>>>>> Rosen >> >> > > >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM >> >> > > >>>>>> *To:* James N Guichard; sfc@ietf.org >> > >> >> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: >> >> > > >>>>>> >> >> > > >>>>>> A request was made to be more specific and update the >> text as >> >> > follows: >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> "Service index MUST be decremented *by a value of 1* by >> Service >> >> > > >>>>>> Functions or by SFC Proxy nodes after performing >> required services ." >> >> > > >>>>>> >> >> > > >>>>>> >> >> > > >>>>>> A couple of observations: >> >> > > >>>>>> >> >> > > >>>>>> - The term "SFC Proxy node" is not defined in either >> the NSH >> >> > > >>>>>> draft or in RFC 7665. I think the intention here is to say >> >> > > >>>>>> "SFC >> >> > Proxy". >> >> > > >>>>>> >> >> > > >>>>>> - Is the intention that the SI remain unchanged while >> the SF is >> >> > > >>>>>> operating on the packet, or is the intention only that >> the SI >> >> > > >>>>>> be decremented before the packet is delivered by the SF >> or SFC >> >> > > >>>>>> Proxy to an SFF? >> >> > > >>>>>> >> >> > > >>>>>> I'd suggest either: >> >> > > >>>>>> >> >> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated >> packet MUST >> >> > > >>>>>> decrement the SI by 1 before delivering the packet to >> the next SFF" >> >> > > >>>>>> >> >> > > >>>>>> or >> >> > > >>>>>> >> >> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated >> packet MUST >> >> > > >>>>>> decrement the SI by 1 before delivering the packet to >> the next >> >> > > >>>>>> SFF, but not until the SF has finished all its other >> processing >> >> > > >>>>>> of the >> >> > > packet" >> >> > > >>>>>> >> >> > > >>>>>> depending upon which is intended. >> >> > > >>>>>> >> >> > > >>>>>> I think an implication of these procedures is that an >> SI value >> >> > > >>>>>> of >> >> > > >>>>>> 1 is not valid. If an SF gets an NSH packet with an SI >> of 1, >> >> > > >>>>>> the SF will decrement the SI (setting it to 0), send >> the packet >> >> > > >>>>>> to an SFF, and the SFF will discard it, because 0 is an >> invalid >> >> > > >>>>>> SI value. Is that the intention? >> >> > > >>>>>> >> >> > > >>>>>> The draft makes it clear (well, sort of) that an SFF should >> >> > > >>>>>> discard a packet with an SI of 0, but does not seem to >> say that >> >> > > >>>>>> an SF or SFC Proxy should discard a packet it receives >> with an >> >> > > >>>>>> SI of 0. It would probably be a good idea to say that. >> >> > > >>>>>> >> >> > > >>>>>> Some text in the draft (e.g., section 7.1) states than >> an SFF >> >> > > >>>>>> should discard a packet with an SI of zero, but other >> text in >> >> > > >>>>>> the draft (e.g., section 3.3) only says that an SFF >> should log >> >> > > >>>>>> an error if it sees an SI of zero. It's probably best to >> >> > > >>>>>> change the text in 3.3. to say "SHOULD generate an >> error/log >> >> > > >>>>>> message and MUST discard the packet", or something similar. >> >> > > >>>>>> >> >> > > >>>>>> _______________________________________________ >> >> > > >>>>>> 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 >> >> > > >>> >> >> > > >>> _______________________________________________ >> >> > > >>> 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 >> From nobody Sun Feb 12 11:59:13 2017 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 62DA5129AB6 for ; Sun, 12 Feb 2017 11:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub_eq0GCeCE4 for ; Sun, 12 Feb 2017 11:59:08 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BA7129485 for ; Sun, 12 Feb 2017 11:59:08 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0319.002; Sun, 12 Feb 2017 11:59:07 -0800 From: Ron Parker To: "Joel M. Halpern" Thread-Topic: [sfc] NSH Service Index Decrement Thread-Index: AdKBdxPsoZStRMOaTWyYN6elhsq7pAA99JyAAAJ/QoAAEEWfAAAVt+wAAAgFwNAAD4+tkAAeZjIw//6oW4D//33gw4AAqsEAgAASngCAASFmAIAAiOAAgAEwB4CAAIMaAP//jNyAgAB+Z8D//4u0gAAJXKMAAAy7vQAADG86AAAHXleAAAWrfREABop6gAAQrw3J Date: Sun, 12 Feb 2017 19:59:06 +0000 Message-ID: <99A64E6B-3E13-4B30-AE0E-1BEE84815974@affirmednetworks.com> References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> <0e0f01d2851b$d7323a10$8596ae30$@olddog.co.uk> , <0ba5fd16-a4ab-c6db-6933-cbc519f153d7@joelhalpern.com> In-Reply-To: <0ba5fd16-a4ab-c6db-6933-cbc519f153d7@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" , Jim Guichard , "sfc@ietf.org" , James N Guichard Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:59:11 -0000 Joel, I was only referring to Jim's assertion that in the SFC architecture only S= FF forwards based on NSH. =20 Ron > On Feb 12, 2017, at 2:56 PM, Joel M. Halpern wrote: >=20 > Ron, I am missing your point. >=20 > There are a lot of ways to build a reclassifier. It can have a co-locate= d SFF. The information that drives the new NSH header content can also spe= cify the SFF to send the packet to. > I suppose the reclassifier could do all of its job, then look up in a tab= le (not one mandated by the spec) to decide where to sesnd the packet. > However, any reclassifier which produces a packet with an SI of 0 is beha= ving pretty strangely. Since it is required to send the packet to an SFF, = it is producing a packet knowing that the packet will be immediately droppe= d, and may produce an error message. >=20 > Yours, > Joel >=20 >> On 2/12/17 2:24 PM, Ron Parker wrote: >> Jim, >>=20 >> I also consider the (re-)classifier to also make (an initial) forwarding >> decision based on NSH. >>=20 >> Ron >>=20 >> On Feb 12, 2017, at 9:07 AM, Jim Guichard > > wrote: >>=20 >>> Hi Adrian, >>>=20 >>> The point is an SFF does not need to distinguish between receipt of a >>> packet from an SF or SFF; the suggested text is relevant to a device >>> that forwards based on NSH and in this architecture only an SFF does th= at. >>>=20 >>> Jim >>> On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel >> > wrote: >>>=20 >>> Thanks Jim, >>>=20 >>>=20 >>>=20 >>> Your text works for me although I would prefer to delete the >>> commentary about a >>>=20 >>> "broken SFC" as a specific example of how this might happen that >>> is not the only >>>=20 >>> case (for example, a broken reclassifier can also cause this). >>>=20 >>>=20 >>>=20 >>> So, can we settle on >>>=20 >>>=20 >>>=20 >>> "Packets received at an SFF with an SI of zero MUST be discarded >>> and the SFF >>>=20 >>> SHOULD generate an error/log message." >>>=20 >>>=20 >>>=20 >>> BTW, I said >>>=20 >>> >> Then (of course) it is also OK for an SFF to receive SI=3D0, but >>> I think the >>>=20 >>> existing >>>=20 >>> >> "discard" text covers that case. >>>=20 >>> and you replied >>>=20 >>> > from an SF yes but not from another SFF. >>>=20 >>> and that (of course) has been a point of entertainment for some whil= e. >>>=20 >>> Since an SFF cannot tell the difference between a packet received >>> from an SFF >>>=20 >>> and one from an SF we must document all cases alike. >>>=20 >>>=20 >>>=20 >>> Fortunately, we're able to do so for this instance. >>>=20 >>>=20 >>>=20 >>> A >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> > -----Original Message----- >>>=20 >>> > From: James N Guichard [mailto:james.n.guichard@huawei.com >>> ] >>>=20 >>> > Sent: 12 February 2017 00:58 >>>=20 >>> > To: adrian@olddog.co.uk ; 'Joel M. >>> Halpern'; 'Ron Parker' >>>=20 >>> > Cc: sfc@ietf.org >>>=20 >>> > Subject: RE: [sfc] NSH Service Index Decrement >>>=20 >>> > >>>=20 >>> > Hi Adrian, >>>=20 >>> > >>>=20 >>> > Inline (hat off opinion) .. >>>=20 >>> > >>>=20 >>> > -----Original Message----- >>>=20 >>> > From: sfc [mailto:sfc-bounces@ietf.org >>> ] On Behalf Of Adrian Farrel >>>=20 >>> > Sent: Saturday, February 11, 2017 5:36 PM >>>=20 >>> > To: 'Joel M. Halpern' >> >; 'Ron Parker' >>>=20 >>> > >> > >>>=20 >>> > Cc: sfc@ietf.org >>>=20 >>> > Subject: Re: [sfc] NSH Service Index Decrement >>>=20 >>> > >>>=20 >>> > Joel, >>>=20 >>> > >>>=20 >>> > The -10 version of NSH says >>>=20 >>> > >>>=20 >>> > The >>>=20 >>> > value zero for SI is not valid and indicates a broken SFC or >>>=20 >>> > malfunctioning SF. >>>=20 >>> > >>>=20 >>> > Jim> the above text is perhaps what is causing some confusion as >>> it implies an >>>=20 >>> SI >>>=20 >>> > of 0 from an SF is invalid. May I suggest the following text as >>> a replacement >>>=20 >>> for >>>=20 >>> > the above sentence: >>>=20 >>> > >>>=20 >>> > "The value zero for SI indicates a broken SFC. Packets received >>> at an SFF with >>>=20 >>> an >>>=20 >>> > SI of zero MUST be discarded and the SFF SHOULD generate an >>> error/log >>>=20 >>> > message". >>>=20 >>> > >>>=20 >>> > You are saying that the latter of these is not true. >>>=20 >>> > I can't tell whether the former is really true or, perhaps, >>> represents a >>>=20 >>> discard tail >>>=20 >>> > of an SFC where some (but not all) packets are reclassified per Ro= n. >>>=20 >>> > >>>=20 >>> > Like I said: >>>=20 >>> > >>>=20 >>> > > Let's clarify that it is OK for an SF to send a packet with SI= =3D0 >>>=20 >>> > >>>=20 >>> > Then (of course) it is also OK for an SFF to receive SI=3D0, but I >>> think the >>>=20 >>> existing >>>=20 >>> > "discard" text covers that case. >>>=20 >>> > >>>=20 >>> > Jim> from an SF yes but not from another SFF. However, in either >>> case, a >>>=20 >>> lookup >>>=20 >>> > on should cause the SFF to discard the packet. >>> Hopefully my above >>>=20 >>> > suggested text clarifies that. >>>=20 >>> > >>>=20 >>> > Adrian >>>=20 >>> > >>>=20 >>> > > -----Original Message----- >>>=20 >>> > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>> ] >>>=20 >>> > > Sent: 11 February 2017 18:08 >>>=20 >>> > > To: Ron Parker; adrian@olddog.co.uk >>> ; 'Dave Dolson' >>>=20 >>> > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; >>> sfc@ietf.org ; >>>=20 >>> > > 'James N Guichard'; 'Fabricio Ferraz' >>>=20 >>> > > Subject: Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>=20 >>> > > I was commenting, in personal hat, about the issue of whether >>> there >>>=20 >>> > > was some sort of problem with the impact of the current >>> description on >>>=20 >>> > > SI=3D1 packets arriving at an SF. It seems to me that your exam= ple >>>=20 >>> > > shows that such an effect is sometimes useul. >>>=20 >>> > > It will also sometimes produce packet drops by the SFF, when >>> the SF >>>=20 >>> > > does not terminate the packet. Okay, so be it. >>>=20 >>> > > It is not even clear there is anything, in Adrian's phrase, to >>> paint >>>=20 >>> > > red here. >>>=20 >>> > > >>>=20 >>> > > Yours, >>>=20 >>> > > Joel >>>=20 >>> > > >>>=20 >>> > > On 2/11/17 12:59 PM, Ron Parker wrote: >>>=20 >>> > > > Hi, Joel. >>>=20 >>> > > > >>>=20 >>> > > > Does your comment pertain to my somewhat off topic question >>> which >>>=20 >>> > > > was >>>=20 >>> > > related to one of Adrian's tangential issues, or to Adrian's >>> original >>>=20 >>> > > SF=3D1 >>>=20 >>> > topic? >>>=20 >>> > > > >>>=20 >>> > > > Thanks. >>>=20 >>> > > > >>>=20 >>> > > > Ron >>>=20 >>> > > > >>>=20 >>> > > > >>>=20 >>> > > > -----Original Message----- >>>=20 >>> > > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>> ] >>>=20 >>> > > > Sent: Saturday, February 11, 2017 12:31 PM >>>=20 >>> > > > To: Ron Parker >> >; >>>=20 >>> > > > adrian@olddog.co.uk ; >>>=20 >>> > > 'Dave Dolson' > >>>=20 >>> > > > Cc: 'Eric C Rosen' >> >; 'Dolganow, Andrew (Nokia - SG)' >>>=20 >>> > > >> >; sfc@ietf.org >>> ; 'James N Guichard' >>>=20 >>> > > >> >; 'Fabricio Ferraz' >>>=20 >>> > > > >>>=20 >>> > > > Subject: Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > > >>>=20 >>> > > > Personally, what you describe sounds like a quite reasonable >>> case >>>=20 >>> > > > where a >>>=20 >>> > > packet arrive at the SF with an SI of 1 will produce exactly the >>>=20 >>> > > desired >>>=20 >>> > behavior. >>>=20 >>> > > > >>>=20 >>> > > > Which suggests, to my limited view, that the current text >>> works fine. >>>=20 >>> > > > >>>=20 >>> > > > Yours, >>>=20 >>> > > > Joel >>>=20 >>> > > > >>>=20 >>> > > > On 2/11/17 11:55 AM, Ron Parker wrote: >>>=20 >>> > > >> Hi, Adrian. >>>=20 >>> > > >> >>>=20 >>> > > >> Not the original topic, per se, but wrt your comment: >>>=20 >>> > > >> >>>=20 >>> > > >> * On the other hand, we appear to be clear about an SF that >>> strips >>>=20 >>> > > >> the NSH >>>=20 >>> > > and forwards the traffic as native : this is currently forbidden= . >>>=20 >>> > > >> >>>=20 >>> > > >> I'm wondering how to reconcile this to a transparent HTTP Pro= xy >>>=20 >>> > > >> that does >>>=20 >>> > not >>>=20 >>> > > preserve the original source-IP? Does this mean that it is >>> mandatory for >>>=20 >>> > such an >>>=20 >>> > > SF to also be a classifier so it can self-classify its own relat= ed >>>=20 >>> > > flows >>>=20 >>> > (i.e., using its >>>=20 >>> > > own visible IP addresses)? From SFF perspective, it would >>> look like all >>>=20 >>> > packets >>>=20 >>> > > on the access side are dropped in the upstream direction and >>> injected >>>=20 >>> > > by the >>>=20 >>> > SF >>>=20 >>> > > in the downstream direction. On the Internet side, it would >>> look like all >>>=20 >>> > packets >>>=20 >>> > > are injected by the SF in the upstream direction and dropped >>> in the >>>=20 >>> > > downstream direction. >>>=20 >>> > > >> >>>=20 >>> > > >> Thanks for any clarification. >>>=20 >>> > > >> >>>=20 >>> > > >> Ron >>>=20 >>> > > >> >>>=20 >>> > > >> >>>=20 >>> > > >> >>>=20 >>> > > >> -----Original Message----- >>>=20 >>> > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk >>> ] >>>=20 >>> > > >> Sent: Saturday, February 11, 2017 11:34 AM >>>=20 >>> > > >> To: 'Dave Dolson' >> >; 'Joel M. Halpern' >>>=20 >>> > > >> >; Ron Parke= r >>>=20 >>> > >> > >>>=20 >>> > > >> Cc: 'Eric C Rosen' >> >; 'Dolganow, Andrew (Nokia - >>>=20 >>> > > >> SG)' >> >; sfc@ietf.org >>> ; 'James N Guichard' >>>=20 >>> > > >> >> >; 'Fabricio Ferraz' >>>=20 >>> > > >> >> > >>>=20 >>> > > >> Subject: RE: [sfc] NSH Service Index Decrement >>>=20 >>> > > >> >>>=20 >>> > > >> I hate to do my impersonation of Eric, but... >>>=20 >>> > > >> >>>=20 >>> > > >> "On the wire" is the crunch. >>>=20 >>> > > >> >>>=20 >>> > > >> Some have said that there must be no visible difference >>> between the >>>=20 >>> > > >> three >>>=20 >>> > > case: >>>=20 >>> > > >> - on the wire between SFF and SF >>>=20 >>> > > >> - on the wire between SF and SFF >>>=20 >>> > > >> - on the wire between SFF and SFF >>>=20 >>> > > >> >>>=20 >>> > > >> If this holds then you are correct that sending SI=3D1 in the >>> first >>>=20 >>> > > >> case >>>=20 >>> > requires >>>=20 >>> > > the SF to do more than a simple decrement (although decrement an= d >>>=20 >>> > > discard is hardly painful). And it means that SI=3D1 is a >>> dubious value in an >>>=20 >>> SFP. >>>=20 >>> > > >> >>>=20 >>> > > >> On the other hand, we appear to be clear about an SF that >>> strips >>>=20 >>> > > >> the NSH >>>=20 >>> > and >>>=20 >>> > > forwards the traffic as native : this is currently forbidden. >>> So there >>>=20 >>> > > is no alternative for an SF receiving SI=3D1 except to discard >>> the packet. >>>=20 >>> > > >> >>>=20 >>> > > >> Now, does that mean that an SFF should never send a packet wi= th >>>=20 >>> > > >> SI=3D1? Well, >>>=20 >>> > > possibly it is OK for a few specialist SFs intended to sit at >>> the end >>>=20 >>> > > of the >>>=20 >>> > chain and >>>=20 >>> > > be a bit bucket with analysis. But, for most SFs there would >>> be no point. >>>=20 >>> > > >> >>>=20 >>> > > >> Maybe (just maybe) we should stop letting the tail wag the do= g! >>>=20 >>> > > >> That is, >>>=20 >>> > let's >>>=20 >>> > > decide on the functional behavior we want to see and then >>> design the >>>=20 >>> > > protocol to match. >>>=20 >>> > > >> >>>=20 >>> > > >> Adrian >>>=20 >>> > > >> >>>=20 >>> > > >>> -----Original Message----- >>>=20 >>> > > >>> From: Dave Dolson [mailto:ddolson@sandvine.com >>> ] >>>=20 >>> > > >>> Sent: 10 February 2017 22:26 >>>=20 >>> > > >>> To: adrian@olddog.co.uk ; >>> 'Joel M. Halpern'; 'Ron Parker' >>>=20 >>> > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; >>> sfc@ietf.org ; >>>=20 >>> > > >>> 'James N Guichard'; 'Fabricio Ferraz' >>>=20 >>> > > >>> Subject: RE: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>> >>>=20 >>> > > >>> Adrian, >>>=20 >>> > > >>> I think I agree with everything you said. >>>=20 >>> > > >>> But you did not suggest whether or not you think that SI=3D0 >>> should >>>=20 >>> > > >>> be valid on >>>=20 >>> > > >> the >>>=20 >>> > > >>> wire. >>>=20 >>> > > >>> I'm saying it could work, if the next hop is a path terminus= . >>>=20 >>> > > >>> >>>=20 >>> > > >>> If I understand Joel correctly, he says we shouldn't send >>> SI=3D0 in >>>=20 >>> > > >>> case the >>>=20 >>> > > >> next >>>=20 >>> > > >>> hop blindly decrements it. >>>=20 >>> > > >>> --> this seems to mean SI=3D1 cannot be used except at the >>> terminus >>>=20 >>> > > >>> --> or when the >>>=20 >>> > > >>> SF is expected to drop all packets. >>>=20 >>> > > >>> So I think this is an unnecessary seat belt, trying to >>> anticipate >>>=20 >>> > > >>> bugs in >>>=20 >>> > > >> down- >>>=20 >>> > > >>> stream devices. >>>=20 >>> > > >>> >>>=20 >>> > > >>> I realize the current language has been there a long time, >>> and if >>>=20 >>> > > >>> it is >>>=20 >>> > > >> important to >>>=20 >>> > > >>> anyone then it should remain. >>>=20 >>> > > >>> Nonetheless, I think devices could safely handle SI=3D0 on >>> the wire >>>=20 >>> > > >>> without breaking anything. >>>=20 >>> > > >>> >>>=20 >>> > > >>> But I'm not pushing for a change, since the current >>> behavior seems >>>=20 >>> > > >>> important >>>=20 >>> > > >> to >>>=20 >>> > > >>> some. >>>=20 >>> > > >>> >>>=20 >>> > > >>> -Dave >>>=20 >>> > > >>> >>>=20 >>> > > >>> >>>=20 >>> > > >>> -----Original Message----- >>>=20 >>> > > >>> From: sfc [mailto:sfc-bounces@ietf.org >>> ] On Behalf Of Adrian Farrel >>>=20 >>> > > >>> Sent: Friday, February 10, 2017 9:16 AM >>>=20 >>> > > >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' >>>=20 >>> > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; >>> sfc@ietf.org ; >>>=20 >>> > > >>> 'James N Guichard'; 'Fabricio Ferraz' >>>=20 >>> > > >>> Subject: Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>> >>>=20 >>> > > >>> Oh, you finally pushed me into this discussion, Dave. >>>=20 >>> > > >>> >>>=20 >>> > > >>> We're building a protocol. with a protocol, you cannot >>> (must not) >>>=20 >>> > > >>> assume good behavior from your neighbor. >>>=20 >>> > > >>> >>>=20 >>> > > >>> So if the SF touches the SI (which it does) we must define t= he >>>=20 >>> > > >>> edge >>>=20 >>> > > >> conditions. >>>=20 >>> > > >>> If it is the SF's job to decrement the SI, then we must also >>>=20 >>> > > >>> define what it >>>=20 >>> > > >> does >>>=20 >>> > > >>> when SI=3D0 (otherwise, it will set SI to 0-1). >>>=20 >>> > > >>> If the SF is not allowed to decrement the SI below zero (whi= ch >>>=20 >>> > > >>> makes >>>=20 >>> > > >>> sense) we must define what it must do. >>>=20 >>> > > >>> Since SFs are allowed to drop packets (indeed that is one >>> of their >>>=20 >>> > > >>> main jobs >>>=20 >>> > > >> ;-) >>>=20 >>> > > >>> then this would be fine. >>>=20 >>> > > >>> All that would be left is to define whether they apply the >>> test >>>=20 >>> > > >>> before or >>>=20 >>> > > >> after >>>=20 >>> > > >>> normal processing. >>>=20 >>> > > >>> >>>=20 >>> > > >>> As an aside, I agree with Don that TTL helps relax this a >>> little, >>>=20 >>> > > >>> but does not get us all the way there. >>>=20 >>> > > >>> >>>=20 >>> > > >>> Cheers, >>>=20 >>> > > >>> Adrian >>>=20 >>> > > >>> >>>=20 >>> > > >>>> -----Original Message----- >>>=20 >>> > > >>>> From: sfc [mailto:sfc-bounces@ietf.org >>> ] On Behalf Of Dave Dolson >>>=20 >>> > > >>>> Sent: 09 February 2017 21:00 >>>=20 >>> > > >>>> To: Joel M. Halpern; Ron Parker >>>=20 >>> > > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org >>> ; Eric C >>>=20 >>> > > >>>> Rosen; Dolganow, Andrew (Nokia - SG) >>>=20 >>> > > >>>> Subject: Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> Discussing misconfigured SFFs is a straw-man argument. >>> Once one >>>=20 >>> > > >>>> starts >>>=20 >>> > > >> trying >>>=20 >>> > > >>> to >>>=20 >>> > > >>>> anticipate down-stream devices being misconfigured, one can >>>=20 >>> > > >>>> invent a lot of >>>=20 >>> > > >>> silly >>>=20 >>> > > >>>> requirements. >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> >From an aesthetic point of view, I think it's bad that >>> there are >>>=20 >>> > > >>>>> two SI >>>=20 >>> > > >>> values (0 >>>=20 >>> > > >>>> and 1) that cannot be used. >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> The real requirement, IMO, is that no device decrements 0 a= nd >>>=20 >>> > > >>>> forwards >>>=20 >>> > > NSH. >>>=20 >>> > > >>>> Since only SFs decrement SI, only SFs need to do this check= . >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> And any discussion about buggy SFs... well there is a lot >>> of bad >>>=20 >>> > > >>>> stuff that >>>=20 >>> > > >>> bugs can >>>=20 >>> > > >>>> cause. >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> -----Original Message----- >>>=20 >>> > > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>> ] >>>=20 >>> > > >>>> Sent: Thursday, February 09, 2017 2:54 PM >>>=20 >>> > > >>>> To: Ron Parker; Dave Dolson >>>=20 >>> > > >>>> Cc: Eric C Rosen; sfc@ietf.org ; >>> Dolganow, Andrew (Nokia - SG); >>>=20 >>> > > >>>> James N >>>=20 >>> > > >>> Guichard; >>>=20 >>> > > >>>> Fabricio Ferraz >>>=20 >>> > > >>>> Subject: Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> From my perspective as an individual participant in this >>> work, >>>=20 >>> > > >>>> declaring that 0 must be dropped is a matter of robustness. >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> if we allow 0 to be processed for exit at an SFF, then a >>>=20 >>> > > >>>> mis-configured SFF could easily continue processing such >>> a packet. >>>=20 >>> > > >>>> Now, it is true that TTL will eventually drop it, but >>> that is an >>>=20 >>> > expensive >>>=20 >>> > > fallback. >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> More importantly, presumably the next entitiy down the >>> incorrect >>>=20 >>> > > >>>> path would drop it for a 255 SI. But at that point we are >>>=20 >>> > > >>>> getting the error in the wrong place, making it harder to >>> diagnose and >>>=20 >>> > repair. >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> Yours, >>>=20 >>> > > >>>> Joel >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> On 2/9/17 12:42 PM, Ron Parker wrote: >>>=20 >>> > > >>>>> agree. >>>=20 >>> > > >>>>> >>>=20 >>> > > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson >>> >>>=20 >>> > > >>>>> >> >> wrote: >>>=20 >>> > > >>>>> >>>=20 >>> > > >>>>>> I'm not clear on why this is broken, or why this >>> restriction is made. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> I agree it should not be sent to an SF, but an SFF >>> could map an >>>=20 >>> > > >>>>>> SI of zero into a path termination. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> I.e., the last SF in a path could decrement SI from 1 >>> to 0, and >>>=20 >>> > > >>>>>> the SFF could then terminate the chain. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org >>> ] *On Behalf Of *James N >>>=20 >>> > > >>>>>> Guichard >>>=20 >>> > > >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM >>>=20 >>> > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dav= e >>>=20 >>> > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org >>> > >>>=20 >>> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Not exactly. Section 3.3 specifies "The value zero for >>> SI is >>>=20 >>> > > >>>>>> not valid and indicates a broken SFC or malfunctioning >>> SF" .. >>>=20 >>> > > >>>>>> In other words an SF should never receive an NSH packet >>> with SI =3D 0. >>>=20 >>> > > >>>>>> Note that if this happened then either a) a classifier >>> set the >>>=20 >>> > > >>>>>> SI incorrectly, or b) a re-classifier set the SI >>> incorrectly, >>>=20 >>> > > >>>>>> or c) an upstream SF set the SI incorrectly; all of >>> these cases >>>=20 >>> > > >>>>>> should be caught by the SFF whose job it is to discard NS= H >>>=20 >>> > > >>>>>> packets with SI =3D >>>=20 >>> > 0. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Jim >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> *From:*Fabricio Ferraz >>> [mailto:fabricio-ferraz@telecom.pt >>> ] >>>=20 >>> > > >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM >>>=20 >>> > > >>>>>> *To:* James N Guichard >> >>>=20 >>> > > >>>>>> >> >>; Dolganow, Andrew (Nokia >>>=20 >>> > > >>>>>> - >>>=20 >>> > > >>>>>> SG) >> >>>=20 >>> > > >>>>>> >> >>; >>>=20 >>> > > >>>> Dave >>>=20 >>> > > >>>>>> Dolson >> >> >>; >>>=20 >>> > > >>>>>> Eric C Rosen >> >> >>; >>>=20 >>> > > >>>>>> sfc@ietf.org >> > >>>=20 >>> > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Hi Jim, >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Thanks. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> One more question about the SI. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Section 3 states that: >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Service Index (SI): provides location within the SFP. The >>>=20 >>> > > >>>>>> initial classifier MUST set the appropriate SI value for = a >>>=20 >>> > > >>>>>> given classification result. The initial SI value >>> SHOULD default to >>>=20 >>> 255. >>>=20 >>> > > >>>>>> However, the classifier MUST allow configuration of >>> other SI values. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Service Index MUST be decremented by Service Functions >>> or by >>>=20 >>> > > >>>>>> SFC Proxy nodes after performing required services and >>> the new >>>=20 >>> > > >>>>>> decremented SI value MUST be used in the egress NSH packe= t. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> The initial Classifier MUST send the packet to the >>> first SFF in >>>=20 >>> > > >>>>>> the identified SFP for forwarding along an SFP. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> If re-classification occurs, and that re-classification >>> results >>>=20 >>> > > >>>>>> in a new SPI, the (re)classifier is, in effect, the initi= al >>>=20 >>> > > >>>>>> classifier for the resultant SPI. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Thus: >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> a) Initial SI value should be 255 but other values >>> can be >>>=20 >>> > > >>>>>> configured by the classifier. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> b) SF decrements the SI value on the egress NSH pack= et >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> c) If re-classification occurs with new SPI, the >>> re-classifier >>>=20 >>> > > >>>>>> is the initial classifier, so by a), SI should be >>> again 255 or >>>=20 >>> > > >>>>>> other value >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> So any SI value can be receive by an SF, even 1 or 0 >>> because: >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> ?If SI=3D1 and there is no re-classification, the egress >>> NSH will >>>=20 >>> > > >>>>>> have SI=3D0 >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> ?If SI=3D0 and there is re-classification with new SPI, t= he >>>=20 >>> > > >>>>>> egress NSH will have a new SPI and a SI=3D 255 or other >>> value, as >>>=20 >>> stated in >>>=20 >>> > a). >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> ?If SI=3D0 and there is no re-classification the SF shoul= d >>>=20 >>> > > >>>>>> discard the packet >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Also an SFF should forward/handle packets with NSH with >>> SI=3D1 or SI=3D0. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Do you agree? >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org >>> ] *On Behalf Of *James N >>>=20 >>> > > >>>>>> Guichard >>>=20 >>> > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 >>>=20 >>> > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dav= e >>>=20 >>> > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org >>> > >>>=20 >>> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Hi Fabricio, >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Welcome! >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Yes, removal of NSH is the responsibility of an SFF or a >>>=20 >>> > > >>>>>> re-classifier (section 4, bullet point 1 lays this >>> out). With >>>=20 >>> > > >>>>>> the current architecture the SF does not care what SI >>> value it >>>=20 >>> > > >>>>>> gets, it just needs to worry about decrementing it, and >>> leave >>>=20 >>> > > >>>>>> it up to the SFF to evaluate the SI value and >>> associated action. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Jim >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> *From:*Fabricio Ferraz >>> [mailto:fabricio-ferraz@telecom.pt >>> ] >>>=20 >>> > > >>>>>> *Sent:* Thursday, February 09, 2017 7:13 AM >>>=20 >>> > > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) >>> >>>=20 >>> > > >>>>>> >> >>; Dave Dolson >>>=20 >>> > > >>>> >>>=20 >>> > > >>>>>> >> >>; Eric C Rosen >>>=20 >>> > > >>>>>> >>> >>; James N >>>=20 >>> > > >>>>>> Guichard >> >>>=20 >>> > > >>> >> >>; >>>=20 >>> > > >>>>>> sfc@ietf.org >> > >>>=20 >>> > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Hi all, >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> I'm new here (just read the draft last week) but >>> according to >>>=20 >>> > > >>>>>> chapter >>>=20 >>> > > >>>>>> 4 (check figure 8 for example), an SF is not allowed to >>> insert >>>=20 >>> > > >>>>>> or remove NSH. The removal of NSH is reponsability of >>> the SSF, right? >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Figure 8 maps each of the four actions above to the >>>=20 >>> > > >>>>>> components in the >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> SFC architecture that can perform it. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> +---------------+------------------+-------+----------------+-------= --+ >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> | | Insert |Select | Update >>> |Service >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> | | or remove NSH |Service| NSH >>> |policy >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> | | |Function| >>>=20 >>> |selection| >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> | Component +--------+--------+Path >>> +----------------+ >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> | | | | | Dec. >>> |Update | >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> | | Insert | Remove | |Service >>> |Context| >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> | | | | | Index >>> |Header | >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> +----------------+--------+--------+-------+--------+-------+-------= --+ >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> | | + | + | | | >>> + | >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> |Classifier | | | | | >>> | >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> +--------------- >>>=20 >>> > > >>>>>> ++--------+--------+-------+--------+-------+---------+ >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> |Service Function| | + | + | | >>> | >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> |Forwarder(SFF) | | | | | >>> | >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> +--------------- >>>=20 >>> > > >>>>>> ++--------+--------+-------+--------+-------+---------+ >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> |Service | | | | + | >>> + | + >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> |Function (SF) | | | | | >>> | >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> +--------------- >>>=20 >>> > > >>>>>> ++--------+--------+-------+--------+-------+---------+ >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> |SFC Proxy | + | + | | + | >>> | >>>=20 >>> | >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> +----------------+--------+--------+-------+--------+-------+-------= --+ >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Figure 8: NSH Action and Role Mapping >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> An SF could receive an NSH packet with an SI of 1, and >>>=20 >>> > > >>>>>> reclassify it to a different SPI and SI, right? So when >>> a SF >>>=20 >>> > > >>>>>> receives a NSH packet with SI =3D 1 that does not >>> necessarily means a >>>=20 >>> > non valid packet. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> And that can even work for SI=3D0, since you decrement >>> the SI in >>>=20 >>> > > >>>>>> the >>>=20 >>> > > >> egress. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Fabricio >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org >>> ] *On Behalf Of >>>=20 >>> > > >>>>>> *Dolganow, Andrew (Nokia - SG) >>>=20 >>> > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 >>>=20 >>> > > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; >>> sfc@ietf.org >>>=20 >>> > > >>>>>> > >>>=20 >>> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> I assumed that if we get value 1 we process then forward >>>=20 >>> > > >>>>>> without NSH header (i.e.) this is the last SF processing. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> So with that assumption, a more explicit text would be: >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet >>> MUST >>>=20 >>> > > >>>>>> decrement the SI by 1 after performing all required local >>>=20 >>> > > >>>>>> processing and before forwarding the packet to the next >>> SFF. If >>>=20 >>> > > >>>>>> the resulting SI is 0, the SF MUST remove the NSH >>> header before >>>=20 >>> > > forwarding the packet. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Andrew >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> *From: *sfc >> >>>=20 >>> > > >>>>>> >> >> on behalf of Dave Dolson >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>> >= > >>>=20 >>> > > >>>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM >>>=20 >>> > > >>>>>> *To: *Eric Rosen >> >>>=20 >>> > > >>>>>> >> >>, James N Guichard >>>=20 >>> > > >>>>>> >> >>>=20 >>> > > >>>>>> >> >>, "sfc@ietf.org >>> >>>=20 >>> > > >>>>>> >" >>> >> >> >>>=20 >>> > > >>>>>> *Subject: *Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Eric, >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> I was never quite happy with the outcome that neither 0 >>> nor 1 >>>=20 >>> > > >>>>>> is a valid SI. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> (Because if received with value of 1, it is decremented a= nd >>>=20 >>> > > >>>>>> discarded.) >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> It seems to waste an index value. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> I guess I'm interested to know if that is important to >>> other >>>=20 >>> > > >>>>>> implementers, or if that was even the intention? >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> -Dave >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org >>> ] *On Behalf Of *Eric C >>>=20 >>> > > >>>>>> Rosen >>>=20 >>> > > >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM >>>=20 >>> > > >>>>>> *To:* James N Guichard; sfc@ietf.org >>> > >>>=20 >>> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> A request was made to be more specific and update the >>> text as >>>=20 >>> > follows: >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> "Service index MUST be decremented *by a value of 1* by >>> Service >>>=20 >>> > > >>>>>> Functions or by SFC Proxy nodes after performing >>> required services ." >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> A couple of observations: >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> - The term "SFC Proxy node" is not defined in either >>> the NSH >>>=20 >>> > > >>>>>> draft or in RFC 7665. I think the intention here is to s= ay >>>=20 >>> > > >>>>>> "SFC >>>=20 >>> > Proxy". >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> - Is the intention that the SI remain unchanged while >>> the SF is >>>=20 >>> > > >>>>>> operating on the packet, or is the intention only that >>> the SI >>>=20 >>> > > >>>>>> be decremented before the packet is delivered by the SF >>> or SFC >>>=20 >>> > > >>>>>> Proxy to an SFF? >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> I'd suggest either: >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated >>> packet MUST >>>=20 >>> > > >>>>>> decrement the SI by 1 before delivering the packet to >>> the next SFF" >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> or >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated >>> packet MUST >>>=20 >>> > > >>>>>> decrement the SI by 1 before delivering the packet to >>> the next >>>=20 >>> > > >>>>>> SFF, but not until the SF has finished all its other >>> processing >>>=20 >>> > > >>>>>> of the >>>=20 >>> > > packet" >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> depending upon which is intended. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> I think an implication of these procedures is that an >>> SI value >>>=20 >>> > > >>>>>> of >>>=20 >>> > > >>>>>> 1 is not valid. If an SF gets an NSH packet with an SI >>> of 1, >>>=20 >>> > > >>>>>> the SF will decrement the SI (setting it to 0), send >>> the packet >>>=20 >>> > > >>>>>> to an SFF, and the SFF will discard it, because 0 is an >>> invalid >>>=20 >>> > > >>>>>> SI value. Is that the intention? >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> The draft makes it clear (well, sort of) that an SFF shou= ld >>>=20 >>> > > >>>>>> discard a packet with an SI of 0, but does not seem to >>> say that >>>=20 >>> > > >>>>>> an SF or SFC Proxy should discard a packet it receives >>> with an >>>=20 >>> > > >>>>>> SI of 0. It would probably be a good idea to say that. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> Some text in the draft (e.g., section 7.1) states than >>> an SFF >>>=20 >>> > > >>>>>> should discard a packet with an SI of zero, but other >>> text in >>>=20 >>> > > >>>>>> the draft (e.g., section 3.3) only says that an SFF >>> should log >>>=20 >>> > > >>>>>> an error if it sees an SI of zero. It's probably best to >>>=20 >>> > > >>>>>> change the text in 3.3. to say "SHOULD generate an >>> error/log >>>=20 >>> > > >>>>>> message and MUST discard the packet", or something simila= r. >>>=20 >>> > > >>>>>> >>>=20 >>> > > >>>>>> _______________________________________________ >>>=20 >>> > > >>>>>> sfc mailing list >>>=20 >>> > > >>>>>> sfc@ietf.org >> > >>>=20 >>> > > >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> > > >>>>> >>>=20 >>> > > >>>>> >>>=20 >>> > > >>>>> _______________________________________________ >>>=20 >>> > > >>>>> sfc mailing list >>>=20 >>> > > >>>>> sfc@ietf.org >>>=20 >>> > > >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> > > >>>>> >>>=20 >>> > > >>>> >>>=20 >>> > > >>>> _______________________________________________ >>>=20 >>> > > >>>> sfc mailing list >>>=20 >>> > > >>>> sfc@ietf.org >>>=20 >>> > > >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> > > >>> >>>=20 >>> > > >>> _______________________________________________ >>>=20 >>> > > >>> sfc mailing list >>>=20 >>> > > >>> sfc@ietf.org >>>=20 >>> > > >>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> > > >> >>>=20 >>> > > > >>>=20 >>> > >>>=20 >>> > _______________________________________________ >>>=20 >>> > sfc mailing list >>>=20 >>> > sfc@ietf.org >>>=20 >>> > https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>>=20 >>> sfc mailing list >>>=20 >>> sfc@ietf.org >>>=20 >>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 From nobody Sun Feb 12 12:07:42 2017 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 6B4D5129B31 for ; Sun, 12 Feb 2017 12:07:38 -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, 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=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 BSkXc1VgeMvz for ; Sun, 12 Feb 2017 12:07:33 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 AD14A129B35 for ; Sun, 12 Feb 2017 12:07:32 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 96so55274563uaq.3 for ; Sun, 12 Feb 2017 12:07:32 -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=Y5j/H2npyy1kOw/8h0km2mxc+FvOE95jVecpnUvNa2E=; b=bVwgxLQgTFerJbZ6aPoLSInmtkg7HWFseZmhlWhA3KLc+VlITJvijvBK0NaA/8M86d hrwJd6uc3SgOTWolvpWzrePAeTqrILdSTqmkdtp8pcXjQrt+gUyIBLbEKkafQABLQM8e OlNkkVMHFLLyQZRITxIYx+Bj2cUSU1BF/8W27JvztJ/2VA9DX/pYtvmxt+3ciyveYJFW sHqMWCTMATttmC5qdv8aBCT8ZnVaJTSMbRbl33VFxn9qEg2B0dgMpBKODpUlZSFg/XDh PSlkGfrpsTaLhgs5YevaYlRkBlEFqmz4reqlojZtnYiR+Ay5Yh1vIeTJaVK+ee2wp2Is t9Jg== 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=Y5j/H2npyy1kOw/8h0km2mxc+FvOE95jVecpnUvNa2E=; b=hoh9iA6opaXVASfm5XOBEyE9EwVQliV+Mm6qFCdULH+z04VH++Oj0Bx5h1H/EC4eWc aKksT5oxaiyZ2DOz0cXLzzRnrV26B7Tx87uuKjM6AfTd0TNUd0Mx2eJuTwKiYCXqZLI2 F1LbhWhmwzGUdkPi43ofQl3d54bYtZxXchBjKyfFIa/CRCOuJyzBChVVIuDE+JkegWAe idx+QlQ0ZL5By3XT1AWeIs6pKR+jMbHrWdSVkwYYoMCoSyY9Wkpiz+TLqCuOc4TyRV/E KFtMCBzXarL4NQBcMMEs+K5ssZzOKsuZmdotOSWoyMuqAYHjByqB4evjTzUWvPJq1w8t RSCw== X-Gm-Message-State: AMke39kZwTHgxCF6g0e+igzmUQJMoiHby5zy2VWVTdEziueweF/SLJ1SZ44hfDklCrlUjO1IrsfCvfVpn3FKJg== X-Received: by 10.176.66.66 with SMTP id i60mr10421351uai.131.1486930051291; Sun, 12 Feb 2017 12:07:31 -0800 (PST) MIME-Version: 1.0 References: <28DFB214-A1B9-4D60-AE3B-3B72CBE4E22C@affirmednetworks.com> <58b5332d-fea8-2adf-3c12-e099dd444117@joelhalpern.com> <0bae01d283a8$3dba7560$b92f6020$@olddog.co.uk> <0d6e01d28484$c16c85b0$44459110$@olddog.co.uk> <74475094-77b5-12d7-131b-8ced78b310bb@joelhalpern.com> <1c1acb1f-c7ba-619d-fdd6-a73255cfcd78@joelhalpern.com> <0e0f01d2851b$d7323a10$8596ae30$@olddog.co.uk> <0ba5fd16-a4ab-c6db-6933-cbc519f153d7@joelhalpern.com> <99A64E6B-3E13-4B30-AE0E-1BEE84815974@affirmednetworks.com> In-Reply-To: <99A64E6B-3E13-4B30-AE0E-1BEE84815974@affirmednetworks.com> From: Jim Guichard Date: Sun, 12 Feb 2017 20:07:20 +0000 Message-ID: To: "Joel M. Halpern" , Ron Parker Content-Type: multipart/alternative; boundary=94eb2c0939ce83eb8605485ae17b Archived-At: Cc: "adrian@olddog.co.uk" , "sfc@ietf.org" , James N Guichard Subject: Re: [sfc] NSH Service Index Decrement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 20:07:38 -0000 --94eb2c0939ce83eb8605485ae17b Content-Type: text/plain; charset=UTF-8 Which is true ;-) .. a classifier *imposes* NSH which is not forwarding based on SPI/SI although you *could* co-locate SFF forwarding with the classifier. Jim On Sun, Feb 12, 2017 at 2:59 PM Ron Parker wrote: > Joel, > > > > I was only referring to Jim's assertion that in the SFC architecture only > SFF forwards based on NSH. > > > > Ron > > > > > > > On Feb 12, 2017, at 2:56 PM, Joel M. Halpern > wrote: > > > > > > Ron, I am missing your point. > > > > > > There are a lot of ways to build a reclassifier. It can have a > co-located SFF. The information that drives the new NSH header content can > also specify the SFF to send the packet to. > > > I suppose the reclassifier could do all of its job, then look up in a > table (not one mandated by the spec) to decide where to sesnd the packet. > > > However, any reclassifier which produces a packet with an SI of 0 is > behaving pretty strangely. Since it is required to send the packet to an > SFF, it is producing a packet knowing that the packet will be immediately > dropped, and may produce an error message. > > > > > > Yours, > > > Joel > > > > > >> On 2/12/17 2:24 PM, Ron Parker wrote: > > >> Jim, > > >> > > >> I also consider the (re-)classifier to also make (an initial) forwarding > > >> decision based on NSH. > > >> > > >> Ron > > >> > > >> On Feb 12, 2017, at 9:07 AM, Jim Guichard > >> > wrote: > > >> > > >>> Hi Adrian, > > >>> > > >>> The point is an SFF does not need to distinguish between receipt of a > > >>> packet from an SF or SFF; the suggested text is relevant to a device > > >>> that forwards based on NSH and in this architecture only an SFF does > that. > > >>> > > >>> Jim > > >>> On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel > >>> > wrote: > > >>> > > >>> Thanks Jim, > > >>> > > >>> > > >>> > > >>> Your text works for me although I would prefer to delete the > > >>> commentary about a > > >>> > > >>> "broken SFC" as a specific example of how this might happen that > > >>> is not the only > > >>> > > >>> case (for example, a broken reclassifier can also cause this). > > >>> > > >>> > > >>> > > >>> So, can we settle on > > >>> > > >>> > > >>> > > >>> "Packets received at an SFF with an SI of zero MUST be discarded > > >>> and the SFF > > >>> > > >>> SHOULD generate an error/log message." > > >>> > > >>> > > >>> > > >>> BTW, I said > > >>> > > >>> >> Then (of course) it is also OK for an SFF to receive SI=0, but > > >>> I think the > > >>> > > >>> existing > > >>> > > >>> >> "discard" text covers that case. > > >>> > > >>> and you replied > > >>> > > >>> > from an SF yes but not from another SFF. > > >>> > > >>> and that (of course) has been a point of entertainment for some > while. > > >>> > > >>> Since an SFF cannot tell the difference between a packet received > > >>> from an SFF > > >>> > > >>> and one from an SF we must document all cases alike. > > >>> > > >>> > > >>> > > >>> Fortunately, we're able to do so for this instance. > > >>> > > >>> > > >>> > > >>> A > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > -----Original Message----- > > >>> > > >>> > From: James N Guichard [mailto:james.n.guichard@huawei.com > > >>> ] > > >>> > > >>> > Sent: 12 February 2017 00:58 > > >>> > > >>> > To: adrian@olddog.co.uk ; 'Joel M. > > >>> Halpern'; 'Ron Parker' > > >>> > > >>> > Cc: sfc@ietf.org > > >>> > > >>> > Subject: RE: [sfc] NSH Service Index Decrement > > >>> > > >>> > > > >>> > > >>> > Hi Adrian, > > >>> > > >>> > > > >>> > > >>> > Inline (hat off opinion) .. > > >>> > > >>> > > > >>> > > >>> > -----Original Message----- > > >>> > > >>> > From: sfc [mailto:sfc-bounces@ietf.org > > >>> ] On Behalf Of Adrian Farrel > > >>> > > >>> > Sent: Saturday, February 11, 2017 5:36 PM > > >>> > > >>> > To: 'Joel M. Halpern' > >>> >; 'Ron Parker' > > >>> > > >>> > > >>> > > > >>> > > >>> > Cc: sfc@ietf.org > > >>> > > >>> > Subject: Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > > >>> > > >>> > Joel, > > >>> > > >>> > > > >>> > > >>> > The -10 version of NSH says > > >>> > > >>> > > > >>> > > >>> > The > > >>> > > >>> > value zero for SI is not valid and indicates a broken SFC or > > >>> > > >>> > malfunctioning SF. > > >>> > > >>> > > > >>> > > >>> > Jim> the above text is perhaps what is causing some confusion as > > >>> it implies an > > >>> > > >>> SI > > >>> > > >>> > of 0 from an SF is invalid. May I suggest the following text as > > >>> a replacement > > >>> > > >>> for > > >>> > > >>> > the above sentence: > > >>> > > >>> > > > >>> > > >>> > "The value zero for SI indicates a broken SFC. Packets received > > >>> at an SFF with > > >>> > > >>> an > > >>> > > >>> > SI of zero MUST be discarded and the SFF SHOULD generate an > > >>> error/log > > >>> > > >>> > message". > > >>> > > >>> > > > >>> > > >>> > You are saying that the latter of these is not true. > > >>> > > >>> > I can't tell whether the former is really true or, perhaps, > > >>> represents a > > >>> > > >>> discard tail > > >>> > > >>> > of an SFC where some (but not all) packets are reclassified per > Ron. > > >>> > > >>> > > > >>> > > >>> > Like I said: > > >>> > > >>> > > > >>> > > >>> > > Let's clarify that it is OK for an SF to send a packet with SI=0 > > >>> > > >>> > > > >>> > > >>> > Then (of course) it is also OK for an SFF to receive SI=0, but I > > >>> think the > > >>> > > >>> existing > > >>> > > >>> > "discard" text covers that case. > > >>> > > >>> > > > >>> > > >>> > Jim> from an SF yes but not from another SFF. However, in either > > >>> case, a > > >>> > > >>> lookup > > >>> > > >>> > on should cause the SFF to discard the packet. > > >>> Hopefully my above > > >>> > > >>> > suggested text clarifies that. > > >>> > > >>> > > > >>> > > >>> > Adrian > > >>> > > >>> > > > >>> > > >>> > > -----Original Message----- > > >>> > > >>> > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com > > >>> ] > > >>> > > >>> > > Sent: 11 February 2017 18:08 > > >>> > > >>> > > To: Ron Parker; adrian@olddog.co.uk > > >>> ; 'Dave Dolson' > > >>> > > >>> > > Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; > > >>> sfc@ietf.org ; > > >>> > > >>> > > 'James N Guichard'; 'Fabricio Ferraz' > > >>> > > >>> > > Subject: Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > > > >>> > > >>> > > I was commenting, in personal hat, about the issue of whether > > >>> there > > >>> > > >>> > > was some sort of problem with the impact of the current > > >>> description on > > >>> > > >>> > > SI=1 packets arriving at an SF. It seems to me that your > example > > >>> > > >>> > > shows that such an effect is sometimes useul. > > >>> > > >>> > > It will also sometimes produce packet drops by the SFF, when > > >>> the SF > > >>> > > >>> > > does not terminate the packet. Okay, so be it. > > >>> > > >>> > > It is not even clear there is anything, in Adrian's phrase, to > > >>> paint > > >>> > > >>> > > red here. > > >>> > > >>> > > > > >>> > > >>> > > Yours, > > >>> > > >>> > > Joel > > >>> > > >>> > > > > >>> > > >>> > > On 2/11/17 12:59 PM, Ron Parker wrote: > > >>> > > >>> > > > Hi, Joel. > > >>> > > >>> > > > > > >>> > > >>> > > > Does your comment pertain to my somewhat off topic question > > >>> which > > >>> > > >>> > > > was > > >>> > > >>> > > related to one of Adrian's tangential issues, or to Adrian's > > >>> original > > >>> > > >>> > > SF=1 > > >>> > > >>> > topic? > > >>> > > >>> > > > > > >>> > > >>> > > > Thanks. > > >>> > > >>> > > > > > >>> > > >>> > > > Ron > > >>> > > >>> > > > > > >>> > > >>> > > > > > >>> > > >>> > > > -----Original Message----- > > >>> > > >>> > > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com > > >>> ] > > >>> > > >>> > > > Sent: Saturday, February 11, 2017 12:31 PM > > >>> > > >>> > > > To: Ron Parker > >>> >; > > >>> > > >>> > > > adrian@olddog.co.uk ; > > >>> > > >>> > > 'Dave Dolson' ddolson@sandvine.com>> > > >>> > > >>> > > > Cc: 'Eric C Rosen' > >>> >; 'Dolganow, Andrew (Nokia - SG)' > > >>> > > >>> > > > >>> >; sfc@ietf.org > > >>> ; 'James N Guichard' > > >>> > > >>> > > > >>> >; 'Fabricio Ferraz' > > >>> > > >>> > > >> > > >>> > > >>> > > > Subject: Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > > > > >>> > > >>> > > > Personally, what you describe sounds like a quite reasonable > > >>> case > > >>> > > >>> > > > where a > > >>> > > >>> > > packet arrive at the SF with an SI of 1 will produce exactly the > > >>> > > >>> > > desired > > >>> > > >>> > behavior. > > >>> > > >>> > > > > > >>> > > >>> > > > Which suggests, to my limited view, that the current text > > >>> works fine. > > >>> > > >>> > > > > > >>> > > >>> > > > Yours, > > >>> > > >>> > > > Joel > > >>> > > >>> > > > > > >>> > > >>> > > > On 2/11/17 11:55 AM, Ron Parker wrote: > > >>> > > >>> > > >> Hi, Adrian. > > >>> > > >>> > > >> > > >>> > > >>> > > >> Not the original topic, per se, but wrt your comment: > > >>> > > >>> > > >> > > >>> > > >>> > > >> * On the other hand, we appear to be clear about an SF that > > >>> strips > > >>> > > >>> > > >> the NSH > > >>> > > >>> > > and forwards the traffic as native : this is currently > forbidden. > > >>> > > >>> > > >> > > >>> > > >>> > > >> I'm wondering how to reconcile this to a transparent HTTP > Proxy > > >>> > > >>> > > >> that does > > >>> > > >>> > not > > >>> > > >>> > > preserve the original source-IP? Does this mean that it is > > >>> mandatory for > > >>> > > >>> > such an > > >>> > > >>> > > SF to also be a classifier so it can self-classify its own > related > > >>> > > >>> > > flows > > >>> > > >>> > (i.e., using its > > >>> > > >>> > > own visible IP addresses)? From SFF perspective, it would > > >>> look like all > > >>> > > >>> > packets > > >>> > > >>> > > on the access side are dropped in the upstream direction and > > >>> injected > > >>> > > >>> > > by the > > >>> > > >>> > SF > > >>> > > >>> > > in the downstream direction. On the Internet side, it would > > >>> look like all > > >>> > > >>> > packets > > >>> > > >>> > > are injected by the SF in the upstream direction and dropped > > >>> in the > > >>> > > >>> > > downstream direction. > > >>> > > >>> > > >> > > >>> > > >>> > > >> Thanks for any clarification. > > >>> > > >>> > > >> > > >>> > > >>> > > >> Ron > > >>> > > >>> > > >> > > >>> > > >>> > > >> > > >>> > > >>> > > >> > > >>> > > >>> > > >> -----Original Message----- > > >>> > > >>> > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk > > >>> ] > > >>> > > >>> > > >> Sent: Saturday, February 11, 2017 11:34 AM > > >>> > > >>> > > >> To: 'Dave Dolson' > >>> >; 'Joel M. Halpern' > > >>> > > >>> > > >> >; Ron > Parker > > >>> > > >>> > > >>> > > > >>> > > >>> > > >> Cc: 'Eric C Rosen' > >>> >; 'Dolganow, Andrew (Nokia - > > >>> > > >>> > > >> SG)' > >>> >; sfc@ietf.org > > >>> ; 'James N Guichard' > > >>> > > >>> > > >> > >>> >; 'Fabricio Ferraz' > > >>> > > >>> > > >> > >>> > > > >>> > > >>> > > >> Subject: RE: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >> > > >>> > > >>> > > >> I hate to do my impersonation of Eric, but... > > >>> > > >>> > > >> > > >>> > > >>> > > >> "On the wire" is the crunch. > > >>> > > >>> > > >> > > >>> > > >>> > > >> Some have said that there must be no visible difference > > >>> between the > > >>> > > >>> > > >> three > > >>> > > >>> > > case: > > >>> > > >>> > > >> - on the wire between SFF and SF > > >>> > > >>> > > >> - on the wire between SF and SFF > > >>> > > >>> > > >> - on the wire between SFF and SFF > > >>> > > >>> > > >> > > >>> > > >>> > > >> If this holds then you are correct that sending SI=1 in the > > >>> first > > >>> > > >>> > > >> case > > >>> > > >>> > requires > > >>> > > >>> > > the SF to do more than a simple decrement (although decrement > and > > >>> > > >>> > > discard is hardly painful). And it means that SI=1 is a > > >>> dubious value in an > > >>> > > >>> SFP. > > >>> > > >>> > > >> > > >>> > > >>> > > >> On the other hand, we appear to be clear about an SF that > > >>> strips > > >>> > > >>> > > >> the NSH > > >>> > > >>> > and > > >>> > > >>> > > forwards the traffic as native : this is currently forbidden. > > >>> So there > > >>> > > >>> > > is no alternative for an SF receiving SI=1 except to discard > > >>> the packet. > > >>> > > >>> > > >> > > >>> > > >>> > > >> Now, does that mean that an SFF should never send a packet > with > > >>> > > >>> > > >> SI=1? Well, > > >>> > > >>> > > possibly it is OK for a few specialist SFs intended to sit at > > >>> the end > > >>> > > >>> > > of the > > >>> > > >>> > chain and > > >>> > > >>> > > be a bit bucket with analysis. But, for most SFs there would > > >>> be no point. > > >>> > > >>> > > >> > > >>> > > >>> > > >> Maybe (just maybe) we should stop letting the tail wag the > dog! > > >>> > > >>> > > >> That is, > > >>> > > >>> > let's > > >>> > > >>> > > decide on the functional behavior we want to see and then > > >>> design the > > >>> > > >>> > > protocol to match. > > >>> > > >>> > > >> > > >>> > > >>> > > >> Adrian > > >>> > > >>> > > >> > > >>> > > >>> > > >>> -----Original Message----- > > >>> > > >>> > > >>> From: Dave Dolson [mailto:ddolson@sandvine.com > > >>> ] > > >>> > > >>> > > >>> Sent: 10 February 2017 22:26 > > >>> > > >>> > > >>> To: adrian@olddog.co.uk ; > > >>> 'Joel M. Halpern'; 'Ron Parker' > > >>> > > >>> > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; > > >>> sfc@ietf.org ; > > >>> > > >>> > > >>> 'James N Guichard'; 'Fabricio Ferraz' > > >>> > > >>> > > >>> Subject: RE: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Adrian, > > >>> > > >>> > > >>> I think I agree with everything you said. > > >>> > > >>> > > >>> But you did not suggest whether or not you think that SI=0 > > >>> should > > >>> > > >>> > > >>> be valid on > > >>> > > >>> > > >> the > > >>> > > >>> > > >>> wire. > > >>> > > >>> > > >>> I'm saying it could work, if the next hop is a path > terminus. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> If I understand Joel correctly, he says we shouldn't send > > >>> SI=0 in > > >>> > > >>> > > >>> case the > > >>> > > >>> > > >> next > > >>> > > >>> > > >>> hop blindly decrements it. > > >>> > > >>> > > >>> --> this seems to mean SI=1 cannot be used except at the > > >>> terminus > > >>> > > >>> > > >>> --> or when the > > >>> > > >>> > > >>> SF is expected to drop all packets. > > >>> > > >>> > > >>> So I think this is an unnecessary seat belt, trying to > > >>> anticipate > > >>> > > >>> > > >>> bugs in > > >>> > > >>> > > >> down- > > >>> > > >>> > > >>> stream devices. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> I realize the current language has been there a long time, > > >>> and if > > >>> > > >>> > > >>> it is > > >>> > > >>> > > >> important to > > >>> > > >>> > > >>> anyone then it should remain. > > >>> > > >>> > > >>> Nonetheless, I think devices could safely handle SI=0 on > > >>> the wire > > >>> > > >>> > > >>> without breaking anything. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> But I'm not pushing for a change, since the current > > >>> behavior seems > > >>> > > >>> > > >>> important > > >>> > > >>> > > >> to > > >>> > > >>> > > >>> some. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -Dave > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> > > >>> > > >>> From: sfc [mailto:sfc-bounces@ietf.org > > >>> ] On Behalf Of Adrian Farrel > > >>> > > >>> > > >>> Sent: Friday, February 10, 2017 9:16 AM > > >>> > > >>> > > >>> To: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker' > > >>> > > >>> > > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia - SG)'; > > >>> sfc@ietf.org ; > > >>> > > >>> > > >>> 'James N Guichard'; 'Fabricio Ferraz' > > >>> > > >>> > > >>> Subject: Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Oh, you finally pushed me into this discussion, Dave. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> We're building a protocol. with a protocol, you cannot > > >>> (must not) > > >>> > > >>> > > >>> assume good behavior from your neighbor. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> So if the SF touches the SI (which it does) we must define > the > > >>> > > >>> > > >>> edge > > >>> > > >>> > > >> conditions. > > >>> > > >>> > > >>> If it is the SF's job to decrement the SI, then we must also > > >>> > > >>> > > >>> define what it > > >>> > > >>> > > >> does > > >>> > > >>> > > >>> when SI=0 (otherwise, it will set SI to 0-1). > > >>> > > >>> > > >>> If the SF is not allowed to decrement the SI below zero > (which > > >>> > > >>> > > >>> makes > > >>> > > >>> > > >>> sense) we must define what it must do. > > >>> > > >>> > > >>> Since SFs are allowed to drop packets (indeed that is one > > >>> of their > > >>> > > >>> > > >>> main jobs > > >>> > > >>> > > >> ;-) > > >>> > > >>> > > >>> then this would be fine. > > >>> > > >>> > > >>> All that would be left is to define whether they apply the > > >>> test > > >>> > > >>> > > >>> before or > > >>> > > >>> > > >> after > > >>> > > >>> > > >>> normal processing. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> As an aside, I agree with Don that TTL helps relax this a > > >>> little, > > >>> > > >>> > > >>> but does not get us all the way there. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Cheers, > > >>> > > >>> > > >>> Adrian > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>> > > >>> > > >>>> From: sfc [mailto:sfc-bounces@ietf.org > > >>> ] On Behalf Of Dave Dolson > > >>> > > >>> > > >>>> Sent: 09 February 2017 21:00 > > >>> > > >>> > > >>>> To: Joel M. Halpern; Ron Parker > > >>> > > >>> > > >>>> Cc: Fabricio Ferraz; James N Guichard; sfc@ietf.org > > >>> ; Eric C > > >>> > > >>> > > >>>> Rosen; Dolganow, Andrew (Nokia - SG) > > >>> > > >>> > > >>>> Subject: Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> Discussing misconfigured SFFs is a straw-man argument. > > >>> Once one > > >>> > > >>> > > >>>> starts > > >>> > > >>> > > >> trying > > >>> > > >>> > > >>> to > > >>> > > >>> > > >>>> anticipate down-stream devices being misconfigured, one can > > >>> > > >>> > > >>>> invent a lot of > > >>> > > >>> > > >>> silly > > >>> > > >>> > > >>>> requirements. > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> >From an aesthetic point of view, I think it's bad that > > >>> there are > > >>> > > >>> > > >>>>> two SI > > >>> > > >>> > > >>> values (0 > > >>> > > >>> > > >>>> and 1) that cannot be used. > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> The real requirement, IMO, is that no device decrements 0 > and > > >>> > > >>> > > >>>> forwards > > >>> > > >>> > > NSH. > > >>> > > >>> > > >>>> Since only SFs decrement SI, only SFs need to do this > check. > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> And any discussion about buggy SFs... well there is a lot > > >>> of bad > > >>> > > >>> > > >>>> stuff that > > >>> > > >>> > > >>> bugs can > > >>> > > >>> > > >>>> cause. > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>> > > >>> > > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com > > >>> ] > > >>> > > >>> > > >>>> Sent: Thursday, February 09, 2017 2:54 PM > > >>> > > >>> > > >>>> To: Ron Parker; Dave Dolson > > >>> > > >>> > > >>>> Cc: Eric C Rosen; sfc@ietf.org ; > > >>> Dolganow, Andrew (Nokia - SG); > > >>> > > >>> > > >>>> James N > > >>> > > >>> > > >>> Guichard; > > >>> > > >>> > > >>>> Fabricio Ferraz > > >>> > > >>> > > >>>> Subject: Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> From my perspective as an individual participant in this > > >>> work, > > >>> > > >>> > > >>>> declaring that 0 must be dropped is a matter of robustness. > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> if we allow 0 to be processed for exit at an SFF, then a > > >>> > > >>> > > >>>> mis-configured SFF could easily continue processing such > > >>> a packet. > > >>> > > >>> > > >>>> Now, it is true that TTL will eventually drop it, but > > >>> that is an > > >>> > > >>> > expensive > > >>> > > >>> > > fallback. > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> More importantly, presumably the next entitiy down the > > >>> incorrect > > >>> > > >>> > > >>>> path would drop it for a 255 SI. But at that point we are > > >>> > > >>> > > >>>> getting the error in the wrong place, making it harder to > > >>> diagnose and > > >>> > > >>> > repair. > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> Yours, > > >>> > > >>> > > >>>> Joel > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>> On 2/9/17 12:42 PM, Ron Parker wrote: > > >>> > > >>> > > >>>>> agree. > > >>> > > >>> > > >>>>> > > >>> > > >>> > > >>>>> On Feb 9, 2017, at 12:28 PM, Dave Dolson > > >>> > > >>> > > >>> > > >>>>> > >>> >> wrote: > > >>> > > >>> > > >>>>> > > >>> > > >>> > > >>>>>> I'm not clear on why this is broken, or why this > > >>> restriction is made. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> I agree it should not be sent to an SF, but an SFF > > >>> could map an > > >>> > > >>> > > >>>>>> SI of zero into a path termination. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> I.e., the last SF in a path could decrement SI from 1 > > >>> to 0, and > > >>> > > >>> > > >>>>>> the SFF could then terminate the chain. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org > > >>> ] *On Behalf Of *James N > > >>> > > >>> > > >>>>>> Guichard > > >>> > > >>> > > >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM > > >>> > > >>> > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); > Dave > > >>> > > >>> > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > > >>> > > > >>> > > >>> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Not exactly. Section 3.3 specifies "The value zero for > > >>> SI is > > >>> > > >>> > > >>>>>> not valid and indicates a broken SFC or malfunctioning > > >>> SF" .. > > >>> > > >>> > > >>>>>> In other words an SF should never receive an NSH packet > > >>> with SI = 0. > > >>> > > >>> > > >>>>>> Note that if this happened then either a) a classifier > > >>> set the > > >>> > > >>> > > >>>>>> SI incorrectly, or b) a re-classifier set the SI > > >>> incorrectly, > > >>> > > >>> > > >>>>>> or c) an upstream SF set the SI incorrectly; all of > > >>> these cases > > >>> > > >>> > > >>>>>> should be caught by the SFF whose job it is to discard > NSH > > >>> > > >>> > > >>>>>> packets with SI = > > >>> > > >>> > 0. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Jim > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> *From:*Fabricio Ferraz > > >>> [mailto:fabricio-ferraz@telecom.pt > > >>> ] > > >>> > > >>> > > >>>>>> *Sent:* Thursday, February 09, 2017 11:49 AM > > >>> > > >>> > > >>>>>> *To:* James N Guichard > >>> > > >>> > > >>> > > >>>>>> > >>> >>; Dolganow, Andrew (Nokia > > >>> > > >>> > > >>>>>> - > > >>> > > >>> > > >>>>>> SG) > >>> > > >>> > > >>> > > >>>>>> > >>> >>; > > >>> > > >>> > > >>>> Dave > > >>> > > >>> > > >>>>>> Dolson > >>> > >>> >>; > > >>> > > >>> > > >>>>>> Eric C Rosen > >>> > >>> >>; > > >>> > > >>> > > >>>>>> sfc@ietf.org > >>> > > > >>> > > >>> > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Hi Jim, > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Thanks. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> One more question about the SI. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Section 3 states that: > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Service Index (SI): provides location within the SFP. The > > >>> > > >>> > > >>>>>> initial classifier MUST set the appropriate SI value for > a > > >>> > > >>> > > >>>>>> given classification result. The initial SI value > > >>> SHOULD default to > > >>> > > >>> 255. > > >>> > > >>> > > >>>>>> However, the classifier MUST allow configuration of > > >>> other SI values. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Service Index MUST be decremented by Service Functions > > >>> or by > > >>> > > >>> > > >>>>>> SFC Proxy nodes after performing required services and > > >>> the new > > >>> > > >>> > > >>>>>> decremented SI value MUST be used in the egress NSH > packet. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> The initial Classifier MUST send the packet to the > > >>> first SFF in > > >>> > > >>> > > >>>>>> the identified SFP for forwarding along an SFP. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> If re-classification occurs, and that re-classification > > >>> results > > >>> > > >>> > > >>>>>> in a new SPI, the (re)classifier is, in effect, the > initial > > >>> > > >>> > > >>>>>> classifier for the resultant SPI. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Thus: > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> a) Initial SI value should be 255 but other values > > >>> can be > > >>> > > >>> > > >>>>>> configured by the classifier. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> b) SF decrements the SI value on the egress NSH > packet > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> c) If re-classification occurs with new SPI, the > > >>> re-classifier > > >>> > > >>> > > >>>>>> is the initial classifier, so by a), SI should be > > >>> again 255 or > > >>> > > >>> > > >>>>>> other value > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> So any SI value can be receive by an SF, even 1 or 0 > > >>> because: > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> ?If SI=1 and there is no re-classification, the egress > > >>> NSH will > > >>> > > >>> > > >>>>>> have SI=0 > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> ?If SI=0 and there is re-classification with new SPI, the > > >>> > > >>> > > >>>>>> egress NSH will have a new SPI and a SI= 255 or other > > >>> value, as > > >>> > > >>> stated in > > >>> > > >>> > a). > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> ?If SI=0 and there is no re-classification the SF should > > >>> > > >>> > > >>>>>> discard the packet > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Also an SFF should forward/handle packets with NSH with > > >>> SI=1 or SI=0. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Do you agree? > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org > > >>> ] *On Behalf Of *James N > > >>> > > >>> > > >>>>>> Guichard > > >>> > > >>> > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 16:25 > > >>> > > >>> > > >>>>>> *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); > Dave > > >>> > > >>> > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org > > >>> > > > >>> > > >>> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Hi Fabricio, > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Welcome! > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Yes, removal of NSH is the responsibility of an SFF or a > > >>> > > >>> > > >>>>>> re-classifier (section 4, bullet point 1 lays this > > >>> out). With > > >>> > > >>> > > >>>>>> the current architecture the SF does not care what SI > > >>> value it > > >>> > > >>> > > >>>>>> gets, it just needs to worry about decrementing it, and > > >>> leave > > >>> > > >>> > > >>>>>> it up to the SFF to evaluate the SI value and > > >>> associated action. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Jim > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> *From:*Fabricio Ferraz > > >>> [mailto:fabricio-ferraz@telecom.pt > > >>> ] > > >>> > > >>> > > >>>>>> *Sent:* Thursday, February 09, 2017 7:13 AM > > >>> > > >>> > > >>>>>> *To:* Dolganow, Andrew (Nokia - SG) > > >>> > > >>> > > >>> > > >>>>>> > >>> >>; Dave Dolson > > >>> > > >>> > > >>>> > > >>> > > >>> > > >>>>>> > >>> >>; Eric C Rosen > > >>> > > >>> > > >>>>>> > > >>> >>; James N > > >>> > > >>> > > >>>>>> Guichard > >>> > > >>> > > >>> > > >>> > >>> >>; > > >>> > > >>> > > >>>>>> sfc@ietf.org > >>> > > > >>> > > >>> > > >>>>>> *Subject:* RE: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Hi all, > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> I'm new here (just read the draft last week) but > > >>> according to > > >>> > > >>> > > >>>>>> chapter > > >>> > > >>> > > >>>>>> 4 (check figure 8 for example), an SF is not allowed to > > >>> insert > > >>> > > >>> > > >>>>>> or remove NSH. The removal of NSH is reponsability of > > >>> the SSF, right? > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Figure 8 maps each of the four actions above to the > > >>> > > >>> > > >>>>>> components in the > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> SFC architecture that can perform it. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > +---------------+------------------+-------+----------------+---------+ > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> | | Insert |Select | Update > > >>> |Service > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> | | or remove NSH |Service| NSH > > >>> |policy > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> | | |Function| > > >>> > > >>> |selection| > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> | Component +--------+--------+Path > > >>> +----------------+ > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> | | | | | Dec. > > >>> |Update | > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> | | Insert | Remove | |Service > > >>> |Context| > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> | | | | | Index > > >>> |Header | > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > +----------------+--------+--------+-------+--------+-------+---------+ > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> | | + | + | | | > > >>> + | > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> |Classifier | | | | | > > >>> | > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> +--------------- > > >>> > > >>> > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> |Service Function| | + | + | | > > >>> | > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> |Forwarder(SFF) | | | | | > > >>> | > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> +--------------- > > >>> > > >>> > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> |Service | | | | + | > > >>> + | + > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> |Function (SF) | | | | | > > >>> | > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> +--------------- > > >>> > > >>> > > >>>>>> ++--------+--------+-------+--------+-------+---------+ > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> |SFC Proxy | + | + | | + | > > >>> | > > >>> > > >>> | > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > +----------------+--------+--------+-------+--------+-------+---------+ > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Figure 8: NSH Action and Role Mapping > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> An SF could receive an NSH packet with an SI of 1, and > > >>> > > >>> > > >>>>>> reclassify it to a different SPI and SI, right? So when > > >>> a SF > > >>> > > >>> > > >>>>>> receives a NSH packet with SI = 1 that does not > > >>> necessarily means a > > >>> > > >>> > non valid packet. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> And that can even work for SI=0, since you decrement > > >>> the SI in > > >>> > > >>> > > >>>>>> the > > >>> > > >>> > > >> egress. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Fabricio > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org > > >>> ] *On Behalf Of > > >>> > > >>> > > >>>>>> *Dolganow, Andrew (Nokia - SG) > > >>> > > >>> > > >>>>>> *Sent:* quinta-feira, 9 de fevereiro de 2017 01:51 > > >>> > > >>> > > >>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard; > > >>> sfc@ietf.org > > >>> > > >>> > > >>>>>> > > > >>> > > >>> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> I assumed that if we get value 1 we process then forward > > >>> > > >>> > > >>>>>> without NSH header (i.e.) this is the last SF processing. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> So with that assumption, a more explicit text would be: > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> An SF or SFC Proxy receiving an NSH-encapsulated packet > > >>> MUST > > >>> > > >>> > > >>>>>> decrement the SI by 1 after performing all required local > > >>> > > >>> > > >>>>>> processing and before forwarding the packet to the next > > >>> SFF. If > > >>> > > >>> > > >>>>>> the resulting SI is 0, the SF MUST remove the NSH > > >>> header before > > >>> > > >>> > > forwarding the packet. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Andrew > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> *From: *sfc > >>> > > >>> > > >>> > > >>>>>> > >>> >> on behalf of Dave Dolson > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>> >>> > > >>> > > >>> > > >>>>>> *Date: *Thursday, February 9, 2017 at 2:04 AM > > >>> > > >>> > > >>>>>> *To: *Eric Rosen > >>> > > >>> > > >>> > > >>>>>> > >>> >>, James N Guichard > > >>> > > >>> > > >>>>>> > >>> > > >>> > > >>> > > >>>>>> > >>> >>, "sfc@ietf.org > > >>> > > >>> > > >>> > > >>>>>> >" > > >>> > >>> >> > > >>> > > >>> > > >>>>>> *Subject: *Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Eric, > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> I was never quite happy with the outcome that neither 0 > > >>> nor 1 > > >>> > > >>> > > >>>>>> is a valid SI. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> (Because if received with value of 1, it is decremented > and > > >>> > > >>> > > >>>>>> discarded.) > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> It seems to waste an index value. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> I guess I'm interested to know if that is important to > > >>> other > > >>> > > >>> > > >>>>>> implementers, or if that was even the intention? > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> -Dave > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org > > >>> ] *On Behalf Of *Eric C > > >>> > > >>> > > >>>>>> Rosen > > >>> > > >>> > > >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM > > >>> > > >>> > > >>>>>> *To:* James N Guichard; sfc@ietf.org > > >>> > > > >>> > > >>> > > >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> On 2/7/2017 2:24 PM, James N Guichard wrote: > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> A request was made to be more specific and update the > > >>> text as > > >>> > > >>> > follows: > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> "Service index MUST be decremented *by a value of 1* by > > >>> Service > > >>> > > >>> > > >>>>>> Functions or by SFC Proxy nodes after performing > > >>> required services ." > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> A couple of observations: > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> - The term "SFC Proxy node" is not defined in either > > >>> the NSH > > >>> > > >>> > > >>>>>> draft or in RFC 7665. I think the intention here is to > say > > >>> > > >>> > > >>>>>> "SFC > > >>> > > >>> > Proxy". > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> - Is the intention that the SI remain unchanged while > > >>> the SF is > > >>> > > >>> > > >>>>>> operating on the packet, or is the intention only that > > >>> the SI > > >>> > > >>> > > >>>>>> be decremented before the packet is delivered by the SF > > >>> or SFC > > >>> > > >>> > > >>>>>> Proxy to an SFF? > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> I'd suggest either: > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated > > >>> packet MUST > > >>> > > >>> > > >>>>>> decrement the SI by 1 before delivering the packet to > > >>> the next SFF" > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> or > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> "An SF or SFC Proxy receiving an NSH-encapsulated > > >>> packet MUST > > >>> > > >>> > > >>>>>> decrement the SI by 1 before delivering the packet to > > >>> the next > > >>> > > >>> > > >>>>>> SFF, but not until the SF has finished all its other > > >>> processing > > >>> > > >>> > > >>>>>> of the > > >>> > > >>> > > packet" > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> depending upon which is intended. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> I think an implication of these procedures is that an > > >>> SI value > > >>> > > >>> > > >>>>>> of > > >>> > > >>> > > >>>>>> 1 is not valid. If an SF gets an NSH packet with an SI > > >>> of 1, > > >>> > > >>> > > >>>>>> the SF will decrement the SI (setting it to 0), send > > >>> the packet > > >>> > > >>> > > >>>>>> to an SFF, and the SFF will discard it, because 0 is an > > >>> invalid > > >>> > > >>> > > >>>>>> SI value. Is that the intention? > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> The draft makes it clear (well, sort of) that an SFF > should > > >>> > > >>> > > >>>>>> discard a packet with an SI of 0, but does not seem to > > >>> say that > > >>> > > >>> > > >>>>>> an SF or SFC Proxy should discard a packet it receives > > >>> with an > > >>> > > >>> > > >>>>>> SI of 0. It would probably be a good idea to say that. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> Some text in the draft (e.g., section 7.1) states than > > >>> an SFF > > >>> > > >>> > > >>>>>> should discard a packet with an SI of zero, but other > > >>> text in > > >>> > > >>> > > >>>>>> the draft (e.g., section 3.3) only says that an SFF > > >>> should log > > >>> > > >>> > > >>>>>> an error if it sees an SI of zero. It's probably best to > > >>> > > >>> > > >>>>>> change the text in 3.3. to say "SHOULD generate an > > >>> error/log > > >>> > > >>> > > >>>>>> message and MUST discard the packet", or something > similar. > > >>> > > >>> > > >>>>>> > > >>> > > >>> > > >>>>>> _______________________________________________ > > >>> > > >>> > > >>>>>> 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 > > > --94eb2c0939ce83eb8605485ae17b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Which is true ;-) .. a classifier *imposes* NSH which is not forwardin= g based on SPI/SI although you *could* co-locate SFF forwarding with the cl= assifier.

Jim
O= n Sun, Feb 12, 2017 at 2:59 PM Ron Parker <Ron_Parker@affirmednetworks.com> wrote:
Joel,



I was only referring to Jim's assertion that in the= SFC architecture only SFF forwards based on NSH.


=C2=A0 =C2=A0Ron

<= br class=3D"gmail_msg">


> On Feb 12, 2017= , at 2:56 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:

>

> Ron, I am missi= ng your point.

>

&= gt; There are a lot of ways to build a reclassifier.=C2=A0 It can have a co= -located SFF.=C2=A0 The information that drives the new NSH header content = can also specify the SFF to send the packet to.

= > I suppose the reclassifier could do all of its job, then look up in a = table (not one mandated by the spec) to decide where to sesnd the packet.
> However, any reclassifier which produces a p= acket with an SI of 0 is behaving pretty strangely.=C2=A0 Since it is requi= red to send the packet to an SFF, it is producing a packet knowing that the= packet will be immediately dropped, and may produce an error message.

>

> Yours,

> Joel

>

>> On 2/12/17 2:24 PM, Ron Parker wrote:

>> Jim,

>>

>> I also consider the (re-)classifier to also make (an= initial) forwarding

>> decision based on = NSH.

>>

>>= ;=C2=A0 =C2=A0Ron

>>

>> On Feb 12, 2017, at 9:07 AM, Jim Guichard <jguichar= d1966@gmail.com

>> <mailto:j= guichard1966@gmail.com>> wrote:

>&g= t;

>>> Hi Adrian,

>>>

>>> The point is an = SFF does not need to distinguish between receipt of a

>>> packet from an SF or SFF; the suggested text is relevant= to a device

>>> that forwards based on= NSH and in this architecture only an SFF does that.

>>>

>>> Jim

>>> On Sun, Feb 12, 2017 at 5:36 AM Adrian Farrel &l= t;adrian@olddog.co.uk

>>> <mai= lto:adrian@olddog.co.uk>> wrote:

>= ;>>

>>>=C2=A0 =C2=A0 Thanks Jim,<= br class=3D"gmail_msg">
>>>

>>= >

>>>

>= ;>>=C2=A0 =C2=A0 Your text works for me although I would prefer to de= lete the

>>>=C2=A0 =C2=A0 commentary ab= out a

>>>

&g= t;>>=C2=A0 =C2=A0 "broken SFC" as a specific example of how= this might happen that

>>>=C2=A0 =C2= =A0 is not the only

>>>

>>>=C2=A0 =C2=A0 case (for example, a broken reclassif= ier can also cause this).

>>>

>>>

>>>

>>>=C2=A0 =C2=A0 So, can we settle on

>>>

>>>=

>>>

>>= ;>=C2=A0 =C2=A0 "Packets received at an SFF with an SI of zero MUST= be discarded

>>>=C2=A0 =C2=A0 and the = SFF

>>>

>= >>=C2=A0 =C2=A0 SHOULD generate an error/log message."

>>>

>>>

>>>

>>>= ;=C2=A0 =C2=A0 BTW, I said

>>>

>>>=C2=A0 =C2=A0 >> Then (of course) it i= s also OK for an SFF to receive SI=3D0, but

>= >>=C2=A0 =C2=A0 I think the

>>>
>>>=C2=A0 =C2=A0 existing

>>>

>>>=C2=A0 =C2= =A0 >> "discard" text covers that case.

>>>

>>>=C2=A0 =C2=A0 a= nd you replied

>>>

>>>=C2=A0 =C2=A0 > from an SF yes but not from another S= FF.

>>>

>= >>=C2=A0 =C2=A0 and that (of course) has been a point of entertainmen= t for some while.

>>>

>>>=C2=A0 =C2=A0 Since an SFF cannot tell the difference= between a packet received

>>>=C2=A0 = =C2=A0 from an SFF

>>>

>>>=C2=A0 =C2=A0 and one from an SF we must document al= l cases alike.

>>>

>>>

>>>

>>>=C2=A0 =C2=A0 Fortunately, we're able to do so = for this instance.

>>>

>>>

>>>

>>>=C2=A0 =C2=A0 A

>= >>

>>>
>>>

>>>

>>>

>>>

>>>

>>>

>>>

>>>=C2=A0 = =C2=A0 > -----Original Message-----

>>&= gt;

>>>=C2=A0 =C2=A0 > From: James N= Guichard [mailto:james.n.guichard@huawei.com

>>>=C2=A0 =C2=A0 <mailto:james.n.guichard= @huawei.com>]

>>>

>>>=C2=A0 =C2=A0 > Sent: 12 February 2017 00:58
>>>

>>&g= t;=C2=A0 =C2=A0 > To: adrian@olddog.co.uk <mailto:adrian@oldd= og.co.uk>; 'Joel M.

>>>=C2= =A0 =C2=A0 Halpern'; 'Ron Parker'

&g= t;>>

>>>=C2=A0 =C2=A0 > Cc: sfc@iet= f.org <mailto:sfc@ietf.org>

>>>= ;

>>>=C2=A0 =C2=A0 > Subject: RE: [s= fc] NSH Service Index Decrement

>>>

>>>=C2=A0 =C2=A0 >

>>>

>>>=C2=A0 =C2=A0 &g= t; Hi Adrian,

>>>

>>>=C2=A0 =C2=A0 >

>>>= ;

>>>=C2=A0 =C2=A0 > Inline (hat off= opinion) ..

>>>

>>>=C2=A0 =C2=A0 >

>>>=

>>>=C2=A0 =C2=A0 > -----Original Me= ssage-----

>>>
<= br>>>>=C2=A0 =C2=A0 > From: sfc [mailto:sfc-bounces@ietf.org=

>>>=C2=A0 =C2=A0 <mailto:sfc= -bounces@ietf.org>] On Behalf Of Adrian Farrel

>>>

>>>=C2=A0 =C2=A0 >= ; Sent: Saturday, February 11, 2017 5:36 PM

>= >>

>>>=C2=A0 =C2=A0 > To: '= ;Joel M. Halpern' <jmh@joelhalpern.com
=
>>>=C2=A0 =C2=A0 <mailto:jmh@joelhalpern.com>>;= 'Ron Parker'

>>>

>>>=C2=A0 =C2=A0 > <Ron_Parker@a= ffirmednetworks.com

>>>=C2=A0 =C2= =A0 <mailto:Ron_Parker@affirmednetworks.com>>
>>>

>>&g= t;=C2=A0 =C2=A0 > Cc: sfc@ietf.org <mailto:sfc@ietf.org>

>>>

>>>=C2=A0 = =C2=A0 > Subject: Re: [sfc] NSH Service Index Decrement

>>>

>>>=C2=A0 =C2= =A0 >

>>>
>>>=C2=A0 =C2=A0 > Joel,

>>&g= t;

>>>=C2=A0 =C2=A0 >

>>>

>>>=C2=A0 =C2= =A0 > The -10 version of NSH says

>>>= ;

>>>=C2=A0 =C2=A0 >

>>>

>>>=C2=A0 =C2= =A0 >=C2=A0 =C2=A0 The

>>>

>>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 value zero f= or SI is not valid and indicates a broken SFC or
>>>

>>>=C2=A0 =C2=A0 >=C2= =A0 =C2=A0 malfunctioning SF.

>>>

>>>=C2=A0 =C2=A0 >

>>>

>>>=C2=A0 =C2=A0 >= Jim> the above text is perhaps what is causing some confusion as

>>>=C2=A0 =C2=A0 it implies an

>>>

>>>=C2=A0 =C2= =A0 SI

>>>

&= gt;>>=C2=A0 =C2=A0 > of 0 from an SF is invalid. May I suggest the= following text as

>>>=C2=A0 =C2=A0 a r= eplacement

>>>
<= br>>>>=C2=A0 =C2=A0 for

>>>
>>>=C2=A0 =C2=A0 > the above sentence:=

>>>

>>= ;>=C2=A0 =C2=A0 >

>>>

>>>=C2=A0 =C2=A0 > "The value zero for SI = indicates a broken SFC. Packets received

>>= ;>=C2=A0 =C2=A0 at an SFF with

>>>
>>>=C2=A0 =C2=A0 an

>>>

>>>=C2=A0 =C2=A0 &g= t; SI of zero MUST be discarded and the SFF SHOULD generate an

>>>=C2=A0 =C2=A0 error/log
<= br>>>>

>>>=C2=A0 =C2=A0 > m= essage".

>>>

>>>=C2=A0 =C2=A0 >

>>>= ;

>>>=C2=A0 =C2=A0 > You are saying = that the latter of these is not true.

>>&g= t;

>>>=C2=A0 =C2=A0 > I can't te= ll whether the former is really true or, perhaps,
>>>=C2=A0 =C2=A0 represents a

>>= ;>

>>>=C2=A0 =C2=A0 discard tail

>>>

>>>= ;=C2=A0 =C2=A0 > of an SFC where some (but not all) packets are reclassi= fied per Ron.

>>>

>>>=C2=A0 =C2=A0 >

>>>= ;

>>>=C2=A0 =C2=A0 > Like I said:
>>>

>>&g= t;=C2=A0 =C2=A0 >

>>>

>>>=C2=A0 =C2=A0 > > Let's clarify that it = is OK for an SF to send a packet with SI=3D0

>= ;>>

>>>=C2=A0 =C2=A0 >

>>>

>>>=C2= =A0 =C2=A0 > Then (of course) it is also OK for an SFF to receive SI=3D0= , but I

>>>=C2=A0 =C2=A0 think the

>>>

>>>= =C2=A0 =C2=A0 existing

>>>

>>>=C2=A0 =C2=A0 > "discard" text cove= rs that case.

>>>

>>>=C2=A0 =C2=A0 >

>>>= ;

>>>=C2=A0 =C2=A0 > Jim> from an= SF yes but not from another SFF. However, in either

>>>=C2=A0 =C2=A0 case, a

>>&= gt;

>>>=C2=A0 =C2=A0 lookup

>>>

>>>=C2=A0 = =C2=A0 > on <SPI><SI=3D0> should cause the SFF to discard th= e packet.

>>>=C2=A0 =C2=A0 Hopefully my= above

>>>

&= gt;>>=C2=A0 =C2=A0 > suggested text clarifies that.

>>>

>>>=C2=A0 =C2= =A0 >

>>>
>>>=C2=A0 =C2=A0 > Adrian

>>&= gt;

>>>=C2=A0 =C2=A0 >

>>>

>>>=C2=A0 = =C2=A0 > > -----Original Message-----

>= >>

>>>=C2=A0 =C2=A0 > > Fro= m: Joel M. Halpern [mailto:jmh@joelhalpern.com

>>>=C2=A0 =C2=A0 <mailto:jmh@joelhalpern.com>]
>>>

>>&g= t;=C2=A0 =C2=A0 > > Sent: 11 February 2017 18:08

>>>

>>>=C2=A0 =C2=A0 &g= t; > To: Ron Parker; adrian@olddog.co.uk
>>>=C2=A0 =C2=A0 <mailto:adrian@olddog.co.uk>; '= Dave Dolson'

>>>

>>>=C2=A0 =C2=A0 > > Cc: 'Eric C Rosen'; &#= 39;Dolganow, Andrew (Nokia - SG)';

>>&= gt;=C2=A0 =C2=A0 sfc@ietf.org <mailto:sfc@ietf.org>;

>>>

>>>=C2=A0 =C2=A0 = > > 'James N Guichard'; 'Fabricio Ferraz'

>>>

>>>=C2=A0 = =C2=A0 > > Subject: Re: [sfc] NSH Service Index Decrement

>>>

>>>=C2=A0 = =C2=A0 > >

>>>

>>>=C2=A0 =C2=A0 > > I was commenting, in personal = hat, about the issue of whether

>>>=C2= =A0 =C2=A0 there

>>>

>>>=C2=A0 =C2=A0 > > was some sort of problem with = the impact of the current

>>>=C2=A0 =C2= =A0 description on

>>>

>>>=C2=A0 =C2=A0 > > SI=3D1 packets arriving at a= n SF.=C2=A0 It seems to me that your example

>= ;>>

>>>=C2=A0 =C2=A0 > > sh= ows that such an effect is sometimes useul.

>= >>

>>>=C2=A0 =C2=A0 > > It = will also sometimes produce packet drops by the SFF, when

>>>=C2=A0 =C2=A0 the SF

>&= gt;>

>>>=C2=A0 =C2=A0 > > does= not terminate the packet.=C2=A0 Okay, so be it.
>>>

>>>=C2=A0 =C2=A0 > >= ; It is not even clear there is anything, in Adrian's phrase, to

>>>=C2=A0 =C2=A0 paint

>>>

>>>=C2=A0 =C2=A0 >= > red here.

>>>

>>>=C2=A0 =C2=A0 > >

>= >>

>>>=C2=A0 =C2=A0 > > You= rs,

>>>

>= >>=C2=A0 =C2=A0 > > Joel

>>>= ;

>>>=C2=A0 =C2=A0 > >

>>>

>>>=C2= =A0 =C2=A0 > > On 2/11/17 12:59 PM, Ron Parker wrote:

>>>

>>>=C2=A0 =C2= =A0 > > > Hi, Joel.

>>>

>>>=C2=A0 =C2=A0 > > >

>>>

>>>=C2=A0 = =C2=A0 > > > Does your comment pertain to my somewhat off topic qu= estion

>>>=C2=A0 =C2=A0 which

>>>

>>>=C2= =A0 =C2=A0 > > > was

>>>

>>>=C2=A0 =C2=A0 > > related to one of= Adrian's tangential issues, or to Adrian's
=
>>>=C2=A0 =C2=A0 original

>>&= gt;

>>>=C2=A0 =C2=A0 > > SF=3D1
>>>

>>&= gt;=C2=A0 =C2=A0 > topic?

>>>

>>>=C2=A0 =C2=A0 > > >

>>>

>>>=C2=A0 = =C2=A0 > > > Thanks.

>>>

>>>=C2=A0 =C2=A0 > > >

>>>

>>>=C2=A0 = =C2=A0 > > >=C2=A0 =C2=A0 Ron

>>&= gt;

>>>=C2=A0 =C2=A0 > > >

>>>

>>>= ;=C2=A0 =C2=A0 > > >

>>>

>>>=C2=A0 =C2=A0 > > > -----Origina= l Message-----

>>>

>>>=C2=A0 =C2=A0 > > > From: Joel M. Halpern [mail= to:jmh@joelhalpern.com

>>>=C2=A0 = =C2=A0 <mailto:jmh@joelhalpern.com>]
>>>

>>>=C2=A0 =C2=A0 > >= ; > Sent: Saturday, February 11, 2017 12:31 PM
>>>

>>>=C2=A0 =C2=A0 > &g= t; > To: Ron Parker <Ron_Parker@affirmednetworks.com

>>>=C2=A0 =C2=A0 <mailto:Ron_Parker@affirmednetworks.com>>;
=
>>>

>>>=C2=A0 =C2=A0 > = > > adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>= ;;

>>>

>&= gt;>=C2=A0 =C2=A0 > > 'Dave Dolson' <ddolson@sandvin= e.com <mailto:ddolson@sandvine.com>>

>>>

>>>=C2=A0 =C2=A0 = > > > Cc: 'Eric C Rosen' <erosen@juniper.net

>>>=C2=A0 =C2=A0 <mailto:erosen@juniper.= net>>; 'Dolganow, Andrew (Nokia - SG)'

>>>

>>>=C2=A0 =C2=A0 = > > <andrew.dolganow@nokia.com
=
>>>=C2=A0 =C2=A0 <mailto:andrew.dolganow@nokia.com<= /a>>>; sfc@ietf.org

>>>=C2=A0 =C2= =A0 <mailto:sfc@ietf.org>; 'James N Guichard'

>>>

>>>=C2=A0 =C2= =A0 > > <james.n.guichard@huawei.com

>>>=C2=A0 =C2=A0 <mailto:james.n.guichard= @huawei.com>>; 'Fabricio Ferraz'
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; <fabricio-ferraz@telecom.pt <mailto:fabrici= o-ferraz@telecom.pt>>

>>>

>>>=C2=A0 =C2=A0 > > > Subject: R= e: [sfc] NSH Service Index Decrement

>>>= ;

>>>=C2=A0 =C2=A0 > > >

>>>

>>>= =C2=A0 =C2=A0 > > > Personally, what you describe sounds like a qu= ite reasonable

>>>=C2=A0 =C2=A0 case
>>>

>>&g= t;=C2=A0 =C2=A0 > > > where a

>>&= gt;

>>>=C2=A0 =C2=A0 > > packet a= rrive at the SF with an SI of 1 will produce exactly the

>>>

>>>=C2=A0 =C2=A0 = > > desired

>>>

>>>=C2=A0 =C2=A0 > behavior.
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >

>>>
>>>=C2=A0 =C2=A0 > > > Which suggests, to my limited vie= w, that the current text

>>>=C2=A0 =C2= =A0 works fine.

>>>

>>>=C2=A0 =C2=A0 > > >
>>>

>>>=C2=A0 =C2=A0 > >= ; > Yours,

>>>

>>>=C2=A0 =C2=A0 > > > Joel
=
>>>

>>>=C2=A0 =C2=A0 > = > >

>>>
>>>=C2=A0 =C2=A0 > > > On 2/11/17 11:55 AM, Ron Parker = wrote:

>>>

&= gt;>>=C2=A0 =C2=A0 > > >> Hi, Adrian.

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>

>>>

>>>=C2=A0 =C2=A0 > > >> Not the original top= ic, per se, but wrt your comment:

>>>
>>>=C2=A0 =C2=A0 > > >>

>>>

>>>= =C2=A0 =C2=A0 > > >> * On the other hand, we appear to be clear= about an SF that

>>>=C2=A0 =C2=A0 stri= ps

>>>

>&= gt;>=C2=A0 =C2=A0 > > >> the NSH

= >>>

>>>=C2=A0 =C2=A0 > >= and forwards the traffic as native : this is currently forbidden.

>>>

>>>=C2= =A0 =C2=A0 > > >>

>>>

>>>=C2=A0 =C2=A0 > > >> I'm = wondering how to reconcile this to a transparent HTTP Proxy

>>>

>>>=C2=A0 =C2= =A0 > > >> that does

>>>
>>>=C2=A0 =C2=A0 > not

>>>

>>>=C2=A0 =C2= =A0 > > preserve the original source-IP?=C2=A0 =C2=A0Does this mean t= hat it is

>>>=C2=A0 =C2=A0 mandatory fo= r

>>>

>&g= t;>=C2=A0 =C2=A0 > such an

>>>
>>>=C2=A0 =C2=A0 > > SF to also be = a classifier so it can self-classify its own related

>>>

>>>=C2=A0 =C2=A0 >= > flows

>>>
=
>>>=C2=A0 =C2=A0 > (i.e., using its
=
>>>

>>>=C2=A0 =C2=A0 > = > own visible IP addresses)?=C2=A0 =C2=A0 From SFF perspective, it would=

>>>=C2=A0 =C2=A0 look like all

>>>

>>>=C2= =A0 =C2=A0 > packets

>>>

>>>=C2=A0 =C2=A0 > > on the access side are = dropped in the upstream direction and

>>&g= t;=C2=A0 =C2=A0 injected

>>>

>>>=C2=A0 =C2=A0 > > by the

>>>

>>>=C2=A0 = =C2=A0 > SF

>>>

>>>=C2=A0 =C2=A0 > > in the downstream direction.=C2= =A0 =C2=A0On the Internet side, it would

>>= ;>=C2=A0 =C2=A0 look like all

>>>
>>>=C2=A0 =C2=A0 > packets

>>>

>>>=C2=A0 = =C2=A0 > > are injected by the SF in the upstream direction and dropp= ed

>>>=C2=A0 =C2=A0 in the

>>>

>>>=C2=A0 = =C2=A0 > > downstream direction.

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>=

>>>

>>= ;>=C2=A0 =C2=A0 > > >> Thanks for any clarification.

>>>

>>>=C2= =A0 =C2=A0 > > >>

>>>

>>>=C2=A0 =C2=A0 > > >>=C2=A0 = =C2=A0 Ron

>>>
<= br>>>>=C2=A0 =C2=A0 > > >>

= >>>

>>>=C2=A0 =C2=A0 > >= >>

>>>
>>>=C2=A0 =C2=A0 > > >>

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >> -----Original Message-----

>>>=

>>>=C2=A0 =C2=A0 > > >> Fr= om: Adrian Farrel [mailto:adrian@olddog.co.uk
=
>>>=C2=A0 =C2=A0 <mailto:adrian@olddog.co.uk>]

>>>

>>>= ;=C2=A0 =C2=A0 > > >> Sent: Saturday, February 11, 2017 11:34 A= M

>>>

>&g= t;>=C2=A0 =C2=A0 > > >> To: 'Dave Dolson' <ddo= lson@sandvine.com

>>>=C2=A0 =C2=A0 = <mailto:ddolson@sandvine.com>>; 'Joel M. Halpern'
>>>

>>&= gt;=C2=A0 =C2=A0 > > >> <jmh@joelhalpern.com <mailt= o:jmh@joelhalpern.com>>; Ron Parker

= >>>

>>>=C2=A0 =C2=A0 > <= Ron_Parker@affirmednetworks.com
>>>=C2=A0 =C2=A0 <mailto:Ron_Parker@affirmednet= works.com>>

>>>

>>>=C2=A0 =C2=A0 > > >> Cc: 'Eric C = Rosen' <erosen@juniper.net

>>&= gt;=C2=A0 =C2=A0 <mailto:erosen@juniper.net>>; 'Dolganow,= Andrew (Nokia -

>>>

>>>=C2=A0 =C2=A0 > > >> SG)' <andrew.dolganow@nokia.com

>>>=C2= =A0 =C2=A0 <mailto:andrew.dolganow@nokia.com>>; sfc@ietf.or= g

>>>=C2=A0 =C2=A0 <mailto:sfc@ietf.o= rg>; 'James N Guichard'

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= <james.n.guichard@huawei.com

&= gt;>>=C2=A0 =C2=A0 <mailto:james.n.guichard@huawei.com>>; 'Fabricio Ferraz'

>>&g= t;

>>>=C2=A0 =C2=A0 > > >> = <fabricio-ferraz@telecom.pt

>= >>=C2=A0 =C2=A0 <mailto:fabricio-ferraz@telecom.pt>= ;>

>>>

&g= t;>>=C2=A0 =C2=A0 > > >> Subject: RE: [sfc] NSH Service I= ndex Decrement

>>>

>>>=C2=A0 =C2=A0 > > >>
=
>>>

>>>=C2=A0 =C2=A0 > = > >> I hate to do my impersonation of Eric, but...

>>>

>>>=C2=A0 =C2= =A0 > > >>

>>>

>>>=C2=A0 =C2=A0 > > >> "On the wi= re" is the crunch.

>>>

>>>=C2=A0 =C2=A0 > > >>

>>>

>>>=C2=A0 =C2= =A0 > > >> Some have said that there must be no visible differe= nce

>>>=C2=A0 =C2=A0 between the

>>>

>>>= =C2=A0 =C2=A0 > > >> three

>>&= gt;

>>>=C2=A0 =C2=A0 > > case:
>>>

>>&g= t;=C2=A0 =C2=A0 > > >> - on the wire between SFF and SF

>>>

>>>=C2= =A0 =C2=A0 > > >> - on the wire between SF and SFF

>>>

>>>=C2=A0 = =C2=A0 > > >> - on the wire between SFF and SFF

>>>

>>>=C2=A0 =C2= =A0 > > >>

>>>

>>>=C2=A0 =C2=A0 > > >> If this holds t= hen you are correct that sending SI=3D1 in the

&= gt;>>=C2=A0 =C2=A0 first

>>>

>>>=C2=A0 =C2=A0 > > >> case
>>>

>>&g= t;=C2=A0 =C2=A0 > requires

>>>

>>>=C2=A0 =C2=A0 > > the SF to do more= than a simple decrement (although decrement and
>>>

>>>=C2=A0 =C2=A0 > >= ; discard is hardly painful). And it means that SI=3D1 is a

>>>=C2=A0 =C2=A0 dubious value in an

>>>

>>>=C2=A0 =C2=A0= SFP.

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>

>&= gt;>

>>>=C2=A0 =C2=A0 > > >= > On the other hand, we appear to be clear about an SF that

>>>=C2=A0 =C2=A0 strips

= >>>

>>>=C2=A0 =C2=A0 > >= >> the NSH

>>>

>>>=C2=A0 =C2=A0 > and

>= ;>>

>>>=C2=A0 =C2=A0 > > fo= rwards the traffic as native : this is currently forbidden.

>>>=C2=A0 =C2=A0 So there

&= gt;>>

>>>=C2=A0 =C2=A0 > > = is no alternative for an SF receiving SI=3D1 except to discard

>>>=C2=A0 =C2=A0 the packet.

>>>

>>>=C2=A0 =C2=A0 >= > >>

>>>

>>>=C2=A0 =C2=A0 > > >> Now, does that mean tha= t an SFF should never send a packet with

>>= ;>

>>>=C2=A0 =C2=A0 > > >&g= t; SI=3D1? Well,

>>>

>>>=C2=A0 =C2=A0 > > possibly it is OK for a few sp= ecialist SFs intended to sit at

>>>=C2= =A0 =C2=A0 the end

>>>

>>>=C2=A0 =C2=A0 > > of the

>>>

>>>=C2=A0 =C2=A0 >= ; chain and

>>>
=
>>>=C2=A0 =C2=A0 > > be a bit bucket with analysis. But,= for most SFs there would

>>>=C2=A0 =C2= =A0 be no point.

>>>

>>>=C2=A0 =C2=A0 > > >>

>>>

>>>=C2=A0 =C2=A0 >= ; > >> Maybe (just maybe) we should stop letting the tail wag the = dog!

>>>

>= ;>>=C2=A0 =C2=A0 > > >> That is,
<= br>>>>

>>>=C2=A0 =C2=A0 > l= et's

>>>
>>>=C2=A0 =C2=A0 > > decide on the functional behavior we w= ant to see and then

>>>=C2=A0 =C2=A0 de= sign the

>>>
>>>=C2=A0 =C2=A0 > > protocol to match.

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>

>>>

>>>=C2=A0 =C2=A0 > > >> Adrian

>>>

>>>=C2=A0 = =C2=A0 > > >>

>>>

>>>=C2=A0 =C2=A0 > > >>> -----Or= iginal Message-----

>>>

>>>=C2=A0 =C2=A0 > > >>> From: Dave Dol= son [mailto:ddolson@sandvine.com

>>= >=C2=A0 =C2=A0 <mailto:ddolson@sandvine.com>]

>>>

>>>=C2=A0 = =C2=A0 > > >>> Sent: 10 February 2017 22:26

>>>

>>>=C2=A0 =C2= =A0 > > >>> To: adrian@olddog.co.uk <mailto:adria= n@olddog.co.uk>;

>>>=C2=A0 =C2= =A0 'Joel M. Halpern'; 'Ron Parker'
=
>>>

>>>=C2=A0 =C2=A0 > = > >>> Cc: 'Eric C Rosen'; 'Dolganow, Andrew (Nokia = - SG)';

>>>=C2=A0 =C2=A0 sfc@ietf.org <mailto:sfc@ietf.org>;

>>>

>>>=C2=A0 =C2=A0 > > >>> '= ;James N Guichard'; 'Fabricio Ferraz'
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>> Subject: RE: [sfc] NSH Service Index Decrement

>>>

>>>=C2=A0 = =C2=A0 > > >>>

>>>

>>>=C2=A0 =C2=A0 > > >>> Adri= an,

>>>

>= >>=C2=A0 =C2=A0 > > >>> I think I agree with everythin= g you said.

>>>
=
>>>=C2=A0 =C2=A0 > > >>> But you did not sugges= t whether or not you think that SI=3D0

>>&= gt;=C2=A0 =C2=A0 should

>>>

>>>=C2=A0 =C2=A0 > > >>> be valid o= n

>>>

>&g= t;>=C2=A0 =C2=A0 > > >> the

>&= gt;>

>>>=C2=A0 =C2=A0 > > >= >> wire.

>>>

>>>=C2=A0 =C2=A0 > > >>> I'm saying it c= ould work, if the next hop is a path terminus.

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >>>

>>>

>>>=C2=A0 =C2=A0 > > >>> If I understand Joel = correctly, he says we shouldn't send

>>= ;>=C2=A0 =C2=A0 SI=3D0=C2=A0 in

>>><= br class=3D"gmail_msg">
>>>=C2=A0 =C2=A0 > > >>>= case the

>>>
>>>=C2=A0 =C2=A0 > > >> next
=
>>>

>>>=C2=A0 =C2=A0 > = > >>> hop blindly decrements it.

>= ;>>

>>>=C2=A0 =C2=A0 > > &g= t;>> --> this seems to mean SI=3D1 cannot be used except at the
>>>=C2=A0 =C2=A0 terminus

>>>

>>>=C2=A0 =C2= =A0 > > >>> --> or when the

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>> SF is expected to drop all packets.

= >>>

>>>=C2=A0 =C2=A0 > >= >>> So I think this is an unnecessary seat belt, trying to

>>>=C2=A0 =C2=A0 anticipate

>>>

>>>=C2=A0 =C2=A0= > > >>> bugs in

>>>

>>>=C2=A0 =C2=A0 > > >> down-<= br class=3D"gmail_msg">
>>>

>>= >=C2=A0 =C2=A0 > > >>> stream devices.

>>>

>>>=C2=A0 =C2=A0 = > > >>>

>>>

>>>=C2=A0 =C2=A0 > > >>> I realize t= he current language has been there a long time,

= >>>=C2=A0 =C2=A0 and if

>>>
>>>=C2=A0 =C2=A0 > > >>> i= t is

>>>

>= ;>>=C2=A0 =C2=A0 > > >> important to

>>>

>>>=C2=A0 =C2=A0 &g= t; > >>> anyone then it should remain.
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >>> Nonetheless, I think devices could safely handle SI=3D0 on=

>>>=C2=A0 =C2=A0 the wire

>>>

>>>=C2=A0 = =C2=A0 > > >>> without breaking anything.

>>>

>>>=C2=A0 =C2=A0 = > > >>>

>>>

>>>=C2=A0 =C2=A0 > > >>> But I'm= not pushing for a change, since the current

>= ;>>=C2=A0 =C2=A0 behavior seems

>>&g= t;

>>>=C2=A0 =C2=A0 > > >>&= gt; important

>>>

>>>=C2=A0 =C2=A0 > > >> to

>>>

>>>=C2=A0 =C2=A0 >= ; > >>> some.

>>>

>>>=C2=A0 =C2=A0 > > >>>

>>>

>>>=C2= =A0 =C2=A0 > > >>> -Dave

>>= >

>>>=C2=A0 =C2=A0 > > >>= ;>

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >>> -----Original Message-----

>>= >

>>>=C2=A0 =C2=A0 > > >>= ;> From: sfc [mailto:sfc-bounces@ietf.org
=
>>>=C2=A0 =C2=A0 <mailto:sfc-bounces@ietf.org>] O= n Behalf Of Adrian Farrel

>>>

>>>=C2=A0 =C2=A0 > > >>> Sent: F= riday, February 10, 2017 9:16 AM

>>>
>>>=C2=A0 =C2=A0 > > >>> T= o: Dave Dolson; 'Joel M. Halpern'; 'Ron Parker'

>>>

>>>=C2=A0 = =C2=A0 > > >>> Cc: 'Eric C Rosen'; 'Dolganow, An= drew (Nokia - SG)';

>>>=C2=A0 =C2= =A0 s= fc@ietf.org <mailto:sfc@ietf.org>;

>= >>

>>>=C2=A0 =C2=A0 > > >= ;>> 'James N Guichard'; 'Fabricio Ferraz'

>>>

>>>=C2=A0 = =C2=A0 > > >>> Subject: Re: [sfc] NSH Service Index Decremen= t

>>>

>&g= t;>=C2=A0 =C2=A0 > > >>>

>&= gt;>

>>>=C2=A0 =C2=A0 > > >= >> Oh, you finally pushed me into this discussion, Dave.

>>>

>>>=C2=A0 = =C2=A0 > > >>>

>>>

>>>=C2=A0 =C2=A0 > > >>> We&#= 39;re building a protocol. with a protocol, you cannot

>>>=C2=A0 =C2=A0 (must not)

>= >>

>>>=C2=A0 =C2=A0 > > >= ;>> assume good behavior from your neighbor.
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >>>

>>>

>>>=C2=A0 =C2=A0 > > >>> So if the SF touc= hes the SI (which it does) we must define the

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>> edge

>>>

>>>=C2=A0 =C2=A0 > > >> conditions.

>>>

>>>=C2= =A0 =C2=A0 > > >>> If it is the SF's job to decrement th= e SI, then we must also

>>>

>>>=C2=A0 =C2=A0 > > >>> define wha= t it

>>>

>= ;>>=C2=A0 =C2=A0 > > >> does

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >>> when SI=3D0 (otherwise, it will set SI to 0-1).

>>>

>>>=C2=A0 =C2= =A0 > > >>> If the SF is not allowed to decrement the SI bel= ow zero (which

>>>

>>>=C2=A0 =C2=A0 > > >>> makes

>>>

>>>=C2=A0 = =C2=A0 > > >>> sense) we must define what it must do.

>>>

>>>= =C2=A0 =C2=A0 > > >>> Since SFs are allowed to drop packets = (indeed that is one

>>>=C2=A0 =C2=A0 of= their

>>>

&= gt;>>=C2=A0 =C2=A0 > > >>> main jobs

>>>

>>>=C2=A0 =C2=A0= > > >> ;-)

>>>

>>>=C2=A0 =C2=A0 > > >>> then this = would be fine.

>>>

>>>=C2=A0 =C2=A0 > > >>> All that would be l= eft is to define whether they apply the

>>= >=C2=A0 =C2=A0 test

>>>

>>>=C2=A0 =C2=A0 > > >>> before or
>>>

>>&= gt;=C2=A0 =C2=A0 > > >> after

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;> normal processing.

>>>

>>>=C2=A0 =C2=A0 > > >>>

>>>

>>>=C2= =A0 =C2=A0 > > >>> As an aside, I agree with Don that TTL he= lps relax this a

>>>=C2=A0 =C2=A0 littl= e,

>>>

>&= gt;>=C2=A0 =C2=A0 > > >>> but does not get us all the way= there.

>>>

= >>>=C2=A0 =C2=A0 > > >>>
>>>

>>>=C2=A0 =C2=A0 > >= ; >>> Cheers,

>>>

>>>=C2=A0 =C2=A0 > > >>> Adrian

>>>

>>>= =C2=A0 =C2=A0 > > >>>

>>>= ;

>>>=C2=A0 =C2=A0 > > >>&g= t;> -----Original Message-----

>>>
>>>=C2=A0 =C2=A0 > > >>>&= gt; From: sfc [mailto:sfc-bounces@ietf.org
>>>=C2=A0 =C2=A0 <mailto:sfc-bounces@ietf.org>] On = Behalf Of Dave Dolson

>>>

>>>=C2=A0 =C2=A0 > > >>>> Sent: 09= February 2017 21:00

>>>

>>>=C2=A0 =C2=A0 > > >>>> To: Joel = M. Halpern; Ron Parker

>>>

>>>=C2=A0 =C2=A0 > > >>>> Cc: Fab= ricio Ferraz; James N Guichard; sfc@ietf.org

>= >>=C2=A0 =C2=A0 <mailto:sfc@ietf.org>; Eric C

>>>

>>>=C2=A0 =C2=A0 = > > >>>> Rosen; Dolganow, Andrew (Nokia - SG)

>>>

>>>=C2=A0 = =C2=A0 > > >>>> Subject: Re: [sfc] NSH Service Index Decr= ement

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>>
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >>>> Discussing misconfigured SFFs is a straw-man argument.=

>>>=C2=A0 =C2=A0 Once one

>>>

>>>=C2=A0 = =C2=A0 > > >>>> starts

>>= ;>

>>>=C2=A0 =C2=A0 > > >&g= t; trying

>>>
>>>=C2=A0 =C2=A0 > > >>> to

>>>

>>>=C2=A0 =C2=A0 >= ; > >>>> anticipate down-stream devices being misconfigured,= one can

>>>
>>>=C2=A0 =C2=A0 > > >>>> invent a lot of

>>>

>>>= =C2=A0 =C2=A0 > > >>> silly

>&= gt;>

>>>=C2=A0 =C2=A0 > > >= >>> requirements.

>>>

>>>=C2=A0 =C2=A0 > > >>>>

>>>

>>>= ;=C2=A0 =C2=A0 > > >>>> >From an aesthetic point of vi= ew, I think it's bad that

>>>=C2=A0= =C2=A0 there are

>>>

>>>=C2=A0 =C2=A0 > > >>>>> two SI
>>>

>>&= gt;=C2=A0 =C2=A0 > > >>> values (0
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>>> and 1) that cannot be used.

= >>>

>>>=C2=A0 =C2=A0 > >= >>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>> The real req= uirement, IMO, is that no device decrements 0 and
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>>> forwards

>>>

>>>=C2=A0 =C2=A0 > > NSH.

>>>

>>>=C2=A0 = =C2=A0 > > >>>> Since only SFs decrement SI, only SFs nee= d to do this check.

>>>

>>>=C2=A0 =C2=A0 > > >>>>

>>>

>>>=C2= =A0 =C2=A0 > > >>>> And any discussion about buggy SFs...= well there is a lot

>>>=C2=A0 =C2=A0 o= f bad

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>> stuff that

>>>

>>>=C2=A0 = =C2=A0 > > >>> bugs can

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >> cause.

>>>

>>>=C2=A0 =C2=A0 > > >>>>

>>>

>>>=C2=A0 =C2= =A0 > > >>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>=

>>>

>>= ;>=C2=A0 =C2=A0 > > >>>> -----Original Message-----
>>>

>>&g= t;=C2=A0 =C2=A0 > > >>>> From: Joel M. Halpern [mailto:= jmh@joelhalpern.com

>>>=C2=A0 =C2= =A0 <mailto:jmh@joelhalpern.com>]

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>> Sent: Thursday, February 09, 2017 2:54 PM

>>>

>>>=C2=A0 =C2=A0= > > >>>> To: Ron Parker; Dave Dolson

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>>> Cc: Eric C Rosen; sfc@ietf.org <mailto:sfc@ietf.org= >;

>>>=C2=A0 =C2=A0 Dolganow, An= drew (Nokia - SG);

>>>

>>>=C2=A0 =C2=A0 > > >>>> James N

>>>

>>>= ;=C2=A0 =C2=A0 > > >>> Guichard;

= >>>

>>>=C2=A0 =C2=A0 > >= >>>> Fabricio Ferraz

>>>
>>>=C2=A0 =C2=A0 > > >>>&= gt; Subject: Re: [sfc] NSH Service Index Decrement
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>=C2=A0 Fro= m my perspective as an individual participant in this

>>>=C2=A0 =C2=A0 work,

>>&g= t;

>>>=C2=A0 =C2=A0 > > >>&= gt;> declaring that 0 must be dropped is a matter of robustness.

>>>

>>>=C2= =A0 =C2=A0 > > >>>>

>>&g= t;

>>>=C2=A0 =C2=A0 > > >>&= gt;> if we allow 0 to be processed for exit at an SFF, then a

>>>

>>>=C2= =A0 =C2=A0 > > >>>> mis-configured SFF could easily conti= nue processing such

>>>=C2=A0 =C2=A0 a = packet.

>>>

= >>>=C2=A0 =C2=A0 > > >>>> Now, it is true that T= TL will eventually drop it, but

>>>=C2= =A0 =C2=A0 that is an

>>>

>>>=C2=A0 =C2=A0 > expensive

>>>

>>>=C2=A0 =C2=A0 &g= t; > fallback.

>>>

>>>=C2=A0 =C2=A0 > > >>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>> More importantly, presumably the next ent= itiy down the

>>>=C2=A0 =C2=A0 incorrec= t

>>>

>&g= t;>=C2=A0 =C2=A0 > > >>>> path would drop it for a 255= SI.=C2=A0 But at that point we are

>>>=

>>>=C2=A0 =C2=A0 > > >>>= ;> getting the error in the wrong place, making it harder to

>>>=C2=A0 =C2=A0 diagnose and

>>>

>>>=C2=A0 =C2=A0 &g= t; repair.

>>>
<= br>>>>=C2=A0 =C2=A0 > > >>>>

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>>> Yours,

>>>
>>>=C2=A0 =C2=A0 > > >>>&g= t; Joel

>>>

= >>>=C2=A0 =C2=A0 > > >>>>

>>>

>>>=C2=A0 =C2=A0 >= > >>>> On 2/9/17 12:42 PM, Ron Parker wrote:

>>>

>>>=C2=A0 =C2= =A0 > > >>>>> agree.

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>> On Feb 9, = 2017, at 12:28 PM, Dave Dolson

>>>=C2= =A0 =C2=A0 <ddolson@sandvine.com <mailto:ddolson@sandvine.c= om>

>>>
<= br>>>>=C2=A0 =C2=A0 > > >>>>> <mailto:d= dolson@sandvine.com

>>>=C2=A0 =C2= =A0 <mailto:ddolson@sandvine.com>>> wrote:

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>

>>&g= t;

>>>=C2=A0 =C2=A0 > > >>&= gt;>>> I'm not clear on why this is broken, or why this

>>>=C2=A0 =C2=A0 restriction is made.

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>> I agree it should not be sent to an SF, but an SFF<= br class=3D"gmail_msg">
>>>=C2=A0 =C2=A0 could map an

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> SI of zero into a path termin= ation.

>>>

&= gt;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>> I.e., the last SF in a path could de= crement SI from 1

>>>=C2=A0 =C2=A0 to 0= , and

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>>>> the SFF could th= en terminate the chain.

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>= ;

>>>

>&g= t;>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 &g= t; > >>>>>>

>>>
>>>=C2=A0 =C2=A0 > > >>>&g= t;>>

>>>
<= br>>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>> *From:*sfc [mailto:sfc-bounces= @ietf.org

>>>=C2=A0 =C2=A0 <mail= to:sfc-bounces@ietf.org>] *On Behalf Of *James N

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>> Guichard

= >>>

>>>=C2=A0 =C2=A0 > >= >>>>>> *Sent:* Thursday, February 09, 2017 12:02 PM

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>> *To:* Fabricio Ferraz; Dol= ganow, Andrew (Nokia - SG); Dave

>>>
>>>=C2=A0 =C2=A0 > > >>>&g= t;>> Dolson; Eric C Rosen; sfc@ietf.org

>= ;>>=C2=A0 =C2=A0 <mailto:sfc@ietf.org> <mailto:sfc@ietf.org &l= t;mailto:sfc@ietf.org>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>&g= t;> *Subject:* Re: [sfc] NSH Service Index Decrement

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>>>>>

>>>
>>>=C2=A0 =C2=A0 > > >>>&= gt;>>

>>>
=
>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> Not exactly. Section 3.3 spec= ifies "The value zero for

>>>=C2= =A0 =C2=A0 SI is

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> not v= alid and indicates a broken SFC or malfunctioning
>>>=C2=A0 =C2=A0 SF" ..

>>= >

>>>=C2=A0 =C2=A0 > > >>= ;>>>> In other words an SF should never receive an NSH packet
>>>=C2=A0 =C2=A0 with SI =3D 0.

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> Note that if this happened th= en either a) a classifier

>>>=C2=A0 =C2= =A0 set the

>>>
=
>>>=C2=A0 =C2=A0 > > >>>>>> SI incorre= ctly, or b) a re-classifier set the SI

>>&= gt;=C2=A0 =C2=A0 incorrectly,

>>>

>>>=C2=A0 =C2=A0 > > >>>>&= gt;> or c) an upstream SF set the SI incorrectly; all of

>>>=C2=A0 =C2=A0 these cases
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>>>>> should be caught by the SFF whose job it is to = discard NSH

>>>
=
>>>=C2=A0 =C2=A0 > > >>>>>> packets wi= th SI =3D

>>>
>>>=C2=A0 =C2=A0 > 0.

>>>=

>>>=C2=A0 =C2=A0 > > >>>= ;>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>> Jim

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= ;>

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>>

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>> *From:*Fabricio Ferraz

>>= >=C2=A0 =C2=A0 [mailto:fabricio-ferraz@telecom.pt

>>>=C2=A0 =C2=A0 <mailto:fabricio-f= erraz@telecom.pt>]

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > *Sent:* Thursday, February 09, 2017 11:49 AM
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>>>>> *To:* James N Guichard <james.n.gu= ichard@huawei.com

>>>=C2=A0 =C2=A0 = <mailto:james.n.guichard@huawei.com>

>>>

>>>=C2=A0 =C2=A0 = > > >>>>>> <mailto:james.n.guichard@hu= awei.com

>>>=C2=A0 =C2=A0 <mailt= o:james.n.guichard@huawei.com>>>; Dolganow, Andrew (= Nokia

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>>>> -

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>> SG) <andrew.dolganow@noki= a.com

>>>=C2=A0 =C2=A0 <mailto:<= a href=3D"mailto:andrew.dolganow@nokia.com" class=3D"gmail_msg" target=3D"_= blank">andrew.dolganow@nokia.com>

>>= ;>

>>>=C2=A0 =C2=A0 > > >&g= t;>>>> <mailto:andrew.dolganow@nokia.com

>>>=C2=A0 =C2=A0 <mailto:andrew.dol= ganow@nokia.com>>>;

>>>
>>>=C2=A0 =C2=A0 > > >>>&g= t; Dave

>>>

= >>>=C2=A0 =C2=A0 > > >>>>>> Dolson <= ddolson@sandvine.com

>>>=C2=A0 =C2= =A0 <mailto:ddolson@sandvine.com> <mailto:ddolson@sandvi= ne.com

>>>=C2=A0 =C2=A0 <mailto:= ddolson@sandvine.com>>>;

>>= ;>

>>>=C2=A0 =C2=A0 > > >&g= t;>>>> Eric C Rosen <erosen@juniper.net

>>>=C2=A0 =C2=A0 <mailto:erosen@juniper.net>= ; <mailto:erosen@juniper.net

>>>= ;=C2=A0 =C2=A0 <mailto:erosen@juniper.net>>>;

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>> sfc@ietf.org <mailto:sfc@ietf.org> <mailto:sfc@ietf.org

>>>=C2=A0 = =C2=A0 <mailto:sfc@ietf.org>>

>>&g= t;

>>>=C2=A0 =C2=A0 > > >>&= gt;>>> *Subject:* RE: [sfc] NSH Service Index Decrement

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>= ;

>>>

>&g= t;>=C2=A0 =C2=A0 > > >>>>>> Hi Jim,

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>> Thanks.

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= ;>

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>>

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>> One more question about the SI.
>>>

>>>=C2=A0 =C2=A0 > >= ; >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= >

>>>

>= ;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0= > > >>>>>> Section 3 states that:

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>>

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>> Service Index (SI): provid= es location within the SFP. The

>>>

>>>=C2=A0 =C2=A0 > > >>>>= ;>> initial classifier MUST set the appropriate SI value for a

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>> given classification resul= t. The initial SI value

>>>=C2=A0 =C2= =A0 SHOULD default to

>>>

>>>=C2=A0 =C2=A0 255.

>= ;>>

>>>=C2=A0 =C2=A0 > > &g= t;>>>>> However, the classifier MUST allow configuration of<= br class=3D"gmail_msg">
>>>=C2=A0 =C2=A0 other SI values.

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>>
>>>

>>>=C2=A0 =C2=A0 > >= ; >>>>>> Service Index MUST be decremented by Service Fun= ctions

>>>=C2=A0 =C2=A0 or by

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> SFC Proxy nodes after perform= ing required services and

>>>=C2=A0 =C2= =A0 the new

>>>
=
>>>=C2=A0 =C2=A0 > > >>>>>> decremente= d SI value MUST be used in the egress NSH packet.
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= ;> The initial Classifier MUST send the packet to the

>>>=C2=A0 =C2=A0 first SFF in

= >>>

>>>=C2=A0 =C2=A0 > >= >>>>>> the identified SFP for forwarding along an SFP.
>>>

>>&= gt;=C2=A0 =C2=A0 > > >>>>>>
=
>>>

>>>=C2=A0 =C2=A0 > = > >>>>>> If re-classification occurs, and that re-clas= sification

>>>=C2=A0 =C2=A0 results

>>>

>>>= ;=C2=A0 =C2=A0 > > >>>>>> in a new SPI, the (re)cla= ssifier is, in effect, the initial

>>><= br class=3D"gmail_msg">
>>>=C2=A0 =C2=A0 > > >>>= >>> classifier for the resultant SPI.

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= >

>>>

>= ;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0= > > >>>>>> Thus:

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> a)= =C2=A0 =C2=A0 =C2=A0 Initial SI value should be 255 but other values

>>>=C2=A0 =C2=A0 can be

>>>

>>>=C2=A0 =C2=A0 >= ; > >>>>>> configured by the classifier.

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>> b)=C2=A0 =C2=A0 =C2=A0 SF decrements the SI value on th= e egress NSH packet

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>
>>>

>>&g= t;=C2=A0 =C2=A0 > > >>>>>> c)=C2=A0 =C2=A0 =C2=A0 = =C2=A0If re-classification occurs with new SPI, the
=
>>>=C2=A0 =C2=A0 re-classifier

>= >>

>>>=C2=A0 =C2=A0 > > >= ;>>>>> is the initial classifier, so by=C2=A0 a), SI should = be

>>>=C2=A0 =C2=A0 again 255 or

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>> other value

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>>

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>> So any SI value can be rec= eive by an SF, even 1 or 0

>>>=C2=A0 = =C2=A0 because:

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>> ?If SI=3D1 and there is no= re-classification, the egress

>>>=C2= =A0 =C2=A0 NSH will

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> ha= ve SI=3D0

>>>
>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>> ?If SI=3D0 and there is re-classi= fication with new SPI, the

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > egress NSH will have a new SPI and a SI=3D 255 or other

>>>=C2=A0 =C2=A0 value, as
>>>

>>>=C2=A0 =C2=A0 stated i= n

>>>

>&g= t;>=C2=A0 =C2=A0 > a).

>>>

>>>=C2=A0 =C2=A0 > > >>>>&g= t;>

>>>

&= gt;>>=C2=A0 =C2=A0 > > >>>>>> ?If SI=3D0 and = there is no re-classification the SF should

>= >>

>>>=C2=A0 =C2=A0 > > >= ;>>>>> discard the packet

>>= ;>

>>>=C2=A0 =C2=A0 > > >&g= t;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>= ;=C2=A0 =C2=A0 > > >>>>>>
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>>>>> Also an SFF should forward/handle packets with = NSH with

>>>=C2=A0 =C2=A0 SI=3D1 or SI= =3D0.

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>>

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> Do yo= u agree?

>>>
>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>
>>>

>>&g= t;=C2=A0 =C2=A0 > > >>>>>>
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>&g= t;>

>>>

&= gt;>>=C2=A0 =C2=A0 > > >>>>>> *From:*sfc [mai= lto:sfc-bounces@ietf.org

>>>=C2= =A0 =C2=A0 <mailto:sfc-bounces@ietf.org>] *On Behalf Of *James= N

>>>

>&= gt;>=C2=A0 =C2=A0 > > >>>>>> Guichard

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> *Sent:* quinta-feira, 9 de fe= vereiro de 2017 16:25

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> = *To:* Fabricio Ferraz; Dolganow, Andrew (Nokia - SG); Dave

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>> Dolson; Eric C Rosen; sfc@ietf.org
>>>=C2=A0 =C2=A0 <mailto:sfc@ietf.org&g= t; <mailto:sfc@ietf.org <mailto:sfc@ietf.org>>

>>>

>>>=C2=A0 =C2=A0= > > >>>>>> *Subject:* Re: [sfc] NSH Service Index = Decrement

>>>
>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> Hi= Fabricio,

>>>
<= br>>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> We= lcome!

>>>

&= gt;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>>

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> Yes, = removal of NSH is the responsibility of an SFF or a
=
>>>

>>>=C2=A0 =C2=A0 > = > >>>>>> re-classifier (section 4, bullet point 1 lays= this

>>>=C2=A0 =C2=A0 out). With

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>> the current architecture t= he SF does not care what SI

>>>=C2=A0 = =C2=A0 value it

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> gets, = it just needs to worry about decrementing it, and
>>>=C2=A0 =C2=A0 leave

>>>
>>>=C2=A0 =C2=A0 > > >>>&= gt;>> it up to the SFF to evaluate the SI value and

>>>=C2=A0 =C2=A0 associated action.

>>>

>>>=C2=A0 =C2=A0 &g= t; > >>>>>>

>>>
>>>=C2=A0 =C2=A0 > > >>>&g= t;>>

>>>
<= br>>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>> Jim

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>= ;

>>>

>&g= t;>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 &g= t; > >>>>>> *From:*Fabricio Ferraz

>>>=C2=A0 =C2=A0 [mailto:fabricio-ferraz@telecom.= pt

>>>=C2=A0 =C2=A0 <mailto:fabricio-ferraz@telecom.pt>]

>>= ;>

>>>=C2=A0 =C2=A0 > > >&g= t;>>>> *Sent:* Thursday, February 09, 2017 7:13 AM

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>> *To:* Dolganow, Andrew (Nokia - S= G)

>>>=C2=A0 =C2=A0 <andrew.= dolganow@nokia.com <mailto:andrew.dolganow@nokia.com>=

>>>

>>= ;>=C2=A0 =C2=A0 > > >>>>>> <mailto:an= drew.dolganow@nokia.com

>>>=C2=A0 = =C2=A0 <mailto:andrew.dolganow@nokia.com>>>; Dave D= olson

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>> <ddolson@sandvine.= com <mailto:ddolson@sandvine.com>
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >>>>>> <mailto:ddolson@sandvine.com

>>>=C2=A0 =C2=A0 <mailto:ddolson@sandvin= e.com>>>; Eric C Rosen

>>>=

>>>=C2=A0 =C2=A0 > > >>>= ;>>> <erosen@juniper.net <mailto:erosen@juniper.net>

>>>=C2=A0 =C2=A0 <mailto:eros= en@juniper.net <mailto:erosen@juniper.net>>>; James = N

>>>

>&g= t;>=C2=A0 =C2=A0 > > >>>>>> Guichard <james.n.guichard@huawei.com

>>>= =C2=A0 =C2=A0 <mailto:james.n.guichard@huawei.com>

>>>

>>>= =C2=A0 =C2=A0 > > >>> <mailto:james.n.guichard@= huawei.com

>>>=C2=A0 =C2=A0 <mai= lto:james.n.guichard@huawei.com>>>;

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>> sfc@ietf.org <mailto:sfc@ietf.org&g= t; <mailto:sfc@ietf.org

>>>=C2=A0 =C2= =A0 <mailto:sfc@ietf.org>>

>>>= ;

>>>=C2=A0 =C2=A0 > > >>&g= t;>>> *Subject:* RE: [sfc] NSH Service Index Decrement

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>
>>>

>>&g= t;=C2=A0 =C2=A0 > > >>>>>> Hi all,

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>>

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>> I'm new here (just read the draft last week) but

>>>=C2=A0 =C2=A0 according to

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>> chapter

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >>>>>> 4 (check figure 8 for example), an SF is not allow= ed to

>>>=C2=A0 =C2=A0 insert

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> or remove NSH. The removal of= NSH is reponsability of

>>>=C2=A0 =C2= =A0 the SSF, right?

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>
>>>

>>&g= t;=C2=A0 =C2=A0 > > >>>>>>
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>&g= t;>=C2=A0 =C2=A0Figure 8 maps each of the four actions above to the

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>> components in the

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>>=C2=A0 =C2=A0 SFC architecture that can perform it.<= br class=3D"gmail_msg">
>>>

>>= >=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 >= > >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>= >>

>>>
>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 +---------------+------------------+-------+----------------+-------= --+

>>>

>= >>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 = > > >>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 Insert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|Select |= =C2=A0 =C2=A0Update

>>>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|Service

>>>

>>>=C2=A0 =C2=A0 |
>>>

>>>=C2=A0 =C2=A0 > >= ; >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 or re= move NSH=C2=A0 |Service|=C2=A0 =C2=A0 NSH

>&g= t;>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|policy

= >>>

>>>=C2=A0 =C2=A0 |

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|Func= tion|

>>>

&g= t;>>=C2=A0 =C2=A0 |selection|

>>>=

>>>=C2=A0 =C2=A0 > > >>>= ;>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> | Compon= ent=C2=A0 =C2=A0 =C2=A0 +--------+--------+Path

= >>>=C2=A0 =C2=A0 =C2=A0+----------------+
<= br>>>>

>>>=C2=A0 =C2=A0 |

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>>
>>>

>>>=C2=A0 =C2=A0 > >= ; >>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0| Dec.

>>>=C2= =A0 =C2=A0 =C2=A0|Update |

>>>

>>>=C2=A0 =C2=A0 |

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Insert | Re= move |=C2=A0 =C2=A0 =C2=A0 =C2=A0|Service

>&g= t;>=C2=A0 =C2=A0 |Context|

>>>

>>>=C2=A0 =C2=A0 |
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= ;> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= | Index

>>>=C2=A0 =C2=A0 |Header |

>>>

>>>= =C2=A0 =C2=A0 |

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>>
>>>

>>>=C2=A0 =C2=A0 +-------= ---------+--------+--------+-------+--------+-------+---------+

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0+=C2=A0 =C2=A0 |=C2=A0 =C2=A0+=C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |

= >>>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0|

= >>>

>>>=C2=A0 =C2=A0 |

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>> |Classifier=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 |

>>>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|

>>>

>>>=C2=A0 =C2=A0 |

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > +---------------

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> = ++--------+--------+-------+--------+-------+---------+

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>>>>>

>>>
>>>=C2=A0 =C2=A0 > > >>>&= gt;>> |Service Function|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0+= =C2=A0 =C2=A0 |=C2=A0 +=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>>>

>>>=C2= =A0 =C2=A0 |

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> |Forwarder(SFF)=C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |

>>>= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

>>>= ;

>>>=C2=A0 =C2=A0 |

>>>

>>>=C2=A0 =C2=A0 = > > >>>>>>

>>><= br class=3D"gmail_msg">
>>>=C2=A0 =C2=A0 > > >>>= >>> +---------------

>>>

>>>=C2=A0 =C2=A0 > > >>>>&= gt;> ++--------+--------+-------+--------+-------+---------+

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>> |Service=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0+=C2=A0 =C2=A0 |

>>>=C2= =A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0|=C2=A0 =C2=A0+

&= gt;>>

>>>=C2=A0 =C2=A0 |

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>> |Function=C2=A0 (SF)=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |

>>>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

>>>

>>>=C2=A0 =C2=A0 |

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> +-= --------------

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> ++-----= ---+--------+-------+--------+-------+---------+
>>>

>>>=C2=A0 =C2=A0 > >= ; >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > |SFC Proxy=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+=C2=A0 =C2=A0 |=C2= =A0 =C2=A0+=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+=C2=A0 = =C2=A0 |

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|

>>>
>>>=C2=A0 =C2=A0 |

>>>

>>>=C2=A0 =C2=A0 > > >>>>&g= t;>

>>>

&= gt;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2= =A0 +----------------+--------+--------+-------+--------+-------+---------+=

>>>

>>= ;>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 >= ; > >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>= ;>>

>>>
>>>=C2=A0 =C2=A0 > > >>>>>>=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 8: NSH Acti= on and Role Mapping

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>
>>>

>>&g= t;=C2=A0 =C2=A0 > > >>>>>>
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>&g= t;>

>>>

&= gt;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>> An SF could receive an NSH packet wi= th an SI of 1, and

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> rec= lassify it to a different SPI and SI, right? So when

>>>=C2=A0 =C2=A0 a SF

>>>=

>>>=C2=A0 =C2=A0 > > >>>= ;>>> receives a NSH packet with SI =3D 1 that does not

>>>=C2=A0 =C2=A0 necessarily means a

>>>

>>>=C2=A0 = =C2=A0 > non valid packet.

>>>

>>>=C2=A0 =C2=A0 > > >>>>&= gt;>

>>>

= >>>=C2=A0 =C2=A0 > > >>>>>> And that can e= ven work for SI=3D0, since you decrement

>>= ;>=C2=A0 =C2=A0 the SI in

>>>

>>>=C2=A0 =C2=A0 > > >>>>&g= t;> the

>>>
<= br>>>>=C2=A0 =C2=A0 > > >> egress.

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>>>>>

>>>
>>>=C2=A0 =C2=A0 > > >>>&= gt;>>

>>>
=
>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> Fabricio

>>>

>>>=C2=A0 =C2=A0 &g= t; > >>>>>>

>>>
>>>=C2=A0 =C2=A0 > > >>>&g= t;>>

>>>
<= br>>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> *F= rom:*sfc [mailto:sfc-bounces@ietf.org

>= ;>>=C2=A0 =C2=A0 <mailto:sfc-bounces@ietf.org>] *On Beha= lf Of

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>>>> *Dolganow, Andre= w (Nokia - SG)

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> *Sent:*= quinta-feira, 9 de fevereiro de 2017 01:51

>= >>

>>>=C2=A0 =C2=A0 > > >= ;>>>>> *To:* Dave Dolson; Eric C Rosen; James N Guichard;
>>>=C2=A0 =C2=A0 sfc@ietf.org <mailto:<= a href=3D"mailto:sfc@ietf.org" class=3D"gmail_msg" target=3D"_blank">sfc@ie= tf.org>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> <mai= lto:s= fc@ietf.org <mailto:sfc@ietf.org>>

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >>>>>> *Subject:* Re: [sfc] NSH Service Index Decrement
>>>

>>&= gt;=C2=A0 =C2=A0 > > >>>>>>
=
>>>

>>>=C2=A0 =C2=A0 > = > >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>&= gt;>

>>>

= >>>=C2=A0 =C2=A0 > > >>>>>> I assumed that= if we get value 1 we process then forward

>&= gt;>

>>>=C2=A0 =C2=A0 > > >= >>>>> without NSH header (i.e.) this is the last SF processi= ng.

>>>

>= >>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 = > > >>>>>>

>>><= br class=3D"gmail_msg">
>>>=C2=A0 =C2=A0 > > >>>= >>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> So with t= hat assumption, a more explicit text would be:

&= gt;>>

>>>=C2=A0 =C2=A0 > > = >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= >

>>>

>= ;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0= > > >>>>>> An SF or SFC Proxy receiving an NSH-enc= apsulated packet

>>>=C2=A0 =C2=A0 MUST<= br class=3D"gmail_msg">
>>>

>>= >=C2=A0 =C2=A0 > > >>>>>> decrement the SI by 1 = after performing all required local

>>>=

>>>=C2=A0 =C2=A0 > > >>>= ;>>> processing and before forwarding the packet to the next

>>>=C2=A0 =C2=A0 SFF. If

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>>>>> the resulting SI is 0, the SF MUST remove= the NSH

>>>=C2=A0 =C2=A0 header before=

>>>

>>= ;>=C2=A0 =C2=A0 > > forwarding the packet.
=
>>>

>>>=C2=A0 =C2=A0 > = > >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>&= gt;>

>>>

= >>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>> Andrew

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>= ; *From: *sfc <sfc-bounces@ietf.org

&g= t;>>=C2=A0 =C2=A0 <mailto:sfc-bounces@ietf.org>

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> <mailto:sfc-bounces@iet= f.org

>>>=C2=A0 =C2=A0 <mailto:<= a href=3D"mailto:sfc-bounces@ietf.org" class=3D"gmail_msg" target=3D"_blank= ">sfc-bounces@ietf.org>>> on behalf of Dave Dolson

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>> <ddolson@sandvine.com &= lt;mailto:ddolson@sandvine.com>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>> <mailto:ddolson@sandvine.com <mailto:ddolson@sa= ndvine.com>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > *Date: *Thursday, February 9, 2017 at 2:04 AM
<= br>>>>

>>>=C2=A0 =C2=A0 > &= gt; >>>>>> *To: *Eric Rosen <erosen@juniper.net
>>>=C2=A0 =C2=A0 <mailto:erosen@juni= per.net>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> <ma= ilto:erosen@juniper.net

>>>=C2=A0 = =C2=A0 <mailto:erosen@juniper.net>>>, James N Guichard

>>>

>>>= ;=C2=A0 =C2=A0 > > >>>>>> <james.n.gui= chard@huawei.com

>>>=C2=A0 =C2=A0 &= lt;mailto:james.n.guichard@huawei.com>

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>>>>> <mailto:james.n.guichard@hua= wei.com

>>>=C2=A0 =C2=A0 <mailto= :james.n.guichard@huawei.com>>>, "sfc@ietf.org<= br class=3D"gmail_msg">
>>>=C2=A0 =C2=A0 <mailto:sfc@ietf.org= >

>>>

>= ;>>=C2=A0 =C2=A0 > > >>>>>> <mailto:sfc@ietf.or= g <mailto:sfc@ietf.org>>"

>&= gt;>=C2=A0 =C2=A0 <sfc@ietf.org <mailto:sfc@ietf.org> <mailto:= sfc@i= etf.org

>>>=C2=A0 =C2=A0 <mailto= :sfc@= ietf.org>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > *Subject: *Re: [sfc] NSH Service Index Decrement

>>>

>>>=C2=A0 =C2=A0 >= ; > >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>= ;>>

>>>
>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>> Eric,

= >>>

>>>=C2=A0 =C2=A0 > >= >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > I was never quite happy with the outcome that neither 0

>>>=C2=A0 =C2=A0 nor 1

>= ;>>

>>>=C2=A0 =C2=A0 > > &g= t;>>>>> is a valid SI.

>>&g= t;

>>>=C2=A0 =C2=A0 > > >>&= gt;>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> (Becau= se if received with value of 1, it is decremented and

>>>

>>>=C2=A0 =C2=A0 >= ; > >>>>>> discarded.)

>= >>

>>>=C2=A0 =C2=A0 > > >= ;>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>><= br class=3D"gmail_msg">
>>>

>>= >=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 >= > >>>>>> It seems to waste an index value.

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>= ;

>>>

>&g= t;>=C2=A0 =C2=A0 > > >>>>>> I guess I'm inte= rested to know if that is important to

>>&= gt;=C2=A0 =C2=A0 other

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>= implementers, or if that was even the intention?
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= ;>

>>>

&g= t;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>>

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> -Dave=

>>>

>>= ;>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 >= ; > >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>= ;>>

>>>
>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 = =C2=A0 > > >>>>>>

>&g= t;>

>>>=C2=A0 =C2=A0 > > >&= gt;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>
>>>

>>&g= t;=C2=A0 =C2=A0 > > >>>>>> *From:*sfc [mailto:sf= c-bounces@ietf.org

>>>=C2=A0 =C2=A0= <mailto:sfc-bounces@ietf.org>] *On Behalf Of *Eric C

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> Rosen
=
>>>

>>>=C2=A0 =C2=A0 > = > >>>>>> *Sent:* Wednesday, February 08, 2017 11:53 AM=

>>>

>>= ;>=C2=A0 =C2=A0 > > >>>>>> *To:* James N Guichar= d; sf= c@ietf.org

>>>=C2=A0 =C2=A0 <mai= lto:s= fc@ietf.org> <mailto:sfc@ietf.org <mailto:sfc@ietf.org>>
>>>

>>&= gt;=C2=A0 =C2=A0 > > >>>>>> *Subject:* Re: [sfc] NS= H Service Index Decrement

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= >

>>>

>= ;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0= > > >>>>>>

>>>=

>>>=C2=A0 =C2=A0 > > >>>= ;>>> On 2/7/2017 2:24 PM, James N Guichard wrote:

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>>

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>> A request was made to be more specific and update the

>>>=C2=A0 =C2=A0 text as

>>>

>>>=C2=A0 =C2=A0 = > follows:

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>= ; "Service index MUST be decremented *by a value of 1* by

>>>=C2=A0 =C2=A0 Service
>>>

>>>=C2=A0 =C2=A0 > >= ; >>>>>> Functions or by SFC Proxy nodes after performing=

>>>=C2=A0 =C2=A0 required services .&q= uot;

>>>

>= ;>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0= > > >>>>>>

>>>=

>>>=C2=A0 =C2=A0 > > >>>= ;>>> A couple of observations:

>>= >

>>>=C2=A0 =C2=A0 > > >>= ;>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> - Th= e term "SFC Proxy node" is not defined in either

>>>=C2=A0 =C2=A0 the NSH

>= ;>>

>>>=C2=A0 =C2=A0 > > &g= t;>>>>> draft or in RFC 7665.=C2=A0 I think the intention he= re is to say

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> "SFC=

>>>

>>= ;>=C2=A0 =C2=A0 > Proxy".

>>>= ;

>>>=C2=A0 =C2=A0 > > >>&g= t;>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> - Is th= e intention that the SI remain unchanged while

&= gt;>>=C2=A0 =C2=A0 the SF is

>>><= br class=3D"gmail_msg">
>>>=C2=A0 =C2=A0 > > >>>= >>> operating on the packet, or is the intention only that

>>>=C2=A0 =C2=A0 the SI

>>>

>>>=C2=A0 =C2=A0 >= > >>>>>> be decremented before the packet is delivere= d by the SF

>>>=C2=A0 =C2=A0 or SFC

>>>

>>>= ;=C2=A0 =C2=A0 > > >>>>>> Proxy to an SFF?

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>>

&g= t;>>

>>>=C2=A0 =C2=A0 > > &= gt;>>>>> I'd suggest either:

= >>>

>>>=C2=A0 =C2=A0 > >= >>>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > "An SF or SFC Proxy receiving an NSH-encapsulated

>>>=C2=A0 =C2=A0 packet MUST
>>>

>>>=C2=A0 =C2=A0 > &g= t; >>>>>> decrement the SI by 1 before delivering the pac= ket to

>>>=C2=A0 =C2=A0 the next SFF&qu= ot;

>>>

>= >>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 = > > >>>>>> or

>>&g= t;

>>>=C2=A0 =C2=A0 > > >>&= gt;>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> "= An SF or SFC Proxy receiving an NSH-encapsulated
>>>=C2=A0 =C2=A0 packet MUST

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>> decrement the SI by 1 before delivering the packet to

>>>=C2=A0 =C2=A0 the next

>>>

>>>=C2=A0 =C2=A0= > > >>>>>> SFF, but not until the SF has finished = all its other

>>>=C2=A0 =C2=A0 processi= ng

>>>

>&= gt;>=C2=A0 =C2=A0 > > >>>>>> of the

>>>

>>>=C2=A0 = =C2=A0 > > packet"

>>>

>>>=C2=A0 =C2=A0 > > >>>>&= gt;>

>>>

= >>>=C2=A0 =C2=A0 > > >>>>>> depending upon= which is intended.

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>
>>>

>>&g= t;=C2=A0 =C2=A0 > > >>>>>> I think an implication o= f these procedures is that an

>>>=C2=A0= =C2=A0 SI value

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> of
>>>

>>&g= t;=C2=A0 =C2=A0 > > >>>>>> 1 is not valid.=C2=A0 If= an SF gets an NSH packet with an SI

>>>= ;=C2=A0 =C2=A0 of 1,

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> t= he SF will decrement the SI (setting it to 0), send
=
>>>=C2=A0 =C2=A0 the packet

>>= ;>

>>>=C2=A0 =C2=A0 > > >&g= t;>>>> to an SFF, and the SFF will discard it, because 0 is an<= br class=3D"gmail_msg">
>>>=C2=A0 =C2=A0 invalid

>>>

>>>=C2=A0 =C2= =A0 > > >>>>>> SI value.=C2=A0 Is that the intentio= n?

>>>

>&= gt;>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>>>>> The draft makes it clear (well, sort of) = that an SFF should

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> dis= card a packet with an SI of 0, but does not seem to
=
>>>=C2=A0 =C2=A0 say that

>>&= gt;

>>>=C2=A0 =C2=A0 > > >>= >>>> an SF or SFC Proxy should discard a packet it receives

>>>=C2=A0 =C2=A0 with an

>>>

>>>=C2=A0 =C2=A0= > > >>>>>> SI of 0.=C2=A0 It would probably be a g= ood idea to say that.

>>>

>>>=C2=A0 =C2=A0 > > >>>>>><= br class=3D"gmail_msg">
>>>

>>= >=C2=A0 =C2=A0 > > >>>>>> Some text in the draft= (e.g., section 7.1) states than

>>>=C2= =A0 =C2=A0 an SFF

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> shou= ld discard a packet with an SI of zero, but other
>>>=C2=A0 =C2=A0 text in

>>>=

>>>=C2=A0 =C2=A0 > > >>>= ;>>> the draft (e.g., section 3.3) only says that an SFF

>>>=C2=A0 =C2=A0 should log

>>>

>>>=C2=A0 =C2=A0 &= gt; > >>>>>> an error if it sees an SI of zero.=C2=A0 = It's probably best to

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= > change the text in 3.3. to say "SHOULD generate an

>>>=C2=A0 =C2=A0 error/log
>>>

>>>=C2=A0 =C2=A0 > >= ; >>>>>> message and MUST discard the packet", or so= mething similar.

>>>

>>>=C2=A0 =C2=A0 > > >>>>>>

>>>

>>>= =C2=A0 =C2=A0 > > >>>>>> __________________________= _____________________

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> = sfc mailing list

>>>

>>>=C2=A0 =C2=A0 > > >>>>>> sfc@ietf.o= rg <mailto:sfc@ietf.org> <mailto:sfc@ietf.org

>>>=C2=A0 =C2=A0 <mailto:sfc@ietf.org>>

>>>

>>>=C2= =A0 =C2=A0 > > >>>>>> https://www.ietf.org/mailman/listinfo/sfc

>>>

>>>=C2=A0 =C2=A0 >= > >>>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>=

>>>

>>= ;>=C2=A0 =C2=A0 > > >>>>> _________________________= ______________________

>>>

>>>=C2=A0 =C2=A0 > > >>>>> sfc= mailing list

>>>

>>>=C2=A0 =C2=A0 > > >>>>> sfc@ietf.org = <mailto:sfc@ietf.org>

>>>

>>>=C2=A0 =C2=A0 > > >>>>>= https://www.ietf.org/mailman/listinfo/= sfc

>>>

= >>>=C2=A0 =C2=A0 > > >>>>>

>>>

>>>=C2=A0 =C2=A0 = > > >>>>

>>>

>>>=C2=A0 =C2=A0 > > >>>> ___= ____________________________________________

>= ;>>

>>>=C2=A0 =C2=A0 > > &g= t;>>> sfc mailing list

>
--94eb2c0939ce83eb8605485ae17b-- From nobody Mon Feb 13 09:42:38 2017 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 B7686129706 for ; Mon, 13 Feb 2017 09:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3CRCT9yudjzF for ; Mon, 13 Feb 2017 09:42:35 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879C6129685 for ; Mon, 13 Feb 2017 09:42:35 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1DHgXPs014366 for ; Mon, 13 Feb 2017 17:42:33 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1DHgQcj014276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Feb 2017 17:42:32 GMT From: "Adrian Farrel" To: Date: Mon, 13 Feb 2017 17:42:22 -0000 Message-ID: <018401d28620$8e15e240$aa41a6c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKGIISiuXEbnYgiQ4m3KnmHDVyBQA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22884.000 X-TM-AS-Result: No--10.298-10.0-31-10 X-imss-scan-details: No--10.298-10.0-31-10 X-TMASE-MatchedRID: crhYgkiN54vhUYZPldDIO9OEZs/2oH3cT5++FIORChBPtLhlThdPEO2l xlW3AjAI32QTkj7KSP5b7TcXX+lonMrES94xsQcChsE+u3nnCfAuLZ3AqIxH3Np1biJhIyNRXa2 +zE1cP+VP4834tptSoEb5H/7zTJtBSqSDOjH8JBoIs18ZTh19+HqLSTHPtKxCzHMzwJtUgUi3DI h4Vmbze6iBsty1KPz/yJwXrHqnU5KiwkztVCsqbzbN0t/c2qF2SipwJQ5yg7qFz4nDgsy1wHv4i xlgc06f4tgb4OtJ74iS4r+suLwylftAPEfr8cPbnVTWWiNp+v9Aq6/y5AEOOl3K8ee6c6KjLIHZ B0nMVDGynUhD2tnSEis6L3bFZPPBf46ELUnpDSzqqv01/ojPE1Fa7g7C8t2EmyiLZetSf8nJ4y0 wP1A6AB8AKgKWeNGhYseN4aSOH1fdB/CxWTRRuzcB+yPHwBUaZQtjH3Y6t3B9yQdGdWetFnNQTq 1wfruJuyaRMPXalYWmaO1N7FK9lA== Archived-At: Subject: [sfc] Update to BGP for SFC: I-D Action: draft-mackie-bess-nsh-bgp-control-plane-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:42:38 -0000 Hi SFC WG, Just a note to point you to an update of our draft on using BGP as the control plane for SFC. Apart from a few minor tweaks to wording, the main changes are: - 4.3 Clarify the scope of uniqueness of SPI - 4.5.1 New section on handling lacunae in the SI sequence - 5 Add initial paragraphs on multiple SFTs at a single hop - 7.6 Clarify bit setting rules in the SPI/SI Representation sub-TLV As previously noted, this is a cross-posting for a draft targeted at BESS. You can discuss it anywhere, but probably best to restrict your comments to BESS or SFC. Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 13 February 2017 17:17 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-mackie-bess-nsh-bgp-control-plane-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : BGP Control Plane for NSH SFC > Authors : Adrian Farrel > John Drake > Eric Rosen > Jim Uttaro > Luay Jalil > Filename : draft-mackie-bess-nsh-bgp-control-plane-04.txt > Pages : 52 > Date : 2017-02-13 > > Abstract: > This document describes the use of BGP as a control plane for > networks that support Service Function Chaining (SFC). The document > introduces a new BGP address family called the SFC AFI/SAFI with two > route types. One route type is originated by a node to advertise > that it hosts a particular instance of a specified service function. > This route type also provides "instructions" on how to send a packet > to the hosting node in a way that indicates that the service function > has to be applied to the packet. The other route type is used by a > Controller to advertise the paths of "chains" of service functions, > and to give a unique designator to each such path so that they can be > used in conjunction with the Network Service Header. > > This document adopts the SFC architecture described in RFC 7665. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-mackie-bess-nsh-bgp-control-plane-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-mackie-bess-nsh-bgp-control-plane-04 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Feb 13 11:59:58 2017 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 0410E129AA8 for ; Thu, 9 Feb 2017 07:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 9qeG0hrbEsvA for ; Thu, 9 Feb 2017 07:06:06 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 4E521129531 for ; Thu, 9 Feb 2017 07:06:06 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id 11so6916626qkl.3 for ; Thu, 09 Feb 2017 07:06:06 -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; bh=PnUu/XtSvJDeur3KOxie75hx8DmjST0xKHfhjS6tZ7U=; b=puk7+SyCLck5ypJc7eT6zWPPoe9fNJr9nioKvpXuRv0SLlOTy9HF8VgWrKSVFLxo+2 E++f/qsfyjZfVEuIgBQArz2oVYTxeXDGfqqBvM4gBItnfB0fW+Gw+1J2cenIhfrGVW0u FvewOpxRgNS6MQrC+I86psLj7A0gyfUnFRVBh++VMIVrhEIgza4pTflHoQHMFC/JkI+Q qUr35HsP1I8fiJCGRooosNwxU0NyBHA6fQtIPQnKyppPAycWfNPVskdSFvwW5B7rMck6 z4sxr4Ols8ETsZzCAC80buvLzcJ/+8hduVhbrY66TZyref17vV4jZMIXZcdtIfaeqa74 M/Zw== 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; bh=PnUu/XtSvJDeur3KOxie75hx8DmjST0xKHfhjS6tZ7U=; b=GGRltTQwjlgAndNFWjuml7RaVfYSvMw7Vr8ua2nU/8uKW0U5DL73Bwp6HIXglcWqJc /NtBgAp1JrgldqMkytZ0VlbyOkS6wK32mZROs15w7f/z1+v4ZCh4cCOC0a93OwW3MGiv TaMV9a+D5Nt+ENMgaE75TKr0CCyxcsSNIByelH8jIQ06tgE1IcnRTHOMzG8pNCtKQ1Yp V/omJBBqQWsj8PXWA7sdE3OEJtbHhXUUmKd3bYBvEAtSJhanUo8Ba+0Kykh0psxy4gpG CmOJ0Wil7joZK2NeNahz5JBS5d7Og/sfuPM0JGxrUpt0PFuih5QYEoPr31ZzV7EKrUVa N2fA== X-Gm-Message-State: AMke39nSBTdvfOyZp8SnnNYvwY5KXPTbM1dy3yJksRAvbFiNuCF0MeVMvGQWA84jxfHWybx5hzpPbEpFeQxmVQ== X-Received: by 10.55.73.211 with SMTP id w202mr3133767qka.321.1486652765523; Thu, 09 Feb 2017 07:06:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.11 with HTTP; Thu, 9 Feb 2017 07:06:04 -0800 (PST) From: =?UTF-8?B?2b7ZiNuM2Kcg2K7Ys9ix2YjbjNin2YYg2K/Zh9qp2LHYr9uMIFBvdXlhIEtob3NyYXZpYW4gRA==?= =?UTF-8?B?ZWhrb3JkaQ==?= Date: Thu, 9 Feb 2017 18:36:04 +0330 Message-ID: To: khosravyan Content-Type: multipart/alternative; boundary=001a114a868cfe569105481a51b0 Archived-At: X-Mailman-Approved-At: Mon, 13 Feb 2017 11:59:56 -0800 Subject: [sfc] Help Me! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:06:08 -0000 --001a114a868cfe569105481a51b0 Content-Type: text/plain; charset=UTF-8 Hello Dear Prof.! I am a PHD student and my thesis is about service function chaining and i need a complete list of service function types. How can i get this list? Please help me. Thank you. Best Regards. PHD Student of Islamic Azad University Yazd Branch Faculty Member of Islamic Azad University Shahrekord Branch Home Page: http://iaushk.ac.ir/part/pages.aspx?id=74&pid=1 Google Citation : http://scholar.google.com/citations?user=ZXfOfdQAAAAJ&hl=en Work Phone: 03833361000 - 403 Cell Phone:09132800436 --001a114a868cfe569105481a51b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Dear Prof.!
I am a PHD student and my thesis is about servi= ce function chaining and i need a complete list of service function types. = How can i get this list? Please help me.
Thank you.
Best Regards.


PHD Student of= Islamic Azad University Yazd Branch
Fac= ulty Member of Islamic Azad University Shahrekord Branch
Home Pa= ge:
--001a114a868cfe569105481a51b0-- From nobody Mon Feb 13 12:00:03 2017 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 828871294FB for ; Fri, 10 Feb 2017 00:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] 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 J-ZImTsk4-25 for ; Fri, 10 Feb 2017 00:49:21 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 89C4E1294DF for ; Fri, 10 Feb 2017 00:49:21 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id k15so28472591qtg.3 for ; Fri, 10 Feb 2017 00:49: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; bh=5TY0X4KofDfL/nthqBKtnecBDcXejNeLUHk3e7EhC1k=; b=chpGJXOGcsuY3sa4Xvt/KWVnvThVLgcwVo8OrSGvpt0zKhKla/uwcOCXcGcMQuJlGt RvD2/aHCBB8s2jVfSbY1He8lBvjlhpv2w60Yn45P6UYsWIlfEJ7ZA8sp6aQoAXhEXUDd DKGfBpefMK4cNxw8NWjJX2engV992TQ5KYalpHkalTt0ia9rjQhwMxW5DWk0DSQzAxO8 QdI/Xkzi/7kA6UJsAUyIN6+CSk+gF6Tbszk769iA3oV4pg113rtnNAx1v7ZnMUAW8Rsb 4bu6hZpFKVAZoIDPSpc0yBzpasUrSUH7XndedeVKguV8+YlNRkIN8GJzpfuYY84iMxB3 r2qQ== 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; bh=5TY0X4KofDfL/nthqBKtnecBDcXejNeLUHk3e7EhC1k=; b=hqvQYwSJTnwKXcIs2njMkiHuvLA5NpEQ+Yjg492CGcPf5xa9fhJAfQX6PxPYh9aauV giciOP1UmA8SiBhQatnTG8zTMi07sJIcTzgaPdSqghH0uvqiGQToksT6n41SOlb4jCb8 nxdZSX28Zd904DBP9ceJG322Mtv2m/18vDvc4QfoOwTTUXcRUOyV0d/U8rHkucm7sJMB DCoIjcJTDyK716JG0Ih/yP41Uzn8ma0YolIhMMqkYEUQnC6qvFatrxz/R36EDSHhKPB2 knLfhPMgTyQUsskqI3YrVgSfs3SxC0Fn9aaDh4zfKL6mN8cQ0xbmO/aeaz1m/xd7TOKb Px+Q== X-Gm-Message-State: AMke39m0Xzy6Bw7b4x65/Gqdr1OyAGHD1v1X/KxqQDxWe/2UjRM88ujYF22e6zRI04W7RMLd4yuWKIcToHuu5A== X-Received: by 10.200.1.2 with SMTP id e2mr6616837qtg.142.1486716560703; Fri, 10 Feb 2017 00:49:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.11 with HTTP; Fri, 10 Feb 2017 00:49:19 -0800 (PST) From: =?UTF-8?B?2b7ZiNuM2Kcg2K7Ys9ix2YjbjNin2YYg2K/Zh9qp2LHYr9uMIFBvdXlhIEtob3NyYXZpYW4gRA==?= =?UTF-8?B?ZWhrb3JkaQ==?= Date: Fri, 10 Feb 2017 12:19:19 +0330 Message-ID: To: khosravyan Content-Type: multipart/mixed; boundary=f403045f39e47c031f0548292c08 Archived-At: X-Mailman-Approved-At: Mon, 13 Feb 2017 11:59:56 -0800 Subject: [sfc] service function types list X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 08:49:23 -0000 --f403045f39e47c031f0548292c08 Content-Type: multipart/alternative; boundary=f403045f39e47c031b0548292c06 --f403045f39e47c031b0548292c06 Content-Type: text/plain; charset=UTF-8 Hello Dear Prof. I have a list of services in attachment please help me which of them are service function or not. For example is it TCP or UDP are service function ? Thank you. Best Regards. PHD Student of Islamic Azad University Yazd Branch Faculty Member of Islamic Azad University Shahrekord Branch Home Page: http://iaushk.ac.ir/part/pages.aspx?id=74&pid=1 Google Citation : http://scholar.google.com/citations?user=ZXfOfdQAAAAJ&hl=en Work Phone: 03833361000 - 403 Cell Phone:09132800436 --f403045f39e47c031b0548292c06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --f403045f39e47c031b0548292c06-- --f403045f39e47c031f0548292c08 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="totallist.docx" Content-Disposition: attachment; filename="totallist.docx" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iyzkn0nf0 UEsDBBQABgAIAAAAIQAykW9XZgEAAKUFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lMtqwzAQRfeF/oPRtthKuiilxMmij2UbaPoBijRORPVCo7z+vuM4MaUkMTTJxiDP3HvPCDGD0dqa bAkRtXcl6xc9loGTXmk3K9nX5C1/ZBkm4ZQw3kHJNoBsNLy9GUw2ATAjtcOSzVMKT5yjnIMVWPgA jiqVj1YkOsYZD0J+ixnw+17vgUvvEriUp9qDDQcvUImFSdnrmn43JBEMsuy5aayzSiZCMFqKRHW+ dOpPSr5LKEi57cG5DnhHDYwfTKgrxwN2ug+6mqgVZGMR07uw1MVXPiquvFxYUhanbQ5w+qrSElp9 7Rail4BId25N0Vas0G7Pf5TDLewUIikvD9Jad0Jg2hjAyxM0vt3xkBIJrgGwc+5EWMH082oUv8w7 QSrKnYipgctjtNadEInWADTf/tkcW5tTkdQ5jj4grZX4j7H3e6NW5zRwgJj06VfXJpL12fNBvZIU qAPZfLtkhz8AAAD//wMAUEsDBBQABgAIAAAAIQAekRq37wAAAE4CAAALAAgCX3JlbHMvLnJlbHMg ogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAArJLBasMwDEDvg/2D0b1R2sEYo04vY9DbGNkHCFtJTBPb2GrX/v082NgCXelhR8vS05PQ enOcRnXglF3wGpZVDYq9Cdb5XsNb+7x4AJWFvKUxeNZw4gyb5vZm/cojSSnKg4tZFYrPGgaR+IiY zcAT5SpE9uWnC2kiKc/UYySzo55xVdf3mH4zoJkx1dZqSFt7B6o9Rb6GHbrOGX4KZj+xlzMtkI/C 3rJdxFTqk7gyjWop9SwabDAvJZyRYqwKGvC80ep6o7+nxYmFLAmhCYkv+3xmXBJa/ueK5hk/Nu8h WbRf4W8bnF1B8wEAAP//AwBQSwMEFAAGAAgAAAAhALUjNIhjEAAABSgBABwACAF3b3JkL19yZWxz L2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3F3b cts4En3fqv2HlKt2K/sQ2yR9U3Y8U7Jsx5qxLMWSx6l9QcEUJGFCARwQ8mW+fgHqYmUcZw0S45PF S6rMFMFuAWh0o/uc/uGn+2n25papgktxuBFtbm+8YSKVQy7GhxtXg9N3BxtvCk3FkGZSsMONB1Zs /PTj3//2wyXLqDYvFROeF2/MKKI43Jhonb/f2irSCZvSYlPmTJj/GUk1pdr8qcZbOU0/0zHbire3 97bU+hgbP34x5pv28HBDtYdRtL/xZvCQs5eMLkcjnrJjmc6mTOivfGRrYkZSGRefzaBUjZmeD1uY cZnYvOOfec6GnJaj2b+22kMzEsmV1DKV2fKtjhwagU7uNVOCZhtbX5c9bjSwsh91SP+h0GxKcjfJ k+0EKvl5r3np+FtHWIF5oYkckUGrR8xuIVfHPZJLpYmYTW/M9nJTZicOSJk98FLyqszBDlSZU2OX mapojqLkACp8S06nM8HTcgzCxDCXXGhHHXZxJnWLiyG738wn+U+a64wdHpnDbKzkzKyqU54xMlBU FCMzPz0lx4pO/0mn+b9paj93aIbR5d+KDe0HD629crHIMXblDVjG0vUJLMj66y9UYmcXqsTFyaDV vTh1FHpvD7vnB72+4ybZ34ZKfL189L7F9Xy3C8aGbOioRiOkMz3exq79AZ8y0tfGBFnzVMWbjbH7 wPN07GDjinMumJkIcwCa8+KYsqnZJBWP9W20Jl7nZQ/rpJRneCn+OX0wU9Nn6Uxx/eCoxQE28vM7 JxHWDh/zIqVqWNFsJdhYqlw/xvBOWOYo+G5IcdM+1nv1vB9irI3qdPvvf25efuheOMq9E5JVSiJw ROTlpEgSrFt4Tm9YRoyJ1YrfzEpfvaKd3X0t91BLmRWbnOlROdZET7MtNUr3D3bttnQReR/rOS3P Bpl+ZrqYLyPHMwK7A8w+7tkN0Gfq1gxOOrNM8zxj9656NMCbwO/xsPe9hN/ti+N2v3XZ7rQvmoMT Ry0OsF7foxa/MsVHnN7wzN0Pj7Ax65UoAzw1yzW/yZhZVHfmpChmeZ65apIEFeWVphqnzfFZq3dr l4aLzPsheU8xNixqTaiiqb37+MAEU1TL8ta8gt+xgwuTniQELuVMM9JMU1YUK3V8ZgH2sC7vo03u ZYwWjKQZNbbZ0ZRFEXbzez7tE6xZ6PBUyUKOHBNpcQPrpJSuYkrNTPTlTBnf0d7yyFumHqrGH9vY vdGhKen2yafSGXb1f5M4JAc42cF6XUcnJz1Hifew3tXpwFHgg6ACpl2sLfKszX5IacuogXUUH12O OsFsvI21SD3FUm5rLEmZhq2agAVfV/FpbmLYC6bvpPpMenTMxbiqLjsh+YDxHtYHrH+RGIVUcZiE lDmLtrE75VKzTDDXMr0YuyGWNuqC3RVflOVVMVUHWO+kgjcbBRVNJCHVHSW7YDxDv9Vvu4m8G1Lu fj+krdEIaWdEO1g7e8mmUjNbhJeyoXWnUupashPtYUO/hYf+gWp2Rx9IRwquparupUcHWLfwSKqh TREs9Kl4foMRZMvk+LlcIB8q3m/uhxQxBVVKDMbVGClvZs4JWKyDXikBG1RYFwWVTQYjTjqUZ6SY 3Ux5Ud6y0TFzRZbFaLSJt0I8MNDEc7wUFOokAaNOKgHgdr6XooM6GYA97KY4klKbnU2rgq8Ogor0 kqDyfbsh5fuSIPBX0T4Y9fNlqqxDhfFI7OhVA/EG1vdt5kadAc1WL7zQpwJDEz2lXV9rRzwDbIh2 yz3pIjIY6GPrIO2tU1vMP1TdmY3CSuUFFfOBYQ6lTbLEGzWqEMAYhx5j6p2W73LmXDAIBjZ0c82n /A82JOfmLcsroBlZbvtqOPYEjHAYyFxmcvxAjpSkw7I09YYWRkNjvC6Z5Uhj73pUT8ipVHdUWYo0 ouppjCYTMvtHL5LjbpLvhnTFsI/dSh9kPjGO7tvlGvqXm/SNkHBBUYw9U9oWrSWYJla4B9KaUNfC l52ggsFXg2k94/om++WCcBEZjNLqSTMB3XLcik4Jdj8vsuC/yRtihlSucfdeSHWE0UFI0UccFOwq BsOuLLPZkGVbV58c5QZjHfyF5nFQOIcYjHOYUycsJoLMk4H9O67TiZktxyMQDHbwPDHfQZBUs4IY yHr5FKLMijne8kk5klecckgr8CCoCCvCnj9zPvJilRppKmPhNEv1TDFHTZKgQi0wuKsCygAM4ep3 m84o3/97mNZuUPHVflDZnQbWU/k446lNNfOsNuIJDDnr0Dy3MYqZmia3b5YemP0OsQwRZHVLVzWh izUDTeNj3VrCC2WOPel6xZKA4WieCHK/D7BHz4I9ioKc3Bst7HCOWoDxHuVcLGteW1JoZWLHion2 kEBeYE7NAXNHzL4ae+YzIjdbzVb/H/GRm9RgAk3f5RlYm3QmCy3o1DEMisEYLVuGsezpkrl7tAkY nWXlE0VJzmgM521ZLVa9oCR5NSjQcwmzvbJDkZOtfC1v6BmRd/ZK2+cgMtY7PUknsuLyaIAjZp46 WsSguqpF4LZqFvNGigrscBG4hVr/47mjwOA2ac2ZlkJO5awgRXnfSN4uY0bH6poYDNPzSWSSgEF6 Rhdh1HCcADBWZM7mSDomSqRjRo4yma7efaEGYHyI+dmvqWImPlSVS+BDKvcDk1NeLx/Vg7Nhvebj BxOo8JTYkMVePIz4eKbKASsXE3wXgB0vt6dgrI73uUnAKJ5jKc0BPjaRsePhnYD79PjGDmNdkbOB cyPKA+zvf2Zf0Oxe193SEbgDWv2i0gjcBs035DaoxGFYzdHAvXyaF678djEYltdJmyPmeOubvBr4 7plbu905kaGLyGCwXf3qixiMTunIG1uN2HYse4nBmJQjPhqRt6mc5mXpsaMTB+YyPaYPujp2PCjq UjBz6fXy0fsOFTOaWcX6+iFjZo40K0oFKwKZQ/KNYjBoZTATgmU1QLFgmMqxnFIuiE3EEsXGZm6c K3TA0JRfmDLLRhaVIaVgpsmLk8Hlz46RZgMcG5tlItWD3cV6wlYFao4n3Tb2nJ5LXY5grGtXjang f5R/EvNli/EXQ4t7nz9z1A3cb25xv+cDzREBO86tGagLa6Dm1fSO8oObyFXuXg3ueVRtUydgvF8l xr8kKGhfUKQ7YPiObwqhkJQJCo8Ug5EmlrCtSq1MDMaUWA+jQz87iw0Gj3hOVYEBJKdcFfqdeakw vmsxkVK7N+QEV0UmjTKOdxAZTC28bHPwdl5xVRC6hux0DEDBHKS1yXpD8jiioFrDReDecMt6vhp8 pFFQ/ZgicEOm6+Wj95bRxQ5EBGNDNnQ8L8B4Ns/nNxjXdlk8CNdSdXAvrP8kjc0y1Hdx+sCAoz+1 V3psyV4x2QVGInk2TEHFpq8G5HiuXKBRdpFwERmM1rjM5Jg744FDqkuKwSiONZg/FyVpWUW7BMZw fCWjSF3D0ZBwtq9GKvpUma/QYZU8AGXdd2vC0s/ry8wnIxaYltQ3Uhp8Odh3pf6JwmoeB2/JJIby rngkYpknI+c3QI6WDY3vap+3qnNvB9XHCNgi64ldXvXBY8O5cZ5nuv8S0xyBm2vVJh1PwAjDvjsT GxjuVYWhJQaDQKr2YAIjP2pXo8VgsIeHvuAxGOHhQwUwrMN3ghJMAbdGmvMlRLOZloRkVVG0UK28 cCWDIYMWafdWzLM0rlnLsNJ+QQVM4FZLnq3Xq+GQnrvN3S9/TweRwaSVvuGn30cl6oqVpNahEYH7 X5W3u9V4kcC9r5bzUGb0e9TiCsnJfTqhYux6CwKG6NV20hMwhurUmZsg8YuTGkmhB/QmW0384cbq 0aYZ7VmXDQz66NCUdPvkU3l75w6Ixc76mX3BB8FDDMZ0+C6rRoebNJtXOPW1YnRap0FrSFEnmOr0 Y3dw7GojoQJ7JGV6NZLTV1lH20HFZuAOT55jMzBAp8NT48fJkePlNpga0jtnWSMs4lowB8ZaMq4l p7kUZmTSvfmNpSYGNSq4RpxBtQeLguoPloBRbC1epNJRZDBUrULrLDBIzU8PF68LZb5Y13pdHm6s Hn0zfg4KnhKD4SnNjA6HXJBfhLzL2HC8ZBhwVQMMUbm6arlyZIXEFAomCrUugvEVFFlcjTpalaA6 EcVgeJO/GzIwvsZ3/h8b77SPOqTZ/kTems/ZOEeMF40KXFPOWDWul49qcZmDeSF9Z5qxG/5KcLOS HGUGNx/zfcv6vfAU/mq81xGnNzxz962BrYKeFOMu08y5LEpTtcwR+izCTYJqNZSAwWu+4cDYqOR0 4Bpf+0WuafPuWl63/HP+MPpmaApGyfiGkIZwZxGDkTOLStz+hLkW4IJpUT1blKA42YDAmb9AGzAa 5pyPJ/qO2X8fW2TXq3ADUzA2L3vNeWZrBZOrTj66HRT5C7ixmL0nJMtu82ZCbELLUQNwN7ELpo/a XcfStwjcPewxQqpzbRCBuwv1LzqubikYQbaqDVhVqVaq+kuC6iWUgOFl/tu1gcFm9fusgNmHB4rf cpp5IQtvBBUCwjFB3l3DGAwMumTamOTcFtK8tZb5jjqTZXpdYYVtqLJaFocb87+/ecsRVCgHRva0 5HTKlCuHRgxG8PiuD4vBuJ4BF2llJExQRJARuPuW79wcdp/Mc3OkY5Qxi2us6LSERmTGE5/R8aPZ faE24H5cJ1PKnaGG2JDtk3EbitySrHSoML+4sg63OYCzyp2Rg0pagdFcF0bKFfbevVFgAsZwVeu0 AoZq+cmqgOmCPzEl78mSWrtSxSKYuvZ6+eh9L2O0YCTNqOIj56IBrC/uF5ceg1FOJd9Sf2ICMtdZ gIq9/O37zBwIFX95MCLLQ6deMGLG2KBMrkrZXygzGBWzSE2Xt15V+srFYByMn6MMTEfpGyiKBo6N uaYZaU/p2EY6ViN7xTETC/KrgnBhToshT7lwNbPg5mGPR3atxhERuG1PmZJWrJDZrNRh0afb7J9F Hx9HLzwC9+5ZYMaXzuA8zrOjVyYPR9/gi9n9u7Omo9RgHJHvFB3WH6nbcRVMz+p3MsDMrX6VaWC3 yeMZUivsA/Ybe1Ir3u9cffJaFw4GUPmNab0ut4JpW46/nq1bPNm8/xZgNih8HRhus1oey2iDNItC pnzuEFr9fmHL2+YaXkgMRujUJ3EGg3I8lT7FQFhOudyOOo5nA7iNVdd8ZeWMz4HBNhBc3DX0VoTU LWdC6gjcE+fPSe+5Yifilisp7Fcc1QF2xfkLPHYw9MXia8+oGtpymnXr2zIjykeOxhcqg0a+sIxp Re3AhIkxF+wLoowXKgEGvizvdN2BL69GdvwaGwPM81qj7SyY4LVuDO6X7RUV6YG7iD2pn3C0QWCg VP28UhRUx6c4KDBRDAYTnQ2cOahjMHrINw4SnMq4cMWJx2gIUX2DtI1dQa1Wv1seypX4+8H9avof zx0PMDAAon1y4gqSC6otfUh5FDBp5fVZt+14WoFJKz1nfrCuT+0L1QjcKMtzoUpQvbOSsLpNgTFR nuq6wBgpP1p4XVd37Kb/JIW49nDz/vksYhRUQ68YDHNa1smd/D7j+eKiWhl1yjEdVQFjnFYJUZv3 rNYMKwYDmzwkO8Fh5f+oPt5aF7r48b8CAAAA//8DAFBLAwQUAAYACAAAACEAY+SUe8haAAANNg0A EQAAAHdvcmQvZG9jdW1lbnQueG1s7H3tctu4tuX/qZp3QPnPteuGsfXlj5zb6VJkJ9bpyFZbyu2c OX3KBVOQxDZJcEgqjs+veYh5gDxLHmWeZABQkkWZomVLFilwdVc5+qSwN7AX1toENv7r1++OTb4x P7C4+8tO6e3BDmGuyXuWO/hl50v3o3G8Q4KQuj1qc5f9snPPgp1f3//P//Ffd+963Bw5zA2JuIQb vLvzzF92hmHovdvfD8whc2jw1rFMnwe8H741ubPP+33LZPt33O/tlw9KB+qR53OTBYH4vQZ1v9Fg Z3w55/HVuMdc8Waf+w4NxVN/sO9Q/3bkGeLqHg2tG8u2wntx7YPDyWX4Lzsj3303voQxbZD8yruo QeN/Jt/wl/nd6CunYw+oX9z3mS3awN1gaHkPZrz0auLN4eQi39KM+ObYk8/deaXqan1w6tM78c/D BZdpfi/6kmNHLU+/YulgiR6Rl5h+Y5kmxH9z0hKHWu7DD7/INTPOLdWed4Hy/AW8wWqd88nnI+/h atZqV2u6t9Nrych+xrXGnTxrWrBaYzpD6okIdMx3zYHLfXpjixaJLiPC60QO6533AnFueO9e/hve 2ON/2v74wR/kTo4UAV/i6b0nvk1HId/ZH7/9QfyaADn1jHviM9+o/cuO/GWbya8E//5l51A98KjJ xtcxuc0FGtTVf9GlbNYPX/7tGx6G3Hn5931rMHzxz+/POyIY9ibXMm1G/ZlvKd+Jp33LFu9+PJH/ T33ZYLbdopHjlS+F30u1B8f3vtOYsxa9PfXGog9MzE1+P7JntjE39mfObyc2HVTryhF9yw/CKy4v Ip/adPzs4c0Gt0eOnP0m709eUB9x+fkHMf9Nn/139Kz00IbpIPzkWz35cCD+FdcYN718XIvsib18 JCepxy+XDmqVhytPLhj64l0xR/euRDMOPpRL9cMj2Rr1UtuXL54eHdaPlJfki1312viD0RWmrTxn VAyB8W9MXjajv5NnqeFkIpqU72b9sHwwleX/E0/Ox1H1ODWOTlTDUuIo8fszcVRZEEiThnyr29bA nVoi2Ajzp5+JBods6XOG4tUp69ORHT7+eHvmw+rK0Q9Iv4veEB+6YWKOFw0tV1Un0L5ozfSZbclZ a+bJ1UhOGg/j9C/zsR3ih6Mf8T9yNwzkRQPTEjNp3beoLa/ERPzXA4v+stO1HBaQC3ZHrrhDXfnm sO4Gsx82g8mTqCeiv41A/au6f9KEA/Vf9LHg35NXywpF5CsN2ZaZ1/bHLd2fuiX6s12tF6PmfTMg VkgC5n8TBID0R64pSfKvakhFn4wGMb+VZL4TUl+OVWsKuNQRvXr9iX+g5u1kwEefPXNlzEWfjH7U G4/UKLiiv4A0QFoSpIl4sHpMfOgW+JYLfEt08haaJHHtlAWmb3kS6WJAB4wCRgGjgFF5wChBtcJR sBielDxUH52aveRwe6w+gXObwrnZXM3GcS7hArqqy9cM+LWiFigHQrFAjGNr4lL8mugcX9hwS3yV xfCbvYgmcm6Hlida2GiTNvdD0hlnT1oj+YbNvjM17IZWEHL/Xiajlc2JHbJZp3w4ODh+IR9Js3ae pUxdlxe7V+BhP3/sCtNbX77uvSXnqkct8y35wMMhkS6hbo98OW2TIf3GyA1jLqFBIGKX9UjI5SfE N8nNPWnWL+oxN4lx5nPeP/NlKyMgGPjUURm2caxst+PeLGPumdvLubGlo8fGTl77xvwwhtTBSAz8 KLcQd0ff7jWGVP7U+FFXueCGDSx38skCuMFyg9Dvsu9qVcpkYvd8JvPPbOc9Of9H++zqc/PiN6Lu Vwfv9veZ+/bOurU81rNotJhAPNv/LCLxmvevRYBdixC8FiF47Ql0unZHzo347R3yp012TCtk1y4P mSHDzxDwLdsybURh3L5g9AXMoz4NWd4GYOIstR5PhO//WfvXHDAVs/NZhLy5d8Kys/TNKJTzbI/J 2Zdw175X87MVkMBjptW3WO/tXMcnMDxFy6lrDqVgeIAPv2+WDo6OjRNl05bwurVFzEk8YuIETxJm CFgIWAjYvAlYeakthvRLuSZRXHYee5ACB2whBY4UOEIRDAJxuekUuPLSNAV+xRwhj8hf/IaIDvLv VRO1SnvPWwglBBwDjm0ZjslLQQlBCQG2oITk16GEEIpgEIjLZeMyUQlFnTpRQmfmkJO2z0Muflm1 TysZFDMvRQMlekrdNUu8qXZ8WDZKanwU7qZa6SDtrlqiHyNPPXYk9TybGbc3xnm3fFA+qVaNktos XTyflnCnErPrrKGYXaHPoc8BWy+CrYOzw+PGlsFWNkg1hibIcUReYSMvB4RBzzBM1kJK4Uzl96kV mNTvaazA5y1METrJDivL1i1Q4RWjVNkml61PMVagGDEBzBqKCQACEQIRKLUMSuEG7vgdCEREHiJv ezLKpbLqkHFUjp+BMOTCCDEw3tfN0PrGyJdABAbZjdGGu8cb6QOP2bYuhQO2fqf8MkaubR985z4I aXi9642zAns75E9OdqKXyezL8te3aef7CmNlq/a1LwcIgerQpYAg/yU1Vuha3Xatjwsv7831bFL+ TiXoHufvopFhuCxU/0alLIuXx5ur6rC/REK0muzQq4+N48NDo6RIXvEceYiEKATPrKFIiELfICEK lNIVpQBMSIgi8rKIPPCDV+MHSXpH+ethxQy9D0UrdV4xM2dhiq5Jdpga1QtWzBwZJTXKiicQjyAQ MQHMGooJAAIRAhEopStKAZggEBF5WUQe+MFGBaLyylQg/n7ZPVXt0koU/j6S5dx4n4RDRoRCTNEy +bB1BRL188eu7MRlbi6r+F0gdWtG9HbxpO4xpC6msllDMZVB6kLqAqV0RSkAE6QuIi+LyAM/2KjU VSXpplK3xYKADhjpMFfnEgKJZqYonETXldWQSD4iq1Q7MSLXFk8rph6SlexJVcIi2ZOVUtmIPF04 T5ZTCyNiVsWsilkVqnsVIyS4QHUDpfKCUgAmqG5EXhaRB36wSdVdViXopqpb7uqlprCefGIu86mQ ORqL7zRrU/ROPuxegWj9/LHbOK9ffTq7WOI+dHnBJmd1H7pqRIq5eIoYZe0x42HGgyKGIgZKQRED mJ4FTOAHiDzwg5wqYlWDaKqIP1o2I12fukGf6ayFk+1M0Tj5sHg1Ffyx294jPRpSEo4tjxmcPD5U POHEt8W33VOlcbJPFTAm5hiqJ4cHRnRQQvE8WUaSASRi1lCQCCQZkGQASumKUgAmJBkQeVlEHvjB RpMM8X3dSDLonmQwRSN9bpNdkzuiCb1lbrwv2ACOREPk2hclGtROCCQa5j2ZmmhI9GRFIXOiJ48O a0a0rqh4y0Je4MjFW05OaidGtPymeI7EIaCgtjFDQW2R+kLqCyilK0oBmJD6QuRlEXngB5tMfVXi O046zBz5jHSGzNYw4TVrXYqeyYedq6W5Op3zvTcxG5O7f8F2EmS1Ik8+mdXa+pESRDFh84HlBm9+ /lhizCQsyZss2NIPM/qz5gWao8Zc5+Mc5a03cn3nKCucuDa5dz8+QTkCjugF+Ys4O3lbMS4wvaUi Hwcnb4mJ4fvHMznAfOuNXB+Yd86vJbG5nhCba2+6ykFhe+ecxIgPeXgfUL/VUN8PgfWaYf0eoW6P eNwPSZ/7d9TvWe4g1sn7yMAiA6veV5YgA4s7tC9CGtyhBUrlBaUATLhDi8jLIvLAD16NHyTdblH+ mt5u6TLbZaFqmVb3WSK75omFXvdXJkmU//d//u/IZa7p33sh65FQZnTkToSRa5k0tLgbv8+UPCxU 7OLO7Tr3I1QUACUXV6xVjagWSfEWf1ex+BvUYdZQUAekFpBaAErpilIAJqQWEHlZRB74wUZTC1En Thd/W47QjqRFLbsI5Q9SzU1RPPkwfKVExG6n1W0vtT58wQ59ZBkiV74kyxChSXKWoVwyooqWxcsy 1DRfaD8KWE+uzyDMkYjj81EoJ5wbFt4x5hL1olrI9XiVOQgUCNTEEhAoJFhehEBIsACl8oJSACYk WBB5WUQe+MEmEyxVJYof1m6IJmqcUImZlyrmklylChEsONjw2Cir4V48VXyIe++A/llDAf2QhpCG QCldUQrABGmIyMsi8sAPNioNVeWtqTS84qOQkbppsiCYaiiy69EBIz0uWi/EEGHfhf7ZU83PnRCq 12rHtePnO0n44H2i8Sm6JxcGr0K4fv7Yvaq3YxbePd6HP/Cpo0t9jvD9/BkLiebmv+rAeqT91pcr WY8b1lbQ5LPAw2vev+422tfU7V1/OW1fy4II1+7IuRG/vUP+tEk8q1SqHh0a8uQX2Z5tKmjyqiNw q0qerC/NdhRPsxW197elLsraOn6u15N4Wrza5R8T7HnXvDhtdhpXzVbzot49U3blgZRZ0d9GsOkg shwJuNQ12a/bSd3W5YhHGXtocGjwiSXQ4MjRP9sICSfI0QOl8oJSACbk6BF5WUQe+MGr8YMk7af8 9ZCjZwEf+SYjn3lUpqV4ifqFHthOybd8tv4zsvXI1iNbn1m2/vj4yJBHcMvmIFlf7GT9MZL1SNYn E7aIVSNZ/5QvkawfO2JroGQ52iYrS072mfeYEGqO5UrZFg7lEW9jzs77ZCiUKPOJzb4xe5kz36pK H84cE+l/s4QM2A3ug5A5AaG+ORTTtRmOfJZT3bPSqRmRvZof/9b3ubPUYIiXjTnnQUh2XRbecf9W w84fCvs073kBCnSpnlflYKY93+CONxIgQ8adr1/fjw1L6f195G+Rv0X+Fvd3VwRh3N8FSuUFpQBM uL+LyMsi8sAPXo0fJMiZWhR2EzlTv2rXiVKzF9RhRCY5tC6AutDUFLmT7EdV5uRx7Q6LuaXSoVFW qrF4tTtOULsD88KsoZgXoBuhG4FSuqIUgAm6EZGXReSBH2xUN6pahQ/LTM4vmx3VMK3koTIrRcHk w8AVqNPDgZwxK5O7XJVrSS5PWSobFTXSCydxKwfPPv2ipvZTJzrypFY1KsU8RqTy/GNEagq0Ex1Z OZFDUoFU8TxZRtYFrGrWULAqZF2QdQFK6YpSACZkXRB5WUQe+MFGsy5RJ00P06g36o3Of6qm6XWM RmRYiorJh4kvp0/J+0d//vjMB5YbrcCIWX+n+27rBXkobLrGputsS6SelI1KBbuusev6n5UKdl3L 3seu68fETNHVSSa6MfS5K9o3sExqX1tye6h8O2FTdou6I2rL7aid8N5m+6ciqAIisIlMISkn3C6z fdouY72AjLyecA12asfNh1CHUJ9YAqGORP6zjZBwgkQ+UCovKAVgQiIfkZdF5IEfvBo/SNKL8fox V8zhISMtatmkMWTmrXRIwSqrJif3Ej0TYypbkRlfpeJs4pbE9Mz4/pwyThqBakdi4tq5UqVyYlTU IsXirZ2rpq9CzIMHsk52HUacASUGn/IlSgyOHYHEFYgpiCkSV+szQsIJEldAqbygFIAJiStEXhaR B36wycTVodqcONV+X5nPv4smqhKxpBOVwlYN1Wo9aqKZ2ynpVlqduvv1orNHZLsKtjp1QQ4ut1a9 VjYoj8tx09I7r+icfC/Ozcgpa1uquzip+CcnKSlH2ZbcLNPN18jMz6Ld3CVkMUDkACnaul5kpaE6 oTpzwrJl+I3bmOivrTBCwgmy0kCpvKAUgAlZaUReFpEHfvBq/CApKx2vRnkqGma547r+KlmrWqlV SvqxjfOEQ686lbunF535E9mTRsKCIpXU82xm3N4Y593yQfmkWjVKxSyzWEots4hJDpMcJjmI4FXx GiIYKJUXlAIwQQQj8rKIPPAD8INEfpC8OiBxlRWJ1hzNKT/NlxspLBADeMhHAZszPbemYc3RqzsH a46w5ghrjrDmSJ8BgjVHkFOQU5BTkFOr6AWkW4FSeUEpABPSrYi8LCIP/AD8IJEfIN2aTp/EkByK KLJMGlrcnbM9t7Yh3/rqzkG+FflW5FuRb0W+FflW6CnoKeiplJBFvhX5VqAU8q3ItyLywA8Qhi8P w63nB3X3nni+9U0ocSI6yLFcahNqmiyIVw3MsaGvlV1M2rOpjppIOE+gLTAjYMS0qW/175VdhT5P oD/ywyHzCfvu2dRVyWoij8dkvXkiiuMFMIm/9OuYxOWrmMQh8iHygVL5QCkAE0Q+Ii+LyAM/AD9I 5AdYVJVOn+SRnXMW59YiLKV6dedgKRWWUmEpFZZS6TNAsJQKKgoqCioKKmoVmYAsK1AqLygFYEKW FZGXReSBH7waP0hacKP8NV1w84HzMAh96pHJMZeqlVqVy39s4zzh0Kxc/ofLy257j6hMkv+3mLHJ Y0IFLgrnL0ztphfO12DIUDvgZBSwHrm5//ljiRGjsPXh0I17lzqWSc55EJIGd/vWYORHa9T0hZUl jNYcZ07PG+34uRxgfmB+YH7IDK0KLsgMAaXyglIAJmSGEHlZRB74wUYzQ1EnIjOkf2bItC0RZMtk hk5kg5AZQmZo2czQUTR5IzOEzNC8jWB+YH4TS8D8kBl6EbggMwSUygtKAZiQGULkZRF54AebzAwd KW0/1XRd3/omfp18tGxGuj51gz7zNZZz6fZqruS6H7tzSi55iJRlO5AoenGiKMmnlWSfWswtVSpG RaFY4RxZqT3fkarI2GNH+n3z6Fg4Us1BxXPk4fMdqYZcoiNLldqBUVHTZ/E8eZTmSTBbMFswW2S+ ViVjyHwBpfKCUgAmZL4QeVlEHvjBRjNfUSdNMl+fuCdrMO9649zPnmqkVsmuyMQUOZMPC1dKak26 L2Zlcv+rqEgWvNXKiVFRQV48wXsMwYsJbdZQTGgQvBC8QCldUQrABMGLyMsi8sAPNip445uALs66 V3/vqJZppXIju1I0TD4s3JTKXbDLR6jc42Ojot4tnsY9efbt8WMFCsnrDKoHRoQZhXNk9eD5jlRr hJIHZFk4sphLiKqpS4jAqsCqwKqQdVmVOCDrApTKC0oBmJB1QeRlEXngB+AHyfxg9nzznrg84aNQ lZq1TBbjDDm2dG2SbM7gJCmrNsbggPMnfYkDznH0DmZxzOIZhixUPlQ+UAoqHyofkQd+gDB8eRhu PT+YVflXzOHin7/4DREjx7+PcYYcW7pJla9KNUDlP+lLqHyofMzimMUzDFmofKh8oBRUPlQ+Ig/8 AGH48jBMloKq2NxUCn4UDhB6Z7IYXzVRq60Ucwamyrgkd6nhhcKRC5MPLygceaxwYsE+hLJRVUsS ird8vvx8R6aUfygfHxtVlfYpnicr2IgAcjJrKMgJkhdIXgCllkGpg7PD48aWoRSACckLRF4WkQd+ sNHkRbz8w7n8RMi+h0U45iPF2BS1kw+zV6BZP3/snneXOuPjGIfBrj1Vc6KAJDHDUD4sHRpVBWDF yzA8/5CPk8U1I47KlQOjquaf4nny+ad8nCw4y0d6sibrmKips3iexCkfYLUxQ8FqkfVC1gsotQxK YcnO+J2NAFNCAC8T3QnvyDiff3k+sKehPhPY6rV5dAJJQPiBJIAkrEoSZnfniA5yLJfaROqQGGvI sZkb3Jpzgq052Jqzil+wNQdTOKZwTOHrM0LCCXQ+UCovKAVgwuoWRF4WkQd+8Gr8IEkKxrfm/Mb8 G+bzQOvzPCdGpmq4JF+psYXFHmtd7KFAInk7Sa10YEQgU7wb66mniSZ7cvHGnGpJnhBSzDNrqk+c WZMHD6ygmX7+EDPRUEyelhmlp4L7IGTOvMngX+BfE0vAv5CfeRHWID+jJ0ph99H4HeRnEHmIPPCD rPiB53PeP/PlFaNuCTxm252Q+krXJHxg4FNn5n35xhYTjJ74me8xdrHIJ2duL8Uj03e32x/ku2NP kMfzmTxQhu28J7tLeUiXUdG3e40hlRcaP+oqG2/YwFKrDide2GojLTcI/a7cZ5fc5ef/aJ9dfW5e /EZ2hmHoBe/295n79m6ybuct9wf78tn+F9cKWe9adH7IgutT5olB4AjovuZ98azP3EDMa39yshN9 kEQfJA8fJLxPph+ULZw2TRNXLxhPgfSA8EXehtSHl6e5T/np87BUx35lkXFaDN0F6PDzxwUL77h/ SzrMHPlWeE/64uearvjrREnBs+/mkLoDtqdCujBzR/h+7JECxcGiKWSZZaHxne4dy1TN3soVoMsN j8AyY27Zz8XNgTRjV4iFX+dGgI7D/F+kHoa+dTMKGenyW+Y+CXh6KagW9ball19rvXseFeGzI3o9 zsm3dsrIKWvTWg/bJpoXp81O46rZal7Uu2eRwFr8rmxLblRVvkZmflRYZltOLMfjfkhdk+Vjvs7X ANkWOYeNNgu+jRs1c37AjRos5MBCDqDUOlAKG23G72AhByIPkQd+kBU/SEquxyqFXjQbb8uN66bs i8nj+kX9mrq962ajfnGhenRaczZKwct7s+GQEfUtl4XKLq125ghXzHMSvRbrx6xLHCelgwifp33P g9CljkIxvTp7KCwj0rSULseMhhkNMxoU76rIC8ULlMoLSgGYoHgReVlEHvjBJhVv6UBVQZgqmUi2 qgWJ1CaX/oC61r+j9YlyvWInFOKX+r3xa8oErfROs3OZonTyYd5K4ladESPvXpMO879ZJiN102RB QNrccsNH+xYSh4w6Z2E6ZLqdelu/gSCt0nkk7JGGTUW3H0xPQP7bMl2vipIm1q84Oa4YNYWShStf UTt4diGQ0oGq6ZNcU+Xg4NCoFbM6TS21Og2YJJgkmCQyTatOfsg0AaXyglIAJmSaEHlZRB74wWYz Tcph07TBqTWwQmqTpkMH0hnU7ZEGd5yRO66SFxDLJS3WEzO1q8awXgmG59mfIory4YmVklK7p83G ZetvhNoBJyo5VRL/leNn+wLcAe4Ad4i/VeEG4g8olReUAjBB/CHysog88IPNir+olybir9HoXJIL 6kQb+tXQ0krdJZctUFbHaMfddhR3WkHmPnTyUoaPa4DsL3MHVUVa4h3UcuXo2KipZQrFu4Naxh1U TJKzhmKShIiGiAZK6YpSACaIaEReFpEHfrBZER2v/XoVMlvLHeZXzBFCjnwRupF0lY2TxeopyiYf Vq9AqX7+KNahAaKfo85dympNCj+/j9/TXhDnsTIUsczGcenYqKlF+MVLbFSQ2ABxmTUUxAWJDSQ2 gFK6ohSACYkNRF4WkQd+AH6QzA+aH1pLVYgrRVAyPadHnfgu2xydAlX3zaHQdWY48lUQ6pXASbM2 RcNt/eD4+WO3c1HfIwMasjt6T2hUWiFh/QOmI0xHmI4wHa2KOJCrQKm8oBSACXIVkZdF5IEfvBo/ SNR28Zp5bVkjW03EjLTHxbRUQ7XSdElW6qzl3hCh2QJZ+LBMdtuX7bndyAtGhlpznlwfrXJk1FTR r+Ldua3izi2mullDMdVBCkMKA6V0RSkAE6QwIi+LyAM/AD9I5gdJAvZB5FWUyKssJfIWFMGmnmcz 4/bGOO+WD8on1aoRJQoKp/dKqUWcFzg1rR72ccmoqcgsnnSuvcCVylXJrjypnBg1hazFc+UhshBg GbOGgmWAZSALAZTSFaUATMhCIPKyiDzwg1fjB4mKJ+qlyQ35S4+507XHDe54o1D6ZLytXGh/k/VG PiMNamt4o/451qcIonz4YQUm9ng/fTYG3UR/G8F6zbu8aJCrdiMXJq7NqDck4A4LVQN81me+z3ok 5IQGjzZdaNWZnZGrX2eifD8IFAgUEizrRRUkWPREqYOzw+PGlqEUgAkJFkReFpEHfrDZBItyyzTB 0uyJjpgeHK6aGE+h6F7VXjlgTq09q6B9HuxfSaeLoT0UPhifVae2uFsm27ekY6z+5OXJEHkz56vE MaaQAstq1rusZnEpwVK1VDFqKrCLtxbkKN2VWx6eP3+MAtYjN/dLlSopR6RqCu5yjpU1V6+YTe9J Y0g1LDHbvIon27QbAFHNkUAmT8eYfE/EoPCDebNBukG6J5aAdCMp9yK8QVIOKJUXlAIwISmHyMsi 8sAPwA+S+UE9ni0an+ZBinbghUyaLWWyNqddvCGi44nnsx6TpTDFVUOek6U8VvR33Ut5FmRAc2Hy 2ox8Kw/nUSuzekwAriPAlVCVX/iPYJxvCO8J74sXPRG8ljmyqU+6jTYxuesyU7rm7ZxLElNTKtO7 oJ5Oyaipeax42ctj7GQDZ5s1FJwNnA05HaDUMiiFnWzjd5DTQeQh8sAP8rTQqqwKiD4cG2I5ns3I R0v86frUDfrMnxavUS3W69yQNHNTJM8CX6JOz/oXFJUX1+k5keuJ1Hqj4inyEyhyzLizhmLGhSKH IgdK6YpSACYockReFpEHfrBZRa4cNlXkX7402qQlJKT0hJCmfzFTw+XxSVamCJx82LsCs/r5Y9ej 4XCyjWm+CnBurVubgJ0zODEQIriaBMIf1q3lsZ5F3zWsMFrr4DLWY73cREPaAo9XTQeYcYdsZ+Cs yxmPEiOgOqA6E0tAdZAKebYREk6QCgFK5QWlAExIhSDysog88APwg2R+0An9kRmOZPnQ30fMvyef qTsY0cHjPSeJUjde7qbz+2fVdr3WWvz+eZ486ZTR2ZtsMooXPMixXRvN5UR4PBngrcvOu7/Xrz5d XuRmnGeWvPmL+gPubmdoIGez4NvgZHN+ACcDJ0POBihVVJQCMCFng8jLIvLAD16NHyQqPbUgf6r0 JucCiVYGRdhRkm7vdqq8pZe0XFx023vLlN6tqNGPnTIv3imz9WPFZ6FvMfG2LNrhimAZ+HzkEdGi gA4e5dASx1BKqY6jI+NQDbHCDZzDg+dvsaqoPYCJnqwoVxYzBg9TYxAkFCQUJBRJqlWnQiSpgFJ5 QSkAE5JUiLwsIg/8YKNJqoqq1PEoSSXbWoDcVMzMFImTD4NXTEnJjJQsFNojfXHRUJoe3Aup63PX +rfaNRPzwILxsqAICfJVkaOfyFdhLsRciLkQWnlVPIdWBkrlBaUATNDKiLwsIg/8APwgmR985L4j NMdyp5BW1EB4qLPiWsF9oFqrV2UVZVeKONv2XiffHXsCj57P1DmkO0L6C8NDKjdi8YHlviE+c6mj zqglkUvkYSJzw0T344Auvp71rGcdI67n4BifJvMwFNo+H/jUcdRxMn9w//aGueZQZYwKNkQaki/I 0kQYJaTVaL8h1CXN0zM5FJabVSJOE59V5JXkwUxqjEkGYY83h2o73yiLA94P76jPSI99Yzb3HEHh UiYiSUOgAqACoAKgAlaZwpAl1BOlcDb0+B1kCRF5iDzwg1ytqIlXsDkVmsa3bkahkNkN7nijULrk zP1m+dyVOkC1Wivhc9o4SxE3+TBvBVa1nPqNl3kRPe+M3MnJxMztedzSsesnlund/z4LuD16tGIK 0zKmZUzLkO2rAgxkO1AqLygFYIJsR+RlEXngB5uV7fFqLS3L9Lm8badap5VGm5qmt0g7a7fqbbJ7 5vZIW0pSdagS8/feEGoHnNy6/M4lNCCnjbP9mCeSx0c08Kfj44o5PGTyVrbJeiOfEZPayiC9xspV u6H3KPnMTSr6a3L81DIle6oLyq0cquIhxSsOUta8QI/aMhdy4quQt++JaIEsZz4eMgGxXNMe9cSU uVRmsBo/Z/70XK4PketsFH/RLBP8YJzOY+TNch0f32p7KlppueSCOox07oOQORr2/0VHb2yIxjah bm+5IaB2z84c5Of2+F1AmpLzuywcD4YIV/QbDX809R4Ob0ldMks1X9wst/S+qmTawpuF3BVykFze yENASYv3mIYU87Rx2UoZFftImiBpot5XliBpgpsqL4IZ3FTRE6WwY3r8Dm6qIPIQeeAHebqpUo16 aaa62IfmZUe1Tbd6YtKwFBmTDxNXynXMJidmConJzcTEZwMpXaPljUtnQ+IrZdX1H5bWkV1TLZdl PglUeizY02/gLF5J+GSt8gghE2uVlw4OSsahSjcW73ZE5fll36vq3u8iV5aNQ5W2K54rqyhlB+I1 ayiIFxIzSMwApXRFKQATEjOIvCwiD/wA/CCZH4xzK+SUhlSWDZqkIGJ8IVnX1VT3oVj5QoX31OF6 iU5dfNoc8g7PdOXi4+aQd0DeAbwCvAK8AnkHoJTuKAVgQt4BkZdF5IEfgB8k84NJ3qHDgkAuR3hG 2kEpYCjkdSjkBcfNQSGnuBIzIGZAzICYAVedAaGQgVJ5QSkAExQyIi+LyAM/eDV+kKh4lMOmi+Kn pQFaQobKqiN10xSPiL5nsz9lcYrwyYftKzCunz92m616e2+ZMkQ1Fc5Y3PDixQ1bP1YcVYdI1pAn vL/UjptafMfNmUMtDRGE2cwMfe5aJpEGaj4IIpQMiNx4lVRracFIWLx7qFKTOUo1DRUvsVZDYg3E edZQEOccEmd5qS1GbSTWgFJ5QSkAExJriLwsIg/84NX4QaLiiRd4/0DN24HPR26PfLRsRro+dYM+ 82WeSW0z2fVk8qnHhSVCGRH2XWihnFagqNdqx0LQPdthwh3vn/JDihzKhe0rpts+fOy2YybePT7g XbpBn3Pt95YxN//H2a9H8vftXmNI5U+NH3WVC27YwHInnyyAGyw3CP0u+x6S7449maM9n6l00s57 cv6P9tnV5+bFb2RnGIZe8G5/n7lv76xby2M9i77l/mBfPtv/LLDxmvevu432NXV7119O29ce98Nr d+TciN/eIX/aZH4d1+GxcSimUNmeaUMK4/oFIzBgHvVpyPI2CD+8bvrtMJ5+K2rvswh+C+IE0fFz vZ7E3w4j3fRQO30MPu+aF6fNTuOq2Wpe1LtnyrA8MDQr+tsINh1FliMRl7om+3U7ydu6HPEolQ9x DnE+sQTiHMn7Zxsh4QTJe6BUXlAKwITkPSIvi8gDP3g1fpAo/tQSxqn46wiNYzPyiYbsjt6TFnct IfikW/RdF/u0zdup9pZO1Xc+tdry9FZ56KqyV5Ufj05lJJYbeMyclB8n1BaxEVUj530yGPtsZsGk 5YovO+oTMbctGH5phZrKx0YUtcVbLXeE1XKYUGcNxYQKwQ3BDZTSFaUATBDciLwsIg/8APwgmR90 Qn9khiOf9cjvI+bfk8/UHYzk4r3dZaRd/FT2zu+fVdv1Sh38/jlFp239ANhbUJsrt2ZtdNlE/Mj5 1mXn3d/rV58uL3IzzDNbKPEX9QdPHLym/RDCGglQMlAyULL1GSHhBCkboFReUArAhJQNIi+LyAM/ eDV+kKj0lMOmSu9UHsht3YxC1iMtatmko07Rnq4WKMoGx6f8sJ36b+lVEzHzsjLoJvqbKPFXMO+0 1ZnfvLnlHfaGBNxhoWqAz/rMl1nNkBMaPKrv9WjfZuAx2858n+ordXXbfFTKa5ELpntXsZF3ZiNv 4oyh5vUFy5pqh8ah4gXFW9Z0vKWFAzeaV46XEsR2PGzHe8IRSDVDSkJK5oRAyPAbtzHRX1thhIQT pJqBUnlBKQATUs2IvCwiD/zg1fhBoviLenFuO94FC++4f0taD9ustN+Ol2Lzdqq9pRPLnYtWez4F lThWVN3F5CRTqXZkRO8XL8l0giTTk2PnKJrfHyeZGlYY7e50GeuxXm5GUGZZJjPukGIPrfkicolD S+0ox/E5C8Mz/fgc0HPQc9BzpO9WJZJI3wGl8oJSACak7xB5WUQe+MGr8YNE7aPKGSF9V+D0Xden HlE5vO5Vfak83pHaKI083pxMfiqPl+hKtSf3sStNKzC5IX5NrhgyjsrVqhFlwArn1aMDZEefjkg1 7yE7+rQ3kR2dcQbW4YGog6jnjqjLS20xpUQiDyiVF5QCMCGRh8jLIvLAD16NHyQqwKiXJgqw7Vtu SNShjWpc6ZWym7Wu2ApuqeTAov15/818q2/RG8u2wvvcjJLMUgPflDtMpAeQHljwfUz/mP6RHljB CAknSA8ApfKCUgAmpAcQeVlEHvjBZtMD8W16X8mpFXi2PDxOLXfxSUPY5XNb43U+T9u8nWpv2XU+ u19PWw15bN4oYL3ZA/NsPrDcQNUWcx/VFkscTGp9z+LBVICxo/dQScisJY+EY4WXj5cvfS2Vro7e Hho9bhrfe47pGdEmq+KtXkrdOpXjobLJBOVxbANeh9l9wxvd2FYwZL3rgI98kwUxxEEKc4G3g5jv SOS7Yg9AJDEhUiBScidS5KW2mCMhiQmUygtKAZiQxETkZRF54Aevxg8SdWJ8s2I0zMgnGrI7eq9x 5nKBodup65ZOV3741N57E7NxwahYvBuxWj4qGdEW1+JlnspbmnladoCoNHbICftuDqk7YMTno1CC InV7xGdUvBqlhYjl9rnvROu6qMPdwVJZ7uP4cal1gaIud/goIEF0bMxuU84DLsvrUTmrQI6cM2LW BjoPpt16Z4+IwREO2XJDQ83c06ExGQf6DYOJZSmdD8YMxgzGjIzaqhiMjBpQKi8oBWBCRg2Rl0Xk gR+8Gj9IFDJRL80LGXLF5FqnxpBqrGlmjEyRN/kwd7VMWvOqsUxZr2MVI4mJtKOTUtWIyn4VL5FW QfVrTG+zhmJ6g/yF/AVK6YpSACbIX0ReFpEHfrBZ+RvfFde5aLVVw/Sqby2sShEw+bBvJYHrjGT/ 2ey7HMHeeHUM2Y0ZvWAAxHeydVpfvpJdjw4Y6XFhj5C/RFw1yOsd/nqtdlw7fuGwELbqPCyWyXic KGBLLmReLh8ZUXXu4mU8qs8vZH6y4BA1l4WB63hyJ2BgXJ3VT1tnbwNn9N2IJqvi+baGDYFPx2V8 oefDdr/mxWmz07hqtpoX9e5ZbgZQZvv9LEeeDyCijv1a7FGFXX4QXRBduRNd8lJbzCGRlAVK5QWl AExIyiLysog88INX4weJ4k8tM3nYdyNPYe9S+1a1TqvM7NS07dRuy6Znr8b7slrUEiHlSrUKtQY0 BhpDra0VaaDWgFJ5QSkAE9QaIi+LyAM/2Kxai1dJ+H1kmfIMdcsmXZ+6QZ/5GhdmSbM2RdMB0ABo ADQInlWMkOACwQOUygtKAZggeBB5WUQe+MFmBY9y2MPtqYtOUzVMrztTwqoUAZMP+1ZgTktVeRvH 46Sn/1fl5G1NjWq9+jqyK6W3MR1hOsJ0BLm6KuhCrgKl8oJSACbIVUReFpEHfrBZuarc8qjC2x33 b0mbmrcsJGfjAuqqwVqWekuyNkXw5MPuleTtbrP9Nb4DGigNlAZKQ8Wtii1QcUCpvKAUgAkqDpGX ReSBH2xWxcULlbVYEMgiVR4P1M6qh5pXxahdtch+zTVdq92GpgNmA7Oh6daLLdB0QKm8oBSACZoO kZdF5IEfbFbTxWsPT48lmoibummKRxrvnnvKYs3VXLNVb++9Id8EtsiDqStQdkBuIDeU3VpxBsoO KJUXlAIwQdkh8rKIPPAD8INkfnCm+IEYKKQz5L48E9fhISOXQmnRUMiSgOyeda4ucdsJ4APwAfis F3wgToBSeUEpABPECSIvi8gDP3g1fuD5nPfPfHnFqFsCj9l2J6S+OkBr6wlE3TetoOcEMQKxyOwz tzf+PsAJ4ARwgniBeAFKQbwAmCBeEHngB3njBwlr5soHUdxN1sxFw4x8oiG7o/ekJRxomcICjRfN PWnyPB/RbNXch08tbIICYAOwIejWDC4QdECpvKAUgAmCDpGXReSBH4AfJPODYRh6Rowc6H+DzRk4 4VIm4+YasBZYC6yFFgNKQYtNXwQwQYsh8sAPcscPdBcuF/wblbf9niNett1o8t2xJ/Dh+Sxg/je2 855cunKskg/UvB15iwkV0BhoDDSGWns+7kCtAaVyg1IAJqg1RF4WkQd+8Gr8IHEpZEn10rQkPDXJ ZYd8JR1J+9XQ0mvh45yB81xDr2WO9Z5juTETFwyCsmwHdc2hBBHTCtm1y0NmUM+zmXF7Y5x3xWdO qlWjpIbLtgyJ0tFjP01eE50fxiAoGAnHBKZveSp3MevJf5ZK/9J7pOzyMfm275c51Lx8UInBRl0O lM6Q+mpa0+wQ+6lteg+BZpv8wW4IlZghOjAq3LPMUKgmg0ezflE31HRcOLioaY0WWDcPdg92nzt2 Ly+1xaiC7B9QKi8oBWBC9g+Rl0XkgR+AHyTzg/Zvza/LpSbUIJimJmSTSSekjqfxdu4EI+d5lGb5 qm4H+7cxz2CewTyzZmyBDgVK5QWlAEzQoYi8LCIP/ODV+EGiZot6aaLZ2j4zLXWcoRI2+uq2BYZq rt3a3fYeYd/kcTFOdGZnvPQyoBpQDaiGlFsVaiDlgFJ5QSkAE6QcIi+LyAM/2KyUU26BlCuQlBsw l/nUhphb8H2ANcAaYm5FsIGYA0rlBaUATBBziLwsIg/8YLNiLurFh93hniedwPukbsnPMtL1qZyY Cf/GfNKU3eQynQ/OebYLNBeArXq3KSSgDGRSh/ADsAPYIfzWCjIQfkCpvKAUgAnCD5GXReSBH4Af JPMDpUAiAfIBAgQAA4ABwKwVYCBAgFJ5QSkAEwQIIi+LyAM/AD9I5AfJ56WYNqduyA2XhUaJ7I4C 1iM39yTGIe60Pz+nEXlhKav1Pj6n7lgDSs6+e+JXmE+o2yP/3QpQwgQTEiYkTEjrRV0IVqBUXlAK wATBisjLIvLAD8APFvAD1zhljpQgLWrZ5IrZ9J7sXp62rqBHgDfAG+DNmvEGegQolROUAjBBjyDy sog88APwg2R+cOWZZY/7oUM96A/gC/AF+LJWfIH+AErlBaUATNAfiLwsIg/8APwgmR+YvEeF34fl N6QhHhL5WAwby1RHYBO1hMuHMgHyAHmAPGtFHigTPVHq4OzwuLFlKAVggjJB5GUReeAH4AfJ/ADK BMgD5AHyQJkApaBMAEyrAxP4ASIP/AD8YFV+EDBz5DNTNKX0hvBROOCyu0Sv3TLR6JD//BFjDnfJ 5cVP1Kiclhc3632mYlGvmuEX9eY8jdKoCnhywYP/CIpW66KjIqIhmrKU4XqXu4gyE/GTwJIxoKTA nLrmUM6ZphWya5eHzHhwp3GkJq9twYTS0WO3TV4TPgljU20wEh4JTN/yVBDMjqd/Hh3+S2PYeF8P 5CEKZfH9eStBUEFQJ5aAoIKgvghekMDSE6Ww6Hf8DhJYiDxEHvhBVvxA/9qVIhqE/mQxBlFMOb+U C/Tpemrf9J7T65iTMCdhToJmXRV3oFmBUnlBKQATNCsiL4vIAz8AP0jmB+dt0qMhJdSmvkPEj9MB ln8DaYA0QJo1Iw2UCFAqLygFYIISQeRlEXngB+AHyfygTq6Yw0Mmfj284/4t6agFn6RzH4TMgSQB 5AByADlrhRxIEqBUXlAKwARJgsjLIvLAD8APkvlB/ctVm+zG2MHMhqnZHWclNfImu07rnmezLrVv VWO12ng6NW2eM+m0j+znjy9ej4bMuKHykPUrPgplnLZ9HnLxI/Ej7RaMiLJs4OM9iEcKFIq38fAo beMh5mvM15ivMV+vitvQ80CpvKAUgAl6HpGXReSBH7waP0hUOhXVSxPt+1n23x1TvXhq+cyUQofU TZMFwVRBqZZrpYuXMjtFAuXDAStp5t3Pp/X2Utq4KhvyWBtTmVswbm+M8275oHxSrRpRXqVwarlU glrGbDhrKGZDqGWoZaCUrigFYIJaRuRlEXngB5tVy8phU7V8ag2skNrk7H+PLM8RnUIa3Pe4rw5j US3WSiWnmpsiefJh+ErqOGbdneb1bvp2rzGk8kLjR11l4w0bWO7kk1tvpOUGod9l3xdVODr/R/vs 6nPz4jeyMwxDL3i3v8/ct3fWreWxnkXfcn+wL5/tn541XBbukD852Zk8lr8z/QFNHLZgVATMowIB WN4Gxio4p3pxqZDXo8rXgq5l02JW2z96VYqzPaTB/2fvbJfaVtp0fSpd+bHL1MaLzxCYqUoVMeaF ik1cyFnrnT0zlZLlxmgjSy5JDrB+zUHMAeRYcihzJKNuf4CM7CgYI9G+/qyVBDB6uvu5+r4f9YcU f/7fDRGovSntWmvrvDU7caG+Ud+TSFDfVOeeBRuqc1CqLJQCTFTnyLwiMg99sDJ9kFmdG/XSpDr3 1XdVR4TDQex2PCkGwW0i+qPhYODd6wc2qji3KNpZFWLYypWvLSu9cAVKQ2kojYtbli24OChVFkoB JlwcmVdE5qEPXtfF6WaZujh1jpjrSNEIHL3OwOBdCHNDNdy/WY18Gw90erPxgI0HTHpMephiTDGU whQDphcCE/qAzEMfoA+W1QcXF1ZrUwzsMBbB1ZOV85nG7kgPwYnjn5wgnjx9JNqh7UdXMjTY9i+O F0cHsR8FCrEhNo4OSplKKcCEoyPzisg89MHK9EGW6dkd5d3E9DSDjutJcd7ST2eUv5mGtsDKlCPI JTTUzx/HPbUjPs9587slfT15cLC3d3DwvPgvT2vi/dH+vsl9zCJjZldmV9z3y1IF9w2lykIpwIT7 JvOKyDz0weu6b33B09R9n6lvidVhUGvwvnFBsCa7t58/1KE/uV5I76YPxdfNNAjCWDTse3WntXSG oRsbuIm43bBMHgJbefpeH2//aPtB0tdSWIFzI5PA9AAwr98tq2F26ucqy+lJ9GFOaLdblnldrcMy ubPzbCXZ1SKNrSRsJXnuz2NtsDaUPpdENaVPKFUWSgEmSp9kXhGZhz5YmT7I9D4z5yu4/cTziMkm hJbdU01i8CELC+NdYHrKEflyVRDrotXa2MxXA9XJbt4ipZ33B4cLepmpi6mLqQtruyxssbZQqiyU AkxYWzKviMxDH6APsvVB03XCIAqu4uqJlc+PpQ9JOHZi97sUJ24oHeXQ9LMbZdRnI1xg2t78aNgU f7l+N7iNRHRthzKarxqZcphymHKYcp4BGSwplCoLpQATlpTMKyLz0Afog2x98NuWdG/ElMcn9ctQ NGUU2T0pPnmBc6Of36z3x81PswIq5UQzG0ovIma58TOXG7/5zPr540qdgKK8fULA+fqbyZvJm8mb yfsZiMHcQ6myUAowYe7JvCIyD32wMn2Q6evSp0h8lmFHJhZaVAbj5cQb+jmN8r+TIM32a7Vr2+/J LUvGYmBH0W0CEGwbWAbL2LYXJQ22zUxKbdcPDmtvjFKACdtG5hWReegD9EG2Pvh62RCX0u/Kv78H w+hhMay4Sj7fspqiUnMjJxBTw4lLgUJQCAq9KIVwKdRSykIpwIRLIfOKyDz0wcr0QSLfg6t6qD5x 1C3RQHqeFduhXiv35gVE7Ax8GV/b0SAKv6dUxLzY637XiMjzHbazlz5w/Nizu13XF5/94NaT3Z4U 1n0Uy36kn9ysXZ7zQp3Vmma9XzxLUkFEMvzuOuz2ZE5mTsazvzBj8OxQqiyUAkx4djKviMxDH6xM H2T6uPTlQZcyDoPEzjqxqKiNlbd2KLOWhL4J+7+EyTux/fjvlBB5E7b/+RGLu743wdAglMroyXcf xcN4mFVlnEAL4J98HcBjADGAUAoDCJgwgGTe7NfRB+UzgLrBpgbwXHWDL+PplcHiOIqCZFaO3cAX tt8Vn+W9aNq+3ZP9pM+EufeuPLspFlilcjTKEhrt54/KuXX8udnaEFv5XhSPKPBkfKm2q985etei wWPncZimj4vP9Tw32e5pDnO01DOPlkJMIaYQUxRblgU2xRYoVRZKASaKLWReEZmHPnjdYsuoFydm uBl0O0MDl0iP4lpgYsoR4VJ2d16xB/gCX+CLOcOcQSnMGWDCnJF56IM3Yc7S95XW3NjuSm/r6z/1 4xll0MaxmezQNkU/GfLueMfq9LgpfQxVV3Zdx45lVzieK1UQ6l/jaynGDSN6YTAcqMXvItKbe3F5 UByK4/JeFFG4PChVFkoBJlwemVdE5qEPVqYPTD+k6tQNo7jm2VH6Xdu8wA05oWrOVtXJCzlROa21 NjbFMEr8Xef+ySJlswfFldetXdvqg8Z/ausYO7Ln+pPvfPNBun4Uh215N28onP1bq37ZOL/4LN5d x/Eg+petLen/ceveuIPE+dt/BGFvS/1t6yGB3on/CMS7x39Xv2/6iwxpuDmjI5IDO7RjWbYB8un5 Fa61ROOc7pWj4IwYwWrpxahot6WzPaRUhxRPB4oUL6EUVx/1hqFDqQ5KlYVSgIlSHZlXROahD1am D7IWZIwCe3Q2XT+IparzODKKRP1OOkO1FV8/7HodT3cpk+BTWuQXxnbLtMUd8wYD7g+6Q3fc34vi BvcHpcpCKcCE+yPzisg89MHK9IHpCzWcoB/Z6SO0DV+kkVi0OOjJ+Fomn+bG17nOitvXB35NDf8n 9+pKVJK2GyTWzu9lnUNfhkZawsd3kghnRSVnfTE/Pfk68xP+Ff8KpfCvgAn/SubNfh19UL63l7u6 l6ZvL71ALcFWj2aUhQl1XJgYIAWk1A9jYjAxUAoTA5hyggl9QOahD9AHy+qDv66DlDSY48r21DM8 vX0mvHJ29va3qx/0sF27O2c+HHLnDIh+HCiIBtFYOChlKqUAExaOzCsi89AHK9MHmY5nX/fSzC46 61p6+oHMehv1OLoFhqYccT5fSWWfezQ+8yoOhNoeOEzawQ/8qqvyznZi97sUTtBPHrQbCXWBsQhH jTU6NkVUHrfdpj7+aG1OzYo/htF1roiNPkNt/Xpd9ter3z+mb2hGuCHcEG4UdpalCoUdKFUWSgEm CjtkXhGZhz543cKObrBpYce6j7ygpx/NqJLOKK5ZZWHUaUap4OZ0tk7Jp+sW7MHAk9WbTvWsvbu9 e7S/X93Rm2jXbgXDzs6iFQxvfoz8/KFre+qesnG9LkmKXgK9+ZKb+Zr5mvkaP/8M2uDnoVRZKAWY 8PNkXhGZhz54XT+vm2Xq5xtJhKIV6tf34sSW/cCf3mKsH9gol58Rrdl2rtJonWzkcv46uXH+6+v8 ByotxPgm8/mSnPmc+Zz5HL//DMbg96FUWSgFmPD7ZF4RmYc+QB9k64O27d1gPAALYAEsLwoWjAeU KgulABPGg8wrIvPQByvTB6bv4Lx4Yk3mxfxwEypkgkyQCeeCc4FSOBfAhHMh89AHOJfXFRDyKvod 3/Lm490U8i6WflftYnM9KXy7L/WiNhnO11AAGAADYAzaM3iDQYNSZaEUYMKgkXlFZB76YGX6IHOz 0pHupelhw8EwVo1w7l8FYd+O3cAXLWP3sC2KdlaFGLaZ7fK8xcmiUBpK4+Jeli24OChVFkoBJlwc mVdE5qEPXtXFvdeBTY6cSLS939Pdhq2bjTZ5ortY/EP6MtRfMNzmpcIz/xWtHvm5YuZ6ECZpJmkm aUw8Jh5KYeIx8WQemYc+KNLE69Mgp579QsZ/2aEUtSBUB22aatYzw5zVHYa58otaa0O40ej2V3VD hC2+26Er43sRXycDPxLR0LkWdiRsx5FRpG6IHYRu3w7vxaS9RgtxRSijYBgm37QpVEzCuved6zDw 3b91eWNTyNj5A4/IHMAcgEd8UY7hEaFUWSgFmPCIZF4RmYc+QB9k6wP1q7ubP3+k9MEc57urx97E +eqH1vZGP69Rdvchtlnd9MjjgmAQDIJB8LIIxqJBqbJQCjBh0ci8IjIPfbAyfZBpZvZ0L02X3sp+ EEt1EaAju8NQCsf2DHyNlxnmAotTjoCX0FZqD2WrxvJLuAyX8W0vyxZ8G5QqC6UAE76NzCsi89AH K9MHpu+D82Xsy1tTjit9mYvHr7xu7dpWv2r8p7Zug47suf7kO9egGVw/isO22gR71/cmuB2Eo5eS 7z6Ks39r1S8b5xefxbvrOB5E/7K1Jf0/bt0bdyC7rv1HEPa21N+2Gm4UfwuuvrVrrW+23/329aT1 bRCE8Td/2O8kv/ud+A9PvHPcWH7zg1hW7cHAk9WbTvWsvbu9e7S/X93ZeSfUk00faW06Yc5YjOTA Du1Ylm04ZtaFXqYl4o//vrPznzOgWs/el9P7bsZzFVIRqYhUpJS0jBKklASlykIpwEQpicwrIvPQ B5SSnl9Kup19lf92S0n5Yt4Up8kH1fsy7EnfuRefwsDuOsmTpStqMBgGw2A82rK4waNBqbJQCjDh 0ci8IjIPfYA+yNYHX333rhoHVfV/UQsG99NzksTsAb+ZC9L39XicLEj/+rXW0k9v1PpzFdWsfjJp uTkLzZlZmFmYWV6WKjhPKFUWSgEmnCeZV0TmoQ9Wpg8y/ZhusKkfqwX9vgwdPTrN8mTOODKTfdnP H5VJB4rjwcBzHX3uboRfg8fwGL/2srTBr0GpslAKMOHXyLwiMg99sDJ9YPpqzhsv6Ll+Sj7MC9qY xZz5jiAepeLElH+WYUeGQSQqg/Gr1g39zEb580mQs2rSLH/+dMQz2zLbMtvixpdlC24cSpWFUoAJ N07mFZF56APc+HPdeHQt121rZT43rsc+blz91yw3Pj4n/OnAZ9Jl0mXSxZQvixhMOZQqC6UAE6ac zCsi89AHK9MHmX5t1IsTv3ZyVmt91x1nlkUbxWW2QXM8N8kirBnoBb1YsxeFC9YMSpWFUoAJa0bm FZF56IPXtWZHupewZm/fmukrekKsGegFvVizF4UL1gxKlYVSgAlrRuYVkXnog1e1ZgejvJtYM3V8 jBSnrqdaYnLCq35So5xaZphmG7fK8WlrQwSJecu1+vVgJzUu2qHtR303itzAF7Uk0jDwDB4f7V8c 5JvZYrvqiWzfuVYk/tWds2+nxVZ2x2q6UVEJqARUAlWEZWc6qghQqiyUAkxUEci8IjIPfYA+yNYH vrytprTBrfFbfMPb6yBXyObcnap6+WnUmbZ9Tz3JU9seXjk7e/vb1Q8aUGtn1j8cYtaZjB8HymTM ZIxZh1KmUgowYdbJvCIyD32wMn2Q6XjSd7FeStsT6kGFFYfS7pv95n9RtAsMTzniXkJp/fxRuWxb rfSVQHPGh04oXmTzIpu5j7kPb4w3hlJ4Y8D0QmBCH5B56IMS6APTX/uOjrm9Sh/ma/yr33yr20fJ +FAC0QcCn7qeFNZ9FMu+fmSzCh+n1qySNKi+Ie763mTaGIRS71J/93FT5Br7Bq30uIq+ZezQ/0XS o0hQJCgSKhbL0oeKBZQqC6UAExULMq+IzEMfULF4rn3pB76beO7fMS9vPuhNMS4/NDOCB72gF/Ri zZaFDNYMSpWFUoAJa0bmFZF56AP0QbY+yDJesAW2wBbYsixb8B5QqiyUAkx4DzKviMxDH6xMH2Su cNTNMl3heHHRbukHM2pNo4pqVlWYtWkz/3nNo6xNndc8CMJYNOx7GQpLOsPQje/NGwPthsnrWj9u 5en79PVauq+lsALnRiaB6QFgXr9bVsPs1K8oulnpDdtILiQXkouSzLJ0oSQDpcpCKcBESYbMKyLz 0AevWpL5MMq7iU1r2q4nomFncquS3Us6Rj+pUT5N9lWcya+PkgAfxbvQvGU2nz5s6umxVIe6Wdfu EKrD7UWHUJWjBZbzv6nw5owJfefWQ+XD7at73XRm6QrYlQwNPsvOappd/qT2gbZB21D7eFmqUPuA UmWhFGCi9kHmFZF56IPXrX3oW5amRk2dtNW0b0x8Lz0NzWRn9vPHwR/bomL7XeHZySjeEH/JjrCu 7VAN7cpZu90Sx17yBT/56qawvSgQkZRCr0g53MbYAW7AjbF7WShh7KBUWSgFmDB2ZF4RmYc+QB9k 6oPsI4K1Vbls1dbtpOD6IFfAhhyyld33omkP8p0X/mH2yjR9YFfSZI7sqrX2ju0Z+H45M8xZdb2m +21GE8V0RJypb4nlXbwO6w4WBGvy6NgUQTKx+2IYya7o3OcbJiMRMxkmJ8k4CN3OME4+oRb0B4Gf 6BbxpfP/pROLZtCVBo6WX8dsNlLUZOM6ye+3/W6+MZPeutl0nTCIkqEn6nfOte33pLD0Ef/mDZW5 oS4YIVu4Q9wh7hB3uCSoqR5DqbJQCjBRPSbzisg89AH6IFsfXErPtTuezGfh0qexWPeRF/T005q1 AUXHtcCcvfle//lDGdDEvov/+a//HlV+rpJPjvQlkSIJvpck7XzJyHzDfMN8w3zzDPLgR6FUWSgF mPCjZF4RmYc+QB9k64P214uLekMtzkiGt9xMyYQ5plQfE5lxgIY+WGP9DtDYMfwADVsNDr0qQ3nW XHWL0Vkq07rFp3q99ZbGRr6WUVGZ3fN5elon/bSnW1KG1TioDqSJ6wpUVJHZXR4HKsn7wvbzdX/6 4JzjwcBzHTtW51B5Zp4XbM+GCALSe3LbQ9+XntJ8k2nDvEEQ6xgX9PwW7gx3hjvDnS0JYKq3UKos lAJMVG/JvCIyD32APsjWB8fWqRhvr2vavt2TfbUpRp2nU0seOwy86Y4qUUm+t3rZrLU2xP+x+4N/ Feet5nnGD8/bggWv4BW8glf4GSiFnwFM+BkyD31QNn2Q+YImferIueoGXyql7/qxag5zj5iYH+us AjHs0pPzVit9OuqcoaFz6elaHvWWU1ZvOtWz9u727tH+fnVnPVf37Cxc3cO0x7THtIctXhbY2GIo VRZKASZsMZlXROahD9AH2frgsvH/xMknO5LzBQJ0gS7QBbo8gy64DyhVFkoBJtwHmVdE5qEPVqYP Mt+8jHpp8lKuofrvVupePHFD6ajXLOLYcWQUGfx+LlfYs7pkTa8KONSJ9LDPTp2Zry9CbKhtiMKS zjB043vzBkm7YZk8BLby9P3MQYCqr6WwAudGJoHpAWBev1tWw+zUrzROjltWrvf0c87c4D39qC15 T48SRglTKVsxsqmUQamyUAowUSkj84rIPPQB+iBbHzStk1a+m0CPRjCZXs6WDAPXSUJIPP0wdKQ4 cSNHVYbuDS7+5QgaTwezHwUKs2E2ng5KmUopwISnI/OKyDz0wcr0wSAMgqt6qD5x1C3RQHqeFduh fo3z5gWENRyo1/BWcBXPGL/syOt+14S4xV3fmxBkEEp1Pbl89zF5lLthNDlWqhb0++owqooT6NOo trzEwEo/Ge8bm0KfK393L3p2LG/te5F8jy8dvUk7HP34+KdEHNpKpM1XaOAdvIN37N/vUwz7B6VK QynAhP0j84rIPPQB9u+59u/4wo3vf8f5gSbQBJqwLsuSB+sCpcpCKcCEdSHzisg89MHK9EHmwr30 hacNuyM9tXAtDt3OUN8KafBu3fnBzmoQ4zbqtfQbqzAY6hdU0xuRh5HsCjffZalH6ctS9fLH6QeN 2ta6dWPnOvkN5g2eZsvsbbw/f/gyvg3Cmyc3BDOZM5lPImEyx+w/Cy+YfShVFkoBJsw+mVdE5qEP Xtfs76nfOzl25VJ6rt1xvfEhS1Mjd3Lv233XEWdBFKt7N6/c3jC0Da8FnJzVWuLUdj21Yc9sXzfx 6Kko5wwYfdXS03N6DrX1X7tTeQ53OZWHqe9xoEx9WGOsMZQylVKACWtM5hWReegD9EG2PriUPfXK +l6M/2CHU18uKpeXuS5KPdLjI8PY6QrB+hm7PYwd4H4cKOAG3Bg7KGUqpQATxo7MKyLz0Afog2x9 cF6v16vN5pNlpcAFuAAX4IL5gFKYD8CE+SDz0Adl0wecC5qOfB3PBe3asc1RoBAdouP4cHxQCkrh +F4cTOgDMg99gD5YVh80Zde1RdP27Z7sJ+NFWPdRLPui0mxaG+LJVx/WGDab+dYY6gGbscZQbypb vzWG+6wxBOqPAwXqQB3TB6VMpRRgwvSReUVkHvpgZfog0+noZpkeoNJ2fUdUJsdsbOhnTLudN/Gu MNMO5VMhqgVmHOKvrpAw64yVP1sXomvLfuDPF2JQHIpDcVzeMwCDy4NSZaEUYMLlkXlFZB764HVd 3qgXJy7v/FNTP5dRx2AmQc1qCrOM2WWzJirjZZuJO3OTvlMjWa3erI3WZG5Mb8PYHF2H0bnPdx3G 0ezwmLxQHZg3TiaRvTd7tPy62/e2R7Px424/Pv+nqATJt9p6yW+k2yqrDPTGB0ESp9ndf57MtL2k FxMI/OmG8dD23L9HByGP1kWEonL+ZzPHWoi9bX3NUsZaCD0Jr99aiPeL1kK8+ZGTzCb52JG+QUmx 48wOu7d2KB+vvEkmpigYyWCzALIgWLPBEgeTPSGir0PPOV706WwPl7W1ji/NGxRe0HMd2xMDO4xd BdtIVFSkacyaOCSkb3c8Kbrj8/enDSBC6Tw+hn+2ISgZUDKYRELJgFcKzyIQrxSgVFkoBZh4pUDm FZF56IOV6YNMQ6e3wjxcoWw74osl/iksdcqAHlqGXZqcDtBsR2d3+66vD2hXpm0zFeyc4aDz52mV 8Pz44ri6npVCswuFP38kjREpi7+z/ce+fguVTCmeO5Mac0aLRvzT0WIPBp6s3nSqZ+3d7d2j/f3q jq4+r93Y2dlhxx3C6HGgCCMKJxROoFQeSm3XDw5rb4xSgInCCZlXROahD163cJLecXcSJN1b6dl9 aeAyKxXcAh9TjviWEFCb4soNo1gEvhqo+RZCpJfinqqfryojmDjp6DoIVFIaNw50K81EuWBcMH8x fzF/4W+XxTP+lipcWSgFmPC3ZF4RmYc+eF1/m95MdjwYeK4z2npSe7wUWBw7joyi6eGc+unN2mSU N/QFVqgcjbCEBvv5o3JcO545dRWAA3AAjsFbFi4YPChVFkoBJgwemVdE5qEP0AfZ+uCyftxoVi+/ WieiktIIt8bfeajNp+078i87TG9Jnxe72bcejpbti2mzZN0PgkllEmISYhJ6WRJjUqFUWSgFmDCp ZF4RmYc+WJk+MN3K/Sk9XwZ4uJF5G79QbYe2H10lju7hcsc/j9u8ZwTRIBoL98IExsJBqbJQCjBh 4ci8IjIPfbAyfZC1kHRnlHfTE6ZcJwyi4CrWT2fW2VLWrLBYu7sIRuf8PO1sUb9zrm2/J409WGwS oNlD4DIYqhsl5gtoZl9mX2Zf3Pkz6II7h1JloRRgwp2TeUVkHvrgdd15+gKohusP76pnx/rhjPJn k8jM9mfXSf5V7e+269kd13Pje3GdECLuSDvGs8FkmIxne1Hi4NmgVFkoBZjwbGReEZmHPnhdz5a+ hPW8Xq/rBzPKr6mozPZqTdl17cf7F8dX2gffZZjvZWv67ia9lHYQhLFo2PcyFJZ0hmFiAc0bG5bV MHtoVNTorzabVjUJNc/t7juaoRm3u2ugr9/t7gfcu4O4eRwo4obiB8UPKGUqpQATxQ8yr4jMQx+8 bvFj1EsT0/tlELt992/ZFQ31fVZsx1KMV6mKwXhPqX5yoxzworAXOJ9yxL2cNf7SsC7ZHgyv4TV+ 7mXhgp+DUmWhFGDCz5F5RWQe+uB1/Zxulqmfq9/FMnmkjifViUDf3cgNfNUo5l4v86uIDbdz9VZr Y1PYU68urpKPdoJ+f+hPzojqyPhWSj/fO/ERFB6u5e3bri98uy9FKHvJwAkNfB/efRqlKyOzB47t d/MNiPQ9VhkDYjSBmTUipqEZPQpmD4PP6v9dPXGWr3cPDvb2Dg6eF/flaU28/7C3b3LfUuJDwiPh Syfh1Ue9YapQ4oNSZaEUYKLER+YVkXnoA/RBtj7Qqykebcl4OJW80WxtbKZkwxy/qU/Ay1iJr8fG +q3E/7BoJf6bHy8/fzyqXMbXdizCoR9NKpaqrGm7oQiucpWqdtNncVwEXSkqfvJRQXiTUGPjLQ2g fM3nJyGaX6cUbiSGkeyKOBB9zZZ8wyG9za8tPRmHtjIwQvq9ZJqQYTIqzBsUGUGaPUQq7fpGvhEx s+EvGRGpNyWRUD9g3ohQUS3ChJIfqH/UP+of9U91EEpRHQRMj8GEPiDz0Afog2X1wfnlefqKjzk2 TQ+BjBKgHq/rVwI8XFwCzGxCnboZTahXc61fEx4ZXkWtnCv6+jIWl+NVmuLcvwrC/mgFqLo0xnXk Rv6zkXbTy4o/1euttzRy8rWbisrwcfHJC5ybSDxaJD29SWjybibP+Ui7Gr1PeXKkZ9W148nRtuk8 yTMmSjqXLLsydO/ocM/k3mVlKN4Ob1eShFTpZ4S3o/YLpcpCKcBE7ZfMKyLz0Acr0wdZFmxvlHeT Ko113qiJymQ9nYHr3fSR3FJMi10N97sUtcC/kqH0Vf+b7NsSV646GPsGnsEz9u1l4YJ9g1JloRRg wr6ReUVkHvrgde2b3us2tW81N3L0CDLLtOmwzDZmbbsnTvSxUZ2hXnCRefjYnEGgd61lvFrXg2P9 Xq3v/P5qpz290yujCXXTrl8T7j6jCfXWqIwm1E27fk24Z/QCj//5r//uSDXfhnLgJeqnKzr3Ir6W otlqWLnWh+3puf7h3nu7I71sBL6l8ZOv9RYE+/t5p4VaRt7pfFy/vNvn4jnMzONAMTMlNDPqo97w 9EexE0qVhVKAiWInmVdE5qEPVqYPMp1OekdROxgkv7N3Lz6Fgd11kmcXHVsd8pO4qUuZmIZIVlt2 fC1Og/DWDrvarRp/L91LtMoCA1WO9lmq1Fppf7psnf5rviJFSTeMLr1D5eCQs8uZ1ZnVmdVx/bmp guuHUmWhFGDC9ZN5RWQe+uB1XX/6+rDPMuzIMIiM3qWSEaTJbu3nD7vbd319X5p6GZ6KNXtUjIb7 07fe9mDgyepNp3rW3t3ePdrfr+6s5yqonYWroJjxmPGY8XDEy5IbRwylykIpwIQjJvOKyDz0wcr0 QeL/gqt6qD5x1C3RQHqeFduhlvxvXkDcjJ3ujOXLDrvud40Iuup+38z1+nk/vb1rrWofs5LSrIKH Woihlv2f/zlfOjPvMu8y7+LLnwEYfDmUKgulABO+nMwrIvPQB+iDbH0wXgme/OLRyu8zaScpISqX l2d5LnPYn3fihB4y67fn+D3vWmH240BhNszG00GpPJTarh8c1t4YpQATno7MKyLz0Afog2x9kNvT ARyAA3AAzrLAwZBAqbJQCjBhSMi8IjIPfYA+yNYHsfQ8EUm/i/uALtAFurwoXXAfZlKKJW7jr+A+ yDwyD32APvjtIG5xH9AFukAX3MckBChlLKUAE+6DzCsi89AHK9MHph980e921uzQi64t+zNnO0Jb aAttcWPLsgU3BqXKQinAhBsj84rIPPTByvRB5iEAe7qXJofTXdTbtS8Xp/rZjDqQbhzYrLYw6zy6 4LsM8x1JqK+Vn/a6JZ1hKIV1nThV87ress4WdDuzE7MTsxPudVn64l6hVFkoBZhwr2ReEZmHPnhd 96obDPdalhBfyb2OcnPS65/q9ZZ5Xa6iWtDfTEtMS0xL2NZlsYtthVJloRRgwraSeUVkHvrgdW2r bhZsa1lCXMq2XgU5XesodafvXL8cG+haVVRmd3f+KsVRqr/P2u2WZV6H67AW9Dg6BB2CDqFOsSx4 qVNAqbJQCjBRpyDzisg89MGr1inej/KOOkVJQnyVOsX79HX11CneZnfnrlO819dAspoCFYIKQYVQ paBKAaWoUgAmqhRkHvqgVGk4x8DoLeyTe+wvpefaHddz43vdeRNfc3Lv233XEWdBFIta4F+5vWFo x27gi1YYxEHyoDoco2zPyVmtJU5t11NucIH/KUegS/ndwbgT50svuA234Ta+7hl4wddBqbJQCjDh 68i8IjIPfYA+yNYH/wiD4UCcJL/W9cWXK3GuhswglPHIYFb+cfLlfENgUbJ/HgSBIBC0JIKwKFCq LJQCTFgUMq+IzEMfrEwfZL56Sp+jOzYAF3ZfCus+imVfP6ZZr5QuFm33K0d4S8io31k4qbNl2vnt 0PajQRDGomHfy1DoQ5XHbyHNGgLthuFDoJKn9zWgy9exBwd7ewcHz4v88rQmPhy+PzS5dzdmg0Nd oa4mkaCuqL48iypUX6BUWSgFmKi+kHlFZB764HWrL7pZpgb83KpZ5/rJjHLbrgrLZEeW02/rlDXP b+992N02uXfx28ynzKf47ZelCn4bSpWFUoAJv03mFZF56AP0wRx98NdxsyWc5BHDwBO5/KU+rtk8 f7l/8P5gViXhLwXzR+aPM3+of2X+wF/iL6FUOSgFmPCXZF4RmYc+QB9k64P2b/vLA91r5vnL93vv P8yqJPylYP7I/HHmD/WvzB/4S/wllCoHpQAT/pLMKyLz0Acr0weZFix9s81ldO87+snSpmwQBsFV PVQPM+rRaCA9z4rtMB43Q2ZfvG4DfXr+guJQxZ0SHvNirvvd8Q8bdhWS60mhWuE6DHz379EhXZzO lf3z8Bye4/eWZA5+D0qVhVKACb9H5hWReeiD1/V76ZstT9stSz+YUdtDVVSzqsIstza5nkdUunZs b2zmOpzrQF8K9Ljvjex6s3s+91FsB+lz+DiKzZAhsJWn7/W0+HBfteprKazAuZFJYHoAmNfvltVY 0O+oUlQpqpSq1bL4pWoFpcpCKcBE1YrMKyLz0Acr0weZfmbUS1StTKlajXcJ5C1c6aygcPWmOz9/ 4WqEbApXhg2BXIUrfeIEhSsKVwjTJ19HmFK4onAFpShcAaYHMKEPyDz0QUkLVx9GeTfxMxcy9uVt pJ/NKAszDmyBjSlHiEtVMI67fddPui0cbY4Z3WYpKhfHVvpAhDlDQe+0sn3nWqHEcWP5zQ9iWd3Z 1suy3sp42PnwtLEm//ZdhnGKO9EwaYfICd2B3ib2uDn/PYn7PxeMF6Y1pjWmNWzvstjG9kKpslAK MGF7ybwiMg998Lq2N73LqC09X8b60cx6YavjWmBiyhHhUqZ3cgSEyP3+/kN6mxHv79fo/f2H9KYj 3t8jVFT3IVSmkSBUKGQ8izIUMqBUWSgFmChkkHlFZB764HULGbrBpn7mXHVDYvlFU0aR3ZPi2HGS P4nJxgb90EZ5m19FvMD4lCP2pYof+Wseo2ym5mHYEMhV80jvTqLmYUTqV86bx618C3v0TP90YY89 GHiyetOpnrV3t3eP9verO3oJ0Pqt9NlhoQ/693Gg6N8S6l/1UW8Y2dTHoFRZKAWYqI+ReUVkHvpg Zfog0/uk9+u3gigWeiKWBtfEsqJcYHDKEe9SZngv/+qfwxGJqYQZNgjyVMIO05dJUQkzIvkrrS+t vVyVsEO97JNKGJUwlC5Kl0pY2Sth6n8d78mg2T3Y+3RQzxof46+MnkE6cWvaUo++qj+vZ6mHTkb3 zu54TFwnf35/uD+OadBLRq4a9kEiFHb2R9+ik+Lhr6Mkevi7yrmHv11Lu6tG34dd/derINCDcfzX 3jAej81J26oGG+NDfY/+527g/CN0FSXUiG25sZM85d6B/urWJET9x07Qvdd/SH5k2E+S8OP/CgAA AP//AwBQSwMEFAAGAAgAAAAhAKpSJd8jBgAAixoAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzs WU2LGzcYvhf6H8TcHX/N+GOJN9hjO2mzm4TsJiVHeUaeUawZGUneXRMCJTkWCqVp6aGB3noobQMJ 9JL+mm1T2hTyF6rReGzJllnabGApWcNaH8/76tH7So80nstXThICjhDjmKYdp3qp4gCUBjTEadRx 7hwOSy0HcAHTEBKaoo4zR9y5svvhB5fhjohRgoC0T/kO7DixENOdcpkHshnyS3SKUtk3piyBQlZZ VA4ZPJZ+E1KuVSqNcgJx6oAUJtLtzfEYBwgcZi6d3cL5gMh/qeBZQ0DYQeYaGRYKG06q2Refc58w cARJx5HjhPT4EJ0IBxDIhezoOBX155R3L5eXRkRssdXshupvYbcwCCc1Zcei0dLQdT230V36VwAi NnGD5qAxaCz9KQAMAjnTnIuO9XrtXt9bYDVQXrT47jf79aqB1/zXN/BdL/sYeAXKi+4Gfjj0VzHU QHnRs8SkWfNdA69AebGxgW9Wun23aeAVKCY4nWygK16j7hezXULGlFyzwtueO2zWFvAVqqytrtw+ FdvWWgLvUzaUAJVcKHAKxHyKxjCQOB8SPGIY7OEolgtvClPKZXOlVhlW6vJ/9nFVSUUE7iCoWedN Ad9oyvgAHjA8FR3nY+nV0SBvXv745uVzcProxemjX04fPz599LPF6hpMI93q9fdf/P30U/DX8+9e P/nKjuc6/vefPvvt1y/tQKEDX3397I8Xz1598/mfPzyxwLsMjnT4IU4QBzfQMbhNEzkxywBoxP6d xWEMsW7RTSMOU5jZWNADERvoG3NIoAXXQ2YE7zIpEzbg1dl9g/BBzGYCW4DX48QA7lNKepRZ53Q9 G0uPwiyN7IOzmY67DeGRbWx/Lb+D2VSud2xz6cfIoHmLyJTDCKVIgKyPThCymN3D2IjrPg4Y5XQs wD0MehBbQ3KIR8ZqWhldw4nMy9xGUObbiM3+XdCjxOa+j45MpNwVkNhcImKE8SqcCZhYGcOE6Mg9 KGIbyYM5C4yAcyEzHSFCwSBEnNtsbrK5Qfe6lBd72vfJPDGRTOCJDbkHKdWRfTrxY5hMrZxxGuvY j/hELlEIblFhJUHNHZLVZR5gujXddzEy0n323r4jldW+QLKeGbNtCUTN/TgnY4iU8/Kanic4PVPc 12Tde7eyLoX01bdP7bp7IQW9y7B1R63L+Dbcunj7lIX44mt3H87SW0huFwv0vXS/l+7/vXRv28/n L9grjVaX+OKqrtwkW+/tY0zIgZgTtMeVunM5vXAoG1VFGS0fE6axLC6GM3ARg6oMGBWfYBEfxHAq h6mqESK+cB1xMKVcng+q2eo76yCzZJ+GeWu1WjyZSgMoVu3yfCna5Wkk8tZGc/UItnSvapF6VC4I ZLb/hoQ2mEmibiHRLBrPIKFmdi4s2hYWrcz9Vhbqa5EVuf8AzH7U8NyckVxvkKAwy1NuX2T33DO9 LZjmtGuW6bUzrueTaYOEttxMEtoyjGGI1pvPOdftVUoNelkoNmk0W+8i15mIrGkDSc0aOJZ7ru5J NwGcdpyxvBnKYjKV/nimm5BEaccJxCLQ/0VZpoyLPuRxDlNd+fwTLBADBCdyretpIOmKW7XWzOZ4 Qcm1KxcvcupLTzIaj1EgtrSsqrIvd2LtfUtwVqEzSfogDo/BiMzYbSgD5TWrWQBDzMUymiFm2uJe RXFNrhZb0fjFbLVFIZnGcHGi6GKew1V5SUebh2K6PiuzvpjMKMqS9Nan7tlGWYcmmlsOkOzUtOvH uzvkNVYr3TdY5dK9rnXtQuu2nRJvfyBo1FaDGdQyxhZqq1aT2jleCLThlktz2xlx3qfB+qrNDoji XqlqG68m6Oi+XPl9eV2dEcEVVXQinxH84kflXAlUa6EuJwLMGO44Dype1/Vrnl+qtLxBya27lVLL 69ZLXc+rVwdetdLv1R7KoIg4qXr52EP5PEPmizcvqn3j7UtSXLMvBTQpU3UPLitj9falWtv+9gVg GZkHjdqwXW/3GqV2vTssuf1eq9T2G71Sv+E3+8O+77Xaw4cOOFJgt1v33cagVWpUfb/kNioZ/Va7 1HRrta7b7LYGbvfhItZy5sV3EV7Fa/cfAAAA//8DAFBLAwQUAAYACAAAACEAWP3ZpJUKAABELAAA EQAAAHdvcmQvc2V0dGluZ3MueG1stFrpbhtHEv6/wL6DwN8rq+9DiBz0Mb2bIN4sQucBhuRQGpjk EMORFWWx7741PCxb+SbwbhDAgKn+uqqr6+qqnv7m21+2m6uPTX9ou93djL9hs6tmt+xW7e7+bvbz +3LtZleHod6t6k23a+5mz81h9u3bv/7lm6fbQzMMNO1wRSx2h9vt8m72MAz725ubw/Kh2daHN92+ 2RG47vptPdCf/f3Ntu4/PO6vl912Xw/tot20w/ONYMzMzmy6u9ljv7s9s7jetsu+O3TrYSS57dbr dtmc/7tQ9F+z7okkd8vHbbMbjive9M2GZOh2h4d2f7hw2/6/3Ah8uDD5+Hub+LjdXOY9cfYV233q +tUniq8RbyTY992yORzIQNvNRcB297Kw+g2jT2u/obXPWzyyInLOjr8+l1z/bwzEKwaHzdfs5AT9 0C76uj/5yXkb2+Xtd/e7rq8XG/JK2s4VSTR7S275a9dtr55u902/JNuQT0s2uxkB0ki3ng/10BB8 2DebzdHJl5umJoZPt/d9vSX3vIwcaVbNun7cDO/rxXzo9jTpY01yW3FmuXyo+3o5NP18Xy+JW+p2 Q99tLvNW3T+7IZGr92SJM8XR8V9+zU9BRBS7eks7+SIw3nWrZpTssW+/XtkjwXF10sdnS75eqKOg 79tV837U4Hx43jSFhJ+3vzZht/r+8TC0xPEYHn9Agt8ToNmNK/9INn//vG9KUw+PpKY/abGjJcqm 3b9r+77rv9utyDf+tMXa9brpaYGWfO0duU/bd09HPf+jqVeUa//gujefuxFl7tXh8uOnrhsuUxnL 1gR7doIRfUEYs1l4iHCujMKIKE5ARAgTE0QkZ9xNIFkFjGiWMaKEkgYiWqqEd6pVtOdofYVYYwPm 5o3jWDuBKYPXCSqLjBGbkoVIZM5jbtEahbklkSO2QlZaYMtlKxnWaGGqmkBMctBynBlp4TqcM411 zbmxWkJEkNxwP1zxJKF2uNLKQo1yw7LH3AwtBK3NrTIMWps7nipoBe70p2PlNWJUwTv13OVz3niN mOKxBIH5jNcJ3AW8ThCuFIzQwYW5RbId5haFldgPoggO7ydxP6HRJEyFuSXFCuaWtVZYtkrIBPMO L0ZhCQRnlYO+I7hyKU4gvqogIoUWUNdCSm2h1ELxiPOOUMpbuB+hKcNBvxZmzL8YkdFgqR05PIws QkoFY1s4Ky2MBeG5ydCmIoissa6jFhHrIJlKY6TilccSVKLS0K9FJUOaQJR0MPNJPnXKSHIEjmmE UAUjkqSGHiJJn9hyUrEgoe9IKxSDNiVbWwu9VybmcRaTWVYW77RIGeA6immhITfFjMcnk+K0V6gD QnwFpVZcuwB9R9FZMsFNMItPTSW0x2eWUtInzE1TvoR+TUiFzzmlrRV4P0Zw7FVUbmULM5+y0kxI 7VjEMac8lzhbqkASwJyogoq4dqHxqLEfJMESljqRI2Kk0jHAvKMqwwPeaWUczhSqCD0hQbEGn6d6 LKCg3jTFvYd602PBA62tBdc4v2lKyxqvI3nBmVzTQhXcqdbCT+xH6+Cg3rSx3kPtUIk2kfkI0Q5L YOlowlJbq3CPoZ0UEWvHqcJglGivWIKeqIOWOH50MHKCJjKdsE0jjwX6tY5CZpgPdKICCq+TWNFY o8kGHKe6Mj5hmsK8gnozzHrs8YbOHxxzRtkQoYcYym8KymYMTzjHG0O9DIwFY6mfg7o2lqig9xon o4RWMI4idQIxImPEa8+w1EFH3FEaqmEL9GsTqQfEGs3cyAmE2lBsOaqDJEYqTm6KEMtV4NByllMs QF1TfZ9wbUmFQ8SdhKWKIsOqkxrkhHsZa7nFnYS1suDuw1qdcI631mjcy1gn9YRsTuYKatR6KRm0 DyFJYtm8ptCCSFBpQm/BaI1pIqVRbIVoy8ROqa/HJ4bNguH6zWYrcE601Bld7ihfI1SKwWgkxBVM U6jjhjneFopGqGvHhGVQNkISto+jGMbdoeN0DMMIdlwYbDnHyXcwNyUn6hBKO5lhbtTRRmgF5w2P 0KYuCI1vMKi0dbjicslKfC/mMpW+mCZzLWBOJCQFrOssXAX9wFXUbeL9kLULPLc9ncICRqMXY/2E EVsypqHiBXcF3oxXFROI0zCTe8pi+HbSexZx5eC9nOIWeM4TCJ3CeD9UoThoHx+lwX2Wj8rgs9En KbHv+KRZgBHsM/O45vNZJYe1k3XG/Y/PlK+xTTP1gJAm0D8BLRcoU1RQo4HpXKBGA6dkgdcROmAd BGlENYXEAM+FoMY7Z4xohSuHoEyFa5egRcQdGLmOxKcmHTIMV/iEOFx5E1JwvROM0bj/CVYynA8C 1f4Zr+OVT5jGqwqfPyExMaGdTP0CpskyTMiWlcC3bKGywmMdFJmwTeN4ewu1E6llwvETBQ8G+ig1 EhLfNEby0QlukhpeuNMoubSYxlBfjRFLJRzMo9FRvQ5tGqNUuMcgxE+sk+RE5xqzSNjjY6YiGstW aYZvQZOkvhFmvkRHPb5LS8pM9CVpLF1gzCXLnIGemOgwCVAHVNpmfOOcAiVL6G+EVArqOgXLMpaa nBTXiSmKUkGbpmgFvqWm0tbju7SUVSjQpinbzKGuszQVviPOymosddZaZOgHmbpQ/K0tG6E8jKxs TMaWm/4Wmh2TBuo6OxlwHs1Oa44l8FxxLIG33OGdFgohrJ3CDa4GcxEFd0YV9YcJ+lvFKftD2Qix Hlq7EsLhfE1Iwnco5NQTvlMpRaXiBJLxPWylDZloCsF+UBlTJqSmZhPfeVdOafytuqK+Ed/uV0Ew 3IFVwTB8719FTurGiJA4sqqoDY6FKpGDYJpMBRT2EOoXCvaQSgsHpS5MFHyaFS4SvikpQngD8wEh oUBdF2rn8LfdIkXCfVaROkZon6LMxB1XUZbjb+KEOPwNrGjF8JlVjM3462WxcqKfK1ZzDU+M4uRE 9i9UV+GqswRqeKFXlcCDxrJFFvENRokm4/qgJFNJvJ88hhBGBHUzGLETXytKRWo4Sn1zgg5vv9ne jm/s/tVffo0Plq62J4pUbxd9W1+9G1/h3YwzFv2H2O4u+KJZd33zOTJ/XFzA6+sTcNjWm03p6+UF OKad7e2qPexzsz7+3ryr+/sXvucZPRxdNevvP/EaX6M1/d/77nF/Qp/6en96iHSZwpU6U7a74Yd2 exk/PC7mF6pd3T9/Bj3uVj9+7I96elHP0+3w0GyPD7p+qI8Pk45zm931z/PxKdGiXbV3s7q/np8t udz08/ENUvOu3u9PT5kW9/xutmnvHwY+kgz016ruPxz/WNyLMyaOmDhhxz/q5bhRmn3+8TImLmOf zZOXMfkypi5j6mVMX8b0y5i5jJlx7OF53/Sbdvfhbvbp5zi+7jab7qlZ/eMF/83QSQmHh3rf5NOD P/K27jRwfgF4uPp42/wykBJX7TC7Ouzb1bb+hUzGxNGzz7M39XP3OHwxd8TGyfsvOazqob685/qC +Ojxr2QZHyIuW/LO+fN28fK+8M1J8E17GObNvu7roesv2N+OGNfHN4rDe3LqD2TYn5p1rA/N6oyt uuV3q/Hl5Inm35aHwCsvri11t9cqVuI6GsmuI7XopRgqS3P6zzkoL89/3/4XAAD//wMAUEsDBBQA BgAIAAAAIQCvwL1E4QEAAIYMAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWzsl01u2zAQhfcFegeB +1gS9S/EDuAGKQoURZGmB6Ao2iJKcgSStuqcvpRkO3bSRbyIV1pxOOR8mnlPC+n27q8U3pZpw0HN UTgLkMcUhZqr9Rz9fnq4yZFnLFE1EaDYHO2YQXeLz59uu7Jj1S9mrbtpPEdRppR0jhpr29L3DW2Y JGYGLVPucAVaEuu2eu1Lov9s2hsKsiWWV1xwu/NxEKRoj9HvocBqxSm7B7qRTNmh3tdMOCIo0/DW HGjde2gd6LrVQJkxbh4pRp4kXB0xYfwGJDnVYGBlZ26YfUcDypWHwRBJ8QJILgPgI0DS8ttagSaV cBa4TjwHQwvnQc23Zr96XcnrOUoSnEV5HKfDeQX17n442xLh/EV+n3UOfGcre8gGx+wjXzf/ST9B +za5BGtBvsq7Ppa17iP7UqPcm4Pcxjz39/qgJZTtYwoCnOFkY2FEiJPOLquszjq6rFafTn5JqX86 dG/Hl4aL+twTHOIC50EQjaZM8n+I/GN4rnyWJnkSFXExCX9d4UOcZzgLgiSalL+y8kmYxziJcTYp f2XlszAqwhQX+aT8dZV3HzxZGiV5MAn/8cKP6+E751W2fxi0lkv+zB5ALzV0humhByIEdD9/fB2p J38Pi38AAAD//wMAUEsDBBQABgAIAAAAIQDlurlCCgwAAPd0AAAPAAAAd29yZC9zdHlsZXMueG1s zJ1bc9u6EcffO9PvwNFT++BY8jXJHOeM48S1p7n4RE7zDJGQhZokVF7iuJ++AEhKoJaguOAeT59s idwfQOz+F1hexN9+/5XEwU+e5UKmF5PZq+kk4GkoI5E+XEy+318fvJ4EecHSiMUy5ReTZ55Pfn/3 17/89vQ2L55jngcKkOZvk/BisiqK9dvDwzxc8YTlr+Sap2rjUmYJK9TH7OEwYdljuT4IZbJmhViI WBTPh0fT6dmkxmRDKHK5FCH/IMMy4Wlh7A8zHiuiTPOVWOcN7WkI7Ulm0TqTIc9zddBJXPESJtIN ZnYCQIkIM5nLZfFKHUzdI4NS5rOp+S+Jt4BTHOBoA0jCt7cPqczYIlajr3oSKNjknRr+SIYf+JKV cZHrj9ldVn+sP5k/1zIt8uDpLctDIe5VywqSCMW7uUxzMVFbOMuLy1ywzo0r/U/nljAvrK/fi0hM DnWL+X/Vxp8svpgcHTXfXOketL6LWfrQfMfTg+9zuyfWVwvFvZiw7GB+qQ0P6wOr/lqHu979ZBpe s1CYdtiy4CqyZmdTDY2FDuSj0zfNh2+lHltWFrJuxACqvxvsIRhxFXAq/OaVCtRWvvwkw0cezQu1 4WJi2lJffr+9y4TMVKRfTN6YNtWXc56IGxFFPLV2TFci4j9WPP2e82j7/R/XJlrrL0JZpur/4/OZ iYI4jz7+Cvlax77amjLtky/aINZ7l2LbuDH/TwOb1Z7osl9xphNAMNtFmO6jEEfaIreOtptZ7hy7 2QvV0PFLNXTyUg2dvlRDZy/V0PlLNfT6pRoymD+zIZFG/FclRNgMoO7jONSI5jjEhuY4tITmOKSC 5jiUgOY4Ah3NccQxmuMIUwSnkKErCq1gP3ZEez93/xzhx90/Jfhx988Aftz9Cd+Puz+/+3H3p3M/ 7v7s7cfdn6zx3GqpFdwqmaXFaJUtpSxSWfCg4L/G01iqWKYqouHpSY9nJAdJgKkyWz0Rj6aFzHze HyFGpP7zeaELuUAug6V4KDNVTI/tOE9/8liVtQGLIsUjBGa8KDPHiPjEdMaXPONpyCkDmw6qK8Eg LZMFQWyu2QMZi6cR8fA1RJKksAloVT+vtEgEQVAnLMzk+K5JRpYfPol8/FhpSPC+jGNOxPpCE2KG Nb42MJjxpYHBjK8MDGZ8YWD5jGqIahrRSNU0ogGraUTjVsUn1bjVNKJxq2lE41bTxo/bvShik+Lt Vcds+Lm7q1jq89ij+zEXDylTC4Dx0019zjS4Yxl7yNh6Feiz0t1Y+5ix7byX0XNwTzGnbUhU63oT IlfqqEVajh/QFo1KXBsekbw2PCKBbXjjJfZZLZP1Au2Gpp6Zl4uiU7SGNEi0cxaX1YJ2vNpYMT7C tgK4FllOJoNuLEEEf9HLWe1Oisy37eX4jm1Z42W1m5VIu1cjCXoZy/CRJg3fPK95psqyx9GkaxnH 8olHdMR5kckq1mzJHxmXDJL8x2S9YrkwtVILMXyqb66AB5/ZevQB3cVMpDR++3iQMBEHdCuIm/vP n4J7udZlph4YGuB7WRQyIWPWZwL/9oMv/k7TwUtVBKfPREd7SXR6yMCuBMEkU5FkRERSy0yRCpI5 1PD+yZ8XkmURDe0u49VNJwUnIs5Zsq4WHQTaUnnxSeUfgtWQ4f2LZUKfF6IS1T0JzDptmJeLf/Nw fKr7IgOSM0Nfy8KcfzRLXWNNhxu/TGjhxi8RjDfV9KDjl+BgW7jxB9vCUR3sVczyXDgvoXrzqA63 4VEf7/jir+bJWGbLMqYbwAZINoINkGwIZVwmaU55xIZHeMCGR328hCFjeASn5AzvH5mIyJxhYFSe MDAqNxgYlQ8MjNQB4+/QsWDjb9OxYOPv1algREsAC0YVZ6TTP9FVHgtGFWcGRhVnBkYVZwZGFWfH HwK+XKpFMN0UYyGpYs5C0k00acGTtcxY9kyE/BjzB0ZwgrSi3WVyqZ9GkGl1EzcBUp+jjgkX2xWO ysk/+IKsa5pF2S+CM6IsjqUkOre2nXCMZfvetX1m5kmO0V24i1nIVzKOeOY4Jretqpfn1WMZu903 3Rh02vOTeFgVwXy1OdtvY86mey2bgr1ltr/BrjE/a55n6TL7zCNRJk1H4cMUZ8fDjU1Et4xP9htv VxIty9OBlrDNs/2W21Vyy/J8oCVs8/VAS6PTlmWfHj6w7LEzEM774mdT4zmC77wvijbGnc32BdLG sisEz/uiqCWV4DIM9dUC6J1hmnHbDxOP2x6jIjcFIyc3ZbCu3Ig+gX3jP4We2TFJ07S3uXsC5H2z iB6UOf8oZXXevnXBafhDXbdq4ZTmPOjkHA+/cNXKMu5xHJxu3IjBeceNGJyA3IhBmchpjkpJbsrg 3ORGDE5SbgQ6W8EZAZetoD0uW0F7n2wFKT7ZasQqwI0YvBxwI9BChQi0UEesFNwIlFCBuZdQIQUt VIhACxUi0EKFCzCcUKE9TqjQ3keokOIjVEhBCxUi0EKFCLRQIQItVIhAC9Vzbe809xIqpKCFChFo oUIEWqhmvThCqNAeJ1Ro7yNUSPERKqSghQoRaKFCBFqoEIEWKkSghQoRKKECcy+hQgpaqBCBFipE oIVaPWroL1RojxMqtPcRKqT4CBVS0EKFCLRQIQItVIhACxUi0EKFCJRQgbmXUCEFLVSIQAsVItBC NRcLRwgV2uOECu19hAopPkKFFLRQIQItVIhACxUi0EKFCLRQIQIlVGDuJVRIQQsVItBChYi++Kwv Ubpus5/hz3o679gffumq7tQ3+1FuG3U8HNX0ys0a/izCeykfg84HD49NvTEMIhaxkOYUteOyus01 t0SgLnx+vep/wsemj/zRpfpZCHPNFMBPhlqCcyonfSFvW4Ii76Qv0m1LsOo86cu+tiWYBk/6kq7R ZXNTipqOgHFfmrGMZw7zvmxtmcMh7svRliEc4b7MbBnCAe7Lx5bhaaCT86716cBxOtvcXwoIfeFo Ec7dhL6whL5q0jEUxlCnuQlDvecmDHWjm4DypxODd6wbhfawG+XnaigzrKv9heomYF0NCV6uBhh/ V0OUt6shys/VMDFiXQ0JWFf7J2c3wcvVAOPvaojydjVE+bkaTmVYV0MC1tWQgHX1yAnZifF3NUR5 uxqi/FwNF3dYV0MC1tWQgHU1JHi5GmD8XQ1R3q6GKD9XgyoZ7WpIwLoaErCuhgQvVwOMv6shytvV ENXnanMWpeVqlIctc9wizDLETciWIS45W4Ye1ZJl7VktWQTPagn6qvE5rlqyneYmDPWemzDUjW4C yp9ODN6xbhTaw26Un6tx1VKXq/2F6iZgXY2rlpyuxlVLva7GVUu9rsZVS25X46qlLlfjqqUuV/sn ZzfBy9W4aqnX1bhqqdfVuGrJ7WpctdTlaly11OVqXLXU5eqRE7IT4+9qXLXU62pcteR2Na5a6nI1 rlrqcjWuWupyNa5acroaVy31uhpXLfW6GlctuV2Nq5a6XI2rlrpcjauWulyNq5acrsZVS72uxlVL va52VEuHT60XMGm2eSGZ2rl4XnP9G9zWAzNR9Ruk9UVAs+NttHlRkjbWPQnqV1LVX5sO1xcMqxaN IWwqXKm2wvrXkxxN1b+CunmMx/wG6m7Djp9KNR3ZDkGzdz2k20uh1X6ty569/S70kPf02bikd4wq r7k6+KYOw309VP1ZxNVLu9Q/t2mkAE/1C6uqnka/WIVS2694HH9m1d5y7d415sui2jqbmofmd7Yv qt9/c9pnJlE4AYftzlQf6xeHOca7+kX4+gq2MyS1GjqG29xOMXakB8bwpjfbH0zc7dB2SzWYTDXw VUvaDuR2tI+OkiwXOjSM1XT64fzs8ry+SF2/7y7UuWO7x3R6fV232nypfxu5CljrZXKoIYG/Jbk7 NHCP/9cheq2G6HWd5McPUVjmSlAmH+9GNVuvY34QyvQnzwoeHeh383EwcN174QbPNQDuY2hNFDtT ww++cGW+6oceuzpnTx9/ji/BGw4X+tcF9ahPTSarPl6Whax3qf3RvAix2st8gjvV70c82bwssfv9 iI6XTKpZQyQ8D77wp+CbTJh50nX7aseOjeYlk51bwhx+XY3d9i2T9f0trbdMmu9g8Db/5e/+BwAA //8DAFBLAwQUAAYACAAAACEA1IatX2gBAADhAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASig AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJJRT4MwFIXfTfwPpO+shRm3EGCJmj25xMQZ jW+1vdvqoG3abox/b4HBJO7Jt3t7vnu4nDZdnMoiOIKxQskMRROCApBMcSG3GXpbL8M5CqyjktNC SchQDRYt8tublOmEKQMvRmkwToANvJO0CdMZ2jmnE4wt20FJ7cQT0osbZUrqfGu2WFO2p1vAMSH3 uARHOXUUN4ahHhzR2ZKzwVIfTNEacIahgBKksziaRPjCOjClvTrQKr/IUrhaw1W0Fwf6ZMUAVlU1 qaYt6veP8Mfq+bX91VDIJisGKE85S5xwBeQpvpS+soevb2CuOx4aXzMD1CmTa3Woaav2J03We6gr Zbj1c6POYxwsM0I7f4Od6+jA0wW1buWvdCOAP9T9B/4KDWvgKJq3kMctMbTpOdhuKeCBDyTp4uuV 9+nj03qJ8phEs5DEYUTWZJ7czRJCPpu9RvMXw/K8wL8de4MumvGjzH8AAAD//wMAUEsDBBQABgAI AAAAIQAtPESTNQQAAFBQAAASAAAAd29yZC9udW1iZXJpbmcueG1s7Jzdjto4FIDvK+07oNzP5B8y qExFAqymWlUrdVZ7HYKBqLEdOQE6e9mX6SP0sfoK69iJSWaYKMBcZKRzFeLjc2x/hoRPInz89B0n gz1iWUzJRDNvDW2ASERXMdlMtH8eFzeeNsjykKzChBI00Z5Qpn26/+PDx8OY7PASMd5xwGuQbHxI o4m2zfN0rOtZtEU4zG5xHDGa0XV+G1Gs0/U6jpB+oGylW4ZpiFcpoxHKMl4nCMk+zLSyHH5ZjaaI 8OCaMhzm/JRtdByyb7v0hldPwzxexkmcP/HaxrAqQyfajpFxWeJGTahIGcsJlYcqg3UZV6bMaLTD iORiRJ2hhM+Bkmwbp8dlXFqNB7dVkX3bIvY4qfodUtO5bg9mLDzww7Fgl+mvZBJO5MzbK5pGhx0p SqiMLlNojlnNBIcxOQ58EZoaXNM9r4D1vEC6uW5z/mR0lx6rxddVeyDfVK3io31GrXKT60vLrpvM 122Y8k8gjsYPG0JZuEz4jPiWDTj1QfG21u75JSdcZjkLo/zLDg8aZw+riWaILiSLVzy2DxPeYruB 6XuGphcRvEvy+C+0R8njU4qqPqI1KVplrxynSRXzPN+wHWcoI8m+CMT8UI3FL4wsrzqbshe/Ki6w alzukgTlKv8RfVeh3z9+qfbPUdWaoHXZPf2bifnwVZbHqg8fQuOvU8qZjyyxOv3YMSbF+os6MspP tiHZiAu6Pax6l9VZeVhQkmcF0iyK+dvq6xNe0kSkTjnQRkNMeOEVWoccnJxp9l81MzUZUVcXa3uO ziyq5Pwyx6+Ve1ScX42SvgFI03HaSIrwJSgDumMxYoMv6FDj+bz1WqjW20P9/ePnG2C1TMXpFFYR vgTrv7x38SUlq0Fttl2L1O4tUk9e0V5DWoT7idTpK1KOqA2pCPcTqdtXpI7demcS4X4iHfYVqWu0 3qJEuJ9IR71FOmq9PYlwP5F6fUU6dFpvTyLcF6R6QyKKjFbDkIzrhmEvrDvX9S82DNOxprPyPdjc XzAMMAwwjA5YwTDAMBRSMAwwDDAMMAwwDDCM92gYlmBcNwzHGPmj+dyVw51vGMHCCDzbDxR3tb9g GGAYYBgdsIJhgGEopGAYYBhgGGAYYBhgGO/RMGzBuGEYpj+17epXTucbxtQxAsN0HcVd7S8YBhgG GEYHrGAYYBgKKRgGGAYYBhgGGAYYxns0DPmoRt0whncjw5qOStLnG4ZvzoLZ0PMUd7W/YBhgGGAY HbCCYYBhKKRgGGAYYBhgGGAYYBjv0TBcwbhhGP5iZnnzuRzufMOYB77h3wVlfn1/wTDAMMAwOmAF wwDDUEjBMMAwwDDAMMAwwDB6ahhEmAWpP9nd0IwGW130fJEmH9c4mWa1pMnfYJ1Mc1rSXvwH1jGt WvOpNGlLJ9PEUyWvpA1fT7PrafIo/wnw/n8AAAD//wMAUEsDBBQABgAIAAAAIQBUPq0kNwIAABUJ AAASAAAAd29yZC9mb250VGFibGUueG1s1JRdb9owFIbvJ+0/RL4vcUz4VKGirEiTpl10nXZtjEOs +SOyDSn/fsdJoGXARjSt02IhnHPsN8eP3uPbu2cloy23Thg9QUkHo4hrZlZCryfo69PiZogi56le UWk0n6Add+hu+v7dbTnOjPYugv3ajRWboNz7YhzHjuVcUdcxBdeQzIxV1MOrXceK2u+b4oYZVVAv lkIKv4sJxn3UyNhrVEyWCcY/GLZRXPtqf2y5BEWjXS4Kt1crr1ErjV0V1jDuHJxZyVpPUaEPMkl6 IqQEs8aZzHfgME1FlRRsT3A1U/JFoNdOgBwEFBt/XGtj6VICfKgkAjE0behH5VhTBYkvO7U0sooX VBvHE0htqZwg3IOR4FDVAPfhv4cHKA4LWU6t40GjXkjqcEaVkLt91BpFdZ0ohGf5Pr6lVoSa6pQT a0hs3BKDTvOgOpKAqY4j5GRN9zjCKp3hcSR5tQa+GdcATkA8CcVd9JmX0WNV+TkiBEYfd4FECj8C s/Q8kepLf07kAWoms8XihcgcIoNhmpwQGf2KSPWa1DrXE5mbjRXcBiYXaAyAwKiiEmikrWgos+L2 HI5MPPNVCxbdt2DxDTo83GzuQqecPC06hW68+Y8aZU6lWFpxwRKLygphpGAO0soSrhTOtWuQcHDy 2hQpBGbzQ6SVKUYtTTGDss5fnQTfw0WRNiQqGn+XQ8Dwz5qjcUT0Saxzf9EXwQ1v5YtZKJk8/OQL uLDu23VIzeO3vmgmbvoDAAD//wMAUEsDBBQABgAIAAAAIQDG2IEn4gEAAOADAAAQAAgBZG9jUHJv cHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTwW7bMAy9D9g/ GLo3spMmKwJFxZBi6GFbA8Rtz5pMJ8JkSZBUo9nXj7IXT9l6qk+Pj/TTE0mx29dOFz34oKzZkGpW kgKMtI0yhw15rL9c3ZAiRGEaoa2BDTlBILf84we289aBjwpCgRImbMgxRremNMgjdCLMMG0w01rf iYihP1DbtkrCnZUvHZhI52W5ovAawTTQXLlJkIyK6z6+V7SxMvkLT/XJoR5nNXROiwj8e/pTMzoR rLZR6Fp1wEukp4DtxAECv2F0BOzZ+ibwT6vFitERs+1ReCEjdo9fL5aLitGMYZ+d00qKiJ3l35T0 Ntg2Fg+D3SIpMJqXMLzCHuSLV/GUrOQh+6oMelis5oyOEO15cfDCHQOvynlyOcVsL4WGLTaAt0IH YPQvwe5BpOHuhEoe+7juQUbri6B+4XjnpPghAqS2bUgvvBImkrFsDAasXYie1ypq1J7iAeZlOVbX vBoKEFwWDsHgAfGlu+GE8NDi3eIbZqvc7OBhtJrZyZ2dz/hHdWs7Jwz2mE4IW/wzPLra3qUN+dPD SzKb/bOKx70TEqeyrMrVMt+CLMf2yEKDY52mMhHsHu/gdToB/zUHaM41/yfSXj2ND5ZXy1mJ37BI Zw5XYXpJ/DcAAAD//wMAUEsBAi0AFAAGAAgAAAAhADKRb1dmAQAApQUAABMAAAAAAAAAAAAAAAAA AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat+8AAABOAgAACwAAAAAA AAAAAAAAAACfAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAtSM0iGMQAAAFKAEAHAAAAAAA AAAAAAAAAAC/BgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQBj 5JR7yFoAAA02DQARAAAAAAAAAAAAAAAAAGQYAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAI AAAAIQCqUiXfIwYAAIsaAAAVAAAAAAAAAAAAAAAAAFtzAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQ SwECLQAUAAYACAAAACEAWP3ZpJUKAABELAAAEQAAAAAAAAAAAAAAAACxeQAAd29yZC9zZXR0aW5n cy54bWxQSwECLQAUAAYACAAAACEAr8C9ROEBAACGDAAAFAAAAAAAAAAAAAAAAAB1hAAAd29yZC93 ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA5bq5QgoMAAD3dAAADwAAAAAAAAAAAAAAAACI hgAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhANSGrV9oAQAA4QIAABEAAAAAAAAAAAAA AAAAv5IAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAC08RJM1BAAAUFAAABIAAAAA AAAAAAAAAAAAXpUAAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQBUPq0kNwIAABUJ AAASAAAAAAAAAAAAAAAAAMOZAAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAxtiB J+IBAADgAwAAEAAAAAAAAAAAAAAAAAAqnAAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMAAED AABCnwAAAAA= --f403045f39e47c031f0548292c08-- From nobody Mon Feb 13 12:00:08 2017 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 223F11294E3 for ; Sat, 11 Feb 2017 06:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 aTOixdXAifYm for ; Sat, 11 Feb 2017 06:15:50 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 3B878129406 for ; Sat, 11 Feb 2017 06:15:50 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id 11so63670487qkl.3 for ; Sat, 11 Feb 2017 06:15:50 -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; bh=heOyBQB+/kt63goj3lZukRY19lot9NMce2Fjko0YDT8=; b=Yzv6Tt2qSS+fn9agkeJ/B1qvPV7bG8MH+Um/6N6u8tork74Xm9iOC5GJ93vXSG8qhC 2+1UEP96frboCdDdhLs2EIyFi919CmCOQF91N+mTCw21JHQJxbUsgGWRAZw9Lt2hH7k+ dx+tqMPKFOuRQep+jbNGkacuK39BPqnCACkAuKrDukYAAMJafY7WyiarwseQOekYr/H8 mbArJ6LKVgQyD5u73p34yDSxFiGIKUjUAqgf73lu0Mu1uqSwMSrV7F7Qoiw52/58lWjM 7QQR8Ba7gb5Q6W6scGiXXiDTA7hainkd+WZYX1erIywqNF/FTgAF0X4Ef/4QWwBRnKbc 0VlA== 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; bh=heOyBQB+/kt63goj3lZukRY19lot9NMce2Fjko0YDT8=; b=mLVwIqWSBbDFtCTHIJ7PlmK0tKuRhGND0lYiDsErrJChzQdFJq7UQBidTMBKWtAWyz WAVSj6iWV24PURlyDwE8xrK35zAxwo4Qoo4nVmf0TLncwFjZHdNToRFpScieoA2PDbtZ //aIJIy96tHBFgQZkWkADAxJL9onAHxzrCYzgUtnWTabIcHxMm41NuDAo4aw6q60vhK0 CvejRMTGW6oAnPrY8kJomMdZN7BsGbeP8XzoV/nvey4mm9Isv5qa6VWkzgCmjcJi2yh5 wsoToVBO6x+zwLvLmUaaxh7xNUqa1mXzgvDQ45xf0s7OlEVPq/N3qKk8lMZHRhiTE9Gm 6YZA== X-Gm-Message-State: AMke39lXr4h3jOecAy9s5S+9+2dEvkyT/Y4mpXftvezWcTZEQxt53n0OHegH5ZyvrhFvP/2g+bbY8rEHDHbZIA== X-Received: by 10.55.144.4 with SMTP id s4mr12983449qkd.101.1486822549185; Sat, 11 Feb 2017 06:15:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.11 with HTTP; Sat, 11 Feb 2017 06:15:48 -0800 (PST) From: =?UTF-8?B?2b7ZiNuM2Kcg2K7Ys9ix2YjbjNin2YYg2K/Zh9qp2LHYr9uMIFBvdXlhIEtob3NyYXZpYW4gRA==?= =?UTF-8?B?ZWhrb3JkaQ==?= Date: Sat, 11 Feb 2017 17:45:48 +0330 Message-ID: To: khosravyan Content-Type: multipart/alternative; boundary=94eb2c057a70e36bf1054841d91a Archived-At: X-Mailman-Approved-At: Mon, 13 Feb 2017 11:59:56 -0800 Subject: [sfc] List of Service Function Types X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 14:15:53 -0000 --94eb2c057a70e36bf1054841d91a Content-Type: text/plain; charset=UTF-8 Hello! I prepared a list of Service Function. Please check which of them are SF or Not. *No* *Service Function* *Y/N* 1 (IDS) Intrusion Detection System / (IPS) Intrusion prevention systems 2 WAN Optimizer 3 Application Delivery Controller (ADC) 4 Firewall 5 Wireless Access Point (WAP) Gateway 6 Packet Data Network (PDN) Gateway 7 Transparent Caching 8 Overlay Transport Virtualization (OTV) 9 TCP Optimizer 10 (DPI) Deep Packet Inspection 11 Content Delivery Network (CDN) 12 IP Reputation 13 Lawful Intercept (LI) 14 (SBC) Session Border Controller 15 Parental Control 16 Virtual Router CE/CPE 17 Virtual Router Reflector 18 Virtual Private LAN Service (VPLS) 19 Network Analysis Module (NAM) 20 Virtual PE/IP Router 21 Wide Area Application Service (WAAS) 22 (AppNav) Deployment of Application Navigator and (AVC) Application Visibility and Control 23 CML(Cisco Modeling lab) and VIRL(Virtual Internet and Routing lab) 24 Dynamic Host Configuration Protocol (DHCP) 25 (IP SLA) Internet protocol service level agreement 26 (VXLAN) Virtual eXtensible Local Area Network 27 Wireless LAN Control 28 Domain Name System (DNS) 29 Virtual eXtensible Local Area Network (VXLAN) 30 (SSL VPN) Secure Sockets Layer virtual private network 31 Virtual Cisco Firepower Next-Generation IPS (vNGIPS) 32 Network address translation (NAT) 33 IPSec VPNs (Flex, Easy, GET) 34 Deep Packet Inspection (DPI) 35 Web Security 36 E-Mail Security 37 Identity Services Engine 38 dynamic multipoint virtual private network (DMVPN) 39 (SSL VPN) Secure Sockets Layer virtual private network 40 Cisco Packet Data Network Gateway (PGW) 41 Proxy 42 Data Loss Prevention (DLP) 43 Open VPN 44 Load Balancer 45 High Availability 46 Virtual Private Network (VPN) 47 NETCONF 48 Network Prefix Translation IPv6-to-IPv6 (NPT) 49 Serving Gateway (SGW) 50 Gateway GPRS Support Node (GGSN) 51 Internet Protocol Security- Gateway (IPsec-GW) 52 video optimizer 53 (BNG) Broadband Network Gateway 54 Content Delivery Optimization 55 Performance-enhancing proxies (PEPs) 56 Web Proxy 57 Distributed Denial of Service (DDOS) 58 Voice Over IP Thank You. Best Regards. PHD Student of Islamic Azad University Yazd Branch Faculty Member of Islamic Azad University Shahrekord Branch Home Page: http://iaushk.ac.ir/part/pages.aspx?id=74&pid=1 Google Citation : http://scholar.google.com/citations?user=ZXfOfdQAAAAJ&hl=en Work Phone: 03833361000 - 403 Cell Phone:09132800436 --94eb2c057a70e36bf1054841d91a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello!

I prepared a list of Service Function. Please che= ck which of them are SF or Not.

No

Service Function

Y/N<= /b>

1

(IDS) Intrusion Detection System / (IPS) Intrusion prevention systems

=C2=A0

2

WAN Optimizer

=C2=A0

3

Application Delivery Controller (ADC)

=C2=A0

4

Firewall

=C2=A0

5

Wireless Access Point (WAP) Gateway

=C2=A0

6

Packet Data Network (PDN) Gateway

=C2=A0

7

Transparent Caching<= /span>

=C2=A0

8

Overlay Transport Virtualization (OTV)

=C2=A0

9

TCP Optimizer=

=C2=A0

10

(DPI) Deep Packet Inspection

=C2=A0

11

Content Delivery Network (CDN)

=C2=A0

12

IP Reputation=

=C2=A0

13

Lawful Intercept (LI)

=C2=A0

14

(SBC) Session Border Controller

=C2=A0

15

Parental Control

=C2=A0

16

Virtual Router CE/CPE

=C2=A0

17

Virtual Router Reflector

=C2=A0

18

Virtual Private LAN Service (VPLS)

=C2=A0

19

Network Analysis Module (NAM)

=C2=A0

20

Virtual PE/IP Router=

=C2=A0

21

Wide Area Application Service (WAAS)

=C2=A0

22

(AppNav) Deployment of Application Navigator and (AVC) Application Visibility and Control<= /span>

=C2=A0

23

CML(Cisco Modeling lab) and VIRL(Virtual Internet and Routing lab)

=C2=A0

24

Dynamic Host Configuration Protocol (DHCP)

=C2=A0

25

(IP SLA) =C2=A0Internet protocol = service level agreement

=C2=A0

26

(VXLAN) Virtual eXtensible Local Area Network

=C2=A0

27

Wireless LAN Control=

=C2=A0

28

Domain Name System (DNS)

=C2=A0

29

Virtual eXtensible Local Area Network (VXLAN)

=C2=A0

30

(SSL VPN) =C2=A0Secure Sockets Layer virtual private network

=C2=A0

31

Virtual Cisco Firepower Next-Generation IPS (vNGIPS)

=C2=A0

32

Network address translation (NAT)

=C2=A0

33

IPSec VPNs (Flex, Easy, GET)

=C2=A0

34

Deep Packet Inspection (DPI)

=C2=A0

35

Web Security<= /p>

=C2=A0

36

E-Mail Security

=C2=A0

37

Identity Services Engine

=C2=A0

38

dynamic multipoint virtual private network (DMVPN)

=C2=A0

39

(SSL VPN)=C2=A0 Secure Sockets Layer virtual private network

=C2=A0

40

Cisco Packet Data Network Gateway (PGW)

=C2=A0

41

Proxy

=C2=A0

42

Data Loss Prevention (DLP)

=C2=A0

43

Open VPN

=C2=A0

44

Load Balancer=

=C2=A0

45

High Availability

=C2=A0

46

Virtual Private Network (VPN)

=C2=A0

47

NETCONF

=C2=A0

48

Network Prefix Translation IPv6-to-IPv6 (NPT)

=C2=A0

49

Serving Gateway (SGW)

=C2=A0

50

Gateway GPRS Support Node (GGSN)

=C2=A0

51

Internet Protocol Security- Gateway (IPsec-GW)

=C2=A0

52

video optimizer

=C2=A0

53

(BNG) Broadband Network Gateway

=C2=A0

54

Content Delivery Optimization

=C2=A0

55

Performance-enhancing proxies (PEPs)

=C2=A0

56

Web Proxy

=C2=A0

57

Distributed Denial of Service (DDOS)

=C2=A0

58

Voice Over IP

=C2=A0

Thank You.
Best Regards.

<= div>
<= font color=3D"#ff0000">PHD Student of Islamic Azad University Yazd Branch <= /font>
Faculty Member of Islamic Azad University= Shahrekord Branch
Home Page:
--94eb2c057a70e36bf1054841d91a-- From nobody Mon Feb 13 15:24:58 2017 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 127331299E3; Mon, 13 Feb 2017 15:24:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148702829407.22233.17840362650943020234.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2017 15:24:54 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:24:54 -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 of the IETF. Title : Network Service Header Authors : Paul Quinn Uri Elzur Filename : draft-ietf-sfc-nsh-11.txt Pages : 37 Date : 2017-02-13 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 13 15:30:05 2017 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 7C08F1299FA for ; Mon, 13 Feb 2017 15:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isSjlr-cQbJK for ; Mon, 13 Feb 2017 15:29:54 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C950E1299D9 for ; Mon, 13 Feb 2017 15:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8536; q=dns/txt; s=iport; t=1487028588; x=1488238188; h=from:to:subject:date:message-id:references:mime-version; bh=ngcBcJBM5/UqgDPPVBGn4fTKALIl3eXtqC3hd1JMzPQ=; b=Q1ZEFenYpVCm36e22K9GnkLBZPC30lAib0WR7R9HVuSgFQWLGNLLGfhR WrlZ0nkOSJVQgP0O8t55S18ckOtX9tApQA9imw1JyRce/fBxTGnrOtgkJ FwQ29KnE1sfB4zwulPwxjjDjROWbuCQGA/Ij8YYQDCIOEq+HPTDWz+jXO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQBIQaJY/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1JhgQkHjVqSDZAKhSyCDC6EGoFaAoFuPxgBAgEBAQEBAQFiHQu?= =?us-ascii?q?EaQEGawwSAgEZAQIBAigHMhQDBAIIAgQTiWoOsSGLWwEBAQEBAQEDAQEBAQEBA?= =?us-ascii?q?QEBH4ZMggWCaoMXgQ8RATwWgn6CMQWPQ4wvAYZuiyWBe1OERIlzkxQBDxA4eAh?= =?us-ascii?q?RFRg2AYQzHYFhdQEEh3uBIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,158,1484006400"; d="scan'208,217";a="384441577" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Feb 2017 23:29:39 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1DNTc7M029948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Feb 2017 23:29:39 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 17:29:38 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Mon, 13 Feb 2017 17:29:38 -0600 From: "Paul Quinn (paulq)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sfc-nsh-11.txt Thread-Index: AQHShlBkUCIc1jOOIUqdPqawp9G6OQ== Date: Mon, 13 Feb 2017 23:29:38 +0000 Message-ID: <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> References: <148702829421.22233.782542928593751229.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.17.231] Content-Type: multipart/alternative; boundary="_000_969E035087F941A682E6BC01608A41FAciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:29:57 -0000 --_000_969E035087F941A682E6BC01608A41FAciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This version integrates: - Much of the email thread with Alia re: her AD review of the draft. There= still might be a few minor items that need to be updated (e.g. some of the= IETF vs. expert review for registries) - The changes summarized by the chairs (https://mailarchive.ietf.org/arch/m= sg/sfc/03g2WEAeID_XIQgsFOZxD-diqQU/?qid=3D4eda91ca1d7acd135b12947201b6547a) - Some minor editorial changes Paul Begin forwarded message: From: > Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt Date: February 13, 2017 at 6:24:54 PM EST To: Uri Elzur >, Paul Quinn= > A new version of I-D, draft-ietf-sfc-nsh-11.txt has been successfully submitted by Paul Quinn and posted to the IETF repository. Name: draft-ietf-sfc-nsh Revision: 11 Title: Network Service Header Document date: 2017-02-12 Group: sfc Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.= txt Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-11 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_969E035087F941A682E6BC01608A41FAciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1D0072F844313A4FA08F88A1881ED6E7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Folks,

This version integrates:

- Much of the email thread with Alia re: her AD review of t= he draft.  There still might be a few minor items that need to be upda= ted (e.g. some of the IETF vs. expert review for registries)
- The changes summarized by the chairs (https://mailarchive.ietf.org/arch/ms= g/sfc/03g2WEAeID_XIQgsFOZxD-diqQU/?qid=3D4eda91ca1d7acd135b12947201b6547a)
- Some minor editorial changes

Paul


Begin forwarded message:

From: <internet-drafts@ietf.org>
Subject: New Version Notification = for draft-ietf-sfc-nsh-11.txt
Date: February 13, 2017 at 6:24:54 PM EST
To: Uri Elzur <uri.elzur@intel.com>, Paul Quinn <paulq@cisco.com>


A new version of I-D, draft-ietf-sfc-nsh-11.txt
has been successfully submitted by Paul Quinn and posted to the
IETF repository.

Name: draft-ietf-sfc-n= sh
Revision: 1= 1
Title: Network Service= Header
Document date: 2017-02-12
Group: sfc
Pages: 37
URL:            https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.txt Status:         https://datatracke= r.ietf.org/doc/draft-ietf-sfc-nsh/
Htmlized:       https://tools.ietf.org/html/dra= ft-ietf-sfc-nsh-11
Diff:           h= ttps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11

Abstract:
  This document describes a Network Service Header (NSH) inserted= onto
  packets or frames to realize service function paths.  NSH = also
  provides a mechanism for metadata exchange along the instantiat= ed
  service path.  NSH is the SFC encapsulation required to su= pport the
  Service Function Chaining (SFC) Architecture (defined in RFC766= 5).




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

The IETF Secretariat


--_000_969E035087F941A682E6BC01608A41FAciscocom_-- From nobody Tue Feb 14 01:06:53 2017 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 0FB6E129A1F for ; Tue, 14 Feb 2017 01:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 rog9thHKu_Ze for ; Tue, 14 Feb 2017 01:06:48 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFB21294C4 for ; Tue, 14 Feb 2017 01:06:46 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1E96fRS004628; Tue, 14 Feb 2017 09:06:41 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1E96ZXW004599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2017 09:06:38 GMT From: "Adrian Farrel" To: "'Paul Quinn \(paulq\)'" , References: <148702829421.22233.782542928593751229.idtracker@ietfa.amsl.com> <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> In-Reply-To: <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> Date: Tue, 14 Feb 2017 09:06:33 -0000 Message-ID: <02c901d286a1$a6af5210$f40df630$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CA_01D286A1.A6B397D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGMnwxIZb2zyo37VD+Wl5+I7TICSgI73LNHoeImM9A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22884.006 X-TM-AS-Result: No--21.333-10.0-31-10 X-imss-scan-details: No--21.333-10.0-31-10 X-TMASE-MatchedRID: HQYVVRq48RxbJCKOm3VRCbRWD4ydITYYb9cDvwh8Qkn7WEWV6Ymc/Ub5 H/7zTJtBLA/Iupptg2S4jAucHcCqnQ2AVSpm3nkDN15VVRl9DpFI0SOi4oVjlGUAHvSQ6dDic3c xZD41aLeXv2xdWsrNkoEMv3ouDK4x+uIuZYGsMgTKDbqftp1f15mI9bcoArAi4GZkEfdlVFJl8+ Yom0yW5pNPnS9GFVSgxZQoGMRGhhN/r8x3wtvaX7rfxlRjqBJ3XxRtKfVFN8PWsBqRfU1d88x9M rkHp569WX3rYwK+gsRVTfJWlqPdDLtq3FNsoMQgzsQ8iRVyD469Aok7FYFmb4BAUdh4514r9u75 WUASg3SInHjrjZy8lv0peXGEEBlvrogFtKd/P7fSlkoRLCKfE56QVnlXMIygXrfYosn++oqhIBg kfoHq9iIdmtkBwO3DlwOGeK/WrXNT4DtiSkMnWCgMxnfFXjiIdXDbHFxm2F+dv7RrSohAJCkm8k uls98/aEoHA+Yew8UAGGKG8CG8Akh41hM/w6ZM+TdKNkxxkWRSUGH6RuK0zz8NRz8HpCmSZEZKd Sp4I705BGX7329oyQwfhKwa9GwDWq9ln3+CkiGPaLJ/Ca3ST2ji04EzOjY469wtzA/gMV3q4Cah hpdFIOvSxgkYhCpaQesjq8XPMbuXYX34rFl3xyejSyZ3UYtkAMf5JkUGtGokg8WaoMOWypJTzjw z+GzoSLzBQxkvS+/uykw7cfAoIPxeH3fk9hIOl32P5ZifvYbz0Qr7GJy0y14tir8tqeDEbnM/8V JDhM2jbvDx57hYLzTR2TFg0xG3o/T1ZSiAQNCbKItl61J/yZUdXE/WGn0FfeZdJ1Xsorjr4Ukqz 3sOOaekT+magwxAg0aBGFrNAz15ILrkKK3IDN3ooP9s20QPb/kL+cIbu0alDJf+8bvQ7IqkAf4D SDP5ftwZ3X11IV0= Archived-At: Subject: Re: [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 09:06:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CA_01D286A1.A6B397D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nice. Thanks Paul. This is a great help. Adrian From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: 13 February 2017 23:30 To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-11.txt Folks, This version integrates: - Much of the email thread with Alia re: her AD review of the draft. There still might be a few minor items that need to be updated (e.g. some of the IETF vs. expert review for registries) - The changes summarized by the chairs (https://mailarchive.ietf.org/arch/msg/sfc/03g2WEAeID_XIQgsFOZxD-diqQU/?qid=4eda 91ca1d7acd135b12947201b6547a) - Some minor editorial changes Paul Begin forwarded message: From: Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt Date: February 13, 2017 at 6:24:54 PM EST To: Uri Elzur , Paul Quinn A new version of I-D, draft-ietf-sfc-nsh-11.txt has been successfully submitted by Paul Quinn and posted to the IETF repository. Name: draft-ietf-sfc-nsh Revision: 11 Title: Network Service Header Document date: 2017-02-12 Group: sfc Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.txt Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-11 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-11 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). 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 ------=_NextPart_000_02CA_01D286A1.A6B397D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nice.

Thanks = Paul.

This is a great = help.

Adrian

 

From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn = (paulq)
Sent: 13 February 2017 23:30
To: = sfc@ietf.org
Subject: [sfc] Fwd: New Version Notification for = draft-ietf-sfc-nsh-11.txt

 

Folks, =

 

This version integrates:

 

- Much of the email thread with Alia re: her AD review of the = draft.  There still might be a few minor items that need to be = updated (e.g. some of the IETF vs. expert review for = registries)

- Some minor editorial = changes

 

Paul

 



Begin forwarded = message:

 

Subject: New Version Notification for = draft-ietf-sfc-nsh-11.txt

Date: February 13, 2017 at 6:24:54 PM EST

To: Uri Elzur <uri.elzur@intel.com>, Paul = Quinn <paulq@cisco.com>

 


A new version of = I-D, draft-ietf-sfc-nsh-11.txt
has been successfully submitted by = Paul Quinn and posted to the
IETF repository.

Name: draft-ietf-sfc-nsh
Revision: 11
Title: = Network Service Header
Document date: 2017-02-12
Group: sfc
Pages: 37
URL: =            h= ttps://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.txt
Stat= us:         https://dat= atracker.ietf.org/doc/draft-ietf-sfc-nsh/
Htmlized: =       https://tools.= ietf.org/html/draft-ietf-sfc-nsh-11
Diff: =           https:= //www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11

Abstract:<= br>  This document describes a Network Service Header (NSH) = inserted onto
  packets or frames to realize service = function paths.  NSH also
  provides a mechanism for = metadata exchange along the instantiated
  service path. =  NSH is the SFC encapsulation required to support = the
  Service Function Chaining (SFC) Architecture (defined = in RFC7665).




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

 

------=_NextPart_000_02CA_01D286A1.A6B397D0-- From nobody Wed Feb 15 13:00:36 2017 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 85FF41297CE for ; Wed, 15 Feb 2017 13:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 vvF2hOFUbw2d for ; Wed, 15 Feb 2017 13:00:33 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6121297E1 for ; Wed, 15 Feb 2017 13:00:32 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1FL0UwF030285 for ; Wed, 15 Feb 2017 21:00:30 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1FL0Rn3030232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Feb 2017 21:00:29 GMT From: "Adrian Farrel" To: Date: Wed, 15 Feb 2017 21:00:25 -0000 Message-ID: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKHznKalxPKklEDRqOqF5nO++eCgQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22888.002 X-TM-AS-Result: No--2.369-10.0-31-10 X-imss-scan-details: No--2.369-10.0-31-10 X-TMASE-MatchedRID: Ru+54+IMWaS5rzEqaXlmzQz4VsCc1YW+C/ExpXrHizzhpE4kTKmv3CjQ lso6ZK5SHQ/CSk0EQtUjFhLOQQccdnsRVu35DItMQVWLLVSdiGtMkOX0UoduuXnJ59lE/B82z3R 6BkzM8/XUNSa0GEb3Xx9l1zPMOb+6TX7PJ/OU3vL+xOhjarOnHt0H8LFZNFG76sBnwpOylLPD11 OAQ3+GwWTadxKiyVJopDJ3anDzoxI6ooUXXjt7B/u48udXA6VaUrwD4rrmiEntFm8vHW6yQ+3R1 N33nw2QX7nI7GQkPl2Rzy9lhw/CZKG6tVpjWHJfjF1XCR4TdrdTI6qsXPa6iH7cGd19dSFd Archived-At: Subject: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 21:00:34 -0000 Hi, I think it is right that the NSH spec only minimally describe OAM, but I want to double check the intention of a couple of things here. Section 3.2 says: > O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet. The actual packet format and processing of > SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]). > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. 1. Isn't the first paragraph actually making a decision about the meaning of the O bit? That is, it is saying that the packet is an OAM packet? Would it be better to defer this type of decisions and say something a little more vague such as... > O bit: Setting this bit indicates that the NSH packet contains Operations, > Administration, and Maintenance (OAM) data. The actual packet format > and processing of SFC OAM data and how that data is carried in an NSH > packet is outside the scope of this specification (see > [I-D.ietf-sfc-oam-framework]). 2. Do we really want OAM packets discarded rather than passed through? That substantially minimises the utility of any OAM. Surely we want to specify > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > OAM procedures, SHALL process and forward packets with the O bit set > as normal. Thanks, Adrian From nobody Wed Feb 15 13:13:15 2017 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 BAF4A129B8E for ; Wed, 15 Feb 2017 13:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, 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 ReVQzJvzsNaV for ; Wed, 15 Feb 2017 13:13:06 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F31129B8C for ; Wed, 15 Feb 2017 13:13:06 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 15 Feb 2017 16:13:04 -0500 From: Dave Dolson To: "adrian@olddog.co.uk" , "sfc@ietf.org" Thread-Topic: [sfc] O-bit behavior in NSH spec Thread-Index: AdKHznKalxPKklEDRqOqF5nO++eCgQAASE5Q Date: Wed, 15 Feb 2017 21:13:04 +0000 Message-ID: References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> In-Reply-To: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 21:13:10 -0000 I prefer to think of the inverse: If the O-bit is zero, no functions are required to search the packet for OA= M information. I.e., if O-bit is zero, an SFF may forward the packet on the basis of SPI/S= I without checking next-protocol or searching metadata. I wish the text would actually say that. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, February 15, 2017 4:00 PM To: sfc@ietf.org Subject: [sfc] O-bit behavior in NSH spec Hi, I think it is right that the NSH spec only minimally describe OAM, but I wa= nt to double check the intention of a couple of things here. Section 3.2 says: > O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet. The actual packet format and processing of > SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]). > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. 1. Isn't the first paragraph actually making a decision about the meaning=20 of the O bit? That is, it is saying that the packet is an OAM packet? Would it be better to defer this type of decisions and say something a=20 little more vague such as... > O bit: Setting this bit indicates that the NSH packet contains Operations= , > Administration, and Maintenance (OAM) data. The actual packet format > and processing of SFC OAM data and how that data is carried in an NSH > packet is outside the scope of this specification (see=20 > [I-D.ietf-sfc-oam-framework]). 2. Do we really want OAM packets discarded rather than passed through? That substantially minimises the utility of any OAM. Surely we want to specify=20 > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > OAM procedures, SHALL process and forward packets with the O bit set=20 > as normal. Thanks, Adrian _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Feb 15 13:48:08 2017 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 98F83129847 for ; Wed, 15 Feb 2017 13:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 LiiVtbS3-6Ci for ; Wed, 15 Feb 2017 13:48:06 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8B2126B6D for ; Wed, 15 Feb 2017 13:48:05 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1FLm3CF021175; Wed, 15 Feb 2017 21:48:03 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1FLlWpC020905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2017 21:47:55 GMT From: "Adrian Farrel" To: "'Dave Dolson'" , References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> In-Reply-To: Date: Wed, 15 Feb 2017 21:47:31 -0000 Message-ID: <07aa01d287d5$2eec2f20$8cc48d60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKs4QfPsAfGu+IdxTavj2M4SM8+/wH6B6zrn6YXaIA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22888.003 X-TM-AS-Result: No--18.441-10.0-31-10 X-imss-scan-details: No--18.441-10.0-31-10 X-TMASE-MatchedRID: y/2oPz6gbvg4HKI/yaqRm4xVBvj1jbcjmyqQJWNsukloi2wGFOH+KGM9 4EcycNIw9833CkTuOdc8kMeEPbtdejhkyYEbqgcmbMGKOuLn5FVR3sGN+j7mNMz1fqX318VP0u5 faGP8ztQCN9w0OA8GC7m5LPmirU91LYNX1L+v3J6aVoAi2I40/Qd1gf75ubQY47ndse0z1bfzK7 bE2HRM4Ip0khaznkByo1ztrNL0UlfEQS2ecfkpF/t3QgyOPXbLciGHjBucKAqo+b+yOP0oGA42c I60OgkFnpKzo7ZuKEYcOfC+voH6NBgHZ8655DOPOX/V8P8ail3InWAWA4yE6foA9r2LThYYKrau Xd3MZDUD/dHyT/Xh7Q== Archived-At: Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 21:48:07 -0000 Well, > If the O-bit is zero, no functions are required to search the packet for OAM > information. > I.e., if O-bit is zero, an SFF may forward the packet on the basis of SPI/SI without > checking next-protocol or searching metadata. I can agree that. O bit zero. No OAM. > I wish the text would actually say that. Ha! And I am worried by what the text does say :-) Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, February 15, 2017 4:00 PM > To: sfc@ietf.org > Subject: [sfc] O-bit behavior in NSH spec > > Hi, > > I think it is right that the NSH spec only minimally describe OAM, but I want to > double check the intention of a couple of things here. > > Section 3.2 says: > > > O bit: Setting this bit indicates an Operations, Administration, and > > Maintenance (OAM) packet. The actual packet format and processing of > > SFC OAM messages is outside the scope of this specification (see [I- > > D.ietf-sfc-oam-framework]). > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > > OAM procedures, SHALL discard packets with O-bit set. > > 1. Isn't the first paragraph actually making a decision about the meaning > of the O bit? That is, it is saying that the packet is an OAM packet? > Would it be better to defer this type of decisions and say something a > little more vague such as... > > > O bit: Setting this bit indicates that the NSH packet contains Operations, > > Administration, and Maintenance (OAM) data. The actual packet format > > and processing of SFC OAM data and how that data is carried in an NSH > > packet is outside the scope of this specification (see > > [I-D.ietf-sfc-oam-framework]). > > 2. Do we really want OAM packets discarded rather than passed through? > That substantially minimises the utility of any OAM. > Surely we want to specify > > > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > > OAM procedures, SHALL process and forward packets with the O bit set > > as normal. > > Thanks, > Adrian > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Feb 15 13:53:46 2017 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 7AF3112987F for ; Wed, 15 Feb 2017 13:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, 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 JBX-4SYY-1MP for ; Wed, 15 Feb 2017 13:53:43 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9B6129871 for ; Wed, 15 Feb 2017 13:53:41 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 15 Feb 2017 16:53:39 -0500 From: Dave Dolson To: "Paul Quinn (paulq)" , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sfc-nsh-11.txt Thread-Index: AQHShlBkUCIc1jOOIUqdPqawp9G6OaFqnyRg Date: Wed, 15 Feb 2017 21:53:38 +0000 Message-ID: References: <148702829421.22233.782542928593751229.idtracker@ietfa.amsl.com> <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> In-Reply-To: <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9870512E62wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 21:53:44 -0000 --_000_E8355113905631478EFF04F5AA706E9870512E62wtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do we expect changes regarding: - Removal of C-flag ? - Addition of TTL ? From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Monday, February 13, 2017 6:30 PM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-11.txt Folks, This version integrates: - Much of the email thread with Alia re: her AD review of the draft. There= still might be a few minor items that need to be updated (e.g. some of the= IETF vs. expert review for registries) - The changes summarized by the chairs (https://mailarchive.ietf.org/arch/m= sg/sfc/03g2WEAeID_XIQgsFOZxD-diqQU/?qid=3D4eda91ca1d7acd135b12947201b6547a) - Some minor editorial changes Paul Begin forwarded message: From: > Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt Date: February 13, 2017 at 6:24:54 PM EST To: Uri Elzur >, Paul Quinn= > A new version of I-D, draft-ietf-sfc-nsh-11.txt has been successfully submitted by Paul Quinn and posted to the IETF repository. Name: draft-ietf-sfc-nsh Revision: 11 Title: Network Service Header Document date: 2017-02-12 Group: sfc Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.= txt Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-11 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_E8355113905631478EFF04F5AA706E9870512E62wtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do we expect changes rega= rding:

- =          Removal of C-flag= ?

- =          Addition of TTL ?=

 <= /p>

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Monday, February 13, 2017 6:30 PM
To: sfc@ietf.org
Subject: [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-= 11.txt

 

Folks,

 

This version integrates:

 

- Much of the email thread with Alia re: her AD revi= ew of the draft.  There still might be a few minor items that need to = be updated (e.g. some of the IETF vs. expert review for registries)

- Some minor editorial changes

 

Paul

 



Begin forwarded message:

 

Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt

Date: February 13, 2017 at 6:24:54 PM EST

 


A new version of I-D, draft-ietf-sfc-nsh-11.txt
has been successfully submitted by Paul Quinn and posted to the
IETF repository.

Name: draft-ietf-sfc-nsh
Revision: 11
Title: Network Service Header
Document date: 2017-02-12
Group: sfc
Pages: 37
URL:            http= s://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.txt
Status:         https://datatracker.ietf.org/= doc/draft-ietf-sfc-nsh/
Htmlized:       https://tools.ietf.org/html/draft-ietf-sfc= -nsh-11
Diff:           https://www.= ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11

Abstract:
  This document describes a Network Service Header (NSH) inserted= onto
  packets or frames to realize service function paths.  NSH = also
  provides a mechanism for metadata exchange along the instantiat= ed
  service path.  NSH is the SFC encapsulation required to su= pport the
  Service Function Chaining (SFC) Architecture (defined in RFC766= 5).




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

The IETF Secretariat

 

--_000_E8355113905631478EFF04F5AA706E9870512E62wtlexchp1sandvi_-- From nobody Wed Feb 15 14:17:18 2017 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 611D0129871 for ; Wed, 15 Feb 2017 14:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 V9tQu1XLltvh for ; Wed, 15 Feb 2017 14:17:14 -0800 (PST) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.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 A18E0129869 for ; Wed, 15 Feb 2017 14:17:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 51E8C28595C; Wed, 15 Feb 2017 14:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487197034; bh=JB8CQ5kbFhC22AeAN6Q3twxIsGOBfQzIXDC1gXYrUy4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=B0FmtRCXcD1oNFFOe+cqIryYxQtA5FSyjcbXQrXwTeOVzSGpCiGuvNqj+AVRazgUw O8Yqp53GSfL9sniaB1bpZ54aT2QUAGr4UDnQRd2pmJkUjGZdSaGDREs3dGKMzITZGA /d1VEVyANWbmsXErYpzHqi2Z0qNbXaiKvC3c9Qhs= 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 C58421C0206; Wed, 15 Feb 2017 14:17:13 -0800 (PST) To: Dave Dolson , "Paul Quinn (paulq)" , "sfc@ietf.org" References: <148702829421.22233.782542928593751229.idtracker@ietfa.amsl.com> <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> From: "Joel M. Halpern" Message-ID: <3174cda2-2dda-bb2c-43c7-279e978fe639@joelhalpern.com> Date: Wed, 15 Feb 2017 17:17:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 22:17:16 -0000 The chairs request of the authors was to get the text out with the known and (we believed) agreed changes, so that we all had text to work from. Once the chairs call consensus on the other points, then we expect the following revision to include them. Yours, Joel On 2/15/17 4:53 PM, Dave Dolson wrote: > Do we expect changes regarding: > > - Removal of C-flag ? > > - Addition of TTL ? > > > > > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn (paulq) > *Sent:* Monday, February 13, 2017 6:30 PM > *To:* sfc@ietf.org > *Subject:* [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-11.txt > > > > Folks, > > > > This version integrates: > > > > - Much of the email thread with Alia re: her AD review of the draft. > There still might be a few minor items that need to be updated (e.g. > some of the IETF vs. expert review for registries) > > - The changes summarized by the chairs > (https://mailarchive.ietf.org/arch/msg/sfc/03g2WEAeID_XIQgsFOZxD-diqQU/?qid=4eda91ca1d7acd135b12947201b6547a) > > - Some minor editorial changes > > > > Paul > > > > > > Begin forwarded message: > > > > *From: *> > > *Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt* > > *Date: *February 13, 2017 at 6:24:54 PM EST > > *To: *Uri Elzur >, Paul > Quinn > > > > > > A new version of I-D, draft-ietf-sfc-nsh-11.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. > > Name:draft-ietf-sfc-nsh > Revision:11 > Title:Network Service Header > Document date:2017-02-12 > Group:sfc > Pages:37 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-11 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-11 > > Abstract: > This document describes a Network Service Header (NSH) inserted onto > packets or frames to realize service function paths. NSH also > provides a mechanism for metadata exchange along the instantiated > service path. NSH is the SFC encapsulation required to support the > Service Function Chaining (SFC) Architecture (defined in RFC7665). > > > > > 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 > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Feb 15 17:12:06 2017 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 2DEB112960A for ; Wed, 15 Feb 2017 17:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 1Kp2n5LyjTK5 for ; Wed, 15 Feb 2017 17:12:03 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 03744129B91 for ; Wed, 15 Feb 2017 17:12:02 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id u143so1634569oif.3 for ; Wed, 15 Feb 2017 17:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UivAE4K1POlkVXk/IkaWgqkmfLrFrLR/+ivNNs5VlII=; b=iGJzuSEhhrT9HIU3qUF0Nf4x/w69IuPEzjGEN0WoWxswd+L+SuYwfwxKg99n+xslEn +C+6B5CtoMNHe6bUcuJT4CJEUhvc3cH9c2Xo2BUFPeYprGdk4n9ys/AhEjtsk+fF7+Ch YRn4PFcOQRmqyLF2AdE/vWr5oV5KlfFflx8c5xHAT+F1zSENIT0yUu/b5vC/ymCC3hBs /MZCFJThQnCtAIxpToPxRKLmhS6XImnUukWqZY1Bas9k1CP2SFBbbIdzUl7URjR8ejnf duj3XZQk7Y4xoWpDBL4TyW77Ode0avWUCHqWRmfjQVSRMgGQlpChJ4Q67hLggWNE9ybb 9O5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UivAE4K1POlkVXk/IkaWgqkmfLrFrLR/+ivNNs5VlII=; b=DYSrIz3MSHNs7jDf+qh7UXj0jjlAzhff93lYx2oh0LgwBtXqADR3ex9lRasl7dBq55 e1arYGWuM66BLyMZgXusjvz+CSzDGVNrOx+GhuDvICGvxnlBS4hX8UjDCFW4u/3lb2vd tN2eg6JCDo0xA5jiLUXkvhPV3cnoxbo96Y927KW+jLQNR/myB/3PSxnwheC3OUqQ4jFi UNuxdo4KJIX6TVmcnpSiUwU6CTgw4be3/P1GK5KeQhX060i5fvY2a3Z2ZDxDY4IfqIue p4xUCxfnN7afVerE2xT7wu6o8sxVLF7GCXS1lDyLKXW8b/zYv0AeMV6ciQb0zbKXohgE uK0g== X-Gm-Message-State: AMke39nxlHVeaqAnxVL3U8sMlrj+zhJ+Cib3J7H5WgbP3VVfHdznzKA+nNPn9oO5S+SaJnjR/fBEpVcMOU9cBA== X-Received: by 10.202.239.2 with SMTP id n2mr22490324oih.157.1487207522232; Wed, 15 Feb 2017 17:12:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Wed, 15 Feb 2017 17:12:01 -0800 (PST) In-Reply-To: References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> From: Greg Mirsky Date: Wed, 15 Feb 2017 17:12:01 -0800 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=94eb2c0931da11f07e05489b7c25 Archived-At: Cc: "adrian@olddog.co.uk" , "sfc@ietf.org" Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:12:05 -0000 --94eb2c0931da11f07e05489b7c25 Content-Type: text/plain; charset=UTF-8 Hi Dave, in "without checking next-protocol or searching metadata" you've expressed common assumption that O-bit indicates two options: - message that immediately follows NSH is OAM message; - one of Variable Length Context Headers carries OAM message. If that is in fact implicit common interpretation of O-bit, then I have couple questions: - why there's need to use two mechanisms to carry OAM message; - how to avoid unnecessary search through metadata if the message immediately after NSH is OAM, e.g. BFD control message. I think that it would be much simpler and cleaner if we interpret "OAM packet" as "message that immediately follows NSH is OAM message" and indicate this case in NSH Base Header (I prefer use OAM protocol type). And what is carried in metadata conveyed through Metadata Class and Type in Variable Context Header. Regards, Greg On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson wrote: > I prefer to think of the inverse: > If the O-bit is zero, no functions are required to search the packet for > OAM information. > I.e., if O-bit is zero, an SFF may forward the packet on the basis of > SPI/SI without checking next-protocol or searching metadata. > > I wish the text would actually say that. > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, February 15, 2017 4:00 PM > To: sfc@ietf.org > Subject: [sfc] O-bit behavior in NSH spec > > Hi, > > I think it is right that the NSH spec only minimally describe OAM, but I > want to > double check the intention of a couple of things here. > > Section 3.2 says: > > > O bit: Setting this bit indicates an Operations, Administration, and > > Maintenance (OAM) packet. The actual packet format and processing of > > SFC OAM messages is outside the scope of this specification (see [I- > > D.ietf-sfc-oam-framework]). > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > > OAM procedures, SHALL discard packets with O-bit set. > > 1. Isn't the first paragraph actually making a decision about the meaning > of the O bit? That is, it is saying that the packet is an OAM packet? > Would it be better to defer this type of decisions and say something a > little more vague such as... > > > O bit: Setting this bit indicates that the NSH packet contains > Operations, > > Administration, and Maintenance (OAM) data. The actual packet format > > and processing of SFC OAM data and how that data is carried in an NSH > > packet is outside the scope of this specification (see > > [I-D.ietf-sfc-oam-framework]). > > 2. Do we really want OAM packets discarded rather than passed through? > That substantially minimises the utility of any OAM. > Surely we want to specify > > > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > > OAM procedures, SHALL process and forward packets with the O bit set > > as normal. > > Thanks, > Adrian > > _______________________________________________ > 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 > --94eb2c0931da11f07e05489b7c25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,
in "wit= hout checking next-protocol or searching metadata" you've expresse= d common assumption that O-bit indicates two options:
    =
  • message that immediately follows NSH i= s OAM message;
  • one of Varia= ble Length Context Headers carries OAM message.
If that is in fact implicit common interpretation of = O-bit, then I have couple questions:
  • why there's need to use two mechanisms to carry O= AM message;
  • how to avoid un= necessary search through metadata if the message immediately after NSH is O= AM, e.g. BFD control message.
I think that it would be much simpler and cleaner if we interpret = "OAM packet" as "mes= sage that immediately follows NSH is OAM message" and indicate this ca= se in NSH Base Header (I prefer use OAM protocol type). And what is carried= in metadata conveyed through Metadata Class and Type in Variable Context H= eader.

<= /div>
Regards,
Greg

On Wed, Feb 15, 2017 at 1:13 PM, Dave Dols= on <ddolson@sandvine.com> wrote:
I prefer to think of the inverse:
If the O-bit is zero, no functions are required to search the packet for OA= M information.
I.e., if O-bit is zero, an SFF may forward the packet on the basis of SPI/S= I without checking next-protocol or searching metadata.

I wish the text would actually say that.


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 4:00 PM
To: sfc@ietf.org
Subject: [sfc] O-bit behavior in NSH spec

Hi,

I think it is right that the NSH spec only minimally describe OAM, but I wa= nt to
double check the intention of a couple of things here.

Section 3.2 says:

> O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet.=C2=A0 The actual packet format and processin= g of
> SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]).
>
> SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set.

1. Isn't the first paragraph actually making a decision about the meani= ng
=C2=A0 =C2=A0of the O bit? That is, it is saying that the packet is an OAM = packet?
=C2=A0 =C2=A0Would it be better to defer this type of decisions and say som= ething a
=C2=A0 =C2=A0little more vague such as...

> O bit: Setting this bit indicates that the NSH packet contains Operati= ons,
> Administration, and Maintenance (OAM) data.=C2=A0 The actual packet fo= rmat
> and processing of SFC OAM data and how that data is carried in an NSH<= br> > packet is outside the scope of this specification (see
> [I-D.ietf-sfc-oam-framework]).

2. Do we really want OAM packets discarded rather than passed through?
=C2=A0 =C2=A0 That substantially minimises the utility of any OAM.
=C2=A0 =C2=A0 Surely we want to specify

> SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > OAM procedures, SHALL process and forward packets with the O bit set > as normal.

Thanks,
Adrian

_______________________________________________
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

--94eb2c0931da11f07e05489b7c25-- From nobody Wed Feb 15 18:01:02 2017 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 D6E271294B7 for ; Wed, 15 Feb 2017 18:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 Gobpslc9K9BS for ; Wed, 15 Feb 2017 18:00:59 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997161293FE for ; Wed, 15 Feb 2017 18:00:59 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 15 Feb 2017 21:00:58 -0500 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 15 Feb 2017 21:00:58 -0500 From: Dave Dolson To: Greg Mirsky Thread-Topic: [sfc] O-bit behavior in NSH spec Thread-Index: AdKHznKalxPKklEDRqOqF5nO++eCgQAASE5QABMAjoD//7naeg== Date: Thu, 16 Feb 2017 02:00:56 +0000 Message-ID: <20170216020055.8495190.89878.137349@sandvine.com> References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_20170216020055849519089878137349sandvinecom_" MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" , "sfc@ietf.org" Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 02:01:01 -0000 --_000_20170216020055849519089878137349sandvinecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, Multiple ideas have been discussed, and no one seems willing to put what OA= M *is* in the NSH draft. So I thought it might be more productive to say what it is not, and gain a = performance benefit of checking a single bit to know whether slow-path proc= essing is required. -Dave From: Greg Mirsky Sent: Wednesday, February 15, 2017 8:12 PM To: Dave Dolson Cc: adrian@olddog.co.uk; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec Hi Dave, in "without checking next-protocol or searching metadata" you've expressed = common assumption that O-bit indicates two options: * message that immediately follows NSH is OAM message; * one of Variable Length Context Headers carries OAM message. If that is in fact implicit common interpretation of O-bit, then I have cou= ple questions: * why there's need to use two mechanisms to carry OAM message; * how to avoid unnecessary search through metadata if the message immed= iately after NSH is OAM, e.g. BFD control message. I think that it would be much simpler and cleaner if we interpret "OAM pack= et" as "message that immediately follows NSH is OAM message" and indicate t= his case in NSH Base Header (I prefer use OAM protocol type). And what is c= arried in metadata conveyed through Metadata Class and Type in Variable Con= text Header. Regards, Greg On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson > wrote: I prefer to think of the inverse: If the O-bit is zero, no functions are required to search the packet for OA= M information. I.e., if O-bit is zero, an SFF may forward the packet on the basis of SPI/S= I without checking next-protocol or searching metadata. I wish the text would actually say that. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Beh= alf Of Adrian Farrel Sent: Wednesday, February 15, 2017 4:00 PM To: sfc@ietf.org Subject: [sfc] O-bit behavior in NSH spec Hi, I think it is right that the NSH spec only minimally describe OAM, but I wa= nt to double check the intention of a couple of things here. Section 3.2 says: > O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet. The actual packet format and processing of > SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]). > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. 1. Isn't the first paragraph actually making a decision about the meaning of the O bit? That is, it is saying that the packet is an OAM packet? Would it be better to defer this type of decisions and say something a little more vague such as... > O bit: Setting this bit indicates that the NSH packet contains Operations= , > Administration, and Maintenance (OAM) data. The actual packet format > and processing of SFC OAM data and how that data is carried in an NSH > packet is outside the scope of this specification (see > [I-D.ietf-sfc-oam-framework]). 2. Do we really want OAM packets discarded rather than passed through? That substantially minimises the utility of any OAM. Surely we want to specify > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > OAM procedures, SHALL process and forward packets with the O bit set > as normal. Thanks, Adrian _______________________________________________ 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 --_000_20170216020055849519089878137349sandvinecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: Greg Mirsky
Sent: Wednesday, February 15, 2017 8:12 PM
To: Dave Dolson
Cc: adrian@olddog.co.uk; sfc@ietf.org
Subject: Re: [sfc] O-bit behavior in NSH spec

Hi Dave,
in "without checking next-protoc= ol or searching metadata" you've expressed common assumption that O-bi= t indicates two options:
  • message that immediately follows NSH i= s OAM message;
  • one of Varia= ble Length Context Headers carries OAM message.
If that is in fact implicit common interpr= etation of O-bit, then I have couple questions:
  • why there's need to use two mechanisms= to carry OAM message;
  • how = to avoid unnecessary search through metadata if the message immediately aft= er NSH is OAM, e.g. BFD control message.
I think that it would be much simpler= and cleaner if we interpret "OAM packet" as "message that immediately follows NSH is OAM messa= ge" and indicate this case in NSH Base Header (I prefer use OAM protocol type). And what is carried in metadata conveyed through M= etadata Class and Type in Variable Context Header.

Regards,
Greg

On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson <ddolson@sandv= ine.com> wrote:
I prefer to think of the inverse:
If the O-bit is zero, no functions are required to search the packet for OA= M information.
I.e., if O-bit is zero, an SFF may forward the packet on the basis of SPI/S= I without checking next-protocol or searching metadata.

I wish the text would actually say that.


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 4:00 PM
To: sfc@ietf.org
Subject: [sfc] O-bit behavior in NSH spec

Hi,

I think it is right that the NSH spec only minimally describe OAM, but I wa= nt to
double check the intention of a couple of things here.

Section 3.2 says:

> O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet.  The actual packet format and processin= g of
> SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]).
>
> SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set.

1. Isn't the first paragraph actually making a decision about the meaning    of the O bit? That is, it is saying that the packet is an OAM = packet?
   Would it be better to defer this type of decisions and say som= ething a
   little more vague such as...

> O bit: Setting this bit indicates that the NSH packet contains Operati= ons,
> Administration, and Maintenance (OAM) data.  The actual packet fo= rmat
> and processing of SFC OAM data and how that data is carried in an NSH<= br> > packet is outside the scope of this specification (see
> [I-D.ietf-sfc-oam-framework]).

2. Do we really want OAM packets discarded rather than passed through?
    That substantially minimises the utility of any OAM.
    Surely we want to specify

> SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > OAM procedures, SHALL process and forward packets with the O bit set > as normal.

Thanks,
Adrian

_______________________________________________
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

--_000_20170216020055849519089878137349sandvinecom_-- From nobody Wed Feb 15 18:20:55 2017 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 0F011129C53 for ; Wed, 15 Feb 2017 18:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 QoWDzqp3gfuu for ; Wed, 15 Feb 2017 18:20:51 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 4F8941299C1 for ; Wed, 15 Feb 2017 18:20:51 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id s203so2237134oie.1 for ; Wed, 15 Feb 2017 18:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vozKs350AVLUg5pXj0QyFR0JgOjFeX1uRoG8UbZBKJU=; b=r8ttWkvtywBFtczS34hz+9uDo5PHz5bZBi01ZTv+yh/V6Sfz4ApW2XvC027MIJ/Wt2 +OeGKEyjJyxzJGmZ7v+g4Dnw+7izLLbF2ZctoNRn06MjVmM18fV28UDVc3mvcZK8sOEw sIIGdYyWh7/wdIjRes1eRe9oW9PJVZ+eh3iiinPDH5IPgN/NfgS071shKKeUgg1S8hMo rD5auboHQ7+tsdujRqgB840N08xJZN27aS9yTTjMoALUuis4GbPmvBlNqGiXm1NtdMc8 SrpdPQfXEg+1Rj8fjBS6pF3k46Yje5J7SSlG/b6EW0HhzzWrBw0ITycE/cN2Bk00Tln0 hYUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vozKs350AVLUg5pXj0QyFR0JgOjFeX1uRoG8UbZBKJU=; b=o0qfco6WSI5cqOn+JTUZuG7p3dNF9StjvtBgeCRqT7oiu6w3YXA8zuvsq/aUthn+VQ liApweoDAiWghp5tGnj66RoViNPKsJ9PQWLKVjbW8LjOImKryVKdGlNC5MUypNWihfQU MW+4T773G9n696h2mB84lrVxrxr2i9Dj3wveny28QEsjxb7tTaWA2zSfh6HTyHC5RtKK g6fVYY7J4SY6SFdJjoutAqJkG/YhowEWvKvuvWzjL+w1fHAnqWoE1nZ89NskG2Nly7iZ naL2qjFvpDE1UnJRlibNOfNrlUanB7J+7mLIzwR/bd5WVUbRUBFR21WKFkYHQdZzu6bV lezg== X-Gm-Message-State: AMke39k9UmrFoxM3WJgzLiyRNSP/TZB0UeWYTO0qZNtSxCEEkE8kV+hNVtnnbY7bqIvRIfHE/yaaMxpcQYbNpA== X-Received: by 10.202.172.136 with SMTP id v130mr21627593oie.167.1487211650664; Wed, 15 Feb 2017 18:20:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Wed, 15 Feb 2017 18:20:50 -0800 (PST) In-Reply-To: <20170216020055.8495190.89878.137349@sandvine.com> References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <20170216020055.8495190.89878.137349@sandvine.com> From: Greg Mirsky Date: Wed, 15 Feb 2017 18:20:50 -0800 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a113ce9bc24d16505489c7282 Archived-At: Cc: "adrian@olddog.co.uk" , "sfc@ietf.org" Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 02:20:54 -0000 --001a113ce9bc24d16505489c7282 Content-Type: text/plain; charset=UTF-8 Hi Dave, I propose to deprecate O-bit all together and return it in Reserved pool.We had discussion whether checking value of one bit long flag is more efficient then checking multi-bit field for particular value. The conclusion, as I recall, was that there's no significant advantage of former over the latter, if any advantage at all. Regards, Greg On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson wrote: > Greg, > Multiple ideas have been discussed, and no one seems willing to put what > OAM *is* in the NSH draft. > > So I thought it might be more productive to say what it is not, and gain a > performance benefit of checking a single bit to know whether slow-path > processing is required. > > -Dave > > > *From: *Greg Mirsky > *Sent: *Wednesday, February 15, 2017 8:12 PM > *To: *Dave Dolson > *Cc: *adrian@olddog.co.uk; sfc@ietf.org > *Subject: *Re: [sfc] O-bit behavior in NSH spec > > Hi Dave, > in "without checking next-protocol or searching metadata" you've > expressed common assumption that O-bit indicates two options: > > - message that immediately follows NSH is OAM message; > - one of Variable Length Context Headers carries OAM message. > > If that is in fact implicit common interpretation of O-bit, then I have > couple questions: > > - why there's need to use two mechanisms to carry OAM message; > - how to avoid unnecessary search through metadata if the message > immediately after NSH is OAM, e.g. BFD control message. > > I think that it would be much simpler and cleaner if we interpret "OAM > packet" as "message that immediately follows NSH is OAM message" and > indicate this case in NSH Base Header (I prefer use OAM protocol type). And > what is carried in metadata conveyed through Metadata Class and Type in > Variable Context Header. > > Regards, > Greg > > On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson wrote: > >> I prefer to think of the inverse: >> If the O-bit is zero, no functions are required to search the packet for >> OAM information. >> I.e., if O-bit is zero, an SFF may forward the packet on the basis of >> SPI/SI without checking next-protocol or searching metadata. >> >> I wish the text would actually say that. >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel >> Sent: Wednesday, February 15, 2017 4:00 PM >> To: sfc@ietf.org >> Subject: [sfc] O-bit behavior in NSH spec >> >> Hi, >> >> I think it is right that the NSH spec only minimally describe OAM, but I >> want to >> double check the intention of a couple of things here. >> >> Section 3.2 says: >> >> > O bit: Setting this bit indicates an Operations, Administration, and >> > Maintenance (OAM) packet. The actual packet format and processing of >> > SFC OAM messages is outside the scope of this specification (see [I- >> > D.ietf-sfc-oam-framework]). >> > >> > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC >> > OAM procedures, SHALL discard packets with O-bit set. >> >> 1. Isn't the first paragraph actually making a decision about the meaning >> of the O bit? That is, it is saying that the packet is an OAM packet? >> Would it be better to defer this type of decisions and say something a >> little more vague such as... >> >> > O bit: Setting this bit indicates that the NSH packet contains >> Operations, >> > Administration, and Maintenance (OAM) data. The actual packet format >> > and processing of SFC OAM data and how that data is carried in an NSH >> > packet is outside the scope of this specification (see >> > [I-D.ietf-sfc-oam-framework]). >> >> 2. Do we really want OAM packets discarded rather than passed through? >> That substantially minimises the utility of any OAM. >> Surely we want to specify >> >> > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC >> > OAM procedures, SHALL process and forward packets with the O bit set >> > as normal. >> >> Thanks, >> Adrian >> >> _______________________________________________ >> 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 >> > > --001a113ce9bc24d16505489c7282 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,
I propose to deprecate O-bit all together and= return it in Reserved pool.We had discussion whether checking value of one= bit long flag is more efficient then checking multi-bit field for particul= ar value. The conclusion, as I recall, was that there's no significant = advantage of former over the latter, if any advantage at all.
Regards,
Greg
<= br>
On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson = <ddolson@sandvine.com> wrote:
Greg,
Multiple ideas have been discussed, and no one seems willing to put what OA= M *is* in the NSH draft.

So I thought it might be more productive to say what it is not, and gain a = performance benefit of checking a single bit to know whether slow-path proc= essing is required.

-Dave


From: Greg Mirsky
Sent: Wednesday, February 15, 2017 8:12 PM
To: Dave Dolson
Subject: Re: [sfc] O-bit behavior in NSH spec

Hi Dave,
in "without checking next-protoc= ol or searching metadata" you've expressed common assumption that = O-bit indicates two options:
  • message that immediately follows NSH i= s OAM message;
  • one of Varia= ble Length Context Headers carries OAM message.
If that is in fact implicit common interpr= etation of O-bit, then I have couple questions:
  • why there's need to use two mechan= isms to carry OAM message;
  • = how to avoid unnecessary search through metadata if the message immediately= after NSH is OAM, e.g. BFD control message.
I think that it would be much simpler= and cleaner if we interpret "OAM packet" as "message that immediately follows NSH is OAM messa= ge" and indicate this case in NSH Base Header (I prefer use OAM protocol type). And what is carried in metadata conveyed through M= etadata Class and Type in Variable Context Header.

Regards,
Greg

On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson <ddolson@sandv= ine.com> wrote:
I prefer to think of the inverse:
If the O-bit is zero, no functions are required to search the packet for OA= M information.
I.e., if O-bit is zero, an SFF may forward the packet on the basis of SPI/S= I without checking next-protocol or searching metadata.

I wish the text would actually say that.


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 4:00 PM
To: sfc@ietf.org
Subject: [sfc] O-bit behavior in NSH spec

Hi,

I think it is right that the NSH spec only minimally describe OAM, but I wa= nt to
double check the intention of a couple of things here.

Section 3.2 says:

> O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet.=C2=A0 The actual packet format and processin= g of
> SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]).
>
> SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set.

1. Isn't the first paragraph actually making a decision about the meani= ng
=C2=A0 =C2=A0of the O bit? That is, it is saying that the packet is an OAM = packet?
=C2=A0 =C2=A0Would it be better to defer this type of decisions and say som= ething a
=C2=A0 =C2=A0little more vague such as...

> O bit: Setting this bit indicates that the NSH packet contains Operati= ons,
> Administration, and Maintenance (OAM) data.=C2=A0 The actual packet fo= rmat
> and processing of SFC OAM data and how that data is carried in an NSH<= br> > packet is outside the scope of this specification (see
> [I-D.ietf-sfc-oam-framework]).

2. Do we really want OAM packets discarded rather than passed through?
=C2=A0 =C2=A0 That substantially minimises the utility of any OAM.
=C2=A0 =C2=A0 Surely we want to specify

> SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > OAM procedures, SHALL process and forward packets with the O bit set > as normal.

Thanks,
Adrian

_______________________________________________
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


--001a113ce9bc24d16505489c7282-- From nobody Thu Feb 16 01:41:22 2017 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 DA6CB129424 for ; Thu, 16 Feb 2017 01:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 QWjRuv5XniOe for ; Thu, 16 Feb 2017 01:41:18 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAC8129408 for ; Thu, 16 Feb 2017 01:41:16 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1G9fDWe028362; Thu, 16 Feb 2017 09:41:13 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1G9f9NN028314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2017 09:41:11 GMT From: "Adrian Farrel" To: "'Greg Mirsky'" , "'Dave Dolson'" References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <20170216020055.8495190.89878.137349@sandvine.com> In-Reply-To: Date: Thu, 16 Feb 2017 09:41:09 -0000 Message-ID: <085401d28838$cf1dd2b0$6d597810$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0855_01D28838.CF248970" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKs4QfPsAfGu+IdxTavj2M4SM8+/wH6B6zrApUMVOEC4N2N+gHz78PHn2uPlZA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22888.005 X-TM-AS-Result: No--23.578-10.0-31-10 X-imss-scan-details: No--23.578-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO0XXEXrP7ee7aOuVibdZNTvNRv92EahEcHSYAzZ6KmqWv2c gRYyKZ28mnHTJAPU2hMibsbwElNx2YWDz7mPxd0pfFMOK/HqfAbLBdK2mpaYlsz1fqX318VP0u5 faGP8ztRWZo3G/TpFVe5MHvi1B5E4tw/o4J9vD+ZsIyeExXlNbvRNGadeWv2Oa0TOsL14A2nM1Q TxDGbaGBEjJSSoNYXRH23VKxSbpudSN5j/GgtDwdSXAsH1ZIvUmyqQJWNsuklb6PBUqmq+UklLn R7iTfZsBkCMDAj7YGW9YhHcRu9f6JT4aNAfw9QKE0Q83A2vD+spWss5kPUFdAv/nTOPQovs8hpl Q9P0DiKjDmpdVPstGkVPXQcFT7LoRX0yvJubikzDr0AjBcmfRpLcb1TGljGw4ilGqCIXmu2YpuG 7kpoKR10o1OP2AtE9IVVUF8haIas0S6xFgcSPdjNKWYiz0CE6gGa+oYp5i6ooDMZ3xV44iIs3KZ MobQolag08UR9b+sdUu62uX/rSGY8sb4DSq8Smqbg9uWhLYLf2kudi1D33ErJ3rmpkUU+TJ8H95 H5rK0M22uoEm245foFaNaPuEIbSaWbbDm4LdIZ3vIzA7XyIiCEF1RdqrHVdtdx2lXHjF1Ii/B2g ujrEHzB6EdCmNDGVVbEDP0uzojXyTBeqcpWTVl0yuDrT1H0Eo7heNWkyUV2f6WkmZi4Ro3uW2rI m8eCn8k6NRrEpcqoZIoMiCNT2eTLj310JtDLwiguiJuCNURfVY9jEIdWup2AfN+t90cS3hzQHk5 Qv+7UzmpYx+UKjh3C2KyYp/H7vWYqLLUX2mAueAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCsiYXGrixzTzNo4RjYus3jycokYiQl/GQMT469nnkrm+tSwwcGKLTYEc= Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 09:41:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0855_01D28838.CF248970 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable So a high-level question is: Will you ever want to include OAM in an NSH packet that also contains = user data? =20 My impression was that there was some desire for this. =20 That would certainly change: - the use of "next protocol" to indicate OAM (unless OAM had a recursive = next protocol?) - how a node that did not support OAM found the user data =20 It would make of the O flag more useful. =20 A =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: 16 February 2017 02:21 To: Dave Dolson Cc: adrian@olddog.co.uk; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec =20 Hi Dave, I propose to deprecate O-bit all together and return it in Reserved = pool.We had discussion whether checking value of one bit long flag is = more efficient then checking multi-bit field for particular value. The = conclusion, as I recall, was that there's no significant advantage of = former over the latter, if any advantage at all. =20 Regards, Greg =20 On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson = wrote: Greg, Multiple ideas have been discussed, and no one seems willing to put what = OAM *is* in the NSH draft. =20 So I thought it might be more productive to say what it is not, and gain = a performance benefit of checking a single bit to know whether slow-path = processing is required. =20 -Dave =20 =20 From: Greg Mirsky Sent: Wednesday, February 15, 2017 8:12 PM To: Dave Dolson Cc: adrian@olddog.co.uk; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec =20 Hi Dave,=20 in "without checking next-protocol or searching metadata" you've = expressed common assumption that O-bit indicates two options: * message that immediately follows NSH is OAM message; * one of Variable Length Context Headers carries OAM message. If that is in fact implicit common interpretation of O-bit, then I have = couple questions: * why there's need to use two mechanisms to carry OAM message; * how to avoid unnecessary search through metadata if the message = immediately after NSH is OAM, e.g. BFD control message. I think that it would be much simpler and cleaner if we interpret "OAM = packet" as "message that immediately follows NSH is OAM message" and = indicate this case in NSH Base Header (I prefer use OAM protocol type). = And what is carried in metadata conveyed through Metadata Class and Type = in Variable Context Header. =20 Regards, Greg =20 On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson = wrote: I prefer to think of the inverse: If the O-bit is zero, no functions are required to search the packet for = OAM information. I.e., if O-bit is zero, an SFF may forward the packet on the basis of = SPI/SI without checking next-protocol or searching metadata. I wish the text would actually say that. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, February 15, 2017 4:00 PM To: sfc@ietf.org Subject: [sfc] O-bit behavior in NSH spec Hi, I think it is right that the NSH spec only minimally describe OAM, but I = want to double check the intention of a couple of things here. Section 3.2 says: > O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet. The actual packet format and processing of > SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]). > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. 1. Isn't the first paragraph actually making a decision about the = meaning of the O bit? That is, it is saying that the packet is an OAM packet? Would it be better to defer this type of decisions and say something = a little more vague such as... > O bit: Setting this bit indicates that the NSH packet contains = Operations, > Administration, and Maintenance (OAM) data. The actual packet format > and processing of SFC OAM data and how that data is carried in an NSH > packet is outside the scope of this specification (see > [I-D.ietf-sfc-oam-framework]). 2. Do we really want OAM packets discarded rather than passed through? That substantially minimises the utility of any OAM. Surely we want to specify > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > OAM procedures, SHALL process and forward packets with the O bit set > as normal. Thanks, Adrian _______________________________________________ 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 =20 =20 ------=_NextPart_000_0855_01D28838.CF248970 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

So a high-level question = is:

Will you ever want to include = OAM in an NSH packet that also contains user = data?

 

My impression was that there = was some desire for this.

 

That would certainly = change:

- the use of "next = protocol" to indicate OAM (unless OAM had a recursive next = protocol?)

- how a node that did not = support OAM found the user data

 

It would make of the O flag = more useful.

 

A

 

From: Greg Mirsky = [mailto:gregimirsky@gmail.com]
Sent: 16 February 2017 = 02:21
To: Dave Dolson
Cc: adrian@olddog.co.uk; = sfc@ietf.org
Subject: Re: [sfc] O-bit behavior in NSH = spec

 

Hi = Dave,

I propose to deprecate = O-bit all together and return it in Reserved pool.We had discussion = whether checking value of one bit long flag is more efficient then = checking multi-bit field for particular value. The conclusion, as I = recall, was that there's no significant advantage of former over the = latter, if any advantage at all.

 

Regards,

Greg

 

On Wed, = Feb 15, 2017 at 6:00 PM, Dave Dolson <ddolson@sandvine.com> = wrote:

Greg,

Multiple = ideas have been discussed, and no one seems willing to put what OAM *is* = in the NSH draft.

 

So I thought = it might be more productive to say what it is not, and gain a = performance benefit of checking a single bit to know whether slow-path = processing is required.

 

-Dave

 

 

From: = Greg = Mirsky

Sent: = Wednesday, = February 15, 2017 8:12 PM

To: = Dave = Dolson

Subject: = Re: [sfc] = O-bit behavior in NSH = spec

 

Hi = Dave,

in "without checking next-protocol or searching = metadata" you've expressed common assumption that O-bit indicates = two options:

  • message that immediately follows NSH is OAM = message;
  • one = of Variable Length Context Headers carries OAM = message.

If that is in fact implicit common = interpretation of O-bit, then I have couple = questions:

  • why = there's need to use two mechanisms to carry OAM = message;
  • how = to avoid unnecessary search through metadata if the message immediately = after NSH is OAM, e.g. BFD control = message.

I think that it would be much simpler and = cleaner if we interpret "OAM packet" as "message that = immediately follows NSH is OAM message" and indicate this case in = NSH Base Header (I prefer use OAM protocol type). And what is carried in = metadata conveyed through Metadata Class and Type in Variable Context = Header.

 

Regards,

Greg

 

On Wed, = Feb 15, 2017 at 1:13 PM, Dave Dolson <ddolson@sandvine.com> wrote:

I prefer to think of the inverse:
If the O-bit is = zero, no functions are required to search the packet for OAM = information.
I.e., if O-bit is zero, an SFF may forward the packet on = the basis of SPI/SI without checking next-protocol or searching = metadata.

I wish the text would actually say = that.



-----Original = Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian = Farrel
Sent: Wednesday, February 15, 2017 4:00 PM
To: sfc@ietf.org
Subject: [sfc] O-bit behavior in = NSH spec

Hi,

I think it is right that the NSH spec only = minimally describe OAM, but I want to
double check the intention of a = couple of things here.

Section 3.2 says:

> O bit: = Setting this bit indicates an Operations, Administration, and
> = Maintenance (OAM) packet.  The actual packet format and processing = of
> SFC OAM messages is outside the scope of this specification = (see [I-
> D.ietf-sfc-oam-framework]).
>
> SF/SFF/SFC = Proxy/Classifer implementations, which do not support SFC
> OAM = procedures, SHALL discard packets with O-bit set.

1. Isn't the = first paragraph actually making a decision about the meaning
  =  of the O bit? That is, it is saying that the packet is an OAM = packet?
   Would it be better to defer this type of = decisions and say something a
   little more vague such = as...

> O bit: Setting this bit indicates that the NSH packet = contains Operations,
> Administration, and Maintenance (OAM) = data.  The actual packet format
> and processing of SFC OAM = data and how that data is carried in an NSH
> packet is outside = the scope of this specification (see
> = [I-D.ietf-sfc-oam-framework]).

2. Do we really want OAM packets = discarded rather than passed through?
    That = substantially minimises the utility of any OAM.
    Surely = we want to specify

> SF/SFF/SFC Proxy/Classifier = implementations, that do not support SFC
> OAM procedures, SHALL = process and forward packets with the O bit set
> as = normal.

Thanks,
Adrian

_________________________________= ______________
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

 

 

------=_NextPart_000_0855_01D28838.CF248970-- From nobody Thu Feb 16 05:09:09 2017 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 7DB38129C47 for ; Thu, 16 Feb 2017 05:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 OymouG0b_sVF for ; Thu, 16 Feb 2017 05:09:06 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535CA129CF4 for ; Thu, 16 Feb 2017 05:09:06 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GD93Mw001882 for ; Thu, 16 Feb 2017 13:09:03 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GD8wVN001780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Feb 2017 13:09:03 GMT From: "Adrian Farrel" To: Date: Thu, 16 Feb 2017 13:08:57 -0000 Message-ID: <08bf01d28855$d8a11a00$89e34e00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKIVdQZQUQisgqxTJCy5iNzWDe4qQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22888.006 X-TM-AS-Result: No--14.134-10.0-31-10 X-imss-scan-details: No--14.134-10.0-31-10 X-TMASE-MatchedRID: JkXbjKHw6Vi8eaYomTBk5GjZ8q/Oc1nAZEwsqdFd6DezotxpJhQnAw1K mkMdmvUnIkJJMp14/2PvCwaJ+8u76g7Qbfq/wswqzNY33yIEF4YNmVMWD55fO8z1fqX318VPWKo DKTsuRuR1L+X18ZczPR/Ne6ZdAvcMjE4CeeESgDNNVr4vdmCpzoLsLasl5ROhnSPw4pGdVDwARd T81SrHjsYtOSRj0UCj1vRwxUNeqRVFXAohF8vNJmZUc2jtcaSdu7UEq7BmxZGjQtlWJheV3XwsT 5jF3WC+c6xbnmd9jx0+IJsxz6/MGy/33TWoSUH6SEQN/D/3cG6DddlymG7iSwzvg1/q1MH2Z3KR kLO0vRk0cyESKOBv9AXOZdORTuqr5NfCQaRNDqowKDcSSka1a30tCKdnhB58vqq8s2MNhPDPPeN 6HN6d7N7f/25JKIC+C24oEZ6SpSlND5/KBbSwnO8atudvtZllRmjLeTvAj22z1Eht3fuBNDEeXK pFvHJ/vyQqL+RU6MN+3BndfXUhXQ== Archived-At: Subject: [sfc] New revision: draft-farrel-sfc-convent-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:09:08 -0000 Hi WG, I updated this document after some comments on list and off-list reviews from Eric and Med. Still not sure whether this ends up as a stand-alone document, but I'm currently also using it as a repository for text that has been on list and might get subsumed into the NSH spec at some point. Feel free to criticise and/or hack at the text. Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 16 February 2017 13:04 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrel-sfc-convent-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Operating the Network Service Header (NSH) with Next Protocol > "None" > Authors : Adrian Farrel > Lucy Yong > John Drake > Filename : draft-farrel-sfc-convent-01.txt > Pages : 10 > Date : 2017-02-16 > > Abstract: > This document describes the use of the Network Service Header (NSH) > in a Service Function Chaining (SFC) enabled network with no payload > data and only carrying metadata. This is achieved by defining a new > NSH "Next Protocol" type value of "None". > > This document illustrates some of the functions that may be achieved > or enhanced by this mechanism, but it does not provide an exhaustive > list of use cases, nor is it intended to be definitive about the > functions it describes. It is expected that other documents will > describe specific use cases in more detail and will define the > protocol mechanics for each use case. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-farrel-sfc-convent-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-farrel-sfc-convent-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Feb 16 07:04:14 2017 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 7F6CA129509 for ; Thu, 16 Feb 2017 07:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 a891xLSghMIR for ; Thu, 16 Feb 2017 07:04:10 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 667CC129A1A for ; Thu, 16 Feb 2017 07:04:10 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s186so17831070qkb.1 for ; Thu, 16 Feb 2017 07:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2hUV/UWIuDMRM63sTLWFqu32QnYgnM/vcbk3MMsUAqk=; b=OOI3ytXdxzxvXC+b4aSNlkTkIcIJmPeGQuigAP+sNOaZSjny5svC2az3cyaRTCo1AL 6WZCbewOtUAYLuRFCStEzsv/oOtcKkrooRWDhuyeePngI6H1myZvNbZ476xvPHBbXful LDloQ+/BmHOCJx663k/aCaugAjUZ+d4o7x9PXueMVUsrvTxYg7JfU2IoagsmfbuFm41l 5HjtO7pSii9/cChtVnSdlJMCXbOhVI3TVt4tins28mWJLOAZjbU4t3uVRT7D5s/SaNpl Enkq8tahkbgHxZQCaOswM1yzn+dO9PFaqVGuL+B1lQ5Y7rm0KXJk44s50XUwVXh1kMWC Nvkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=2hUV/UWIuDMRM63sTLWFqu32QnYgnM/vcbk3MMsUAqk=; b=oQJqEh5PTqvqG4KXBKKHFPUpSiUHD7UQmr1jWmC00i6WeVBqlHldd8xWmi6vj9iiIO SgEPDIORU5I+KK4FAk+SnhoB8uZZOjOW86JaEa6+is/PyNWofMcp77Pgj4dwhbOn5xsd dTZZX2/iUQX2IMLBnHOO1mNCgUdt5sibX9ry02AryBewgyZG9a6vnzDIYmCwe8oVoFVc Ji9WdUYe9q0okVNu7cVpPISFOCM1r7fBe6U5zFZQOlofT27d6J8k4zHHRdzAxjNsE4W8 yXd+l37PvaYvk2Ns5kfi/l82AnEGMK3Ix5f0A10JfcSqenJCSOgVmjONL/YzuBW/g3mU zDHA== X-Gm-Message-State: AMke39nwmoWj+vi+SGiDg7u97ZPphiSkOX6NR4OFDaOiRRDT6vEObP1trcJASUwrxWZxF5vthBEscYhkmzEafA== X-Received: by 10.55.144.6 with SMTP id s6mr2785984qkd.140.1487257449256; Thu, 16 Feb 2017 07:04:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.11 with HTTP; Thu, 16 Feb 2017 07:04:08 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?2b7ZiNuM2Kcg2K7Ys9ix2YjbjNin2YYg2K/Zh9qp2LHYr9uMIFBvdXlhIEtob3NyYXZpYW4gRA==?= =?UTF-8?B?ZWhrb3JkaQ==?= Date: Thu, 16 Feb 2017 18:34:08 +0330 Message-ID: To: sfc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c085968f407ae0548a71be7 Archived-At: Subject: [sfc] Fwd: List of Service Function Types X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:04:12 -0000 --94eb2c085968f407ae0548a71be7 Content-Type: text/plain; charset=UTF-8 Hello! I prepared a list of Service Function. Please check which of them are SF or Not. *No* *Service Function* *Y/N* 1 (IDS) Intrusion Detection System / (IPS) Intrusion prevention systems 2 WAN Optimizer 3 Application Delivery Controller (ADC) 4 Firewall 5 Wireless Access Point (WAP) Gateway 6 Packet Data Network (PDN) Gateway 7 Transparent Caching 8 Overlay Transport Virtualization (OTV) 9 TCP Optimizer 10 (DPI) Deep Packet Inspection 11 Content Delivery Network (CDN) 12 IP Reputation 13 Lawful Intercept (LI) 14 (SBC) Session Border Controller 15 Parental Control 16 Virtual Router CE/CPE 17 Virtual Router Reflector 18 Virtual Private LAN Service (VPLS) 19 Network Analysis Module (NAM) 20 Virtual PE/IP Router 21 Wide Area Application Service (WAAS) 22 (AppNav) Deployment of Application Navigator and (AVC) Application Visibility and Control 23 CML(Cisco Modeling lab) and VIRL(Virtual Internet and Routing lab) 24 Dynamic Host Configuration Protocol (DHCP) 25 (IP SLA) Internet protocol service level agreement 26 (VXLAN) Virtual eXtensible Local Area Network 27 Wireless LAN Control 28 Domain Name System (DNS) 29 Virtual eXtensible Local Area Network (VXLAN) 30 (SSL VPN) Secure Sockets Layer virtual private network 31 Virtual Cisco Firepower Next-Generation IPS (vNGIPS) 32 Network address translation (NAT) 33 IPSec VPNs (Flex, Easy, GET) 34 Deep Packet Inspection (DPI) 35 Web Security 36 E-Mail Security 37 Identity Services Engine 38 dynamic multipoint virtual private network (DMVPN) 39 (SSL VPN) Secure Sockets Layer virtual private network 40 Cisco Packet Data Network Gateway (PGW) 41 Proxy 42 Data Loss Prevention (DLP) 43 Open VPN 44 Load Balancer 45 High Availability 46 Virtual Private Network (VPN) 47 NETCONF 48 Network Prefix Translation IPv6-to-IPv6 (NPT) 49 Serving Gateway (SGW) 50 Gateway GPRS Support Node (GGSN) 51 Internet Protocol Security- Gateway (IPsec-GW) 52 video optimizer 53 (BNG) Broadband Network Gateway 54 Content Delivery Optimization 55 Performance-enhancing proxies (PEPs) 56 Web Proxy 57 Distributed Denial of Service (DDOS) 58 Voice Over IP Thank You. Best Regards. PHD Student of Islamic Azad University Yazd Branch Faculty Member of Islamic Azad University Shahrekord Branch Home Page: http://iaushk.ac.ir/part/pages.aspx?id=74&pid=1 Google Citation : http://scholar.google.com/citations?user=ZXfOfdQAAAAJ&hl=en Work Phone: 03833361000 - 403 Cell Phone:09132800436 --94eb2c085968f407ae0548a71be7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello!

I prepared a list of Service Function. Please check wh= ich of them are SF or Not.

=

No

Service Function

Y/N<= /b>

1

(IDS) Intrusion Detection System / (IPS) Intrusion prevention systems

=C2=A0

2

WAN Optimizer

=C2=A0

3

Application Delivery Controller (ADC)

=C2=A0

4

Firewall

=C2=A0

5

Wireless Access Point (WAP) Gateway

=C2=A0

6

Packet Data Network (PDN) Gateway

=C2=A0

7

Transparent Caching<= /span>

=C2=A0

8

Overlay Transport Virtualization (OTV)

=C2=A0

9

TCP Optimizer=

=C2=A0

10

(DPI) Deep Packet Inspection

=C2=A0

11

Content Delivery Network (CDN)

=C2=A0

12

IP Reputation=

=C2=A0

13

Lawful Intercept (LI)

=C2=A0

14

(SBC) Session Border Controller

=C2=A0

15

Parental Control

=C2=A0

16

Virtual Router CE/CPE

=C2=A0

17

Virtual Router Reflector

=C2=A0

18

Virtual Private LAN Service (VPLS)

=C2=A0

19

Network Analysis Module (NAM)

=C2=A0

20

Virtual PE/IP Router=

=C2=A0

21

Wide Area Application Service (WAAS)

=C2=A0

22

(AppNav) Deployment of Application Navigator and (AVC) Application Visibility and Control<= /span>

=C2=A0

23

CML(Cisco Modeling lab) and VIRL(Virtual Internet and Routing lab)

=C2=A0

24

Dynamic Host Configuration Protocol (DHCP)

=C2=A0

25

(IP SLA) =C2=A0Internet protocol = service level agreement

=C2=A0

26

(VXLAN) Virtual eXtensible Local Area Network

=C2=A0

27

Wireless LAN Control=

=C2=A0

28

Domain Name System (DNS)

=C2=A0

29

Virtual eXtensible Local Area Network (VXLAN)

=C2=A0

30

(SSL VPN) =C2=A0Secure Sockets Layer virtual private network

=C2=A0

31

Virtual Cisco Firepower Next-Generation IPS (vNGIPS)

=C2=A0

32

Network address translation (NAT)

=C2=A0

33

IPSec VPNs (Flex, Easy, GET)

=C2=A0

34

Deep Packet Inspection (DPI)

=C2=A0

35

Web Security<= /p>

=C2=A0

36

E-Mail Security

=C2=A0

37

Identity Services Engine

=C2=A0

38

dynamic multipoint virtual private network (DMVPN)

=C2=A0

39

(SSL VPN)=C2=A0 Secure Sockets Layer virtual private network

=C2=A0

40

Cisco Packet Data Network Gateway (PGW)

=C2=A0

41

Proxy

=C2=A0

42

Data Loss Prevention (DLP)

=C2=A0

43

Open VPN

=C2=A0

44

Load Balancer=

=C2=A0

45

High Availability

=C2=A0

46

Virtual Private Network (VPN)

=C2=A0

47

NETCONF

=C2=A0

48

Network Prefix Translation IPv6-to-IPv6 (NPT)

=C2=A0

49

Serving Gateway (SGW)

=C2=A0

50

Gateway GPRS Support Node (GGSN)

=C2=A0

51

Internet Protocol Security- Gateway (IPsec-GW)

=C2=A0

52

video optimizer

=C2=A0

53

(BNG) Broadband Network Gateway

=C2=A0

54

Content Delivery Optimization

=C2=A0

55

Performance-enhancing proxies (PEPs)

=C2=A0

56

Web Proxy

=C2=A0

57

Distributed Denial of Service (DDOS)

=C2=A0

58

Voice Over IP

=C2=A0
Thank You.
Best Regards.

PHD Student of Islamic Azad University Yazd Branch
Faculty Member of Islamic Azad University = Shahrekord Branch
Home Page:
<= a href=3D"http://iaushk.ac.ir/part/pages.aspx?id=3D74&pid=3D1" target= =3D"_blank">http://iaushk.ac.ir/part/pages.aspx?id=3D74&pid=3D1
Google Citation :
http://scholar.google.com= /citations?user=3DZXfOfdQAAAAJ&hl=3Den
Work Phone: 03833361000 - 403
C= ell Phone:09132800436




--94eb2c085968f407ae0548a71be7-- From nobody Thu Feb 16 08:04:02 2017 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 6FF3F129D77 for ; Thu, 16 Feb 2017 08:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 SR2UBC66nKjl for ; Thu, 16 Feb 2017 08:03:59 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCFC129D6E for ; Thu, 16 Feb 2017 08:03:58 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 493AC1005D3; Thu, 16 Feb 2017 17:03:57 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 26008180073; Thu, 16 Feb 2017 17:03:57 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 17:03:56 +0100 From: To: "Paul Quinn (paulq)" , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sfc-nsh-11.txt Thread-Index: AQHShlBkUCIc1jOOIUqdPqawp9G6OaFrzs4w Date: Thu, 16 Feb 2017 16:03:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E138E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <148702829421.22233.782542928593751229.idtracker@ietfa.amsl.com> <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> In-Reply-To: <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E138E4OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:04:00 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E138E4OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, Thank you for the update. I'm afraid the agreed text (the one to be added to Section 3.5.1) as record= ed in https://trac.ietf.org/trac/sfc/ticket/21 was not integrated in this r= evision. Can you please fix that? Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Paul Quinn (paulq) Envoy=E9 : mardi 14 f=E9vrier 2017 00:30 =C0 : sfc@ietf.org Objet : [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-11.txt Folks, This version integrates: - Much of the email thread with Alia re: her AD review of the draft. There= still might be a few minor items that need to be updated (e.g. some of the= IETF vs. expert review for registries) - The changes summarized by the chairs (https://mailarchive.ietf.org/arch/m= sg/sfc/03g2WEAeID_XIQgsFOZxD-diqQU/?qid=3D4eda91ca1d7acd135b12947201b6547a) - Some minor editorial changes Paul Begin forwarded message: From: > Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt Date: February 13, 2017 at 6:24:54 PM EST To: Uri Elzur >, Paul Quinn= > A new version of I-D, draft-ietf-sfc-nsh-11.txt has been successfully submitted by Paul Quinn and posted to the IETF repository. Name: draft-ietf-sfc-nsh Revision: 11 Title: Network Service Header Document date: 2017-02-12 Group: sfc Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.= txt Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-11 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_787AE7BB302AE849A7480A190F8B933009E138E4OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

Thank you for the update.

 

I’m afraid the agreed tex= t (the one to be added to Section 3.5.1) as recorded in https://trac.ietf.org/= trac/sfc/ticket/21 was not integrated in this revision. Can you please = fix that?

 

Cheers,

Med

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Paul Quinn (paulq)
Envoy=E9 : mardi 14 f=E9vrier 2017 00:30
=C0 : sfc@ietf.org
Objet : [sfc] Fwd: New Version Notification for draft-ietf-sfc-= nsh-11.txt

 

Folks,

 

This version integrates:

 

- Much of the email thread with Alia re: her AD revi= ew of the draft.  There still might be a few minor items that need to = be updated (e.g. some of the IETF vs. expert review for registries)

- Some minor editorial changes

 

Paul

 



Begin forwarded message:

 

Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt

Date: February 13, 2017 at 6:24:54 PM EST

 


A new version of I-D, draft-ietf-sfc-nsh-11.txt
has been successfully submitted by Paul Quinn and posted to the
IETF repository.

Name: draft-ietf-sfc-nsh
Revision: 11
Title: Network Service Header
Document date: 2017-02-12
Group: sfc
Pages: 37
URL:            http= s://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.txt
Status:         https://datatracker.ietf.org/= doc/draft-ietf-sfc-nsh/
Htmlized:       https://tools.ietf.org/html/draft-ietf-sfc= -nsh-11
Diff:           https://www.= ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11

Abstract:
  This document describes a Network Service Header (NSH) inserted= onto
  packets or frames to realize service function paths.  NSH = also
  provides a mechanism for metadata exchange along the instantiat= ed
  service path.  NSH is the SFC encapsulation required to su= pport the
  Service Function Chaining (SFC) Architecture (defined in RFC766= 5).




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

The IETF Secretariat

 

--_000_787AE7BB302AE849A7480A190F8B933009E138E4OPEXCLILMA3corp_-- From nobody Thu Feb 16 09:07:05 2017 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 C772E129663 for ; Thu, 16 Feb 2017 09:07:02 -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 c1VlHDBv8jnZ for ; Thu, 16 Feb 2017 09:06:57 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 0F2431297AC for ; Thu, 16 Feb 2017 09:06:57 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id 73so15300231otj.0 for ; Thu, 16 Feb 2017 09:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=038j3pJ/DGx73N7Lm4MxUx/pvKOxTwNNUzu+FE2gz9w=; b=OvQSuO9Ll5HQf9kFye+/BNbWcbl0gUUUMUppsNnj7Z3WR+W4nVtHBUQHq9VfBgQgLR /4gjX5PvTj/ENfse/uUy4Di9a4+Idmazt3LOiPBl8e5FjYPnX+oJIsF4rXMqfamBOXpy uVlT2LKQ61FsGC9l4wisIWongi0bEC7jY5yBrxBbo8mkSrr3+pLtQ6JvoSeEMCZ1x8h/ n9XetQc2KM48wzAeeSQmriFue0+vjV08g71mqarIR/9XDWzhW0o9WOeGBAuf8u1/B2CK dTe4XYt6LqKGQnlGYQeuJbGMJHknooAglutMacpf2T+KWw5yxveprXQi4iIBGGHZZXUN Japw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=038j3pJ/DGx73N7Lm4MxUx/pvKOxTwNNUzu+FE2gz9w=; b=qnZza1nSR8k76/JoOntVZGNOYfkIpNe53H2aFmxdEJuxwkMeZT/uvjtE2tsI8hT8fg vRfsLTtRH/wG96cpoRRDqticdCQyBAFzrui4Yh1TFt1BrQyKydNOE452ssvUXcqIr8yf j1APFMUQr0omVSMN3A3lQYJ927Fo571CHste3h856INIIePOjDdECrF8uvnXdtINOxTr AU7jlgLolQfp93wu+fGDMQSHFf4SoaOkqugUXB1ZIJ7yMB1uXI/3Va4ddIWx7EqA899V nk47qcwEXeAYPjm7Gyk6RyIq+NklCbyfgStXAQ5RrwstwTdwCMT1HUq9hBZfgikywdps VhCg== X-Gm-Message-State: AMke39luNza3xGIEDB/Toa9hIg9+HB7iX38F0NtMhxtEwL03hm12/Hq/ueVxQ/m4N9mMcA8i84D/4/awdNmksA== X-Received: by 10.157.16.9 with SMTP id h9mr1635345ote.40.1487264816357; Thu, 16 Feb 2017 09:06:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Thu, 16 Feb 2017 09:06:55 -0800 (PST) In-Reply-To: <085401d28838$cf1dd2b0$6d597810$@olddog.co.uk> References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <20170216020055.8495190.89878.137349@sandvine.com> <085401d28838$cf1dd2b0$6d597810$@olddog.co.uk> From: Greg Mirsky Date: Thu, 16 Feb 2017 09:06:55 -0800 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a11402c0210e7be0548a8d37f Archived-At: Cc: sfc@ietf.org, Dave Dolson Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:07:03 -0000 --001a11402c0210e7be0548a8d37f Content-Type: text/plain; charset=UTF-8 Hi Adrian, the proposed Overlay OAM header has Length field that reflects the length of the OAM message and Next Protocol field. I believe that Overlay OAM Header supports all scenarios for OAM, with and without user data, in simple consistent manner. Regards, Greg On Thu, Feb 16, 2017 at 1:41 AM, Adrian Farrel wrote: > So a high-level question is: > > Will you ever want to include OAM in an NSH packet that also contains user > data? > > > > My impression was that there was some desire for this. > > > > That would certainly change: > > - the use of "next protocol" to indicate OAM (unless OAM had a recursive > next protocol?) > > - how a node that did not support OAM found the user data > > > > It would make of the O flag more useful. > > > > A > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* 16 February 2017 02:21 > > *To:* Dave Dolson > *Cc:* adrian@olddog.co.uk; sfc@ietf.org > *Subject:* Re: [sfc] O-bit behavior in NSH spec > > > > Hi Dave, > > I propose to deprecate O-bit all together and return it in Reserved > pool.We had discussion whether checking value of one bit long flag is more > efficient then checking multi-bit field for particular value. The > conclusion, as I recall, was that there's no significant advantage of > former over the latter, if any advantage at all. > > > > Regards, > > Greg > > > > On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson wrote: > > Greg, > > Multiple ideas have been discussed, and no one seems willing to put what > OAM *is* in the NSH draft. > > > > So I thought it might be more productive to say what it is not, and gain a > performance benefit of checking a single bit to know whether slow-path > processing is required. > > > > -Dave > > > > > > *From: *Greg Mirsky > > *Sent: *Wednesday, February 15, 2017 8:12 PM > > *To: *Dave Dolson > > *Cc: *adrian@olddog.co.uk; sfc@ietf.org > > *Subject: *Re: [sfc] O-bit behavior in NSH spec > > > > Hi Dave, > > in "without checking next-protocol or searching metadata" you've > expressed common assumption that O-bit indicates two options: > > - message that immediately follows NSH is OAM message; > - one of Variable Length Context Headers carries OAM message. > > If that is in fact implicit common interpretation of O-bit, then I have > couple questions: > > - why there's need to use two mechanisms to carry OAM message; > - how to avoid unnecessary search through metadata if the message > immediately after NSH is OAM, e.g. BFD control message. > > I think that it would be much simpler and cleaner if we interpret "OAM > packet" as "message that immediately follows NSH is OAM message" and > indicate this case in NSH Base Header (I prefer use OAM protocol type). And > what is carried in metadata conveyed through Metadata Class and Type in > Variable Context Header. > > > > Regards, > > Greg > > > > On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson wrote: > > I prefer to think of the inverse: > If the O-bit is zero, no functions are required to search the packet for > OAM information. > I.e., if O-bit is zero, an SFF may forward the packet on the basis of > SPI/SI without checking next-protocol or searching metadata. > > I wish the text would actually say that. > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, February 15, 2017 4:00 PM > To: sfc@ietf.org > Subject: [sfc] O-bit behavior in NSH spec > > Hi, > > I think it is right that the NSH spec only minimally describe OAM, but I > want to > double check the intention of a couple of things here. > > Section 3.2 says: > > > O bit: Setting this bit indicates an Operations, Administration, and > > Maintenance (OAM) packet. The actual packet format and processing of > > SFC OAM messages is outside the scope of this specification (see [I- > > D.ietf-sfc-oam-framework]). > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > > OAM procedures, SHALL discard packets with O-bit set. > > 1. Isn't the first paragraph actually making a decision about the meaning > of the O bit? That is, it is saying that the packet is an OAM packet? > Would it be better to defer this type of decisions and say something a > little more vague such as... > > > O bit: Setting this bit indicates that the NSH packet contains > Operations, > > Administration, and Maintenance (OAM) data. The actual packet format > > and processing of SFC OAM data and how that data is carried in an NSH > > packet is outside the scope of this specification (see > > [I-D.ietf-sfc-oam-framework]). > > 2. Do we really want OAM packets discarded rather than passed through? > That substantially minimises the utility of any OAM. > Surely we want to specify > > > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > > OAM procedures, SHALL process and forward packets with the O bit set > > as normal. > > Thanks, > Adrian > > _______________________________________________ > 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 > > > > > --001a11402c0210e7be0548a8d37f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,
the proposed Overlay OAM header=C2=A0has= Length field that reflects the length of the OAM message and Next Protocol= field.
I believe that Overlay OAM Header supports all scenarios = for OAM, with and without user data, in simple consistent manner.

Regards,
Greg

On Thu, Feb 16, 2017 at 1:41 AM, Adrian F= arrel <adrian@olddog.co.uk> wrote:

So a high-level question is:

Will you ever want to include O= AM in an NSH packet that also contains user data?

<= p class=3D"MsoNormal">=C2=A0

My impression was th= at there was some desire for this.

=C2=A0

That would certainly change:

- the= use of "next protocol" to indicate OAM (unless OAM had a recursi= ve next protocol?)

- how a node that did not support OAM found the user data=

= =C2=A0

It would make of the O flag more useful.

=C2=A0

A<= /p>

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.c= om]
Sent: 16 February 2017 02:21


To: Dave Dolson
Cc: adrian@olddog.co.uk; sfc@ietf.org
Subject: Re: [sfc= ] O-bit behavior in NSH spec

=C2=A0

Hi Dave,

= I propose to deprecate O-bit all together and return it in Reserved pool.We= had discussion whether checking value of one bit long flag is more efficie= nt then checking multi-bit field for particular value. The conclusion, as I= recall, was that there's no significant advantage of former over the l= atter, if any advantage at all.

=C2=A0

Regards,<= u>

Greg

=C2=A0

On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson <ddolson@sandvine.com>= wrote:

Greg,

Multiple ideas have been disc= ussed, and no one seems willing to put what OAM *is* in the NSH draft.

=C2=A0

So I thought it might be more pr= oductive to say what it is not, and gain a performance benefit of checking = a single bit to know whether slow-path processing is required.

=C2=A0

-Dave

=C2=A0<= u>

=C2=A0

From: Greg Mirsky

Sent: Wednesday, February 15, 201= 7 8:12 PM

To: Dave Dolson

Subjec= t: Re: [sfc] O-bit behavior in NSH spec

=C2=A0

Hi Dave, <= u>

in "without checking next-protocol or searching metadata" you&#= 39;ve expressed common assumption that O-bit indicates two options:<= u>

  • message that immediately follows NSH is OAM mess= age;
  • one of Variable Length Context Headers carries OAM message.

If that is in fact implicit common interpretation of O-bit, then I ha= ve couple questions:

    <= li class=3D"MsoNormal">why there's need= to use two mechanisms to carry OAM message;
  • how to avoid unnecessary= search through metadata if the message immediately after NSH is OAM, e.g. = BFD control message.

I think that it would be much simpler a= nd cleaner if we interpret "OAM packet" as "message that imm= ediately follows NSH is OAM message" and indicate this case in NSH Bas= e Header (I prefer use OAM protocol type). And what is carried in metadata = conveyed through Metadata Class and Type in Variable Context Header.=

=C2=A0<= /u>

Re= gards,

Greg

=C2=A0

On Wed,= Feb 15, 2017 at 1:13 PM, Dave Dolson <ddolson@sandvine.com> wrote:<= /p>

I prefer to think of the inverse:
If the O-bit= is zero, no functions are required to search the packet for OAM informatio= n.
I.e., if O-bit is zero, an SFF may forward the packet on the basis of= SPI/SI without checking next-protocol or searching metadata.

I wish= the text would actually say that.



-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org= ] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 4:00 PM<= br>To: sfc@ietf.orgSubject: [sfc] O-bit behavior in NSH spec

Hi,

I think it is= right that the NSH spec only minimally describe OAM, but I want to
doub= le check the intention of a couple of things here.

Section 3.2 says:=

> O bit: Setting this bit indicates an Operations, Administratio= n, and
> Maintenance (OAM) packet.=C2=A0 The actual packet format and= processing of
> SFC OAM messages is outside the scope of this specif= ication (see [I-
> D.ietf-sfc-oam-framework]).
>
> SF/SFF= /SFC Proxy/Classifer implementations, which do not support SFC
> OAM = procedures, SHALL discard packets with O-bit set.

1. Isn't the f= irst paragraph actually making a decision about the meaning
=C2=A0 =C2= =A0of the O bit? That is, it is saying that the packet is an OAM packet?=C2=A0 =C2=A0Would it be better to defer this type of decisions and say so= mething a
=C2=A0 =C2=A0little more vague such as...

> O bit: S= etting this bit indicates that the NSH packet contains Operations,
> = Administration, and Maintenance (OAM) data.=C2=A0 The actual packet format<= br>> and processing of SFC OAM data and how that data is carried in an N= SH
> packet is outside the scope of this specification (see
> [= I-D.ietf-sfc-oam-framework]).

2. Do we really want OAM packets disca= rded rather than passed through?
=C2=A0 =C2=A0 That substantially minimi= ses the utility of any OAM.
=C2=A0 =C2=A0 Surely we want to specify
<= br>> SF/SFF/SFC Proxy/Classifier implementations, that do not support SF= C
> OAM procedures, SHALL process and forward packets with the O bit = set
> as normal.

Thanks,
Adrian

____________________= ___________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailma= n/listinfo/sfc

_______________________________________= ________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc<= u>

=C2=A0<= /u>

= =C2=A0

--001a11402c0210e7be0548a8d37f-- From nobody Thu Feb 16 09:20:20 2017 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 F2101129483 for ; Thu, 16 Feb 2017 09:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 Hdj5vFep2R5v for ; Thu, 16 Feb 2017 09:20:16 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 6425A126CD8 for ; Thu, 16 Feb 2017 09:20:16 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id j15so12142707oih.2 for ; Thu, 16 Feb 2017 09:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h0K2/SqNjTHHkmnwbqO+iZxAspOQmMgbMG+s1CIR4uI=; b=ZhsmxyPTXRbw6BsP6oD9qRXIsUponcRuqBYMdZqochurrJ+voelnpzRCnZSS+KsqTV 9MurjGb9KPX2uzlrbtMfXslx74Gx9rnV1gnYSyHp1VugIpdVldLe0fGLG8xiVjVdmpkf xjXVq4QXyoUPf4wsm9cf8NuuhsvGT7Y+yFUgaA+U98XW2FAWNkBLHRV3sU9imZug8k8g DsU1pY3HxNxvOldG5jg3i5Qd1q/ep422t3s9xGHbg1kRFym2IxNmWrNcwq8VpbPazoJV YLVevdQzeFEg9Mk4+Jo5zsByOjIjRJR4c7mVUWVcSs5kuGVWKIPGlKtuTkLRJsX3sp2h yjxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h0K2/SqNjTHHkmnwbqO+iZxAspOQmMgbMG+s1CIR4uI=; b=onFoTqeRg3Pf3lAwxa9k1TKG4Rx8LF/EqGPfh+gI9HIkvvFQbynQWbU+1YTn406+eg 0L9G3u+9piCrZBDiLryEUCDMh//Fr3WCcfVWQfukP9nQSZXlmBgtt8FeqZRSA//yvRIx GG962eD04xmlJ9mgZa7sxyJpLnUXPZuv41sDfKKS4EWqsYVIU5Zhf0GGE3++m3vh39uP BEy4BoWWOCoPIG0rZiH6ChckeInRPDVYkLR1sRwe1M1pcR7Hjmnl2p2SJmplqBGb4UUo e2fCihhwJQQGWAU1ux9b/Zy839bD+cPBTFq5D+ne4keL12qXHrcyuVKUAlGeNOWVB54k N3qw== X-Gm-Message-State: AMke39l59DTpbEleznS7IGCZyloq9lS+QmwssNqw6/iHSMG9UyidlO89hdxI8jHqsLgxcdHPqbIhS904fDyvVA== X-Received: by 10.202.172.136 with SMTP id v130mr1854523oie.167.1487265615628; Thu, 16 Feb 2017 09:20:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Thu, 16 Feb 2017 09:20:15 -0800 (PST) In-Reply-To: <098401d28878$6d4076c0$47c16440$@olddog.co.uk> References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <20170216020055.8495190.89878.137349@sandvine.com> <085401d28838$cf1dd2b0$6d597810$@olddog.co.uk> <098401d28878$6d4076c0$47c16440$@olddog.co.uk> From: Greg Mirsky Date: Thu, 16 Feb 2017 09:20:15 -0800 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113ce9bcb4d0790548a902fc Archived-At: Cc: sfc@ietf.org, Dave Dolson Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:20:19 -0000 --001a113ce9bcb4d0790548a902fc Content-Type: text/plain; charset=UTF-8 Hi Adrian, but we can re-word text in NSH document. Alternative, as I see it, would be to embed OAM in NSH. Regards, Greg On Thu, Feb 16, 2017 at 9:16 AM, Adrian Farrel wrote: > Except that it requires a node that does not support OAM to act as > currently described in the NSH spec and drop packets containing OAM. > > I think this is a draw-back > > > > Adrian > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* 16 February 2017 17:07 > *To:* Adrian Farrel > *Cc:* Dave Dolson; sfc@ietf.org > > *Subject:* Re: [sfc] O-bit behavior in NSH spec > > > > Hi Adrian, > > the proposed Overlay OAM header > has > Length field that reflects the length of the OAM message and Next Protocol > field. > > I believe that Overlay OAM Header supports all scenarios for OAM, with and > without user data, in simple consistent manner. > > > > Regards, > > Greg > > > > On Thu, Feb 16, 2017 at 1:41 AM, Adrian Farrel > wrote: > > So a high-level question is: > > Will you ever want to include OAM in an NSH packet that also contains user > data? > > > > My impression was that there was some desire for this. > > > > That would certainly change: > > - the use of "next protocol" to indicate OAM (unless OAM had a recursive > next protocol?) > > - how a node that did not support OAM found the user data > > > > It would make of the O flag more useful. > > > > A > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* 16 February 2017 02:21 > > > *To:* Dave Dolson > *Cc:* adrian@olddog.co.uk; sfc@ietf.org > *Subject:* Re: [sfc] O-bit behavior in NSH spec > > > > Hi Dave, > > I propose to deprecate O-bit all together and return it in Reserved > pool.We had discussion whether checking value of one bit long flag is more > efficient then checking multi-bit field for particular value. The > conclusion, as I recall, was that there's no significant advantage of > former over the latter, if any advantage at all. > > > > Regards, > > Greg > > > > On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson wrote: > > Greg, > > Multiple ideas have been discussed, and no one seems willing to put what > OAM *is* in the NSH draft. > > > > So I thought it might be more productive to say what it is not, and gain a > performance benefit of checking a single bit to know whether slow-path > processing is required. > > > > -Dave > > > > > > *From: *Greg Mirsky > > *Sent: *Wednesday, February 15, 2017 8:12 PM > > *To: *Dave Dolson > > *Cc: *adrian@olddog.co.uk; sfc@ietf.org > > *Subject: *Re: [sfc] O-bit behavior in NSH spec > > > > Hi Dave, > > in "without checking next-protocol or searching metadata" you've > expressed common assumption that O-bit indicates two options: > > - message that immediately follows NSH is OAM message; > - one of Variable Length Context Headers carries OAM message. > > If that is in fact implicit common interpretation of O-bit, then I have > couple questions: > > - why there's need to use two mechanisms to carry OAM message; > - how to avoid unnecessary search through metadata if the message > immediately after NSH is OAM, e.g. BFD control message. > > I think that it would be much simpler and cleaner if we interpret "OAM > packet" as "message that immediately follows NSH is OAM message" and > indicate this case in NSH Base Header (I prefer use OAM protocol type). And > what is carried in metadata conveyed through Metadata Class and Type in > Variable Context Header. > > > > Regards, > > Greg > > > > On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson wrote: > > I prefer to think of the inverse: > If the O-bit is zero, no functions are required to search the packet for > OAM information. > I.e., if O-bit is zero, an SFF may forward the packet on the basis of > SPI/SI without checking next-protocol or searching metadata. > > I wish the text would actually say that. > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, February 15, 2017 4:00 PM > To: sfc@ietf.org > Subject: [sfc] O-bit behavior in NSH spec > > Hi, > > I think it is right that the NSH spec only minimally describe OAM, but I > want to > double check the intention of a couple of things here. > > Section 3.2 says: > > > O bit: Setting this bit indicates an Operations, Administration, and > > Maintenance (OAM) packet. The actual packet format and processing of > > SFC OAM messages is outside the scope of this specification (see [I- > > D.ietf-sfc-oam-framework]). > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > > OAM procedures, SHALL discard packets with O-bit set. > > 1. Isn't the first paragraph actually making a decision about the meaning > of the O bit? That is, it is saying that the packet is an OAM packet? > Would it be better to defer this type of decisions and say something a > little more vague such as... > > > O bit: Setting this bit indicates that the NSH packet contains > Operations, > > Administration, and Maintenance (OAM) data. The actual packet format > > and processing of SFC OAM data and how that data is carried in an NSH > > packet is outside the scope of this specification (see > > [I-D.ietf-sfc-oam-framework]). > > 2. Do we really want OAM packets discarded rather than passed through? > That substantially minimises the utility of any OAM. > Surely we want to specify > > > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > > OAM procedures, SHALL process and forward packets with the O bit set > > as normal. > > Thanks, > Adrian > > _______________________________________________ > 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 > > > > > > > --001a113ce9bcb4d0790548a902fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,
but we can re-word text in NSH document. Al= ternative, as I see it, would be to embed OAM in NSH.

<= div>Regards,
Greg

On Thu, Feb 16, 2017 at 9:16 AM, Adrian Farrel <ad= rian@olddog.co.uk> wrote:
<= div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">

= Except that it requires a node that does not support OAM to act as currentl= y described in the NSH spec and drop packets containing OAM.<= /span>

I think this is= a draw-back

=C2=A0

Adrian

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: 16 F= ebruary 2017 17:07
To: Adrian Farrel
Cc: Dave Dolson; <= a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org


Subject: Re: [sfc] O-bit behavior in NSH= spec

=C2=A0

Hi= Adrian,

the proposed Overlay OAM header=C2=A0has Length field that reflects the = length of the OAM message and Next Protocol field.

<= div>

I believe that Overlay OAM Header supports all s= cenarios for OAM, with and without user data, in simple consistent manner.<= u>

=C2=A0

=

Regards,

Greg

=C2=A0

On Thu, Feb 16, 2= 017 at 1:41 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

So a high-level questi= on is:

Will you ever want to include OAM in an NSH packet that also contains= user data?

=C2=A0

My impression was that there was some desire for this.

=C2= =A0

That would certainly change:

- the use of "next protocol" to in= dicate OAM (unless OAM had a recursive next protocol?)=

- how a node that did= not support OAM found the user data

=C2=A0

It would make of the O flag more = useful.

=C2=A0

A

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: 16 February = 2017 02:21


= To: Dave Dolson
Cc: adrian@olddog.co.uk; sfc@ietf.org
Subject: Re: [sfc] O-bit behavio= r in NSH spec

=C2=A0

Hi Dave,=

I propose to deprecate O-bit = all together and return it in Reserved pool.We had discussion whether check= ing value of one bit long flag is more efficient then checking multi-bit fi= eld for particular value. The conclusion, as I recall, was that there's= no significant advantage of former over the latter, if any advantage at al= l.

=C2=A0<= /p>

Regards,

<= p class=3D"MsoNormal">Greg

=C2=A0

On Wed, Feb 15= , 2017 at 6:00 PM, Dave Dolson <ddolson@sandvine.com> wrote:

Greg,

Multiple ideas have been discussed, and no one seems willi= ng to put what OAM *is* in the NSH draft.

=C2=A0=

So I thought it might be more productive to say what it is no= t, and gain a performance benefit of checking a single bit to know whether = slow-path processing is required.

=C2=A0<= u>

-Dave

=C2=A0

<= p class=3D"MsoNormal" style=3D"background:white">=C2=A0=

=

From: Greg Mirsky

Sent: Wednesday, February 15, 2017 8:12 PM

To: Dave Dolson

Subject: Re:= [sfc] O-bit behavior in NSH spec

=C2=A0<= /p>

Hi Dave,

in "without checking n= ext-protocol or searching metadata" you've expressed common assump= tion that O-bit indicates two options:

<= ul type=3D"disc">
  • me= ssage that immediately follows NSH is OAM message;
  • one of Variable Le= ngth Context Headers carries OAM message.

    • If that is in fact impl= icit common interpretation of O-bit, then I have couple questions:

    • why there's need to use two mechanisms to car= ry OAM message;
    • how to avoid unnecessary search through metadata if t= he message immediately after NSH is OAM, e.g. BFD control message.

    I think that it would be much simpler and cleaner if we interpret &q= uot;OAM packet" as "message that immediately follows NSH is OAM m= essage" and indicate this case in NSH Base Header (I prefer use OAM pr= otocol type). And what is carried in metadata conveyed through Metadata Cla= ss and Type in Variable Context Header.

    =C2=A0

    Regards,

    Greg

    =C2=A0=

    On Wed, Feb 15, 2017 at 1:13 PM, Dav= e Dolson <ddol= son@sandvine.com> wrote:

    I p= refer to think of the inverse:
    If the O-bit is zero, no functions are re= quired to search the packet for OAM information.
    I.e., if O-bit is zero,= an SFF may forward the packet on the basis of SPI/SI without checking next= -protocol or searching metadata.

    I wish the text would actually say = that.



    -----Origin= al Message-----
    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian FarrelSent: Wednesday, February 15, 2017 4:00 PM
    To: sfc@ietf.org
    Subject: [sfc] O-bit behavior= in NSH spec

    Hi,

    I think it is right that the NSH spec only m= inimally describe OAM, but I want to
    double check the intention of a cou= ple of things here.

    Section 3.2 says:

    > O bit: Setting thi= s bit indicates an Operations, Administration, and
    > Maintenance (OAM= ) packet.=C2=A0 The actual packet format and processing of
    > SFC OAM = messages is outside the scope of this specification (see [I-
    > D.ietf= -sfc-oam-framework]).
    >
    > SF/SFF/SFC Proxy/Classifer implementa= tions, which do not support SFC
    > OAM procedures, SHALL discard packe= ts with O-bit set.

    1. Isn't the first paragraph actually making = a decision about the meaning
    =C2=A0 =C2=A0of the O bit? That is, it is s= aying that the packet is an OAM packet?
    =C2=A0 =C2=A0Would it be better = to defer this type of decisions and say something a
    =C2=A0 =C2=A0little = more vague such as...

    > O bit: Setting this bit indicates that th= e NSH packet contains Operations,
    > Administration, and Maintenance (= OAM) data.=C2=A0 The actual packet format
    > and processing of SFC OAM= data and how that data is carried in an NSH
    > packet is outside the = scope of this specification (see
    > [I-D.ietf-sfc-oam-framework]).
    =
    2. Do we really want OAM packets discarded rather than passed through?<= br>=C2=A0 =C2=A0 That substantially minimises the utility of any OAM.
    = =C2=A0 =C2=A0 Surely we want to specify

    > SF/SFF/SFC Proxy/Classi= fier implementations, that do not support SFC
    > OAM procedures, SHALL= process and forward packets with the O bit set
    > as normal.

    T= hanks,
    Adrian

    ______________________________________________= _
    sfc mailing list
    = sfc@ietf.org
    https://www.ietf.org/mailman/listinfo/sfc

    = _______________________________________________
    sfc mailing listsfc@ietf.org
    https:/= /www.ietf.org/mailman/listinfo/sfc

    =C2=A0

    =

    =C2=A0

    =C2=A0


    --001a113ce9bcb4d0790548a902fc-- From nobody Thu Feb 16 09:24:48 2017 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 66571127077 for ; Thu, 16 Feb 2017 09:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWgMW1v-r486 for ; Thu, 16 Feb 2017 09:24:41 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1CE12964F for ; Thu, 16 Feb 2017 09:16:40 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GHGb4O025161; Thu, 16 Feb 2017 17:16:37 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GHGXRS025128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2017 17:16:35 GMT From: "Adrian Farrel" To: "'Greg Mirsky'" References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <20170216020055.8495190.89878.137349@sandvine.com> <085401d28838$cf1dd2b0$6d597810$@olddog.co.uk> In-Reply-To: Date: Thu, 16 Feb 2017 17:16:29 -0000 Message-ID: <098401d28878$6d4076c0$47c16440$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0985_01D28878.6D464320" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKs4QfPsAfGu+IdxTavj2M4SM8+/wH6B6zrApUMVOEC4N2N+gHz78PHAx+YWP0BgzipDZ9G+NRQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22890.000 X-TM-AS-Result: No--24.264-10.0-31-10 X-imss-scan-details: No--24.264-10.0-31-10 X-TMASE-MatchedRID: JorHcieTUslbJCKOm3VRCXPH2ClDM6ZEr5qahUVerFxUvuFi0BemlpNC FJkTKtUhnVzTgrSv7smdVNZaI2n6//riLmWBrDIEsp5O052MzLr74EoM4qsMf83DBOwul+3LIog 2od+iX+fTo/qcrjih0ARH1Nr7oERdf7rvXBvEkWkbQ3XP/Jy4ss+cwCLpvDnE9xpAIriy0MTtPO cFA7ylRzfU8/vod2Mhws9cphnKwlEfXzVgO0hVqhER5MrEGoh5srOkjdJDOwERIyUkqDWF0R9t1 SsUm6bnUjeY/xoLQ8HUlwLB9WSL1JsqkCVjbLpJ/mFoFIdH1tKbbDaZvEixyQOFhQFE3BP66Zzb Wd4WqZSH6FJxCilEmR3EEAbn+GRbfkSt9GqmKVWjC1E/zCEIr/lFKh61mxmMXUuWQ64OEIPkKxa e3huKX9cUNjoF7YuVSHCU59h5KrHJ5SXtoJPLyOcmA1UeESs0KPndoQHmoMtdyNy8gKRdJjUXeM xF94l7ubR55ixr98dUXvI6K7irafadDzLnUoyl31GU/N5W5BDdrgb7DovExLPZYjNFubUuto6XA LfsscXvXvInwhwK20K9qlwiTElfdZPoD9V2prR0PA/ki2kI7EtU4/pKr/oblbuU0VRkgxHbWjfF UhEL88NYV73vYBFQjtK7dC6UBnkUqWKocoJo6esoDDE6CvPdp4WcmyqBbFxC3bjvSDu95yxaLix dyIaFPwbcb/CNUOlwvDydhBUuyCAXLFyLhL5W5GdZsk1yqBcqoeXFMnt4lSJunynLhcivKEdCtw yfJsLWV8MKb34RlRZU/yoIC8o9zgMwzBVI5+ybKItl61J/yZUdXE/WGn0FVoTa5lFknUGHHQtvy gWztFjVWFnWzmjaZJ4EPl3y7BDwMWotajB3hp7aCPckAh0Lwqwy+L0ksig= Archived-At: Cc: sfc@ietf.org, 'Dave Dolson' Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:24:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0985_01D28878.6D464320 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Except that it requires a node that does not support OAM to act as = currently described in the NSH spec and drop packets containing OAM. I think this is a draw-back =20 Adrian =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: 16 February 2017 17:07 To: Adrian Farrel Cc: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec =20 Hi Adrian, the proposed Overlay OAM header = has = Length field that reflects the length of the OAM message and Next = Protocol field. I believe that Overlay OAM Header supports all scenarios for OAM, with = and without user data, in simple consistent manner. =20 Regards, Greg =20 On Thu, Feb 16, 2017 at 1:41 AM, Adrian Farrel = wrote: So a high-level question is: Will you ever want to include OAM in an NSH packet that also contains = user data? =20 My impression was that there was some desire for this. =20 That would certainly change: - the use of "next protocol" to indicate OAM (unless OAM had a recursive = next protocol?) - how a node that did not support OAM found the user data =20 It would make of the O flag more useful. =20 A =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: 16 February 2017 02:21 To: Dave Dolson Cc: adrian@olddog.co.uk; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec =20 Hi Dave, I propose to deprecate O-bit all together and return it in Reserved = pool.We had discussion whether checking value of one bit long flag is = more efficient then checking multi-bit field for particular value. The = conclusion, as I recall, was that there's no significant advantage of = former over the latter, if any advantage at all. =20 Regards, Greg =20 On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson = wrote: Greg, Multiple ideas have been discussed, and no one seems willing to put what = OAM *is* in the NSH draft. =20 So I thought it might be more productive to say what it is not, and gain = a performance benefit of checking a single bit to know whether slow-path = processing is required. =20 -Dave =20 =20 From: Greg Mirsky Sent: Wednesday, February 15, 2017 8:12 PM To: Dave Dolson Cc: adrian@olddog.co.uk; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec =20 Hi Dave,=20 in "without checking next-protocol or searching metadata" you've = expressed common assumption that O-bit indicates two options: * message that immediately follows NSH is OAM message; * one of Variable Length Context Headers carries OAM message. If that is in fact implicit common interpretation of O-bit, then I have = couple questions: * why there's need to use two mechanisms to carry OAM message; * how to avoid unnecessary search through metadata if the message = immediately after NSH is OAM, e.g. BFD control message. I think that it would be much simpler and cleaner if we interpret "OAM = packet" as "message that immediately follows NSH is OAM message" and = indicate this case in NSH Base Header (I prefer use OAM protocol type). = And what is carried in metadata conveyed through Metadata Class and Type = in Variable Context Header. =20 Regards, Greg =20 On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson = wrote: I prefer to think of the inverse: If the O-bit is zero, no functions are required to search the packet for = OAM information. I.e., if O-bit is zero, an SFF may forward the packet on the basis of = SPI/SI without checking next-protocol or searching metadata. I wish the text would actually say that. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, February 15, 2017 4:00 PM To: sfc@ietf.org Subject: [sfc] O-bit behavior in NSH spec Hi, I think it is right that the NSH spec only minimally describe OAM, but I = want to double check the intention of a couple of things here. Section 3.2 says: > O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet. The actual packet format and processing of > SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]). > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. 1. Isn't the first paragraph actually making a decision about the = meaning of the O bit? That is, it is saying that the packet is an OAM packet? Would it be better to defer this type of decisions and say something = a little more vague such as... > O bit: Setting this bit indicates that the NSH packet contains = Operations, > Administration, and Maintenance (OAM) data. The actual packet format > and processing of SFC OAM data and how that data is carried in an NSH > packet is outside the scope of this specification (see > [I-D.ietf-sfc-oam-framework]). 2. Do we really want OAM packets discarded rather than passed through? That substantially minimises the utility of any OAM. Surely we want to specify > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > OAM procedures, SHALL process and forward packets with the O bit set > as normal. Thanks, Adrian _______________________________________________ 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 =20 =20 =20 ------=_NextPart_000_0985_01D28878.6D464320 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Except that it requires a node = that does not support OAM to act as currently described in the NSH spec = and drop packets containing OAM.

    I think this is a = draw-back

     

    Adrian

     

    From: Greg Mirsky = [mailto:gregimirsky@gmail.com]
    Sent: 16 February 2017 = 17:07
    To: Adrian Farrel
    Cc: Dave Dolson; = sfc@ietf.org
    Subject: Re: [sfc] O-bit behavior in NSH = spec

     

    Hi = Adrian,

    the proposed Ov= erlay OAM header has Length field that reflects the length of = the OAM message and Next Protocol field.

    I believe that Overlay OAM Header supports all = scenarios for OAM, with and without user data, in simple consistent = manner.

     

    Regards,

    Greg

     

    On Thu, = Feb 16, 2017 at 1:41 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

    So a high-level question is:

    Will you ever want to include OAM in an NSH packet that also contains = user data?

     

    My impression was that there was some desire for = this.

     

    That would certainly change:

    - the use of "next protocol" to indicate OAM (unless OAM = had a recursive next protocol?)

    - how a node that did not support OAM found the user = data

     

    It would make of the O flag more useful.

     

    A

     

    From: Greg Mirsky [mailto:gregimirsky@gmail.com]
    Sent: 16 = February 2017 02:21


    To: Dave Dolson
    Cc: adrian@olddog.co.uk; sfc@ietf.org
    Subject: Re: [sfc] O-bit = behavior in NSH spec

     <= /o:p>

    Hi = Dave,

    I propose = to deprecate O-bit all together and return it in Reserved pool.We had = discussion whether checking value of one bit long flag is more efficient = then checking multi-bit field for particular value. The conclusion, as I = recall, was that there's no significant advantage of former over the = latter, if any advantage at all.

     <= /o:p>

    Regards,

    Greg

     <= /o:p>

    On Wed, Feb = 15, 2017 at 6:00 PM, Dave Dolson <ddolson@sandvine.com> = wrote:

    Greg,

    Multiple = ideas have been discussed, and no one seems willing to put what OAM *is* = in the NSH draft.

     <= o:p>

    So = I thought it might be more productive to say what it is not, and gain a = performance benefit of checking a single bit to know whether slow-path = processing is required.

     <= o:p>

    -Dave

     <= o:p>

     <= o:p>

    From: = Greg = Mirsky

    Sent: = Wednesday, = February 15, 2017 8:12 PM

    To: = Dave = Dolson

    Subject: = Re: [sfc] = O-bit behavior in NSH = spec

     <= /o:p>

    Hi Dave, =

    in = "without checking next-protocol or = searching metadata" you've expressed common assumption that O-bit = indicates two options:

    • message that immediately follows NSH is OAM = message;
    • one = of Variable Length Context Headers carries OAM = message.

    If that is in fact implicit common = interpretation of O-bit, then I have couple = questions:

    • why = there's need to use two mechanisms to carry OAM = message;
    • how = to avoid unnecessary search through metadata if the message immediately = after NSH is OAM, e.g. BFD control = message.

    I think that it would be much simpler and = cleaner if we interpret "OAM packet" as "message that = immediately follows NSH is OAM message" and indicate this case in = NSH Base Header (I prefer use OAM protocol type). And what is carried in = metadata conveyed through Metadata Class and Type in Variable Context = Header.

     <= /o:p>

    Regards,

    Greg

     <= /o:p>

    On Wed, Feb = 15, 2017 at 1:13 PM, Dave Dolson <ddolson@sandvine.com> wrote:

    I prefer to = think of the inverse:
    If the O-bit is zero, no functions are required = to search the packet for OAM information.
    I.e., if O-bit is zero, an = SFF may forward the packet on the basis of SPI/SI without checking = next-protocol or searching metadata.

    I wish the text would = actually say that.



    ----= -Original Message-----
    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian = Farrel
    Sent: Wednesday, February 15, 2017 4:00 PM
    To: sfc@ietf.org
    Subject: [sfc] O-bit behavior in = NSH spec

    Hi,

    I think it is right that the NSH spec only = minimally describe OAM, but I want to
    double check the intention of a = couple of things here.

    Section 3.2 says:

    > O bit: = Setting this bit indicates an Operations, Administration, and
    > = Maintenance (OAM) packet.  The actual packet format and processing = of
    > SFC OAM messages is outside the scope of this specification = (see [I-
    > D.ietf-sfc-oam-framework]).
    >
    > SF/SFF/SFC = Proxy/Classifer implementations, which do not support SFC
    > OAM = procedures, SHALL discard packets with O-bit set.

    1. Isn't the = first paragraph actually making a decision about the meaning
      =  of the O bit? That is, it is saying that the packet is an OAM = packet?
       Would it be better to defer this type of = decisions and say something a
       little more vague such = as...

    > O bit: Setting this bit indicates that the NSH packet = contains Operations,
    > Administration, and Maintenance (OAM) = data.  The actual packet format
    > and processing of SFC OAM = data and how that data is carried in an NSH
    > packet is outside = the scope of this specification (see
    > = [I-D.ietf-sfc-oam-framework]).

    2. Do we really want OAM packets = discarded rather than passed through?
        That = substantially minimises the utility of any OAM.
        Surely = we want to specify

    > SF/SFF/SFC Proxy/Classifier = implementations, that do not support SFC
    > OAM procedures, SHALL = process and forward packets with the O bit set
    > as = normal.

    Thanks,
    Adrian

    _________________________________= ______________
    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

     <= /o:p>

     <= /o:p>

     

    ------=_NextPart_000_0985_01D28878.6D464320-- From nobody Thu Feb 16 09:47:33 2017 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 16363129564 for ; Thu, 16 Feb 2017 09:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 aVxDWeCnY0nG for ; Thu, 16 Feb 2017 09:47:30 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B695129535 for ; Thu, 16 Feb 2017 09:47:29 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GHlQoP001131; Thu, 16 Feb 2017 17:47:26 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1GHlJeO001037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2017 17:47:23 GMT From: "Adrian Farrel" To: "'Greg Mirsky'" References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <20170216020055.8495190.89878.137349@sandvine.com> <085401d28838$cf1dd2b0$6d597810$@olddog.co.uk> <098401d28878$6d4076c0$47c16440$@olddog.co.uk> In-Reply-To: Date: Thu, 16 Feb 2017 17:47:19 -0000 Message-ID: <09a601d2887c$bb1dcba0$315962e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09A7_01D2887C.BB248260" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKs4QfPsAfGu+IdxTavj2M4SM8+/wH6B6zrApUMVOEC4N2N+gHz78PHAx+YWP0BgzipDQJW25A7AUBHVbOfKkeowA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22890.000 X-TM-AS-Result: No--25.818-10.0-31-10 X-imss-scan-details: No--25.818-10.0-31-10 X-TMASE-MatchedRID: JorHcieTUslbJCKOm3VRCaxVtyymKeG0mtHuQhKV0oMf2n5P2FPAsXiH J0xPX/SK/X21VUfdax2VUcz8XpiS9FaOJcCxVHYr/RBGKwtrhjPV9x7gL2l/MpvkENX+ovXqvFf s6GFQrsidXNOCtK/uyZ1U1lojafr/+uIuZYGsMgSynk7TnYzMuu+bIpSUkDueMssDyl2JOL7ZFQ FW9+fZXEJpGilGG1VQF0vYDRID+cohotH7bEpEMvgnJH5vm2+gnClorBXsaJ0WCFKYHMKZzu5MH vi1B5E4tw/o4J9vD+ZsIyeExXlNbvmfQZ2+Eu+1aIwFrkgzXvapsObNt5zEWw5PwVoIWWYTELXk /LkjhRWZdH+xzatcBFUl3Km/ezeGgsuHb8lxzt4LCC+rIG9+ZVQjgLZA14fKTbpHHrS0p1WRog+ 4lbNA/se4Woyb+kVFjFUG+PWNtyPAWTziWGaDPHNI5KOuyHOVMTvUpd4dRh6WdOnmuZ5t72UHA+ 1wxQjNSSQ7jOqms06mG+fak9r3agreImldQ5BDT7S4ZU4XTxC2FQsfk4g6XDt3IfHGemQW2YTJm p9MaBOKrl1+EpmJUIxSc6X/yxTJEtdrY/Wb3fPJ2i9a4v4pV3Tv7ZA0xIMkEVtxaPoSt7CWzX4L UFA/pEdb73gUDwkXwbRQ2Bpmliq0X0Yw27VuouQ45nVtPqmxrsFU8Uw5BC6ytmB2/5InT/zxIC9 LasqudG57tpB6osSzLD5kmcW6ZCBW9lXcEHZA0ToSvkRVqOZbYToDRWMGWpDQiv0Qe0IxAkhxxo wNxQIX8k3r0LX5EJHXKSSl+ScKgqd6JzaZubObKItl61J/yZUdXE/WGn0FVoTa5lFknUGHHQtvy gWztAxdgwoMYhSm5JtjB/1dyKGwiw1PzzZoAwYrrwx2jOBh6bKtSiBSlJo= Archived-At: Cc: sfc@ietf.org, 'Dave Dolson' Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:47:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09A7_01D2887C.BB248260 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, Greg, =20 That's where this conversation started: looking at the text in the = current NSH spec about how to process an O-bit. But I would also like a receiver of an NSH packet (as described in the = NSH spec) to know how to step over any OAM and find the payload data. =20 That either requires one of the following: - describing the OAM presence (between NSH and payload) in the NSH spec - banning OAM in packets that carry payload - making it OK for OAM packets to be discarded at (i.e. not pass = through) transit nodes - putting the OAM in metadata =20 Adrian =20 =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: 16 February 2017 17:20 To: Adrian Farrel Cc: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec =20 Hi Adrian, but we can re-word text in NSH document. Alternative, as I see it, would = be to embed OAM in NSH. =20 Regards, Greg =20 On Thu, Feb 16, 2017 at 9:16 AM, Adrian Farrel = wrote: Except that it requires a node that does not support OAM to act as = currently described in the NSH spec and drop packets containing OAM. I think this is a draw-back =20 Adrian =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: 16 February 2017 17:07 To: Adrian Farrel Cc: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec =20 Hi Adrian, the proposed Overlay OAM header = has = Length field that reflects the length of the OAM message and Next = Protocol field. I believe that Overlay OAM Header supports all scenarios for OAM, with = and without user data, in simple consistent manner. =20 Regards, Greg =20 On Thu, Feb 16, 2017 at 1:41 AM, Adrian Farrel = wrote: So a high-level question is: Will you ever want to include OAM in an NSH packet that also contains = user data? =20 My impression was that there was some desire for this. =20 That would certainly change: - the use of "next protocol" to indicate OAM (unless OAM had a recursive = next protocol?) - how a node that did not support OAM found the user data =20 It would make of the O flag more useful. =20 A =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: 16 February 2017 02:21 To: Dave Dolson Cc: adrian@olddog.co.uk; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec =20 Hi Dave, I propose to deprecate O-bit all together and return it in Reserved = pool.We had discussion whether checking value of one bit long flag is = more efficient then checking multi-bit field for particular value. The = conclusion, as I recall, was that there's no significant advantage of = former over the latter, if any advantage at all. =20 Regards, Greg =20 On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson = wrote: Greg, Multiple ideas have been discussed, and no one seems willing to put what = OAM *is* in the NSH draft. =20 So I thought it might be more productive to say what it is not, and gain = a performance benefit of checking a single bit to know whether slow-path = processing is required. =20 -Dave =20 =20 From: Greg Mirsky Sent: Wednesday, February 15, 2017 8:12 PM To: Dave Dolson Cc: adrian@olddog.co.uk; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec =20 Hi Dave,=20 in "without checking next-protocol or searching metadata" you've = expressed common assumption that O-bit indicates two options: * message that immediately follows NSH is OAM message; * one of Variable Length Context Headers carries OAM message. If that is in fact implicit common interpretation of O-bit, then I have = couple questions: * why there's need to use two mechanisms to carry OAM message; * how to avoid unnecessary search through metadata if the message = immediately after NSH is OAM, e.g. BFD control message. I think that it would be much simpler and cleaner if we interpret "OAM = packet" as "message that immediately follows NSH is OAM message" and = indicate this case in NSH Base Header (I prefer use OAM protocol type). = And what is carried in metadata conveyed through Metadata Class and Type = in Variable Context Header. =20 Regards, Greg =20 On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson = wrote: I prefer to think of the inverse: If the O-bit is zero, no functions are required to search the packet for = OAM information. I.e., if O-bit is zero, an SFF may forward the packet on the basis of = SPI/SI without checking next-protocol or searching metadata. I wish the text would actually say that. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, February 15, 2017 4:00 PM To: sfc@ietf.org Subject: [sfc] O-bit behavior in NSH spec Hi, I think it is right that the NSH spec only minimally describe OAM, but I = want to double check the intention of a couple of things here. Section 3.2 says: > O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet. The actual packet format and processing of > SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]). > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. 1. Isn't the first paragraph actually making a decision about the = meaning of the O bit? That is, it is saying that the packet is an OAM packet? Would it be better to defer this type of decisions and say something = a little more vague such as... > O bit: Setting this bit indicates that the NSH packet contains = Operations, > Administration, and Maintenance (OAM) data. The actual packet format > and processing of SFC OAM data and how that data is carried in an NSH > packet is outside the scope of this specification (see > [I-D.ietf-sfc-oam-framework]). 2. Do we really want OAM packets discarded rather than passed through? That substantially minimises the utility of any OAM. Surely we want to specify > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > OAM procedures, SHALL process and forward packets with the O bit set > as normal. Thanks, Adrian _______________________________________________ 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 =20 =20 =20 =20 ------=_NextPart_000_09A7_01D2887C.BB248260 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Yes, = Greg,

     

    That's where this conversation = started: looking at the text in the current NSH spec about how to = process an O-bit.

    But I would also like a = receiver of an NSH packet (as described in the NSH spec) to know how to = step over any OAM and find the payload data.

     

    That either requires one of = the following:

    - describing the OAM presence = (between NSH and payload) in the NSH spec

    - banning OAM in packets that = carry payload

    - making it OK for OAM packets = to be discarded at (i.e. not pass through) transit = nodes

    - putting the OAM in = metadata

     

    Adrian

     

     

    From: Greg Mirsky = [mailto:gregimirsky@gmail.com]
    Sent: 16 February 2017 = 17:20
    To: Adrian Farrel
    Cc: Dave Dolson; = sfc@ietf.org
    Subject: Re: [sfc] O-bit behavior in NSH = spec

     

    Hi = Adrian,

    but we can re-word text = in NSH document. Alternative, as I see it, would be to embed OAM in = NSH.

     

    Regards,

    Greg

     

    On Thu, = Feb 16, 2017 at 9:16 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

    Except that it requires a node that does not support OAM to act as = currently described in the NSH spec and drop packets containing = OAM.

    I think this is a draw-back

     

    Adrian

     

    From: Greg Mirsky [mailto:gregimirsky@gmail.com]
    Sent: 16 = February 2017 17:07
    To: Adrian Farrel
    Cc: Dave = Dolson; sfc@ietf.org


    Subject: Re: [sfc] O-bit behavior in NSH = spec

     <= /o:p>

    Hi = Adrian,

    the = proposed Overlay OAM header has Length field that = reflects the length of the OAM message and Next Protocol = field.

    I believe = that Overlay OAM Header supports all scenarios for OAM, with and without = user data, in simple consistent manner.

     <= /o:p>

    Regards,

    Greg

     <= /o:p>

    On Thu, Feb = 16, 2017 at 1:41 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

    So a high-level question is:

    Will you ever want to include OAM in an NSH packet that also contains = user data?

     

    My impression was that there was some desire for = this.

     

    That would certainly change:

    - the use of "next protocol" to indicate OAM (unless OAM = had a recursive next protocol?)

    - how a node that did not support OAM found the user = data

     

    It would make of the O flag more useful.

     

    A

     

    From: Greg Mirsky [mailto:gregimirsky@gmail.com]
    Sent: 16 = February 2017 02:21


    To: Dave Dolson
    Cc: adrian@olddog.co.uk; sfc@ietf.org
    Subject: Re: [sfc] O-bit = behavior in NSH spec

     <= /o:p>

    Hi = Dave,

    I propose = to deprecate O-bit all together and return it in Reserved pool.We had = discussion whether checking value of one bit long flag is more efficient = then checking multi-bit field for particular value. The conclusion, as I = recall, was that there's no significant advantage of former over the = latter, if any advantage at all.

     <= /o:p>

    Regards,

    Greg

     <= /o:p>

    On Wed, Feb = 15, 2017 at 6:00 PM, Dave Dolson <ddolson@sandvine.com> = wrote:

    Greg,

    Multiple = ideas have been discussed, and no one seems willing to put what OAM *is* = in the NSH draft.

     <= o:p>

    So = I thought it might be more productive to say what it is not, and gain a = performance benefit of checking a single bit to know whether slow-path = processing is required.

     <= o:p>

    -Dave

     <= o:p>

     <= o:p>

    From: = Greg = Mirsky

    Sent: = Wednesday, = February 15, 2017 8:12 PM

    To: = Dave = Dolson

    Subject: = Re: [sfc] = O-bit behavior in NSH = spec

     <= /o:p>

    Hi Dave, =

    in = "without checking next-protocol or = searching metadata" you've expressed common assumption that O-bit = indicates two options:

    • message that immediately follows NSH is OAM = message;
    • one = of Variable Length Context Headers carries OAM = message.

    If that is in fact implicit common = interpretation of O-bit, then I have couple = questions:

    • why = there's need to use two mechanisms to carry OAM = message;
    • how = to avoid unnecessary search through metadata if the message immediately = after NSH is OAM, e.g. BFD control = message.

    I think that it would be much simpler and = cleaner if we interpret "OAM packet" as "message that = immediately follows NSH is OAM message" and indicate this case in = NSH Base Header (I prefer use OAM protocol type). And what is carried in = metadata conveyed through Metadata Class and Type in Variable Context = Header.

     <= /o:p>

    Regards,

    Greg

     <= /o:p>

    On Wed, Feb = 15, 2017 at 1:13 PM, Dave Dolson <ddolson@sandvine.com> wrote:

    I prefer to = think of the inverse:
    If the O-bit is zero, no functions are required = to search the packet for OAM information.
    I.e., if O-bit is zero, an = SFF may forward the packet on the basis of SPI/SI without checking = next-protocol or searching metadata.

    I wish the text would = actually say that.



    ----= -Original Message-----
    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian = Farrel
    Sent: Wednesday, February 15, 2017 4:00 PM
    To: sfc@ietf.org
    Subject: [sfc] O-bit behavior in = NSH spec

    Hi,

    I think it is right that the NSH spec only = minimally describe OAM, but I want to
    double check the intention of a = couple of things here.

    Section 3.2 says:

    > O bit: = Setting this bit indicates an Operations, Administration, and
    > = Maintenance (OAM) packet.  The actual packet format and processing = of
    > SFC OAM messages is outside the scope of this specification = (see [I-
    > D.ietf-sfc-oam-framework]).
    >
    > SF/SFF/SFC = Proxy/Classifer implementations, which do not support SFC
    > OAM = procedures, SHALL discard packets with O-bit set.

    1. Isn't the = first paragraph actually making a decision about the meaning
      =  of the O bit? That is, it is saying that the packet is an OAM = packet?
       Would it be better to defer this type of = decisions and say something a
       little more vague such = as...

    > O bit: Setting this bit indicates that the NSH packet = contains Operations,
    > Administration, and Maintenance (OAM) = data.  The actual packet format
    > and processing of SFC OAM = data and how that data is carried in an NSH
    > packet is outside = the scope of this specification (see
    > = [I-D.ietf-sfc-oam-framework]).

    2. Do we really want OAM packets = discarded rather than passed through?
        That = substantially minimises the utility of any OAM.
        Surely = we want to specify

    > SF/SFF/SFC Proxy/Classifier = implementations, that do not support SFC
    > OAM procedures, SHALL = process and forward packets with the O bit set
    > as = normal.

    Thanks,
    Adrian

    _________________________________= ______________
    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

     <= /o:p>

     <= /o:p>

     <= /o:p>

     

    ------=_NextPart_000_09A7_01D2887C.BB248260-- From nobody Thu Feb 16 09:58:25 2017 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 EDF5F1295B2 for ; Thu, 16 Feb 2017 09:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 xYvemQ3X19Tw for ; Thu, 16 Feb 2017 09:58:22 -0800 (PST) Received: from mxa2.tigertech.net (mxa2.tigertech.net [208.80.4.162]) (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 34C52129535 for ; Thu, 16 Feb 2017 09:58:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D9D05DC0335; Thu, 16 Feb 2017 09:58:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487267901; bh=+zoOc0dcvMP2I/KZI82tm5zr1F4xAM2pCSwTS4qY178=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eIqBGGMA7CrpIXEIzqFkzHT2+j4wkzDUL1tSN8MNW+fyexPsZ1xpn55UkHn/WIE2R a7NZ3h4LgWPRJkVsfIw34zE21X/pTNE6pSFkItgWBiUQ1ZsZ2ukeRPYsX9hPX09Acs GMZXwmf5zrake6FYslRuG5dRZlt9EmekcPuxBtfE= 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 42958DC0330; Thu, 16 Feb 2017 09:58:21 -0800 (PST) To: Greg Mirsky References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <20170216020055.8495190.89878.137349@sandvine.com> <085401d28838$cf1dd2b0$6d597810$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Thu, 16 Feb 2017 12:58:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Dave Dolson , sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:58:24 -0000 Just to clarify: An NSH Supporting SF which does not support in-Situ OAM would receive packets with an NSH header with a next header value of OAM. Would not such an SF either discard the packet or get very confused? Particularly since our current approach to conventional OAM for SFPs is not to involve the SFs, as we are not trying to monitor applications with data plane measurement. Yours, Joel On 2/16/17 12:06 PM, Greg Mirsky wrote: > Hi Adrian, > the proposed Overlay OAM header > has > Length field that reflects the length of the OAM message and Next > Protocol field. > I believe that Overlay OAM Header supports all scenarios for OAM, with > and without user data, in simple consistent manner. > > Regards, > Greg > > On Thu, Feb 16, 2017 at 1:41 AM, Adrian Farrel > wrote: > > So a high-level question is:____ > > Will you ever want to include OAM in an NSH packet that also > contains user data?____ > > __ __ > > My impression was that there was some desire for this.____ > > __ __ > > That would certainly change:____ > > - the use of "next protocol" to indicate OAM (unless OAM had a > recursive next protocol?)____ > > - how a node that did not support OAM found the user data____ > > __ __ > > It would make of the O flag more useful.____ > > __ __ > > A____ > > __ __ > > *From:*Greg Mirsky [mailto:gregimirsky@gmail.com > ] > *Sent:* 16 February 2017 02:21 > > > *To:* Dave Dolson > *Cc:* adrian@olddog.co.uk ; sfc@ietf.org > > *Subject:* Re: [sfc] O-bit behavior in NSH spec____ > > __ __ > > Hi Dave,____ > > I propose to deprecate O-bit all together and return it in Reserved > pool.We had discussion whether checking value of one bit long flag > is more efficient then checking multi-bit field for particular > value. The conclusion, as I recall, was that there's no significant > advantage of former over the latter, if any advantage at all.____ > > __ __ > > Regards,____ > > Greg____ > > __ __ > > On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson > wrote:____ > > Greg,____ > > Multiple ideas have been discussed, and no one seems willing to put > what OAM *is* in the NSH draft.____ > > __ __ > > So I thought it might be more productive to say what it is not, and > gain a performance benefit of checking a single bit to know whether > slow-path processing is required.____ > > __ __ > > -Dave____ > > __ __ > > __ __ > > *From: *Greg Mirsky____ > > *Sent: *Wednesday, February 15, 2017 8:12 PM____ > > *To: *Dave Dolson____ > > *Cc: *adrian@olddog.co.uk ; sfc@ietf.org > ____ > > *Subject: *Re: [sfc] O-bit behavior in NSH spec____ > > __ __ > > Hi Dave, ____ > > in "without checking next-protocol or searching metadata" you've > expressed common assumption that O-bit indicates two options:____ > > * message that immediately follows NSH is OAM message;____ > * one of Variable Length Context Headers carries OAM message.____ > > If that is in fact implicit common interpretation of O-bit, then I > have couple questions:____ > > * why there's need to use two mechanisms to carry OAM message;____ > * how to avoid unnecessary search through metadata if the message > immediately after NSH is OAM, e.g. BFD control message.____ > > I think that it would be much simpler and cleaner if we interpret > "OAM packet" as "message that immediately follows NSH is OAM > message" and indicate this case in NSH Base Header (I prefer use OAM > protocol type). And what is carried in metadata conveyed through > Metadata Class and Type in Variable Context Header.____ > > __ __ > > Regards,____ > > Greg____ > > __ __ > > On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson > wrote:____ > > I prefer to think of the inverse: > If the O-bit is zero, no functions are required to search the packet > for OAM information. > I.e., if O-bit is zero, an SFF may forward the packet on the basis > of SPI/SI without checking next-protocol or searching metadata. > > I wish the text would actually say that.____ > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org > ] On Behalf Of Adrian Farrel > Sent: Wednesday, February 15, 2017 4:00 PM > To: sfc@ietf.org > Subject: [sfc] O-bit behavior in NSH spec > > Hi, > > I think it is right that the NSH spec only minimally describe OAM, > but I want to > double check the intention of a couple of things here. > > Section 3.2 says: > > > O bit: Setting this bit indicates an Operations, Administration, and > > Maintenance (OAM) packet. The actual packet format and processing of > > SFC OAM messages is outside the scope of this specification (see [I- > > D.ietf-sfc-oam-framework]). > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > > OAM procedures, SHALL discard packets with O-bit set. > > 1. Isn't the first paragraph actually making a decision about the > meaning > of the O bit? That is, it is saying that the packet is an OAM packet? > Would it be better to defer this type of decisions and say > something a > little more vague such as... > > > O bit: Setting this bit indicates that the NSH packet contains > Operations, > > Administration, and Maintenance (OAM) data. The actual packet format > > and processing of SFC OAM data and how that data is carried in an NSH > > packet is outside the scope of this specification (see > > [I-D.ietf-sfc-oam-framework]). > > 2. Do we really want OAM packets discarded rather than passed through? > That substantially minimises the utility of any OAM. > Surely we want to specify > > > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > > OAM procedures, SHALL process and forward packets with the O bit set > > as normal. > > Thanks, > Adrian > > _______________________________________________ > 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 > From nobody Thu Feb 16 10:05:51 2017 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 881341294F1 for ; Thu, 16 Feb 2017 10:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkhLluwd8gRs for ; Thu, 16 Feb 2017 10:05:48 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93CF129406 for ; Thu, 16 Feb 2017 10:05:48 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 10:05:47 -0800 From: Ron Parker To: "Joel M. Halpern" , Greg Mirsky Thread-Topic: [sfc] O-bit behavior in NSH spec Thread-Index: AdKHznKalxPKklEDRqOqF5nO++eCgQAASE5QABlJ4YAAAbVaAAAAsesAAA9gvYAAD5F3gAABy7MAABCVvuA= Date: Thu, 16 Feb 2017 18:05:46 +0000 Message-ID: References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <20170216020055.8495190.89878.137349@sandvine.com> <085401d28838$cf1dd2b0$6d597810$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.205.79.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , Dave Dolson Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:05:50 -0000 I'd really like to hold the option open to support OAM that includes the NS= H-aware SF, too, even if initially we define OAM that is terminated by the = SFF, primarily. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 16, 2017 12:58 PM To: Greg Mirsky Cc: Dave Dolson ; sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec Just to clarify: An NSH Supporting SF which does not support in-Situ OAM would receive packe= ts with an NSH header with a next header value of OAM. Would not such an SF either discard the packet or get very confused? Particularly since our current approach to conventional OAM for SFPs is not= to involve the SFs, as we are not trying to monitor applications with data= plane measurement. Yours, Joel On 2/16/17 12:06 PM, Greg Mirsky wrote: > Hi Adrian, > the proposed Overlay OAM header > has=20 > Length field that reflects the length of the OAM message and Next=20 > Protocol field. > I believe that Overlay OAM Header supports all scenarios for OAM, with=20 > and without user data, in simple consistent manner. > > Regards, > Greg > > On Thu, Feb 16, 2017 at 1:41 AM, Adrian Farrel > wrote: > > So a high-level question is:____ > > Will you ever want to include OAM in an NSH packet that also > contains user data?____ > > __ __ > > My impression was that there was some desire for this.____ > > __ __ > > That would certainly change:____ > > - the use of "next protocol" to indicate OAM (unless OAM had a > recursive next protocol?)____ > > - how a node that did not support OAM found the user data____ > > __ __ > > It would make of the O flag more useful.____ > > __ __ > > A____ > > __ __ > > *From:*Greg Mirsky [mailto:gregimirsky@gmail.com > ] > *Sent:* 16 February 2017 02:21 > > > *To:* Dave Dolson > *Cc:* adrian@olddog.co.uk ; sfc@ietf.org > > *Subject:* Re: [sfc] O-bit behavior in NSH spec____ > > __ __ > > Hi Dave,____ > > I propose to deprecate O-bit all together and return it in Reserved > pool.We had discussion whether checking value of one bit long flag > is more efficient then checking multi-bit field for particular > value. The conclusion, as I recall, was that there's no significant > advantage of former over the latter, if any advantage at all.____ > > __ __ > > Regards,____ > > Greg____ > > __ __ > > On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson > wrote:____ > > Greg,____ > > Multiple ideas have been discussed, and no one seems willing to put > what OAM *is* in the NSH draft.____ > > __ __ > > So I thought it might be more productive to say what it is not, and > gain a performance benefit of checking a single bit to know whether > slow-path processing is required.____ > > __ __ > > -Dave____ > > __ __ > > __ __ > > *From: *Greg Mirsky____ > > *Sent: *Wednesday, February 15, 2017 8:12 PM____ > > *To: *Dave Dolson____ > > *Cc: *adrian@olddog.co.uk ; sfc@ietf.org > ____ > > *Subject: *Re: [sfc] O-bit behavior in NSH spec____ > > __ __ > > Hi Dave, ____ > > in "without checking next-protocol or searching metadata" you've > expressed common assumption that O-bit indicates two options:____ > > * message that immediately follows NSH is OAM message;____ > * one of Variable Length Context Headers carries OAM=20 > message.____ > > If that is in fact implicit common interpretation of O-bit, then I > have couple questions:____ > > * why there's need to use two mechanisms to carry OAM message;____ > * how to avoid unnecessary search through metadata if the message > immediately after NSH is OAM, e.g. BFD control message.____ > > I think that it would be much simpler and cleaner if we interpret > "OAM packet" as "message that immediately follows NSH is OAM > message" and indicate this case in NSH Base Header (I prefer use OAM > protocol type). And what is carried in metadata conveyed through > Metadata Class and Type in Variable Context Header.____ > > __ __ > > Regards,____ > > Greg____ > > __ __ > > On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson > wrote:____ > > I prefer to think of the inverse: > If the O-bit is zero, no functions are required to search the packet > for OAM information. > I.e., if O-bit is zero, an SFF may forward the packet on the basis > of SPI/SI without checking next-protocol or searching metadata. > > I wish the text would actually say that.____ > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org > ] On Behalf Of Adrian Farrel > Sent: Wednesday, February 15, 2017 4:00 PM > To: sfc@ietf.org > Subject: [sfc] O-bit behavior in NSH spec > > Hi, > > I think it is right that the NSH spec only minimally describe OAM, > but I want to > double check the intention of a couple of things here. > > Section 3.2 says: > > > O bit: Setting this bit indicates an Operations, Administration, an= d > > Maintenance (OAM) packet. The actual packet format and processing = of > > SFC OAM messages is outside the scope of this specification (see [I= - > > D.ietf-sfc-oam-framework]). > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SF= C > > OAM procedures, SHALL discard packets with O-bit set. > > 1. Isn't the first paragraph actually making a decision about the > meaning > of the O bit? That is, it is saying that the packet is an OAM pack= et? > Would it be better to defer this type of decisions and say > something a > little more vague such as... > > > O bit: Setting this bit indicates that the NSH packet contains > Operations, > > Administration, and Maintenance (OAM) data. The actual packet form= at > > and processing of SFC OAM data and how that data is carried in an N= SH > > packet is outside the scope of this specification (see > > [I-D.ietf-sfc-oam-framework]). > > 2. Do we really want OAM packets discarded rather than passed through= ? > That substantially minimises the utility of any OAM. > Surely we want to specify > > > SF/SFF/SFC Proxy/Classifier implementations, that do not support SF= C > > OAM procedures, SHALL process and forward packets with the O bit se= t > > as normal. > > Thanks, > Adrian > > _______________________________________________ > 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 > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 16 10:16:32 2017 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 7F0CD12955D for ; Thu, 16 Feb 2017 10:16:30 -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 0oedmTILTew8 for ; Thu, 16 Feb 2017 10:16:29 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 D87021294F5 for ; Thu, 16 Feb 2017 10:16:28 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id 32so16649110oth.3 for ; Thu, 16 Feb 2017 10:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+FA1AtpdUDeTuiSzR/ie+dNN9bkhOgQVabV7ecYodEQ=; b=VjRbSb2Vruhb4S0F421kXeiH79zdBAyDpl6rzJCnHw1rLyOzF/rwsOpymMPoTliGeZ /NIsKA4Dl004JuburGf5dt/nxtmkaxk2q3chBAhba2LZ/dwgwrNGOV5lOwdjhkBKjLHj JfJFYfzmA3vqcb6/zHaOG17FErjjiaN2nrZjxV5CKDoZreGr0IMeWg4X5avU0/ockHsw 1A0SiMM8NwBi8yNE6LZBmAy1DWUgWWulAiSOxvTflIqBxbAaglsYkZSTuRHprN0ET0a2 X2TIx9xq5Z2S8lVxIpaz2ynypU6mst8oFN38ojZ6L0LEU5Gc4HV1cdi8UX2ejnQxGlZp NZEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+FA1AtpdUDeTuiSzR/ie+dNN9bkhOgQVabV7ecYodEQ=; b=e7ocGirgVzJxfoLmcpPwjfXfAxYlXrp0xZ4vv2iERzgv2+ILSNJ2oLtOgzmpJljb7m LDB8R4Nu4vNoORxV9R9V/IzTIGp10NDt/JCSp2Mmnx6N6rFrJNHL/1IvCAZyraiJd5Hh cy0+hKmsX05dh0U5yZecuVdH8D0Bq+E8Vwm/KeVp0hGXx3YO23z01xjU+TMoDB8fQ2kG MOg9KSLcESJ77ywW0icmx6yACQ7G6QT7HnXTiaDCIbX7qzHh4QqHp+L4KnipJP86ZyVt JMP2mEF87WfAg8MMoPqChWqYAo7r3lxoup04GOcVCaVphnVJ8Pdg2yrsmgtEx2R4kAxN Hdfw== X-Gm-Message-State: AMke39kIjB1KOCl5XS+oOFrbBJVmcUodP5p+Aak+a7EF+wuZoMa3+wkW6ZuXe0Wk9S2IEpR8GO66r4jxoSIejg== X-Received: by 10.157.16.5 with SMTP id h5mr185161ote.77.1487268988277; Thu, 16 Feb 2017 10:16:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Thu, 16 Feb 2017 10:16:07 -0800 (PST) In-Reply-To: <3174cda2-2dda-bb2c-43c7-279e978fe639@joelhalpern.com> References: <148702829421.22233.782542928593751229.idtracker@ietfa.amsl.com> <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> <3174cda2-2dda-bb2c-43c7-279e978fe639@joelhalpern.com> From: "Andrew G. Malis" Date: Thu, 16 Feb 2017 13:16:07 -0500 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11403546bb5a320548a9cb86 Archived-At: Cc: "Paul Quinn \(paulq\)" , "sfc@ietf.org" , Dave Dolson Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:16:30 -0000 --001a11403546bb5a320548a9cb86 Content-Type: text/plain; charset=UTF-8 Joel, Just curious when you expect to call consensus for TTL and C flag. Thanks, Andy On Wed, Feb 15, 2017 at 5:17 PM, Joel M. Halpern wrote: > The chairs request of the authors was to get the text out with the known > and (we believed) agreed changes, so that we all had text to work from. > > Once the chairs call consensus on the other points, then we expect the > following revision to include them. > > Yours, > Joel > > On 2/15/17 4:53 PM, Dave Dolson wrote: > >> Do we expect changes regarding: >> >> - Removal of C-flag ? >> >> - Addition of TTL ? >> >> >> >> >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn >> (paulq) >> *Sent:* Monday, February 13, 2017 6:30 PM >> *To:* sfc@ietf.org >> *Subject:* [sfc] Fwd: New Version Notification for >> draft-ietf-sfc-nsh-11.txt >> >> >> >> Folks, >> >> >> >> This version integrates: >> >> >> >> - Much of the email thread with Alia re: her AD review of the draft. >> There still might be a few minor items that need to be updated (e.g. >> some of the IETF vs. expert review for registries) >> >> - The changes summarized by the chairs >> (https://mailarchive.ietf.org/arch/msg/sfc/03g2WEAeID_XIQgsF >> OZxD-diqQU/?qid=4eda91ca1d7acd135b12947201b6547a) >> >> - Some minor editorial changes >> >> >> >> Paul >> >> >> >> >> >> Begin forwarded message: >> >> >> >> *From: *> >> >> *Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt* >> >> *Date: *February 13, 2017 at 6:24:54 PM EST >> >> *To: *Uri Elzur >, Paul >> Quinn > >> >> >> >> >> A new version of I-D, draft-ietf-sfc-nsh-11.txt >> has been successfully submitted by Paul Quinn and posted to the >> IETF repository. >> >> Name:draft-ietf-sfc-nsh >> Revision:11 >> Title:Network Service Header >> Document date:2017-02-12 >> Group:sfc >> Pages:37 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-11 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-11 >> >> Abstract: >> This document describes a Network Service Header (NSH) inserted onto >> packets or frames to realize service function paths. NSH also >> provides a mechanism for metadata exchange along the instantiated >> service path. NSH is the SFC encapsulation required to support the >> Service Function Chaining (SFC) Architecture (defined in RFC7665). >> >> >> >> >> 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 >> >> >> >> >> >> _______________________________________________ >> 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 > --001a11403546bb5a320548a9cb86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Joel,

    Just curious when you expect to c= all consensus for TTL and C flag.

    Thanks,
    Andy


    On Wed, Feb 15, 2017 at 5:17 PM, Joel M. Halpern <jmh@j= oelhalpern.com> wrote:
    The = chairs request of the authors was to get the text out with the known and (w= e believed) agreed changes, so that we all had text to work from.

    Once the chairs call consensus on the other points, then we expect the foll= owing revision to include them.

    Yours,
    Joel

    On 2/15/17 4:53 PM, Dave Dolson wrote:
    Do we expect changes regarding:

    -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Removal of C-flag ?

    -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Addition of TTL ?







     *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn (paulq)
    *Sent:* Monday, February 13, 2017 6:30 PM
    *To:* sfc@ietf.org *Subject:* [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-11.tx= t



    Folks,



    This version integrates:



    - Much of the email thread with Alia re: her AD review of the draft.
    =C2=A0There still might be a few minor items that need to be updated (e.g.<= br> some of the IETF vs. expert review for registries)

    - The changes summarized by the chairs
    (https://mailarchive.ietf.org/arch/msg/sfc/03g2WEAeID_XIQgs= FOZxD-diqQU/?qid=3D4eda91ca1d7acd135b12947201b6547a)

    - Some minor editorial changes



    Paul





    Begin forwarded message:



     *From: *<i= nternet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>

    *Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt*

    *Date: *February 13, 2017 at 6:24:54 PM EST

    *To: *Uri Elzur <uri.elzur@intel.com <mailto:uri.elzur@intel.com>>, Paul
    Quinn <paulq@cisco.= com <mailto:pau= lq@cisco.com>>




    A new version of I-D, draft-ietf-sfc-nsh-11.txt
    has been successfully submitted by Paul Quinn and posted to the
    IETF repository.

    Name:draft-ietf-sfc-nsh
    Revision:11
    Title:Network Service Header
    Document date:2017-02-12
    Group:sfc
    Pages:37
    URL:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.txt=
    Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.i= etf.org/html/draft-ietf-sfc-nsh-11
    Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11

    Abstract:
    =C2=A0 This document describes a Network Service Header (NSH) inserted onto=
    =C2=A0 packets or frames to realize service function paths.=C2=A0 NSH also<= br> =C2=A0 provides a mechanism for metadata exchange along the instantiated =C2=A0 service path.=C2=A0 NSH is the SFC encapsulation required to support= the
    =C2=A0 Service Function Chaining (SFC) Architecture (defined in RFC7665).



    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org
    <= http://tools.ietf.org>.

    The IETF Secretariat





    _______________________________________________
    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

    --001a11403546bb5a320548a9cb86-- From nobody Thu Feb 16 15:15:10 2017 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 D7869129401 for ; Thu, 16 Feb 2017 15:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH5Ix-LGdLMn for ; Thu, 16 Feb 2017 15:15:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DB8124281 for ; Thu, 16 Feb 2017 15:15:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAT34738; Thu, 16 Feb 2017 23:15:02 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 16 Feb 2017 23:15:02 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Thu, 16 Feb 2017 15:14:57 -0800 From: James N Guichard To: "mohamed.boucadair@orange.com" , "Paul Quinn (paulq)" , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sfc-nsh-11.txt Thread-Index: AQHShlBkUCIc1jOOIUqdPqawp9G6OaFrzs4wgAB41SA= Date: Thu, 16 Feb 2017 23:14:56 +0000 Message-ID: References: <148702829421.22233.782542928593751229.idtracker@ietfa.amsl.com> <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> <787AE7BB302AE849A7480A190F8B933009E138E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E138E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.7] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB8D4BSJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58A63277.01F0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bdc39a7343f67125cc340b4415a0d5f4 Archived-At: Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 23:15:09 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB8D4BSJCEML701CHMchina_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For reference the agreed upon text to be added at the end of section 3.5.1 = is as follows - NSH editors please make the change: This specification does not make any assumption about TLVs that are mandatory-to-implement or those that are mandatory-to-process. These considerations are deployment-specific. However, the control plane is entitled to instruct SFC-aware SFs with the data structure of TLVs together with their scoping (See Section 3.3.3 of [I-D.ietf-sfc- control-plane]). Upon receipt of a packet that belong to a given SFP, if a mandatory- to-process TLV is missing in that packet, the SFC-aware SF MUST NOT process the packet and MUST log at least once per the SPI for which a mandatory metadata is missing. If multiple mandatory-to-process TLVs are required for a given SFP, the control plane MAY instruct the SFC-aware SF with the order to consume these TLVs. If no instructions are provided, the SFC-aware SF MUST process these TLVs in the order their appear in the NSH packet. If multiple instances of the same TLV are included in an NSH packet, but the definition of that TLV does not allow for it, the SFC-aware SF MUST NOT process the packet and MUST log at least once per the SPI for which multiple instances of that TLV is supplied. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, February 16, 2017 11:04 AM To: Paul Quinn (paulq) ; sfc@ietf.org Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-11.txt Hi Paul, Thank you for the update. I'm afraid the agreed text (the one to be added to Section 3.5.1) as record= ed in https://trac.ietf.org/trac/sfc/ticket/21 was not integrated in this r= evision. Can you please fix that? Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Paul Quinn (paulq) Envoy=E9 : mardi 14 f=E9vrier 2017 00:30 =C0 : sfc@ietf.org Objet : [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-11.txt Folks, This version integrates: - Much of the email thread with Alia re: her AD review of the draft. There= still might be a few minor items that need to be updated (e.g. some of the= IETF vs. expert review for registries) - The changes summarized by the chairs (https://mailarchive.ietf.org/arch/m= sg/sfc/03g2WEAeID_XIQgsFOZxD-diqQU/?qid=3D4eda91ca1d7acd135b12947201b6547a) - Some minor editorial changes Paul Begin forwarded message: From: > Subject: New Version Notification for draft-ietf-sfc-nsh-11.txt Date: February 13, 2017 at 6:24:54 PM EST To: Uri Elzur >, Paul Quinn= > A new version of I-D, draft-ietf-sfc-nsh-11.txt has been successfully submitted by Paul Quinn and posted to the IETF repository. Name: draft-ietf-sfc-nsh Revision: 11 Title: Network Service Header Document date: 2017-02-12 Group: sfc Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.= txt Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-11 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB8D4BSJCEML701CHMchina_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    For reference the agreed upon text to= be added at the end of section 3.5.1 is as follows – NSH editors ple= ase make the change:

    This specification does not make any assumption about TLVs that are
    mandatory-to-implement or those that are mandatory-to-process. These
    considerations are deployment-specific. However, the control plane
    is entitled to instruct SFC-aware SFs with the data structure of
    TLVs together with their scoping (See Section 3.3.3 of [I-D.ietf-sfc-
    control-plane]).

    Upon receipt of a packet that belong to a given SFP, if a mandatory-
    to-process TLV is missing in that packet, the SFC-aware SF MUST NOT
    process the packet and MUST log at least once per the SPI for which
    a mandatory metadata is missing.

    If multiple mandatory-to-process TLVs are required for a given SFP,
    the control plane MAY instruct the SFC-aware SF with the order to
    consume these TLVs. If no instructions are provided, the SFC-aware
    SF MUST process these TLVs in the order their appear in the NSH
    packet.

    If multiple instances of the same TLV are included in an NSH packet,
    but the definition of that TLV does not allow for it, the SFC-aware
    SF MUST NOT process the packet and MUST log at least once per the SPI
    for which multiple instances of that TLV is supplied.

     

    &nbs= p;

    From: sfc [mailto:sfc-bounces@ietf.o= rg] On Behalf Of mohamed.boucadair@orange.com
    Sent: Thursday, February 16, 2017 11:04 AM
    To: Paul Quinn (paulq) <paulq@cisco.com>; sfc@ietf.org
    Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-1= 1.txt

     

    Hi Paul,

     

    Thank you for the update.

     

    I’m afraid the agreed text (the one to b= e added to Section 3.5.1) as recorded in https://trac.ietf.org/= trac/sfc/ticket/21 was not integrated in this revision. Can you please = fix that?

     

    Cheers,

    Med

     

    De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Paul Quinn (paulq)
    Envoy=E9 : mardi 14 f=E9vrier 2017 00:30
    =C0 : sfc@ietf.org
    Objet : [sfc] Fwd: New Version Notification for draft-ietf-sfc-= nsh-11.txt

     

    Folks,

     

    This version integrates:

     

    - Much of the email thread with Al= ia re: her AD review of the draft.  There still might be a few minor i= tems that need to be updated (e.g. some of the IETF vs. expert review for r= egistries)

    - Some minor editorial changes

     

    Paul

     

     

    Begin forwarded message:

     

    Subject: New Version Notification for draft-ietf-sfc-nsh-= 11.txt

    Date: February 13, 2017 at 6:24:54 PM EST<= /span>

    To: Uri = Elzur <uri.elzur@intel.com>= ;, Paul Quinn <paulq@cisco.com>= ;

     

    A new version of I-D, draft-ietf-sfc-nsh-11.txt
    has been successfully submitted by Paul Quinn and posted to the
    IETF repository.

    Name: draft-ietf-sfc-nsh
    Revision: 11
    Title: Network Service Header
    Document date: 2017-02-12
    Group: sfc
    Pages: 37
    URL:            http= s://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-11.txt
    Status:         https://datatracker.ietf.org/= doc/draft-ietf-sfc-nsh/
    Htmlized:       https://tools.ietf.org/html/draft-ietf-sfc= -nsh-11
    Diff:           https://www.= ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-11

    Abstract:
      This document describes a Network Service Header (NSH) inserted= onto
      packets or frames to realize service function paths.  NSH = also
      provides a mechanism for metadata exchange along the instantiat= ed
      service path.  NSH is the SFC encapsulation required to su= pport the
      Service Function Chaining (SFC) Architecture (defined in RFC766= 5).




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

    The IETF Secretariat

     

    --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB8D4BSJCEML701CHMchina_-- From nobody Thu Feb 16 22:32:52 2017 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 25D9A129510 for ; Thu, 16 Feb 2017 22:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 7VZ6FFNbwd2z for ; Thu, 16 Feb 2017 22:32:50 -0800 (PST) Received: from relais-inet.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 407B61294A4 for ; Thu, 16 Feb 2017 22:32:50 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id D531C20648; Fri, 17 Feb 2017 07:32:48 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id AF3EC1A0051; Fri, 17 Feb 2017 07:32:48 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 07:32:48 +0100 From: To: Kyle Larose Thread-Topic: Some comments on draft-ietf-sfc-control-plane/ Thread-Index: AdJ2XSWLQrZOCvI0SHOBJJB2cIUAmAAeehxAAQuOhgADeB8v8A== Date: Fri, 17 Feb 2017 06:32:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E13F43@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933009DE9608@OPEXCLILMA3.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.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Some comments on draft-ietf-sfc-control-plane/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 06:32:52 -0000 Hi Kyle,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Kyle Larose [mailto:klarose@sandvine.com] > Envoy=E9=A0: lundi 30 janvier 2017 15:59 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: sfc@ietf.org > Objet=A0: RE: Some comments on draft-ietf-sfc-control-plane/ >=20 > Hey Med, sorry for taking so long to get back to you. The last few days > have been fairly hectic for me. >=20 > Please see inline. >=20 > Thanks, >=20 > Kyle >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Wednesday, January 25, 2017 2:58 AM > > To: Kyle Larose > > Cc: sfc@ietf.org > > Subject: RE: Some comments on draft-ietf-sfc-control-plane/ > > > > Hi Kyle, > > > > Thank you for the comments. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Kyle Larose [mailto:klarose@sandvine.com] Envoy=E9=A0: mardi 2= 4 > > > janvier 2017 17:32 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: sfc@itef.= org > > > Objet=A0: Some comments on draft-ietf-sfc-control-plane/ > > > > > > Hello Mohamed, > > > > > > > > > I'm starting to look into developing a control plane protocol for > > > classifiers (C1 in the draft), so I've taken a look at the sfc > > control > > > plane draft. I have a few comments on it. I'll start with the > > issue > > > that stood out the most for me. > > > > > > First, thanks for authoring this draft. It definitely captured a > > bunch > > > of concepts and ideas that I'll need to think about. > > > > [Med] Thanks. > > > > > > > > Back to the issue: after reading through the document, I had some > > > concerns regarding separation of responsibility among the > > interfaces. > > > In particular, some information and actions, which I felt belonged > > in > > > C2 were in C1, and vice versa. I used the SFC Architecture, RFC > > 7665, > > > as a guide in deciding which interface should be responsible for > > what. > > > My concerns could be based entirely on my narrow interpretation of > > it. > > > Please let me know if I've taken too narrow a view. :) > > > > > > As an example of something belonging in C2, but not C1: > > > > > > Section 3.3.1: > > > " The classifier may be notified (regularly or upon eventual > > change) > > > by > > > the control plane about the available SFs (including the SFFs > > they > > > are attached to) or be part of the service function discovery > > > procedure. > > > " > > > > > > What is the purpose behind this? > > > > [Med] This is an **optional** feature that was requested by the WG > > participants to support an SFC distributed model (Ron may further > > elaborate as he asked for it). For example, this feature allows a > > classifier to bind flows as a function of the available paths and SF > > instances. Then, packets can be bound to a fully or partially > > constrained path accordingly. Also, the discovery information > > provided to a classifier may be used for load distribution purposes. > > >=20 > [Kyle] I didn't really think of that use-case. The load distribution one > in particular is interesting. > I see the classifier as a mapper of packets to paths, so I've been > thinking of C1 as an interface for mapping packet information to paths. > Mapping packets to service functions and from there to paths seems like a > higher level concept. On the one hand, I think that keeping C1 purely > about "packet -> path" will lead to simpler protocols. On the other hand, > to allow the use-case you suggested, we'd need to add new interfaces, and > as you've said below, you don't really want to do that. >=20 > But, I could ask this: if we constrain C1 to talk about only "packet -> > path", then it can probably be fairly well defined, and it should be easy > to reason about. However, if we relax it to allow other information such > as service functions just to support a few use-cases, why not relax it to > allow all information that could be relevant to SFC? I'm sure some smart > people could think of many use cases for that. Then again, as I say below= , > I could very well just be approaching this document from the wrong > perspective entirely, >=20 [Med] Your observation are really fair one. As an individual, I'm for restr= icting the classifier to the "packet/flow=3D=3D>path", but as an editor of = the document I integrated comments from the WG participants that wanted to = have such feature included as optional one. =20 > > Of course, those cases may be implemented without involving the > > classifier by invoking C2 as recorded in Section 3.3.2: > > > > " This interface is also used by the SFF to report the > > connectivity to > > their attached (including embedded) SFs. Local means may be > > enabled > > between the SFC-aware SFs and SFFs to allow for the dynamic > > attachment of SFs to an SFF and/or discovery of SFs by an SFF" > > > > > > Given that the classifiers are not > > > conceptually "attached" to SFs on the data plane, doesn't it seem > > > wrong to have the classifiers be aware of the SFs on the control > > plane? > > > > [Med] See above. The idea is to allow for a distributed model to > > adjust paths (and implement other policies at the classifier). > > > > > I understand the classifiers may be co-located with SFs, but I > > don't > > > see how their functionality would, or should, depend on the > > > availability of SFs in the data plane. > > > > [Med] The SF/SFF discovery information is not MANDATORY to be > > provided to a classifier, but may help in some deployment cases > > (such as those mentioned above). > > > > > > > > One use-case I could see for this is having the classifier map a > > > packet to an explicit set of SFs. However, the classifier maps > > packets > > > to paths, not SFs. Should the logic of mapping of packet to an SF > > not > > > be performed by conjoining C1 and C2 at the controller itself? > > > > [Med] That's indeed possible. See the excerpt of Section 3.3.2 > > provided above. > > > > Using C1 to indicate SF > > > mapping seems to blur the lines between C1 and C2. > > > > > > After writing the above, I saw section 4.10.2. It seems to kind of > > > match what I proposed above. But, I still ask: is this truly the > > > responsibility of the classifier, or something which may be co- > > located > > > with it? If the latter, should it not be a different interface? > > > > [Med] Good point. We can always decompose a single interface into a > > set of interfaces following some functional rationale, but the > > reasons why I prefer to not add a new one are the following: > > * Maintain the SFC control plane architecture as simple as possible. > > * How a classifier decides to bind flows/packets to a given chain is > > completely policy-based and deployment-specific. There may be simple > > policies that do not require a feedback from the SFC-enabled domain > > (e.g., blindly bind a flow to a chain based on the transport > > coordinates) and advanced policies that require additional > > information to be enforced (e.g., bind a flow to a chain as a > > function of available paths, bind a flow to a chain as a function of > > available SF instances, bind a flow to a chian while avoiding to > > cross a given network region, etc.). > > >=20 > [Kyle] I guess one of my challenges here is that I'm thinking as a > protocol developer, and I'm seeing stuff I would never want to put into m= y > protocol. > So, maybe I just need to think of this from a different perspective. > Rather than saying what must or must not be in a protocol implementing C1= , > this document is just providing suggestions and things to think about? [Med] The document calls out things that must be supported and others that = are "nice to have". > My concern is that if this is actually trying to put down requirements fo= r > a set of protocols implement C1, a large number of optional requirements > aren't really going to provide a lot of guidance. >=20 [Med] Perhaps, the WG needs to check the language to make sure that must/sh= ould/may are really justified for each item. =20 > > > > > > > > > Further, section 3.3.3 has an example of something belonging in > > C1, > > > but not C2: > > > > > > " SF execution status: Some SFs may need to send information > > to the > > > control plane to fine tune SFPs. For example, a threat- > > detecting > > > SF can periodically send the threat characteristics via this > > > interface, such as high probability of threat with packet of a > > > given size. The control plane can then add an appropriate > > > matching criteria to SFF to steer traffic to a scrubbing > > center." > > > > > > Should this information not be fed back to the classifier via C1, > > > rather than C2? > > > > [Med] It can of course! Please note that the text starts with "For > > example, ". If the decision is to use a distinct service path, then > > a classifier is likely to be invoked by means of C1. But if the > > entity managing the SFC domain does not want to alter the service > > path, a local policy can be provisioned to an SFF via C2 to redirect > > subsequent packets to a scrubbing center. > > >=20 > [Kyle] Is it not altering the path, though? It feels like we're just > defining a path through a sideways channel -- we're moving a packet to a > path which isn't specified through the normal mechanisms. If it were > specified normally, I.e. through classify in C1, specify forwarding logic > in C2, then the SF could just reclassify the packet, [Med] An SF cannot reclassify a packet. or somehow indicate > that it wants reclassification (for example, via metadata). [Med] Yes, but this would require that a classifier will be on path upstrea= m... and immediately after that SF's service is consumed.=20 This > reclassification would not alter the previous path of the packet, since > the new path already existed. In that case, C2 would just need to allow > for indicating the information that would lead to reclassification, and > the complex packet information necessary to do the classification could b= e > transmitted in C1. Of course, perhaps the information I'm suggesting bein= g > indicated in C2 is no less complicated than what is being moved to C1. :) [Med] :) From nobody Thu Feb 16 22:54:39 2017 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 22DCC1293F0 for ; Thu, 16 Feb 2017 22:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 e-1AVu4gP9VE for ; Thu, 16 Feb 2017 22:54:36 -0800 (PST) Received: from relais-inet.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 828B5128874 for ; Thu, 16 Feb 2017 22:54:36 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 0A7D0203C9; Fri, 17 Feb 2017 07:54:35 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id B445C120055; Fri, 17 Feb 2017 07:54:34 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 07:54:34 +0100 From: To: Sumandra Majee , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHSbcis3hdHLiI6x0KplOR4MfXXEaE3IioAgBDY9oCAC5bFAIAZYoxw Date: Fri, 17 Feb 2017 06:54:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E13F77@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933009DE9028@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <8D1EA927-4722-425D-B776-A82948176AF0@f5.com> In-Reply-To: <8D1EA927-4722-425D-B776-A82948176AF0@f5.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 06:54:38 -0000 SGkgU3VtYW5kcmEsIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBTdW1hbmRyYSBNYWplZSBbbWFp bHRvOlMuTWFqZWVARjUuY29tXQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDEgZsOpdnJpZXIgMjAx NyAwMzo1Ng0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKb2VsIE0uIEhhbHBl cm47IHNmY0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW3NmY10gSG93IHRvIHByb2dyZXNzIG91 ciBjb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyBkb2N1bWVudA0KPiANCj4gTWVkLA0KPiANCj4g U29ycnkgZm9yIHRoZSBkZWxheSwgSSBndWVzcyBuZXcgeWVhciBzdGFydGVkIHdpdGggYSBiYW5n IOKYuS4NCj4gQmVmb3JlIHdlIGdvIGludG8gZGV0YWlsIEkgYWdyZWUgdGhhdCB0aGF0IGEgY29t bW9uL3N0YW5kYXJkaXplZCBpbnRlcmZhY2UNCj4gdG8gYW4gZW50aXR5ICh5b3UgY2FsbCBpdCBj b250cm9sbGVyIGFuZCBJIGNhbGwgaXQgbWFuYWdlcikNCg0KW01lZF0gR3JlYXQhIEJUVywgdGhl IHNmYy1jb250cm9sIGRvY3VtZW50IGRvZXMgbm90IGNhbGwgZm9yIGEgc2luZ2xlIGNlbnRyYWwg ZW50aXR5OyBzZWN0aW9uIDMuMiBzYXlzOiANCg0KICAgVGhlIFNGQyBjb250cm9sIHBsYW5lIGNh biBiZSAobG9naWNhbGx5KSBjZW50cmFsaXplZCwgZGlzdHJpYnV0ZWQgb3INCiAgIGEgY29tYmlu YXRpb24gdGhlcmVvZi4gIFdoZXRoZXIgb25lIG9yIG11bHRpcGxlIFNGQyBDb250cm9sIEVsZW1l bnRzDQogICBhcmUgZW5hYmxlZCBpcyBkZXBsb3ltZW50LXNwZWNpZmljLiAgDQoNCiBpcyB2ZXJ5 IG11Y2gNCj4gcmVxdWlyZWQuIFRoZXJlIHNob3VsZCBiZSBhIHNldCBvZiBpbnRlcmZhY2UgdGhh dCBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSwNCj4gZm9yIGV4YW1wbGUgdGhlIGludGVyZmFjZSAo dGhpbmsgQzIpIGJldHdlZW4gQ29udHJvbGxlciB0byBTRkYgaW4gb3JkZXIgdG8NCj4gZGlzdHJp YnV0ZSBwYXRoL25leHRob3AgaW5mb3JtYXRpb24uIEkgd291bGQgbGlrZSB0byBzZWUgYSBzY2hl bWEgZXRjLg0KDQpbTWVkXSBGYWlyIGNvbW1lbnQuIA0KDQogZm9yDQo+IHRoYXQgaW50ZXJmYWNl IHNvIHdlIGFsbCBjYW4gaW1wbGVtZW50IGl0IGFuZCBleHBlY3QgdG8gd29yayB3aXRoIGFueQ0K PiBjb250cm9sbGVyLg0KPiANCj4gVGhlIGNsYXNzaWZpZXIgbWF5IG9yIG1heSBub3QgYmUgcGFy dCBvZiBTRkMgY29udHJvbGxlciBkb21haW4uIFllcywgdGhlcmUNCj4gbmVlZHMgdG8gYmUgYSBt YXBwaW5nIG9mIDxSVUxFPiB0byA8Q0hBSU4+IGJ1dCBhIGNsYXNzaWZpZXIgbWF5IGNob29zZSB0 bw0KPiBhY3F1aXJlIHRoaXMgcnVsZQ0KPiAtIEZyb20gUENSRg0KPiAtIFNETiBDb250cm9sbGVy DQo+IC0gUkVTVC9TT0FQIG5hbWUgeW91ciBpbnRlcmZhY2UgQVBJDQo+IC0gT2xkIHN0eWxlIENM SQ0KPiAtIEluIHRoaXMgcGFydGljdWxhciBjYXNlIGl0IGlzIHNvbWV0aW1lcyBhIHNjcmlwdCB0 aGF0IHNldHMgdGhlIGJpbmRpbmcuDQo+IA0KDQpbTWVkXSBBZ3JlZS4gVGhpcyBpcyByZWFsbHkg ZGVwbG95bWVudC1zcGVjaWZpYy4NCg0KPiBJbiBmYWN0LCBvdXIgZXhwZXJpZW5jZSBpcyB0aGF0 IGV2ZXJ5IGRlcGxveW1lbnQgaGFzIGRpZmZlcmVudCBuZWVkLA0KPiBkaWZmZXJlbnQgYXV0b21h dGlvbiBuZWVkLiBPbmUgbWF5IGNob29zZSB0byB1c2UgY2xvdWQgZm9ybWF0aW9uIHRlbXBsYXRl Lg0KPiBTbyBzb21lIG9mIHlvdXIgcXVlc3Rpb25zIGJlbG93IGNvdWxkIG5vcC4gSSB0aGluayBp dCB3aWxsIGJlIGdvb2QgdG9waWMNCj4gZm9yIGRpc2N1c3Npb24gYXMgd2VsbCBzb21lIHByZXNl bnRhdGlvbi4NCj4gDQo+IE9uY2Ugd2Ugc2VwYXJhdGUgb3V0IHRoZSBjbGFzc2lmaWVyIGFuZCBT RkYvU0YgdGhlbiB0aGUgc2V0IG9mIGludGVyZmFjZXMNCj4gYXJlIHNtYWxsZXIgKGFuZCB0aGUg Y2xhc3NpZmllciBjb21wbGV4aXR5IGFuZCByaWNobmVzcyBjYW4gYmUgdHVuZWQgZm9yDQo+IHRo ZSBkZXBsb3ltZW50LiBZZXMgaXQgZG9lcyBzdXBwb3J0IHByaW9yaXR5IG9yZGVyLCBlbWJlZGRl ZCBzY3JpcHQsIGFwcA0KPiBpZGVudGlmaWNhdGlvbiBhbmQgYWxsIHRoYXQgaW4gYWR2YW5jZWQg Zm9ybSBvciBpdCBjb3VsZCBhcyBkdW1iIGFzIHBrdA0KPiBtYXRjaGluZyBhY2wgaW4gc3dpdGNo IGh3LiBJIG1heSBuZWVkIHNwZWVkIG9ubHkgc29tZXRpbWVzKS4NCj4gDQo+ICoqIFtNZWRdRG9l cyB5b3VyIGltcGxlbWVudGF0aW9uIGFsbG93IHRvIGRldGVjdCB0aGUgbGl2ZW5lc3Mgb2YgU0Zz Pw0KPiBZZXMgaXQgZG9lcy4gQnV0IGRvIEkgbmVlZCBjb250cm9sbGVyIHRvIGRvIHRoaXMsIG5v dCBhbHdheXMuDQoNCltNZWRdIFRoYW5rIHlvdSBmb3Igc2hhcmluZyB0aGUgaW5mb3JtYXRpb24u IFdoYXQgeW91IGRlc2NyaWJlZCBpcyBhbGlnbmVkIHdpdGggdGhlIGN1cnJlbnQgZXhwZWN0ZWQg YmVoYXZpb3IgaW5jbHVkZWQgaW4gdGhlIENQIHJlcXVpcmVtZW50cyBkcmFmdDogDQoNCiogIkkg bmVlZCBjb250cm9sbGVyIHRvIGRvIHRoaXMiICAgIA0KDQogICBJbiBwYXJ0aWN1bGFyLCB0aGUg Y29udHJvbCBwbGFuZSBtdXN0IGFsbG93IHRvIGR5bmFtaWNhbGx5IGRldGVjdA0KICAgdGhhdCBh biBTRiBpbnN0YW5jZSBpcyBvdXQgb2Ygc2VydmljZSBhbmQgbm90aWZ5IHRoZSByZWxldmFudCBD b250cm9sDQogICBFbGVtZW50IGFjY29yZGluZ2x5LiAgVGhlIGxpdmVuZXNzIGluZm9ybWF0aW9u IG1heSBiZSBhY3F1aXJlZA0KICAgZGlyZWN0bHkgZnJvbSBTRnMgb3IgaW5kaXJlY3RseSBmcm9t IG90aGVyIG1hbmFnZW1lbnQgYW5kIGNvbnRyb2wNCiAgIHN5c3RlbXMgaW4gdGhlIG9wZXJhdGlv bmFsIGVudmlyb25tZW50Lg0KDQoqICIuLiwgbm90IGFsd2F5cyINCg0KICAgTG9jYWwgZmFpbHVy ZSBkZXRlY3QgYW5kIHJlcGFpciBtZWNoYW5pc21zIG1heSBiZSBlbmFibGVkIGJ5IFNGQy0NCiAg IGF3YXJlIG5vZGVzLiAgQ29udHJvbCBFbGVtZW50cyBtYXkgYmUgZmVkIGRpcmVjdGx5IG9yIGlu ZGlyZWN0bHkgd2l0aA0KICAgaW5wdXRzIGZyb20gdGhlc2UgbWVjaGFuaXNtcy4NCg0KIFRoaXMg Y291bGQNCj4gaGF2ZSBiZWVuIGJ1aWx0IGludG8gdGhlIHJvb3Qgb2YgdGhlIGNoYWluLCBjYW4g YmUgZG9uZSBmcm9tIHRoZSBTRiBwcm94eQ0KPiAoaWYgaXQgaXMgcHJlc2VudCwgaXQgb2Z0ZW4g aXMpLiBBIFNGIGFibGUgcmVwbHkgSGVsbG8gZG9lc27igJl0IG1lYW4gaXQgaXMNCj4gYWN0dWFs bHkgc2VydmluZyB1c2VyIHRyYWZmaWMuDQoNCltNZWRdIEZ1bGx5IGFncmVlZC4gVGhpcyBpcyB0 aGUgaW50ZW50IG9mIHRoaXMgdGV4dCBpbiB0aGUgZHJhZnQ6IA0KDQogICBCZWNhdXNlIGEgbm9k ZSBlbWJlZGRpbmcgYW4gU0YgY2FuIGJlIHJlc3BvbnNpdmUgZnJvbSBhIHJlYWNoYWJpbGl0eQ0K ICAgc3RhbmRwb2ludCAoZS5nLiwgSVAgbGV2ZWwpIHdoaWxlIHRoZSBmdW5jdGlvbiBpdCBwcm92 aWRlcyBtYXkgYmUNCiAgIGJyb2tlbiAoZS5nLiwgYSBOQVQgbW9kdWxlIG1heSBiZSBkb3duKSwg YWRkaXRpb25hbCBtZWFucyB0byBhc3Nlc3MNCiAgIHdoZXRoZXIgYW4gU0YgaXMgdXAgYW5kIHJ1 bm5pbmcgYXJlIHJlcXVpcmVkLiAgVGhlc2UgbWVhbnMgbWF5IGJlDQogICBzZXJ2aWNlLXNwZWNp ZmljLg0KDQogVGhlIHBvaW50IG9mIHZpZXcgZnJvbSBjb250cm9sbGVyIGlzIG5vdA0KPiB3aGF0 IGEgdXNlciB0cmFmZmljIGlzIGdvaW5nIHRocnUuIEhvd2V2ZXIsIGEgY29udHJvbGxlciBpcyB0 aGUgcmlnaHQNCj4gcGxhY2UgdG8gcHJvdmlkZSBhIHNpbmdsZSB2aWV3IG9mIHdob2xlIGNoYWlu Lg0KDQpbTWVkXSBBZ3JlZS4gDQoNCj4gDQoNCltNZWRdIFRoYW5rIHlvdSBmb3IgeW91ciBraW5k IGFuc3dlci4gVGhpcyBpcyBleGFjdGx5IHRoZSBkaXNjdXNzaW9uIEkgd2FzIHNlZWtpbmcgZnJv IHdoZW4gSSBzZW50IHRoaXMgc2V0IG9mIHF1ZXN0aW9ucy4gTm9uZSBvZiB0aGUgcG9pbnRzIHlv dSBwcm92aWRlZCBhbmQgdGhvc2UgaW4gbXkgaW5pdGlhbCBzZXQgb2YgcXVlc3Rpb25zIGFyZSBj b3ZlcmVkIGluIG90aGVyIFNGQyBkb2N1bWVudHMuIEkgZG8gc3RpbGwgdGhpbmsgdGhlcmUgaXMg YSBuZWVkIHRvIGhhdmUgdGhvc2UgY292ZXJlZCBhbmQgYSBjb21tb24gdW5kZXJzdGFuZGluZyBv ZiB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgZGVzY3JpYmVkLg0KDQoqIFdoYXQgaXMgdGhlIGluZm9y bWF0aW9uIHRoYXQgaXMgbmVlZGVkIGZvciB5b3VyIGNvbnRyb2xsZXIgYXQgYm9vdHN0cmFwPyAN CiogRG9lcyB5b3VyIGNvbnRyb2xsZXIgcmVxdWlyZSBhIHBlcm1hbmVudCBzZXNzaW9uIHRvIGJl IG1haW50YWluZWQgd2l0aCB0aGUgU0ZDIGNvbnRyb2xsZWQgZGV2aWNlPw0KKiBEb2VzIHlvdXIg Y29udHJvbGxlciBhbGxvdyB0byBpbnN0cnVjdCB0aGUgdW5kZXJseWluZyBTRkMtYXdhcmUgbm9k ZSBhYm91dCB0aGUgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gdG8gYmUgdXNlZD8gIA0KKiBEb2Vz IHlvdXIgaW1wbGVtZW50YXRpb24gYWxsb3cgdG8gY29udHJvbCB0aGUgc2VtYW50aWMgb2YgY29u dGV4dCBpbmZvcm1hdGlvbiwgdGhlaXIgc2NvcGUsIGFuZCBob3cgaXQgc2hvdWxkIGJlIGNvbnN1 bWVkL3N1cHBsaWVkPw0KKiBEb2VzIHlvdXIgaW1wbGVtZW50YXRpb24gYWxsb3cgYSBjbGFzc2lm aWVyIHRvIGF1dG8tY2xlYW4gaXRzIGVudHJpZXMgYnkgbWVhbnMgb2YgYSBsaWZldGltZT8NCiog RG9lcyB5b3VyIGltcGxlbWVudGF0aW9uIGFsbG93IHRvIHJlbW92ZSBzdGFsZSBjbGFzc2lmaWNh dGlvbiBlbnRyaWVzPw0KKiBEb2VzIHlvdXIgaW1wbGVtZW50YXRpb24gYWxsb3cgdG8gcmV0cmll dmUgdGhlIGxpc3Qgb2YgU0ZzIHRoYXQgYXJlIGF0dGFjaGVkIHRvIGEgZ2l2ZW4gU0ZGPw0KKiBE b2VzIHlvdXIgaW1wbGVtZW50YXRpb24gYWxsb3cgdG8gaW5zdHJ1Y3QgYW4gU0ZGIGFib3V0IHRo ZSBsaXN0IG9mIFNGcyBpdCBjYW4gc2VydmljZT8NCiogRG9lcyB5b3VyIGltcGxlbWVudGF0aW9u IGluc3RydWN0IHRoZSBjbGFzc2lmaWVyIGFib3V0IHRoZSB0aWUtYnJlYWsgcnVsZXMgdG8gYmUg Zm9sbG93ZWQgd2hlbiBtb3JlIHRoYW4gb25lIGNsYXNzaWZpY2F0aW9uIGVudHJ5IGlzIG1hdGNo ZWQ/IA0KKiBEb2VzIHlvdXIgaW1wbGVtZW50YXRpb24gYWxsb3cgYW4gU0ZGIHRvIHJlbW92ZSBz dGFsZSBlbnRyaWVzIHdpdGhvdXQgdGhlIGhlbHAgb2YgdGhlIGNvbnRyb2xsZXI/DQoqIERvZXMg eW91ciBpbXBsZW1lbnRhdGlvbiBhbGxvdyB0byBkZXRlY3QgdGhlIGxpdmVuZXNzIG9mIFNGcz8N CiogRG9lcyB5b3VyIGltcGxlbWVudGF0aW9uIGFsbG93IHRvIGNvbnRyb2wgdGhlIGJlaGF2aW9y IHdoZW4gYW4gU0YgaXMgdG8gYmUgd2l0aGRyYXduPw0KKiAuLi4gICANCg0K From nobody Thu Feb 16 23:21:53 2017 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 CDAAA120725 for ; Thu, 16 Feb 2017 23:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 arp6rPTHjTVl for ; Thu, 16 Feb 2017 23:21:51 -0800 (PST) Received: from relais-inet.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 F28561294FC for ; Thu, 16 Feb 2017 23:21:50 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 5BEC06026A; Fri, 17 Feb 2017 08:21:49 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 421004004C; Fri, 17 Feb 2017 08:21:49 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 08:21:48 +0100 From: To: "adrian@olddog.co.uk" , "sfc@ietf.org" Thread-Topic: [sfc] O-bit behavior in NSH spec Thread-Index: AdKHznKalxPKklEDRqOqF5nO++eCgQBHOx9A Date: Fri, 17 Feb 2017 07:21:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E13FA3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> In-Reply-To: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 07:21:53 -0000 Hi Adrian,=20 FWIW: * The first part of the text you quoted is the outcome of the discussion re= lated to this ticket: https://www.ietf.org/mail-archive/web/sfc/current/msg= 03447.html * The full text included as it appears in -11 was agreed in this thread: ht= tps://mailarchive.ietf.org/arch/msg/sfc/wafNWPiS0_ROfy_pJZmSZhlu0fU=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > Envoy=E9=A0: mercredi 15 f=E9vrier 2017 22:00 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] O-bit behavior in NSH spec >=20 > Hi, >=20 > I think it is right that the NSH spec only minimally describe OAM, but I > want to > double check the intention of a couple of things here. >=20 > Section 3.2 says: >=20 > > O bit: Setting this bit indicates an Operations, Administration, and > > Maintenance (OAM) packet. The actual packet format and processing of > > SFC OAM messages is outside the scope of this specification (see [I- > > D.ietf-sfc-oam-framework]). > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > > OAM procedures, SHALL discard packets with O-bit set. >=20 > 1. Isn't the first paragraph actually making a decision about the meaning > of the O bit? That is, it is saying that the packet is an OAM packet? > Would it be better to defer this type of decisions and say something a > little more vague such as... >=20 > > O bit: Setting this bit indicates that the NSH packet contains > Operations, > > Administration, and Maintenance (OAM) data. The actual packet format > > and processing of SFC OAM data and how that data is carried in an NSH > > packet is outside the scope of this specification (see > > [I-D.ietf-sfc-oam-framework]). >=20 > 2. Do we really want OAM packets discarded rather than passed through? > That substantially minimises the utility of any OAM. > Surely we want to specify >=20 > > SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC > > OAM procedures, SHALL process and forward packets with the O bit set > > as normal. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 17 06:15:32 2017 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 17ED91295C9 for ; Fri, 17 Feb 2017 06:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 tcp_63p7ccLA for ; Fri, 17 Feb 2017 06:15:28 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADB4129465 for ; Fri, 17 Feb 2017 06:15:28 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id A35E9100329; Fri, 17 Feb 2017 15:15:26 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 8010518006E; Fri, 17 Feb 2017 15:15:26 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 15:15:26 +0100 From: To: Eric C Rosen , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHSe/Zq3hdHLiI6x0KplOR4MfXXEaFtURsQ Date: Fri, 17 Feb 2017 14:15:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E1440A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> In-Reply-To: <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 14:15:30 -0000 Hi Eric,=20 Thank you for sharing your thoughts.=20 I have comments to some of the points you mentioned in your message, but I = will reply to only one of them.=20 You said, "These reference points do not correspond to anything real.". I'm= afraid I disagree here. If you take for example, the interface to classifi= ers, this is something that exists even in current deployments. Think about= PCRF/PCEF in a 3GPP PCC architecture and the like.=20 I have no problem to abandon the draft if this is what the WG wants, but I'= m afraid we need a document to define the minimum set of capabilities to be= honored by a solution that claims to address SFC control.=20 For example, I checked your BGP CP draft to check if it addresses the CP re= quirement in the SFC CP draft. Many of these CP requirements are included i= n your proposal but many others are missing, e.g., * I don't see how classification rules are installed/removed/updated. * I don't see any features to associate classification and forwarding entri= es with validity lifetime. * I don't see how the CP sets the SI at classifiers * I don't see how the CP set the semantic of a metadata per each chain, sco= pe, etc. * I don't see how the CP indicates the behavior to follow when a metadata i= s consumed * I don't see how an SFC proxy in instructed to insert/supply metadata on b= ehalf of SFC-unaware SFs * I don't see the CP behavior when an SF is to be withdrawn * I don't see how an SFC proxy is instructed about the SFs to service. * Etc.=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Eric C Rosen > Envoy=E9=A0: mardi 31 janvier 2017 20:16 > =C0=A0: Joel M. Halpern; sfc@ietf.org > Objet=A0: Re: [sfc] How to progress our control plane requirements docume= nt >=20 > I believe the control plane requirements document should be abandoned by > the WG. >=20 > The document attempts to describe the information needed by the various > components (e.g., SF, SFF, classifier) of the architecture. However, RFC > 7665 and draft-ietf-sfc-nsh already describe the information needed by > the components, and the control plane requirements document does not add > anything of substance. >=20 > The requirements document attempts to organize the information into four > "interface reference points", but as other have pointed out already, > this method of organization just is not particularly useful, and is not > helpful when designing a control plane architecture. These reference > points do not correspond to anything real. If the document advances, > someone will ask questions like "is this protocol element part of the > implementation of interface C2 or is it part of the implementation of > interface C3?", and the answer will often be "well, you could think of > it as part of C2, or you could think of it as part of C3, or maybe as > part of both, depending on your deployment scenario, but really it > doesn't matter". In this way, the document creates extra work without > adding extra value. >=20 > When I first looked at the document, I thought it was going to provide a > set of APIs allowing one to build an SF without knowing what the control > plane would be. That might be useful (if it is even possible), but the > document does not seem to provide any such thing. >=20 > There is important information that is absent from the prior documents, > such as the information needed to support the interaction of the service > layer components with the underlying transport, but that information is > also absent from the requirements document. >=20 > I don't think this sort of requirements document is helpful when > attempting to design a control plane solution, it just gets in the way. >=20 >=20 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 17 08:29:20 2017 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 7FC43129AD0 for ; Fri, 17 Feb 2017 08:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 vNYUdSy-k_ei for ; Fri, 17 Feb 2017 08:29:16 -0800 (PST) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.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 BCF9B129ACF for ; Fri, 17 Feb 2017 08:29:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A2FC61C0233; Fri, 17 Feb 2017 08:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487348956; bh=lvJhd9l8yEARRxpQGqrGK5g+zXz2XZUHwh7SekGw5do=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZH/ejNyNI4lCSjElncsSYgdEQKwx52t9TPDQkZMp+02gHhNL+qjL3KPR7dPNClFcJ JYNiCA9Lelguimy1hIE4INrHCJd0eLGphYDavn6CsrmJ+1zFqUGW2jEccloeenCr0j Fa/34qZT31XbjTVhb673tLqkok/fKifLXDpLn2iQ= 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 226ED3C2B24; Fri, 17 Feb 2017 08:29:16 -0800 (PST) To: mohamed.boucadair@orange.com, "sfc@ietf.org" References: <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> <787AE7BB302AE849A7480A190F8B933009E1440A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: Date: Fri, 17 Feb 2017 11:29:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E1440A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 16:29:18 -0000 Med, let me try to restate the point Eric and others made in the interim, which the chairs and ADs consider cogent. Yes, the BGP control plane draft perfroms some of the functions you identify. It provides a coherent piece of a control plane solution. This (the BESS SFC draft) does not attempt to solve all control plane problems for SFC. And we would not expect it to. The result is that there is no meaningful question we can ask of the BESS SFC draft using the existing control plane document reference points. It does not provide all of C1, C2, C3, or C4. Once we looked at that, we realized that any given protocol effort on the control plane side was likely to run into the same thing. The purpose of the control plane requirements document, as we understand it, is not to tell the SFC WG or SFC dta plane implementors what they need to implement to talk to control. it is to tell control protocl designers and implementors what they need to provide, in terms of capabilities, to have solutions that work with SFC. Therefore, the decomposition in the control plane document needs to correspond to a meaningful grouping in the control plane. If all we have is a list of requriements that control plane efforts have to pick and choose among, it will not help them any. That may mean that we have no useful way to present these points. That would be unfortunate. But we need to avoid pretending something is useful when we have been told multiple times that it is not. Yours, Joel On 2/17/17 9:15 AM, mohamed.boucadair@orange.com wrote: > Hi Eric, > > Thank you for sharing your thoughts. > > I have comments to some of the points you mentioned in your message, but I will reply to only one of them. > > You said, "These reference points do not correspond to anything real.". I'm afraid I disagree here. If you take for example, the interface to classifiers, this is something that exists even in current deployments. Think about PCRF/PCEF in a 3GPP PCC architecture and the like. > > I have no problem to abandon the draft if this is what the WG wants, but I'm afraid we need a document to define the minimum set of capabilities to be honored by a solution that claims to address SFC control. > > For example, I checked your BGP CP draft to check if it addresses the CP requirement in the SFC CP draft. Many of these CP requirements are included in your proposal but many others are missing, e.g., > > * I don't see how classification rules are installed/removed/updated. > * I don't see any features to associate classification and forwarding entries with validity lifetime. > * I don't see how the CP sets the SI at classifiers > * I don't see how the CP set the semantic of a metadata per each chain, scope, etc. > * I don't see how the CP indicates the behavior to follow when a metadata is consumed > * I don't see how an SFC proxy in instructed to insert/supply metadata on behalf of SFC-unaware SFs > * I don't see the CP behavior when an SF is to be withdrawn > * I don't see how an SFC proxy is instructed about the SFs to service. > * Etc. > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Eric C Rosen >> Envoyé : mardi 31 janvier 2017 20:16 >> À : Joel M. Halpern; sfc@ietf.org >> Objet : Re: [sfc] How to progress our control plane requirements document >> >> I believe the control plane requirements document should be abandoned by >> the WG. >> >> The document attempts to describe the information needed by the various >> components (e.g., SF, SFF, classifier) of the architecture. However, RFC >> 7665 and draft-ietf-sfc-nsh already describe the information needed by >> the components, and the control plane requirements document does not add >> anything of substance. >> >> The requirements document attempts to organize the information into four >> "interface reference points", but as other have pointed out already, >> this method of organization just is not particularly useful, and is not >> helpful when designing a control plane architecture. These reference >> points do not correspond to anything real. If the document advances, >> someone will ask questions like "is this protocol element part of the >> implementation of interface C2 or is it part of the implementation of >> interface C3?", and the answer will often be "well, you could think of >> it as part of C2, or you could think of it as part of C3, or maybe as >> part of both, depending on your deployment scenario, but really it >> doesn't matter". In this way, the document creates extra work without >> adding extra value. >> >> When I first looked at the document, I thought it was going to provide a >> set of APIs allowing one to build an SF without knowing what the control >> plane would be. That might be useful (if it is even possible), but the >> document does not seem to provide any such thing. >> >> There is important information that is absent from the prior documents, >> such as the information needed to support the interaction of the service >> layer components with the underlying transport, but that information is >> also absent from the requirements document. >> >> I don't think this sort of requirements document is helpful when >> attempting to design a control plane solution, it just gets in the way. >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Feb 17 08:30:32 2017 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 14B68129A36 for ; Fri, 17 Feb 2017 08:30:31 -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] 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 Gf_PZ_65dceW for ; Fri, 17 Feb 2017 08:30:29 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3071294A7 for ; Fri, 17 Feb 2017 08:30:28 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1HGUQJO003750; Fri, 17 Feb 2017 16:30:26 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1HGUMdl003711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2017 16:30:24 GMT From: "Adrian Farrel" To: , "'Eric C Rosen'" , "'Joel M. Halpern'" , References: <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> <787AE7BB302AE849A7480A190F8B933009E1440A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E1440A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 17 Feb 2017 16:30:19 -0000 Message-ID: <0bab01d2893b$249ab480$6dd01d80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHufCl/ZYPQW/nW3m+JQQIVxR2GlQKf58g5AfuZgKKhEJ0z4A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22892.001 X-TM-AS-Result: No--6.304-10.0-31-10 X-imss-scan-details: No--6.304-10.0-31-10 X-TMASE-MatchedRID: oHOSwQSJZWgwJ6xbTjBa5pmug812qIbzkT7cMJfe6JswyfWtyopBqAef 5FoKtUGzwLP2FM14P7ZUVc1kcLRKDmy36MnQs0Azt1AhvyEKdj5Rv3hO9k9DQtJgDNnoqapaSE9 DR4rZzFvoHgrZ+UltMZILXnnMR2TbCaIwzQMUe5ITRDzcDa8P6xHlzzcojFNOa0JExaBslTl9xz 0ps7BMyJmqR+phw++QP4LG9bOSoImqYtZoSKdB4TNKWYiz0CE6HJJXhOFmNVsifM7JMNHW6we4u JExVhKTqH/MzQmEl3qISleZ//blDXsQZsIG1c2Hw2taljzThMZgkm9mZ2rZHkS/boWSGMtd+r6f KqtIz3YHjlcKOd8oVYaspB2EsWd1keidl/fOe+T3yyqfyQre4b/I3arxTrvihhC94pXkBxNx/op JOj0ieiCOphfXDxo+d2llOY3WOtgLd3u89FoqUZ4CIKY/Hg3AtOt1ofVlaoIc4jS1nsD4HfoLR4 +zsDTtICGtrjObpPJ79Bbysm0WQnqdn9OhMup/kAMhEDYOK1+Q9am3131SoIcF0OAQFvuEQwymt xuJ6y0= Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 16:30:31 -0000 Hi Med, I'm not convinced that this draft should address the CP requirements in your draft. It seems more important to build a functional system(i.e., one that works and delivers the operational function that makes an SFC network work). Therefore, in reviewing the draft it may be more helpful to say: - this doesn't work - I need to achieve this function - this could be done better. But for completeness, here are some answers to your points: > For example, I checked your BGP CP draft to check if it addresses the CP > requirement in the SFC CP draft. Many of these CP requirements are included in > your proposal but many others are missing, e.g., > > * I don't see how classification rules are installed/removed/updated. Section 7.5 > * I don't see any features to associate classification and forwarding entries with > validity lifetime. I don't believe this to be a useful feature. But it could be added at some point. > * I don't see how the CP sets the SI at classifiers Section 7.5 > * I don't see how the CP set the semantic of a metadata per each chain, scope, > etc. It would be premature to define a control plane for something that hasn't been properly specified in the forwarding plane. But it seems to me that most SFs will not be so programmable: they will look for specific TLVs in metadata and ignore (forward) the rest, and they will add specific TLVs to the metadata. Sending CP messages will not change the behavior of SFs in this regard. Attempting to do so would be adding unnecessary complexity to the system. > * I don't see how the CP indicates the behavior to follow when a metadata is > consumed Ditto the above only more so! An SF is an SF and is not CP-programmable. > * I don't see how an SFC proxy in instructed to insert/supply metadata on behalf > of SFC-unaware SFs An SFC proxy is, in that respect, no different from the metadata component of an SF that can handle metadata. But you *have* pointed to an interesting "hole" in the architecture if it is assumed that the SFC proxy can somehow know about the state in the SFC-unaware SF and shape metadata accordingly. > * I don't see the CP behavior when an SF is to be withdrawn I don't even know what it means to "withdraw an SF". Do you mean "to take an SFI gracefully out of service"? If so, you would simply withdraw the SFIR and the route would go (as is normal in BGP). Or do you mean "to remove an SF from an SFP"? If so, 4.5.1. > * I don't see how an SFC proxy is instructed about the SFs to service. Are you asking how a proxy that severs more than one SF knows to which SF to route packets? If you are, then my answer is "don't do that!" Proxies are cheap. You can virtualise a proxy at any location. > * Etc. See section, oh... :-) Thanks, Adrian From nobody Fri Feb 17 08:41:21 2017 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 D9300129659 for ; Fri, 17 Feb 2017 08:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2Guqqwp6UVRA for ; Fri, 17 Feb 2017 08:41:18 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0665D129656 for ; Fri, 17 Feb 2017 08:41:17 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1HGfGC4016825; Fri, 17 Feb 2017 16:41:16 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1HGfCTG016814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2017 16:41:15 GMT From: "Adrian Farrel" To: , References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E13FA3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E13FA3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 17 Feb 2017 16:41:13 -0000 Message-ID: <0bb201d2893c$a8766460$f9632d20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKs4QfPsAfGu+IdxTavj2M4SM8+/wHdpbuin6nIGRA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22892.001 X-TM-AS-Result: No--23.065-10.0-31-10 X-imss-scan-details: No--23.065-10.0-31-10 X-TMASE-MatchedRID: PL66URbwWA+nykMun0J1wi4uTw19Klh6nvBHr/aFnM7U8xVbnhmOQJcI pZw8MRfrIG75C6QDJcEJ7VKkyipknzK42JVSvu3Ah2VzUlo4HVM7UrmIzxDooEw6MpTEJnCvPpm S7h7CnDrujNgdFtwvKUpO4zY8xTkR1QwDBMM4GeyNZ7kc4Uq+4xmyTBaqiJvc/RM/+SKR6qeJf9 uJ707ggts9aL9NLEGOBPwACG8gzOFjercsEJsEDPHkpkyUphL9Ud7Bjfo+5jT0IKAowY45NjU1V bTjkVv2tcBFD4AT+Ho8MXho6UtjBzJmL3yrEczIEroQVzSW9XSZYYkt8na3t5jk0EbtghtXHKth P6HC0NSRbMnKorW5L/5i49V6LCZ7tR3ZHtcq+ff0hv/rD7WVZCDPOgHqOrGC4aROJEypr9wo0Jb KOmSuUh0PwkpNBELVIxYSzkEHHHZ7EVbt+QyLTEFViy1UnYhrKIZAgzQjFt7ojnCuQ+SGxvTrP5 e8ec7Bt+odoSua73Z/JgN7Aw6tADnPxPlcuWjY3QfwsVk0UbslCGssfkpInQ== Archived-At: Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 16:41:20 -0000 Med, Thanks for the pointers. It's really helpful to see where this text came = from and why. I realise it must be aggravating to have someone come along 8 months = later and ask questions, but there we go. In fact, I find that in addition to my previous points I see another = problem SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC OAM procedures, SHALL discard packets with O-bit set. SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable parameter to enable forwarding received SFC OAM packets unmodified to the next element in the chain.=20 You cannot both have "MUST do X" and "MAY be configured to do Y" Possibly s/SHALL/SHOULD/ But also, if there is a configuration option it becomes a question of = defaults and so... OLD MAY support a configurable parameter to enable forwarding received SFC = OAM=20 NEW MAY forward received SFC OAM subject to local policy and configuration END Furthermore For non OAM packets, the O-bit MUST be cleared and MUST NOT be modified along the SFP. which is not (I hope) to imply that the O bit can be modified on an OAM = packet. In short, the text around the O bit is in need of some work. Thanks, Adrian > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: 17 February 2017 07:22 > To: adrian@olddog.co.uk; sfc@ietf.org > Subject: RE: [sfc] O-bit behavior in NSH spec >=20 > Hi Adrian, >=20 > FWIW: > * The first part of the text you quoted is the outcome of the = discussion related to > this ticket: = https://www.ietf.org/mail-archive/web/sfc/current/msg03447.html > * The full text included as it appears in -11 was agreed in this = thread: > https://mailarchive.ietf.org/arch/msg/sfc/wafNWPiS0_ROfy_pJZmSZhlu0fU >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > > Envoy=E9=A0: mercredi 15 f=E9vrier 2017 22:00 > > =C0=A0: sfc@ietf.org > > Objet=A0: [sfc] O-bit behavior in NSH spec > > > > Hi, > > > > I think it is right that the NSH spec only minimally describe OAM, = but I > > want to > > double check the intention of a couple of things here. > > > > Section 3.2 says: > > > > > O bit: Setting this bit indicates an Operations, Administration, = and > > > Maintenance (OAM) packet. The actual packet format and processing = of > > > SFC OAM messages is outside the scope of this specification (see = [I- > > > D.ietf-sfc-oam-framework]). > > > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support = SFC > > > OAM procedures, SHALL discard packets with O-bit set. > > > > 1. Isn't the first paragraph actually making a decision about the = meaning > > of the O bit? That is, it is saying that the packet is an OAM = packet? > > Would it be better to defer this type of decisions and say = something a > > little more vague such as... > > > > > O bit: Setting this bit indicates that the NSH packet contains > > Operations, > > > Administration, and Maintenance (OAM) data. The actual packet = format > > > and processing of SFC OAM data and how that data is carried in an = NSH > > > packet is outside the scope of this specification (see > > > [I-D.ietf-sfc-oam-framework]). > > > > 2. Do we really want OAM packets discarded rather than passed = through? > > That substantially minimises the utility of any OAM. > > Surely we want to specify > > > > > SF/SFF/SFC Proxy/Classifier implementations, that do not support = SFC > > > OAM procedures, SHALL process and forward packets with the O bit = set > > > as normal. > > > > Thanks, > > Adrian > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 17 11:29:43 2017 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 581C1129693 for ; Fri, 17 Feb 2017 11:29: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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMNt18tdrDCG for ; Fri, 17 Feb 2017 11:29:41 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A591129B36 for ; Fri, 17 Feb 2017 11:23:08 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 11:23:07 -0800 From: Ron Parker To: "mohamed.boucadair@orange.com" , Kyle Larose Thread-Topic: Some comments on draft-ietf-sfc-control-plane/ Thread-Index: AdJ2XSWLQrZOCvI0SHOBJJB2cIUAmAAeehxAAQuOhgADeB8v8AAbQrYg Date: Fri, 17 Feb 2017 19:23:06 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933009DE9608@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E13F43@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E13F43@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.205.79.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Some comments on draft-ietf-sfc-control-plane/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 19:29:42 -0000 Kyle, The partially constrained service path concept is a companion to the Render= ed Service Path (RSP) concept. Only RSP is guaranteed to be fully specifi= ed. The whole concept allows for distributed load balancing and late bin= ding of the RSP. If the SFP allows for this loose binding, then an SFF i= s expected to choose amongst an eligible (policy wise) SF instance. Anot= her property of this allowed behavior is the ability to perform local repai= r of failures. An SFF that hosts multiple instances of an SF and is allow= ed to make the selection is therefore also allowed to choose an alternate u= pon failure detection. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Friday, February 17, 2017 1:33 AM To: Kyle Larose Cc: sfc@ietf.org Subject: Re: [sfc] Some comments on draft-ietf-sfc-control-plane/ Hi Kyle,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Kyle Larose [mailto:klarose@sandvine.com] Envoy=E9=A0: lundi 30=20 > janvier 2017 15:59 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: sfc@ietf.org= =20 > Objet=A0: RE: Some comments on draft-ietf-sfc-control-plane/ >=20 > Hey Med, sorry for taking so long to get back to you. The last few=20 > days have been fairly hectic for me. >=20 > Please see inline. >=20 > Thanks, >=20 > Kyle >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Wednesday, January 25, 2017 2:58 AM > > To: Kyle Larose > > Cc: sfc@ietf.org > > Subject: RE: Some comments on draft-ietf-sfc-control-plane/ > > > > Hi Kyle, > > > > Thank you for the comments. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Kyle Larose [mailto:klarose@sandvine.com] Envoy=E9=A0: mardi 2= 4=20 > > > janvier 2017 17:32 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: sfc@itef.= org=20 > > > Objet=A0: Some comments on draft-ietf-sfc-control-plane/ > > > > > > Hello Mohamed, > > > > > > > > > I'm starting to look into developing a control plane protocol for=20 > > > classifiers (C1 in the draft), so I've taken a look at the sfc > > control > > > plane draft. I have a few comments on it. I'll start with the > > issue > > > that stood out the most for me. > > > > > > First, thanks for authoring this draft. It definitely captured a > > bunch > > > of concepts and ideas that I'll need to think about. > > > > [Med] Thanks. > > > > > > > > Back to the issue: after reading through the document, I had some=20 > > > concerns regarding separation of responsibility among the > > interfaces. > > > In particular, some information and actions, which I felt belonged > > in > > > C2 were in C1, and vice versa. I used the SFC Architecture, RFC > > 7665, > > > as a guide in deciding which interface should be responsible for > > what. > > > My concerns could be based entirely on my narrow interpretation of > > it. > > > Please let me know if I've taken too narrow a view. :) > > > > > > As an example of something belonging in C2, but not C1: > > > > > > Section 3.3.1: > > > " The classifier may be notified (regularly or upon eventual > > change) > > > by > > > the control plane about the available SFs (including the SFFs > > they > > > are attached to) or be part of the service function discovery > > > procedure. > > > " > > > > > > What is the purpose behind this? > > > > [Med] This is an **optional** feature that was requested by the WG=20 > > participants to support an SFC distributed model (Ron may further=20 > > elaborate as he asked for it). For example, this feature allows a=20 > > classifier to bind flows as a function of the available paths and SF=20 > > instances. Then, packets can be bound to a fully or partially=20 > > constrained path accordingly. Also, the discovery information=20 > > provided to a classifier may be used for load distribution purposes. > > >=20 > [Kyle] I didn't really think of that use-case. The load distribution=20 > one in particular is interesting. > I see the classifier as a mapper of packets to paths, so I've been=20 > thinking of C1 as an interface for mapping packet information to paths. > Mapping packets to service functions and from there to paths seems=20 > like a higher level concept. On the one hand, I think that keeping C1=20 > purely about "packet -> path" will lead to simpler protocols. On the=20 > other hand, to allow the use-case you suggested, we'd need to add new=20 > interfaces, and as you've said below, you don't really want to do that. >=20 > But, I could ask this: if we constrain C1 to talk about only "packet=20 > -> path", then it can probably be fairly well defined, and it should=20 > be easy to reason about. However, if we relax it to allow other=20 > information such as service functions just to support a few use-cases,=20 > why not relax it to allow all information that could be relevant to=20 > SFC? I'm sure some smart people could think of many use cases for=20 > that. Then again, as I say below, I could very well just be=20 > approaching this document from the wrong perspective entirely, >=20 [Med] Your observation are really fair one. As an individual, I'm for restr= icting the classifier to the "packet/flow=3D=3D>path", but as an editor of = the document I integrated comments from the WG participants that wanted to = have such feature included as optional one. =20 > > Of course, those cases may be implemented without involving the=20 > > classifier by invoking C2 as recorded in Section 3.3.2: > > > > " This interface is also used by the SFF to report the=20 > > connectivity to > > their attached (including embedded) SFs. Local means may be=20 > > enabled > > between the SFC-aware SFs and SFFs to allow for the dynamic > > attachment of SFs to an SFF and/or discovery of SFs by an SFF" > > > > > > Given that the classifiers are not > > > conceptually "attached" to SFs on the data plane, doesn't it seem=20 > > > wrong to have the classifiers be aware of the SFs on the control > > plane? > > > > [Med] See above. The idea is to allow for a distributed model to=20 > > adjust paths (and implement other policies at the classifier). > > > > > I understand the classifiers may be co-located with SFs, but I > > don't > > > see how their functionality would, or should, depend on the=20 > > > availability of SFs in the data plane. > > > > [Med] The SF/SFF discovery information is not MANDATORY to be=20 > > provided to a classifier, but may help in some deployment cases=20 > > (such as those mentioned above). > > > > > > > > One use-case I could see for this is having the classifier map a=20 > > > packet to an explicit set of SFs. However, the classifier maps > > packets > > > to paths, not SFs. Should the logic of mapping of packet to an SF > > not > > > be performed by conjoining C1 and C2 at the controller itself? > > > > [Med] That's indeed possible. See the excerpt of Section 3.3.2=20 > > provided above. > > > > Using C1 to indicate SF > > > mapping seems to blur the lines between C1 and C2. > > > > > > After writing the above, I saw section 4.10.2. It seems to kind of=20 > > > match what I proposed above. But, I still ask: is this truly the=20 > > > responsibility of the classifier, or something which may be co- > > located > > > with it? If the latter, should it not be a different interface? > > > > [Med] Good point. We can always decompose a single interface into a=20 > > set of interfaces following some functional rationale, but the=20 > > reasons why I prefer to not add a new one are the following: > > * Maintain the SFC control plane architecture as simple as possible. > > * How a classifier decides to bind flows/packets to a given chain is=20 > > completely policy-based and deployment-specific. There may be simple=20 > > policies that do not require a feedback from the SFC-enabled domain=20 > > (e.g., blindly bind a flow to a chain based on the transport > > coordinates) and advanced policies that require additional=20 > > information to be enforced (e.g., bind a flow to a chain as a=20 > > function of available paths, bind a flow to a chain as a function of=20 > > available SF instances, bind a flow to a chian while avoiding to=20 > > cross a given network region, etc.). > > >=20 > [Kyle] I guess one of my challenges here is that I'm thinking as a=20 > protocol developer, and I'm seeing stuff I would never want to put=20 > into my protocol. > So, maybe I just need to think of this from a different perspective. > Rather than saying what must or must not be in a protocol implementing=20 > C1, this document is just providing suggestions and things to think about= ? [Med] The document calls out things that must be supported and others that = are "nice to have". > My concern is that if this is actually trying to put down requirements=20 > for a set of protocols implement C1, a large number of optional=20 > requirements aren't really going to provide a lot of guidance. >=20 [Med] Perhaps, the WG needs to check the language to make sure that must/sh= ould/may are really justified for each item. =20 > > > > > > > > > Further, section 3.3.3 has an example of something belonging in > > C1, > > > but not C2: > > > > > > " SF execution status: Some SFs may need to send information > > to the > > > control plane to fine tune SFPs. For example, a threat- > > detecting > > > SF can periodically send the threat characteristics via this > > > interface, such as high probability of threat with packet of a > > > given size. The control plane can then add an appropriate > > > matching criteria to SFF to steer traffic to a scrubbing > > center." > > > > > > Should this information not be fed back to the classifier via C1,=20 > > > rather than C2? > > > > [Med] It can of course! Please note that the text starts with "For=20 > > example, ". If the decision is to use a distinct service path, then=20 > > a classifier is likely to be invoked by means of C1. But if the=20 > > entity managing the SFC domain does not want to alter the service=20 > > path, a local policy can be provisioned to an SFF via C2 to redirect=20 > > subsequent packets to a scrubbing center. > > >=20 > [Kyle] Is it not altering the path, though? It feels like we're just=20 > defining a path through a sideways channel -- we're moving a packet to=20 > a path which isn't specified through the normal mechanisms. If it were=20 > specified normally, I.e. through classify in C1, specify forwarding=20 > logic in C2, then the SF could just reclassify the packet, [Med] An SF cannot reclassify a packet. or somehow indicate > that it wants reclassification (for example, via metadata). [Med] Yes, but this would require that a classifier will be on path upstrea= m... and immediately after that SF's service is consumed.=20 This > reclassification would not alter the previous path of the packet,=20 > since the new path already existed. In that case, C2 would just need=20 > to allow for indicating the information that would lead to=20 > reclassification, and the complex packet information necessary to do=20 > the classification could be transmitted in C1. Of course, perhaps the=20 > information I'm suggesting being indicated in C2 is no less=20 > complicated than what is being moved to C1. :) [Med] :) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Feb 19 17:59:29 2017 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 7D48512961C for ; Sun, 19 Feb 2017 17:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 orN-AoKgG9kP for ; Sun, 19 Feb 2017 17:59:27 -0800 (PST) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.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 8E71712961A for ; Sun, 19 Feb 2017 17:59:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 700C0500054 for ; Sun, 19 Feb 2017 17:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487555967; bh=vyT02HQjXmu2QCPhYUIBQ0zzpYZq4vL9eG8TTvV7dkM=; h=To:From:Subject:Date:From; b=SYghGixhyLJch9QLcYMsQF38CpUDpSWMhDPxKql+7kwV95nY1yJVkZJ04inaKNME2 o31xWQHxtsT3AoPx7UOsWQWMsnRctbSq06tBNXiD6OG9zVkSp8s3IrXdK/nV5LDhEK fKFRBJCc7orA0wbb4MolbSeSJGR9IxoQ2LWnDzfw= 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 1605F50006D for ; Sun, 19 Feb 2017 17:59:27 -0800 (PST) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Sun, 19 Feb 2017 20:59:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] MD Class registry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 01:59:28 -0000 In the interim meeting, there was a discussion of clarifying the MD Class Registry. Two changes were proposed. This email is to solicit comments from the WG on those two changes. First, the MD Class Allocation table. It currently reserves 0 - 0x01ff for IETF review. The proposal is to reserve 0x0000 for our work, and to reserve the remainder of that range (0x0001 - 0x01ff) for IEtF review. Second, the proposal is to establish the registry for type codes within MD Class 0x0000 in the NSH document. With a policy of RFC Required. No values would be established in the registry by this document, that being left ot other documents. Does anyone see problems with this proposal? Yours, Joel From nobody Sun Feb 19 18:09:10 2017 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 F092C129624 for ; Sun, 19 Feb 2017 18:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Ahg3HndL-0Jy for ; Sun, 19 Feb 2017 18:09:07 -0800 (PST) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.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 26652129623 for ; Sun, 19 Feb 2017 18:09:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1307F500042 for ; Sun, 19 Feb 2017 18:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487556547; bh=3gPa7iSBWxb33/rZHtMolRAJ+l3Jvvd6JSbTyQb4XQQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gEK5ukoXLTxapmBgEzekCTmE3/PeYQ4isOH+soN9zrIH1Rvos+BfuaQFGG8wMmzVD To+IA/alxiQDRGHTH7moGRXBIwl0UAQvM9f7AZXKyrdRF+Ix7jUeCblHA2cEyN1JcN Sod4I0hM9kMuOOQS0DwqD27Veq8pxc2h5GlZ5bXc= 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 B42101C0023 for ; Sun, 19 Feb 2017 18:09:06 -0800 (PST) To: "sfc@ietf.org" References: From: "Joel M. Halpern" Message-ID: <8dfdb5fc-1da3-5633-81b6-6ac108051dae@joelhalpern.com> Date: Sun, 19 Feb 2017 21:09:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] MD Class registry - Vendor Extensibility X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 02:09:08 -0000 A related topic on the MD Class and MD Type Registry is that of Vendor extensibility. The current registry text reads: 0x0000 to 0x01ff: IETF Review 0x0200 to 0xfff5: Expert Review 0xfff6 to 0xfffe: Experimental 0xffff: Reserved Even with the minor change I raised for discussion in my previous note, the only space for Vendor's to define their own type values is in the experimental space. It seems to me that is not sufficient. How do we want to address this? We could take a portion of the Class space for vendors. But how would we assign values to vendors for their use? Yours, Joel From nobody Sun Feb 19 18:09:45 2017 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 74CA5129485 for ; Sun, 19 Feb 2017 18:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 JOw_JqXC6xv3 for ; Sun, 19 Feb 2017 18:09:43 -0800 (PST) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.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 A52C212944E for ; Sun, 19 Feb 2017 18:09:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9289D500042 for ; Sun, 19 Feb 2017 18:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487556583; bh=ocKu3Ku4TJgagEdfOK6OSoAfzCIBZgT9AqddnRfIbIA=; h=To:From:Subject:Date:From; b=WYKmww2G8c9WlPeeGyamYYV2qaRi5Nhc5yvGaD9lpBUrtUmPsuQCh2m1UJgg0tsc1 S/uvtqILlD3nnATkAcATcafsmGG5TyP/2+I2E+desJgmDChrj/gUBWUiF13/uBFrs3 yKDTIdnbeS977+hxTG/N9jNceuv6g/gXDuKI/vhE= 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 3EDB41C0023 for ; Sun, 19 Feb 2017 18:09:43 -0800 (PST) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: <57a8680c-c466-a6e5-bea1-2729f201626f@joelhalpern.com> Date: Sun, 19 Feb 2017 21:09:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] NSH Common Header flags - C bit X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 02:09:44 -0000 Are there any additional comments on the proposal to remove the C bit? Yours, Joel From nobody Sun Feb 19 23:20:37 2017 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 877901298A5 for ; Sun, 19 Feb 2017 23:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 O2H-oBDpn4xi for ; Sun, 19 Feb 2017 23:20:34 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DAC12945F for ; Sun, 19 Feb 2017 23:20:34 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id F0381C057A; Mon, 20 Feb 2017 08:20:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id D505F8006F; Mon, 20 Feb 2017 08:20:32 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Mon, 20 Feb 2017 08:20:32 +0100 From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHSiTr9iefIx5jT8E2m6iqwkInVxaFxgDFQ Date: Mon, 20 Feb 2017 07:20:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E14A95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> <787AE7BB302AE849A7480A190F8B933009E1440A@OPEXCLILMA3.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.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 07:20:36 -0000 Hi Joel,=20 I'm not defending the draft in its current form; that is evident. In the meantime, I'm still convinced there is a need to have a document to = capture what the SFC WG expects from the CP designers.=20 Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: vendredi 17 f=E9vrier 2017 17:29 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Objet=A0: Re: [sfc] How to progress our control plane requirements docume= nt >=20 > Med, let me try to restate the point Eric and others made in the > interim, which the chairs and ADs consider cogent. >=20 > Yes, the BGP control plane draft perfroms some of the functions you > identify. It provides a coherent piece of a control plane solution. > This (the BESS SFC draft) does not attempt to solve all control plane > problems for SFC. And we would not expect it to. >=20 > The result is that there is no meaningful question we can ask of the > BESS SFC draft using the existing control plane document reference > points. It does not provide all of C1, C2, C3, or C4. Once we looked > at that, we realized that any given protocol effort on the control plane > side was likely to run into the same thing. >=20 > The purpose of the control plane requirements document, as we understand > it, is not to tell the SFC WG or SFC dta plane implementors what they > need to implement to talk to control. it is to tell control protocl > designers and implementors what they need to provide, in terms of > capabilities, to have solutions that work with SFC. Therefore, the > decomposition in the control plane document needs to correspond to a > meaningful grouping in the control plane. >=20 > If all we have is a list of requriements that control plane efforts have > to pick and choose among, it will not help them any. > That may mean that we have no useful way to present these points. That > would be unfortunate. > But we need to avoid pretending something is useful when we have been > told multiple times that it is not. >=20 > Yours, > Joel >=20 > On 2/17/17 9:15 AM, mohamed.boucadair@orange.com wrote: > > Hi Eric, > > > > Thank you for sharing your thoughts. > > > > I have comments to some of the points you mentioned in your message, bu= t > I will reply to only one of them. > > > > You said, "These reference points do not correspond to anything real.". > I'm afraid I disagree here. If you take for example, the interface to > classifiers, this is something that exists even in current deployments. > Think about PCRF/PCEF in a 3GPP PCC architecture and the like. > > > > I have no problem to abandon the draft if this is what the WG wants, bu= t > I'm afraid we need a document to define the minimum set of capabilities t= o > be honored by a solution that claims to address SFC control. > > > > For example, I checked your BGP CP draft to check if it addresses the C= P > requirement in the SFC CP draft. Many of these CP requirements are > included in your proposal but many others are missing, e.g., > > > > * I don't see how classification rules are installed/removed/updated. > > * I don't see any features to associate classification and forwarding > entries with validity lifetime. > > * I don't see how the CP sets the SI at classifiers > > * I don't see how the CP set the semantic of a metadata per each chain, > scope, etc. > > * I don't see how the CP indicates the behavior to follow when a > metadata is consumed > > * I don't see how an SFC proxy in instructed to insert/supply metadata > on behalf of SFC-unaware SFs > > * I don't see the CP behavior when an SF is to be withdrawn > > * I don't see how an SFC proxy is instructed about the SFs to service. > > * Etc. > > > > Thank you. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Eric C Rosen > >> Envoy=E9 : mardi 31 janvier 2017 20:16 > >> =C0 : Joel M. Halpern; sfc@ietf.org > >> Objet : Re: [sfc] How to progress our control plane requirements > document > >> > >> I believe the control plane requirements document should be abandoned > by > >> the WG. > >> > >> The document attempts to describe the information needed by the variou= s > >> components (e.g., SF, SFF, classifier) of the architecture. However, > RFC > >> 7665 and draft-ietf-sfc-nsh already describe the information needed by > >> the components, and the control plane requirements document does not > add > >> anything of substance. > >> > >> The requirements document attempts to organize the information into > four > >> "interface reference points", but as other have pointed out already, > >> this method of organization just is not particularly useful, and is no= t > >> helpful when designing a control plane architecture. These reference > >> points do not correspond to anything real. If the document advances, > >> someone will ask questions like "is this protocol element part of the > >> implementation of interface C2 or is it part of the implementation of > >> interface C3?", and the answer will often be "well, you could think of > >> it as part of C2, or you could think of it as part of C3, or maybe as > >> part of both, depending on your deployment scenario, but really it > >> doesn't matter". In this way, the document creates extra work without > >> adding extra value. > >> > >> When I first looked at the document, I thought it was going to provide > a > >> set of APIs allowing one to build an SF without knowing what the > control > >> plane would be. That might be useful (if it is even possible), but th= e > >> document does not seem to provide any such thing. > >> > >> There is important information that is absent from the prior documents= , > >> such as the information needed to support the interaction of the > service > >> layer components with the underlying transport, but that information i= s > >> also absent from the requirements document. > >> > >> I don't think this sort of requirements document is helpful when > >> attempting to design a control plane solution, it just gets in the way= . > >> > >> > >> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > From nobody Sun Feb 19 23:26:38 2017 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 7C7541298A5 for ; Sun, 19 Feb 2017 23:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 XCtT3DAQVao5 for ; Sun, 19 Feb 2017 23:26:35 -0800 (PST) Received: from relais-inet.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 A5D1F12940B for ; Sun, 19 Feb 2017 23:26:34 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 134154043E; Mon, 20 Feb 2017 08:26:33 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id CF9311A005F; Mon, 20 Feb 2017 08:26:32 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Mon, 20 Feb 2017 08:26:32 +0100 From: To: "adrian@olddog.co.uk" , 'Eric C Rosen' , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHufCl/iefIx5jT8E2m6iqwkInVxQKf58g5AfuZgKKhEJ0z4IAEESmQ Date: Mon, 20 Feb 2017 07:26:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E14AA8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> <787AE7BB302AE849A7480A190F8B933009E1440A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0bab01d2893b$249ab480$6dd01d80$@olddog.co.uk> In-Reply-To: <0bab01d2893b$249ab480$6dd01d80$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 07:26:36 -0000 Hi Adrian, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Adrian Farrel [mailto:adrian@olddog.co.uk] > Envoy=E9=A0: vendredi 17 f=E9vrier 2017 17:30 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; 'Eric C Rosen'; 'Joel M. Halpern'; > sfc@ietf.org > Objet=A0: RE: [sfc] How to progress our control plane requirements docume= nt >=20 > Hi Med, >=20 > I'm not convinced that this draft should address the CP requirements in > your > draft.=20 [Med] That's fine by me. It is perfectly fine to address a subset of requir= ements, but what I'm less comfortable with is to call a proposal (The) "Con= trol plane for SFC". It seems more important to build a functional system(i.e., one that > works > and delivers the operational function that makes an SFC network work). >=20 > Therefore, in reviewing the draft it may be more helpful to say: > - this doesn't work > - I need to achieve this function > - this could be done better. >=20 [Med] I confess this wasn't my perspective when reading the mackie draft. = =20 > But for completeness, here are some answers to your points: >=20 > > For example, I checked your BGP CP draft to check if it addresses the C= P > > requirement in the SFC CP draft. Many of these CP requirements are > included in > > your proposal but many others are missing, e.g., > > > > * I don't see how classification rules are installed/removed/updated. >=20 > Section 7.5 [Med] Sorry. Thank you for the pointer. >=20 > > * I don't see any features to associate classification and forwarding > entries > with > > validity lifetime. >=20 > I don't believe this to be a useful feature. [Med] Programming a state that is not limited in time may be a source of tr= oubles from a manageability standpoint. Means to help the classifier to aut= omatically clean its table without an explicit action from a third party (c= ontrollers) are useful, IMO. =20 > But it could be added at some point. >=20 [Med] Sure. BGP is powerful enough :)=20 > > * I don't see how the CP sets the SI at classifiers >=20 > Section 7.5 >=20 > > * I don't see how the CP set the semantic of a metadata per each chain, > scope, > > etc. >=20 > It would be premature to define a control plane for something that hasn't > been > properly specified in the forwarding plane. [Med] I understand your argument about the weakness of the DP plane spec in= this regards, but I do think that is (hopefully) fixed with the new text (= https://trac.ietf.org/trac/sfc/ticket/21)=20 > But it seems to me that most SFs will not be so programmable: they will > look for > specific TLVs in metadata and ignore (forward) the rest, and they will ad= d > specific TLVs to the metadata. [Med] I don't know what is/will be a default behavior of an SFC-ware SF. Fo= r example, I don't see based on which criteria a CGN or firewall SF will de= cide that it must look for particular TLVs. Also, I don't see based on whic= h criteria a classifier implementation will decide to inject a given set of= TLVs, etc. There is a void that needs to be fulfilled by the CP. > Sending CP messages will not change the behavior of SFs in this regard. [Med] There is a need to communicate SFC instructions to underlying SFC-awa= re nodes.=20 > Attempting to do so would be adding unnecessary complexity to the system. >=20 > > * I don't see how the CP indicates the behavior to follow when a > metadata is > > consumed >=20 > Ditto the above only more so! > An SF is an SF and is not CP-programmable. [Med] We are not talking about SFs in general, but about SFC-aware SFs. Of = course, SF-specific control is not of interest here.=20 >=20 > > * I don't see how an SFC proxy in instructed to insert/supply metadata > on > behalf > > of SFC-unaware SFs >=20 > An SFC proxy is, in that respect, no different from the metadata componen= t > of an > SF that can handle metadata. [Med] ... except that the proxy does not know what TLVs are to be inserted/= stripped/modified per attached SF (and per chain).=20 >=20 > But you *have* pointed to an interesting "hole" in the architecture if it > is > assumed that the SFC proxy can somehow know about the state in the SFC- > unaware > SF and shape metadata accordingly. >=20 > > * I don't see the CP behavior when an SF is to be withdrawn >=20 > I don't even know what it means to "withdraw an SF". [Med] What I meant is, for example, when an SF is decommissioned or when n= ow instance is available to deliver the service. Does the solution allows t= o maintain the installed SFPs but with a bypass of that SF or it imposes to= reinstall new paths. =20 > Do you mean "to take an SFI gracefully out of service"? If so, you would > simply > withdraw the SFIR and the route would go (as is normal in BGP). > Or do you mean "to remove an SF from an SFP"? If so, 4.5.1. >=20 > > * I don't see how an SFC proxy is instructed about the SFs to service. >=20 > Are you asking how a proxy that severs more than one SF knows to which SF > to > route packets? [Med] This is more about checking that only entitled SFs are authorized to = be serviced by a proxy. > If you are, then my answer is "don't do that!" Proxies are cheap. You can > virtualise a proxy at any location. >=20 > > * Etc. >=20 > See section, oh... :-) [Med] Will read that section SOON ;-) >=20 > Thanks, > Adrian From nobody Sun Feb 19 23:49:45 2017 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 5994E1293E9 for ; Sun, 19 Feb 2017 23:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH8jMsv_5nqE for ; Sun, 19 Feb 2017 23:49:42 -0800 (PST) Received: from relais-inet.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 B76E31298BC for ; Sun, 19 Feb 2017 23:43:57 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 54D25A0856; Mon, 20 Feb 2017 08:43:56 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 2DB0E1A0069; Mon, 20 Feb 2017 08:43:56 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Mon, 20 Feb 2017 08:43:55 +0100 From: To: "adrian@olddog.co.uk" , "sfc@ietf.org" Thread-Topic: [sfc] O-bit behavior in NSH spec Thread-Index: AQKs4QfPsAfGu+IdxTavj2M4SM8+/wHdpbuin6nIGRCABB3+kA== Date: Mon, 20 Feb 2017 07:43:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E14ACB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E13FA3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0bb201d2893c$a8766460$f9632d20$@olddog.co.uk> In-Reply-To: <0bb201d2893c$a8766460$f9632d20$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 07:49:43 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Adrian Farrel [mailto:adrian@olddog.co.uk] > Envoy=E9=A0: vendredi 17 f=E9vrier 2017 17:41 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Objet=A0: RE: [sfc] O-bit behavior in NSH spec >=20 > Med, >=20 > Thanks for the pointers. It's really helpful to see where this text came > from > and why. >=20 > I realise it must be aggravating to have someone come along 8 months late= r > and > ask questions, but there we go. [Med] Having fresh eyes to double check the text is really valuable and enc= ouraged.=20 >=20 > In fact, I find that in addition to my previous points I see another > problem >=20 > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. >=20 > SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable > parameter to enable forwarding received SFC OAM packets unmodified to > the next element in the chain. >=20 > You cannot both have "MUST do X" and "MAY be configured to do Y" [Med] The initial SHALL is the default behavior. Adding "by default" wouldn= 't be sufficient?=20 > Possibly s/SHALL/SHOULD/ > But also, if there is a configuration option it becomes a question of > defaults > and so... > OLD > MAY support a configurable parameter to enable forwarding received SFC OA= M > NEW > MAY forward received SFC OAM subject to local policy and configuration > END >=20 > Furthermore > For non OAM packets, the O-bit MUST be cleared and MUST NOT be > modified along the SFP. > which is not (I hope) to imply that the O bit can be modified on an OAM > packet. [Med] That's not the intent. =20 >=20 > In short, the text around the O bit is in need of some work. [Med] I won't be the one who will complain about a better proposal here.=20 >=20 > Thanks, > Adrian >=20 >=20 >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: 17 February 2017 07:22 > > To: adrian@olddog.co.uk; sfc@ietf.org > > Subject: RE: [sfc] O-bit behavior in NSH spec > > > > Hi Adrian, > > > > FWIW: > > * The first part of the text you quoted is the outcome of the discussio= n > related to > > this ticket: https://www.ietf.org/mail- > archive/web/sfc/current/msg03447.html > > * The full text included as it appears in -11 was agreed in this thread= : > > https://mailarchive.ietf.org/arch/msg/sfc/wafNWPiS0_ROfy_pJZmSZhlu0fU > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > > > Envoy=E9=A0: mercredi 15 f=E9vrier 2017 22:00 > > > =C0=A0: sfc@ietf.org > > > Objet=A0: [sfc] O-bit behavior in NSH spec > > > > > > Hi, > > > > > > I think it is right that the NSH spec only minimally describe OAM, bu= t > I > > > want to > > > double check the intention of a couple of things here. > > > > > > Section 3.2 says: > > > > > > > O bit: Setting this bit indicates an Operations, Administration, an= d > > > > Maintenance (OAM) packet. The actual packet format and processing > of > > > > SFC OAM messages is outside the scope of this specification (see [I= - > > > > D.ietf-sfc-oam-framework]). > > > > > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SF= C > > > > OAM procedures, SHALL discard packets with O-bit set. > > > > > > 1. Isn't the first paragraph actually making a decision about the > meaning > > > of the O bit? That is, it is saying that the packet is an OAM > packet? > > > Would it be better to defer this type of decisions and say > something a > > > little more vague such as... > > > > > > > O bit: Setting this bit indicates that the NSH packet contains > > > Operations, > > > > Administration, and Maintenance (OAM) data. The actual packet > format > > > > and processing of SFC OAM data and how that data is carried in an > NSH > > > > packet is outside the scope of this specification (see > > > > [I-D.ietf-sfc-oam-framework]). > > > > > > 2. Do we really want OAM packets discarded rather than passed through= ? > > > That substantially minimises the utility of any OAM. > > > Surely we want to specify > > > > > > > SF/SFF/SFC Proxy/Classifier implementations, that do not support SF= C > > > > OAM procedures, SHALL process and forward packets with the O bit se= t > > > > as normal. > > > > > > Thanks, > > > Adrian > > > > > > _______________________________________________ > > > sfc mailing list > > > sfc@ietf.org > > > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 20 01:49:40 2017 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 CB0B4128B38 for ; Mon, 20 Feb 2017 01:49:38 -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] 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 pLjKnT_crT8N for ; Mon, 20 Feb 2017 01:49:35 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8F412960C for ; Mon, 20 Feb 2017 01:49:32 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1K9nTl3012531; Mon, 20 Feb 2017 09:49:29 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1K9nN7r012364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2017 09:49:27 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: <57a8680c-c466-a6e5-bea1-2729f201626f@joelhalpern.com> In-Reply-To: <57a8680c-c466-a6e5-bea1-2729f201626f@joelhalpern.com> Date: Mon, 20 Feb 2017 09:49:23 -0000 Message-ID: <007301d28b5e$a0d29e30$e277da90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKWvDmPqnbH3+qmi0j7zTNnD7nI+Z/pQ2Ew Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22896.006 X-TM-AS-Result: No--3.786-10.0-31-10 X-imss-scan-details: No--3.786-10.0-31-10 X-TMASE-MatchedRID: pBwXUM+nCwujhdS4y9NWlPHkpkyUphL9Ud7Bjfo+5jTM9X6l99fFT9Lu X2hj/M7U3byW8HpaaSU52p2V9wXr3wUJ2rQm9htlnVTWWiNp+v9BldmDYjwlpudTjSOFC/vqo8W MkQWv6iV95l0nVeyiuFSqyRM1YGuh0C1sQRfQzEHEQdG7H66TyHEqm8QYBtMO6vNB+nMSLpJSJt iXIZkfSiAijF54hwkMH9IQNvQ0n3Ndl0Z0CIeIE5PFBHD9dgdr27ga0Z3fP+X+kLqM2M3h/DY20 I0jYDyNpdTv1r0NJiyPTSRT8qxQUS4OAepo+qJnBeb7wZ+ynLM= Archived-At: Subject: Re: [sfc] NSH Common Header flags - C bit X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 09:49:39 -0000 Joel, Per Dave's write-up to the list on Jan 18th, I agree with removing this bit. Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 20 February 2017 02:10 > To: sfc@ietf.org > Subject: [sfc] NSH Common Header flags - C bit > > Are there any additional comments on the proposal to remove the C bit? > > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 20 02:12:37 2017 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 6F62A129999 for ; Mon, 20 Feb 2017 02:12:35 -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] 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 53rRet8ZS-Rx for ; Mon, 20 Feb 2017 02:12:34 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6DD128AB0 for ; Mon, 20 Feb 2017 02:12:33 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1KACUrq002288; Mon, 20 Feb 2017 10:12:30 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1KACPRp002134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2017 10:12:28 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , Date: Mon, 20 Feb 2017 10:12:25 -0000 Message-ID: <007a01d28b61$d7d959c0$878c0d40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01D28B61.D7DEFF10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKLYdHUMpuBDxu4SZudKam+wxVKAA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22896.006 X-TM-AS-Result: No--16.554-10.0-31-10 X-imss-scan-details: No--16.554-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGYnXrvyG+/T7MjW/sniEQKmz61vg1cgl5FDR0AKGX+XHiM N1dSLUYilTJXKqh1ne13IE+1hZ/O9k5/fYay/W3c6rBZUF8y6+i3OFcpziLcq1mmz7LVVfOpvL4 BuAuBsSmlvujt8freXj78wFHlPLuLL0W1btd8e57QfDWILG9Bqfqk6wqWEsjCHL8D2Jlysh+GGl xlkudxLcRHH5tvu//5n+EEi06My3CDBUhj8ZKlO7yR1pIoU1tht3aeg7g/usAutoY2UtFqGK+am oVFXqxcFsFsBxZEz2uK46Tg39O8CpyXv62vBT5YytPf0+gM21ayCFZQzJC88brtDe4+j0ojbYRv 2N9oA1AGs3XCsxYQ58hpPhKVtEnWOTqG3dmTuwDf8GJjBXCUiBlgDfyCPcHELo8sUR8HvhwONnC OtDoJBZ6Ss6O2bihGHDnwvr6B+jREXwnTCGfm3f0peXGEEBlvrogFtKd/P7fSlkoRLCKfE56QVn lXMIygXrfYosn++oqhIBgkfoHq9iIdmtkBwO3DlwOGeK/WrXNT4DtiSkMnWCgMxnfFXjiIdXDbH Fxm2F+dv7RrSohAJCkm8kuls98/aEoHA+Yew8W7vYqkCS0dL7YidXoBo/qVlSFPfwjN9pHsoEFn ZAFTLE+J83GmsfZy66Wuu9SwKD+HFo7dvDc+MOOtrJejSjcwh+w9Wz/xXDoR8rMICe0qkPMxs+u cp3ZMyS4a/w19Mu+0XdFsGUlXTTScgMqgJnG/EgwM8US/pTGQF91MxEBdRgv/nTOPQovsFj7vnT 2w9ftks0eImXJpYS1jeyZyVZgJgiIO7Sf/7rGeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7GNgbF0oRDZ0JEQ2iLqMQpFXQk7VVT9GH+EkwyhhcQAKYlyatX9LYyXonjRa5N5I5RQ/6hSr cVMjAzQFwYgzxIMFN5GY8I1cX4nnXKEejEl95ZjKDMI4PWc= Archived-At: Subject: Re: [sfc] MD Class registry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 10:12:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007B_01D28B61.D7DEFF10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Joel, That's good modulo use of the word "reserve" which has special IANA meaning ("do not allocate"). It may be helpful to write out the proposed text which is, I think... OLD 12.2.4. MD Class Registry IANA is requested to set up a registry of "MD Class". These are 16- bit values. MD Classes defined by this document are assigned as follows: 0x0000 to 0x01ff: IETF Review 0x0200 to 0xfff5: Expert Review 0xfff6 to 0xfffe: Experimental 0xffff: Reserved NEW 12.2.4. MD Class Registry IANA is requested to set up a registry of "MD Class". These are 16- bit values. New allocations are to be made according to the following policies: 0x0000 to 0x01ff: IETF Review 0x0200 to 0xfff5: Expert Review 0xfff6 to 0xfffe: Experimental 0xffff: Reserved IANA is requested to assign the following value: MD Class | Meaning | Reference ---------+----------------------------+----------- 0x0000 | IETF Base NSH MD Class | [This.I-D] Designated Experts evaluating new allocation requests from the "Expert Review" range should principally consider whether a new MD class is needed compared to adding MD types to an existing class. The Designated Experts should also encourage the existence of an associated and publically visible registry of MD types although this registry need not be maintained by IANA. END However, as I type this I do wonder whether 2^16 isn't a very lot of MD classes. Ciao, Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 20 February 2017 01:59 > To: sfc@ietf.org > Subject: [sfc] MD Class registry > > In the interim meeting, there was a discussion of clarifying the MD > Class Registry. Two changes were proposed. This email is to solicit > comments from the WG on those two changes. > > First, the MD Class Allocation table. It currently reserves 0 - 0x01ff > for IETF review. > > The proposal is to reserve 0x0000 for our work, and to reserve the > remainder of that range (0x0001 - 0x01ff) for IEtF review. > > Second, the proposal is to establish the registry for type codes within > MD Class 0x0000 in the NSH document. With a policy of RFC Required. No > values would be established in the registry by this document, that being > left ot other documents. > > Does anyone see problems with this proposal? > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc ------=_NextPart_000_007B_01D28B61.D7DEFF10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Joel,

     

    That's = good modulo use of the word "reserve" which has special IANA = meaning ("do not allocate").

     

    It may = be helpful to write out the proposed text which is, I = think...

     

    OLD

    12.2.4.  MD Class = Registry

     

       IANA is requested to set = up a registry of "MD Class".  These are = 16-

       bit values.  MD Classes defined by this = document are assigned as

       = follows:

     

       0x0000 to 0x01ff: IETF = Review

       0x0200 to 0xfff5: Expert = Review

       0xfff6 to 0xfffe: = Experimental

       0xffff: = Reserved

    NEW

    12.2.4.  MD Class = Registry

     

       IANA is requested to set = up a registry of "MD Class".  These are = 16-

       bit values. New = allocations are to be made according to the

       following = policies:

     

       0x0000 to 0x01ff: IETF = Review

       0x0200 to 0xfff5: Expert = Review

       0xfff6 to 0xfffe: = Experimental

       0xffff: = Reserved

     

       IANA is requested to = assign the following value:

     

       MD Class | Meaning       &nbs= p;            = | Reference

       = ---------+----------------------------+-----------

       0x0000   | IETF Base NSH MD = Class     | = [This.I-D]

     

       Designated Experts = evaluating new allocation requests

       from the "Expert = Review" range should principally

       consider whether a new MD = class is needed compared to

       adding MD types to an = existing class. The Designated

       Experts should also = encourage the existence of an

       associated and publically = visible registry of MD types

       although this registry = need not be maintained by IANA.

    END

     

    However, as I type this I do wonder whether 2^16 = isn't a very lot of MD classes.

     

    Ciao,

    Adrian

     

    > = -----Origina= l Message-----

    > From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. = Halpern

    > Sent: 20 = February 2017 01:59

    > = To: = sfc@ietf.org

    > Subject: = [sfc] MD Class registry

    >

    > In = the interim meeting, there was a discussion of clarifying the = MD

    > Class Registry.  Two changes were proposed.  This email is to = solicit

    > comments from the WG = on those two changes.

    > =

    > First, the MD Class = Allocation table.  It = currently reserves 0 - 0x01ff

    > = for IETF review.

    > =

    > The proposal is to reserve = 0x0000 for our work, and to reserve the

    > remainder of that range (0x0001 - 0x01ff) for = IEtF review.

    > =

    > Second, the proposal is to = establish the registry for type codes within

    > MD Class 0x0000 in the NSH document.  With a policy of RFC = Required.  = No

    > values would be = established in the registry by this document, that = being

    > left ot other = documents.

    >

    > Does anyone see problems with this = proposal?

    > = Yours,

    > Joel

    >

    > = _______________________________________________

    > sfc mailing list

    > sfc@ietf.org

    > = https://www.ietf.org/mailman/listinfo/sfc

    ------=_NextPart_000_007B_01D28B61.D7DEFF10-- From nobody Mon Feb 20 02:13:10 2017 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 1BB2F1299AA for ; Mon, 20 Feb 2017 02:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 86a8E_KwXaP3 for ; Mon, 20 Feb 2017 02:13:06 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A24129999 for ; Mon, 20 Feb 2017 02:13:06 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1KAD38O026026; Mon, 20 Feb 2017 10:13:03 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1KACvtE025891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2017 10:13:03 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: <8dfdb5fc-1da3-5633-81b6-6ac108051dae@joelhalpern.com> In-Reply-To: <8dfdb5fc-1da3-5633-81b6-6ac108051dae@joelhalpern.com> Date: Mon, 20 Feb 2017 10:12:58 -0000 Message-ID: <008e01d28b61$ec399150$c4acb3f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMojjn5qD4A9VjG0JSRFr/2rcn8uAJIkUo1nrNf2aA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22896.006 X-TM-AS-Result: No--15.573-10.0-31-10 X-imss-scan-details: No--15.573-10.0-31-10 X-TMASE-MatchedRID: QW5G6BKkLTrvkBiM1eNiXjTR2TFg0xG3UKlt4AyW7uATbwwNpbyaWVx9 1vue5xn5GUVvlPZC6jneGwYgH1VkOllQJeEqNNYAlTsGW3DmpUtPn74Ug5EKEPgnJH5vm2+gfMr dD3NIUvs76oxhffXo8fFPDHhQkgxyTlEJOJh6wIqVUcz8XpiS9EoPOT/GTMuGmBadosOIaCFQOD HUeEj/lPKpS2s/gzfKuyb1TD/wyf8tj0Ce93dF0p1U1lojafr/QZXZg2I8JabnU40jhQv76qPFj JEFr+olfeZdJ1XsorhYF4vDdkFiv1Z0V5tYhzdWxEHRux+uk8h+ICquNi0WJEcmh8+tjK8QpDiH iTanRV0MzxYp1RAv9pkWz4Oe/qBOftwZ3X11IV0= Archived-At: Subject: Re: [sfc] MD Class registry - Vendor Extensibility X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 10:13:09 -0000 It seems to me, that we need to sort ourselves out a bit wrt flexibility in metadata. We have a hierarchy: MD Class (2^16) MD Type (2^7, about to become 2^8) MD TLVs (different docs) AFAICS only one "optional variable length metadata" can be present in an NSH. So I have some observations... o 2^16 is a lot of MD classes. Really a lot! o 2^8 is more than plenty MD types in any class o A vendor-specific MD class only works on an SFP made up *entirely* of products from that vendor o A vendor-specific MD type only works on an SFP made up *entirely* of products from that vendor o The main (only) place we should care about vendor- specific pieces of metadata is in the definitions of TLVs in MC0/MD2 (not this doc). Am I missing a particular use case? Cheers, Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 20 February 2017 02:09 > To: sfc@ietf.org > Subject: Re: [sfc] MD Class registry - Vendor Extensibility > > A related topic on the MD Class and MD Type Registry is that of Vendor > extensibility. The current registry text reads: > > 0x0000 to 0x01ff: IETF Review > 0x0200 to 0xfff5: Expert Review > 0xfff6 to 0xfffe: Experimental > 0xffff: Reserved > > Even with the minor change I raised for discussion in my previous note, > the only space for Vendor's to define their own type values is in the > experimental space. It seems to me that is not sufficient. > > How do we want to address this? We could take a portion of the Class > space for vendors. But how would we assign values to vendors for their use? > > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 20 02:41:05 2017 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 2A58512999B for ; Mon, 20 Feb 2017 02:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 VXVraTCy5zRG for ; Mon, 20 Feb 2017 02:41:02 -0800 (PST) Received: from relais-inet.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 7F183128B38 for ; Mon, 20 Feb 2017 02:41:02 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 879B0405A4; Mon, 20 Feb 2017 11:41:00 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 3BA1B1A0077; Mon, 20 Feb 2017 11:41:00 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0319.002; Mon, 20 Feb 2017 11:40:59 +0100 From: To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] MD Class registry Thread-Index: AdKLYdHUMpuBDxu4SZudKam+wxVKAAAAlwug Date: Mon, 20 Feb 2017 10:40:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E14CA5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <007a01d28b61$d7d959c0$878c0d40$@olddog.co.uk> In-Reply-To: <007a01d28b61$d7d959c0$878c0d40$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E14CA5OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] MD Class registry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 10:41:04 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E14CA5OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Please see inline. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel Envoy=E9 : lundi 20 f=E9vrier 2017 11:12 =C0 : 'Joel M. Halpern'; sfc@ietf.org Objet : Re: [sfc] MD Class registry Joel, That's good modulo use of the word "reserve" which has special IANA meaning= ("do not allocate"). It may be helpful to write out the proposed text which is, I think... OLD 12.2.4. MD Class Registry IANA is requested to set up a registry of "MD Class". These are 16- bit values. MD Classes defined by this document are assigned as follows: 0x0000 to 0x01ff: IETF Review 0x0200 to 0xfff5: Expert Review 0xfff6 to 0xfffe: Experimental 0xffff: Reserved NEW 12.2.4. MD Class Registry IANA is requested to set up a registry of "MD Class". These are 16- bit values. New allocations are to be made according to the following policies: 0x0000 to 0x01ff: IETF Review 0x0200 to 0xfff5: Expert Review 0xfff6 to 0xfffe: Experimental 0xffff: Reserved IANA is requested to assign the following value: MD Class | Meaning | Reference ---------+----------------------------+----------- 0x0000 | IETF Base NSH MD Class | [This.I-D] Designated Experts evaluating new allocation requests from the "Expert Review" range should principally consider whether a new MD class is needed compared to adding MD types to an existing class. The Designated Experts should also encourage the existence of an associated and publically visible registry of MD types although this registry need not be maintained by IANA. END [Med] While we are discussing this MD#0, I'd like to remind this companion = point that needs to be fixed in the draft too. =3D=3D=3D NEW: x.x.x. IETF Assigned MD TLV Type Registry This document requests IANA to create a registry for the type values owned by the IETF (i.e., MD Class set to 0) called the "IETF Assigned MD TLV Type Registry." The type values are assigned via Standards Action [RFC5226]. No initial values are assigned at the creation of the registry. =3D=3D=3D=3D=3D=3D However, as I type this I do wonder whether 2^16 isn't a very lot of MD cla= sses. [Med] I do personally think this is over-dimensioned. As reported in https:= //trac.ietf.org/trac/sfc/ticket/24, I'd prefer to reduce the length of the = MD class to grab more bits for the length field. Ciao, Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 20 February 2017 01:59 > To: sfc@ietf.org > Subject: [sfc] MD Class registry > > In the interim meeting, there was a discussion of clarifying the MD > Class Registry. Two changes were proposed. This email is to solicit > comments from the WG on those two changes. > > First, the MD Class Allocation table. It currently reserves 0 - 0x01ff > for IETF review. > > The proposal is to reserve 0x0000 for our work, and to reserve the > remainder of that range (0x0001 - 0x01ff) for IEtF review. > > Second, the proposal is to establish the registry for type codes within > MD Class 0x0000 in the NSH document. With a policy of RFC Required. No > values would be established in the registry by this document, that being > left ot other documents. > > Does anyone see problems with this proposal? > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --_000_787AE7BB302AE849A7480A190F8B933009E14CA5OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi all,

     

    Please see inline.

     

    Cheers,

    Med

     

    De : sfc [mailto:sfc-bounces@ietf.or= g] De la part de Adrian Farrel
    Envoy=E9 : lundi 20 f=E9vrier 2017 11:12
    =C0 : 'Joel M. Halpern'; sfc@ietf.org
    Objet : Re: [sfc] MD Class registry

     

    Joel,

     

    That's good modulo use of th= e word "reserve" which has special IANA meaning ("do not all= ocate").

     

    It may be helpful to write o= ut the proposed text which is, I think...

     

    OLD

    12.2.4.  MD Class Registry

     

       IANA is requested to set up a registry of &q= uot;MD Class".  These are 16-

       bit values.  MD Classes defined by this= document are assigned as

       follows:

     

       0x0000 to 0x01ff: IETF Review

       0x0200 to 0xfff5: Expert Review

       0xfff6 to 0xfffe: Experimental

       0xffff: Reserved

    NEW

    12.2.4.  MD Class Registry

     

       IANA is requested to set up a registry of &q= uot;MD Class".  These are 16-

       bit values. New allocations are to be made a= ccording to the

       following policies:

     

       0x0000 to 0x01ff: IETF Review

       0x0200 to 0xfff5: Expert Review

       0xfff6 to 0xfffe: Experimental

       0xffff: Reserved

     

       IANA is requested to assign the following va= lue:

     

       MD Class | Meaning    &n= bsp;            = ;   | Reference

       ---------+----------------------------&#= 43;-----------

       0x0000   | IETF Base NSH MD Class&= nbsp;    | [This.I-D]

     

       Designated Experts evaluating new allocation= requests

       from the "Expert Review" range sho= uld principally

       consider whether a new MD class is needed co= mpared to

       adding MD types to an existing class. The De= signated

       Experts should also encourage the exist= ence of an

       associated and publically visible registry o= f MD types

       although this registry need not be maintaine= d by IANA.

    END

     

    [Med] While we are discussin= g this MD#0, I’d like to remind this companion point that needs to be= fixed in the draft too.

     

    =3D=3D=3D<= /p>

    NEW:

    x.x.x.  IETF Assigned MD TLV Type Registry

     

       This document requests IANA to create a registry for the type= values

       owned by the IETF (i.e., MD Class set to 0) called the "= IETF Assigned

       MD TLV Type Registry."

     

       The type values are assigned via Standards Action [RFC5226].<= o:p>

     

       No initial values are assigned at the creation of the registr= y.

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

     

    However, as I type this I do= wonder whether 2^16 isn't a very lot of MD classes.

     

    [Med] I do personally think = this is over-dimensioned. As reported in https://trac.ietf.org/= trac/sfc/ticket/24, I’d prefer to reduce the length of the MD cla= ss to grab more bits for the length field.

     

    Ciao,

    Adrian

     

    > -----Original Message-----=

    > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Hal= pern

    > Sent: 20 February 2017 01:59

    > To: sfc@ietf.org

    > Subject: [sfc] MD Class registry<= /span>

    >

    > In the interim meeting,= there was a discussion of clarifying the MD

    > Class Registry.  T= wo changes were proposed.  This email is to solicit<= /p>

    > comments from the WG on= those two changes.

    >

    > First, the MD Class All= ocation table.  It currently reserves 0 - 0x01ff

    > for IETF review.

    >

    > The proposal is to rese= rve 0x0000 for our work, and to reserve the

    > remainder of that range= (0x0001 - 0x01ff) for IEtF review.

    >

    > Second, the proposal is= to establish the registry for type codes within

    > MD Class 0x0000 in the = NSH document.  With a policy of RFC Required.  No

    > values would be establi= shed in the registry by this document, that being

    > left ot other documents= .

    >

    > Does anyone see problem= s with this proposal?

    > Yours,

    > Joel<= /p>

    >

    > _______________________= ________________________

    > sfc mailing list

    > sfc@ietf.org

    > https://www.ietf.org/mailman/listinfo/sfc

    --_000_787AE7BB302AE849A7480A190F8B933009E14CA5OPEXCLILMA3corp_-- From nobody Mon Feb 20 04:11:02 2017 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 13452128824 for ; Mon, 20 Feb 2017 04:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 83FLIXFXR2lt for ; Mon, 20 Feb 2017 04:10:59 -0800 (PST) Received: from relais-inet.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 7132A1299BC for ; Mon, 20 Feb 2017 04:10:59 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 1FA1E12018C; Mon, 20 Feb 2017 13:10:58 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 02ACC180062; Mon, 20 Feb 2017 13:10:58 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0319.002; Mon, 20 Feb 2017 13:10:57 +0100 From: To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] MD Class registry - Vendor Extensibility Thread-Index: AQMojjn5qD4A9VjG0JSRFr/2rcn8uAJIkUo1nrNf2aCAAAs9UA== Date: Mon, 20 Feb 2017 12:10:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E14CFC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8dfdb5fc-1da3-5633-81b6-6ac108051dae@joelhalpern.com> <008e01d28b61$ec399150$c4acb3f0$@olddog.co.uk> In-Reply-To: <008e01d28b61$ec399150$c4acb3f0$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] MD Class registry - Vendor Extensibility X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 12:11:01 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > Envoy=E9=A0: lundi 20 f=E9vrier 2017 11:13 > =C0=A0: 'Joel M. Halpern'; sfc@ietf.org > Objet=A0: Re: [sfc] MD Class registry - Vendor Extensibility >=20 > It seems to me, that we need to sort ourselves out a bit wrt flexibility > in > metadata. >=20 > We have a hierarchy: > MD Class (2^16) > MD Type (2^7, about to become 2^8) > MD TLVs (different docs) >=20 > AFAICS only one "optional variable length metadata" can be present in an > NSH. >=20 > So I have some observations... >=20 > o 2^16 is a lot of MD classes. Really a lot! [Med] Agree. > o 2^8 is more than plenty MD types in any class [Med] At least for the mobile case where the practice to "enrich" packets w= ith some data on-path (https://tools.ietf.org/html/draft-ietf-sfc-use-case-= mobility-07#section-3.3) is the rule, the type of data that can be inserted= may be very "rich"; see for example Section 7.1 of http://www.etsi.org/del= iver/etsi_ts/129200_129299/129230/12.06.00_60/ts_129230v120600p.pdf.=20 I know that is frightening but the experience from existing IETF protocols = is that a 2^8 type registry can be exhausted: see for the example the RADIU= S case http://www.iana.org/assignments/radius-types/radius-types.xhtml#radi= us-types-2. In order to cover existing use cases while avoiding coming back to the IETF= to claim the type resources have been exhausted, I do suggest to use more = bits for the type field. 16 bits would be great. =20 > o A vendor-specific MD class only works on an SFP > made up *entirely* of products from that vendor > o A vendor-specific MD type only works on an SFP > made up *entirely* of products from that vendor > o The main (only) place we should care about vendor- > specific pieces of metadata is in the definitions of > TLVs in MC0/MD2 (not this doc). >=20 > Am I missing a particular use case? >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: 20 February 2017 02:09 > > To: sfc@ietf.org > > Subject: Re: [sfc] MD Class registry - Vendor Extensibility > > > > A related topic on the MD Class and MD Type Registry is that of Vendor > > extensibility. The current registry text reads: > > > > 0x0000 to 0x01ff: IETF Review > > 0x0200 to 0xfff5: Expert Review > > 0xfff6 to 0xfffe: Experimental > > 0xffff: Reserved > > > > Even with the minor change I raised for discussion in my previous note, > > the only space for Vendor's to define their own type values is in the > > experimental space. It seems to me that is not sufficient. > > > > How do we want to address this? We could take a portion of the Class > > space for vendors. But how would we assign values to vendors for their > use? > > > > Yours, > > Joel > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 20 05:52:28 2017 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 8120012948C for ; Mon, 20 Feb 2017 05:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 sdCZlmNL4Pao for ; Mon, 20 Feb 2017 05:52:25 -0800 (PST) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.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 B81CF129498 for ; Mon, 20 Feb 2017 05:52:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8FFA14E3DCF; Mon, 20 Feb 2017 05:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487598744; bh=hGiQlNm2bqH6Le98A/DURHNH5U9jTmGaaABjzGvFWpU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pmRa4kvyIoxa2Nm2xUdPNLmRqoBEF89bqcdZ7NjGlf7nP0/VnrS5HORSpn+vaMSca L39jWvHqwue2w31922loXQLZN6tu+lYIjr22hO+ZZt6KbghixaTWWrJsD0pEj0hZOz 9kUIYvam6GsD3w8bYK/F+gDgOn5tjln6LrlBYQQI= 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 231731C00A4; Mon, 20 Feb 2017 05:52:24 -0800 (PST) To: adrian@olddog.co.uk, sfc@ietf.org References: <8dfdb5fc-1da3-5633-81b6-6ac108051dae@joelhalpern.com> <008e01d28b61$ec399150$c4acb3f0$@olddog.co.uk> From: Joel Halpern Direct Message-ID: <37852da7-2560-1edf-26d3-a566cacb9b4c@joelhalpern.com> Date: Mon, 20 Feb 2017 08:52:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <008e01d28b61$ec399150$c4acb3f0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] MD Class registry - Vendor Extensibility X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 13:52:26 -0000 I am not sure what the line in your note "AFAICS only one "optional variable length metadata" can be present in an NSH." means? In an NSH packet using MD2, there are a sequence of metadata elements. Each metdata element has an MD-Class, MD-Type, length, and value. So what limit are your refering to as "only one"? Yours, Joel On 2/20/17 5:12 AM, Adrian Farrel wrote: > It seems to me, that we need to sort ourselves out a bit wrt flexibility in > metadata. > > We have a hierarchy: > MD Class (2^16) > MD Type (2^7, about to become 2^8) > MD TLVs (different docs) > > AFAICS only one "optional variable length metadata" can be present in an NSH. > > So I have some observations... > > o 2^16 is a lot of MD classes. Really a lot! > o 2^8 is more than plenty MD types in any class > o A vendor-specific MD class only works on an SFP > made up *entirely* of products from that vendor > o A vendor-specific MD type only works on an SFP > made up *entirely* of products from that vendor > o The main (only) place we should care about vendor- > specific pieces of metadata is in the definitions of > TLVs in MC0/MD2 (not this doc). > > Am I missing a particular use case? > > Cheers, > Adrian > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: 20 February 2017 02:09 >> To: sfc@ietf.org >> Subject: Re: [sfc] MD Class registry - Vendor Extensibility >> >> A related topic on the MD Class and MD Type Registry is that of Vendor >> extensibility. The current registry text reads: >> >> 0x0000 to 0x01ff: IETF Review >> 0x0200 to 0xfff5: Expert Review >> 0xfff6 to 0xfffe: Experimental >> 0xffff: Reserved >> >> Even with the minor change I raised for discussion in my previous note, >> the only space for Vendor's to define their own type values is in the >> experimental space. It seems to me that is not sufficient. >> >> How do we want to address this? We could take a portion of the Class >> space for vendors. But how would we assign values to vendors for their use? >> >> Yours, >> Joel >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Feb 20 06:22:50 2017 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 F03501294BC for ; Mon, 20 Feb 2017 06:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 fkOWLsyPevmE for ; Mon, 20 Feb 2017 06:22:48 -0800 (PST) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.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 489321294BB for ; Mon, 20 Feb 2017 06:22:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D1E904E3DC9; Mon, 20 Feb 2017 06:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487600567; bh=j6qyy5nlRFwrwBVndiGP7ror+WQrMDMqixLEQ3NMzL4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Irmk9+jOiucmIZwNkWMGs0Id6frprlOFe71IE+VzTHp5ZrBihSceNdDuYzClNq0DD XOlBawqmOeqYvyA0OAQDYumKSDJDyjABw6HCWwLZed54kwtmSOZvSqcr1rP4t9nDQo 7gYKLTdO2x3+fKCo0ZDHrxzxxP6ULJYgrFvDXxxY= 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 682FC1C00A4; Mon, 20 Feb 2017 06:22:47 -0800 (PST) To: mohamed.boucadair@orange.com, "sfc@ietf.org" References: <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> <787AE7BB302AE849A7480A190F8B933009E1440A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E14A95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: Date: Mon, 20 Feb 2017 09:22:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E14A95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 14:22:49 -0000 Thank you Med. Speaking personally, I would like to see a document that captures these expectations. And I appreciate the efforts you have put in to try to achieve that. The challenge I see is finding an effective structuring for that document. So I am hoping for engagement from others here with ideas on how to structure such a document. (I hate saying 'problem' without being able to suggest a path forward, but in this case, that is where I find myself.) Yours, Joel On 2/20/17 2:20 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > I'm not defending the draft in its current form; that is evident. > > In the meantime, I'm still convinced there is a need to have a document to capture what the SFC WG expects from the CP designers. > > Cheers, > Med > From nobody Mon Feb 20 07:23:03 2017 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 B47DE129694 for ; Mon, 20 Feb 2017 07:23:01 -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 DjtGEGk02t4E for ; Mon, 20 Feb 2017 07:23:00 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 3454D12966B for ; Mon, 20 Feb 2017 07:23:00 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id x10so30815003otb.1 for ; Mon, 20 Feb 2017 07:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ieMOsrziX3wmsRni8tmnKQ4rqtkliPnKFCbBMXTCvGM=; b=mls6USu75NId+Q8fej+Xjqp1Blxf7hVSC2wV0ZuM0EKUtbtomtOX82L3k9hXaJQSpr 2q9o0LpnZpXIg+AJO5Aa4YRFux26rD9Xmq94rqlbhPouvYhtPYpUaEQJ9Zxth40RrPHa 80YKhoedSWXV9B47HyOC8lg44846CVLaTWZF0mdgTU7KWfVLEsKiCcmaUnDI1rHVCC/m FjUvPFI8XnBUgylprgGi+NvHknlvDezX0uB8HogJmy86skOxdQ0BEQcf/nQMIWCqEUM8 kyTN60oZqiyEQF4/OlaqWhJYqn7bj2kx07UhRwGzi1Nvc7+LEjny06CfhuzhviAlOLEv deKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ieMOsrziX3wmsRni8tmnKQ4rqtkliPnKFCbBMXTCvGM=; b=EluEvHC9jUw7v4F/UTvtVHw5twKZKY29OkuFCvKsjF63+1hW86ww3X87/eoYlzWQSq QbINZ6jPDnQgRcg5oC0Sd2h7orF2Z7Vf6sRR0DnxNLIMtgn9LwgIcNcu9AWpf71jldLD M2p20ZbwFfTy2MUxEVQM0JaujDVWR4dx6YqYPiCEewGayYoOLyVD9PbG3EVpu7jRQAGh 5+2em74pHzQPhrF2mJs07ZZhIX0uSFZ01TReu8W3aXpJyEA1hylWL/9/KZW803kcfBpm WzfRdXDyuu/6+ndMwARExXCfebKBsaK6i107WPSVbuBK8Jk7IyiMvMbpkAsLvRQSPO8C 5XOw== X-Gm-Message-State: AMke39ltDmZ3hBs84XbwYSkuvMjr5/3l8PmdgEtSom6zmyQcyqYDXUaH87yGPqwL2lznVBslXh4YPFQ3wEa/ng== X-Received: by 10.157.7.170 with SMTP id 39mr2217468oto.249.1487604179389; Mon, 20 Feb 2017 07:22:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.159.42 with HTTP; Mon, 20 Feb 2017 07:22:38 -0800 (PST) In-Reply-To: <007301d28b5e$a0d29e30$e277da90$@olddog.co.uk> References: <57a8680c-c466-a6e5-bea1-2729f201626f@joelhalpern.com> <007301d28b5e$a0d29e30$e277da90$@olddog.co.uk> From: "Andrew G. Malis" Date: Mon, 20 Feb 2017 10:22:38 -0500 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=94eb2c032126add51a0548f7d649 Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] NSH Common Header flags - C bit X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 15:23:02 -0000 --94eb2c032126add51a0548f7d649 Content-Type: text/plain; charset=UTF-8 As do I. Cheers, Andy On Mon, Feb 20, 2017 at 4:49 AM, Adrian Farrel wrote: > Joel, > > Per Dave's write-up to the list on Jan 18th, I agree with removing this > bit. > > Adrian > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: 20 February 2017 02:10 > > To: sfc@ietf.org > > Subject: [sfc] NSH Common Header flags - C bit > > > > Are there any additional comments on the proposal to remove the C bit? > > > > Yours, > > 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 > --94eb2c032126add51a0548f7d649 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    As do I.

    Cheers,
    Andy


    On Mon, Feb 20, 2017 at 4:49 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
    Joel,

    Per Dave's write-up to the list on Jan 18th, I agree with removing this= bit.

    Adrian

    > -----Original Message-----
    > From: sfc [mailto:    sfc-bounces@= ietf.org] On Behalf Of Joel M. Halpern
    > Sent: 20 February 2017 02:10
    > To: sfc@ietf.org
    > Subject: [sfc] NSH Common Header flags - C bit
    >
    > Are there any additional comments on the proposal to remove the C bit?=
    >
    > Yours,
    > 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

    --94eb2c032126add51a0548f7d649-- From nobody Mon Feb 20 08:23:40 2017 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 B32DF129559 for ; Mon, 20 Feb 2017 08:23:39 -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] 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 g6a_P3ElQTR1 for ; Mon, 20 Feb 2017 08:23:38 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BBB1294DF for ; Mon, 20 Feb 2017 08:23:37 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1KGNZIL000564; Mon, 20 Feb 2017 16:23:35 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1KGNVhO000541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2017 16:23:34 GMT From: "Adrian Farrel" To: "'Joel Halpern Direct'" , References: <8dfdb5fc-1da3-5633-81b6-6ac108051dae@joelhalpern.com> <008e01d28b61$ec399150$c4acb3f0$@olddog.co.uk> <37852da7-2560-1edf-26d3-a566cacb9b4c@joelhalpern.com> In-Reply-To: <37852da7-2560-1edf-26d3-a566cacb9b4c@joelhalpern.com> Date: Mon, 20 Feb 2017 16:23:31 -0000 Message-ID: <012001d28b95$af4d6a80$0de83f80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMojjn5qD4A9VjG0JSRFr/2rcn8uAJIkUo1A26DklwB7ivgSZ6I4Ezw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22898.000 X-TM-AS-Result: No--25.806-10.0-31-10 X-imss-scan-details: No--25.806-10.0-31-10 X-TMASE-MatchedRID: Jm7Yxmmj9OkcYHsGkuuPpUKcYi5Qw/RVIfZjRfGTydhnzkfvXPnYLmlF 7OhYLlctjGQRyBjmksCWEQ+RJFzGeLWd3Qhj3xBV+yHb1zBT5AVAq6/y5AEOOr0rWM4nIpJruml LC5g94Huf/ayjPGtsEb5qpPHBHzeD27P9OYpZ3pqOjIrMSa2sRxdnqTrUdQnP/RM/+SKR6qfg5d EPhBTxulbPOVISu9a4ujvpm8rpuoZ6g49JXoQ8gwlPus/MSqC7IM86Aeo6sYIXhhMNKsb4lSITl Ws6BAHiYT2nBLmIgL3l22c7vF4Nm0I69L22RjXL8eSmTJSmEv1R3sGN+j7mNCNGK7UC7ElMr5qa hUVerFx7WkTZe9vmX7brzAuFRoA6pF+0lJVCjVUmtTGirqG/D34yToAKzDgmDYbe/PyX8gQAxL5 7DAfUoIM0UI/wsMx+LlpVh13itBS3D+jgn28P5uqwWVBfMuvokk5xcxBziMER34ro7k23nfNvmS aCnjTlt+odoSua73aRk6XtYogiarQ/aqQZTRfKRjjVhf+j/wpKdDgyPBo71yq2rl3dzGQ1A/3R8 k/14e0= Archived-At: Subject: Re: [sfc] MD Class registry - Vendor Extensibility X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 16:23:39 -0000 Ooops, my misreading. This is what happens when we have "MD Type" and "Type" all within the "metadata":-) Yes, my mail should read... We have a hierarchy: MD Type (2^8, about to become 2^4 when we add the TTL) MD Class (2^16) MD Context Header Types (2^7 about to become 2^8) So I have some observations... o 2^4 is enough MD types There is no MD type for "vendor specific", and I don't believe we need one. Obviously, the IANA section needs rewriting for the change to 4 bits. o 2^16 is a lot of MD classes. Really a lot! The philosophy appears to be that a context header is distinguished by {MD class, type} and that MD class identifies a source of allocations of type. If so, then yes, we should allow vendors to have a value if (and only if) we want to support that kind of non-interoperable exchange between SFIs. In this case I would *strongly* urge FCFS not Private Use so that it is possible to perform diagnostics and know to whom to attribute the context header. It is probably good to have one or two experimental classes. Not sure there is a case for >2. o 2^8 might not be enough types within a class over time as Med says. However, additional classes can be grabbed if the types in one class are depleted. We *could* allow vendor-specific types within the IETF/NSH class, but I hope not (if the vendor can grab a whole class) It is still probably worth having experimental types in the IETF/NSH class, and I can imagine 4 being a good number. Thanks, Adrian > -----Original Message----- > From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] > Sent: 20 February 2017 13:52 > To: adrian@olddog.co.uk; sfc@ietf.org > Subject: Re: [sfc] MD Class registry - Vendor Extensibility > > I am not sure what the line in your note > "AFAICS only one "optional variable length metadata" can be present > in an NSH." > means? > > In an NSH packet using MD2, there are a sequence of metadata elements. > Each metdata element has an MD-Class, MD-Type, length, and value. > > So what limit are your refering to as "only one"? > > Yours, > Joel > > On 2/20/17 5:12 AM, Adrian Farrel wrote: > > It seems to me, that we need to sort ourselves out a bit wrt flexibility in > > metadata. > > > > We have a hierarchy: > > MD Class (2^16) > > MD Type (2^7, about to become 2^8) > > MD TLVs (different docs) > > > > AFAICS only one "optional variable length metadata" can be present in an NSH. > > > > So I have some observations... > > > > o 2^16 is a lot of MD classes. Really a lot! > > o 2^8 is more than plenty MD types in any class > > o A vendor-specific MD class only works on an SFP > > made up *entirely* of products from that vendor > > o A vendor-specific MD type only works on an SFP > > made up *entirely* of products from that vendor > > o The main (only) place we should care about vendor- > > specific pieces of metadata is in the definitions of > > TLVs in MC0/MD2 (not this doc). > > > > Am I missing a particular use case? > > > > Cheers, > > Adrian > > > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > >> Sent: 20 February 2017 02:09 > >> To: sfc@ietf.org > >> Subject: Re: [sfc] MD Class registry - Vendor Extensibility > >> > >> A related topic on the MD Class and MD Type Registry is that of Vendor > >> extensibility. The current registry text reads: > >> > >> 0x0000 to 0x01ff: IETF Review > >> 0x0200 to 0xfff5: Expert Review > >> 0xfff6 to 0xfffe: Experimental > >> 0xffff: Reserved > >> > >> Even with the minor change I raised for discussion in my previous note, > >> the only space for Vendor's to define their own type values is in the > >> experimental space. It seems to me that is not sufficient. > >> > >> How do we want to address this? We could take a portion of the Class > >> space for vendors. But how would we assign values to vendors for their use? > >> > >> Yours, > >> Joel > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > From nobody Mon Feb 20 08:44:54 2017 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 3306D129495 for ; Mon, 20 Feb 2017 08:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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_LOW=-0.7, 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 nCtRjFc1V9i8 for ; Mon, 20 Feb 2017 08:44:51 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 32129127076 for ; Mon, 20 Feb 2017 08:44:51 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id v186so84981025wmd.0 for ; Mon, 20 Feb 2017 08:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=wuMA6WT3s71NiZ9HaJyZkBCvVbzLW9y0ZRcQCnR4OD8=; b=OUocnPC06+vFZQ1DxJCMURTPUIcSn4NDl1DKpwRNG1/fqhNFCQBf+fr2DV67GPsrf+ 5dTSVqa6PKZ8zxrGqCGNtPOkS26y7RgNxUGsjCXcSRl2BS5sUu4AyzmXWN8Fbs8KWKkW Tk8O2RRSQk5tFrF39AL4uY7iYA8y1nI+sL3A+dkyIm3A356KBFL0YA1ai0KWy1kLG2IW GTO+cSU4Fm6OxO6UrONnLsBGRELt4WMn8n8L/BsmfX38ZX9O3eLNAsKF2Dkwwn/QPCnC zmZ8q3JNzb2CNY8dBw9o8swyRchORC6mmepNiFVJC+yHX5vcD2dYyecgfaWQOfOjDFhp qcWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=wuMA6WT3s71NiZ9HaJyZkBCvVbzLW9y0ZRcQCnR4OD8=; b=prqGEDm352Oel0a9pQ2RfbGTPEZFUQtoegbmTdsPjzTp4WyBUzmdOEk3H9GACMD8Oi pBck5HIWSutS5KVJte7TRIK4iM6jZbVj3KSNVzlYq0/ewl/2i5+jfgBJzLsjxfGZ+HWy Si7F037nmA00aiX89tMVUBwrLazGmFXx/ccYWFhsXGXw6uBxBLSwhC61tbtjX+wU+0CC ytpR+ImDrJjo2fxedgo+w+MvSqPNTGANt4Rpcbi5O0KR7RSzCO9Q9ayuX1+q0/qptx7o EPyNtFEYERa6FKuuJQytJZ/1tEZFNRwadee8YsZdZ8wfj20wo3l967etn2i4hU9DGU8t ECqw== X-Gm-Message-State: AMke39ncIsc8FVwJH0Ig6oCh6Wplo/r9YOe3HJml7Qs4M/9LkioydTX6uzNl0AFKIzXzqD3YIur/uR3p19o1GA== X-Received: by 10.28.179.7 with SMTP id c7mr19624233wmf.128.1487609089565; Mon, 20 Feb 2017 08:44:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.136.170 with HTTP; Mon, 20 Feb 2017 08:44:49 -0800 (PST) From: Behcet Sarikaya Date: Mon, 20 Feb 2017 10:44:49 -0600 Message-ID: To: Mohamed Boucadair Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "adrian@olddog.co.uk" , "Joel M. Halpern" , "sfc@ietf.org" , Eric C Rosen Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 16:44:53 -0000 Hi Med, I am curious, we are putting so much effort, so many cycles on CP requirements, while I think the real interest on this should be what is this CP protocol itself? People are asking where is the beef? Currently this is somewhat mysteriously hidden. I suggest putting our efforts, the real minds on that? Regards, Behcet On Mon, Feb 20, 2017 at 1:26 AM, wrote: > Hi Adrian, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Adrian Farrel [mailto:adrian@olddog.co.uk] >> Envoy=C3=A9 : vendredi 17 f=C3=A9vrier 2017 17:30 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; 'Eric C Rosen'; 'Joel M. Halpern'; >> sfc@ietf.org >> Objet : RE: [sfc] How to progress our control plane requirements documen= t >> >> Hi Med, >> >> I'm not convinced that this draft should address the CP requirements in >> your >> draft. > > [Med] That's fine by me. It is perfectly fine to address a subset of requ= irements, but what I'm less comfortable with is to call a proposal (The) "C= ontrol plane for SFC". > > It seems more important to build a functional system(i.e., one that >> works >> and delivers the operational function that makes an SFC network work). >> >> Therefore, in reviewing the draft it may be more helpful to say: >> - this doesn't work >> - I need to achieve this function >> - this could be done better. >> > [Med] I confess this wasn't my perspective when reading the mackie draft. > >> But for completeness, here are some answers to your points: >> >> > For example, I checked your BGP CP draft to check if it addresses the = CP >> > requirement in the SFC CP draft. Many of these CP requirements are >> included in >> > your proposal but many others are missing, e.g., >> > >> > * I don't see how classification rules are installed/removed/updated. >> >> Section 7.5 > [Med] Sorry. Thank you for the pointer. > >> >> > * I don't see any features to associate classification and forwarding >> entries >> with >> > validity lifetime. >> >> I don't believe this to be a useful feature. > > [Med] Programming a state that is not limited in time may be a source of = troubles from a manageability standpoint. Means to help the classifier to a= utomatically clean its table without an explicit action from a third party = (controllers) are useful, IMO. > >> But it could be added at some point. >> > [Med] Sure. BGP is powerful enough :) > >> > * I don't see how the CP sets the SI at classifiers >> >> Section 7.5 >> >> > * I don't see how the CP set the semantic of a metadata per each chain= , >> scope, >> > etc. >> >> It would be premature to define a control plane for something that hasn'= t >> been >> properly specified in the forwarding plane. > > [Med] I understand your argument about the weakness of the DP plane spec = in this regards, but I do think that is (hopefully) fixed with the new text= (https://trac.ietf.org/trac/sfc/ticket/21) > >> But it seems to me that most SFs will not be so programmable: they will >> look for >> specific TLVs in metadata and ignore (forward) the rest, and they will a= dd >> specific TLVs to the metadata. > > [Med] I don't know what is/will be a default behavior of an SFC-ware SF. = For example, I don't see based on which criteria a CGN or firewall SF will = decide that it must look for particular TLVs. Also, I don't see based on wh= ich criteria a classifier implementation will decide to inject a given set = of TLVs, etc. There is a void that needs to be fulfilled by the CP. > >> Sending CP messages will not change the behavior of SFs in this regard. > [Med] There is a need to communicate SFC instructions to underlying SFC-a= ware nodes. > >> Attempting to do so would be adding unnecessary complexity to the system= . >> >> > * I don't see how the CP indicates the behavior to follow when a >> metadata is >> > consumed >> >> Ditto the above only more so! >> An SF is an SF and is not CP-programmable. > > [Med] We are not talking about SFs in general, but about SFC-aware SFs. O= f course, SF-specific control is not of interest here. > >> >> > * I don't see how an SFC proxy in instructed to insert/supply metadata >> on >> behalf >> > of SFC-unaware SFs >> >> An SFC proxy is, in that respect, no different from the metadata compone= nt >> of an >> SF that can handle metadata. > > [Med] ... except that the proxy does not know what TLVs are to be inserte= d/stripped/modified per attached SF (and per chain). > >> >> But you *have* pointed to an interesting "hole" in the architecture if i= t >> is >> assumed that the SFC proxy can somehow know about the state in the SFC- >> unaware >> SF and shape metadata accordingly. >> >> > * I don't see the CP behavior when an SF is to be withdrawn >> >> I don't even know what it means to "withdraw an SF". > > [Med] What I meant is, for example, when an SF is decommissioned or when= now instance is available to deliver the service. Does the solution allows= to maintain the installed SFPs but with a bypass of that SF or it imposes = to reinstall new paths. > >> Do you mean "to take an SFI gracefully out of service"? If so, you would >> simply >> withdraw the SFIR and the route would go (as is normal in BGP). >> Or do you mean "to remove an SF from an SFP"? If so, 4.5.1. >> >> > * I don't see how an SFC proxy is instructed about the SFs to service. >> >> Are you asking how a proxy that severs more than one SF knows to which S= F >> to >> route packets? > > [Med] This is more about checking that only entitled SFs are authorized t= o be serviced by a proxy. > >> If you are, then my answer is "don't do that!" Proxies are cheap. You ca= n >> virtualise a proxy at any location. >> >> > * Etc. >> >> See section, oh... :-) > > [Med] Will read that section SOON ;-) > >> >> Thanks, >> Adrian > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 20 09:00:01 2017 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 C255E12951E for ; Mon, 20 Feb 2017 08:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pvIN_AjcWtFR for ; Mon, 20 Feb 2017 08:59:58 -0800 (PST) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.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 4D0C1129465 for ; Mon, 20 Feb 2017 08:59:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 337BA4E4583; Mon, 20 Feb 2017 08:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1487609998; bh=ruxJHl5omDll/NJt4I8VP0S0Lb+In35DFUDbH1Jbk5k=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DbTgLTgR/GRZWG86wp0KSe/Z2qB4rYK5SDHOUqrXa25OJF0G9XtWotN8DavQEGmZv TKlEeO6kCxtNbcbR3aMfZpseh9QTpjgd2j5WO2QNYHIw8yqVEq/MNQ8kj2liYoknWh SgKowKyCQUzEAaf5LquIrf4BudzaTN020hVYrYkY= 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 8DB5E4E47BE; Mon, 20 Feb 2017 08:59:57 -0800 (PST) To: adrian@olddog.co.uk, sfc@ietf.org References: <8dfdb5fc-1da3-5633-81b6-6ac108051dae@joelhalpern.com> <008e01d28b61$ec399150$c4acb3f0$@olddog.co.uk> <37852da7-2560-1edf-26d3-a566cacb9b4c@joelhalpern.com> <012001d28b95$af4d6a80$0de83f80$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Mon, 20 Feb 2017 11:59:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <012001d28b95$af4d6a80$0de83f80$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] MD Class registry - Vendor Extensibility X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 17:00:00 -0000 Just to make sure I understand your suggestion regarding MD Class, we could take a large portion of the range and declare it to be FCFS, with a note that this is expected to be used by vendors for their own proprietary or pre-standard extensions? On the theory that there probably are not even 1000 different vendors who need code points? While I understand your point about interoperability, we also are not in a position to enumerate all desired metadata. So having a way for folks to deploy stuff we have not enumerated seems helpful. Should we have any statement about how vendors should document Type codes within their assigned MD Class? Yours, Joel On 2/20/17 11:23 AM, Adrian Farrel wrote: > Ooops, my misreading. > > This is what happens when we have "MD Type" and "Type" all within the > "metadata":-) > > Yes, my mail should read... > > We have a hierarchy: > MD Type (2^8, about to become 2^4 when we add the TTL) > MD Class (2^16) > MD Context Header Types (2^7 about to become 2^8) > > So I have some observations... > o 2^4 is enough MD types > There is no MD type for "vendor specific", and I don't believe we > need one. > Obviously, the IANA section needs rewriting for the change to 4 bits. > o 2^16 is a lot of MD classes. Really a lot! > The philosophy appears to be that a context header is distinguished > by {MD class, type} and that MD class identifies a source of allocations > of type. > If so, then yes, we should allow vendors to have a value if (and only if) > we want to support that kind of non-interoperable exchange between > SFIs. > In this case I would *strongly* urge FCFS not Private Use so that it is > possible to perform diagnostics and know to whom to attribute the > context header. > It is probably good to have one or two experimental classes. Not sure > there is a case for >2. > o 2^8 might not be enough types within a class over time as Med says. > However, additional classes can be grabbed if the types in one class > are depleted. > We *could* allow vendor-specific types within the IETF/NSH class, > but I hope not (if the vendor can grab a whole class) > It is still probably worth having experimental types in the IETF/NSH > class, and I can imagine 4 being a good number. > > Thanks, > Adrian > >> -----Original Message----- >> From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] >> Sent: 20 February 2017 13:52 >> To: adrian@olddog.co.uk; sfc@ietf.org >> Subject: Re: [sfc] MD Class registry - Vendor Extensibility >> >> I am not sure what the line in your note >> "AFAICS only one "optional variable length metadata" can be present >> in an NSH." >> means? >> >> In an NSH packet using MD2, there are a sequence of metadata elements. >> Each metdata element has an MD-Class, MD-Type, length, and value. >> >> So what limit are your refering to as "only one"? >> >> Yours, >> Joel >> >> On 2/20/17 5:12 AM, Adrian Farrel wrote: >>> It seems to me, that we need to sort ourselves out a bit wrt flexibility in >>> metadata. >>> >>> We have a hierarchy: >>> MD Class (2^16) >>> MD Type (2^7, about to become 2^8) >>> MD TLVs (different docs) >>> >>> AFAICS only one "optional variable length metadata" can be present in an > NSH. >>> >>> So I have some observations... >>> >>> o 2^16 is a lot of MD classes. Really a lot! >>> o 2^8 is more than plenty MD types in any class >>> o A vendor-specific MD class only works on an SFP >>> made up *entirely* of products from that vendor >>> o A vendor-specific MD type only works on an SFP >>> made up *entirely* of products from that vendor >>> o The main (only) place we should care about vendor- >>> specific pieces of metadata is in the definitions of >>> TLVs in MC0/MD2 (not this doc). >>> >>> Am I missing a particular use case? >>> >>> Cheers, >>> Adrian >>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: 20 February 2017 02:09 >>>> To: sfc@ietf.org >>>> Subject: Re: [sfc] MD Class registry - Vendor Extensibility >>>> >>>> A related topic on the MD Class and MD Type Registry is that of Vendor >>>> extensibility. The current registry text reads: >>>> >>>> 0x0000 to 0x01ff: IETF Review >>>> 0x0200 to 0xfff5: Expert Review >>>> 0xfff6 to 0xfffe: Experimental >>>> 0xffff: Reserved >>>> >>>> Even with the minor change I raised for discussion in my previous note, >>>> the only space for Vendor's to define their own type values is in the >>>> experimental space. It seems to me that is not sufficient. >>>> >>>> How do we want to address this? We could take a portion of the Class >>>> space for vendors. But how would we assign values to vendors for their > use? >>>> >>>> Yours, >>>> 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 Mon Feb 20 09:40:50 2017 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 5BB291294CA for ; Mon, 20 Feb 2017 09:40:49 -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] 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 4g1sf0y1_Lio for ; Mon, 20 Feb 2017 09:40:47 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B031294B6 for ; Mon, 20 Feb 2017 09:40:46 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1KHehcc013599; Mon, 20 Feb 2017 17:40:43 GMT Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1KHeekL013578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2017 17:40:42 GMT From: "Adrian Farrel" To: , "'Mohamed Boucadair'" References: In-Reply-To: Date: Mon, 20 Feb 2017 17:40:38 -0000 Message-ID: <013601d28ba0$76182dd0$62488970$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbvRbjQowIm4UMKTH7zMncQbw1k6Ffxnmw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22898.001 X-TM-AS-Result: No--41.376-10.0-31-10 X-imss-scan-details: No--41.376-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkA4HKI/yaqRm8zWN98iBBeG7N+vyLe4S0dDX9VhR7HOlNLu X2hj/M7UegtkOYJGr+VUkTHjK3FB4qoxnLP9FwYuaDCzqDR7DPYfbG+50hrCQ4qUnvVNf36DbjZ DqA/zbpAjC473tmeTGdKUydbOCQ9jkEj9eRgyMg6dtRmRhPNchtZKsq3DGpalkHKe4syukRjDKS GQAmP2wVhFSGi0B5ld20aOVSzMHoCrk4SVjTOUqlVN8laWo90MlnrMq7Sriu3jsTquy0JRi/Z6p i02vcUycaynXz1H7EVeA6MGWSPEbnOAMSqhBqB69Ib/6w+1lWTomPrNi98UBEsgCDMQSxLSK33G ICKuN/9xpbu+fW+8N7CWR8ETqLLiMtCMcfANeKYSEYfcJF0pRdmmHZ8J+6h3MxVjmK1sOgPVsIS HjAOfi/GwBy5QY1aj1qqYER4Oo4hLc0v2hlJrc8MOZc2T6sulra3+HZkEwPohvFjBsLEZNEDvTH 5iN7bG0O3M83B1FMOMkGULrGF60tPYURkTpZRiYR6QE8KYfsiUi9wB9gmcSri7yMDZhOacYyzka Ncuq8aof8zNCYSXeohKV5n/9uUN0f9apaWMaFLDa1qWPNOExsAm5RFw2LaYOEl+TwtL+9BS5Jz4 Ls9O/ywXMFPlpsQ1K5X4qC6dTGUGYKq163Lsnc6RKnOYsI58IR1rLBJm/M4LCC+rIG9+ZfWyAGU 0Js1gkY4zJJUDay0wKtNd0hOvItMOjHG3nUBwA9lly13c/gEW+kaqYhU/8yBQRBOQhaJizYBEYZ NzuHrJkIy6QRkFQsKKPpXazHlQLSAL/uJe7aieAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Cc: "'Joel M. Halpern'" , sfc@ietf.org, 'Eric C Rosen' Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 17:40:49 -0000 Hi Behcet, datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/ :-) Adrian > -----Original Message----- > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > Sent: 20 February 2017 16:45 > To: Mohamed Boucadair > Cc: adrian@olddog.co.uk; Eric C Rosen; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] How to progress our control plane requirements = document >=20 > Hi Med, >=20 > I am curious, we are putting so much effort, so many cycles on CP > requirements, while I think the real interest on this should be what > is this CP protocol itself? People are asking where is the beef? >=20 > Currently this is somewhat mysteriously hidden. >=20 > I suggest putting our efforts, the real minds on that? >=20 > Regards, >=20 > Behcet >=20 > On Mon, Feb 20, 2017 at 1:26 AM, = wrote: > > Hi Adrian, > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Envoy=C3=A9 : vendredi 17 f=C3=A9vrier 2017 17:30 > >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; 'Eric C Rosen'; 'Joel M. = Halpern'; > >> sfc@ietf.org > >> Objet : RE: [sfc] How to progress our control plane requirements = document > >> > >> Hi Med, > >> > >> I'm not convinced that this draft should address the CP = requirements in > >> your > >> draft. > > > > [Med] That's fine by me. It is perfectly fine to address a subset of > requirements, but what I'm less comfortable with is to call a proposal = (The) > "Control plane for SFC". > > > > It seems more important to build a functional system(i.e., one that > >> works > >> and delivers the operational function that makes an SFC network = work). > >> > >> Therefore, in reviewing the draft it may be more helpful to say: > >> - this doesn't work > >> - I need to achieve this function > >> - this could be done better. > >> > > [Med] I confess this wasn't my perspective when reading the mackie = draft. > > > >> But for completeness, here are some answers to your points: > >> > >> > For example, I checked your BGP CP draft to check if it addresses = the CP > >> > requirement in the SFC CP draft. Many of these CP requirements = are > >> included in > >> > your proposal but many others are missing, e.g., > >> > > >> > * I don't see how classification rules are = installed/removed/updated. > >> > >> Section 7.5 > > [Med] Sorry. Thank you for the pointer. > > > >> > >> > * I don't see any features to associate classification and = forwarding > >> entries > >> with > >> > validity lifetime. > >> > >> I don't believe this to be a useful feature. > > > > [Med] Programming a state that is not limited in time may be a = source of > troubles from a manageability standpoint. Means to help the classifier = to > automatically clean its table without an explicit action from a third = party > (controllers) are useful, IMO. > > > >> But it could be added at some point. > >> > > [Med] Sure. BGP is powerful enough :) > > > >> > * I don't see how the CP sets the SI at classifiers > >> > >> Section 7.5 > >> > >> > * I don't see how the CP set the semantic of a metadata per each = chain, > >> scope, > >> > etc. > >> > >> It would be premature to define a control plane for something that = hasn't > >> been > >> properly specified in the forwarding plane. > > > > [Med] I understand your argument about the weakness of the DP plane = spec in > this regards, but I do think that is (hopefully) fixed with the new = text > (https://trac.ietf.org/trac/sfc/ticket/21) > > > >> But it seems to me that most SFs will not be so programmable: they = will > >> look for > >> specific TLVs in metadata and ignore (forward) the rest, and they = will add > >> specific TLVs to the metadata. > > > > [Med] I don't know what is/will be a default behavior of an SFC-ware = SF. For > example, I don't see based on which criteria a CGN or firewall SF will = decide that it > must look for particular TLVs. Also, I don't see based on which = criteria a classifier > implementation will decide to inject a given set of TLVs, etc. There = is a void that > needs to be fulfilled by the CP. > > > >> Sending CP messages will not change the behavior of SFs in this = regard. > > [Med] There is a need to communicate SFC instructions to underlying = SFC- > aware nodes. > > > >> Attempting to do so would be adding unnecessary complexity to the = system. > >> > >> > * I don't see how the CP indicates the behavior to follow when a > >> metadata is > >> > consumed > >> > >> Ditto the above only more so! > >> An SF is an SF and is not CP-programmable. > > > > [Med] We are not talking about SFs in general, but about SFC-aware = SFs. Of > course, SF-specific control is not of interest here. > > > >> > >> > * I don't see how an SFC proxy in instructed to insert/supply = metadata > >> on > >> behalf > >> > of SFC-unaware SFs > >> > >> An SFC proxy is, in that respect, no different from the metadata = component > >> of an > >> SF that can handle metadata. > > > > [Med] ... except that the proxy does not know what TLVs are to be > inserted/stripped/modified per attached SF (and per chain). > > > >> > >> But you *have* pointed to an interesting "hole" in the architecture = if it > >> is > >> assumed that the SFC proxy can somehow know about the state in the = SFC- > >> unaware > >> SF and shape metadata accordingly. > >> > >> > * I don't see the CP behavior when an SF is to be withdrawn > >> > >> I don't even know what it means to "withdraw an SF". > > > > [Med] What I meant is, for example, when an SF is decommissioned or = when > now instance is available to deliver the service. Does the solution = allows to > maintain the installed SFPs but with a bypass of that SF or it imposes = to reinstall > new paths. > > > >> Do you mean "to take an SFI gracefully out of service"? If so, you = would > >> simply > >> withdraw the SFIR and the route would go (as is normal in BGP). > >> Or do you mean "to remove an SF from an SFP"? If so, 4.5.1. > >> > >> > * I don't see how an SFC proxy is instructed about the SFs to = service. > >> > >> Are you asking how a proxy that severs more than one SF knows to = which SF > >> to > >> route packets? > > > > [Med] This is more about checking that only entitled SFs are = authorized to be > serviced by a proxy. > > > >> If you are, then my answer is "don't do that!" Proxies are cheap. = You can > >> virtualise a proxy at any location. > >> > >> > * Etc. > >> > >> See section, oh... :-) > > > > [Med] Will read that section SOON ;-) > > > >> > >> Thanks, > >> Adrian > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 20 22:34:18 2017 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 EC0D0129B56 for ; Mon, 20 Feb 2017 22:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 1ey4vqiL4DJv for ; Mon, 20 Feb 2017 22:34:15 -0800 (PST) Received: from relais-inet.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 0F448129B59 for ; Mon, 20 Feb 2017 22:34:15 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 35EBF180458; Tue, 21 Feb 2017 07:34:13 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id E7857120074; Tue, 21 Feb 2017 07:34:12 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 07:34:12 +0100 From: To: "adrian@olddog.co.uk" , 'Joel Halpern Direct' , "sfc@ietf.org" Thread-Topic: [sfc] MD Class registry - Vendor Extensibility Thread-Index: AQMojjn5qD4A9VjG0JSRFr/2rcn8uAJIkUo1A26DklwB7ivgSZ6I4EzwgADr7DA= Date: Tue, 21 Feb 2017 06:34:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E151D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8dfdb5fc-1da3-5633-81b6-6ac108051dae@joelhalpern.com> <008e01d28b61$ec399150$c4acb3f0$@olddog.co.uk> <37852da7-2560-1edf-26d3-a566cacb9b4c@joelhalpern.com> <012001d28b95$af4d6a80$0de83f80$@olddog.co.uk> In-Reply-To: <012001d28b95$af4d6a80$0de83f80$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] MD Class registry - Vendor Extensibility X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 06:34:17 -0000 Hi all,=20 One comment inline. Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > Envoy=E9=A0: lundi 20 f=E9vrier 2017 17:24 > =C0=A0: 'Joel Halpern Direct'; sfc@ietf.org > Objet=A0: Re: [sfc] MD Class registry - Vendor Extensibility >=20 > Ooops, my misreading. >=20 > This is what happens when we have "MD Type" and "Type" all within the > "metadata":-) >=20 > Yes, my mail should read... >=20 > We have a hierarchy: > MD Type (2^8, about to become 2^4 when we add the TTL) > MD Class (2^16) > MD Context Header Types (2^7 about to become 2^8) >=20 > So I have some observations... > o 2^4 is enough MD types > There is no MD type for "vendor specific", and I don't believe we > need one. > Obviously, the IANA section needs rewriting for the change to 4 bits. > o 2^16 is a lot of MD classes. Really a lot! > The philosophy appears to be that a context header is distinguished > by {MD class, type} and that MD class identifies a source of > allocations > of type. > If so, then yes, we should allow vendors to have a value if (and only > if) > we want to support that kind of non-interoperable exchange between > SFIs. > In this case I would *strongly* urge FCFS not Private Use so that it i= s > possible to perform diagnostics and know to whom to attribute the > context header. > It is probably good to have one or two experimental classes. Not sure > there is a case for >2. > o 2^8 might not be enough types within a class over time as Med says. > However, additional classes can be grabbed if the types in one class > are depleted. [Med] Grabbing one additional MD Class would be OK for the IETF assigned MD= .Type values. However, for MD classes that want to reuse an existing regist= ry, this is problematic because the 1:1 mapping won't be easy to define.=20 * Having a longer type field will allow to map the whole IPFIX registry (ht= tps://tools.ietf.org/html/rfc7012#section-4). IPFIX ElementID are in the ra= nge 1-32767. * Having a longer type field will allow to map the whole table in Section 7= .1 of http://www.etsi.org/deliver/etsi_ts/129200_129299/129230/12.06.00_60/= ts_129230v120600p.pdf in one single MD Class to be called, for example, 3GP= P. =20 > We *could* allow vendor-specific types within the IETF/NSH class, > but I hope not (if the vendor can grab a whole class) > It is still probably worth having experimental types in the IETF/NSH > class, and I can imagine 4 being a good number. [Med] I suggest: * no vendor-specific values are allowed in the IETF Classes. =20 * using few shared MD Classes for this usage. Type values can be assigned i= n that range following an FCFS approach. Vendor-specific values can be then= assigned without consuming an MD class. One shared MD Class can be created= in the NSH document to anticipate vendor-specific requests. >=20 > Thanks, > Adrian >=20 > > -----Original Message----- > > From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] > > Sent: 20 February 2017 13:52 > > To: adrian@olddog.co.uk; sfc@ietf.org > > Subject: Re: [sfc] MD Class registry - Vendor Extensibility > > > > I am not sure what the line in your note > > "AFAICS only one "optional variable length metadata" can be presen= t > > in an NSH." > > means? > > > > In an NSH packet using MD2, there are a sequence of metadata elements. > > Each metdata element has an MD-Class, MD-Type, length, and value. > > > > So what limit are your refering to as "only one"? > > > > Yours, > > Joel > > > > On 2/20/17 5:12 AM, Adrian Farrel wrote: > > > It seems to me, that we need to sort ourselves out a bit wrt > flexibility in > > > metadata. > > > > > > We have a hierarchy: > > > MD Class (2^16) > > > MD Type (2^7, about to become 2^8) > > > MD TLVs (different docs) > > > > > > AFAICS only one "optional variable length metadata" can be present in > an > NSH. > > > > > > So I have some observations... > > > > > > o 2^16 is a lot of MD classes. Really a lot! > > > o 2^8 is more than plenty MD types in any class > > > o A vendor-specific MD class only works on an SFP > > > made up *entirely* of products from that vendor > > > o A vendor-specific MD type only works on an SFP > > > made up *entirely* of products from that vendor > > > o The main (only) place we should care about vendor- > > > specific pieces of metadata is in the definitions of > > > TLVs in MC0/MD2 (not this doc). > > > > > > Am I missing a particular use case? > > > > > > Cheers, > > > Adrian > > > > > >> -----Original Message----- > > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > >> Sent: 20 February 2017 02:09 > > >> To: sfc@ietf.org > > >> Subject: Re: [sfc] MD Class registry - Vendor Extensibility > > >> > > >> A related topic on the MD Class and MD Type Registry is that of > Vendor > > >> extensibility. The current registry text reads: > > >> > > >> 0x0000 to 0x01ff: IETF Review > > >> 0x0200 to 0xfff5: Expert Review > > >> 0xfff6 to 0xfffe: Experimental > > >> 0xffff: Reserved > > >> > > >> Even with the minor change I raised for discussion in my previous > note, > > >> the only space for Vendor's to define their own type values is in th= e > > >> experimental space. It seems to me that is not sufficient. > > >> > > >> How do we want to address this? We could take a portion of the Clas= s > > >> space for vendors. But how would we assign values to vendors for > their > use? > > >> > > >> Yours, > > >> Joel > > >> > > >> _______________________________________________ > > >> sfc mailing list > > >> sfc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sfc > > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 20 22:55:26 2017 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 A47B2129872 for ; Mon, 20 Feb 2017 22:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nUjLt4D30_X4 for ; Mon, 20 Feb 2017 22:55:24 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1125A12986D for ; Mon, 20 Feb 2017 22:55:24 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 9D3F3120501; Tue, 21 Feb 2017 07:55:22 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 6D6F7180072; Tue, 21 Feb 2017 07:55:22 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 07:55:22 +0100 From: To: "sarikaya@ieee.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHSi5inndWXDlo5okqhhX4it3xlUKFzAjMw Date: Tue, 21 Feb 2017 06:55:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E151F9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: 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.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" , "Joel M. Halpern" , "sfc@ietf.org" , Eric C Rosen Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 06:55:26 -0000 SGkgQmVoY2V0LCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogQmVoY2V0IFNhcmlrYXlhIFttYWls dG86c2FyaWtheWEyMDEyQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBsdW5kaSAyMCBmw6l2cmll ciAyMDE3IDE3OjQ1DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4gQ2PCoDog YWRyaWFuQG9sZGRvZy5jby51azsgRXJpYyBDIFJvc2VuOyBKb2VsIE0uIEhhbHBlcm47IHNmY0Bp ZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW3NmY10gSG93IHRvIHByb2dyZXNzIG91ciBjb250cm9s IHBsYW5lIHJlcXVpcmVtZW50cyBkb2N1bWVudA0KPiANCj4gSGkgTWVkLA0KPiANCj4gSSBhbSBj dXJpb3VzLCB3ZSBhcmUgcHV0dGluZyBzbyBtdWNoIGVmZm9ydCwgc28gbWFueSBjeWNsZXMgb24g Q1ANCj4gcmVxdWlyZW1lbnRzLCB3aGlsZSBJIHRoaW5rIHRoZSByZWFsIGludGVyZXN0IG9uIHRo aXMgc2hvdWxkIGJlIHdoYXQNCj4gaXMgdGhpcyBDUCBwcm90b2NvbCBpdHNlbGY/DQoNCltNZWRd IEknbSBub3Qgc3VyZSB0aGVyZSB3aWxsICJvbmUiIENQIHByb3RvY29sLiBJdCBpcyBsaWtlbHkg dGhlcmUgd2lsbCBiZSBtYW55IHByb3RvY29scyBhbmQgcHJvdG9jb2xzIGV4dGVuc2lvbnMgdG8g ZmlsbCB0aGUgdm9pZC4gRm9yIGV4YW1wbGUsIA0KKiBzb21lIGRlcGxveW1lbnRzIG1heSByZXVz ZSB0aGVpciBleGlzdGluZyBQQ0MgYXJjaGl0ZWN0dXJlIGJ1dCBhdWdtZW50ZWQgd2l0aCBuZXcg dG9vbHMsDQoqIHdoaWxlIG90aGVycyBtYXkgd2FudCB0byByZXVzZSB0aGVpciBSQURJVVMgcGxh dGZvcm1zIHRvIGludGVyYWN0IHdpdGggdGhlIGNsYXNzaWZpZXIgd2hpbGUgb3RoZXIgU0ZDIG5v ZGVzIGFyZSBjb250cm9sbGVkIHZpYSBvbmUgb3IgbW9yZSBjb250cm9sIGVsZW1lbnRzLA0KKiBz b21lIG90aGVyIGRlcGxveW1lbnRzIG1heSBoYXZlIGEgcHJlZmVyZW5jZSBmb3IgYW4gZXh0ZW5z aW9uIHRvIEJHUA0KKiBvdGhlcnMgbWF5IHByZWZlciB0byB1c2UgUENFDQoqIG90aGVyIG1heSBj b21iaW5lIEJHUCBhbmQgUENFLCBhbmQgc28gb24uDQoNClRoZSB3aG9sZSBwb2ludCBvZiB0aGlz IHJlcXVpcmVtZW50IGVmZm9ydCB3YXMgdG8gbWFrZSBzdXJlIHRoYXQgYSBtaW5pbXVtIHNldCBv ZiBDUCByZXF1aXJlbWVudHMsIGRyYXduIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBTRkMg V0cgYnV0IGRlZmluZWQgaW4gb3RoZXIgV0cgZXZlbnR1YWxseSwgYXJlIGZ1bGZpbGxlZCB3aXRo aW4gYW4gU0ZDIGRvbWFpbi4gDQoNCkkgZG9uJ3Qgc2VlIGhvdyB0aGUgSUVURiBjYW4gbWFuZGF0 ZSBhIGdpdmVuIGRlcGxveW1lbnQgdG8gdXNlIEJHUCAoZm9yIGV4YW1wbGUpIHdoaWxlIGFuIHVw ZGF0ZSBvZiBleGlzdGluZyBjb250cm9sIHRvb2xzIG1heSBkbyB0aGUgam9iLiBGb3IgZXhhbXBs ZSwgbWFuZGF0aW5nIHRoYXQgZXZlcnkgU0YgaW5zdGFuY2UgdG8gYmUgYSBCR1Agc3BlYWtlciBp cyB0b28gaGlnaC4gDQoNCiBQZW9wbGUgYXJlIGFza2luZyB3aGVyZSBpcyB0aGUgYmVlZj8NCg0K W01lZF0gWW91IGhhdmUgdG8gd2FpdCBmb3IgdGhlIHN0YXJ0ZXIgZmlyc3QuIEkgZnVsbHkgYWdy ZWUgaXQgaXMgZnJ1c3RyYXRpbmcgdG8gd2FpdCBmb3IgdG9vIGxvbmcuIEkgaGVhciB5b3UsIEJl aGNldC4NCg0KPiANCj4gQ3VycmVudGx5IHRoaXMgaXMgc29tZXdoYXQgbXlzdGVyaW91c2x5IGhp ZGRlbi4NCj4gDQo+IEkgc3VnZ2VzdCBwdXR0aW5nIG91ciBlZmZvcnRzLCB0aGUgcmVhbCBtaW5k cyBvbiB0aGF0Pw0KPiANCj4gUmVnYXJkcywNCj4gDQo+IEJlaGNldA0KPiANCj4gT24gTW9uLCBG ZWIgMjAsIDIwMTcgYXQgMToyNiBBTSwgIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3 cm90ZToNCj4gPiBIaSBBZHJpYW4sDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0K PiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gPj4gRGUgOiBBZHJpYW4gRmFycmVsIFttYWlsdG86YWRyaWFuQG9sZGRvZy5jby51a10N Cj4gPj4gRW52b3nDqSA6IHZlbmRyZWRpIDE3IGbDqXZyaWVyIDIwMTcgMTc6MzANCj4gPj4gw4Ag OiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyAnRXJpYyBDIFJvc2VuJzsgJ0pvZWwgTS4gSGFs cGVybic7DQo+ID4+IHNmY0BpZXRmLm9yZw0KPiA+PiBPYmpldCA6IFJFOiBbc2ZjXSBIb3cgdG8g cHJvZ3Jlc3Mgb3VyIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzDQo+IGRvY3VtZW50DQo+ID4+ DQo+ID4+IEhpIE1lZCwNCj4gPj4NCj4gPj4gSSdtIG5vdCBjb252aW5jZWQgdGhhdCB0aGlzIGRy YWZ0IHNob3VsZCBhZGRyZXNzIHRoZSBDUCByZXF1aXJlbWVudHMgaW4NCj4gPj4geW91cg0KPiA+ PiBkcmFmdC4NCj4gPg0KPiA+IFtNZWRdIFRoYXQncyBmaW5lIGJ5IG1lLiBJdCBpcyBwZXJmZWN0 bHkgZmluZSB0byBhZGRyZXNzIGEgc3Vic2V0IG9mDQo+IHJlcXVpcmVtZW50cywgYnV0IHdoYXQg SSdtIGxlc3MgY29tZm9ydGFibGUgd2l0aCBpcyB0byBjYWxsIGEgcHJvcG9zYWwNCj4gKFRoZSkg IkNvbnRyb2wgcGxhbmUgZm9yIFNGQyIuDQo+ID4NCj4gPiBJdCBzZWVtcyBtb3JlIGltcG9ydGFu dCB0byBidWlsZCBhIGZ1bmN0aW9uYWwgc3lzdGVtKGkuZS4sIG9uZSB0aGF0DQo+ID4+IHdvcmtz DQo+ID4+IGFuZCBkZWxpdmVycyB0aGUgb3BlcmF0aW9uYWwgZnVuY3Rpb24gdGhhdCBtYWtlcyBh biBTRkMgbmV0d29yayB3b3JrKS4NCj4gPj4NCj4gPj4gVGhlcmVmb3JlLCBpbiByZXZpZXdpbmcg dGhlIGRyYWZ0IGl0IG1heSBiZSBtb3JlIGhlbHBmdWwgdG8gc2F5Og0KPiA+PiAtIHRoaXMgZG9l c24ndCB3b3JrDQo+ID4+IC0gSSBuZWVkIHRvIGFjaGlldmUgdGhpcyBmdW5jdGlvbg0KPiA+PiAt IHRoaXMgY291bGQgYmUgZG9uZSBiZXR0ZXIuDQo+ID4+DQo+ID4gW01lZF0gSSBjb25mZXNzIHRo aXMgd2Fzbid0IG15IHBlcnNwZWN0aXZlIHdoZW4gcmVhZGluZyB0aGUgbWFja2llDQo+IGRyYWZ0 Lg0KPiA+DQo+ID4+IEJ1dCBmb3IgY29tcGxldGVuZXNzLCBoZXJlIGFyZSBzb21lIGFuc3dlcnMg dG8geW91ciBwb2ludHM6DQo+ID4+DQo+ID4+ID4gRm9yIGV4YW1wbGUsIEkgY2hlY2tlZCB5b3Vy IEJHUCBDUCBkcmFmdCB0byBjaGVjayBpZiBpdCBhZGRyZXNzZXMgdGhlDQo+IENQDQo+ID4+ID4g cmVxdWlyZW1lbnQgaW4gdGhlIFNGQyBDUCBkcmFmdC4gTWFueSBvZiB0aGVzZSBDUCByZXF1aXJl bWVudHMgYXJlDQo+ID4+IGluY2x1ZGVkIGluDQo+ID4+ID4geW91ciBwcm9wb3NhbCBidXQgbWFu eSBvdGhlcnMgYXJlIG1pc3NpbmcsIGUuZy4sDQo+ID4+ID4NCj4gPj4gPiAqIEkgZG9uJ3Qgc2Vl IGhvdyBjbGFzc2lmaWNhdGlvbiBydWxlcyBhcmUgaW5zdGFsbGVkL3JlbW92ZWQvdXBkYXRlZC4N Cj4gPj4NCj4gPj4gU2VjdGlvbiA3LjUNCj4gPiBbTWVkXSBTb3JyeS4gVGhhbmsgeW91IGZvciB0 aGUgcG9pbnRlci4NCj4gPg0KPiA+Pg0KPiA+PiA+ICogSSBkb24ndCBzZWUgYW55IGZlYXR1cmVz IHRvIGFzc29jaWF0ZSBjbGFzc2lmaWNhdGlvbiBhbmQgZm9yd2FyZGluZw0KPiA+PiBlbnRyaWVz DQo+ID4+IHdpdGgNCj4gPj4gPiB2YWxpZGl0eSBsaWZldGltZS4NCj4gPj4NCj4gPj4gSSBkb24n dCBiZWxpZXZlIHRoaXMgdG8gYmUgYSB1c2VmdWwgZmVhdHVyZS4NCj4gPg0KPiA+IFtNZWRdIFBy b2dyYW1taW5nIGEgc3RhdGUgdGhhdCBpcyBub3QgbGltaXRlZCBpbiB0aW1lIG1heSBiZSBhIHNv dXJjZSBvZg0KPiB0cm91YmxlcyBmcm9tIGEgbWFuYWdlYWJpbGl0eSBzdGFuZHBvaW50LiBNZWFu cyB0byBoZWxwIHRoZSBjbGFzc2lmaWVyIHRvDQo+IGF1dG9tYXRpY2FsbHkgY2xlYW4gaXRzIHRh YmxlIHdpdGhvdXQgYW4gZXhwbGljaXQgYWN0aW9uIGZyb20gYSB0aGlyZA0KPiBwYXJ0eSAoY29u dHJvbGxlcnMpIGFyZSB1c2VmdWwsIElNTy4NCj4gPg0KPiA+PiBCdXQgaXQgY291bGQgYmUgYWRk ZWQgYXQgc29tZSBwb2ludC4NCj4gPj4NCj4gPiBbTWVkXSBTdXJlLiBCR1AgaXMgcG93ZXJmdWwg ZW5vdWdoIDopDQo+ID4NCj4gPj4gPiAqIEkgZG9uJ3Qgc2VlIGhvdyB0aGUgQ1Agc2V0cyB0aGUg U0kgYXQgY2xhc3NpZmllcnMNCj4gPj4NCj4gPj4gU2VjdGlvbiA3LjUNCj4gPj4NCj4gPj4gPiAq IEkgZG9uJ3Qgc2VlIGhvdyB0aGUgQ1Agc2V0IHRoZSBzZW1hbnRpYyBvZiBhIG1ldGFkYXRhIHBl ciBlYWNoDQo+IGNoYWluLA0KPiA+PiBzY29wZSwNCj4gPj4gPiBldGMuDQo+ID4+DQo+ID4+IEl0 IHdvdWxkIGJlIHByZW1hdHVyZSB0byBkZWZpbmUgYSBjb250cm9sIHBsYW5lIGZvciBzb21ldGhp bmcgdGhhdA0KPiBoYXNuJ3QNCj4gPj4gYmVlbg0KPiA+PiBwcm9wZXJseSBzcGVjaWZpZWQgaW4g dGhlIGZvcndhcmRpbmcgcGxhbmUuDQo+ID4NCj4gPiBbTWVkXSBJIHVuZGVyc3RhbmQgeW91ciBh cmd1bWVudCBhYm91dCB0aGUgd2Vha25lc3Mgb2YgdGhlIERQIHBsYW5lIHNwZWMNCj4gaW4gdGhp cyByZWdhcmRzLCBidXQgSSBkbyB0aGluayB0aGF0IGlzIChob3BlZnVsbHkpIGZpeGVkIHdpdGgg dGhlIG5ldw0KPiB0ZXh0IChodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIx KQ0KPiA+DQo+ID4+IEJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IG1vc3QgU0ZzIHdpbGwgbm90IGJl IHNvIHByb2dyYW1tYWJsZTogdGhleSB3aWxsDQo+ID4+IGxvb2sgZm9yDQo+ID4+IHNwZWNpZmlj IFRMVnMgaW4gbWV0YWRhdGEgYW5kIGlnbm9yZSAoZm9yd2FyZCkgdGhlIHJlc3QsIGFuZCB0aGV5 IHdpbGwNCj4gYWRkDQo+ID4+IHNwZWNpZmljIFRMVnMgdG8gdGhlIG1ldGFkYXRhLg0KPiA+DQo+ ID4gW01lZF0gSSBkb24ndCBrbm93IHdoYXQgaXMvd2lsbCBiZSBhIGRlZmF1bHQgYmVoYXZpb3Ig b2YgYW4gU0ZDLXdhcmUgU0YuDQo+IEZvciBleGFtcGxlLCBJIGRvbid0IHNlZSBiYXNlZCBvbiB3 aGljaCBjcml0ZXJpYSBhIENHTiBvciBmaXJld2FsbCBTRiB3aWxsDQo+IGRlY2lkZSB0aGF0IGl0 IG11c3QgbG9vayBmb3IgcGFydGljdWxhciBUTFZzLiBBbHNvLCBJIGRvbid0IHNlZSBiYXNlZCBv bg0KPiB3aGljaCBjcml0ZXJpYSBhIGNsYXNzaWZpZXIgaW1wbGVtZW50YXRpb24gd2lsbCBkZWNp ZGUgdG8gaW5qZWN0IGEgZ2l2ZW4NCj4gc2V0IG9mIFRMVnMsIGV0Yy4gVGhlcmUgaXMgYSB2b2lk IHRoYXQgbmVlZHMgdG8gYmUgZnVsZmlsbGVkIGJ5IHRoZSBDUC4NCj4gPg0KPiA+PiBTZW5kaW5n IENQIG1lc3NhZ2VzIHdpbGwgbm90IGNoYW5nZSB0aGUgYmVoYXZpb3Igb2YgU0ZzIGluIHRoaXMg cmVnYXJkLg0KPiA+IFtNZWRdIFRoZXJlIGlzIGEgbmVlZCB0byBjb21tdW5pY2F0ZSBTRkMgaW5z dHJ1Y3Rpb25zIHRvIHVuZGVybHlpbmcgU0ZDLQ0KPiBhd2FyZSBub2Rlcy4NCj4gPg0KPiA+PiBB dHRlbXB0aW5nIHRvIGRvIHNvIHdvdWxkIGJlIGFkZGluZyB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5 IHRvIHRoZQ0KPiBzeXN0ZW0uDQo+ID4+DQo+ID4+ID4gKiBJIGRvbid0IHNlZSBob3cgdGhlIENQ IGluZGljYXRlcyB0aGUgYmVoYXZpb3IgdG8gZm9sbG93IHdoZW4gYQ0KPiA+PiBtZXRhZGF0YSBp cw0KPiA+PiA+IGNvbnN1bWVkDQo+ID4+DQo+ID4+IERpdHRvIHRoZSBhYm92ZSBvbmx5IG1vcmUg c28hDQo+ID4+IEFuIFNGIGlzIGFuIFNGIGFuZCBpcyBub3QgQ1AtcHJvZ3JhbW1hYmxlLg0KPiA+ DQo+ID4gW01lZF0gV2UgYXJlIG5vdCB0YWxraW5nIGFib3V0IFNGcyBpbiBnZW5lcmFsLCBidXQg YWJvdXQgU0ZDLWF3YXJlIFNGcy4NCj4gT2YgY291cnNlLCBTRi1zcGVjaWZpYyBjb250cm9sIGlz IG5vdCBvZiBpbnRlcmVzdCBoZXJlLg0KPiA+DQo+ID4+DQo+ID4+ID4gKiBJIGRvbid0IHNlZSBo b3cgYW4gU0ZDIHByb3h5IGluIGluc3RydWN0ZWQgdG8gaW5zZXJ0L3N1cHBseQ0KPiBtZXRhZGF0 YQ0KPiA+PiBvbg0KPiA+PiBiZWhhbGYNCj4gPj4gPiBvZiBTRkMtdW5hd2FyZSBTRnMNCj4gPj4N Cj4gPj4gQW4gU0ZDIHByb3h5IGlzLCBpbiB0aGF0IHJlc3BlY3QsIG5vIGRpZmZlcmVudCBmcm9t IHRoZSBtZXRhZGF0YQ0KPiBjb21wb25lbnQNCj4gPj4gb2YgYW4NCj4gPj4gU0YgdGhhdCBjYW4g aGFuZGxlIG1ldGFkYXRhLg0KPiA+DQo+ID4gW01lZF0gLi4uIGV4Y2VwdCB0aGF0IHRoZSBwcm94 eSBkb2VzIG5vdCBrbm93IHdoYXQgVExWcyBhcmUgdG8gYmUNCj4gaW5zZXJ0ZWQvc3RyaXBwZWQv bW9kaWZpZWQgcGVyIGF0dGFjaGVkIFNGIChhbmQgcGVyIGNoYWluKS4NCj4gPg0KPiA+Pg0KPiA+ PiBCdXQgeW91ICpoYXZlKiBwb2ludGVkIHRvIGFuIGludGVyZXN0aW5nICJob2xlIiBpbiB0aGUg YXJjaGl0ZWN0dXJlIGlmDQo+IGl0DQo+ID4+IGlzDQo+ID4+IGFzc3VtZWQgdGhhdCB0aGUgU0ZD IHByb3h5IGNhbiBzb21laG93IGtub3cgYWJvdXQgdGhlIHN0YXRlIGluIHRoZSBTRkMtDQo+ID4+ IHVuYXdhcmUNCj4gPj4gU0YgYW5kIHNoYXBlIG1ldGFkYXRhIGFjY29yZGluZ2x5Lg0KPiA+Pg0K PiA+PiA+ICogSSBkb24ndCBzZWUgdGhlIENQIGJlaGF2aW9yIHdoZW4gYW4gU0YgaXMgdG8gYmUg d2l0aGRyYXduDQo+ID4+DQo+ID4+IEkgZG9uJ3QgZXZlbiBrbm93IHdoYXQgaXQgbWVhbnMgdG8g IndpdGhkcmF3IGFuIFNGIi4NCj4gPg0KPiA+IFtNZWRdICBXaGF0IEkgbWVhbnQgaXMsIGZvciBl eGFtcGxlLCB3aGVuIGFuIFNGIGlzIGRlY29tbWlzc2lvbmVkIG9yDQo+IHdoZW4gbm93IGluc3Rh bmNlIGlzIGF2YWlsYWJsZSB0byBkZWxpdmVyIHRoZSBzZXJ2aWNlLiBEb2VzIHRoZSBzb2x1dGlv bg0KPiBhbGxvd3MgdG8gbWFpbnRhaW4gdGhlIGluc3RhbGxlZCBTRlBzIGJ1dCB3aXRoIGEgYnlw YXNzIG9mIHRoYXQgU0Ygb3IgaXQNCj4gaW1wb3NlcyB0byByZWluc3RhbGwgbmV3IHBhdGhzLg0K PiA+DQo+ID4+IERvIHlvdSBtZWFuICJ0byB0YWtlIGFuIFNGSSBncmFjZWZ1bGx5IG91dCBvZiBz ZXJ2aWNlIj8gSWYgc28sIHlvdQ0KPiB3b3VsZA0KPiA+PiBzaW1wbHkNCj4gPj4gd2l0aGRyYXcg dGhlIFNGSVIgYW5kIHRoZSByb3V0ZSB3b3VsZCBnbyAoYXMgaXMgbm9ybWFsIGluIEJHUCkuDQo+ ID4+IE9yIGRvIHlvdSBtZWFuICJ0byByZW1vdmUgYW4gU0YgZnJvbSBhbiBTRlAiPyBJZiBzbywg NC41LjEuDQo+ID4+DQo+ID4+ID4gKiBJIGRvbid0IHNlZSBob3cgYW4gU0ZDIHByb3h5IGlzIGlu c3RydWN0ZWQgYWJvdXQgdGhlIFNGcyB0bw0KPiBzZXJ2aWNlLg0KPiA+Pg0KPiA+PiBBcmUgeW91 IGFza2luZyBob3cgYSBwcm94eSB0aGF0IHNldmVycyBtb3JlIHRoYW4gb25lIFNGIGtub3dzIHRv IHdoaWNoDQo+IFNGDQo+ID4+IHRvDQo+ID4+IHJvdXRlIHBhY2tldHM/DQo+ID4NCj4gPiBbTWVk XSBUaGlzIGlzIG1vcmUgYWJvdXQgY2hlY2tpbmcgdGhhdCBvbmx5IGVudGl0bGVkIFNGcyBhcmUg YXV0aG9yaXplZA0KPiB0byBiZSBzZXJ2aWNlZCBieSBhIHByb3h5Lg0KPiA+DQo+ID4+IElmIHlv dSBhcmUsIHRoZW4gbXkgYW5zd2VyIGlzICJkb24ndCBkbyB0aGF0ISIgUHJveGllcyBhcmUgY2hl YXAuIFlvdQ0KPiBjYW4NCj4gPj4gdmlydHVhbGlzZSBhIHByb3h5IGF0IGFueSBsb2NhdGlvbi4N Cj4gPj4NCj4gPj4gPiAqIEV0Yy4NCj4gPj4NCj4gPj4gU2VlIHNlY3Rpb24sIG9oLi4uIDotKQ0K PiA+DQo+ID4gW01lZF0gV2lsbCByZWFkIHRoYXQgc2VjdGlvbiBTT09OIDstKQ0KPiA+DQo+ID4+ DQo+ID4+IFRoYW5rcywNCj4gPj4gQWRyaWFuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNmYyBtYWlsaW5nIGxpc3QNCj4gPiBz ZmNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0K From nobody Tue Feb 21 05:28:13 2017 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 6EE8C129BAA for ; Tue, 21 Feb 2017 05:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NIjPXtqqOLI for ; Tue, 21 Feb 2017 05:28:10 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F50129437 for ; Tue, 21 Feb 2017 05:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4823; q=dns/txt; s=iport; t=1487683690; x=1488893290; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iqIhCA3wXKMTiy3Rw6NIb1b+3ezEu+Z8I++JRrh2MEQ=; b=aE+/6ujQkNyBOYtApjweyDfBKFYt9q2h+NtJlTbtEJUd45seEwPBCHXW i/KBw1gfjycSq8h/8106nCnvZSkwTwKw6fSBG5rTtZWcVOW7n7PeTzMXA 4mbh2V3S0uhcw361wzsgNtlLUmAu1d+8QK3Kqm7r8mxh5gtgsjYnK/dzo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AQCBP6xY/5BdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVyRdx+IDId8hSyCDR8BCoV4AoJlPxgBAgEBAQEBAQF?= =?us-ascii?q?iKIRwAQEBBAEBbAsMBAIBCAQNBAEBKAchBgsUCQgCBA4FiVYDFQ6wRIc4DYQTA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGTIIFCIJiglGFN4IxBZVghW46AY4BhBu?= =?us-ascii?q?RDopBiGIBHziBAFMVPhEBg3+CN3WKA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,189,1484006400"; d="scan'208,217";a="386532815" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2017 13:28:08 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1LDS8mM021241 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Feb 2017 13:28:08 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 07:28:08 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 07:28:08 -0600 From: "Paul Quinn (paulq)" To: "Andrew G. Malis" Thread-Topic: [sfc] NSH Common Header flags - C bit Thread-Index: AQHSix5so0irc+t5SkOwMC/udtBv26FyC5OAgABdGwCAAXJWgA== Date: Tue, 21 Feb 2017 13:28:08 +0000 Message-ID: <962B1BEE-A745-4354-B20F-F80237A0C0BD@cisco.com> References: <57a8680c-c466-a6e5-bea1-2729f201626f@joelhalpern.com> <007301d28b5e$a0d29e30$e277da90$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.17.231] Content-Type: multipart/alternative; boundary="_000_962B1BEEA7454354B20FF80237A0C0BDciscocom_" MIME-Version: 1.0 Archived-At: Cc: Adrian Farrel , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] NSH Common Header flags - C bit X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 13:28:11 -0000 --_000_962B1BEEA7454354B20FF80237A0C0BDciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same here. On Feb 20, 2017, at 10:22 AM, Andrew G. Malis > wrote: As do I. Cheers, Andy On Mon, Feb 20, 2017 at 4:49 AM, Adrian Farrel > wrote: Joel, Per Dave's write-up to the list on Jan 18th, I agree with removing this bit= . Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On B= ehalf Of Joel M. Halpern > Sent: 20 February 2017 02:10 > To: sfc@ietf.org > Subject: [sfc] NSH Common Header flags - C bit > > Are there any additional comments on the proposal to remove the C bit? > > Yours, > 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_962B1BEEA7454354B20FF80237A0C0BDciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Same here.


    On Feb 20, 2017, at 10:22 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
    As do I.

    Cheers,
    Andy


    On Mon, Feb 20, 2017 at 4:49 AM, Adrian Farrel <= span dir=3D"ltr" class=3D""> <adr= ian@olddog.co.uk> wrote:
    Joel,

    Per Dave's write-up to the list on Jan 18th, I agree with removing this bit= .

    Adrian

    > -----Original Message-----
    > From: sfc [mailto:s= fc-bounces@ietf.org] On Behalf Of Joel M. Halpern
    > Sent: 20 February 2017 02:10
    > To: sfc@ietf.org
    > Subject: [sfc] NSH Common Header flags - C bit
    >
    > Are there any additional comments on the proposal to remove the C bit?=
    >
    > Yours,
    > 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/lis= tinfo/sfc

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

    --_000_962B1BEEA7454354B20FF80237A0C0BDciscocom_-- From nobody Tue Feb 21 14:00:05 2017 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 2E99D129D22 for ; Tue, 21 Feb 2017 14:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_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=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 E_gdVHKtIUHs for ; Tue, 21 Feb 2017 14:00:02 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 73FB01294FF for ; Tue, 21 Feb 2017 14:00:01 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id v186so124803631wmd.0 for ; Tue, 21 Feb 2017 14:00:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=9QjmRLNtCOVfmHlleWHs0jxOIns+jq2WGToOjs8e8IA=; b=PXUbLiHFoNUejEmEpu+LRZYnsy1YHIwUdo6+piJhgdBtP26Fu6HsYXNUn8thR6YH2T u1zefuURYe2PjOh6q9rorELgXSfie7ma/8b8O9NEheHPG5TRklmebDWTK16M0jImOd2N RqCbs7/Q3xiqYtjgz/rfnVEZlXQ0D1OlNpI2bT83RIsXjZ57CyK8BgimNOhPXTKS7RNM dMdiaW+//RaJSGzji3XfXJNt+YX407QcCZyqscPB0G2xnYvw0WUabZM3+NAmLPLpkC3T 6nB8e5L0Yb0xLxXXRxfT6ReQXX3y7WV1ob2IGJ3cKJCeZ1L20sOZO0oJ5EIXYvsHX+lD EMQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=9QjmRLNtCOVfmHlleWHs0jxOIns+jq2WGToOjs8e8IA=; b=kTDtWb/1lXKixqE/FLU882a9VEfT6SgIr8hAxyy+BBAbHtQqmKKmEGv9L0aDf8RBlP PvqV9QRPQZK739Tg3wwjsIDgv1LxYXqqjwPnn1jPVg7n1GfPjPdt7EnBMUpYKfwWERNA X2JeHQ/tITW8UMazgrygEd/H6q12b3lg/JoxqPHRWfIowKNTptm0YGqkVhD8m5LXAiJr o+AhAHzku5n7KwysLFhZCdGZw+3z7p0tORYZezEWDXw0VddxnMD9bH++FkWvvxAmHZwN tWQmBn1AaKZlT20pyrfu/slJ2YPbz9u4lNwdIGrU7PZdiywNlPpOOn+t+lWE8j/zT0mB Ul5w== X-Gm-Message-State: AMke39nGwNWhpPPI/L4l7omyY/hUsBarOwtaQ5hd9Jq4xOpqvAxq8WqMmhT/JDYfsxITaWPZjtSwD4vJ/5maPg== X-Received: by 10.28.46.73 with SMTP id u70mr26217452wmu.54.1487714399833; Tue, 21 Feb 2017 13:59:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.136.170 with HTTP; Tue, 21 Feb 2017 13:59:59 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E151F9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933009E151F9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Behcet Sarikaya Date: Tue, 21 Feb 2017 15:59:59 -0600 Message-ID: To: Mohamed Boucadair Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "adrian@olddog.co.uk" , "Joel M. Halpern" , "sfc@ietf.org" , Eric C Rosen Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 22:00:04 -0000 On Tue, Feb 21, 2017 at 12:55 AM, wrote: > Hi Behcet, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> Envoy=C3=A9 : lundi 20 f=C3=A9vrier 2017 17:45 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN >> Cc : adrian@olddog.co.uk; Eric C Rosen; Joel M. Halpern; sfc@ietf.org >> Objet : Re: [sfc] How to progress our control plane requirements documen= t >> >> Hi Med, >> >> I am curious, we are putting so much effort, so many cycles on CP >> requirements, while I think the real interest on this should be what >> is this CP protocol itself? > > [Med] I'm not sure there will "one" CP protocol. It is likely there will = be many protocols and protocols extensions to fill the void. For example, > * some deployments may reuse their existing PCC architecture but augmente= d with new tools, > * while others may want to reuse their RADIUS platforms to interact with = the classifier while other SFC nodes are controlled via one or more control= elements, > * some other deployments may have a preference for an extension to BGP > * others may prefer to use PCE > * other may combine BGP and PCE, and so on. > > The whole point of this requirement effort was to make sure that a minimu= m set of CP requirements, drawn from the perspective of the SFC WG but defi= ned in other WG eventually, are fulfilled within an SFC domain. > > I don't see how the IETF can mandate a given deployment to use BGP (for e= xample) while an update of existing control tools may do the job. For examp= le, mandating that every SF instance to be a BGP speaker is too high. > I agree that BGP speaker requirement is too high. Also I don't think SDN approaches like path computation element would suit us here. Why not an in house CP protocol for SFC? Regards, Behcet > People are asking where is the beef? > > [Med] You have to wait for the starter first. I fully agree it is frustra= ting to wait for too long. I hear you, Behcet. > >> >> Currently this is somewhat mysteriously hidden. >> >> I suggest putting our efforts, the real minds on that? >> >> Regards, >> >> Behcet >> >> On Mon, Feb 20, 2017 at 1:26 AM, wrote: >> > Hi Adrian, >> > >> > Please see inline. >> > >> > Cheers, >> > Med >> > >> >> -----Message d'origine----- >> >> De : Adrian Farrel [mailto:adrian@olddog.co.uk] >> >> Envoy=C3=A9 : vendredi 17 f=C3=A9vrier 2017 17:30 >> >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; 'Eric C Rosen'; 'Joel M. Halpern'= ; >> >> sfc@ietf.org >> >> Objet : RE: [sfc] How to progress our control plane requirements >> document >> >> >> >> Hi Med, >> >> >> >> I'm not convinced that this draft should address the CP requirements = in >> >> your >> >> draft. >> > >> > [Med] That's fine by me. It is perfectly fine to address a subset of >> requirements, but what I'm less comfortable with is to call a proposal >> (The) "Control plane for SFC". >> > >> > It seems more important to build a functional system(i.e., one that >> >> works >> >> and delivers the operational function that makes an SFC network work)= . >> >> >> >> Therefore, in reviewing the draft it may be more helpful to say: >> >> - this doesn't work >> >> - I need to achieve this function >> >> - this could be done better. >> >> >> > [Med] I confess this wasn't my perspective when reading the mackie >> draft. >> > >> >> But for completeness, here are some answers to your points: >> >> >> >> > For example, I checked your BGP CP draft to check if it addresses t= he >> CP >> >> > requirement in the SFC CP draft. Many of these CP requirements are >> >> included in >> >> > your proposal but many others are missing, e.g., >> >> > >> >> > * I don't see how classification rules are installed/removed/update= d. >> >> >> >> Section 7.5 >> > [Med] Sorry. Thank you for the pointer. >> > >> >> >> >> > * I don't see any features to associate classification and forwardi= ng >> >> entries >> >> with >> >> > validity lifetime. >> >> >> >> I don't believe this to be a useful feature. >> > >> > [Med] Programming a state that is not limited in time may be a source = of >> troubles from a manageability standpoint. Means to help the classifier t= o >> automatically clean its table without an explicit action from a third >> party (controllers) are useful, IMO. >> > >> >> But it could be added at some point. >> >> >> > [Med] Sure. BGP is powerful enough :) >> > >> >> > * I don't see how the CP sets the SI at classifiers >> >> >> >> Section 7.5 >> >> >> >> > * I don't see how the CP set the semantic of a metadata per each >> chain, >> >> scope, >> >> > etc. >> >> >> >> It would be premature to define a control plane for something that >> hasn't >> >> been >> >> properly specified in the forwarding plane. >> > >> > [Med] I understand your argument about the weakness of the DP plane sp= ec >> in this regards, but I do think that is (hopefully) fixed with the new >> text (https://trac.ietf.org/trac/sfc/ticket/21) >> > >> >> But it seems to me that most SFs will not be so programmable: they wi= ll >> >> look for >> >> specific TLVs in metadata and ignore (forward) the rest, and they wil= l >> add >> >> specific TLVs to the metadata. >> > >> > [Med] I don't know what is/will be a default behavior of an SFC-ware S= F. >> For example, I don't see based on which criteria a CGN or firewall SF wi= ll >> decide that it must look for particular TLVs. Also, I don't see based on >> which criteria a classifier implementation will decide to inject a given >> set of TLVs, etc. There is a void that needs to be fulfilled by the CP. >> > >> >> Sending CP messages will not change the behavior of SFs in this regar= d. >> > [Med] There is a need to communicate SFC instructions to underlying SF= C- >> aware nodes. >> > >> >> Attempting to do so would be adding unnecessary complexity to the >> system. >> >> >> >> > * I don't see how the CP indicates the behavior to follow when a >> >> metadata is >> >> > consumed >> >> >> >> Ditto the above only more so! >> >> An SF is an SF and is not CP-programmable. >> > >> > [Med] We are not talking about SFs in general, but about SFC-aware SFs= . >> Of course, SF-specific control is not of interest here. >> > >> >> >> >> > * I don't see how an SFC proxy in instructed to insert/supply >> metadata >> >> on >> >> behalf >> >> > of SFC-unaware SFs >> >> >> >> An SFC proxy is, in that respect, no different from the metadata >> component >> >> of an >> >> SF that can handle metadata. >> > >> > [Med] ... except that the proxy does not know what TLVs are to be >> inserted/stripped/modified per attached SF (and per chain). >> > >> >> >> >> But you *have* pointed to an interesting "hole" in the architecture i= f >> it >> >> is >> >> assumed that the SFC proxy can somehow know about the state in the SF= C- >> >> unaware >> >> SF and shape metadata accordingly. >> >> >> >> > * I don't see the CP behavior when an SF is to be withdrawn >> >> >> >> I don't even know what it means to "withdraw an SF". >> > >> > [Med] What I meant is, for example, when an SF is decommissioned or >> when now instance is available to deliver the service. Does the solution >> allows to maintain the installed SFPs but with a bypass of that SF or it >> imposes to reinstall new paths. >> > >> >> Do you mean "to take an SFI gracefully out of service"? If so, you >> would >> >> simply >> >> withdraw the SFIR and the route would go (as is normal in BGP). >> >> Or do you mean "to remove an SF from an SFP"? If so, 4.5.1. >> >> >> >> > * I don't see how an SFC proxy is instructed about the SFs to >> service. >> >> >> >> Are you asking how a proxy that severs more than one SF knows to whic= h >> SF >> >> to >> >> route packets? >> > >> > [Med] This is more about checking that only entitled SFs are authorize= d >> to be serviced by a proxy. >> > >> >> If you are, then my answer is "don't do that!" Proxies are cheap. You >> can >> >> virtualise a proxy at any location. >> >> >> >> > * Etc. >> >> >> >> See section, oh... :-) >> > >> > [Med] Will read that section SOON ;-) >> > >> >> >> >> Thanks, >> >> Adrian >> > >> > _______________________________________________ >> > sfc mailing list >> > sfc@ietf.org >> > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Feb 22 12:01:37 2017 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 31C78129AB9 for ; Wed, 22 Feb 2017 12:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ltHmp5FQK-of for ; Wed, 22 Feb 2017 12:01:33 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232E4129AB3 for ; Wed, 22 Feb 2017 12:01:31 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1MK1SNP006942; Wed, 22 Feb 2017 20:01:28 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1MK1LWF006900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2017 20:01:25 GMT From: "Adrian Farrel" To: , "'Mohamed Boucadair'" References: <787AE7BB302AE849A7480A190F8B933009E151F9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Wed, 22 Feb 2017 20:01:21 -0000 Message-ID: <056d01d28d46$7547c2b0$5fd74810$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbvRbjQowIm4UMKTH7zMncQbw1kwIONy9AAYwTcWehRj8yYA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22902.002 X-TM-AS-Result: No--2.899-10.0-31-10 X-imss-scan-details: No--2.899-10.0-31-10 X-TMASE-MatchedRID: pBwXUM+nCws4HKI/yaqRmzXKFtsDtZ7TUAjrAJWsTe+dCqKtxM6bhzcE nRTOt5/IoErxlrDKufy5PDICs81Vme26dmaIobujxZQoGMRGhhPJL9dxWhPfYbKeTtOdjMy6fY6 +xD9jHhLnzlXMYw4XMCAtDqHg/4Qm0C1sQRfQzEHEQdG7H66TyJ8TMnmE+d0ZZvrOZfaKbrqNWJ q/Cgo7GW1NSwT14NQpMCfOx1TmI+qYgAFDEN8YbLOFrLf5DNGVRvot8zLfi6Tf8jXoAsdX808I/ GrtA43vxCoeW0dT2BaH/JCvitQD6SHK6aCMTbp1ojykM9thkxFWXGvUUmKP2w== Archived-At: Cc: "'Joel M. Halpern'" , sfc@ietf.org, 'Eric C Rosen' Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:01:36 -0000 >> I don't see how the IETF can mandate a given deployment to use BGP = (for >> example) while an update of existing control tools may do the job. = For example, >> mandating that every SF instance to be a BGP speaker is too high. >> >=20 > I agree that BGP speaker requirement is too high. Just in case there should be any doubt, = draft-mackie-bess-nsh-bgp-control-plane does NOT require or even suggest = that SFs be BGP speakers. OTOH, it recognises that the SFC network is an overlay of tunnels = between SFFs, and that a routing protocol is appropriate for that type = of network. Of course, if folk want to operate SFC networks using a north-south = management plane model, that is their business, and it shouldn't be too = hard to achieve except in complex and large networks. Adrian From nobody Wed Feb 22 15:58:52 2017 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 03A71126DFB; Wed, 22 Feb 2017 15:58:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148780793100.31132.13136465964290378153.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 15:58:51 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 23:58:51 -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 of the IETF. Title : Service Function Chaining Use Cases In Data Centers Authors : Surendra Kumar Mudassir Tufail Sumandra Majee Claudiu Captari Shunsuke Homma Filename : draft-ietf-sfc-dc-use-cases-06.txt Pages : 23 Date : 2017-02-22 Abstract: Data center operators deploy a variety of layer 4 through layer 7 service functions in both physical and virtual form factors. Most traffic originating, transiting, or terminating in the data center is subject to treatment by multiple service functions. This document describes use cases that demonstrate the applicability of Service Function Chaining (SFC) within a data center environment and provides SFC requirements for data center centric use cases, with primary focus on Enterprise data centers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-dc-use-cases-06 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 Feb 22 16:01:22 2017 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 81F8D1293F5 for ; Wed, 22 Feb 2017 16:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUdpitdQCQoN for ; Wed, 22 Feb 2017 16:01:19 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8DD126DFB for ; Wed, 22 Feb 2017 16:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2155; q=dns/txt; s=iport; t=1487808074; x=1489017674; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZlEr9iahmneWPl3AfDnnvvxLwQO5HWLRX7WNt1OlMXk=; b=UqC1Zxbi+O4sd70OiJTZO+oTGM05t7pr0Ng/9ghELnANjGIhh+/T0txa ce7O0w0MlGkrL2bkXb5QO6f+N+Hjtp8EYBwNdE0eca/L5bu80+zO5PNjU As3tDoAVccedT2AYTPcPHW707jQcFr3vWZLll2R8muGwB1y6Rb88E1Ofc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQCaJa5Y/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHjVyRWpU0gg0fC4V4AoMNPxgBAgEBAQEBAQFiHQuEcAE?= =?us-ascii?q?BAQQBATg0FwQCAQgRBAEBHwkHJwsUCQgCBBMIiW0OsVSLTAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2LO4MXhyIFnBABhnOLJoIEU4RJiXmINYpvAR84gQBUFRgmhkl?= =?us-ascii?q?1iQeBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,196,1484006400"; d="scan'208";a="389213067" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 00:01:13 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1N01DMP022415 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 23 Feb 2017 00:01:13 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Feb 2017 18:01:12 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Wed, 22 Feb 2017 18:01:12 -0600 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-06.txt Thread-Index: AQHSjWekVdx5uCL0gEuETQY+eN0IXaF1tPbA Date: Thu, 23 Feb 2017 00:01:12 +0000 Message-ID: <1196c14b161f422c80dbce873ff04865@XCH-RCD-020.cisco.com> References: <148780793100.31132.13136465964290378153.idtracker@ietfa.amsl.com> In-Reply-To: <148780793100.31132.13136465964290378153.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.124.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:01:20 -0000 No changes, just a revision update. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Wednesday, February 22, 2017 3:59 PM To: i-d-announce@ietf.org Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Service Function Chaining of the IETF. Title : Service Function Chaining Use Cases In Data Cente= rs Authors : Surendra Kumar Mudassir Tufail Sumandra Majee Claudiu Captari Shunsuke Homma Filename : draft-ietf-sfc-dc-use-cases-06.txt Pages : 23 Date : 2017-02-22 Abstract: Data center operators deploy a variety of layer 4 through layer 7 service functions in both physical and virtual form factors. Most traffic originating, transiting, or terminating in the data center is subject to treatment by multiple service functions. This document describes use cases that demonstrate the applicability of Service Function Chaining (SFC) within a data center environment and provides SFC requirements for data center centric use cases, with primary focus on Enterprise data centers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-dc-use-cases-06 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Feb 22 18:18:37 2017 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 EEB57129515 for ; Wed, 22 Feb 2017 18:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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=f5.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 g8iv64mEZ8n6 for ; Wed, 22 Feb 2017 18:18:34 -0800 (PST) Received: from mail15.f5.com (mail15.f5.com [104.219.107.14]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9423C1294E1 for ; Wed, 22 Feb 2017 18:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=f5; t=1487816315; x=1519352315; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=HcgTdKa7Vua7Fw4CbvTBo56jHomQq4DqhIScUM4R0Bc=; b=v361g/Wtt1fXk/DGsWe1QF9hBjX+fKBe4lWxBYblZoMF+QXWe1sUmWZs sqkzyefpCTLPXEWyG7YJ+maFz6q3Ttnq47aEGphwGQIXNRJ+IT0bhX5zO oSXvA4qICVfnTVPv1S17ngB1Bzlo+auWnGmxZfUlxUNKCFbUPjlxpBULN xnpYdiyphkkqKK4UhurKEv/AVCAgrHVwrKV5yFAL1r27wSKMaTiKrh9ov /pvV5QiSUpqNGGexA3ov1RtpozO1AuYTvSqVcTJSMfKdEFDf5s3bm4txb fKlhJkhJQKQccEwT+OcEZL40Hs1AsTAg7thRcJumm31SQgIidvQVXUe8y Q==; X-IronPort-AV: E=McAfee;i="5800,7501,8447"; a="1319380" X-IronPort-AV: E=Sophos;i="5.35,197,1484035200"; d="scan'208,217";a="1319380" Received: from sv5ccpems04.olympus.f5net.com (HELO owa.f5.com) ([172.23.209.15]) by mail.f5net.com with ESMTP/TLS/AES256-SHA256; 22 Feb 2017 18:18:34 -0800 Received: from SV5CCPEMS01.olympus.F5Net.com (172.23.209.12) by SV5CCPEMS04.olympus.F5Net.com (172.23.209.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 22 Feb 2017 18:18:33 -0800 Received: from SV5CCPEMS01.olympus.F5Net.com ([fe80::8cea:a209:8eb7:c2ab]) by SV5CCPEMS01.olympus.F5Net.com ([fe80::8cea:a209:8eb7:c2ab%19]) with mapi id 15.01.0669.032; Wed, 22 Feb 2017 18:18:33 -0800 From: Sumandra Majee To: Eric C Rosen , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHSbciskIOG8xZK3Uy0CKJpHOUgCqFTl1AAgCKCTQE= Date: Thu, 23 Feb 2017 02:18:33 +0000 Message-ID: References: , <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> In-Reply-To: <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.251.194] Content-Type: multipart/alternative; boundary="_000_ee8b85a857e94e7d93d192e3a1654352F5com_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 02:18:36 -0000 --_000_ee8b85a857e94e7d93d192e3a1654352F5com_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >>When I first looked at the document, I thought it was going to provide a set of APIs allowing one to build an SF without knowing what the control plane would be. That might be useful (if it is even possible), but the document does not seem to provide any such thing. [SM] The API and associated information element should be part of *a* docum= ent. I don't think one can capture all the possibilities in oe single docum= ent anyway. ________________________________ From: sfc on behalf of Eric C Rosen Sent: Tuesday, January 31, 2017 11:15:30 AM To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] How to progress our control plane requirements document I believe the control plane requirements document should be abandoned by the WG. The document attempts to describe the information needed by the various components (e.g., SF, SFF, classifier) of the architecture. However, RFC 7665 and draft-ietf-sfc-nsh already describe the information needed by the components, and the control plane requirements document does not add anything of substance. The requirements document attempts to organize the information into four "interface reference points", but as other have pointed out already, this method of organization just is not particularly useful, and is not helpful when designing a control plane architecture. These reference points do not correspond to anything real. If the document advances, someone will ask questions like "is this protocol element part of the implementation of interface C2 or is it part of the implementation of interface C3?", and the answer will often be "well, you could think of it as part of C2, or you could think of it as part of C3, or maybe as part of both, depending on your deployment scenario, but really it doesn't matter". In this way, the document creates extra work without adding extra value. When I first looked at the document, I thought it was going to provide a set of APIs allowing one to build an SF without knowing what the control plane would be. That might be useful (if it is even possible), but the document does not seem to provide any such thing. There is important information that is absent from the prior documents, such as the information needed to support the interaction of the service layer components with the underlying transport, but that information is also absent from the requirements document. I don't think this sort of requirements document is helpful when attempting to design a control plane solution, it just gets in the way. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_ee8b85a857e94e7d93d192e3a1654352F5com_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    >>When I first loo= ked at the document, I thought it was going to provide a
    set of APIs allowing one to build an SF without knowing what the control plane would be.  That might be useful (if it is even possible), but th= e
    document does not seem to provide any such thing.


    [SM] The API and associa= ted information element should be part of *a* document. I don't think one c= an capture all the possibilities in oe single document anyway.

    From: sfc <sfc-bounces= @ietf.org> on behalf of Eric C Rosen <erosen@juniper.net>
    Sent: Tuesday, January 31, 2017 11:15:30 AM
    To: Joel M. Halpern; sfc@ietf.org
    Subject: Re: [sfc] How to progress our control plane requirements do= cument
     
    I believe the control plane requirements document = should be abandoned by
    the WG.

    The document attempts to describe the information needed by the various components (e.g., SF, SFF, classifier) of the architecture. However, RFC 7665 and draft-ietf-sfc-nsh already describe the information needed by
    the components, and the control plane requirements document does not add anything of substance.

    The requirements document attempts to organize the information into four "interface reference points", but as other have pointed out alrea= dy,
    this method of organization just is not particularly useful, and is not helpful when designing a control plane architecture.  These reference =
    points do not correspond to anything real.   If the document adva= nces,
    someone will ask questions like "is this protocol element  part o= f the
    implementation of interface C2 or is it part of the implementation of
    interface C3?", and the answer will often be "well, you could thi= nk of
    it as part of C2, or you could think of it as part of C3, or maybe as
    part of both, depending on your deployment scenario, but really it
    doesn't matter".  In this way, the document creates extra work wi= thout
    adding extra value.

    When I first looked at the document, I thought it was going to provide a set of APIs allowing one to build an SF without knowing what the control plane would be.  That might be useful (if it is even possible), but th= e
    document does not seem to provide any such thing.

    There is important information that is absent from the prior documents, such as the information needed to support the interaction of the service layer components with the underlying transport, but that information is also absent from the requirements document.

    I don't think this sort of requirements document is helpful when
    attempting to design a control plane solution, it just gets in the way.




    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    https://www.ietf.org/= mailman/listinfo/sfc
     --_000_ee8b85a857e94e7d93d192e3a1654352F5com_-- From nobody Thu Feb 23 05:11:53 2017 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 E58FA1297C3; Thu, 23 Feb 2017 05:11:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148785550693.20311.333438821034772492.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 05:11:46 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-12.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 13:11:47 -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 of the IETF. Title : Network Service Header Authors : Paul Quinn Uri Elzur Filename : draft-ietf-sfc-nsh-12.txt Pages : 37 Date : 2017-02-23 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-12 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 Thu Feb 23 05:13:20 2017 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 5329E12A1C9 for ; Thu, 23 Feb 2017 05:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImEMzVwVkq_y for ; Thu, 23 Feb 2017 05:13:16 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7F712A1BC for ; Thu, 23 Feb 2017 05:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30046; q=dns/txt; s=iport; t=1487855595; x=1489065195; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o3hb+gJGSCry8vup8JQyNkY+kBb7t/D4hdO8QxiFB4A=; b=kix3+w2F9ysuDxEEjQT8ObjOpYKB2KRJpDr90NAoSs5ktbbjifjcTn9X BiuVssH9Omgzqt6HegHjM4tfcrp1SFOB45j2DBdKfwiFNJefa/689bGe+ bcT+T+rV5i2lU3BndNZJ74NaTwKsGWROULbxTLZHyxx7Fj/OzABkU5vrL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAQBs365Y/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5iYYEJB4NUigiRW5U0gg0uhXQCGoJ/PxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBCNIDAIQAgEIEQECAQEBIQcDAgICMBQDBggCBAENBYl1Dq5kgiaLQgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2GTIIFgmqDF4EPEQEMJwkWCIJILoIxBYl6hVO?= =?us-ascii?q?GHIYrAYZzgyKIDoF7U4RJiXqIN4pwAQ8QOHgIVBUYNwGEOR2BYXUBBIkTgSGBD?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,197,1484006400"; d="scan'208,217";a="201722697" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2017 13:13:14 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1NDDEXW028399 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 13:13:14 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 07:13:13 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 07:13:13 -0600 From: "Paul Quinn (paulq)" To: James N Guichard , Joel Halpern Thread-Topic: New Version Notification for draft-ietf-sfc-nsh-11.txt Thread-Index: AQHShlBkUCIc1jOOIUqdPqawp9G6OaFrzs4wgAB41SCACr1/AA== Date: Thu, 23 Feb 2017 13:13:13 +0000 Message-ID: References: <148702829421.22233.782542928593751229.idtracker@ietfa.amsl.com> <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> <787AE7BB302AE849A7480A190F8B933009E138E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.17.231] Content-Type: multipart/alternative; boundary="_000_C9C6F8DDA15143B6A7AAA5FEED8CC4E4ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 13:13:18 -0000 --_000_C9C6F8DDA15143B6A7AAA5FEED8CC4E4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgbmV3IHZlcnNpb24gaGFzIGJlZW4gcG9zdGVkIHRvIHJlZmxlY3QgdGhpcyB0ZXh0Lg0KDQpQ YXVsDQoNCg0KT24gRmViIDE2LCAyMDE3LCBhdCA2OjE0IFBNLCBKYW1lcyBOIEd1aWNoYXJkIDxq YW1lcy5uLmd1aWNoYXJkQGh1YXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2Vp LmNvbT4+IHdyb3RlOg0KDQpGb3IgcmVmZXJlbmNlIHRoZSBhZ3JlZWQgdXBvbiB0ZXh0IHRvIGJl IGFkZGVkIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiAzLjUuMSBpcyBhcyBmb2xsb3dzIOKAkyBOU0gg ZWRpdG9ycyBwbGVhc2UgbWFrZSB0aGUgY2hhbmdlOg0KDQpUaGlzIHNwZWNpZmljYXRpb24gZG9l cyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlDQptYW5kYXRvcnkt dG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiBUaGVz ZQ0KY29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuIEhvd2V2ZXIsIHRoZSBj b250cm9sIHBsYW5lDQppcyBlbnRpdGxlZCB0byBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGgg dGhlIGRhdGEgc3RydWN0dXJlIG9mDQpUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAo U2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy0NCmNvbnRyb2wtcGxhbmVdKS4NCg0K VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBh IG1hbmRhdG9yeS0NCnRvLXByb2Nlc3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRo ZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QNCnByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cg YXQgbGVhc3Qgb25jZSBwZXIgdGhlIFNQSSBmb3Igd2hpY2gNCmEgbWFuZGF0b3J5IG1ldGFkYXRh IGlzIG1pc3NpbmcuDQoNCklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJl IHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwNCnRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVj dCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvDQpjb25zdW1lIHRoZXNlIFRMVnMu IElmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUNClNGIE1VU1Qg cHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGVpciBhcHBlYXIgaW4gdGhlIE5TSA0K cGFja2V0Lg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNs dWRlZCBpbiBhbiBOU0ggcGFja2V0LA0KYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRv ZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZQ0KU0YgTVVTVCBOT1QgcHJvY2VzcyB0 aGUgcGFja2V0IGFuZCBNVVNUIGxvZyBhdCBsZWFzdCBvbmNlIHBlciB0aGUgU1BJDQpmb3Igd2hp Y2ggbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoYXQgVExWIGlzIHN1cHBsaWVkLg0KDQoNCg0KRnJv bTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Pg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3IDExOjA0IEFNDQpUbzogUGF1bCBR dWlubiAocGF1bHEpIDxwYXVscUBjaXNjby5jb20+OyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbc2ZjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0x MS50eHQNCg0KSGkgUGF1bCwNCg0KVGhhbmsgeW91IGZvciB0aGUgdXBkYXRlLg0KDQpJ4oCZbSBh ZnJhaWQgdGhlIGFncmVlZCB0ZXh0ICh0aGUgb25lIHRvIGJlIGFkZGVkIHRvIFNlY3Rpb24gMy41 LjEpIGFzIHJlY29yZGVkIGluaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8y MSB3YXMgbm90IGludGVncmF0ZWQgaW4gdGhpcyByZXZpc2lvbi4gQ2FuIHlvdSBwbGVhc2UgZml4 IHRoYXQ/DQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSBEZSBsYSBwYXJ0IGRlIFBhdWwgUXVpbm4gKHBhdWxxKQ0KRW52b3nDqSA6IG1hcmRp IDE0IGbDqXZyaWVyIDIwMTcgMDA6MzANCsOAIDogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQpPYmpldCA6IFtzZmNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1pZXRmLXNmYy1uc2gtMTEudHh0DQoNCkZvbGtzLA0KDQpUaGlzIHZlcnNpb24gaW50ZWdy YXRlczoNCg0KLSBNdWNoIG9mIHRoZSBlbWFpbCB0aHJlYWQgd2l0aCBBbGlhIHJlOiBoZXIgQUQg cmV2aWV3IG9mIHRoZSBkcmFmdC4gIFRoZXJlIHN0aWxsIG1pZ2h0IGJlIGEgZmV3IG1pbm9yIGl0 ZW1zIHRoYXQgbmVlZCB0byBiZSB1cGRhdGVkIChlLmcuIHNvbWUgb2YgdGhlIElFVEYgdnMuIGV4 cGVydCByZXZpZXcgZm9yIHJlZ2lzdHJpZXMpDQotIFRoZSBjaGFuZ2VzIHN1bW1hcml6ZWQgYnkg dGhlIGNoYWlycyAoaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zZmMvMDNn MldFQWVJRF9YSVFnc0ZPWnhELWRpcVFVLz9xaWQ9NGVkYTkxY2ExZDdhY2QxMzViMTI5NDcyMDFi NjU0N2EpDQotIFNvbWUgbWlub3IgZWRpdG9yaWFsIGNoYW5nZXMNCg0KUGF1bA0KDQoNCkJlZ2lu IGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMTEudHh0DQpEYXRlOiBGZWJydWFyeSAx MywgMjAxNyBhdCA2OjI0OjU0IFBNIEVTVA0KVG86IFVyaSBFbHp1ciA8dXJpLmVsenVyQGludGVs LmNvbTxtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbT4+LCBQYXVsIFF1aW5uIDxwYXVscUBjaXNj by5jb208bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWlldGYtc2ZjLW5zaC0xMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgUGF1bCBRdWlubiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpO YW1lOiBkcmFmdC1pZXRmLXNmYy1uc2gNClJldmlzaW9uOiAxMQ0KVGl0bGU6IE5ldHdvcmsgU2Vy dmljZSBIZWFkZXINCkRvY3VtZW50IGRhdGU6IDIwMTctMDItMTINCkdyb3VwOiBzZmMNClBhZ2Vz OiAzNw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXNmYy1uc2gtMTEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtbnNoLw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMTENCkRpZmY6 ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1z ZmMtbnNoLTExDQoNCkFic3RyYWN0Og0KICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIE5ldHdv cmsgU2VydmljZSBIZWFkZXIgKE5TSCkgaW5zZXJ0ZWQgb250bw0KICBwYWNrZXRzIG9yIGZyYW1l cyB0byByZWFsaXplIHNlcnZpY2UgZnVuY3Rpb24gcGF0aHMuICBOU0ggYWxzbw0KICBwcm92aWRl cyBhIG1lY2hhbmlzbSBmb3IgbWV0YWRhdGEgZXhjaGFuZ2UgYWxvbmcgdGhlIGluc3RhbnRpYXRl ZA0KICBzZXJ2aWNlIHBhdGguICBOU0ggaXMgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIHJlcXVpcmVk IHRvIHN1cHBvcnQgdGhlDQogIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0 ZWN0dXJlIChkZWZpbmVkIGluIFJGQzc2NjUpLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZy8+Lg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQo= --_000_C9C6F8DDA15143B6A7AAA5FEED8CC4E4ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQXMgbmV3IHZlcnNpb24gaGFzIGJl ZW4gcG9zdGVkIHRvIHJlZmxlY3QgdGhpcyB0ZXh0Lg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UGF1bDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+T24gRmViIDE2LCAyMDE3LCBhdCA2OjE0IFBNLCBKYW1lcyBOIEd1aWNoYXJkICZsdDs8 YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBodWF3ZWkuY29tIiBjbGFzcz0iIj5qYW1l cy5uLmd1aWNoYXJkQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0i QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5Gb3IgcmVmZXJlbmNlIHRoZSBhZ3JlZWQgdXBv biB0ZXh0IHRvIGJlIGFkZGVkIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiAzLjUuMSBpcyBhcyBmb2xs b3dzIOKAkyBOU0ggZWRpdG9ycyBwbGVhc2UgbWFrZSB0aGUgY2hhbmdlOjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFu eSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmU8YnIgY2xhc3M9IiI+DQptYW5kYXRvcnkt dG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiBUaGVz ZTxiciBjbGFzcz0iIj4NCmNvbnNpZGVyYXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiBI b3dldmVyLCB0aGUgY29udHJvbCBwbGFuZTxiciBjbGFzcz0iIj4NCmlzIGVudGl0bGVkIHRvIGlu c3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2Y8YnIgY2xhc3M9 IiI+DQpUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMg b2YgW0ktRC5pZXRmLXNmYy08YnIgY2xhc3M9IiI+DQpjb250cm9sLXBsYW5lXSkuPG86cCBjbGFz cz0iIj48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0 OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KVXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRv IGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS08YnIgY2xhc3M9IiI+DQp0by1wcm9jZXNzIFRM ViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UPGJy IGNsYXNzPSIiPg0KcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyBhdCBsZWFzdCBvbmNl IHBlciB0aGUgU1BJIGZvciB3aGljaDxiciBjbGFzcz0iIj4NCmEgbWFuZGF0b3J5IG1ldGFkYXRh IGlzIG1pc3NpbmcuPG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSWYgbXVsdGlwbGUgbWFuZGF0 b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLDxiciBjbGFz cz0iIj4NCnRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdp dGggdGhlIG9yZGVyIHRvPGJyIGNsYXNzPSIiPg0KY29uc3VtZSB0aGVzZSBUTFZzLiBJZiBubyBp bnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlPGJyIGNsYXNzPSIiPg0KU0Yg TVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRoZWlyIGFwcGVhciBpbiB0aGUg TlNIPGJyIGNsYXNzPSIiPg0KcGFja2V0LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCklmIG11 bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBw YWNrZXQsPGJyIGNsYXNzPSIiPg0KYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMg bm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZTxiciBjbGFzcz0iIj4NClNGIE1VU1QgTk9U IHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgYXQgbGVhc3Qgb25jZSBwZXIgdGhlIFNQ STxiciBjbGFzcz0iIj4NCmZvciB3aGljaCBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhhdCBUTFYg aXMgc3VwcGxpZWQuPG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGEgbmFtZT0i X01haWxFbmRDb21wb3NlIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7 IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjUsIDIyNSwgMjI1KTsgYm9yZGVyLXRvcC13aWR0aDog MXB0OyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0i Ij5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i IGNsYXNzPSIiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyAxMTowNCBBTTxiciBjbGFz cz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+UGF1bCBRdWlubiAocGF1bHEpICZsdDtwYXVscUBjaXNjby5jb20m Z3Q7OyBzZmNAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtzZmNd IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTExLnR4dDxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291 cmllciBOZXcnOyIgY2xhc3M9IiI+SGkgUGF1bCw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsi IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+VGhh bmsgeW91IGZvciB0aGUgdXBkYXRlLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9 IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj5J4oCZbSBhZnJh aWQgdGhlIGFncmVlZCB0ZXh0ICh0aGUgb25lIHRvIGJlIGFkZGVkIHRvIFNlY3Rpb24gMy41LjEp IGFzIHJlY29yZGVkIGluPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3Rp Y2tldC8yMSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyIgY2xhc3M9IiI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2FzDQogbm90 IGludGVncmF0ZWQgaW4gdGhpcyByZXZpc2lvbi4gQ2FuIHlvdSBwbGVhc2UgZml4IHRoYXQ/PG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0Nv dXJpZXIgTmV3JzsiIGNsYXNzPSIiPkNoZWVycyw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsi IGNsYXNzPSIiPk1lZDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5 bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVy LWxlZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwaW4gMGluIDBpbiA0cHQ7IiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9u ZTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRo OiAxcHQ7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnNmYyBb PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YiBjbGFzcz0iIj5EZQ0KIGxhIHBhcnQgZGU8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBhdWwgUXVpbm4gKHBhdWxxKTxiciBjbGFz cz0iIj4NCjxiIGNsYXNzPSIiPkVudm95w6kmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYXJkaSAxNCBmw6l2cmllciAyMDE3IDAwOjMw PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+w4AmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+T2JqZXQm bmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5bc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zZmMt bnNoLTExLnR4dDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBsYW5nPSJGUiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gbGFuZz0iRlIiIGNsYXNzPSIiPkZvbGtzLDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gbGFuZz0iRlIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkZSIiBjbGFzcz0iIj5U aGlzIHZlcnNpb24gaW50ZWdyYXRlczo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJGUiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRlIi IGNsYXNzPSIiPi0gTXVjaCBvZiB0aGUgZW1haWwgdGhyZWFkIHdpdGggQWxpYSByZTogaGVyIEFE IHJldmlldyBvZiB0aGUgZHJhZnQuICZuYnNwO1RoZXJlIHN0aWxsIG1pZ2h0IGJlIGEgZmV3IG1p bm9yIGl0ZW1zIHRoYXQgbmVlZCB0byBiZSB1cGRhdGVkIChlLmcuIHNvbWUgb2YgdGhlIElFVEYg dnMuIGV4cGVydCByZXZpZXcgZm9yIHJlZ2lzdHJpZXMpPG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRlIiIGNsYXNzPSIiPi0gVGhl IGNoYW5nZXMgc3VtbWFyaXplZCBieSB0aGUgY2hhaXJzICg8YSBocmVmPSJodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NmYy8wM2cyV0VBZUlEX1hJUWdzRk9aeEQtZGlxUVUv P3FpZD00ZWRhOTFjYTFkN2FjZDEzNWIxMjk0NzIwMWI2NTQ3YSIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zZmMvMDNnMldFQWVJRF9YSVFnc0ZPWnhELWRpcVFVLz9x aWQ9NGVkYTkxY2ExZDdhY2QxMzViMTI5NDcyMDFiNjU0N2E8L2E+KTxvOnAgY2xhc3M9IiI+PC9v OnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkZSIiBjbGFzcz0i Ij4tIFNvbWUgbWlub3IgZWRpdG9yaWFsIGNoYW5nZXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJGUiIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRlIiIGNsYXNzPSIiPlBhdWw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJGUiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkZSIiBjbGFz cz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IGxhbmc9IkZSIiBjbGFzcz0iIj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkZSIiBjbGFzcz0iIj48bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsiIGNsYXNzPSIi PkZyb206PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTogJ0hlbHZldGljYSBO ZXVlJzsiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5n PSJGUiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTog J0hlbHZldGljYSBOZXVlJzsiIGNsYXNzPSIiPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTExLnR4dDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RlIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdI ZWx2ZXRpY2EgTmV1ZSc7IiBjbGFzcz0iIj5EYXRlOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Zm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IiBjbGFzcz0iIj5GZWJydWFyeSAxMywgMjAx NyBhdCA2OjI0OjU0IFBNIEVTVDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsiIGNs YXNzPSIiPlRvOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdIZWx2ZXRp Y2EgTmV1ZSc7IiBjbGFzcz0iIj5VcmkgRWx6dXIgJmx0OzxhIGhyZWY9Im1haWx0bzp1cmkuZWx6 dXJAaW50ZWwuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IiBjbGFzcz0iIj51cmkuZWx6dXJAaW50ZWwuY29tPC9hPiZndDssDQogUGF1bCBRdWlu biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhdWxxQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+cGF1bHFAY2lzY28uY29t PC9hPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRlIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDEycHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNw YW4gbGFuZz0iRlIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLXNmYy1uc2gtMTEudHh0PGJyIGNsYXNzPSIiPg0KaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXVsIFF1aW5uIGFuZCBwb3N0ZWQgdG8gdGhlPGJyIGNsYXNz PSIiPg0KSUVURiByZXBvc2l0b3J5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hbWU6 PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPmRyYWZ0LWlldGYtc2ZjLW5zaDxiciBjbGFzcz0i Ij4NClJldmlzaW9uOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj4xMTxiciBjbGFzcz0iIj4N ClRpdGxlOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5OZXR3b3JrIFNlcnZpY2UgSGVhZGVy PGJyIGNsYXNzPSIiPg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ MjAxNy0wMi0xMjxiciBjbGFzcz0iIj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj5zZmM8YnIgY2xhc3M9IiI+DQpQYWdlczo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+Mzc8 YnIgY2xhc3M9IiI+DQpVUkw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNmYy1uc2gtMTEudHh0IiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zZmMtbnNoLTExLnR4dDwvYT48 YnIgY2xhc3M9IiI+DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtc2ZjLW5zaC8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtc2ZjLW5zaC88L2E+PGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMTEiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXNmYy1uc2gtMTE8L2E+PGJyIGNsYXNzPSIiPg0KRGlmZjogJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2ZjLW5zaC0x MSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2ZjLW5z aC0xMTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIE5ldHdvcmsgU2Vydmlj ZSBIZWFkZXIgKE5TSCkgaW5zZXJ0ZWQgb250bzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3Bh Y2tldHMgb3IgZnJhbWVzIHRvIHJlYWxpemUgc2VydmljZSBmdW5jdGlvbiBwYXRocy4gJm5ic3A7 TlNIIGFsc288YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtwcm92aWRlcyBhIG1lY2hhbmlzbSBm b3IgbWV0YWRhdGEgZXhjaGFuZ2UgYWxvbmcgdGhlIGluc3RhbnRpYXRlZDxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwO3NlcnZpY2UgcGF0aC4gJm5ic3A7TlNIIGlzIHRoZSBTRkMgZW5jYXBzdWxh dGlvbiByZXF1aXJlZCB0byBzdXBwb3J0IHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1Nl cnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlIChkZWZpbmVkIGluIFJG Qzc2NjUpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnIgY2xhc3M9IiI+ DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiIGNsYXNzPSIiPnRvb2xzLmlldGYub3JnPC9hPi48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_C9C6F8DDA15143B6A7AAA5FEED8CC4E4ciscocom_-- From nobody Thu Feb 23 05:25:25 2017 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 E55061297CD for ; Thu, 23 Feb 2017 05:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 fSYz3RG5m1xI for ; Thu, 23 Feb 2017 05:25:22 -0800 (PST) Received: from relais-inet.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 9C7A4129717 for ; Thu, 23 Feb 2017 05:25:21 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id EEAFC16084B; Thu, 23 Feb 2017 14:25:19 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id C01EA80073; Thu, 23 Feb 2017 14:25:19 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0319.002; Thu, 23 Feb 2017 14:25:19 +0100 From: To: "Paul Quinn (paulq)" , James N Guichard , Joel Halpern Thread-Topic: New Version Notification for draft-ietf-sfc-nsh-11.txt Thread-Index: AQHShlBkUCIc1jOOIUqdPqawp9G6OaFrzs4wgAB41SCACr1/AP//nTOg Date: Thu, 23 Feb 2017 13:25:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E179E6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <148702829421.22233.782542928593751229.idtracker@ietfa.amsl.com> <969E0350-87F9-41A6-82E6-BC01608A41FA@cisco.com> <787AE7BB302AE849A7480A190F8B933009E138E4@OPEXCLILMA3.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.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E179E6OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 13:25:24 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E179E6OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KVGhhbmsgeW91Lg0KDQpCVFcsIEkgbm90aWNlZCByaWdodCBub3cgdGhhdCB0 aGUgZG9jdW1lbnQgZGlkbuKAmXQgaW1wbGVtZW50ZWQgd2VsbCB0aGUgb3V0Y29tZSBvZiB0aGlz IHRpY2tldDogaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMi4gSW4gcGFy dGljdWxhciwgdGhlIGZvbGxvd2luZyB0ZXh0IG11c3QgYmUgZml4ZWQgYWNjb3JkaW5nbHkuDQoN Cj09PQ0KICAgV2hlbiB0aGUgQmFzZSBIZWFkZXIgc3BlY2lmaWVzIE1EIFR5cGUgPSAweDEsIGZv dXIgQ29udGV4dCBIZWFkZXJzLA0KICAgNC1ieXRlIGVhY2gsIE1VU1QgYmUgYWRkZWQgaW1tZWRp YXRlbHkgZm9sbG93aW5nIHRoZSBTZXJ2aWNlIFBhdGgNCiAgIEhlYWRlciwgYXMgcGVyIEZpZ3Vy ZSA0LiAgQ29udGV4dCBIZWFkZXJzIHRoYXQgY2Fycnkgbm8gbWV0YWRhdGEgTVVTVA0KICAgYmUg c2V0IHRvIHplcm8uDQo9PT0NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgUGF1bCBRdWlubiAocGF1bHEpDQpFbnZv ecOpIDogamV1ZGkgMjMgZsOpdnJpZXIgMjAxNyAxNDoxMw0Kw4AgOiBKYW1lcyBOIEd1aWNoYXJk OyBKb2VsIEhhbHBlcm4NCkNjIDogc2ZjQGlldGYub3JnDQpPYmpldCA6IFJlOiBbc2ZjXSBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0xMS50eHQNCg0KQXMg bmV3IHZlcnNpb24gaGFzIGJlZW4gcG9zdGVkIHRvIHJlZmxlY3QgdGhpcyB0ZXh0Lg0KDQpQYXVs DQoNCg0KT24gRmViIDE2LCAyMDE3LCBhdCA2OjE0IFBNLCBKYW1lcyBOIEd1aWNoYXJkIDxqYW1l cy5uLmd1aWNoYXJkQGh1YXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNv bT4+IHdyb3RlOg0KDQpGb3IgcmVmZXJlbmNlIHRoZSBhZ3JlZWQgdXBvbiB0ZXh0IHRvIGJlIGFk ZGVkIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiAzLjUuMSBpcyBhcyBmb2xsb3dzIOKAkyBOU0ggZWRp dG9ycyBwbGVhc2UgbWFrZSB0aGUgY2hhbmdlOg0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90 IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZQ0KbWFuZGF0b3J5LXRvLWlt cGxlbWVudCBvciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gVGhlc2UNCmNv bnNpZGVyYXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiBIb3dldmVyLCB0aGUgY29udHJv bCBwbGFuZQ0KaXMgZW50aXRsZWQgdG8gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBk YXRhIHN0cnVjdHVyZSBvZg0KVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBT ZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtDQpjb250cm9sLXBsYW5lXSkuDQpVcG9uIHJl Y2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0 b3J5LQ0KdG8tcHJvY2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1h d2FyZSBTRiBNVVNUIE5PVA0KcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyBhdCBsZWFz dCBvbmNlIHBlciB0aGUgU1BJIGZvciB3aGljaA0KYSBtYW5kYXRvcnkgbWV0YWRhdGEgaXMgbWlz c2luZy4NCklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVk IGZvciBhIGdpdmVuIFNGUCwNCnRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZD LWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvDQpjb25zdW1lIHRoZXNlIFRMVnMuIElmIG5vIGlu c3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUNClNGIE1VU1QgcHJvY2VzcyB0 aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGVpciBhcHBlYXIgaW4gdGhlIE5TSA0KcGFja2V0Lg0K SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4g TlNIIHBhY2tldCwNCmJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxv dyBmb3IgaXQsIHRoZSBTRkMtYXdhcmUNClNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBh bmQgTVVTVCBsb2cgYXQgbGVhc3Qgb25jZSBwZXIgdGhlIFNQSQ0KZm9yIHdoaWNoIG11bHRpcGxl IGluc3RhbmNlcyBvZiB0aGF0IFRMViBpcyBzdXBwbGllZC4NCg0KDQpGcm9tOiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMTYsIDIwMTcgMTE6MDQgQU0NClRvOiBQYXVsIFF1aW5uIChwYXVscSkg PHBhdWxxQGNpc2NvLmNvbTxtYWlsdG86cGF1bHFAY2lzY28uY29tPj47IHNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTExLnR4dA0KDQpIaSBQYXVsLA0KDQpUaGFu ayB5b3UgZm9yIHRoZSB1cGRhdGUuDQoNCknigJltIGFmcmFpZCB0aGUgYWdyZWVkIHRleHQgKHRo ZSBvbmUgdG8gYmUgYWRkZWQgdG8gU2VjdGlvbiAzLjUuMSkgYXMgcmVjb3JkZWQgaW5odHRwczov L3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxIHdhcyBub3QgaW50ZWdyYXRlZCBpbiB0 aGlzIHJldmlzaW9uLiBDYW4geW91IHBsZWFzZSBmaXggdGhhdD8NCg0KQ2hlZXJzLA0KTWVkDQoN CkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgUGF1 bCBRdWlubiAocGF1bHEpDQpFbnZvecOpIDogbWFyZGkgMTQgZsOpdnJpZXIgMjAxNyAwMDozMA0K w4AgOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCk9iamV0IDogW3NmY10gRndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0xMS50eHQN Cg0KRm9sa3MsDQoNClRoaXMgdmVyc2lvbiBpbnRlZ3JhdGVzOg0KDQotIE11Y2ggb2YgdGhlIGVt YWlsIHRocmVhZCB3aXRoIEFsaWEgcmU6IGhlciBBRCByZXZpZXcgb2YgdGhlIGRyYWZ0LiAgVGhl cmUgc3RpbGwgbWlnaHQgYmUgYSBmZXcgbWlub3IgaXRlbXMgdGhhdCBuZWVkIHRvIGJlIHVwZGF0 ZWQgKGUuZy4gc29tZSBvZiB0aGUgSUVURiB2cy4gZXhwZXJ0IHJldmlldyBmb3IgcmVnaXN0cmll cykNCi0gVGhlIGNoYW5nZXMgc3VtbWFyaXplZCBieSB0aGUgY2hhaXJzIChodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NmYy8wM2cyV0VBZUlEX1hJUWdzRk9aeEQtZGlxUVUv P3FpZD00ZWRhOTFjYTFkN2FjZDEzNWIxMjk0NzIwMWI2NTQ3YSkNCi0gU29tZSBtaW5vciBlZGl0 b3JpYWwgY2hhbmdlcw0KDQpQYXVsDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZy b206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYt c2ZjLW5zaC0xMS50eHQNCkRhdGU6IEZlYnJ1YXJ5IDEzLCAyMDE3IGF0IDY6MjQ6NTQgUE0gRVNU DQpUbzogVXJpIEVsenVyIDx1cmkuZWx6dXJAaW50ZWwuY29tPG1haWx0bzp1cmkuZWx6dXJAaW50 ZWwuY29tPj4sIFBhdWwgUXVpbm4gPHBhdWxxQGNpc2NvLmNvbTxtYWlsdG86cGF1bHFAY2lzY28u Y29tPj4NCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1zZmMtbnNoLTExLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXVsIFF1aW5uIGFuZCBwb3N0 ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LWlldGYtc2ZjLW5zaA0K UmV2aXNpb246IDExDQpUaXRsZTogTmV0d29yayBTZXJ2aWNlIEhlYWRlcg0KRG9jdW1lbnQgZGF0 ZTogMjAxNy0wMi0xMg0KR3JvdXA6IHNmYw0KUGFnZXM6IDM3DQpVUkw6ICAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2ZjLW5zaC0xMS50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXNmYy1uc2gvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtc2ZjLW5zaC0xMQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNmYy1uc2gtMTENCg0KQWJzdHJhY3Q6DQog IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgTmV0d29yayBTZXJ2aWNlIEhlYWRlciAoTlNIKSBp bnNlcnRlZCBvbnRvDQogIHBhY2tldHMgb3IgZnJhbWVzIHRvIHJlYWxpemUgc2VydmljZSBmdW5j dGlvbiBwYXRocy4gIE5TSCBhbHNvDQogIHByb3ZpZGVzIGEgbWVjaGFuaXNtIGZvciBtZXRhZGF0 YSBleGNoYW5nZSBhbG9uZyB0aGUgaW5zdGFudGlhdGVkDQogIHNlcnZpY2UgcGF0aC4gIE5TSCBp cyB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUNCiAgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1cmUgKGRlZmluZWQgaW4gUkZDNzY2 NSkuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xz LmlldGYub3JnLz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== --_000_787AE7BB302AE849A7480A190F8B933009E179E6OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOp IEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRl LCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNv LXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4N Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2Fy DQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNw YW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBD YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1h dMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQg NzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIFBhdWwsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+QlRXLCBJIG5vdGljZWQgcmlnaHQgbm93IHRoYXQgdGhl IGRvY3VtZW50IGRpZG7igJl0IGltcGxlbWVudGVkIHdlbGwgdGhlIG91dGNvbWUgb2YgdGhpcyB0 aWNrZXQ6DQo8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIy Ij5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIyPC9hPi4gSW4gcGFydGlj dWxhciwgdGhlIGZvbGxvd2luZyB0ZXh0IG11c3QgYmUgZml4ZWQgYWNjb3JkaW5nbHkuICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj49PT08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBXaGVuIHRoZSBCYXNlIEhlYWRlciBzcGVjaWZpZXMgTUQg VHlwZSA9IDB4MSwgZm91ciBDb250ZXh0IEhlYWRlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg NC1ieXRlIGVhY2gsIE1VU1QgYmUgYWRkZWQgaW1tZWRpYXRlbHkgZm9sbG93aW5nIHRoZSBTZXJ2 aWNlIFBhdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBIZWFkZXIsIGFzIHBlciBGaWd1cmUgNC4m bmJzcDsgQ29udGV4dCBIZWFkZXJzIHRoYXQgY2Fycnkgbm8gbWV0YWRhdGEgTVVTVDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmJlIHNldCB0byB6ZXJvLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij49PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10N CjxiPkRlIGxhIHBhcnQgZGU8L2I+IFBhdWwgUXVpbm4gKHBhdWxxKTxicj4NCjxiPkVudm95w6km bmJzcDs6PC9iPiBqZXVkaSAyMyBmw6l2cmllciAyMDE3IDE0OjEzPGJyPg0KPGI+w4AmbmJzcDs6 PC9iPiBKYW1lcyBOIEd1aWNoYXJkOyBKb2VsIEhhbHBlcm48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+ IHNmY0BpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtzZmNdIE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTExLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIG5ldyB2ZXJzaW9uIGhhcyBi ZWVuIHBvc3RlZCB0byByZWZsZWN0IHRoaXMgdGV4dC4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMTYsIDIwMTcsIGF0IDY6 MTQgUE0sIEphbWVzIE4gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy5uLmd1aWNo YXJkQGh1YXdlaS5jb20iPmphbWVzLm4uZ3VpY2hhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciByZWZlcmVuY2UgdGhlIGFncmVl ZCB1cG9uIHRleHQgdG8gYmUgYWRkZWQgYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDMuNS4xIGlzIGFz IGZvbGxvd3Mg4oCTIE5TSCBlZGl0b3JzIHBsZWFzZSBtYWtlIHRoZSBjaGFuZ2U6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgc3BlY2lm aWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmU8 YnI+DQptYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10 by1wcm9jZXNzLiBUaGVzZTxicj4NCmNvbnNpZGVyYXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNp ZmljLiBIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZTxicj4NCmlzIGVudGl0bGVkIHRvIGluc3Ry dWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2Y8YnI+DQpUTFZzIHRv Z2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRm LXNmYy08YnI+DQpjb250cm9sLXBsYW5lXSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZyB0byBhIGdpdmVu IFNGUCwgaWYgYSBtYW5kYXRvcnktPGJyPg0KdG8tcHJvY2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0 aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVDxicj4NCnByb2Nlc3MgdGhlIHBh Y2tldCBhbmQgTVVTVCBsb2cgYXQgbGVhc3Qgb25jZSBwZXIgdGhlIFNQSSBmb3Igd2hpY2g8YnI+ DQphIG1hbmRhdG9yeSBtZXRhZGF0YSBpcyBtaXNzaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFy ZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsPGJyPg0KdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGlu c3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG88YnI+DQpjb25zdW1lIHRo ZXNlIFRMVnMuIElmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmU8 YnI+DQpTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhlaXIgYXBwZWFy IGluIHRoZSBOU0g8YnI+DQpwYWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPklmIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVk IGluIGFuIE5TSCBwYWNrZXQsPGJyPg0KYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRv ZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZTxicj4NClNGIE1VU1QgTk9UIHByb2Nl c3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgYXQgbGVhc3Qgb25jZSBwZXIgdGhlIFNQSTxicj4N CmZvciB3aGljaCBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhhdCBUTFYgaXMgc3VwcGxpZWQuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29t cG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c2ZjDQogWzxhIGhyZWY9Im1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9m PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj48YSBo cmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3IDEx OjA0IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5QYXVsIFF1aW5uIChwYXVscSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVs cUBjaXNjby5jb20iPnBhdWxxQGNpc2NvLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3NmY10gTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMTEudHh0PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpIFBhdWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5UaGFuayB5b3UgZm9yIHRoZSB1cGRhdGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5J4oCZbSBhZnJhaWQgdGhlIGFncmVlZCB0ZXh0ICh0aGUgb25lIHRvIGJlIGFkZGVkIHRv IFNlY3Rpb24gMy41LjEpIGFzIHJlY29yZGVkIGluPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYu b3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndhcw0KIG5vdCBpbnRlZ3JhdGVk IGluIHRoaXMgcmV2aXNpb24uIENhbiB5b3UgcGxlYXNlIGZpeCB0aGF0Pzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NZWQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ c2ZjDQogWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPkRlIGxhIHBh cnQgZGU8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlBhdWwgUXVpbm4gKHBhdWxxKTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYXJkaSAxNCBmw6l2cmllciAy MDE3IDAwOjMwPGJyPg0KPGI+w4AmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5zZmNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPk9i amV0Jm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+W3NmY10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYt c2ZjLW5zaC0xMS50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb2xrcyw8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlz IHZlcnNpb24gaW50ZWdyYXRlczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBNdWNoIG9m IHRoZSBlbWFpbCB0aHJlYWQgd2l0aCBBbGlhIHJlOiBoZXIgQUQgcmV2aWV3IG9mIHRoZSBkcmFm dC4gJm5ic3A7VGhlcmUgc3RpbGwgbWlnaHQgYmUgYSBmZXcgbWlub3IgaXRlbXMgdGhhdCBuZWVk IHRvIGJlIHVwZGF0ZWQgKGUuZy4gc29tZSBvZiB0aGUgSUVURiB2cy4gZXhwZXJ0IHJldmlldyBm b3IgcmVnaXN0cmllcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVGhlIGNoYW5nZXMgc3VtbWFyaXplZCBieSB0aGUg Y2hhaXJzICg8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Nm Yy8wM2cyV0VBZUlEX1hJUWdzRk9aeEQtZGlxUVUvP3FpZD00ZWRhOTFjYTFkN2FjZDEzNWIxMjk0 NzIwMWI2NTQ3YSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9zZmMvMDNnMldFQWVJRF9YSVFnc0ZPWnhELWRpcVFVLz9xaWQ9 NGVkYTkxY2ExZDdhY2QxMzViMTI5NDcyMDFiNjU0N2E8L3NwYW4+PC9hPik8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g U29tZSBtaW5vciBlZGl0b3JpYWwgY2hhbmdlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q YXVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlZ2luIGZvcndh cmRlZCBtZXNzYWdlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkZyb206PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwv YT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0xMS50eHQ8L3NwYW4+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+RmVicnVh cnkgMTMsIDIwMTcgYXQgNjoyNDo1NCBQTSBFU1Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1 ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VXJpIEVsenVyICZsdDs8YSBocmVmPSJtYWlsdG86 dXJpLmVsenVyQGludGVsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dXJpLmVsenVy QGludGVsLmNvbTwvc3Bhbj48L2E+Jmd0OywNCiBQYXVsIFF1aW5uICZsdDs8YSBocmVmPSJtYWls dG86cGF1bHFAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5wYXVscUBjaXNj by5jb208L3NwYW4+PC9hPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtc2ZjLW5z aC0xMS50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhdWwgUXVp bm4gYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFt ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZHJhZnQt aWV0Zi1zZmMtbnNoPGJyPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjExPGJyPg0KVGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk5ldHdvcmsgU2VydmljZSBIZWFkZXI8YnI+DQpEb2N1 bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4yMDE3LTAyLTEyPGJyPg0KR3JvdXA6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPnNmYzxicj4NClBhZ2VzOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4zNzxicj4NClVSTDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2ZjLW5zaC0xMS50 eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNmYy1uc2gtMTEudHh0PC9zcGFuPjwvYT48YnI+DQpTdGF0 dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC8i PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC88L3NwYW4+PC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtbnNoLTExIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtbnNoLTExPC9zcGFu PjwvYT48YnI+DQpEaWZmOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1zZmMtbnNoLTExIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zZmMtbnNoLTExPC9z cGFuPjwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsmbmJzcDtUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhIE5ldHdvcmsgU2VydmljZSBIZWFkZXIgKE5TSCkgaW5zZXJ0ZWQgb250 bzxicj4NCiZuYnNwOyZuYnNwO3BhY2tldHMgb3IgZnJhbWVzIHRvIHJlYWxpemUgc2VydmljZSBm dW5jdGlvbiBwYXRocy4gJm5ic3A7TlNIIGFsc288YnI+DQombmJzcDsmbmJzcDtwcm92aWRlcyBh IG1lY2hhbmlzbSBmb3IgbWV0YWRhdGEgZXhjaGFuZ2UgYWxvbmcgdGhlIGluc3RhbnRpYXRlZDxi cj4NCiZuYnNwOyZuYnNwO3NlcnZpY2UgcGF0aC4gJm5ic3A7TlNIIGlzIHRoZSBTRkMgZW5jYXBz dWxhdGlvbiByZXF1aXJlZCB0byBzdXBwb3J0IHRoZTxicj4NCiZuYnNwOyZuYnNwO1NlcnZpY2Ug RnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlIChkZWZpbmVkIGluIFJGQzc2NjUp Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy8iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRvb2xzLmlldGYu b3JnPC9zcGFuPjwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_787AE7BB302AE849A7480A190F8B933009E179E6OPEXCLILMA3corp_-- From nobody Sun Feb 26 09:31:25 2017 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 2BBEB1295DF for ; Sun, 26 Feb 2017 09:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 Wcdl3akr0-N0 for ; Sun, 26 Feb 2017 09:31:21 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8820D1279EB for ; Sun, 26 Feb 2017 09:31:21 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1QHVJ2c032600; Sun, 26 Feb 2017 17:31:19 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1QHVDHl032531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2017 17:31:18 GMT From: "Adrian Farrel" To: , References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E13FA3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0bb201d2893c$a8766460$f9632d20$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E14ACB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E14ACB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Sun, 26 Feb 2017 17:31:08 -0000 Message-ID: <00bd01d29056$2372a9b0$6a57fd10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKs4QfPsAfGu+IdxTavj2M4SM8+/wHdpbuiASPIQDcBAfo91Z+mwFNA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22910.001 X-TM-AS-Result: No--8.940-10.0-31-10 X-imss-scan-details: No--8.940-10.0-31-10 X-TMASE-MatchedRID: O/y65JfDwwsn2WEbWzq9rSArD+K6XhnHQa2sDHLkQ06HwGEm+CpYGUJm fftVAWC9HRMPIwK2jF/XmhOmx9V2wnKgzS9kU8wEsyw+ZJnFumRWjiXAsVR2K0S/boWSGMtdUlx AXDKPA0zF0wMQNKBsD7xJvbAU9iUFaOHd6Wm/K5TmAId+2bAQwn0tCKdnhB58vqq8s2MNhPB9j2 GwzTE3vSq2rl3dzGQ16+SeJe1QBHxHSmUB+O8ak8zal0eKyqWbl4PbZq6AKH0mye5B6yF8TQ== Archived-At: Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 17:31:23 -0000 Hi, > > In fact, I find that in addition to my previous points I see another > > problem > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > > OAM procedures, SHALL discard packets with O-bit set. > > > > SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable > > parameter to enable forwarding received SFC OAM packets unmodified to > > the next element in the chain. > > > > You cannot both have "MUST do X" and "MAY be configured to do Y" > > [Med] The initial SHALL is the default behavior. Adding "by default" wouldn't be > sufficient? Then you mean "SHOULD" in the first paragraph and "MAY" in the second. I would rewrite as... SF/SFF/SFC Proxy/Classifer implementations that do not support SFC OAM procedures SHOULD discard packets with O-bit set, but MAY support a configurable parameter to enable forwarding received SFC OAM packets unmodified to the next element in the chain. > > Furthermore > > For non OAM packets, the O-bit MUST be cleared and MUST NOT be > > modified along the SFP. > > which is not (I hope) to imply that the O bit can be modified on an OAM > > packet. > > [Med] That's not the intent. So... The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM packets. The O-bit MUST NOT be modified along the SFP. Thanks, Adrian From nobody Sun Feb 26 11:47:16 2017 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 48E44127601 for ; Sun, 26 Feb 2017 11:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HSWmMz493v-k for ; Sun, 26 Feb 2017 11:47:13 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 8EDDF127735 for ; Sun, 26 Feb 2017 11:47:13 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id 2so30422088oif.0 for ; Sun, 26 Feb 2017 11:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u6Nc9c3kIeka7QMYSdlhP01cNl+Zhq1GwzfG0pksN8E=; b=Wpy4NzXEu8Ee/9sdIGVL1V0ckRqCNgF0AuuUQpeCcxVhfHoxOk0Cj/jt4QR6nr8CVH zTuA4VNrBjE/+lVU/9qjmfjphYD/c1+5cZ10Jn4vjd2XHlLn/HNoXQF7lZ9VVd994z5v c5kM8+w47zH7d/e6cKP07pkvPkVikJlYRlRBaAskr5A396EsfZH+eRBqWVtnE6Kp/8q0 EssraENenFABc0seQUUweMP/i5m+oVy2t2A30F1KKnBd6bJ9H/RGbuXFcGlsKpbq1Aqk 6V6iu0CAuHilXVBRGMtY5yqzAB1i/q0+Iy4tPHGE79SxZnOa3MdQ5KDAACbjR4wzRy4f acGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u6Nc9c3kIeka7QMYSdlhP01cNl+Zhq1GwzfG0pksN8E=; b=NzJOEwo5XXrdf6fEcflsKQuhUlrcz4ayL5vhIgBHwxA+GetCBJXcpnNwBFvDbtkRcN WZvhwb+jgsB1+ZDr8Mi9W+qjhyXRFWgNAWVaMLDz5y4cKHY8zRBC5foPXQe/J0JjWOMs tClrpgzuaYkkxBdQZnOGXDQEhfJo0oYnBKv63NcEdfWRUNOFm1DKHTdd8cnSNK4UhUKX p3do8gibuPjbWgDkNcibmrTSGgnPh44TEAJrHImFBbhSN2ccVQfjMu5TbLHd29Et1iKI MYaLgnhsg8X85o8SvNci0Wl64jhyfsZ+1RoLlDy8mVEPwSsD1mLxR/Y4RPbQoLTYjnN7 wqxA== X-Gm-Message-State: AMke39nV9UEsLYBfhBMO0cd44cxqYkkCRLxfQoAgbMkk7pG5YTYN7NlXYyUZiFY68L8SlLLCMmrOiF2vhaZXOw== X-Received: by 10.202.53.9 with SMTP id c9mr6016929oia.75.1488138432873; Sun, 26 Feb 2017 11:47:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Sun, 26 Feb 2017 11:47:12 -0800 (PST) In-Reply-To: <00bd01d29056$2372a9b0$6a57fd10$@olddog.co.uk> References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E13FA3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0bb201d2893c$a8766460$f9632d20$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E14ACB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00bd01d29056$2372a9b0$6a57fd10$@olddog.co.uk> From: Greg Mirsky Date: Sun, 26 Feb 2017 11:47:12 -0800 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113d4806ab12290549743a26 Archived-At: Cc: mohamed.boucadair@orange.com, sfc@ietf.org Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 19:47:15 -0000 --001a113d4806ab12290549743a26 Content-Type: text/plain; charset=UTF-8 Hi Adrian, I think that there's one more definition related to O-bit and OAM we ought to chisel - what OAM packet is. It could be: - specifically constructed message for the purpose of OAM encapsulated in NSH and proper underlay. But that may leave open question whether hybrid OAM, which embeds OAM message into user data packets, supported and if it is, then how we identify it with O-bit. Appreciate your comments. Regards, Greg On Sun, Feb 26, 2017 at 9:31 AM, Adrian Farrel wrote: > Hi, > > > > In fact, I find that in addition to my previous points I see another > > > problem > > > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > > > OAM procedures, SHALL discard packets with O-bit set. > > > > > > SF/SFF/SFC Proxy/Classifer implementations MAY support a > configurable > > > parameter to enable forwarding received SFC OAM packets unmodified > to > > > the next element in the chain. > > > > > > You cannot both have "MUST do X" and "MAY be configured to do Y" > > > > [Med] The initial SHALL is the default behavior. Adding "by default" > wouldn't > be > > sufficient? > > Then you mean "SHOULD" in the first paragraph and "MAY" in the second. I > would > rewrite as... > SF/SFF/SFC Proxy/Classifer implementations that do not support SFC > OAM procedures SHOULD discard packets with O-bit set, but MAY > support a configurable parameter to enable forwarding received SFC > OAM packets unmodified to the next element in the chain. > > > > Furthermore > > > For non OAM packets, the O-bit MUST be cleared and MUST NOT be > > > modified along the SFP. > > > which is not (I hope) to imply that the O bit can be modified on an OAM > > > packet. > > > > [Med] That's not the intent. > > So... > The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM > packets. The O-bit MUST NOT be modified along the SFP. > > Thanks, > Adrian > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a113d4806ab12290549743a26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Adrian,
    I think that there's one more definitio= n related to O-bit and OAM we ought to chisel - what OAM packet is. It coul= d be:
    • specifically constructed message for the purpose of= OAM encapsulated in NSH and proper underlay.
    But that may leave o= pen question whether hybrid OAM, which embeds OAM message into user data pa= ckets, supported and if it is, then how we identify it with O-bit.
    Appreciate your comments.

    Regards,
    Gre= g

    On S= un, Feb 26, 2017 at 9:31 AM, Adrian Farrel <adrian@olddog.co.uk><= /span> wrote:
    Hi,

    > > In fact, I find that in addition to my previous points I see anot= her
    > > problem
    > >
    > >=C2=A0 =C2=A0 SF/SFF/SFC Proxy/Classifer implementations, which do= not support SFC
    > >=C2=A0 =C2=A0 OAM procedures, SHALL discard packets with O-bit set= .
    > >
    > >=C2=A0 =C2=A0 SF/SFF/SFC Proxy/Classifer implementations MAY suppo= rt a configurable
    > >=C2=A0 =C2=A0 parameter to enable forwarding received SFC OAM pack= ets unmodified to
    > >=C2=A0 =C2=A0 the next element in the chain.
    > >
    > > You cannot both have "MUST do X" and "MAY be confi= gured to do Y"
    >
    > [Med] The initial SHALL is the default behavior. Adding "by defau= lt" wouldn't
    be
    > sufficient?

    Then you mean "SHOULD" in the first paragraph and "MA= Y" in the second. I would
    rewrite as...
    =C2=A0 =C2=A0 SF/SFF/SFC Proxy/Classifer implementations that do not suppor= t SFC
    =C2=A0 =C2=A0 OAM procedures SHOULD discard packets with O-bit set, but MAY=
    =C2=A0 =C2=A0 support a configurable parameter to enable f= orwarding received SFC
    =C2=A0 =C2=A0 OAM packets unmodified to the next element in the chain.

    > > Furthermore
    > >=C2=A0 =C2=A0 For non OAM packets, the O-bit MUST be cleared and M= UST NOT be
    > >=C2=A0 =C2=A0 modified along the SFP.
    > > which is not (I hope) to imply that the O bit can be modified on = an OAM
    > > packet.
    >
    > [Med] That's not the intent.

    So...
    The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM
    packets. The O-bit MUST NOT be modified along the SFP.

    Thanks,
    Adrian

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

    --001a113d4806ab12290549743a26-- From nobody Sun Feb 26 22:40:06 2017 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 6CCA7129872 for ; Sun, 26 Feb 2017 22:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 okUhg6-ChpLd for ; Sun, 26 Feb 2017 22:40:03 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346EF129665 for ; Sun, 26 Feb 2017 22:40:03 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 99D8112019D; Mon, 27 Feb 2017 07:40:01 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 75F8C180066; Mon, 27 Feb 2017 07:40:01 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Mon, 27 Feb 2017 07:40:01 +0100 From: To: "adrian@olddog.co.uk" , "sfc@ietf.org" Thread-Topic: [sfc] O-bit behavior in NSH spec Thread-Index: AQKs4QfPsAfGu+IdxTavj2M4SM8+/wHdpbuiASPIQDcBAfo91Z+mwFNAgADmCfA= Date: Mon, 27 Feb 2017 06:40:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E18E87@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <078701d287ce$8a7b12e0$9f7138a0$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E13FA3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0bb201d2893c$a8766460$f9632d20$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009E14ACB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00bd01d29056$2372a9b0$6a57fd10$@olddog.co.uk> In-Reply-To: <00bd01d29056$2372a9b0$6a57fd10$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] O-bit behavior in NSH spec X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 06:40:04 -0000 Hi Adrian, > -----Message d'origine----- > De=A0: Adrian Farrel [mailto:adrian@olddog.co.uk] > Envoy=E9=A0: dimanche 26 f=E9vrier 2017 18:31 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Objet=A0: RE: [sfc] O-bit behavior in NSH spec >=20 > Hi, >=20 > > > In fact, I find that in addition to my previous points I see another > > > problem > > > > > > SF/SFF/SFC Proxy/Classifer implementations, which do not support > SFC > > > OAM procedures, SHALL discard packets with O-bit set. > > > > > > SF/SFF/SFC Proxy/Classifer implementations MAY support a > configurable > > > parameter to enable forwarding received SFC OAM packets unmodified > to > > > the next element in the chain. > > > > > > You cannot both have "MUST do X" and "MAY be configured to do Y" > > > > [Med] The initial SHALL is the default behavior. Adding "by default" > wouldn't > be > > sufficient? >=20 > Then you mean "SHOULD" in the first paragraph and "MAY" in the second. I > would > rewrite as... > SF/SFF/SFC Proxy/Classifer implementations that do not support SFC > OAM procedures SHOULD discard packets with O-bit set, but MAY > support a configurable parameter to enable forwarding received SFC > OAM packets unmodified to the next element in the chain. >=20 [Med] OK, then.=20 > > > Furthermore > > > For non OAM packets, the O-bit MUST be cleared and MUST NOT be > > > modified along the SFP. > > > which is not (I hope) to imply that the O bit can be modified on an > OAM > > > packet. > > > > [Med] That's not the intent. >=20 > So... > The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM > packets. The O-bit MUST NOT be modified along the SFP. >=20 [Med] Works for me.=20 > Thanks, > Adrian From nobody Mon Feb 27 14:00:11 2017 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 C0B88129409 for ; Mon, 27 Feb 2017 14:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 y8YQk2RIkT6n for ; Mon, 27 Feb 2017 14:00:05 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4F11293FE for ; Mon, 27 Feb 2017 14:00:04 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1RM02SE012746 for ; Mon, 27 Feb 2017 22:00:02 GMT Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1RLxwZP012648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2017 22:00:00 GMT From: "Adrian Farrel" To: Date: Mon, 27 Feb 2017 21:59:57 -0000 Message-ID: <027d01d29144$d743bcb0$85cb3610$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKRRHVLY7SkxborSRGHk+YoYh/yhA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22912.002 X-TM-AS-Result: No--22.384-10.0-31-10 X-imss-scan-details: No--22.384-10.0-31-10 X-TMASE-MatchedRID: X2xtN6WCEVOnykMun0J1wru9iqQJLR0v6Jj6zYvfFARgXOZrgU8dCF7w 52/cAr49P2Ek2po70V94ACv80RlEIvGU4m5A0eV9CDuvg040bNwZKp0SZ4P+dWDhWgmpbUmI04a NlSoZaMT7vDJGNPXIZG0JR9FhypxDWAPmaH6lUzVwUSK4/EeOxfgv6yQpgxkbS8QrgUwl2ip9qT NwMiKD+hnpAeQ+vHvlUVS1qS06KEaxuuum/MWy7xHRbGr1ECgHKaRmDCmXszcZeuIwz+p8e2Wt4 KlMT7aqV8bpmwnmaygyhzimQryyp84svDGUw7k93FqOVb7PDEIpWss5kPUFdBqFyGjP7y/CaSvy k63+g0H1veE5A8clLGgvVQWtPx2sULNUje/+PyBsG7r4Qh7N3AuK1hIitSIHauHKE5Laxl8eLmt uLpfaHU3VUFd/jvAb3UxNmAgxsZ5+Z/6qMX/XhI1nuRzhSr7jj/xLIaDSshGSNcbecZTzoZ/oEJ aoKAtL4fPOckRaVXPmvoJuBam7ynidXeNxTCqU9fdTUM4Rka/TBg/CbgV2T1pbYq2f4jz+8myX5 RK7cEVdyNy8gKRdJs5jUmZjANe+QmQQV9edg/3Da1qWPNOExoVdLK46KrcfzAdJD7JeNMNyOp6P i9UEgUHVAXi+ml5+zoFxOq+IDXOsT6Dr98/byVRe8joruKtp0HjeANoeuJ1FNyTs3OcE/wOkuVk kJKW79GNSFeTz0RHGouyZ7yAlmdphB3BcQx/vfjUCBXbhed++1Vx7rDn4r1ThXWky81BHUf+/U+ 1PFHIjwcdfOkRYaUoa2BhJbYs/Do2FJkJmQeqeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07QKmARN5PTKc Archived-At: Subject: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 22:00:10 -0000 Hi all, Many thanks to Paul for the updated revision. This makes life a lot easier. Herewith a review. I suspect some points I've raised are tracked in email threads or tickets, or in the minutes from the interim. That's OK: I just read and scribbled in a continuous stream of consciousness. A bit of a wood/trees scenario here and I can't promise I have caught every concern on this pass. Thanks to all for the work that has gone before and which makes this detailed review possible. Cheers, Adrian --- Requirements Language should not show as a numbered section. If you're using XML use within rather than
    . --- NSH needs to be expanded on first use in the body of the document (in the Introduction). --- Throughout the document you need to look at the use of "NSH". It is often missing an article (sometimes definite, sometimes indefinite). --- In section 2 NSH defines a new service plane protocol specifically for the creation of dynamic service chains and is composed of the following elements: 1. Service Function Path identification 2. Transport independent service function chain 3. Per-packet network and service metadata or optional variable type-length-value (TLV) metadata. Not sure about the middle of these 3. Isn't that a feature (which is fine to talk about somewhere) not one of the components? I think the component missing from the list is the SI. So you might write: 2. Indication of the progress along the Service Function Path. And I have some trouble parsing the third item. I think you mean network and service metadata that is per-packet (although that is perhaps a given as the NSH is also per packet). And I think you mean that the metadata is optional, fixed length, or TLV-based. How about: 3. Network and service metadata that may be optionally included per packet and that may be fixed length or constructed from type-length-value objects (TLVs). --- Why do you point to 7665 for the definition of "Classifier" but then define "Service Classifier" to mean (AFAICS) exactly the same thing? --- In 2.3 I think point 4 is a use case of metadata and so should be part of point 3. --- 3.1 s/draft/document/ --- Wondering whether "Context Headers" should be "Context Header" throughout. --- 3.1 An NSH is composed of a 4-byte (all references to bytes in this draft refer to 8-bit bytes, or octets) Base Header, a 4-byte Service Path Header and Context Headers, as shown in Figure 1 below. s/and Context/and optional Context/ --- 3.1 Service Path Header: provide path identification and location within s/provide/provides/ --- 3.2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Obviously, we have discussed the reformatting of the Base Header and ended up with 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O| TTL | Length |R|R|R|R|MD Type| Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Need to: - Add a description of the TTL field (lots of mailing list discussion) - Delete the C-bit - Update the descriptions of Reserved bits - Update the description of MD Type --- 3.2 Version: The version field is used to ensure backward compatibility going forward with future NSH updates. It MUST be set to 0x0 by the sender, in this first revision of NSH. Given the widespread implementation of existing hardware that uses the first nibble after an MPLS label stack for ECMP decision processing, this document reserves version 01 and this value MUST NOT be used in future versions of the protocol. Please see [RFC7325] for further discussion of MPLS-related forwarding requirements. I believe this text is presuming the NSH-in-MPLS encapsulation. I don't think it should do that, but if it does we have to look at the first nibble not just the first two bits. Now, as 4385 points out, if the first nibble is 4 or 6, IPv4 or IPv6 will be assumed. So 0b0100 or 0b0110 accounts for you reserving version 1 (just in case the C bit is 0 and for any value of the O bit). So far, so good! But 4385 defines a first nibble of 0000 to mean "here is a control word" and that would mean you needed to reserve version 0 as well :-( So my advice here would be that encapsulation in MPLS is not in scope for this document, and you should not play with reserving version numbers. --- 3.2 There's been a long thread on the text about the O-bit. O bit: Setting this bit indicates an Operations, Administration, and Maintenance (OAM) packet. The actual packet format and processing of SFC OAM messages is outside the scope of this specification (see [I- D.ietf-sfc-oam-framework]). First para OK. SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC OAM procedures, SHALL discard packets with O-bit set. SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable parameter to enable forwarding received SFC OAM packets unmodified to the next element in the chain. Such behavior may be acceptable for a subset of OAM functions, but can result in unexpected outcomes for others, thus it is recommended to analyze the impact of forwarding an OAM packet for all OAM functions prior to enabling this behavior. The configurable parameter MUST be disabled by default. These paras are controversial as discarding OAM packets (rather than passing them through) can also result in unexpected outcomes. Consider, if you will, simple end-to-end ping functions. (Also s/Classifer/Classifier/ twice) There is also a mismatch of "SHALL" and "MAY". I would like this text to read... === SF/SFF/SFC Proxy/Classifer implementations that do not support SFC OAM procedures, SHALL ignore the setting of the O-bit and SHALL attempt to process the packet as normal. === ...but I could live with... === SF/SFF/SFC Proxy/Classifer implementations that do not support SFC OAM procedures SHOULD discard packets with O-bit set, but MAY support a configurable parameter to enable forwarding received SFC OAM packets unmodified to the next element in the chain. === For non OAM packets, the O-bit MUST be cleared and MUST NOT be modified along the SFP. This paragraph needs simple clarification as follows === The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM packets. The O-bit MUST NOT be modified along the SFP. === --- 3.2 C-bit is being retired as discussed. --- 3.2 Length: total length, in 4-byte words, of NSH including the Base Header, the Service Path Header and the context headers or optional variable length metadata. The Length MUST be of value 0x6 for MD Type equal to 0x1 and MUST be of value 0x2 or greater for MD Type equal to 0x2. The NSH header length MUST be an integer number of 4 bytes. The length field indicates the "end" of NSH and where the original packet/frame begins. There is no "or optional variable length metadata." That is exactly what the context headers are, and the context headers are optional. And the last sentence is a little too much. So... Length: total length, in 4-byte words, of the NSH including the Base Header, the Service Path Header, and any Context Headers. It the MD Type is 0x1, the Length MUST be 0x6. If the MD Type is 0x2, the Length MUST be 0x2 or greater. The actual NSH header length MUST be an integer multiple of 4 bytes and is padded if necessary. --- 3.2 MD Type: indicates the format of NSH beyond the mandatory Base Header and the Service Path Header. MD Type defines the format of the metadata being carried. Please see IANA Considerations section below. Maybe "...indicates the format of the metadata carried in the Context Headers..." NSH defines two MD types: s/NSH/This document/ s/types/Type values/ 0x1 - which indicates that the format of the header includes fixed length context headers (see Figure 4 below). 0x2 - which does not mandate any headers beyond the Base Header and Service Path Header, but may contain optional variable length context information. Add "...not defined in this specification." --- 3.2 Next Protocol: indicates the protocol type of the encapsulated data. NSH does not alter the inner payload, and the semantics on the inner protocol remain unchanged due to NSH service function chaining. Please see IANA Considerations section below. s/due to/by/ This draft defines the following Next Protocol values: s/draft/document/ 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS Fix formatting 0x6-0xFD: Unassigned 0xFE-0xFF: Experimental Suggest to delete the last two lines as they are not protocols, but info for the IANA Considerations section. --- 3.3 Service Path Identifier (SPI): identifies a service path. Participating nodes MUST use this identifier for Service Function Path selection. The initial classifier MUST set the appropriate SPI for a given classification result. Both uses of "MUST" are unnecessary and the words could be deleted without loss of meaning or tightness of specification. --- 3.3 Service Index (SI): provides location within the SFP. The initial classifier for a given SFP SHOULD set the SI to 255, however the control plane MAY configure the initial value of SI as appropriate (i.e. taking into account the length of the service function path). Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services and the new decremented SI value MUST be used in the egress NSH packet. The initial Classifier MUST send the packet to the first SFF in the identified SFP for forwarding along an SFP. If re-classification occurs, and that re-classification results in a new SPI, the (re)classifier is, in effect, the initial classifier for the resultant SPI. What you are saying, I think is that the initial classifier MUST set the SI equal to the first SI in the SFP. This SHOULD be 255, but an SFP MAY be configured to start at a lower SI value. s/decremented/decremented by one/ (reference the endless email threads) --- 3.3 SI SHOULD be used in conjunction with Service Path Identifier for Service Function Path Selection and for determining the next SFF/SF in the path. What is the variation to this "SHOULD"? In addition to indicating the location within a Service Function Path, SI can be used for service plane loop detection. I think that, although this might still be true, the TTL will be more helpful for loop detection and we should strike this text. --- 3.4 I suggest deleting Figure 4. It does not differ from the information in Figures 1, 2, and 3, and risks not being kept up-to-date with those figures. OTOH, you should say here that Length has a specific value. --- 3.4 When the Base Header specifies MD Type = 0x1, four Context Headers, 4-byte each, MUST be added immediately following the Service Path Header, as per Figure 4. Context Headers that carry no metadata MUST be set to zero. I think this is adding new and strange meaning to "Context Header". See previous comments, but why is a Context Header suddenly a 4-byte thing? Why is this not 3 3-byte Context Headers followed by 1 7-byte Context Header? Or more realistically, why not just talk about "Up to 16 bytes of metadata carried in the 16 byte Context Header that follows the Base Header. Any context Header bytes not used to carry metadata MUST be set to zero." --- 3.4 OLD This specification does not make any assumption about the content placed in the mandatory context field of the NSH header, and does not describe the structure or meaning of the included metadata. NEW This specification does not make any assumptions about the content of the 16 byte Context Header that must be present when the MD Type field is set to 1, and does not describe the structure or meaning of the included metadata. END --- 3.4 Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured for mandatory use of metadata but does not yet receive the data semantics for the mandatory context field, it MUST NOT process the packet and MUST log at least once per the SPI for which a mandatory metadata is missing. There seem to be some assumptions here: - An SF having mandatory use of metadata is a config item and can't be an implementation thing (i.e., you are not allowing an SF that must always use metadata). - You are assuming that the semantics for the metadata are always dynamically installed in the SF and not known a priori. I don't think you should make those restrictions (although, obviously, we should allow them as options). You also seem to be assuming that a non-SFC-aware SF can receive a packet with an NSH and metadata and will somehow manage to parse the NSH and find the metadata that it doesn't understand. Frankly, I think this document talks only about SFC-aware SFs and SFC proxies. Other SFs are by definition not in scope as they will never receive an NSH (except for a bug that will reasonably cause the SF to drop the packet - or crash). Finally "must not process" is ambiguous. I think you mean "must discard" So, maybe... An SF or SFC Proxy that does not know the format or semantics of the Context Header for an NSH with MD Type 1 MUST discard any packet with such an NSH (i.e., MUST NOT ignore the metadata that it cannot process), and MUST log the event at least once per the SPI for which the event occurs (subject to thresholding). --- 3.5 Again, Figure 5 is de trop. You also need to discuss the value of the Length field. --- 3.5 This section has the usual confusion of whether there are multiple context headers (each of variable length), multiple variable length metadata, a single variable length context header (also called a variable context header) containing metadata, or whatever. Figure 6, for example, shows one piece of variable length metadata in an encoding element labelled "Variable Context Headers". This is made more confusing in the context of 3.4 where you have the concept of 4 byte context headers. Later, in 3.5.1, you call it a TLV. I wish we could sort out this language. I think what you are trying to say is that the Context Header (singular) can contain zero, one, or multiple metadata elements each encoded as a TLV as shown in Figure 6. --- 3.5.1 Discussions on the list about the sizing of the Metadata Class and Type fields, the deprecation of the C-bit, the naming of the Type field (which looks like Metadata Type which is easily confused with MD Type), and the deprecation of the split ranges of the Type field. --- 3.5.1 If multiple instances of the same TLV are included in an NSH packet, but the definition of that TLV does not allow for it, the SFC-aware SF MUST NOT process the packet and MUST log at least once per the SPI for which multiple instances of that TLV is supplied. This is OK, but I prefer the more usual (and future-proof)... If multiple instances of the same TLV are included in an NSH packet, but the definition of that TLV does not allow for it, the SFC-aware SF MUST process first instance and ignore subsequent instances. --- 4. NSH-aware nodes are the only nodes that MAY alter the content of the NSH headers. s/MAY/may/ Is there a difference between an "SFC-aware node" and an "NSH-aware node"? Isn't this sentence silly? "Only nodes that can understand the content of the NSH can change the content of the NSH" --- 4. Bullet 1 OLD At the end of a service function path, a SFF, MUST be the last node operating on the service header and MUST remove it. NEW At the end of a service function path, a SFF, MUST be the last node operating on the service header and MUST remove it before forwarding or delivering the encapsulated packet. END --- 4. Bullet 1 Multiple logical classifiers may exist within a given service path. How so "logical"? Are they or are they not "classifiers"? (Multiple occurrences in this bullet.) --- 4. Bullet 1 OLD Non-initial classifiers may re-classify data and that re- classification MAY result in a new Service Function Path. NEW Non-initial classifiers may re-classify data and that re- classification MAY result in a the packet being assigned to a different Service Function Path. END --- 4. 2. Select service path: The Service Path Header provides service chain information and is used by SFFs to determine correct service path selection. SFFs MUST use the Service Path Header for selecting the next SF or SFF in the service path. It is probably a minor point, but the Service Path Header provides service *path* information and not service chain information. --- 4. 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. If an SFF receives a packet with an SPI and SI that do not correspond to a valid next hop in a valid Service Function Path, that packet MUST be dropped by the SFF. Non-NSH-aware SFs will, of course, either not see NSHs or barf. So it is enough to say "SFs" (you have already defined the abbreviation). Say "decrement the service index by one". --- 4. Bullet 3 Classifier(s) MAY update Context Headers if new/updated context is available. s/Classifier(s)/Classifiers/ --- 4. Bullet 3 If an SFC proxy is in use (acting on behalf of a non-NSH-aware service function for NSH actions), then the proxy MUST update Service Index and MAY update contexts. When an SFC proxy receives an NSH-encapsulated packet, it MUST remove the NSH headers before forwarding it to an NSH unaware SF. When the SFC Proxy receives a packet back from an NSH unaware SF, it MUST re- encapsulates it with the correct NSH, and MUST decrement the Service Index. I think "update contexts" means "update the metadata carried in the Context Header. This does not say whether a proxy can add a Context Header if one is not already present, or whether it can add a metadata TLV, or remove one. Decide on "non-NSH-aware", "NSH unaware", "non-SFC-aware". Say "decrement the service index by one". --- 4. 4. Service policy selection: Service Function instances derive policy (i.e. service actions such as permit or deny) selection and enforcement from the service header. Metadata shared in the service header can provide a range of service-relevant information such as traffic classification. Service functions SHOULD use NSH to select local service policy. "Service Function instance" is not properly defined in 7665 and not previously mentioned in this document. OTOH, the term could usefully be used in 7.1 para 2. s/service header/NSH/ (twice) Does the last sentence add anything? It appears to say what the previous sentences say, but the "SHOULD" is ambiguous. Suggest deleting it. --- In Figure 8 - "Select Service Function Path" is ambiguous. Isn't the SFF bound by the SPI and so cannot select the path, only use the one it is instructed to use? OTOH, the Classifier is responsible for determining which path to use. - Surely the SFC proxy can update the Context Header as in bullet 3, above. - Might an SFC proxy also select service policy for an NSH-unaware SF? --- 5. The presence of NSH is indicated via protocol type or other indicator in the outer encapsulation. You are prejudging the "encapsulation of NSH" work that is to be done. You may be largely correct, but not always. We should omit this text. --- 7.1 This indirection -- path ID to overlay -- creates a true service plane. That is the SFF/SF topology is constructed without impacting the network topology but more importantly service plane only participants (i.e. most SFs) need not be part of the network overlay topology and its associated infrastructure (e.g. control plane, routing tables, etc.). As mentioned above, an existing overlay topology may be used provided it offers the requisite connectivity. There is a lot hidden or implied in this paragraph. But consider an SF that is somehow remote from the SFF. The SFF knows how to send to the SF over the underlay network. But does the SF know how to send back to the SFF? In some underlay technologies you can just reverse the encapsulation addresses. In others, you can't. Perhaps the relationship between SF and SFF is configured (i.e., known a priori)? Now consider an SF that is used on multiple SFPs. And consider further that the SF might be reachable from different SFFs on the different SFPs. Now selecting the return path becomes a challenge. Maybe "most SFs" is the clue. Maybe "some SFs" participate in the control plane and routing tables. Perhaps this could be clearer. --- 8.1 NSH itself does not provide privacy functions, rather it relies on the transport/overlay layer. An operator can select the appropriate transport to ensure the confidentially (and other security) considerations are met. I think you are making a big leap to decide what the metadata documents will define. You are also failing to consider metadata that needs to be kept private between the SF at SI 250 and the SF at SI 240 when there are other SFs in between. I suggest replacing this paragraph with something like... This specification does not provide any privacy or security functions for the NSH. Hop-by-hop security and privacy can be achieved by using features of the underlay (transport) connections. Metadata privacy and security considerations are a matter for the documents that define metadata formats, encodings, and TLVs. --- 8.2 Why do you not consider imposing metadata at a subsequent point along the path? This would happen, for example, if one SF needed to convey information to another SF for a packet that did not already have metadata. --- 12 Obviously the IANA stuff needs updating to reflect changes elsewhere: 12.2.1 The C bit has gone and the reserved bits have moved. 12.2.2 See my comment on section 3.2 12.2.3 The size of the MD Type registry is reduced. Allowing one experimental code point looks like enough to me. 12.2.4 There is a thread about this. The registry has to indicate that MD Class 0 has been assigned by this document for "IETF use". The advice to DEs needs to be supplied. The size of the range of classes may be reduced to allow an increase in the number of "types" Missing registry for "types" within the MD Class 0 The same thread applies. (I recall there was also action from the interim) The registry will be empty but should be created in this doc The name of this registry is confusable with "MD type" The size of the range may be increases as the MD class range is reduced. From nobody Tue Feb 28 22:55:57 2017 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 EB85D12941D for ; Tue, 28 Feb 2017 22:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 Uh35WpFeJeUK for ; Tue, 28 Feb 2017 22:55:53 -0800 (PST) Received: from relais-inet.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 C9B01129413 for ; Tue, 28 Feb 2017 22:55:52 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 410D912047E; Wed, 1 Mar 2017 07:55:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 21FDCC0056; Wed, 1 Mar 2017 07:55:51 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0319.002; Wed, 1 Mar 2017 07:55:50 +0100 From: To: "adrian@olddog.co.uk" , "sfc@ietf.org" Thread-Topic: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt Thread-Index: AdKRRHVLY7SkxborSRGHk+YoYh/yhABDl2OA Date: Wed, 1 Mar 2017 06:55:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E1A57E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <027d01d29144$d743bcb0$85cb3610$@olddog.co.uk> In-Reply-To: <027d01d29144$d743bcb0$85cb3610$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 06:55:55 -0000 Hi Adrian, all, Please see some comments inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > Envoy=E9=A0: lundi 27 f=E9vrier 2017 23:00 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt >=20 > Hi all, >=20 > Many thanks to Paul for the updated revision. This makes life a lot > easier. >=20 > Herewith a review. I suspect some points I've raised are tracked in > email threads or tickets, or in the minutes from the interim. That's > OK: I just read and scribbled in a continuous stream of consciousness. >=20 > A bit of a wood/trees scenario here and I can't promise I have caught > every concern on this pass. >=20 > Thanks to all for the work that has gone before and which makes this > detailed review possible. >=20 > Cheers, > Adrian >=20 > --- [SNIP] >=20 > --- >=20 > 3.2 >=20 > There's been a long thread on the text about the O-bit. >=20 > O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet. The actual packet format and processing of > SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]). >=20 > First para OK. >=20 > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. >=20 > SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable > parameter to enable forwarding received SFC OAM packets unmodified to > the next element in the chain. Such behavior may be acceptable for a > subset of OAM functions, but can result in unexpected outcomes for > others, thus it is recommended to analyze the impact of forwarding an > OAM packet for all OAM functions prior to enabling this behavior. > The configurable parameter MUST be disabled by default. >=20 > These paras are controversial as discarding OAM packets (rather than > passing them through) can also result in unexpected outcomes. Consider, > if you will, simple end-to-end ping functions. >=20 > (Also s/Classifer/Classifier/ twice) >=20 > There is also a mismatch of "SHALL" and "MAY". >=20 > I would like this text to read... >=20 > =3D=3D=3D > SF/SFF/SFC Proxy/Classifer implementations that do not support SFC > OAM procedures, SHALL ignore the setting of the O-bit and SHALL > attempt to process the packet as normal. > =3D=3D=3D >=20 [Med] Ignoring the O-bit while processing the packet "as normal" for a trac= e message, for example, will result in a broken SFC trace service (given th= at some elements won't be able to insert their information in the record li= st). =20 > ...but I could live with... >=20 > =3D=3D=3D > SF/SFF/SFC Proxy/Classifer implementations that do not support SFC > OAM procedures SHOULD discard packets with O-bit set, but MAY > support a configurable parameter to enable forwarding received SFC > OAM packets unmodified to the next element in the chain. > =3D=3D=3D >=20 [Med] OK with this one.=20 > For non OAM packets, the O-bit MUST be cleared and MUST NOT be > modified along the SFP. >=20 > This paragraph needs simple clarification as follows >=20 > =3D=3D=3D > The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM > packets. The O-bit MUST NOT be modified along the SFP. > =3D=3D=3D >=20 [Med] Agree.=20 > --- >=20 > 3.2 >=20 > C-bit is being retired as discussed. >=20 > --- >=20 > 3.2 >=20 > Length: total length, in 4-byte words, of NSH including the Base > Header, the Service Path Header and the context headers or optional > variable length metadata. The Length MUST be of value 0x6 for MD > Type equal to 0x1 and MUST be of value 0x2 or greater for MD Type > equal to 0x2. The NSH header length MUST be an integer number of 4 > bytes. The length field indicates the "end" of NSH and where the > original packet/frame begins. >=20 > There is no "or optional variable length metadata." That is exactly what > the context headers are, and the context headers are optional. And the > last sentence is a little too much. So... >=20 > Length: total length, in 4-byte words, of the NSH including the Base > Header, the Service Path Header, and any Context Headers. It the > MD Type is 0x1, the Length MUST be 0x6. If the MD Type is 0x2, the > Length MUST be 0x2 or greater. The actual NSH header length MUST be > an integer multiple of 4 bytes and is padded if necessary. >=20 > --- >=20 > 3.2 >=20 > MD Type: indicates the format of NSH beyond the mandatory Base Header > and the Service Path Header. MD Type defines the format of the > metadata being carried. Please see IANA Considerations section > below. >=20 > Maybe "...indicates the format of the metadata carried in the Context > Headers..." >=20 > NSH defines two MD types: >=20 > s/NSH/This document/ > s/types/Type values/ >=20 > 0x1 - which indicates that the format of the header includes fixed > length context headers (see Figure 4 below). [Med] s/length context headers/length context header There is only one fixed length context header (MD#1). >=20 > 0x2 - which does not mandate any headers beyond the Base Header and > Service Path Header, but may contain optional variable length context > information. >=20 > Add "...not defined in this specification." >=20 > --- >=20 [SNIP] > --- >=20 > 3.4 > I suggest deleting Figure 4. It does not differ from the information in > Figures 1, 2, and 3, and risks not being kept up-to-date with those > figures. >=20 > OTOH, you should say here that Length has a specific value. >=20 > --- >=20 > 3.4 >=20 > When the Base Header specifies MD Type =3D 0x1, four Context Headers, > 4-byte each, MUST be added immediately following the Service Path > Header, as per Figure 4. Context Headers that carry no metadata MUST > be set to zero. >=20 > I think this is adding new and strange meaning to "Context Header". [Med] As already reported to the authors, this text was forgotten when impl= ementing the change agreed in https://trac.ietf.org/trac/sfc/ticket/22. The= re isn't anymore 4 context headers.=20 > See previous comments, but why is a Context Header suddenly a 4-byte > thing? Why is this not 3 3-byte Context Headers followed by 1 7-byte > Context Header? Or more realistically, why not just talk about "Up to > 16 bytes of metadata carried in the 16 byte Context Header that follows > the Base Header. Any context Header bytes not used to carry metadata > MUST be set to zero." >=20 > --- >=20 > 3.4 >=20 > OLD > This specification does not make any assumption about the content > placed in the mandatory context field of the NSH header, and does not > describe the structure or meaning of the included metadata. > NEW > This specification does not make any assumptions about the content of > the 16 byte Context Header that must be present when the MD Type > field is set to 1, and does not describe the structure or meaning of > the included metadata. > END >=20 [Med] I'm OK with your proposal. "s/mandatory context field/fixed length co= ntext field" would be OK, too. > --- >=20 > 3.4 >=20 > Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is > configured for mandatory use of metadata but does not yet receive the > data semantics for the mandatory context field, it MUST NOT process > the packet and MUST log at least once per the SPI for which a > mandatory metadata is missing. >=20 > There seem to be some assumptions here: > - An SF having mandatory use of metadata is a config item and can't be > an implementation thing (i.e., you are not allowing an SF that must > always use metadata). > - You are assuming that the semantics for the metadata are always > dynamically installed in the SF and not known a priori. >=20 [Med] How an SF is "configured" and how it does "receive the data semantic"= are not detailed in the text. This can be manual configuration, hardcoded = parameters, dynamic provisioning, etc.=20 > I don't think you should make those restrictions (although, obviously, > we should allow them as options). >=20 > You also seem to be assuming that a non-SFC-aware SF can receive a > packet with an NSH and metadata and will somehow manage to parse the NSH > and find the metadata that it doesn't understand. Frankly, I think this > document talks only about SFC-aware SFs and SFC proxies. [Med] There is a need to distinguish SFs that are SFC-aware and those that = aren't (typically, those serviced by an SF proxy).=20 Other SFs are > by definition not in scope as they will never receive an NSH (except for > a bug that will reasonably cause the SF to drop the packet - or crash). >=20 > Finally "must not process" is ambiguous. I think you mean "must discard" >=20 > So, maybe... >=20 > An SF or SFC Proxy that does not know the format or semantics of the > Context Header for an NSH with MD Type 1 MUST discard any packet with > such an NSH (i.e., MUST NOT ignore the metadata that it cannot > process), and MUST log the event at least once per the SPI for which > the event occurs (subject to thresholding). >=20 [Med] IMHO, this is too restrictive as failures will be experienced each ti= me a path involved an SF, not aware of the data semantic, even if that SF i= s not supposed to consume/supply a context data for a given chain. I'd like= failures to be declared only by SFs who require the mandatory context data= for executing their service. --- [SNIP] > 3.5.1 >=20 > Discussions on the list about the sizing of the Metadata Class and > Type fields, the deprecation of the C-bit, the naming of the Type field > (which looks like Metadata Type which is easily confused with MD Type), > and the deprecation of the split ranges of the Type field. >=20 > --- >=20 > 3.5.1 >=20 > If multiple instances of the same TLV are included in an NSH packet, > but the definition of that TLV does not allow for it, the SFC-aware > SF MUST NOT process the packet and MUST log at least once per the SPI > for which multiple instances of that TLV is supplied. >=20 > This is OK, but I prefer the more usual (and future-proof)... >=20 > If multiple instances of the same TLV are included in an NSH packet, > but the definition of that TLV does not allow for it, the SFC-aware > SF MUST process first instance and ignore subsequent instances. >=20 [Med] The OLD wording is consistent with the specification of a TLV indicat= ing explicitly that multiple instances MUST NOT be allowed.=20 Further, picking the first instance may be problematic. Consider for exampl= e, a TLV that carries a subscriber identifier + the definition of this TLV = indicates that only one instance is allowed per chain. Consider now that fo= r some reason, two subscriber-identifier TLV instances are present in a pac= ket, because there are no requirements about the ordering of the TLVs (incl= uding order preservation when processing and forwarding NSH packets), picki= ng the first instance may lead to applying per-subscriber policies that may= not those of the correct one. The consequence may be for example access to= privacy data, access to a service while that user is not allowed, and so n= o.=20 I prefer the text as it is in -12. The logs can trigger alarms to fix problems in configuring an SFC domain. = =20 [snip]