From nobody Tue Nov 1 09:56:41 2016 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 1B5F41294D0; Tue, 1 Nov 2016 09:56:40 -0700 (PDT) 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 8HXMMx7IEEBp; Tue, 1 Nov 2016 09:56:38 -0700 (PDT) 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 A0A391294A5; Tue, 1 Nov 2016 09:56:34 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1GuWJ9004649; Tue, 1 Nov 2016 16:56:32 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1GuSia004621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 16:56:29 GMT From: "Adrian Farrel" To: Date: Tue, 1 Nov 2016 16:56:23 -0000 Message-ID: <022801d23460$e2609190$a721b4b0$@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: AdI0YNSia0oWGMevSXyHlqL96d0UCA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22674.001 X-TM-AS-Result: No--22.092-10.0-31-10 X-imss-scan-details: No--22.092-10.0-31-10 X-TMASE-MatchedRID: TyMThhr6WqXnzGzIj554J8WUKBjERoYTbv16+gil4jfM7zpEspqG/3/2 0wqGUabSTWLw2jvbfpw2HZCtTkRx1PUe3cF58v23uIwLnB3Aqp3omPrNi98UBDKTTxPF8Sb9DcQ KdfimlTJPjVS7XYOPooQSjqSszbEG/jsbtWBGy0y7vYqkCS0dLyOSuAnftGqPjNnoU1fopotpgr Yvic2QdZqEyqY1drdF1wze+AUePnwPTseEfsgma7MjW/sniEQKgRykyfrH1xk6iP0NczjR0rEsm xAG+5F7YGXbdQDneY5/IKDFmVluyRgC11h6mOpCTVa+L3Zgqc46En2bnefhoDERi1haWZ7IWT8R VkWVKi636h2hK5rvdpGTpe1iiCJqtD9qpBlNF8rAuFFGa+JUhfoA9r2LThYYKrauXd3MZDUD/dH yT/Xh7Q== Archived-At: Cc: draft-mackie-bess-nsh-bgp-control-plane@ietf.org Subject: [sfc] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-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: Tue, 01 Nov 2016 16:56:40 -0000 Hi SFC WG, You may be interested in this draft. It provides a BGP control pane for an (NSH-enabled) SFC network. Currently the document is being discussed on the BESS mailing list which, from reading the charters, is where it belongs. Thanks, Adrian > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 30 October 2016 16:19 > To: bess@ietf.org > Subject: [bess] FW: New Version Notification for draft-mackie-bess-nsh-bgp- > control-plane-01.txt > > Hi Bess WG, > > We made some updates to this document to tidy it and to get the terminology in > line with RFC 7665. > > Adrian > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 30 October 2016 16:09 > > To: Eric Rosen; Adrian Farrel; John Drake; Jim Uttaro; Luay Jalil > > Subject: New Version Notification for draft-mackie-bess-nsh-bgp-control- > plane- > > 01.txt > > > > > > A new version of I-D, draft-mackie-bess-nsh-bgp-control-plane-01.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Name: draft-mackie-bess-nsh-bgp-control-plane > > Revision: 01 > > Title: BGP Control Plane for NSH SFC > > Document date: 2016-10-30 > > Group: Individual Submission > > Pages: 37 > > URL: https://www.ietf.org/internet-drafts/draft-mackie-bess-nsh-bgp- > > control-plane-01.txt > > Status: https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp- > control- > > plane/ > > Htmlized: https://tools.ietf.org/html/draft-mackie-bess-nsh-bgp-control- > > plane-01 > > Diff: https://www.ietf.org/rfcdiff?url2=draft-mackie-bess-nsh-bgp- > control- > > plane-01 > > > > 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. > > > > > > > > > > > > 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 > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Nov 1 10:24:51 2016 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 EE2331294BB for ; Tue, 1 Nov 2016 10:24:49 -0700 (PDT) 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 qNDe-M2KEZeA for ; Tue, 1 Nov 2016 10:24:49 -0700 (PDT) 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 13D2B1293DC for ; Tue, 1 Nov 2016 10:24:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 00CF9253716 for ; Tue, 1 Nov 2016 10:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478021089; bh=UXaYDtbL/Cv2R2wSQTBZBAswnqWwtGRECnxTf4gD+/U=; h=To:From:Subject:Date:From; b=L2+lIXzJP2WK8VOTax8ddnnuT6z4R47gAkenNmkgie6nkU+YNDFcP4GmF65w2RxQq vpino1HgduYUFqi5hFkCoGFfzuIZqAvNEBb5F0cPA2T6JTtZMYoZpZ21BIUNALCBZ6 Pf0Ppl/0vQHf7BSBA8XXtxfL+X8uz9jlSEGHhKEk= 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 9F32324B501 for ; Tue, 1 Nov 2016 10:24:48 -0700 (PDT) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Tue, 1 Nov 2016 13:26:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] decrementing service function path index 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, 01 Nov 2016 17:24:50 -0000 I was having a discussion (see IDR list) about SFC, and it was observed that in the NSH draft we never specify a meaning for "decrement". While I have assumed a meaning, assumptions are not good for interoperable implementations. Do people understand the current document to require decrementing by 1, or to allow a larger decrement? More importantly, what do we want to say in the spec about this? If we want to allow decrement by more than 1, since the SF is doing the decrement, we need to talk about the SF being configured to know how much to decrement. In my personal opinion, that seems overly complex and fragile. Yours, Joel From nobody Tue Nov 1 10:29:39 2016 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 B099A1293E3 for ; Tue, 1 Nov 2016 10:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.518 X-Spam-Level: X-Spam-Status: No, score=-8.518 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=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 A7Qjo-p5B0lx for ; Tue, 1 Nov 2016 10:29:36 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E801294AD for ; Tue, 1 Nov 2016 10:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1478021376; x=1509557376; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eMpeADUljWoji0R0bds6RtO1TFHov3H+bTBu2ZXo4L4=; b=HX4rdo5LiiagPjlGO/gwjZ2KzIBd5ZSUbg2sG2cGDZ+ir2UmuijvDsEa DVcvt67BJB7saaHaiTwcTHJqv/FxckS8awGqsAkgVsk9T5vaeSse984Ft B6f4rez+bbdMJgTLI2WbQ3qjGz1vp+Uc/LeZGwDEYVARCizuqc7JBufck 8=; X-IronPort-AV: E=McAfee;i="5700,7163,8336"; a="253135387" X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="253135387" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 01 Nov 2016 17:29:36 +0000 Received: from SE3CCPEMS03.olympus.F5Net.com (172.23.161.14) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 1 Nov 2016 10:29:33 -0700 Received: from SE3CCPEMS05.olympus.F5Net.com (172.23.161.16) by SE3CCPEMS03.olympus.F5Net.com (172.23.161.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Tue, 1 Nov 2016 10:29:33 -0700 Received: from SE3CCPEMS05.olympus.F5Net.com ([fe80::50f9:a657:ac15:1c1f]) by SE3CCPEMS05.olympus.F5Net.com ([fe80::50f9:a657:ac15:1c1f%18]) with mapi id 15.01.0544.027; Tue, 1 Nov 2016 10:29:32 -0700 From: Sumandra Majee To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSNGTbiKpz88W/ZEauyJijvio456DEYjwA Date: Tue, 1 Nov 2016 17:29:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.168.15.215] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 17:29:38 -0000 SSBoYXZlIGFsd2F5cyBhc3N1bWVkIChpbXBsaWNpdGx5KSB0aGF0IGRlY3JlbWVudCBvZiBTSSBt ZWFucyBTMS0xIGJ5IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIG9uY2UgdGhlIHNlcnZpY2UgaXMgcmVu ZGVyZWQuDQoNCk9uIDExLzEvMTYsIDEwOjI2IEFNLCAic2ZjIG9uIGJlaGFsZiBvZiBKb2VsIE0u IEhhbHBlcm4iIDxzZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam1oQGpvZWxoYWxw ZXJuLmNvbT4gd3JvdGU6DQoNCiAgICBJIHdhcyBoYXZpbmcgYSBkaXNjdXNzaW9uIChzZWUgSURS IGxpc3QpIGFib3V0IFNGQywgYW5kIGl0IHdhcyBvYnNlcnZlZCANCiAgICB0aGF0IGluIHRoZSBO U0ggZHJhZnQgd2UgbmV2ZXIgc3BlY2lmeSBhIG1lYW5pbmcgZm9yICJkZWNyZW1lbnQiLg0KICAg IA0KICAgIFdoaWxlIEkgaGF2ZSBhc3N1bWVkIGEgbWVhbmluZywgYXNzdW1wdGlvbnMgYXJlIG5v dCBnb29kIGZvciANCiAgICBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4NCiAgICANCiAg ICBEbyBwZW9wbGUgdW5kZXJzdGFuZCB0aGUgY3VycmVudCBkb2N1bWVudCB0byByZXF1aXJlIGRl Y3JlbWVudGluZyBieSAxLCANCiAgICBvciB0byBhbGxvdyBhIGxhcmdlciBkZWNyZW1lbnQ/DQog ICAgDQogICAgTW9yZSBpbXBvcnRhbnRseSwgd2hhdCBkbyB3ZSB3YW50IHRvIHNheSBpbiB0aGUg c3BlYyBhYm91dCB0aGlzPyAgSWYgd2UgDQogICAgd2FudCB0byBhbGxvdyBkZWNyZW1lbnQgYnkg bW9yZSB0aGFuIDEsIHNpbmNlIHRoZSBTRiBpcyBkb2luZyB0aGUgDQogICAgZGVjcmVtZW50LCB3 ZSBuZWVkIHRvIHRhbGsgYWJvdXQgdGhlIFNGIGJlaW5nIGNvbmZpZ3VyZWQgdG8ga25vdyBob3cg DQogICAgbXVjaCB0byBkZWNyZW1lbnQuICBJbiBteSBwZXJzb25hbCBvcGluaW9uLCB0aGF0IHNl ZW1zIG92ZXJseSBjb21wbGV4IA0KICAgIGFuZCBmcmFnaWxlLg0KICAgIA0KICAgIFlvdXJzLA0K ICAgIEpvZWwNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgIHNmYyBtYWlsaW5nIGxpc3QNCiAgICBzZmNAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KICAgIA0KDQo= From nobody Tue Nov 1 10:34:41 2016 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 8A049129524 for ; Tue, 1 Nov 2016 10:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 x4GyIycicdBl for ; Tue, 1 Nov 2016 10:34:38 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::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 829FF129517 for ; Tue, 1 Nov 2016 10:34:38 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id v78so24964540ybe.3 for ; Tue, 01 Nov 2016 10:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=U2PcOZ1K9Vb0q5ceFN17O+xGXxV74prV+z0x7br3xaE=; b=dYU4GMxxkLvYXIdeA7aO+zHbCKStITASgIQpBpIyuzymEsOYpjcShOJOR+yNV1s1lG EuE7xLmxnfyYy4D83pJS11VLHt1fvTUId7+E/8svwV/3n3xD8gbjZ7fReBkkFw4g7k0B HJrKT5adbdGjNDp7fQLQuyruDCbVSciD6e0M5/TnDgTMqEksDmgujKZVjvMvkZvZlKlg wiGnGo6aETCozrz/3AsOgEkPmwagKk/z557WigpYc+Ho2u7J0jTWlL0ujJJ5zc3xQhge FJzbj/WUtV6RIw3wQOWb8GAB7n/JI0EteeXWMlT7tC9rHRmQiylafOr1rT3xUgtaQbup uaNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=U2PcOZ1K9Vb0q5ceFN17O+xGXxV74prV+z0x7br3xaE=; b=jTBl3PrEb1OBjE11mqvmSE9dy5zzx6ioorXGGOGBGVWHOkeOYON8/iIUnqFqCFoMah MTr2tlt4Ims3FEYD43LWTSis4m75985qjf2lxcfevWnq/aIwivNEBcefRBog4EceoRQQ a9jtGGcJNHgoEHjHvpImbxjrjcnuSAdubE74Epg/hiiQcBINGpQ3Smwkr0ocCqSg8R9p gTyWdPAqvVGZlbD9hJ77CmBKi9RNI9L09NigzXKjOe1MJR1VScHH+RzeML3QnNID4QDf QesLWFP1Bra+qwz+PqOucrcWZzV5zF1ZCQqnnTJaJXIW5zWedcWRP88GlVWOX7MKbsmj DMkA== X-Gm-Message-State: ABUngveWvCTYCOi94k/QWYlDyATX7mSZrTrmU+AKWg2I9kczF1ox+4OGN7F2C47rCmTaiLpru9PI3IT6WRmhJw== X-Received: by 10.37.170.193 with SMTP id t59mr28706542ybi.86.1478021677681; Tue, 01 Nov 2016 10:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.56.133 with HTTP; Tue, 1 Nov 2016 10:34:37 -0700 (PDT) From: Alia Atlas Date: Tue, 1 Nov 2016 13:34:37 -0400 Message-ID: To: "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a1148180a1192a4054040bda2 Archived-At: Cc: Thomas Narten , Martin Stiemerling Subject: [sfc] SFC Chair Changes 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, 01 Nov 2016 17:34:39 -0000 --001a1148180a1192a4054040bda2 Content-Type: text/plain; charset=UTF-8 I would again like to thank Thomas Narten and and Martin Stiemerling for their work as SFC Chairs. It is greatly appreciated and has helped the SFC WG progress. At this time, they are both stepping down as SFC Chairs. I am appointing Joel Halpern to replace them. I am confident that Joel and Jim will work well together to bring a more rapid advancement of the SFC work. Regards, Alia --001a1148180a1192a4054040bda2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would again like to thank Thomas Narten and and Martin S= tiemerling for their work as SFC Chairs.=C2=A0 It is greatly appreciated an= d has helped the SFC WG progress.

At this time, they are= both stepping down as SFC Chairs.

I am appointing= Joel Halpern to replace them.=C2=A0 I am confident that Joel and Jim will = work well together to bring a more rapid advancement of the SFC work.
=

Regards,
Alia
--001a1148180a1192a4054040bda2-- From nobody Tue Nov 1 11:02:57 2016 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 D9DFC12973E for ; Tue, 1 Nov 2016 11:02:54 -0700 (PDT) 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 zqo0et6dXeDp for ; Tue, 1 Nov 2016 11:02:53 -0700 (PDT) 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 AA9991296D2 for ; Tue, 1 Nov 2016 11:02:52 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1I2niW015985; Tue, 1 Nov 2016 18:02:49 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1I2mM6015973 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 18:02:49 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: In-Reply-To: Date: Tue, 1 Nov 2016 18:02:42 -0000 Message-ID: <025f01d2346a$24f947a0$6eebd6e0$@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: AQIgrbss3hc6CKL2djyaMboulKyfnaAnd8Ow Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22674.001 X-TM-AS-Result: No--11.409-10.0-31-10 X-imss-scan-details: No--11.409-10.0-31-10 X-TMASE-MatchedRID: QfHZjzml1E8TfAqiYFP7BilrosmS0SOAKLwy5ubGYBTkMnUVL5d0EwSI qbVzaI9G1vNKGjIONd0skUg+WjIazGAddajfrokAlTsGW3DmpUu3dp6DuD+6wCIWzbRXGr/Caus AbI7vYo/KC27Ht5n6Jor/1lK/mB31VJ3fELbkWeh1fPeXvwXdiV7OZ6hrwwnzjV5GHmaEmvrgxk zVD9ly8DXb9ZdX6KpnfESa829+Aq2RUXjihTf9CJ1U1lojafr/QZXZg2I8JabnU40jhQv76qPFj JEFr+olfeZdJ1XsorhCITlsmPfzAAtuKBGekqUpI/NGWt0UYPC/dsHnlL/Xvo0bIzr2le8JYn7S o9gIEUxkoW7cxDRSOsX55enpC3hi Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 18:02:55 -0000 Well, of course, the discussion was on the BESS list, not the IDR list. I have always assumed that "decrement" meant "reduce" but not necessarily "reduce by one." But that may be because I am puzzled about why there is a mix of functional architecture and protocol architecture in the same document. When a re-classifier is "co-resident" with an SF, can anyone *outside* the SF tell who it was that decremented the SI by more than one? Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 01 November 2016 17:27 > To: sfc@ietf.org > Subject: [sfc] decrementing service function path index > > I was having a discussion (see IDR list) about SFC, and it was observed > that in the NSH draft we never specify a meaning for "decrement". > > While I have assumed a meaning, assumptions are not good for > interoperable implementations. > > Do people understand the current document to require decrementing by 1, > or to allow a larger decrement? > > More importantly, what do we want to say in the spec about this? If we > want to allow decrement by more than 1, since the SF is doing the > decrement, we need to talk about the SF being configured to know how > much to decrement. In my personal opinion, that seems overly complex > and fragile. > > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 1 11:06:40 2016 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 065BC12979D for ; Tue, 1 Nov 2016 11:06:39 -0700 (PDT) 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 AKB2F_SrF5ob for ; Tue, 1 Nov 2016 11:06:37 -0700 (PDT) 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 BACAB12973E for ; Tue, 1 Nov 2016 11:06:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 978AC2464D2; Tue, 1 Nov 2016 11:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478023597; bh=eu6Om4oIoltVCWN+eaYTRrLi88oy9RpHRX2rMnE8yw8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gAojjS8PBKgiShJxzipfZJIzG7lvacSMdqOIl3XJfX2ASVgHyrxFrYiPpbEtOGYRo AYdiiJFpJWqfBi+fsyNHwXf9HwboXeD77qZ3wJcovvdWaBDbGv+ECnKJzoibNhP/+0 Ci3UcgCMnwjRwaXkHoLya6yKUWI0U4CWogZn4a5Y= 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 16E72245E66; Tue, 1 Nov 2016 11:06:36 -0700 (PDT) To: adrian@olddog.co.uk, sfc@ietf.org References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Tue, 1 Nov 2016 14:08:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 18:06:39 -0000 Sorry for crossing IDR and BES. With regard to the architectural components, the NSH draft does not define those. It is using the architectural, logical, components and architecture defined by the SFC Architecture documents. Yours, Joel On 11/1/16 2:02 PM, Adrian Farrel wrote: > Well, of course, the discussion was on the BESS list, not the IDR list. > > I have always assumed that "decrement" meant "reduce" but not necessarily > "reduce by one." > > But that may be because I am puzzled about why there is a mix of functional > architecture and protocol architecture in the same document. > When a re-classifier is "co-resident" with an SF, can anyone *outside* the SF > tell who it was that decremented the SI by more than one? > > Adrian > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: 01 November 2016 17:27 >> To: sfc@ietf.org >> Subject: [sfc] decrementing service function path index >> >> I was having a discussion (see IDR list) about SFC, and it was observed >> that in the NSH draft we never specify a meaning for "decrement". >> >> While I have assumed a meaning, assumptions are not good for >> interoperable implementations. >> >> Do people understand the current document to require decrementing by 1, >> or to allow a larger decrement? >> >> More importantly, what do we want to say in the spec about this? If we >> want to allow decrement by more than 1, since the SF is doing the >> decrement, we need to talk about the SF being configured to know how >> much to decrement. In my personal opinion, that seems overly complex >> and fragile. >> >> Yours, >> Joel >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > From nobody Tue Nov 1 11:34:44 2016 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 0414E1297C3 for ; Tue, 1 Nov 2016 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=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 7teHnxeP0cS6 for ; Tue, 1 Nov 2016 11:34:41 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0124.outbound.protection.outlook.com [104.47.40.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B81112979D for ; Tue, 1 Nov 2016 11:34:41 -0700 (PDT) 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=6PFwoZkfAzqo9ueXe6iqG7c0EtYJg2JifwbS+GbuP7g=; b=OWMUzieWKgzRcBIFWw4hxKy+qQrbHKMOS9rOFz5eajvc2P5b+R5xVmE4hXgc/Lmkku1DfZZT1THPlIoEfOn4NI/Ylcvt4l+ogbWFDv/vhACMAGwBR9e/0ug/PZHRNi6H1eqpS1BP15uvvElRn9MD2lg1rapwbDJ0NnPyTZMEOCY= Received: from BN6PR05MB2995.namprd05.prod.outlook.com (10.173.19.13) by CY1PR05MB2186.namprd05.prod.outlook.com (10.166.192.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Tue, 1 Nov 2016 18:34:39 +0000 Received: from BN6PR05MB2995.namprd05.prod.outlook.com ([10.173.19.13]) by BN6PR05MB2995.namprd05.prod.outlook.com ([10.173.19.13]) with mapi id 15.01.0707.004; Tue, 1 Nov 2016 18:34:38 +0000 From: John E Drake To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSNGTbPeThdXXVkEabm0FuHlDQ0KDEcWSw Date: Tue, 1 Nov 2016 18:34:38 +0000 Message-ID: References: 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=jdrake@juniper.net; x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; CY1PR05MB2186; 7:g0QC0IkUSGunWOhxnRwnZbrQ+4ecdKzoqV8oKCPx4F30y3okrxqP01WBAdOlI50zOPpd5vsV+Kzk33II8FL+mecwqJLfQLMq9P+r+JJqeR6jXmTU1EeiXILn8QPSeE+9qqe/GhjNu+4lCptaeh18lmCrUrW9Jvp3M+81JAuXyPi2Qkz+u7eloVGg38nO4x0bpd9T5farfGotGH8pq42j8iBZ26NCHkifbWwwbQ+z6PxwhIJT+bg+VOjQoMQdeGndSJP8H4ad9eVBdd+wsjBYYxFzIicxDg4fxDuYTrI9veXexeXrMLE/TPi4odcowzAcvl7Q7Vu1IWmUADlg2JlIPjV0AdvZV4dW/AANIAJKRCw= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(13464003)(189002)(4326007)(9686002)(76576001)(99286002)(7736002)(10400500002)(105586002)(3280700002)(33656002)(106116001)(15975445007)(101416001)(76176999)(8936002)(7846002)(3660700001)(122556002)(2906002)(50986999)(68736007)(54356999)(106356001)(19580395003)(87936001)(19580405001)(7696004)(66066001)(81166006)(92566002)(81156014)(5001770100001)(107886002)(5660300001)(8676002)(5002640100001)(77096005)(189998001)(74316002)(2900100001)(97736004)(2501003)(305945005)(2950100002)(6116002)(102836003)(86362001)(586003)(3846002)(4001430100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2186; H:BN6PR05MB2995.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 6ff2c212-0ac0-43e6-94d2-08d40285bc87 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2186; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2186; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2186; x-forefront-prvs: 01136D2D90 received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2016 18:34:38.1899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2186 Archived-At: Cc: Adrian Farrel , Eric Rosen Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 18:34:43 -0000 Hi, 'Decrement' has a very well defined meaning and it is different than 'decre= ment by 1'. Given that service function paths need to be defined and distr= ibuted to the nodes in an SFC network I don't see any reason why that defin= ition can't include the SI values. This allows a service function path to be modified by either adding or dele= ting elements without having to renumber its unaffected portions. Yours Irrespectively, John > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, November 1, 2016 1:27 PM > To: sfc@ietf.org > Subject: [sfc] decrementing service function path index >=20 > I was having a discussion (see IDR list) about SFC, and it was observed t= hat in the > NSH draft we never specify a meaning for "decrement". >=20 > While I have assumed a meaning, assumptions are not good for interoperabl= e > implementations. >=20 > Do people understand the current document to require decrementing by 1, o= r to > allow a larger decrement? >=20 > More importantly, what do we want to say in the spec about this? If we w= ant to > allow decrement by more than 1, since the SF is doing the decrement, we n= eed > to talk about the SF being configured to know how much to decrement. In = my > personal opinion, that seems overly complex and fragile. >=20 > Yours, > Joel >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 1 11:44:37 2016 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 9FA6F12985C for ; Tue, 1 Nov 2016 11:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 6Ugo4yCnV59f for ; Tue, 1 Nov 2016 11:44:34 -0700 (PDT) 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 0B4A7129866 for ; Tue, 1 Nov 2016 11:44:34 -0700 (PDT) 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, 1 Nov 2016 14:44:32 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0319.002; Tue, 1 Nov 2016 14:44:33 -0400 From: Dave Dolson To: John E Drake , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSNGTcgDa3IiYdtkCDma+QNmaeP6DEt3gA//+/QDA= Date: Tue, 1 Nov 2016 18:44:31 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Adrian Farrel , Eric Rosen Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 18:44:35 -0000 I had understood the service function must decrement the SI value by exactl= y one before returning to the SFF. (This doesn't require any configuration.) Given John's different interpretation, let's make it explicit. -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of John E Drake Sent: Tuesday, November 01, 2016 2:35 PM To: Joel M. Halpern; sfc@ietf.org Cc: Adrian Farrel; Eric Rosen Subject: Re: [sfc] decrementing service function path index Hi, 'Decrement' has a very well defined meaning and it is different than 'decre= ment by 1'. Given that service function paths need to be defined and distr= ibuted to the nodes in an SFC network I don't see any reason why that defin= ition can't include the SI values. This allows a service function path to be modified by either adding or dele= ting elements without having to renumber its unaffected portions. Yours Irrespectively, John > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, November 1, 2016 1:27 PM > To: sfc@ietf.org > Subject: [sfc] decrementing service function path index >=20 > I was having a discussion (see IDR list) about SFC, and it was observed t= hat in the > NSH draft we never specify a meaning for "decrement". >=20 > While I have assumed a meaning, assumptions are not good for interoperabl= e > implementations. >=20 > Do people understand the current document to require decrementing by 1, o= r to > allow a larger decrement? >=20 > More importantly, what do we want to say in the spec about this? If we w= ant to > allow decrement by more than 1, since the SF is doing the decrement, we n= eed > to talk about the SF being configured to know how much to decrement. In = my > personal opinion, that seems overly complex and fragile. >=20 > Yours, > Joel >=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 Tue Nov 1 11:48:03 2016 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 13F29129875 for ; Tue, 1 Nov 2016 11:48:03 -0700 (PDT) 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 G6p2Ot1hC7wp for ; Tue, 1 Nov 2016 11:48:02 -0700 (PDT) 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 94F7F12985F for ; Tue, 1 Nov 2016 11:47:49 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1IllSU010331; Tue, 1 Nov 2016 18:47:47 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1IlkhU010319 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 18:47:46 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> In-Reply-To: Date: Tue, 1 Nov 2016 18:47:40 -0000 Message-ID: <026701d23470$6cef2880$46cd7980$@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: AQIgrbss3hc6CKL2djyaMboulKyfnQG7Sgr8AXzjmRGgDcGowA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22674.001 X-TM-AS-Result: No--2.217-10.0-31-10 X-imss-scan-details: No--2.217-10.0-31-10 X-TMASE-MatchedRID: 7ySqCuYCpfg4HKI/yaqRm8FWmsryu9ZfGWAN/II9wcTzus+II/WN4KDS FbNSvOcnWBraUBEggAhcCggYPLR+fLHSW/JqXXHEaDCzqDR7DPYZKp0SZ4P+dZ+D2WKPwBVcWCt Y5fOKaAP/syQDt3ytONUkJMc7dlafGAdnzrnkM485f9Xw/xqKXdivpTdmVCR22bNx1HEv7HAqtq 5d3cxkNZ88Opk9iYSPQmZYXM+SXSRHRdfInpzEanryKNNjQKOu6MYkl1KceKDJSoLyORBgDL2ii oZJ95kREg11qeLaTrGIjIEXldji1B5Y7iXi6/Pur3LE7lHo4NKJkNr6rpsABVVB/ObyHMK5Zzbw ncYrg9dDDKa3G4nrLQ== Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 18:48:03 -0000 > With regard to the architectural components, the NSH draft does not > define those. It is using the architectural, logical, components and > architecture defined by the SFC Architecture documents. I'd like to understand where in 7665 it says that the SF is responsible for moving the packet on to the next SF in the path, rather than the SFF. I'd also like to understand why the NSH document (that tells us how to encapsulate, and what to do at each hop in the path) needs to divide the responsibility for bits of protocol work between different logical functional entities. In short, why does the SF decrement the SI, why isn't this an SFF function? What benefit comes from doing it this way or did a choice simply have to be made? Thanks, Adrian From nobody Tue Nov 1 11:55:10 2016 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 70CAA12985A for ; Tue, 1 Nov 2016 11:55:08 -0700 (PDT) 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 1iNvpAfJk47v for ; Tue, 1 Nov 2016 11:55:06 -0700 (PDT) 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 37944129891 for ; Tue, 1 Nov 2016 11:55:06 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1It4Ew014049; Tue, 1 Nov 2016 18:55:04 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1It3U1014042 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 18:55:03 GMT From: "Adrian Farrel" To: "'Dave Dolson'" , "'John E Drake'" , "'Joel M. Halpern'" , References: In-Reply-To: Date: Tue, 1 Nov 2016 18:54:57 -0000 Message-ID: <026c01d23471$718f9630$54aec290$@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: AQIgrbss3hc6CKL2djyaMboulKyfnQGVKzS6AVo2cCugEArpEA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22674.001 X-TM-AS-Result: No--26.135-10.0-31-10 X-imss-scan-details: No--26.135-10.0-31-10 X-TMASE-MatchedRID: xcONGPdDH5rxlOJuQNHlfY+YSzwl92XTCI3p+Ju8mqoZIBFbO0q3jxND 3wNw/alW3f0e/BgwI9BLfvF/pHb+8qQ4hjf3OSHYdXu122+iJtpUXmZR3qwgxrKeTtOdjMy6f/b TCoZRptJNYvDaO9t+nFxBgG7mg/Dlrc1P3+sGT5yVUcz8XpiS9IEcpMn6x9cZwsVsQDOlmqeUOB X211gmSe/8OPHwIoWvStcxem7S7Ti5XqTmH3jzrTXKFtsDtZ7T7h2RrsKOiu3zaJ5V6EdAXszpa T8RVq/t9V8xaspiF8qHKpBh4wyCdY6vrd50xb7zQ1OcCEvT+bcAc38TO70Sccj0QMA/92m2IieR nemP2JU12/WXV+iqZ3xEmvNvfgKtkVF44oU3/QidVNZaI2n6/0GV2YNiPCWm51ONI4UL++qjxYy RBa/qJX3mXSdV7KK4WKD2QKkwR8Iv7bm8B5Akl/oA9r2LThYYKrauXd3MZDUD/dHyT/Xh7Q== Archived-At: Cc: 'Adrian Farrel' , 'Eric Rosen' Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 18:55:08 -0000 Hi Dave, So the thing at question here is "can you support a non-configured chain?" That is, can the "thing" know by how much to decrement the SI without being configured? Well, certainly making a rule that it MUST decrement by 1 avoids that. But note that configuration is needed so that the SFF knows how to forward to the next hop, so the logical node (i.e. the SF+SFF) has to be configured. We could get further into why the SF does the decrement (not the SFF), or we could say that: "The SF is responsible for setting the SI value for the next hop in the SFP and absent any other information it MUST decrement the SI by 1." If we do that, I can do what I want, and you can do what you want, and everything works fine. And the protocol is undisturbed! Thanks, Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: 01 November 2016 18:45 > To: John E Drake; Joel M. Halpern; sfc@ietf.org > Cc: Adrian Farrel; Eric Rosen > Subject: Re: [sfc] decrementing service function path index > > I had understood the service function must decrement the SI value by exactly > one before returning to the SFF. > (This doesn't require any configuration.) > > Given John's different interpretation, let's make it explicit. > > -Dave > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of John E Drake > Sent: Tuesday, November 01, 2016 2:35 PM > To: Joel M. Halpern; sfc@ietf.org > Cc: Adrian Farrel; Eric Rosen > Subject: Re: [sfc] decrementing service function path index > > Hi, > > 'Decrement' has a very well defined meaning and it is different than 'decrement > by 1'. Given that service function paths need to be defined and distributed to the > nodes in an SFC network I don't see any reason why that definition can't include > the SI values. > > This allows a service function path to be modified by either adding or deleting > elements without having to renumber its unaffected portions. > > Yours Irrespectively, > > John > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: Tuesday, November 1, 2016 1:27 PM > > To: sfc@ietf.org > > Subject: [sfc] decrementing service function path index > > > > I was having a discussion (see IDR list) about SFC, and it was observed that in > the > > NSH draft we never specify a meaning for "decrement". > > > > While I have assumed a meaning, assumptions are not good for interoperable > > implementations. > > > > Do people understand the current document to require decrementing by 1, or > to > > allow a larger decrement? > > > > More importantly, what do we want to say in the spec about this? If we want > to > > allow decrement by more than 1, since the SF is doing the decrement, we need > > to talk about the SF being configured to know how much to decrement. In my > > personal opinion, that seems overly complex and fragile. > > > > 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 From nobody Tue Nov 1 12:04:31 2016 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 2DDB5129975 for ; Tue, 1 Nov 2016 12:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 fU2aQs0GYKB2 for ; Tue, 1 Nov 2016 12:04:28 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC29129978 for ; Tue, 1 Nov 2016 12:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4572; q=dns/txt; s=iport; t=1478027026; x=1479236626; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rceN4s78nCr9E9twBZqKpNdGbftZnBQxcZZwpyHztgg=; b=NKGp6jhEenp2Ety8rp491usZ1DRQ9VQrUIkLGIm2YuxfKEkpJ4wRWNfZ bw3GcPkuJFzfcLlA98EIKc4OVCY8AMbJO+RO+o647CNiUC7S2GPYUbl8y bAUuupk+XHCMlsx984FaPRwHgpxKJvWfDoYmwdz6LmN5fU0yks5jZM47m s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQB/5hhY/5NdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfAeNL5cBlEWCBx0LhXoCghM/FAECAQEBAQEBAWIohGE?= =?us-ascii?q?BAQEEAQEBNzQLDAQCAQgRBAEBHwkHJwsUCQgCBAENBQiITA64EAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARcFixKKJwWaGgGGMIl9kA2NE4QDAR42YIUTcoZQgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="341448900" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 19:03:45 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uA1J3iL5003810 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 19:03:45 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 14:03:45 -0500 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; Tue, 1 Nov 2016 14:03:44 -0500 From: "Surendra Kumar (smkumar)" To: "adrian@olddog.co.uk" , "'Dave Dolson'" , "'John E Drake'" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSNGTfytQ8CwTGWE+e5qr3f+KpX6DEyDsAgAACw4CAAALqgP//rQhw Date: Tue, 1 Nov 2016 19:03:44 +0000 Message-ID: <5cc8da2f282243e78c3fef37c93f3326@XCH-RCD-020.cisco.com> References: <026c01d23471$718f9630$54aec290$@olddog.co.uk> In-Reply-To: <026c01d23471$718f9630$54aec290$@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.155.33.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 'Adrian Farrel' , 'Eric Rosen' Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 19:04:30 -0000 There are two aspects to this. 1) Who decrements and 2) By how much For #1) We specified doing this entirely outside the SF, in the SFF here to= not have non-classifying SFs concern with SPI manipulation: https://datatr= acker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/ For #2) I expect a default behavior - to decrement by 1, but allow the cont= rol plane to configure it to a different number, as suggested below. Thanks, Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, November 01, 2016 11:55 AM To: 'Dave Dolson' ; 'John E Drake' ; 'Joel M. Halpern' ; sfc@ietf.org Cc: 'Adrian Farrel' ; 'Eric Rosen' Subject: Re: [sfc] decrementing service function path index Hi Dave, So the thing at question here is "can you support a non-configured chain?" That is, can the "thing" know by how much to decrement the SI without being= configured? Well, certainly making a rule that it MUST decrement by 1 avoids that. But = note that configuration is needed so that the SFF knows how to forward to t= he next hop, so the logical node (i.e. the SF+SFF) has to be configured. We could get further into why the SF does the decrement (not the SFF), or w= e could say that: "The SF is responsible for setting the SI value for the next hop in the SFP= and absent any other information it MUST decrement the SI by 1." If we do that, I can do what I want, and you can do what you want, and ever= ything works fine. And the protocol is undisturbed! Thanks, Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: 01 November 2016 18:45 > To: John E Drake; Joel M. Halpern; sfc@ietf.org > Cc: Adrian Farrel; Eric Rosen > Subject: Re: [sfc] decrementing service function path index >=20 > I had understood the service function must decrement the SI value by=20 > exactly one before returning to the SFF. > (This doesn't require any configuration.) >=20 > Given John's different interpretation, let's make it explicit. >=20 > -Dave >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of John E Drake > Sent: Tuesday, November 01, 2016 2:35 PM > To: Joel M. Halpern; sfc@ietf.org > Cc: Adrian Farrel; Eric Rosen > Subject: Re: [sfc] decrementing service function path index >=20 > Hi, >=20 > 'Decrement' has a very well defined meaning and it is different than 'decrement > by 1'. Given that service function paths need to be defined and=20 > distributed to the > nodes in an SFC network I don't see any reason why that definition=20 > can't include > the SI values. >=20 > This allows a service function path to be modified by either adding or deleting > elements without having to renumber its unaffected portions. >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: Tuesday, November 1, 2016 1:27 PM > > To: sfc@ietf.org > > Subject: [sfc] decrementing service function path index > > > > I was having a discussion (see IDR list) about SFC, and it was=20 > > observed that in > the > > NSH draft we never specify a meaning for "decrement". > > > > While I have assumed a meaning, assumptions are not good for=20 > > interoperable implementations. > > > > Do people understand the current document to require decrementing by=20 > > 1, or > to > > allow a larger decrement? > > > > More importantly, what do we want to say in the spec about this? If=20 > > we want > to > > allow decrement by more than 1, since the SF is doing the decrement,=20 > > we need to talk about the SF being configured to know how much to=20 > > decrement. In my personal opinion, that seems overly complex and fragi= le. > > > > 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 >=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 Tue Nov 1 12:34:46 2016 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 AFA4C129989 for ; Tue, 1 Nov 2016 12:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 DR7SmIS0OOsY for ; Tue, 1 Nov 2016 12:34:43 -0700 (PDT) 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 7240E12997E for ; Tue, 1 Nov 2016 12:34:43 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Tue, 1 Nov 2016 15:34:42 -0400 From: Dave Dolson To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSNGTcgDa3IiYdtkCDma+QNmaeP6DErowAgAABlICAAAr8AP//yVtw Date: Tue, 1 Nov 2016 19:34:41 +0000 Message-ID: References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> In-Reply-To: <026701d23470$6cef2880$46cd7980$@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] decrementing service function path index 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, 01 Nov 2016 19:34:45 -0000 The SF decrements the index so that the SFF doesn't have to look at the pac= ket origin in order to determine whether or not to decrement it. We don't want the SFF to have logic like: If NSH packet is from one of addresses x, y z=20 Decrement SI As currently defined, the SFF simply routes packets by SPI/SI without havin= g to do consider source address. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, November 01, 2016 2:48 PM To: 'Joel M. Halpern'; sfc@ietf.org Subject: Re: [sfc] decrementing service function path index > With regard to the architectural components, the NSH draft does not > define those. It is using the architectural, logical, components and > architecture defined by the SFC Architecture documents. I'd like to understand where in 7665 it says that the SF is responsible for moving the packet on to the next SF in the path, rather than the SFF. I'd also like to understand why the NSH document (that tells us how to encapsulate, and what to do at each hop in the path) needs to divide the responsibility for bits of protocol work between different logical function= al entities. In short, why does the SF decrement the SI, why isn't this an SFF function? What benefit comes from doing it this way or did a choice simply = have to be made? Thanks, Adrian _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 1 13:00:10 2016 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 0D8A51299BB for ; Tue, 1 Nov 2016 13:00:09 -0700 (PDT) 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 u8mSwOI3xobN for ; Tue, 1 Nov 2016 13:00:06 -0700 (PDT) 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 0E9421299B9 for ; Tue, 1 Nov 2016 13:00:05 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1K02In015637; Tue, 1 Nov 2016 20:00:02 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1K01P4015571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 20:00:02 GMT From: "Adrian Farrel" To: "'Dave Dolson'" , "'Joel M. Halpern'" , References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> In-Reply-To: Date: Tue, 1 Nov 2016 19:59:55 -0000 Message-ID: <028701d2347a$850d1fd0$8f275f70$@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: AQIgrbss3hc6CKL2djyaMboulKyfnQG7Sgr8AXzjmREBJLKr8wNKeon+n+pb0EA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22674.002 X-TM-AS-Result: No--14.246-10.0-31-10 X-imss-scan-details: No--14.246-10.0-31-10 X-TMASE-MatchedRID: 6lay9u8oTUMaZ2jc4v9fI6fXIl6Cf6VrO1K5iM8Q6KBtv4+aU05V+2dQ R7oiQr0guBv/D8BB2s2BsGiCnelShfDPsOf70zK9e7MO8jvmPSxlkwUvxRC7B7i7yMDZhOacdO/ tkDTEgyTuBFA2gYmurI1tYtwPvjHZNeyeXkXe6VniHyvyXeXh5rd2noO4P7rAIhbNtFcav8Jq6w Bsju9ij8oLbse3mfom69So477wGF57rjItHwarhcFWmsryu9ZfIgQH9fS2CAaMbDv6XkOHDQhkl Ht5Yr9cRQCOHlKWkB3zdRJMnNkUeM7MWnfHypaG84dsinZ5e1jmMlJFeRgcqbKeTtOdjMy6em0L 3kwJxTfh1HHVB1vZFe0B0WOVOkZHise8Q+yJhnrmAId+2bAQwpJOcXMQc4jBEd+K6O5Nt506W33 UwHDV5uLzNWBegCW2XC3N7C7YzrdWRVlrjsKO8N0H8LFZNFG7bkV4e2xSge7KKTx7WoHDFocwEE DmsQzvL4nlCirQQ8cMAKonIMZLVuulxyHOcPoH Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 20:00:09 -0000 Just clarifying my understanding of what you said (not necessarily agreeing ;-) You are saying that an SFF is simply a forwarder and cannot tell the difference between a packet received on a transport tunnel from another SFF and a packet received (back) from an SF that it serves. Or, more precisely, you are saying that the SFF is simply a forwarder that cannot tell the difference between passing a packet to a local SF and passing a packet on to a remote SFF. And the SFF sees a packet n+1 times for an SFP with n local SFs. Is that your point? Cheers, Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 19:35 > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > The SF decrements the index so that the SFF doesn't have to look at the packet > origin in order to determine whether or not to decrement it. > We don't want the SFF to have logic like: > If NSH packet is from one of addresses x, y z > Decrement SI > > As currently defined, the SFF simply routes packets by SPI/SI without having to > do consider source address. > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, November 01, 2016 2:48 PM > To: 'Joel M. Halpern'; sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > > With regard to the architectural components, the NSH draft does not > > define those. It is using the architectural, logical, components and > > architecture defined by the SFC Architecture documents. > > I'd like to understand where in 7665 it says that the SF is responsible for > moving the packet on to the next SF in the path, rather than the SFF. > > I'd also like to understand why the NSH document (that tells us how to > encapsulate, and what to do at each hop in the path) needs to divide the > responsibility for bits of protocol work between different logical functional > entities. In short, why does the SF decrement the SI, why isn't this an SFF > function? What benefit comes from doing it this way or did a choice simply have > to be made? > > Thanks, > Adrian > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 1 13:26:43 2016 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 3CB361299DC for ; Tue, 1 Nov 2016 13:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 zhBi6jmJaNLw for ; Tue, 1 Nov 2016 13:26:39 -0700 (PDT) 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 7169F1294B8 for ; Tue, 1 Nov 2016 13:26:39 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Tue, 1 Nov 2016 16:26:38 -0400 From: Dave Dolson To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSNGTcgDa3IiYdtkCDma+QNmaeP6DErowAgAABlICAAAr8AP//yVtwgABK1YD//8LesA== Date: Tue, 1 Nov 2016 20:26:37 +0000 Message-ID: References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> In-Reply-To: <028701d2347a$850d1fd0$8f275f70$@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] decrementing service function path index 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, 01 Nov 2016 20:26:41 -0000 Adrian, Thank you for paraphrasing in a clear manner. Yes, I'm saying that the current (as I understand it) design permits the SF= F to be a simple forwarder, not needing to discriminate between packets from another SFF or returning f= rom an SF. A single forwarding table handles both cases. E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 So it could tell the difference, but doesn't need to. In some cases, an SFF can be a single-interface device, so "from SFF" or "f= rom SF" is not as simple=20 as checking ingress interface, for example. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, November 01, 2016 4:00 PM To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: [sfc] decrementing service function path index Just clarifying my understanding of what you said (not necessarily agreeing= ;-) You are saying that an SFF is simply a forwarder and cannot tell the differ= ence between a packet received on a transport tunnel from another SFF and a pack= et received (back) from an SF that it serves. Or, more precisely, you are saying that the SFF is simply a forwarder that cannot tell the difference between passing a packet to a local SF and passi= ng a packet on to a remote SFF. And the SFF sees a packet n+1 times for an SFP with n local SFs. Is that your point? Cheers, Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 19:35 > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > The SF decrements the index so that the SFF doesn't have to look at the p= acket > origin in order to determine whether or not to decrement it. > We don't want the SFF to have logic like: > If NSH packet is from one of addresses x, y z > Decrement SI >=20 > As currently defined, the SFF simply routes packets by SPI/SI without hav= ing to > do consider source address. >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, November 01, 2016 2:48 PM > To: 'Joel M. Halpern'; sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > > With regard to the architectural components, the NSH draft does not > > define those. It is using the architectural, logical, components and > > architecture defined by the SFC Architecture documents. >=20 > I'd like to understand where in 7665 it says that the SF is responsible f= or > moving the packet on to the next SF in the path, rather than the SFF. >=20 > I'd also like to understand why the NSH document (that tells us how to > encapsulate, and what to do at each hop in the path) needs to divide the > responsibility for bits of protocol work between different logical functi= onal > entities. In short, why does the SF decrement the SI, why isn't this an S= FF > function? What benefit comes from doing it this way or did a choice simpl= y have > to be made? >=20 > Thanks, > Adrian >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 1 15:15:07 2016 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 D7B2A1295CD for ; Tue, 1 Nov 2016 15:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.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 BktTG5GE-8lw for ; Tue, 1 Nov 2016 15:15:04 -0700 (PDT) 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 B416E1298C8 for ; Tue, 1 Nov 2016 15:15:02 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id p190so232275096wmp.1 for ; Tue, 01 Nov 2016 15:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=aahxrMT/BlMl9VjLeacBhg0oL7GyrHPshsOawhrw1dQ=; b=mw/aQhFCT5Ta4RgOqKkWbjBgFSwuESFM1juEgmnVZT7sSwW2qalLnMpSyDIgFLWB9K /Pamfg+HuxrrhocuyPLqyFyVkF1YGA3xt/uhXgg6Z6VNRkgAt6En7PDzp/sBOHuarZZh E+I1ykuZccD2JZ3bHAkpB8M17+T1cO4FEj4EFU9OatfgSC1j12Bo9DfjuwJ26Qibu+Ff m+CwJp+Q3d5saK0EGIX0jr7M38XhtXO6kh91hkvT14b5eMBRIGHPBZOEWz9VskMmYA52 iLSS9+zeq48ozZGsIPF0ssG/ryTFJu4lRcm+GQeMtvy5QsPheYPLP7YK74Oqte+uaDow XkqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=aahxrMT/BlMl9VjLeacBhg0oL7GyrHPshsOawhrw1dQ=; b=gp/0yAS2iuKvvX2kqfHhSXe3I1wcnGXzdpcCEtaKCfmoDZ+W2ijlZGM7KPOfF/yFqP 2OjqKSOau0Za1Sf/vK37ha0vUbr8Mj+2VuuLcZ+o99xBTage5+305B9XgWWNk5HsRWq1 sFEFWITGd4FT7HKpFdyupKykRWZgtUK4Z5kKjwQNNWs8J4ns9BXspOZGb4m20Ab1d34p 8AOqs+ouZ6NIfxZMLJvrFCWuVgADdC0U0nrNc3XWqpNzJFLJRSoazklECeEyl4y8JZwz D4i1eAAU3r4nk/yiMGRexipelpomOiPMY2iQJJQNvIwoJOmzPJ8mAS2lbIiW9B8sfrP4 Incg== X-Gm-Message-State: ABUngve9EShafGhmNDEURmDhjlK7GWw3OYBy+5mxBUWgYv9dsXzMwsaRnoH1ra/6+XaZHbpR X-Received: by 10.28.39.67 with SMTP id n64mr124052wmn.68.1478038501236; Tue, 01 Nov 2016 15:15:01 -0700 (PDT) Received: from acorde.lan (85.251.161.16.dyn.user.ono.com. [85.251.161.16]) by smtp.gmail.com with ESMTPSA id ua15sm12433999wjb.1.2016.11.01.15.15.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 01 Nov 2016 15:15:00 -0700 (PDT) Message-ID: <1478038499.6038.11.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Tue, 01 Nov 2016 23:14:59 +0100 In-Reply-To: <5169E6B0-BC21-40DA-9B87-1F78F9A9E2AD@cisco.com> References: <5169E6B0-BC21-40DA-9B87-1F78F9A9E2AD@cisco.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.1-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Call for Seoul SFC WG Agenda Topics X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 22:15:06 -0000 Dear Jim, all, We'd like to request a presentation slot (10 minutes) in Seoul. We have submitted a document [1] about a potential use case for SFC: fog RAN. This document is related to draft-ietf-sfc-use-case-mobility. Thanks, Carlos [1] https://tools.ietf.org/html/draft-bernardos-sfc-fog-ran-00 On Fri, 2016-10-21 at 14:56 +0000, Jim Guichard (jguichar) wrote: > Greetings WG: > > Our meeting in Seoul is fast approaching. As always the goal of the > meeting will be to make the best use of our limited face-to-face > time. With that in mind we welcome requests for agenda time. > > As we build the meeting agenda our goal will be to select > presentations that best further the work of the WG, and that > generally means focusing on key charter deliverables and topics with > important open issues to resolve. When making a request please > consider what you think the WG should do with its content 鈥 for > example: > > - Does the document have useful content that should be moved into > another WG document or progress on its own merit > - Does the content have a good basis for one of the WG documents per > the charter > - Should the document content be merged with one or more other > documents, so that a combined document could become a WG document > > **Please send your request to the SFC chairs until November 4th, 9 am > EST.** > > The request must include the name of the draft or topic to be > presented, time for the presentation requested, and the presenter. > > Thanks, > > Jim, Thomas & Martin > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 1 16:03:45 2016 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 D510D129487 for ; Tue, 1 Nov 2016 16:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 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=-1.497, 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 GdS9me-w4bOU for ; Tue, 1 Nov 2016 16:03:42 -0700 (PDT) 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 083E812943A for ; Tue, 1 Nov 2016 16:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4880; q=dns/txt; s=iport; t=1478041422; x=1479251022; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=v35wG4NkD80PTmNVQJn5ARgfdn9HVcGKx7n0Q/rKbFQ=; b=JJ9Iv23/7F1ggEtRW061NR1Ao5FuBiQjh2sVl4nZ8g7CslpKzJa98w1l gGBZNITzdDeSyOOqgh5Ab9F4xfUueNL0pd/3/HLRn3sm5x4hLFWwx9B+j Lr1oF+vMVOU1QrPGZSg7X6zkjRUAHt82u47EQHPG5aD3gwCakzTvpLRGN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQATHxlY/4wNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfAeNL5cAlEWCBx0LhXoCghY/FAECAQEBAQEBAWIohGE?= =?us-ascii?q?BAQEEAQEBNzQXBAIBCA4DAQMBAR8JBycLFAMGCAIEARIIiEwOuC4BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEcixKKJwWEBJYWAYk5hnSQDY0ThAMBHjZggyQcgVNyhlC?= =?us-ascii?q?BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,433,1473120000"; d="scan'208";a="169986446" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2016 23:03:41 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uA1N3efM010118 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 23:03:41 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 18:03:40 -0500 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; Tue, 1 Nov 2016 18:03:40 -0500 From: "Surendra Kumar (smkumar)" To: Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSNGTfytQ8CwTGWE+e5qr3f+KpX6DEv08AgAABlICAAAr8AIAADSOAgAAHDYCAAAd2gP//0rAQ Date: Tue, 1 Nov 2016 23:03:40 +0000 Message-ID: <3d08c8a3d82a445bb6d12d3bf52bde13@XCH-RCD-020.cisco.com> References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@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-transport-fromentityheader: Hosted x-originating-ip: [10.155.33.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 23:03:44 -0000 Since the forwarders already exists, they are logical components to support= and perform NSH based forwarding - forwarding on SFPs, rather than treat t= hem as dumb forwarders. There is benefit to be had, offloads being one of t= hem, on top of end of chain forwarding, etc. needed. I would rather have SFs focus on servicing the traffic than be burdened wit= h SPI management (whether it is tens or thousands of SPIs) and the forwardi= ng thereof. IOW, consume metadata and service traffic and leave the SFP man= agement to the external forwarders. This not only simplifies the SFs, it al= so reduces the control plane touch point as it concerns to the SPI manageme= nt. And you don't need complex logic to differentiate between traffic received = from one SFF or a SF, this is what we addressed in the forwarding draft - t= rivial to implement even in hardware. Thanks,=20 Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Tuesday, November 01, 2016 1:27 PM To: adrian@olddog.co.uk; 'Joel M. Halpern' ; sfc@ietf.= org Subject: Re: [sfc] decrementing service function path index Adrian, Thank you for paraphrasing in a clear manner. Yes, I'm saying that the current (as I understand it) design permits the SF= F to be a simple forwarder, not needing to discriminate between packets fro= m another SFF or returning from an SF. A single forwarding table handles both cases. E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 So it could tell the difference, but doesn't need to. In some cases, an SFF can be a single-interface device, so "from SFF" or "f= rom SF" is not as simple as checking ingress interface, for example. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, November 01, 2016 4:00 PM To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: [sfc] decrementing service function path index Just clarifying my understanding of what you said (not necessarily agreeing= ;-) You are saying that an SFF is simply a forwarder and cannot tell the differ= ence between a packet received on a transport tunnel from another SFF and a pack= et received (back) from an SF that it serves. Or, more precisely, you are saying that the SFF is simply a forwarder that cannot tell the difference between passing a packet to a local SF and passi= ng a packet on to a remote SFF. And the SFF sees a packet n+1 times for an SFP with n local SFs. Is that your point? Cheers, Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 19:35 > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > The SF decrements the index so that the SFF doesn't have to look at the p= acket > origin in order to determine whether or not to decrement it. > We don't want the SFF to have logic like: > If NSH packet is from one of addresses x, y z > Decrement SI >=20 > As currently defined, the SFF simply routes packets by SPI/SI without hav= ing to > do consider source address. >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, November 01, 2016 2:48 PM > To: 'Joel M. Halpern'; sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > > With regard to the architectural components, the NSH draft does not > > define those. It is using the architectural, logical, components and > > architecture defined by the SFC Architecture documents. >=20 > I'd like to understand where in 7665 it says that the SF is responsible f= or > moving the packet on to the next SF in the path, rather than the SFF. >=20 > I'd also like to understand why the NSH document (that tells us how to > encapsulate, and what to do at each hop in the path) needs to divide the > responsibility for bits of protocol work between different logical functi= onal > entities. In short, why does the SF decrement the SI, why isn't this an S= FF > function? What benefit comes from doing it this way or did a choice simpl= y have > to be made? >=20 > Thanks, > Adrian >=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 Tue Nov 1 16:09:23 2016 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 87BD81294B3 for ; Tue, 1 Nov 2016 16:09:21 -0700 (PDT) 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 41NO6DL9RkRf for ; Tue, 1 Nov 2016 16:09:19 -0700 (PDT) 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 C0B16129487 for ; Tue, 1 Nov 2016 16:09:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1N9Eva009365; Tue, 1 Nov 2016 23:09:14 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA1N9Ctv009355 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 23:09:13 GMT From: "Adrian Farrel" To: "'Surendra Kumar \(smkumar\)'" , "'Dave Dolson'" , "'Joel M. Halpern'" , References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <3d08c8a3d82a445bb6d12d3bf52bde13@XCH-RCD-020.cisco.com> In-Reply-To: <3d08c8a3d82a445bb6d12d3bf52bde13@XCH-RCD-020.cisco.com> Date: Tue, 1 Nov 2016 23:09:05 -0000 Message-ID: <02d801d23494$f2ecb910$d8c62b30$@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: AQIgrbss3hc6CKL2djyaMboulKyfnQG7Sgr8AXzjmREBJLKr8wNKeon+AeVOae4Bj9QfJANUW3sHn7RHPYA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22674.003 X-TM-AS-Result: No--36.160-10.0-31-10 X-imss-scan-details: No--36.160-10.0-31-10 X-TMASE-MatchedRID: Rp71wniPtoOnykMun0J1wqfXIl6Cf6VrWzrNDQlnopO2ouCVA4y4hcLm p4jPUF8t4bw3qGt9FmCql22yJrFTEnz5lEEBuvacVU3yVpaj3QzjZVW6jxrColpbYq2f4jz+gig UN2900pYQQBchBQfS1BO/SdprKdAhyDnSHyuYrR6628cXbnOhT3/0yDqj7AyLMLk1AGUYTYtaDb uHVL621FMp76wi2RkBf5IDZAYYihDHSssK+vO2mZ21GZGE81yGCQ3xS+zL6e1yB8ETkOc/wxXx6 Ns80rLo5seX3emR8UokOZlozX424FlP3wf1xZiclUgQqGVMqmzomPrNi98UBH5h6y4KCSJcY4EN C/ULveTHlv4ThFcixRWsRvtG4mXEQDSWm8bJmzJ7sw7yO+Y9LGWTBS/FELsHuLvIwNmE5pzbNQh 85GhqIu4EUDaBia6sjW1i3A++MdkVLX6oLGmWi+IfK/Jd5eHmfjJOgArMOCYoFW8VuxQzlTAl1y 8YMtiUCLs7K4O4o3SN+Iq380gE0v0h1gfJr9xBcFEiuPxHjsVimi8LvNfmr83pmMQVlfYp07zaV ZEg+DPpNMXF2na7y8mCsOeJe4JXgwVIY/GSpTupuD25aEtgt3WT6A/Vdqa0myiLZetSf8nJ4y0w P1A6AB8AKgKWeNGhKVv+AHCw0Uqx5amWK2anSPoLR4+zsDTtAqYBE3k9Mpw= Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 23:09:21 -0000 Thanks Surendra, You said it better than me. I don't mind if an SF also munges with the NSH, but I think it is wrong to say: - the SFF MUST NOT - the SF MUST munge in a specific way. A > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: 01 November 2016 23:04 > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Since the forwarders already exists, they are logical components to support and > perform NSH based forwarding - forwarding on SFPs, rather than treat them as > dumb forwarders. There is benefit to be had, offloads being one of them, on top > of end of chain forwarding, etc. needed. > > I would rather have SFs focus on servicing the traffic than be burdened with SPI > management (whether it is tens or thousands of SPIs) and the forwarding > thereof. IOW, consume metadata and service traffic and leave the SFP > management to the external forwarders. This not only simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI management. > > And you don't need complex logic to differentiate between traffic received from > one SFF or a SF, this is what we addressed in the forwarding draft - trivial to > implement even in hardware. > > Thanks, > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ; > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Adrian, > Thank you for paraphrasing in a clear manner. > > Yes, I'm saying that the current (as I understand it) design permits the SFF to be a > simple forwarder, not needing to discriminate between packets from another > SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=x, send to SF1; when SI=x+1, send to SFF2 > > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF" or "from SF" > is not as simple as checking ingress interface, for example. > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > Just clarifying my understanding of what you said (not necessarily agreeing ;-) > > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a packet > received (back) from an SF that it serves. > > Or, more precisely, you are saying that the SFF is simply a forwarder that > cannot tell the difference between passing a packet to a local SF and passing a > packet on to a remote SFF. > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > Is that your point? > > Cheers, > Adrian > > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does not > > > define those. It is using the architectural, logical, components and > > > architecture defined by the SFC Architecture documents. > > > > I'd like to understand where in 7665 it says that the SF is responsible for > > moving the packet on to the next SF in the path, rather than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how to > > encapsulate, and what to do at each hop in the path) needs to divide the > > responsibility for bits of protocol work between different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this an SFF > > function? What benefit comes from doing it this way or did a choice simply > have > > to be made? > > > > 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 From nobody Tue Nov 1 16:22:00 2016 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 7A6741295AB for ; Tue, 1 Nov 2016 16:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 ymseSp02a9J4 for ; Tue, 1 Nov 2016 16:21:56 -0700 (PDT) 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 7E93D129459 for ; Tue, 1 Nov 2016 16:21:56 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Tue, 1 Nov 2016 19:21:55 -0400 From: Dave Dolson To: "Surendra Kumar (smkumar)" , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSNGTcgDa3IiYdtkCDma+QNmaeP6DErowAgAABlICAAAr8AP//yVtwgABK1YD//8LesIAAcHgA///CCuM= Date: Tue, 1 Nov 2016 23:21:53 +0000 Message-ID: <20161101232153.5697621.61192.116340@sandvine.com> References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> , <3d08c8a3d82a445bb6d12d3bf52bde13@XCH-RCD-020.cisco.com> In-Reply-To: <3d08c8a3d82a445bb6d12d3bf52bde13@XCH-RCD-020.cisco.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 01 Nov 2016 23:21:58 -0000 I agree that the SF should be simple. But don't confuse decrementing the SI with complexity. There is absolutely no configuration required to have the SF decrement the = SI of every packet. And there is a lot of benefit to keeping the SFF from having rules about pa= cket source. As far as I'm concerned, the SF decrements the SI, and it has been describe= d this way for a long time. Furthermore, the forwarding is described as a l= ookup table based on SPI/SI. There is no mention of the source in the forwa= rding table. Original Message From: Surendra Kumar (smkumar) Sent: Tuesday, November 1, 2016 7:03 PM To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: [sfc] decrementing service function path index Since the forwarders already exists, they are logical components to support= and perform NSH based forwarding - forwarding on SFPs, rather than treat t= hem as dumb forwarders. There is benefit to be had, offloads being one of t= hem, on top of end of chain forwarding, etc. needed. I would rather have SFs focus on servicing the traffic than be burdened wit= h SPI management (whether it is tens or thousands of SPIs) and the forwardi= ng thereof. IOW, consume metadata and service traffic and leave the SFP man= agement to the external forwarders. This not only simplifies the SFs, it al= so reduces the control plane touch point as it concerns to the SPI manageme= nt. And you don't need complex logic to differentiate between traffic received = from one SFF or a SF, this is what we addressed in the forwarding draft - t= rivial to implement even in hardware. Thanks, Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Tuesday, November 01, 2016 1:27 PM To: adrian@olddog.co.uk; 'Joel M. Halpern' ; sfc@ietf.= org Subject: Re: [sfc] decrementing service function path index Adrian, Thank you for paraphrasing in a clear manner. Yes, I'm saying that the current (as I understand it) design permits the SF= F to be a simple forwarder, not needing to discriminate between packets fro= m another SFF or returning from an SF. A single forwarding table handles both cases. E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 So it could tell the difference, but doesn't need to. In some cases, an SFF can be a single-interface device, so "from SFF" or "f= rom SF" is not as simple as checking ingress interface, for example. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 4:00 PM To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: [sfc] decrementing service function path index Just clarifying my understanding of what you said (not necessarily agreeing= ;-) You are saying that an SFF is simply a forwarder and cannot tell the differ= ence between a packet received on a transport tunnel from another SFF and a pack= et received (back) from an SF that it serves. Or, more precisely, you are saying that the SFF is simply a forwarder that cannot tell the difference between passing a packet to a local SF and passi= ng a packet on to a remote SFF. And the SFF sees a packet n+1 times for an SFP with n local SFs. Is that your point? Cheers, Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 19:35 > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > The SF decrements the index so that the SFF doesn't have to look at the p= acket > origin in order to determine whether or not to decrement it. > We don't want the SFF to have logic like: > If NSH packet is from one of addresses x, y z > Decrement SI > > As currently defined, the SFF simply routes packets by SPI/SI without hav= ing to > do consider source address. > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, November 01, 2016 2:48 PM > To: 'Joel M. Halpern'; sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > > With regard to the architectural components, the NSH draft does not > > define those. It is using the architectural, logical, components and > > architecture defined by the SFC Architecture documents. > > I'd like to understand where in 7665 it says that the SF is responsible f= or > moving the packet on to the next SF in the path, rather than the SFF. > > I'd also like to understand why the NSH document (that tells us how to > encapsulate, and what to do at each hop in the path) needs to divide the > responsibility for bits of protocol work between different logical functi= onal > entities. In short, why does the SF decrement the SI, why isn't this an S= FF > function? What benefit comes from doing it this way or did a choice simpl= y have > to be made? > > 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 From nobody Tue Nov 1 18:52:20 2016 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 A6F4A1293F4 for ; Tue, 1 Nov 2016 18:52:19 -0700 (PDT) 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 TW8Vu1rzSkBY for ; Tue, 1 Nov 2016 18:52:16 -0700 (PDT) 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 3E158120726 for ; Tue, 1 Nov 2016 18:52:16 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA21qA2B005604; Wed, 2 Nov 2016 01:52:10 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA21q9v6005594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 2 Nov 2016 01:52:10 GMT From: "Adrian Farrel" To: "'Dave Dolson'" , "'Surendra Kumar \(smkumar\)'" , "'Joel M. Halpern'" , Date: Wed, 2 Nov 2016 01:52:04 -0000 Message-ID: <02e601d234ab$b69648c0$23c2da40$@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: AdI0q6STRZCLqSXLQzOUvbtSwnTj2A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22674.004 X-TM-AS-Result: No--28.836-10.0-31-10 X-imss-scan-details: No--28.836-10.0-31-10 X-TMASE-MatchedRID: 0ms9ZPk71Ir8OkSa7MC2+7AcrYExeE002sEGsaoEZ+WRfqKA4oV+e3hE dmuwBgpiWyV8VgHh4RPOgXE6r4gNc2gAguu6mUCqw2taljzThMb68oZ4wywtCq2PbheqHTJcH2f 3OLcqE221RfQogczQlrdsDGMuQxNXYqmUd3tOErVVTfJWlqPdDJZ6zKu0q4rtv6ISTfKYVkagt4 bI+KwqnVw0YJSZ5iu6x7olxEwxT+LcDD2L0Ps8bC4uTw19Klh6Noanwssvalntbk+IjHppmurOS EJRBEaXaK+ZoqLQjle5u5xq5rpm435iF3J6dlPP1QWGBM/v9tZhBfGxmdHCgmw6YPA9kjhwpZkF xNdtI051L+X18ZczPZY4iAiVNRMU7K35r0y1/56cgbKevk5shudIlGzDlIXiiIOsL5jCm+gF17c PlENBU/9pdOoMPfsYTforx7J8D4A8c+bQ4YQ9BszWN98iBBeGd4LzQ5cJCvMU/vlp1PIMiRSAtq 43EFwm74sPlTuDCYKLpL6IjROswQVnfa7xoeysdFIm3orOnRBfohHCqSnabkklF5L0lQHcZpoEq FgnM0yEmmFz+RIbZurPDBxL/oFish0UtarsT5PcWo5Vvs8MQlHB9PagRph0qPm/sjj9KBgK1Ng+ lpSQpctshBV8Ef5ZqnFrYA9j2T9oUepsgExzz5RrnSy7UTtbncKJki+ooR0kt9BigJAcVugYWcI 4QZwHquWeodkTMpMPIIYTdT+JZ5ya2tEru0x76Zzj+kMRBrb6rVj794QCtrepDvmFKVfY2zUIfO RoaiLuBFA2gYmurI1tYtwPvjHZFS1+qCxploueAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47gsv7zZO iFab6ebHCxzBV4T3QfwsVk0UbslCGssfkpInQ== Archived-At: Subject: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 02 Nov 2016 01:52:20 -0000 Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product like this." But they are real rat-holes. What we need is a set of rule that work for simple implementations *and* that do not preclude more sophisticated implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next hop on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leave the SPI unchanged and to decrement the SI by 1. However, and SF MAY know to make other changes to a the SPI and SI. How that knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF back to SFF so that the SPI/SI received by the SFF is not a simple decrement of the SI. There may be a classifier co-resident with the SFF that processes the packet before the SFF performs forwarding so that the SPI/SI received by the SFF is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to send the packet for the given SPI/SI. How it resolves this choice is a local matter (some policy that might be load balancing and could be influenced by any manner of things if an implementation chooses without prejudice to the interoperability of replaceability of SFFs). The fact of the choice is a function of how the network has been built, and how SFIs have been assigned, and how the SFPs have been constructed by the controller - it is not a function of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send the packet out of interface X encapsulated in tunnel Y) or more complex (make some form of choice and manipulate the packet) just as in most other modern forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state for it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what the WG wanted to achieve with the NSH draft without requiring any limitation on processing. That is, a simple implementation as envisaged by the proponents of "MUST decrement by one" is able to perform that function and still be conformant and interoperable. Similarly, a simple SFF as suggested in this thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and implementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) and allows a control plane to program an SFF to do more sophisticated things. Of course, if the SFF cannot do those things then that will be OK since it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 section 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with an SPI and SI for which it does not have forwarding state, it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either ambiguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in Section 4. 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern'; > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules about packet > source. > > As far as I'm concerned, the SF decrements the SI, and it has been described this > way for a long time. Furthermore, the forwarding is described as a lookup table > based on SPI/SI. There is no mention of the source in the forwarding table. > > > > > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Since the forwarders already exists, they are logical components to support and > perform NSH based forwarding - forwarding on SFPs, rather than treat them as > dumb forwarders. There is benefit to be had, offloads being one of them, on top > of end of chain forwarding, etc. needed. > > I would rather have SFs focus on servicing the traffic than be burdened with SPI > management (whether it is tens or thousands of SPIs) and the forwarding > thereof. IOW, consume metadata and service traffic and leave the SFP > management to the external forwarders. This not only simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI management. > > And you don't need complex logic to differentiate between traffic received from > one SFF or a SF, this is what we addressed in the forwarding draft - trivial to > implement even in hardware. > > Thanks, > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ; > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Adrian, > Thank you for paraphrasing in a clear manner. > > Yes, I'm saying that the current (as I understand it) design permits the SFF to be a > simple forwarder, not needing to discriminate between packets from another > SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=x, send to SF1; when SI=x+1, send to SFF2 > > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF" or "from SF" > is not as simple as checking ingress interface, for example. > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > Just clarifying my understanding of what you said (not necessarily agreeing ;-) > > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a packet > received (back) from an SF that it serves. > > Or, more precisely, you are saying that the SFF is simply a forwarder that > cannot tell the difference between passing a packet to a local SF and passing a > packet on to a remote SFF. > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > Is that your point? > > Cheers, > Adrian > > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does not > > > define those. It is using the architectural, logical, components and > > > architecture defined by the SFC Architecture documents. > > > > I'd like to understand where in 7665 it says that the SF is responsible for > > moving the packet on to the next SF in the path, rather than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how to > > encapsulate, and what to do at each hop in the path) needs to divide the > > responsibility for bits of protocol work between different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this an SFF > > function? What benefit comes from doing it this way or did a choice simply > have > > to be made? > > > > 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 From nobody Tue Nov 1 23:33:59 2016 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 CBE4D1293F2 for ; Tue, 1 Nov 2016 23:33:56 -0700 (PDT) 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, 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 jH7ODxzdE8I9 for ; Tue, 1 Nov 2016 23:33:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919861294BD for ; Tue, 1 Nov 2016 23:33:53 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id ADA4B3B433B; Wed, 2 Nov 2016 07:33:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8A3BC27C086; Wed, 2 Nov 2016 07:33:51 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 07:33:51 +0100 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Progressing of NSH metadata drafts Thread-Index: AQHSMSq4xIKE2v4eREaE/CUJATlZOaDFQtNg Date: Wed, 2 Nov 2016 06:33:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009D9C7BA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <2A921CE4-6500-4984-9F40-487AB33C0A99@cisco.com> In-Reply-To: <2A921CE4-6500-4984-9F40-487AB33C0A99@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.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009D9C7BAOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.2.54516 Archived-At: Subject: Re: [sfc] Progressing of NSH metadata drafts 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, 02 Nov 2016 06:33:57 -0000 --_000_787AE7BB302AE849A7480A190F8B933009D9C7BAOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLA0KDQpDYW4geW91IHBsZWFzZSBhZGQgdGhpcyBkcmFmdCB0byB0aGUgY2FuZGlkYXRl IFdHIGRvY3VtZW50czogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhcmlrYXlh LXNmYy1ob3N0aWQtc2VydmljZWhlYWRlci0wMz8NCg0KKEkgd2FzIHVuYWJsZSB0byBhdHRlbmQg dGhlIGludGVyaW0gbWVldGluZyB0byB2b2ljZSBmb3IgdGhpcykuDQoNClRoYW5rIHlvdS4NCg0K Q2hlZXJzLA0KTWVkDQoNCkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERl IGxhIHBhcnQgZGUgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNCkVudm95w6kgOiB2ZW5kcmVkaSAy OCBvY3RvYnJlIDIwMTYgMTY6NTENCsOAIDogc2ZjQGlldGYub3JnDQpPYmpldCA6IFtzZmNdIFBy b2dyZXNzaW5nIG9mIE5TSCBtZXRhZGF0YSBkcmFmdHMNCg0KDQpEZWFyIFNGQyBXRzoNCg0KDQoN ClRoYW5rIHlvdSB0byB0aG9zZSB0aGF0IHdlcmUgYWJsZSB0byBhdHRlbmQgb3VyIHJlY2VudCBp bnRlcmltIG1lZXRpbmcuDQoNCg0KDQpPbmUgb2YgdGhlIHRvcGljcyB3ZSBpbnZlc3RpZ2F0ZWQg d2FzIGhvdyB0byBwcm9ncmVzcyBkcmFmdHMgb24gbWV0YWRhdGEgd2l0aGluIHRoZSBXRy4gQXMg YSBXRyB3ZSByZWFsbHkgbmVlZCB0byBtYWtlIHByb2dyZXNzIGluIHRoaXMgYXJlYS4NCg0KDQoN CldlIGhhZCBhIGxpdmVseSBkaXNjdXNzaW9uIGFyb3VuZCBib3RoIHR5cGUtMSBhbmQgdHlwZS0y IG1ldGFkYXRhLg0KDQoNCg0KQXQgdGhlIGludGVyaW0gbWVldGluZyB3ZSByZWFjaGVkIGEgZ2Vu ZXJhbCBhZ3JlZW1lbnQgdGhhdCB3ZSBzaG91bGQgYWRvcHQgc29tZSBvZiB0aGUgdHlwZS0xIGFs bG9jYXRpb24gZG9jdW1lbnRzIChpbml0aWFsbHkgdGhlIERDIGFuZCBNb2JpbGl0eSBhbGxvY2F0 aW9ucykgYW5kIHdvcmsgdG93YXJkIFdHIGNvbnNlbnN1cyBvbiB0aGUgZm9ybWF0cy4gV2hpbGUg dGhlcmUgd2FzIGRpc2N1c3Npb24gb24gd2hldGhlciB0aGVzZSBkb2N1bWVudHMgc2hvdWxkIGJl IGluZm9ybWF0aW9uYWwgb3Igc3RhbmRhcmRzIHRyYWNrLCB3ZSBhZ3JlZWQgdG8gaW5pdGlhbGx5 IGFkb3B0IHRoZW0gYXMgaW5mb3JtYXRpb25hbCBhbmQgbW92ZSB0byBhIGRpZmZlcmVudCB0cmFj ayBpZiB0aGUgV0cgZGVjaWRlcyB0aGF0IGlzIGFwcHJvcHJpYXRlIGluIHRoZSBmdXR1cmUuDQoN Cg0KDQpXZSBhbHNvIHJlYWNoZWQgYSBnZW5lcmFsIGFncmVlbWVudCB0aGF0IHdlIHNob3VsZCBj YWxsIGZvciB0aGUgYWRvcHRpb24gb2YgdGhlIHR5cGUtMiBUTFYgcmVnaXN0cnkgZG9jdW1lbnQg KGRyYWZ0LXF1aW5uLXNmYy1uc2gtdGx2KS4NCg0KDQoNClRoZSBjaGFpcnMgd291bGQgbGlrZSB0 byBlbXBoYXNpcyB0aGF0IHRoZXNlIGFncmVlbWVudHMgd2VyZSBwcmVsaW1pbmFyeSBhcyBub3Qg YWxsIGludGVyZXN0ZWQgcGFydGllcyB3ZXJlIGluIGF0dGVuZGFuY2UgYXQgdGhlIGludGVyaW0g bWVldGluZy4gVGhlcmVmb3JlLCBpZiB0aGVyZSBhcmUgb2JqZWN0aW9ucyBvciBhZ3JlZW1lbnQg dG8gdGhpcyBwYXRoIGZvcndhcmQsIHBsZWFzZSBkbyBpbmRpY2F0ZSBhcyBzdWNoIG9uIHRoZSBt YWlsaW5nIGxpc3QuIElmIHRoZXJlIGFyZSBubyBzdWJzdGFudGl2ZSBvYmplY3Rpb25zLCB0aGUg Y2hhaXJzIHdpbGwgc2VuZCBzZXBhcmF0ZSBlbWFpbHMgc2hvcnRseSB0byByZXF1ZXN0IGFkb3B0 aW9uIG9mIHRoZXNlIGRyYWZ0cy4gUGxlYXNlIGxvb2sgb3V0IGZvciB0aGVtIGFuZCBpbmRpY2F0 ZSBvbiB0aGUgbWFpbGluZyBsaXN0IHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24sIGFuZCBp ZiBub3QsIHdoeS4NCg0KDQoNCkppbQ0K --_000_787AE7BB302AE849A7480A190F8B933009D9C7BAOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6Ymxh Y2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgSmltLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DYW4geW91IHBs ZWFzZSBhZGQgdGhpcyBkcmFmdCB0byB0aGUgY2FuZGlkYXRlIFdHIGRvY3VtZW50czoNCjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYXJpa2F5YS1zZmMtaG9zdGlk LXNlcnZpY2VoZWFkZXItMDMiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNh cmlrYXlhLXNmYy1ob3N0aWQtc2VydmljZWhlYWRlci0wMzwvYT4/IDxvOnA+DQo8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPihJIHdhcyB1bmFibGUgdG8gYXR0 ZW5kIHRoZSBpbnRlcmltIG1lZXRpbmcgdG8gdm9pY2UgZm9yIHRoaXMpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwv Yj4gSmltIEd1aWNoYXJkIChqZ3VpY2hhcik8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gdmVu ZHJlZGkgMjggb2N0b2JyZSAyMDE2IDE2OjUxPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBzZmNAaWV0 Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtzZmNdIFByb2dyZXNzaW5nIG9mIE5TSCBt ZXRhZGF0YSBkcmFmdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgU0ZDIFdHOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtt aW4taGVpZ2h0OiAxNHB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlRoYW5rIHlvdSB0byB0aG9zZSB0aGF0IHdlcmUgYWJsZSB0byBhdHRlbmQgb3VyIHJlY2Vu dCBpbnRlcmltIG1lZXRpbmcuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O21pbi1oZWlnaHQ6IDE0cHgiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T25lIG9mIHRoZSB0b3BpY3Mg d2UgaW52ZXN0aWdhdGVkIHdhcyBob3cgdG8gcHJvZ3Jlc3MgZHJhZnRzIG9uIG1ldGFkYXRhIHdp dGhpbiB0aGUgV0cuIEFzIGEgV0cgd2UgcmVhbGx5IG5lZWQgdG8gbWFrZSBwcm9ncmVzcyBpbiB0 aGlzDQogYXJlYS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bWluLWhlaWdodDogMTRweCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XZSBoYWQgYSBsaXZlbHkgZGlzY3Vzc2lv biBhcm91bmQgYm90aCB0eXBlLTEgYW5kIHR5cGUtMiBtZXRhZGF0YS4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7 bWluLWhlaWdodDogMTRweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5BdCB0aGUgaW50ZXJpbSBtZWV0aW5nIHdlIHJlYWNoZWQgYSBnZW5lcmFsIGFncmVlbWVu dCB0aGF0IHdlIHNob3VsZCBhZG9wdCBzb21lIG9mIHRoZSB0eXBlLTEgYWxsb2NhdGlvbiBkb2N1 bWVudHMgKGluaXRpYWxseSB0aGUgREMgYW5kDQogTW9iaWxpdHkgYWxsb2NhdGlvbnMpIGFuZCB3 b3JrIHRvd2FyZCBXRyBjb25zZW5zdXMgb24gdGhlIGZvcm1hdHMuIFdoaWxlIHRoZXJlIHdhcyBk aXNjdXNzaW9uIG9uIHdoZXRoZXIgdGhlc2UgZG9jdW1lbnRzIHNob3VsZCBiZSBpbmZvcm1hdGlv bmFsIG9yIHN0YW5kYXJkcyB0cmFjaywgd2UgYWdyZWVkIHRvIGluaXRpYWxseSBhZG9wdCB0aGVt IGFzIGluZm9ybWF0aW9uYWwgYW5kIG1vdmUgdG8gYSBkaWZmZXJlbnQgdHJhY2sgaWYgdGhlIFdH DQogZGVjaWRlcyB0aGF0IGlzIGFwcHJvcHJpYXRlIGluIHRoZSBmdXR1cmUuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAw MXB0O21pbi1oZWlnaHQ6IDE0cHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNt O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+V2UgYWxzbyByZWFjaGVkIGEgZ2VuZXJhbCBhZ3JlZW1lbnQgdGhhdCB3ZSBzaG91 bGQgY2FsbCBmb3IgdGhlIGFkb3B0aW9uIG9mIHRoZSB0eXBlLTIgVExWIHJlZ2lzdHJ5IGRvY3Vt ZW50IChkcmFmdC1xdWlubi1zZmMtbnNoLXRsdikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O21pbi1oZWlnaHQ6IDE0cHgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIGNoYWlycyB3 b3VsZCBsaWtlIHRvIGVtcGhhc2lzIHRoYXQgdGhlc2UgYWdyZWVtZW50cyB3ZXJlIHByZWxpbWlu YXJ5IGFzIG5vdCBhbGwgaW50ZXJlc3RlZCBwYXJ0aWVzIHdlcmUgaW4gYXR0ZW5kYW5jZSBhdCB0 aGUgaW50ZXJpbQ0KIG1lZXRpbmcuIFRoZXJlZm9yZSwgaWYgdGhlcmUgYXJlIG9iamVjdGlvbnMg b3IgYWdyZWVtZW50IHRvIHRoaXMgcGF0aCBmb3J3YXJkLCBwbGVhc2UgZG8gaW5kaWNhdGUgYXMg c3VjaCBvbiB0aGUgbWFpbGluZyBsaXN0LiBJZiB0aGVyZSBhcmUgbm8gc3Vic3RhbnRpdmUgb2Jq ZWN0aW9ucywgdGhlIGNoYWlycyB3aWxsIHNlbmQgc2VwYXJhdGUgZW1haWxzIHNob3J0bHkgdG8g cmVxdWVzdCBhZG9wdGlvbiBvZiB0aGVzZSBkcmFmdHMuIFBsZWFzZQ0KIGxvb2sgb3V0IGZvciB0 aGVtIGFuZCBpbmRpY2F0ZSBvbiB0aGUgbWFpbGluZyBsaXN0IHdoZXRoZXIgeW91IHN1cHBvcnQg YWRvcHRpb24sIGFuZCBpZiBub3QsIHdoeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SmltPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933009D9C7BAOPEXCLILMA3corp_-- From nobody Tue Nov 1 23:50:44 2016 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 EFB34129544; Tue, 1 Nov 2016 23:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.097 X-Spam-Level: X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, 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 KLMHqIP-az8n; Tue, 1 Nov 2016 23:50:42 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5765212950D; Tue, 1 Nov 2016 23:50:42 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id B1363180303; Wed, 2 Nov 2016 07:50:40 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 87EF41A005F; Wed, 2 Nov 2016 07:50:40 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 07:50:40 +0100 From: To: "adrian@olddog.co.uk" , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.txt Thread-Index: AdI0YNSia0oWGMevSXyHlqL96d0UCAAc/LeQ Date: Wed, 2 Nov 2016 06:50:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009D9C7D1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <022801d23460$e2609190$a721b4b0$@olddog.co.uk> In-Reply-To: <022801d23460$e2609190$a721b4b0$@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: Cc: "draft-mackie-bess-nsh-bgp-control-plane@ietf.org" Subject: Re: [sfc] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.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, 02 Nov 2016 06:50:44 -0000 Hi Adrian, Thank you for sharing the draft.=20 While it is true that the SFC Data Plane architecture is defined in RFC 766= 5, an SFC Control Plane architecture is defined in another document: https:= //tools.ietf.org/html/draft-ietf-sfc-control-plane-08. As I don't see it explained in your draft, can you please position this sol= ution with regards to the SFC Control Architecture, especially indicate whi= ch control interface you are targeting?=20 Thank you. Cheers, Med=20 > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > Envoy=E9=A0: mardi 1 novembre 2016 17:56 > =C0=A0: sfc@ietf.org > Cc=A0: draft-mackie-bess-nsh-bgp-control-plane@ietf.org > Objet=A0: [sfc] FW: New Version Notification for draft-mackie-bess-nsh-bg= p- > control-plane-01.txt >=20 > Hi SFC WG, >=20 > You may be interested in this draft. It provides a BGP control pane for a= n > (NSH-enabled) SFC network. >=20 > Currently the document is being discussed on the BESS mailing list which, > from > reading the charters, is where it belongs. >=20 > Thanks, > Adrian >=20 > > -----Original Message----- > > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: 30 October 2016 16:19 > > To: bess@ietf.org > > Subject: [bess] FW: New Version Notification for draft-mackie-bess-nsh- > bgp- > > control-plane-01.txt > > > > Hi Bess WG, > > > > We made some updates to this document to tidy it and to get the > terminology in > > line with RFC 7665. > > > > Adrian > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: 30 October 2016 16:09 > > > To: Eric Rosen; Adrian Farrel; John Drake; Jim Uttaro; Luay Jalil > > > Subject: New Version Notification for draft-mackie-bess-nsh-bgp- > control- > > plane- > > > 01.txt > > > > > > > > > A new version of I-D, draft-mackie-bess-nsh-bgp-control-plane-01.txt > > > has been successfully submitted by Adrian Farrel and posted to the > > > IETF repository. > > > > > > Name: draft-mackie-bess-nsh-bgp-control-plane > > > Revision: 01 > > > Title: BGP Control Plane for NSH SFC > > > Document date: 2016-10-30 > > > Group: Individual Submission > > > Pages: 37 > > > URL: > https://www.ietf.org/internet-drafts/draft-mackie-bess-nsh-bgp- > > > control-plane-01.txt > > > Status: https://datatracker.ietf.org/doc/draft-mackie-bess- > nsh-bgp- > > control- > > > plane/ > > > Htmlized: > https://tools.ietf.org/html/draft-mackie-bess-nsh-bgp-control- > > > plane-01 > > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mackie-bess= - > nsh-bgp- > > control- > > > plane-01 > > > > > > 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. > > > > > > > > > > > > > > > > > > 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 > > > > _______________________________________________ > > BESS mailing list > > BESS@ietf.org > > https://www.ietf.org/mailman/listinfo/bess >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Nov 2 01:50:58 2016 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 71CBD126D74 for ; Wed, 2 Nov 2016 01:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 EgfnbCSS8B5Z for ; Wed, 2 Nov 2016 01:50:53 -0700 (PDT) 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 EED0E128E19 for ; Wed, 2 Nov 2016 01:50:52 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 04:50:52 -0400 From: Dave Dolson To: Adrian Farrel , "'Surendra Kumar (smkumar)'" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICm Date: Wed, 2 Nov 2016 08:50:51 +0000 Message-ID: <20161102085050.5697621.72811.116410@sandvine.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> In-Reply-To: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 02 Nov 2016 08:50:56 -0000 Adrian, Perhaps I'm making too fine a point, but I consider that if an SF does anyt= hing other than decrementing the SI by 1, we've entered the realm of reclas= sification, and it is a Classifier co-located with the SF that is overridin= g the SPI/SI. If you refer to Figure 8, path selection is not an action done by an SF. Once reclassification is added to a deployment, we can have unicorns (and a= lso dragons); much more becomes possible, but it also becomes much more dif= ficult to reason about. You can read in the (expired) draft-penno-sfc-packet-03 some ideas about pa= cket reversal that depending heavily on rigid SF decrement-by-one. I don't = know how to begin reasoning about reverse forwarding once reclassification = is added... For those reasons, I would prefer to see the SF action limited to decrement= -by-one. If you require otherwise, co-locate a classifier with the SF. -Dave Original Message From: Adrian Farrel Sent: Tuesday, November 1, 2016 9:52 PM To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern'; sfc@ietf.or= g Reply To: adrian@olddog.co.uk Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that work= for simple implementations *and* that do not preclude more sophisticated implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement of the= SI. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF i= s not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local mat= ter (some policy that might be load balancing and could be influenced by any ma= nner of things if an implementation chooses without prejudice to the interoperab= ility of replaceability of SFFs). The fact of the choice is a function of how the network has been built, and how SFIs have been assigned, and how the SFPs h= ave been constructed by the controller - it is not a function of the NSH itself= . The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make s= ome form of choice and manipulate the packet) just as in most other modern forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitation on processing. That is, a simple implementation as envisaged by the proponents= of "MUST decrement by one" is able to perform that function and still be confo= rmant and interoperable. Similarly, a simple SFF as suggested in this thread woul= d have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and implementations. It is consistent with draft-mackie-bess-nsh-bgp-control-pl= ane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated things. O= f course, if the SFF cannot do those things then that will be OK since it won= 't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with an SPI and SI for which it does not have forwarding state, it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either ambiguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in Section 4. 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern'; > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement th= e SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules about packet > source. > > As far as I'm concerned, the SF decrements the SI, and it has been descri= bed this > way for a long time. Furthermore, the forwarding is described as a lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. > > > > > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Since the forwarders already exists, they are logical components to suppo= rt and > perform NSH based forwarding - forwarding on SFPs, rather than treat them= as > dumb forwarders. There is benefit to be had, offloads being one of them, = on top > of end of chain forwarding, etc. needed. > > I would rather have SFs focus on servicing the traffic than be burdened w= ith SPI > management (whether it is tens or thousands of SPIs) and the forwarding > thereof. IOW, consume metadata and service traffic and leave the SFP > management to the external forwarders. This not only simplifies the SFs, = it also > reduces the control plane touch point as it concerns to the SPI managemen= t. > > And you don't need complex logic to differentiate between traffic receive= d from > one SFF or a SF, this is what we addressed in the forwarding draft - triv= ial to > implement even in hardware. > > Thanks, > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ; > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Adrian, > Thank you for paraphrasing in a clear manner. > > Yes, I'm saying that the current (as I understand it) design permits the = SFF to be a > simple forwarder, not needing to discriminate between packets from anothe= r > SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF" or = "from SF" > is not as simple as checking ingress interface, for example. > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > Just clarifying my understanding of what you said (not necessarily agreei= ng ;-) > > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a pa= cket > received (back) from an SF that it serves. > > Or, more precisely, you are saying that the SFF is simply a forwarder tha= t > cannot tell the difference between passing a packet to a local SF and pas= sing a > packet on to a remote SFF. > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > Is that your point? > > Cheers, > Adrian > > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI without h= aving > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does not > > > define those. It is using the architectural, logical, components and > > > architecture defined by the SFC Architecture documents. > > > > I'd like to understand where in 7665 it says that the SF is responsible= for > > moving the packet on to the next SF in the path, rather than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how to > > encapsulate, and what to do at each hop in the path) needs to divide th= e > > responsibility for bits of protocol work between different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this an= SFF > > function? What benefit comes from doing it this way or did a choice sim= ply > have > > to be made? > > > > 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 From nobody Wed Nov 2 02:12:53 2016 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 B0B1212949D for ; Wed, 2 Nov 2016 02:12:51 -0700 (PDT) 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, 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 RPIDNVXHI58z for ; Wed, 2 Nov 2016 02:12:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB47A1294BE for ; Wed, 2 Nov 2016 02:04:27 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 181583240AF; Wed, 2 Nov 2016 10:04:26 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.59]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C75EB35C082; Wed, 2 Nov 2016 10:04:25 +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; Wed, 2 Nov 2016 10:04:25 +0100 From: To: "adrian@olddog.co.uk" , 'Dave Dolson' , "'Surendra Kumar (smkumar)'" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AALvPdw Date: Wed, 2 Nov 2016 09:04:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009D9C9A5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> In-Reply-To: <02e601d234ab$b69648c0$23c2da40$@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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.2.83316 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 02 Nov 2016 09:12:52 -0000 Hi Adrian,=20 Please see inline. Cheers, Med PS: I would love the NSH spec to make the distinction between looping vs. s= piraling (https://www.ietf.org/mail-archive/web/sfc/current/msg03179.html) > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > Envoy=E9=A0: mercredi 2 novembre 2016 02:52 > =C0=A0: 'Dave Dolson'; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern'; > sfc@ietf.org > Objet=A0: [sfc] OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > Been thinking about this instead of sleeping. >=20 > Keep getting caught in rat-holes that say "no, but you could build produc= t > like > this." But they are real rat-holes. What we need is a set of rule that > work for > simple implementations *and* that do not preclude more sophisticated > implementations. >=20 > So... >=20 > When a packet arrives at an SFF the SPI/SI indicates the SFP and the next > hop on > that SFP to be executed. >=20 > When an SF has finished processing a packet the default behavior is to > leave the > SPI unchanged and to decrement the SI by 1. >=20 > However, and SF MAY know to make other changes to a the SPI and SI. How > that > knowledge is installed in the SF is implementation dependent: > - it may be the result of configuration (for example, normally decrement > by > 1 but in event of a specific condition forward to a different chain) [Med] This is not the role of an SFW-aware SF but a classifier. All require= ments about setting SI/SPI would then be applied for this.=20 > - it may be the result of a policy and visibility of the SFP [Med] Not sure to understand this one. > - it may be based on information in the metadata > - there may be unicorns >=20 > There may be a classifier co-resident with the SF or in the path from SF > back to > SFF so that the SPI/SI received by the SFF is not a simple decrement of > the SI. >=20 > There may be a classifier co-resident with the SFF that processes the > packet > before the SFF performs forwarding so that the SPI/SI received by the SFF > is not > a simple decrement of the SI. >=20 > The SFF's routing lookup may give it a choice of SFIs or SFFs to which to > send > the packet for the given SPI/SI. How it resolves this choice is a local > matter > (some policy that might be load balancing and could be influenced by any > manner > of things if an implementation chooses without prejudice to the > interoperability > of replaceability of SFFs). The fact of the choice is a function of how > the > network has been built, and how SFIs have been assigned, and how the SFPs > have > been constructed by the controller - it is not a function of the NSH > itself. >=20 > The SFF's forwarding instructions can be simple (look up SPI/SI and send > the > packet out of interface X encapsulated in tunnel Y) or more complex (make > some > form of choice and manipulate the packet) just as in most other modern > forwarding paradigms. >=20 > An SFF that does not recognise the SPI/SI (i.e., has no forwarding state > for it) > can only (read MUST) drop the packet. >=20 > What forwarding state an SFF has is a matter of: > - implementation > - control/management plane instructions > - visibility into the SFP (and other SFPs) >=20 >=20 > I believe this set of rules is consistent with 7665 and also supports wha= t > the > WG wanted to achieve with the NSH draft without requiring any limitation > on > processing. That is, a simple implementation as envisaged by the > proponents of > "MUST decrement by one" is able to perform that function and still be > conformant > and interoperable. Similarly, a simple SFF as suggested in this thread > would > have no problems interoperating. >=20 > Similarly, this behavior is flexible enough to allow for other uses and > implementations. It is consistent with draft-mackie-bess-nsh-bgp-control- > plane > (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all= ) > and > allows a control plane to program an SFF to do more sophisticated things. > Of > course, if the SFF cannot do those things then that will be OK since it > won't > support those control plane instructions. >=20 > Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 > section > 4 as follows: >=20 > OLD > 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. > NEW > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > service index. By default the SF decrements the SI by 1, but it > MAY apply other decrements according to configuration and other > information available to it.=20 [Med] I do think we should maintain the initial wording here. Resetting SI = or SPI remarking is the responsibility of a classifier node. Whether this c= lassifier is co-resident with an SFC-aware function is deployment-specific.= =20 If an SFF receives a packet with > an SPI and SI for which it does not have forwarding state, > it MUST be drop the packet, and SHOULD log the event subject to > rate limiting on such logs. [Med] OK for the log. > END >=20 > Similarly later in the same bullet... > OLD > 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. > NEW > 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. By default the SFC Proxy decrements the SI by 1, > but it MAY apply other decrements according to configuration and > other information available to it. [Med] Same comment as above. > END >=20 > Furthermore, in section 3.3 since the term "egress NSH packet" is either > ambiguous or neglects the possibility of reclassification... >=20 > OLD > 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. > NEW > Service Index MUST be decremented by Service Functions or by SFC > Proxy nodes after performing required services as described in > Section 4. 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. > END [Med] I like this one. >=20 >=20 > Now perhaps I can sleep :-) >=20 > Adrian >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 23:22 > > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern'; > > sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > I agree that the SF should be simple. > > But don't confuse decrementing the SI with complexity. > > There is absolutely no configuration required to have the SF decrement > the SI > of > > every packet. > > And there is a lot of benefit to keeping the SFF from having rules abou= t > packet > > source. > > > > As far as I'm concerned, the SF decrements the SI, and it has been > described > this > > way for a long time. Furthermore, the forwarding is described as a > lookup > table > > based on SPI/SI. There is no mention of the source in the forwarding > table. > > > > > > > > > > Original Message > > From: Surendra Kumar (smkumar) > > Sent: Tuesday, November 1, 2016 7:03 PM > > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > > > Since the forwarders already exists, they are logical components to > support > and > > perform NSH based forwarding - forwarding on SFPs, rather than treat > them as > > dumb forwarders. There is benefit to be had, offloads being one of them= , > on > top > > of end of chain forwarding, etc. needed. > > > > I would rather have SFs focus on servicing the traffic than be burdened > with > SPI > > management (whether it is tens or thousands of SPIs) and the forwarding > > thereof. IOW, consume metadata and service traffic and leave the SFP > > management to the external forwarders. This not only simplifies the SFs= , > it > also > > reduces the control plane touch point as it concerns to the SPI > management. > > > > And you don't need complex logic to differentiate between traffic > received > from > > one SFF or a SF, this is what we addressed in the forwarding draft - > trivial > to > > implement even in hardware. > > > > Thanks, > > Surendra. > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: Tuesday, November 01, 2016 1:27 PM > > To: adrian@olddog.co.uk; 'Joel M. Halpern' ; > > sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > Adrian, > > Thank you for paraphrasing in a clear manner. > > > > Yes, I'm saying that the current (as I understand it) design permits th= e > SFF > to be a > > simple forwarder, not needing to discriminate between packets from > another > > SFF or returning from an SF. > > A single forwarding table handles both cases. > > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > > > So it could tell the difference, but doesn't need to. > > In some cases, an SFF can be a single-interface device, so "from SFF" o= r > "from > SF" > > is not as simple as checking ingress interface, for example. > > > > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Tuesday, November 01, 2016 4:00 PM > > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > Just clarifying my understanding of what you said (not necessarily > agreeing > ;-) > > > > You are saying that an SFF is simply a forwarder and cannot tell the > difference > > between a packet received on a transport tunnel from another SFF and a > packet > > received (back) from an SF that it serves. > > > > Or, more precisely, you are saying that the SFF is simply a forwarder > that > > cannot tell the difference between passing a packet to a local SF and > passing > a > > packet on to a remote SFF. > > > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > > > Is that your point? > > > > Cheers, > > Adrian > > > > -- > > Support an author and your imagination. > > Tales from the Wood - Eighteen new fairy tales. > > More Tales from the Wood - Eighteen MORE new fairy tales. > > https://www.feedaread.com/profiles/8604/ > > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > > Or buy from me direct. > > > > > > > > > -----Original Message----- > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > Sent: 01 November 2016 19:35 > > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > > Subject: RE: [sfc] decrementing service function path index > > > > > > The SF decrements the index so that the SFF doesn't have to look at > the > packet > > > origin in order to determine whether or not to decrement it. > > > We don't want the SFF to have logic like: > > > If NSH packet is from one of addresses x, y z > > > Decrement SI > > > > > > As currently defined, the SFF simply routes packets by SPI/SI without > having > > to > > > do consider source address. > > > > > > > > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > > Sent: Tuesday, November 01, 2016 2:48 PM > > > To: 'Joel M. Halpern'; sfc@ietf.org > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > With regard to the architectural components, the NSH draft does not > > > > define those. It is using the architectural, logical, components > and > > > > architecture defined by the SFC Architecture documents. > > > > > > I'd like to understand where in 7665 it says that the SF is > responsible for > > > moving the packet on to the next SF in the path, rather than the SFF. > > > > > > I'd also like to understand why the NSH document (that tells us how t= o > > > encapsulate, and what to do at each hop in the path) needs to divide > the > > > responsibility for bits of protocol work between different logical > functional > > > entities. In short, why does the SF decrement the SI, why isn't this > an SFF > > > function? What benefit comes from doing it this way or did a choice > simply > > have > > > to be made? > > > > > > 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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Nov 2 03:02:16 2016 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 6EA7B129A95 for ; Wed, 2 Nov 2016 03:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 dmKNG3R0MvlV for ; Wed, 2 Nov 2016 03:02:12 -0700 (PDT) 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 13D41129A7F for ; Wed, 2 Nov 2016 03:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5597; q=dns/txt; s=iport; t=1478080923; x=1479290523; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tLzZFfNRbcW8ThD4K3CpQulmqxTPt668oJ68w1IxjZ8=; b=F0tQugqvn1D2uFOUrwQ+WWY6aOfXKe6jDv+ZxZa9Rms4G0hoWDnDiR3V 6ktx4/n866u/g3Z/Fqf5LCJqm5CXJ9alTdVC6Z1ScaJh/wDZ8jrfGEodL BSnrvQpoJfPFWvIJ3aZmq3khVh5Uzai1ZppE+a2apYwbM4EMk0PNONh14 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAQD4uBlY/4gNJK1aAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYMsAQEBAQEfWHwHjTCXAZRHggcdDYV4AoIbPxQBAgEBAQEBAQFiHQu?= =?us-ascii?q?EYQEBAQQBAQFrCQIMBAIBCBEBAwEBKAcnCxQDBQEIAgQOBQgTiDsOrWuLPgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARyLEoQZEQEoFSaFGQWOUTuFM4VeAYYygwmGd4F?= =?us-ascii?q?1ToQhiAOBKI0YhAMBHjZnhRdyAQGGIQ0XgQmBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,583,1473120000"; d="scan'208";a="341339600" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2016 10:02:02 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uA2A21Pk018848 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Nov 2016 10:02:01 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Nov 2016 05:02:01 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1210.000; Wed, 2 Nov 2016 05:02:01 -0500 From: "Roberta Maglione (robmgl)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-radius-00.txt Thread-Index: AQHSLcmZLa6Ssga+Y0mKdc8a+TR+qKDFhEcw Date: Wed, 2 Nov 2016 10:02:01 +0000 Message-ID: <7ba24d5130e3472f9c8bbd94c2ebda57@XCH-RCD-009.cisco.com> References: <147651526420.14954.691320262825038260.idtracker@ietfa.amsl.com> <7b056fd8879c42a0ad63417586dff2a4@XCH-RCD-009.cisco.com> <787AE7BB302AE849A7480A190F8B933009D96F6E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009D96F6E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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.61.166.84] 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] FW: New Version Notification for draft-maglione-sfc-nsh-radius-00.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, 02 Nov 2016 10:02:15 -0000 Hi Med, We posted a new version of this draft to address your comments.=20 Best Regards Roberta =A0 Roberta Maglione TECHNICAL SOLUTIONS ARCHITECT GSP Architecture robmgl@cisco.com Tel: +39 039 629 5758 Cisco Systems, Inc. Via Torri Bianche 8 VIMERCATE 20871 Italy cisco.com Think before you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Monday, October 24, 2016 9:38 AM To: Roberta Maglione (robmgl) ; sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-= radius-00.txt Hi Roberta,=20 Thank you for sharing this draft. Some comments below: * You may consider the template in https://tools.ietf.org/html/draft-ietf-r= adext-datatypes-08#section-2.1.3 for defining the RADIUS attributes.=20 * This draft is an implementation of the "C1: Interface between SFC Control= Plane & SFC Classifier" interface: https://tools.ietf.org/html/draft-ietf-= sfc-control-plane-08#section-3.3.1. Having a reference to the CP architectu= re would be helpful. If you can indicate which requirements from the CP doc= ument you are targeting, this would be even appreciated.=20 * The draft focuses on two pieces of information that can be instructed via= the CP. I do agree those two are important ones, but I wonder whether thos= e are sufficient to cover SFC needs in the broadband case. For example, how= to demux among multiple services to be delivered to the same subscriber? D= o you assume that other control protocols are used to instruct the classifi= cation rules or this is done by RADIUS? * Because NSH-SI may be bound to a given path, the presence of NSH-SPI attr= ibute may be required. BTW, I wonder whether you can define a "SFC Rule" RA= DIUS attribute that can convey one or many SFC-related TLVs (e.g., NSH-SPI,= NSH-SI, etc.). Thank you. Cheers, Med=20 > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Roberta Maglione > (robmgl) > Envoy=E9=A0: samedi 22 octobre 2016 11:52 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-= =20 > radius-00.txt >=20 > Hello, > We submitted this document about Radius attributes for NSH. > The draft is targeted at addressing Broadband access use cases. > Your comments are welcome. > Best Regards > Roberta >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Saturday, October 15, 2016 9:08 AM > To: Guillermo Trueba (gtrueba) ; Roberta Maglione > (robmgl) ; Carlos Pignataro (cpignata)=20 > > Subject: New Version Notification for=20 > draft-maglione-sfc-nsh-radius-00.txt >=20 >=20 > A new version of I-D, draft-maglione-sfc-nsh-radius-00.txt > has been successfully submitted by Roberta Maglione and posted to the=20 > IETF repository. >=20 > Name: draft-maglione-sfc-nsh-radius > Revision: 00 > Title: RADIUS Attributes for NSH > Document date: 2016-10-14 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-maglione-sfc- > nsh-radius-00.txt > Status: https://datatracker.ietf.org/doc/draft-maglione-sfc-nsh- > radius/ > Htmlized: https://tools.ietf.org/html/draft-maglione-sfc-nsh-radius= - > 00 >=20 >=20 > Abstract: > Network Service Header (NSH) protocol defines the Service Function > Chaining (SFC) encapsulation required to support the Service Function > Chaining (SFC) Architecture. One of the components of the Network > Service Header (NSH) protocol is the Service Path Identifier (SPI), > which identifies a service path, another important element of the NSH > protocol is the Service Index (SI), which provides location within > the Service Path. >=20 > When Service Providers would like to deliver customized services > offers requiring Service Functions Chains, a different service chain > may be required for each subscriber or group of subscribers. In > order to simplify the service provisioning in this scenario, it would > be useful to be able to associate the Service Path Identifier (SPI), > identifying the service chain, and the appropriate Service Index > (SI), identifying the location in the service path, with the customer > profile. >=20 > In some Broadband networks, the customer profile information may be > stored in Authentication, Authorization, and Accounting (AAA) > servers. This document specifies two new Remote Authentication Dial- > In User Service (RADIUS) attributes to carry the Service Path > Identifier (SPI) and the Service Index (SI). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Nov 2 03:20:22 2016 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 7A64F12945A for ; Wed, 2 Nov 2016 03:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 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=-1.497, 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 1fGy0e4Hwwbp for ; Wed, 2 Nov 2016 03:20:00 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE031295E2 for ; Wed, 2 Nov 2016 03:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2141; q=dns/txt; s=iport; t=1478081999; x=1479291599; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5OJZFE4oeIyfacZ+dxqt6J6x7LxtPcBP/Vpxkbk0Xgk=; b=OPuqdbk+UKqOaImVJave47R/mD2eX7cckleii8m0I1xFF4FBcFl72FMn Qnym5mGVEWnDB+QqjTo2dfGqZ/wZ/kC1HwgbLcWyQW8COyZ3AzJK4DQTd zpZVfo2SmEgbSd/q1ggHaCgSiZWpl/WxKrGxhI8CKerQNXAQS3c6ODYyh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuAQB4vRlY/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywBAQEBAR9YfAeNMJcBlEeCBx0LhXoCghs/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEEAQEBGlEbAgEIEQQBASgHJwsUCQgCBAESCIhODrk5AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWLEoQjhgQFjlE7ixEBkDKBdYRviSuNGIQDAR42Z4UXcoY?= =?us-ascii?q?hgS+BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,583,1473120000"; d="scan'208";a="343266228" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2016 10:19:58 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uA2AJw4t024390 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 2 Nov 2016 10:19:59 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Nov 2016 05:19:58 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1210.000; Wed, 2 Nov 2016 05:19:58 -0500 From: "Roberta Maglione (robmgl)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for Seoul SFC WG Agenda Topics Thread-Index: AQHSK6tfxvjclDMfu06fop86xfqfdKC+QD+AgAdMfyA= Date: Wed, 2 Nov 2016 10:19:58 +0000 Message-ID: <872fd178b36e40089a78e651a52dbf71@XCH-RCD-009.cisco.com> References: <5169E6B0-BC21-40DA-9B87-1F78F9A9E2AD@cisco.com> <0ADC1970-9EDF-44BC-8E10-A45EAEB934AA@cisco.com> In-Reply-To: <0ADC1970-9EDF-44BC-8E10-A45EAEB934AA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.166.84] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for Seoul SFC WG Agenda Topics 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, 02 Nov 2016 10:20:02 -0000 Dear WG Chairs, The authors of draft-maglione-sfc-nsh-radius-01 would like to ask for 5 min= utes slot to present this draft. The document defines two new Radius attributes for NSH and it is targeted a= t addressing Broadband access use cases. Thanks Best Regards Roberta =A0 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, October 28, 2016 3:48 PM To: sfc@ietf.org Subject: Re: [sfc] Call for Seoul SFC WG Agenda Topics Dear SFC WG: This is a reminder to please send requests for agenda time to the chairs by= November 4th 9AM EST. Please also indicate if there are specific topics that you would like to se= e discussed during the face-to-face meeting. Jim Sent from my iPhone On Oct 21, 2016, at 10:57 AM, Jim Guichard (jguichar) wrote: Greetings WG: Our meeting in Seoul is fast approaching. As always the goal of the meeting= will be to make the best use of our limited face-to-face time. With that i= n mind we welcome requests for agenda time. As we build the meeting agenda our goal will be to select presentations tha= t best further the work of the WG, and that generally means focusing on key= charter deliverables and topics with important open issues to resolve. Whe= n making a request please consider what you think the WG should do with its= content - for example: - Does the document have useful content that should be moved into another W= G document or progress on its own merit - Does the content have a good basis for one of the WG documents per the ch= arter - Should the document content be merged with one or more other documents, s= o that a combined document could become a WG document **Please send your request to the SFC chairs until November 4th, 9 am EST.*= * The request must include the name of the draft or topic to be presented, ti= me for the presentation requested, and the presenter. Thanks, Jim, Thomas & Martin _______________________________________________ sfc mailing list mailto:sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Nov 2 11:02:52 2016 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 166091293DC for ; Wed, 2 Nov 2016 11:02:51 -0700 (PDT) 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=unavailable 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 mNSy4YiOCsr1 for ; Wed, 2 Nov 2016 11:02:50 -0700 (PDT) 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 3A39A1293DB for ; Wed, 2 Nov 2016 10:54:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 209252405F3 for ; Wed, 2 Nov 2016 10:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478109295; bh=qIvtm75jgloiu4IIQinm7zJiB9CMKe0oSlGdInbkK7E=; h=To:From:Subject:Date:From; b=Mt/C6bXSWblspC/OO/s/Y5Kinvlmdg+hlcW7TDn/QQaq6vEji2gzh4qLPs3nyEU+9 tRAktiKFdBO3NcNKoG2Q5Sy0eSwFee5/n1CHUHfwrranN3QW0XRW27ocAmXaTBBRLm zrSLBtuRkOUrkYWJZBVO423kQPl2VBDxCaUD8CTk= 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 C13FE2401B1 for ; Wed, 2 Nov 2016 10:54:54 -0700 (PDT) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Wed, 2 Nov 2016 13:57:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] NSH MD-1 description 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, 02 Nov 2016 18:02:51 -0000 Given that various existing MD-1 proposals break up the "4" fields in various ways, and given that we may want to allow , for example, a singl 64 bit field in some MD-1 allocation, it seems cleaner and more consistent to me to describe the MD-1 content as a block of 16 bytes rather than as 4 4 byte words. Given that this is purely descriptive for the NSH document, I do not see a down side. YANG models for metadata are a more complex question, but the simple 4x4 byte representation is probably not want we want there either. Yours, Joel From nobody Wed Nov 2 11:30:20 2016 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 04D87129672 for ; Wed, 2 Nov 2016 11:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_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 F4dPZkpGRCBD for ; Wed, 2 Nov 2016 11:30:17 -0700 (PDT) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B104A12964F for ; Wed, 2 Nov 2016 11:30:17 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 11:30:16 -0700 From: Ron Parker To: "Joel M. Halpern" Thread-Topic: [sfc] NSH MD-1 description Thread-Index: AQHSNTNWuIlDBojW5EGGSxJHqQZAIaDGA+n4 Date: Wed, 2 Nov 2016 18:30:16 +0000 Message-ID: <3A2ACD29-D5D5-4F18-B263-4F816642CCDE@affirmednetworks.com> References: In-Reply-To: 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: "sfc@ietf.org" Subject: Re: [sfc] NSH MD-1 description 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, 02 Nov 2016 18:30:19 -0000 Agree with this position.=20 Ron > On Nov 2, 2016, at 10:02 PM, Joel M. Halpern wrote: >=20 > > Given that various existing MD-1 proposals break up the "4" fields in var= ious ways, and given that we may want to allow , for example, a singl 64 bi= t field in some MD-1 allocation, it seems cleaner and more consistent to me= to describe the MD-1 content as a block of 16 bytes rather than as 4 4 byt= e words. >=20 > Given that this is purely descriptive for the NSH document, I do not see = a down side. YANG models for metadata are a more complex question, but the= simple 4x4 byte representation is probably not want we want there either. >=20 > Yours, > Joel >=20 > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Nov 2 11:52:29 2016 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 7678D129B4F for ; Wed, 2 Nov 2016 11:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 9b8VD7tLqgek for ; Wed, 2 Nov 2016 11:52:13 -0700 (PDT) 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 45563129B4E for ; Wed, 2 Nov 2016 11:52:13 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 14:52:12 -0400 From: Dave Dolson To: Ron Parker , "Joel M. Halpern" Thread-Topic: [sfc] NSH MD-1 description Thread-Index: AQHSNTNbdzNhEb8yGUOZcYzTRyF25aDGRvcA///DB/A= Date: Wed, 2 Nov 2016 18:52:11 +0000 Message-ID: References: <3A2ACD29-D5D5-4F18-B263-4F816642CCDE@affirmednetworks.com> In-Reply-To: <3A2ACD29-D5D5-4F18-B263-4F816642CCDE@affirmednetworks.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH MD-1 description 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, 02 Nov 2016 18:52:14 -0000 +1 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Wednesday, November 02, 2016 2:30 PM To: Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] NSH MD-1 description Agree with this position.=20 Ron > On Nov 2, 2016, at 10:02 PM, Joel M. Halpern wrote: >=20 > > Given that various existing MD-1 proposals break up the "4" fields in var= ious ways, and given that we may want to allow , for example, a singl 64 bi= t field in some MD-1 allocation, it seems cleaner and more consistent to me= to describe the MD-1 content as a block of 16 bytes rather than as 4 4 byt= e words. >=20 > Given that this is purely descriptive for the NSH document, I do not see = a down side. YANG models for metadata are a more complex question, but the= simple 4x4 byte representation is probably not want we want there either. >=20 > Yours, > Joel >=20 > >=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 Wed Nov 2 12:27:06 2016 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 27E1C1297CD for ; Wed, 2 Nov 2016 12:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.518 X-Spam-Level: X-Spam-Status: No, score=-8.518 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=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 bvI67di08ukg for ; Wed, 2 Nov 2016 12:27:04 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72860129862 for ; Wed, 2 Nov 2016 12:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1478114823; x=1509650823; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=huIp9fULN4hc+0t5oVsfctAGAD8CiOY3jCFT78EaviA=; b=Z8IJnU0vgnER/O13fuEZ4x+Q+tDwYuWcJXycjhNaE8+j6ZDZsJ1ne8nz EGylLJ6mMZ6aysNCFjHht1fDD0aFckmO9NnepJTihWMcIHUPh0LfPtaOD JGpPEiWQ5mdz+4nHEguk6n+/tBLDTGpZFAXBl2+u7zQUGnrA60Nlp1Grc E=; X-IronPort-AV: E=McAfee;i="5700,7163,8337"; a="252673281" X-IronPort-AV: E=Sophos;i="5.31,436,1473120000"; d="scan'208";a="252673281" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 02 Nov 2016 19:27:02 +0000 Received: from SE3CCPEMS02.olympus.F5Net.com (172.23.161.13) by SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 2 Nov 2016 12:26:59 -0700 Received: from SE3CCPEMS05.olympus.F5Net.com (172.23.161.16) by SE3CCPEMS02.olympus.F5Net.com (172.23.161.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Wed, 2 Nov 2016 12:26:59 -0700 Received: from SE3CCPEMS05.olympus.F5Net.com ([fe80::50f9:a657:ac15:1c1f]) by SE3CCPEMS05.olympus.F5Net.com ([fe80::50f9:a657:ac15:1c1f%18]) with mapi id 15.01.0544.027; Wed, 2 Nov 2016 12:26:58 -0700 From: Sumandra Majee To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] NSH MD-1 description Thread-Index: AQHSNTNnMJLfPpPfF0W/O0mU+KCMyKDGE8MA Date: Wed, 2 Nov 2016 19:26:58 +0000 Message-ID: <51C18388-D737-45E1-9D76-57B998A79024@f5.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.168.15.218] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH MD-1 description 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, 02 Nov 2016 19:27:05 -0000 QWdyZWUNCg0KT24gMTEvMi8xNiwgMTA6NTcgQU0sICJzZmMgb24gYmVoYWxmIG9mIEpvZWwgTS4g SGFscGVybiIgPHNmYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqbWhAam9lbGhhbHBl cm4uY29tPiB3cm90ZToNCg0KICAgIDxzcGVha2luZyBhcyBhIHBhcnRpY2lwYW50Pg0KICAgIEdp dmVuIHRoYXQgdmFyaW91cyBleGlzdGluZyBNRC0xIHByb3Bvc2FscyBicmVhayB1cCB0aGUgIjQi IGZpZWxkcyBpbiANCiAgICB2YXJpb3VzIHdheXMsIGFuZCBnaXZlbiB0aGF0IHdlIG1heSB3YW50 IHRvIGFsbG93ICwgZm9yIGV4YW1wbGUsIGEgc2luZ2wgDQogICAgNjQgYml0IGZpZWxkIGluIHNv bWUgTUQtMSBhbGxvY2F0aW9uLCBpdCBzZWVtcyBjbGVhbmVyIGFuZCBtb3JlIA0KICAgIGNvbnNp c3RlbnQgdG8gbWUgdG8gZGVzY3JpYmUgdGhlIE1ELTEgY29udGVudCBhcyBhIGJsb2NrIG9mIDE2 IGJ5dGVzIA0KICAgIHJhdGhlciB0aGFuIGFzIDQgNCBieXRlIHdvcmRzLg0KICAgIA0KICAgIEdp dmVuIHRoYXQgdGhpcyBpcyBwdXJlbHkgZGVzY3JpcHRpdmUgZm9yIHRoZSBOU0ggZG9jdW1lbnQs IEkgZG8gbm90IHNlZSANCiAgICBhIGRvd24gc2lkZS4gIFlBTkcgbW9kZWxzIGZvciBtZXRhZGF0 YSBhcmUgYSBtb3JlIGNvbXBsZXggcXVlc3Rpb24sIGJ1dCANCiAgICB0aGUgc2ltcGxlIDR4NCBi eXRlIHJlcHJlc2VudGF0aW9uIGlzIHByb2JhYmx5IG5vdCB3YW50IHdlIHdhbnQgdGhlcmUgDQog ICAgZWl0aGVyLg0KICAgIA0KICAgIFlvdXJzLA0KICAgIEpvZWwNCiAgICANCiAgICA8L3NwZWFr aW5nIGFzIGEgcGFydGljaXBhbnQ+DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzZmMgbWFpbGluZyBsaXN0DQogICAgc2ZjQGll dGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCiAg ICANCg0K From nobody Wed Nov 2 15:49:31 2016 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 1513C126FDC for ; Wed, 2 Nov 2016 15:49:30 -0700 (PDT) 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 GzknwyWsJCZy for ; Wed, 2 Nov 2016 15:49:28 -0700 (PDT) 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 E0F8C129473 for ; Wed, 2 Nov 2016 15:49:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C913B240965 for ; Wed, 2 Nov 2016 15:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478126968; bh=2KsIlGmKNIogkIXvpOjuHznmzfey19KnWjtTPG8yVXM=; h=To:From:Subject:Date:From; b=SdQuC+i7q3JacB2WetpPP+RzfFBx9zBpH29UXCiFLTE4XD7M5oqMI2t0VGvEE907B sLqtCuCKOFYZFxYX5UProrJ/vOP/IDEqFa0+M7xZmjTGcy2jX4XFCWAF5RYBHwXBkf pnwGBx99wKfFiItcbUInKbVxaw0pd+IdhvVaHNCY= 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 439092405F3 for ; Wed, 2 Nov 2016 15:49:28 -0700 (PDT) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: <692d294d-6ab4-e1f3-b99e-f45c01515ca9@joelhalpern.com> Date: Wed, 2 Nov 2016 18:51:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Regarding Hierarchical Service Function Chaining (hSFC) 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, 02 Nov 2016 22:49:30 -0000 After the July IETF meeting, we adopted https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ The authors have some revisions as per earlier discussions. There has not been much discussion of this document on the list. Before we conclude that this is done, it would be good, as per the slides from that meeting (https://www.ietf.org/proceedings/96/slides/slides-96-sfc-7.pdf, last slide) to have a couple of reviews. Are there a couple of working group members (not authors of this document) who can take the time and have the interest to review this? Thank you, Joel From nobody Wed Nov 2 16:38:36 2016 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 5B48C129580 for ; Wed, 2 Nov 2016 16:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 LTPfyCSbklke for ; Wed, 2 Nov 2016 16:38:28 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F00129416 for ; Wed, 2 Nov 2016 16:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13640; q=dns/txt; s=iport; t=1478129908; x=1479339508; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ghBQvtBoenqiq/SWzk8uDzuJXJG0Qm/3/+ypfWdJ6N0=; b=G3dqXWnnPY0lPER9vSNg6U4xRfAVAEMIJNcHDvg45hwoNu2MdsPG/DMP dnxbfqX/0zspNHKxGb0uCCOIBXmT2cKzN2oUpsNe/uLwaNwaVr27uSFtn q6ejOR/5Ttr0y/0kPd/GoX1Qha72UkYvlJFN86PoRRpnPOm8LbvE4n2dW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AQCGeBpY/40NJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgywBAQEBAR9YfAeNMJcAlEeCCB0LhXoCgh8/FAECAQEBAQEBAWIohGE?= =?us-ascii?q?BAQEEAQEBNzQXBAIBCBEBAwEBHwkHJwsUAwYIAQEEARIIiE4Ouh8BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEcixKKJwWEB5A4hV4BiTuGd4F1iCqFcYckhXSEAwEeNme?= =?us-ascii?q?DKBwYgTtyh0aBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,436,1473120000"; d="scan'208";a="343551534" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2016 23:38:26 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uA2NcQkL029578 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Nov 2016 23:38:26 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Nov 2016 18:38:25 -0500 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, 2 Nov 2016 18:38:25 -0500 From: "Surendra Kumar (smkumar)" To: "adrian@olddog.co.uk" , "'Dave Dolson'" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommA Date: Wed, 2 Nov 2016 23:38:25 +0000 Message-ID: <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> In-Reply-To: <02e601d234ab$b69648c0$23c2da40$@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.155.33.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 02 Nov 2016 23:38:30 -0000 Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding.=20 Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI=20 However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with=20 an SPI and SI for which it does not have forwarding state,=20 it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in=20 Section 4. The initial Classifier MUST send the packet to the=20 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. >=20 > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. >=20 >=20 >=20 >=20 > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 >=20 > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. >=20 > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. >=20 > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > Adrian, > Thank you for paraphrasing in a clear manner. >=20 > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >=20 > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" > is not as simple as checking ingress interface, for example. >=20 >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) >=20 > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. >=20 > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. >=20 > And the SFF sees a packet n+1 times for an SFP with n local SFs. >=20 > Is that your point? >=20 > Cheers, > Adrian >=20 > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. >=20 >=20 >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 Wed Nov 2 16:46:19 2016 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 25C1B12953F for ; Wed, 2 Nov 2016 16:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 07DMmxejKYiD for ; Wed, 2 Nov 2016 16:46:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E1812943A for ; Wed, 2 Nov 2016 16:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14349; q=dns/txt; s=iport; t=1478130375; x=1479339975; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jVnAf4wxesIUz7Dk9Wk+/YuBNWs2m571GrjbpSceggE=; b=TE6Bex8J2XSNdW6c/2T5o/buuBVEDoClu5exk9lB6Z817kO36xNzzhM9 s6jOrGNVZ2VeI0rWGASutAIqy8E/bXLYyTEstB6vg7d//hUEw6oAUbC+/ 0EGGx/Y7weadR8FQZjFy5ErFF0LQ5/ZvmPEgyakBeg8QsmwPWUTnJG2XE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AQDneRpY/5FdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgywBAQEBAR9YfAeNMJcAlEeCCB0LhXoCgh8/FAECAQEBAQEBAWIohGE?= =?us-ascii?q?BAQEEAQEBNzQXBAIBCA4DAQMBAR8JBycLFAMGCAEBBAESCIhODroSAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHIsShCOGBAWEB4Q6h0yEMoVeAYk7hneBdYgqhXGHJIV?= =?us-ascii?q?0hAMBHjZngygcGIE7coYXgS+BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,436,1473120000"; d="scan'208";a="164960471" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2016 23:46:13 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA2NkDDS002231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Nov 2016 23:46:13 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Nov 2016 18:46:13 -0500 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, 2 Nov 2016 18:46:13 -0500 From: "Surendra Kumar (smkumar)" To: Dave Dolson , Adrian Farrel , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAB8If2A= Date: Wed, 2 Nov 2016 23:46:13 +0000 Message-ID: <15233159ac6a4f3792284537082dec7c@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> In-Reply-To: <20161102085050.5697621.72811.116410@sandvine.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.33.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 02 Nov 2016 23:46:18 -0000 At the risk of spiraling (borrowing Adiran), this reasoning begs the questi= on - why even have non-classifier SFs touch the SI to start with ? I would argue to leave it alone and treat SPI+SI as a forwarding state and = opaque to SFs. Control plane can weave the same SF instance into thousands (well, it is a = 24bit SPI) of SPIs and that shouldn't be a concern for the SF - consume met= adata and service traffic. Allowing for control plane programmed decrement value is very reasonable an= d useful. Surendra. -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Wednesday, November 02, 2016 1:51 AM To: Adrian Farrel ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, Perhaps I'm making too fine a point, but I consider that if an SF does anyt= hing other than decrementing the SI by 1, we've entered the realm of reclas= sification, and it is a Classifier co-located with the SF that is overridin= g the SPI/SI. If you refer to Figure 8, path selection is not an action done by an SF. Once reclassification is added to a deployment, we can have unicorns (and a= lso dragons); much more becomes possible, but it also becomes much more dif= ficult to reason about. You can read in the (expired) draft-penno-sfc-packet-03 some ideas about pa= cket reversal that depending heavily on rigid SF decrement-by-one. I don't = know how to begin reasoning about reverse forwarding once reclassification = is added... For those reasons, I would prefer to see the SF action limited to decrement= -by-one. If you require otherwise, co-locate a classifier with the SF. -Dave Original Message From: Adrian Farrel Sent: Tuesday, November 1, 2016 9:52 PM To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern'; sfc@ietf.or= g Reply To: adrian@olddog.co.uk Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with an SPI and SI for which it does not have forwarding state, it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in Section 4. 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. > > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. > > > > > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. > > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. > > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. > > Thanks, > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Adrian, > Thank you for paraphrasing in a clear manner. > > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" > is not as simple as checking ingress interface, for example. > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) > > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. > > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > Is that your point? > > Cheers, > Adrian > > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > 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 From nobody Wed Nov 2 17:54:25 2016 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 16D941295AB for ; Wed, 2 Nov 2016 17:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 69ATRw4HFeSb for ; Wed, 2 Nov 2016 17:54:22 -0700 (PDT) Received: from nm21.bullet.mail.ne1.yahoo.com (nm21.bullet.mail.ne1.yahoo.com [98.138.90.84]) (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 AAA2112955C for ; Wed, 2 Nov 2016 17:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1478134462; bh=Q94wq7U1aIQDylWlV7ds+xTdJvB1/+ssFWSkXiLSaEE=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=rxEDbfbpDiXvNY01qi/5Er0eBu79nisWwSaFXW8Fe6QsmLOhPexgS2bjfalH+vSncjBNNKJhqXbQKWrBubTUCpAV3by3tyTGTGvl4pNhiYToEl4Ztd37M7DYzhS0yXvK93anY62PwO94VT6WEaf6Pp6jFpK52WVM5QkYGYAWnxOz1+bCWeY5B798A982Naz6Puy4v1JDNNisaD+yB2dIW59PY46DOcE61Cnydgfmm6GMObmNMokRxd5VHPDCjDLA2hqn0NwXlAKm3jw8E/fUCkiCW6uAg5p85AZ4Ct53wdmN4C2sNZXqVHqxDjy/cid2D8GFc1ZTqoJqsZH92L4ASA== Received: from [98.138.226.176] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 03 Nov 2016 00:54:22 -0000 Received: from [98.138.89.254] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 03 Nov 2016 00:54:22 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 03 Nov 2016 00:54:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 71270.5545.bm@omp1046.mail.ne1.yahoo.com X-YMail-OSG: NAEb3zAVM1nPDXWe3Y5QQL3HuoOZ3TCwky.CBkXjH2uqCY.On3RUQH7Jjx0xCEQ hR1WshUbQxaSaZNITWcnKur30lCr3uqOTLI9gO8XlHggePexfJiH8NpOJRVIQa5P9v7EX8sjjGmv XUcBBzMlu7IerVv6JPKKd5ab2W3EIrU1w20l3oD62dD7kT0dnQ95e2RvjCXsgWoRVOr8bmz_Q34I AuRqJ4IDY.jnkknoTaEuI6z.SXzf9.vGYZHI1M4cZpwUl2pTr.bZLkJrUeI8Oi3LlfKc8nSg7B6v l1e7qrqgdKwVEpP.HHYwgv3qVmDI0FKh3X.1NSx3_JsuvHj45ixqecZ.Y8Rq1X.cGwuM44_6GFz7 mOwDNOyM_X9.H4f42svDfFp7lHI.NFUz2P2IOyBCTYcCwa8kWoCPzl4PlHkmX0IUf72nqRQsfXfp g3m6xXb1P3bXQdjYgmmjXGwr_UzINz7sT7a7a2bUXIvnykdTDLlXQe2t1y5Ypca2GI0CG.2OWia5 dTywtxf0kZe233OK8Rhkx Received: from jws200148.mail.ne1.yahoo.com by sendmailws101b.mail.ne1.yahoo.com; Thu, 03 Nov 2016 00:54:21 +0000; 1478134461.674 Date: Thu, 3 Nov 2016 00:54:21 +0000 (UTC) From: Sumandra Majee To: "Joel M. Halpern" , "sfc@ietf.org" Message-ID: <1993744082.43344.1478134461430@mail.yahoo.com> In-Reply-To: <692d294d-6ab4-e1f3-b99e-f45c01515ca9@joelhalpern.com> References: <692d294d-6ab4-e1f3-b99e-f45c01515ca9@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_43343_1641520353.1478134461429" Archived-At: Subject: Re: [sfc] Regarding Hierarchical Service Function Chaining (hSFC) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Sumandra Majee List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 00:54:24 -0000 ------=_Part_43343_1641520353.1478134461429 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I will.=C2=A0=20 On Wednesday, November 2, 2016 5:13 PM, Joel M. Halpern wrote: =20 After the July IETF meeting, we adopted https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ The authors have some revisions as per earlier discussions. There has not been much discussion of this document on the list. Before we conclude that this is done, it would be good, as per the=20 slides from that meeting=20 (https://www.ietf.org/proceedings/96/slides/slides-96-sfc-7.pdf, last=20 slide) to have a couple of reviews. Are there a couple of working group members (not authors of this=20 document) who can take the time and have the interest to review this? Thank you, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc =20 ------=_Part_43343_1641520353.1478134461429 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I will. 


On Wednesday, November= 2, 2016 5:13 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:


After the July IETF mee= ting, we adopted
https://datatracker.ietf.org/doc/draft= -ietf-sfc-hierarchical/

The authors have some revisions as per e= arlier discussions.
There has not been much discussion of this document = on the list.
Before we conclude that this is done, it would be good, as = per the
slides from that meeting
(https://www.ie= tf.org/proceedings/96/slides/slides-96-sfc-7.pdf, last
slide) to ha= ve a couple of reviews.

Are there a couple of working group members = (not authors of this
document) who can take the time and have the inter= est to review this?

Thank you,
Joel

______________________= _________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org= /mailman/listinfo/sfc


------=_Part_43343_1641520353.1478134461429-- From nobody Wed Nov 2 23:55:09 2016 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 8548C129496 for ; Wed, 2 Nov 2016 23:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 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=-1.497, 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 yulsztkXeZY0 for ; Wed, 2 Nov 2016 23:55:06 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.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 497D21293D6 for ; Wed, 2 Nov 2016 23:55:06 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 6F10320353; Thu, 3 Nov 2016 07:55:04 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 48E6B4006C; Thu, 3 Nov 2016 07:55:04 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 07:55:04 +0100 From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] NSH MD-1 description Thread-Index: AQHSNTNa93s1B3EwwkeFhV4QxJ/iUKDG073A Date: Thu, 3 Nov 2016 06:55:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DA78EA@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.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH MD-1 description 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, 03 Nov 2016 06:55:07 -0000 Hi Joel, Agree.=20 Please consider processing this ticket to record the WG feedback: https://t= rac.tools.ietf.org/wg/sfc/trac/ticket/22=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > Envoy=E9=A0: mercredi 2 novembre 2016 18:57 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] NSH MD-1 description >=20 > > Given that various existing MD-1 proposals break up the "4" fields in > various ways, and given that we may want to allow , for example, a singl > 64 bit field in some MD-1 allocation, it seems cleaner and more > consistent to me to describe the MD-1 content as a block of 16 bytes > rather than as 4 4 byte words. >=20 > Given that this is purely descriptive for the NSH document, I do not see > a down side. YANG models for metadata are a more complex question, but > the simple 4x4 byte representation is probably not want we want there > either. >=20 > Yours, > Joel >=20 > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Nov 3 00:01:11 2016 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 738E8129407 for ; Thu, 3 Nov 2016 00:01:09 -0700 (PDT) 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, 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 UbCXUOfomnIS for ; Thu, 3 Nov 2016 00:01:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA163129467 for ; Thu, 3 Nov 2016 00:01:06 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 426132643E7; Thu, 3 Nov 2016 08:01:05 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 971ED238089; Thu, 3 Nov 2016 08:01:04 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 08:01:04 +0100 From: To: "Surendra Kumar (smkumar)" , Dave Dolson , Adrian Farrel , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAB8If2AADzdLoA== Date: Thu, 3 Nov 2016 07:01:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DA9905@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <15233159ac6a4f3792284537082dec7c@XCH-RCD-020.cisco.com> In-Reply-To: <15233159ac6a4f3792284537082dec7c@XCH-RCD-020.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.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.3.3616 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 07:01:09 -0000 Hi Surendra,=20 It seems to me that we are trying to modifyi the SFC data plane architectur= e to accommodate a given control plane solution proposal. As an editor of the SFC CP requirements I-D, I don't remember this "flexibi= lity" requirement was raised.=20 Can you please elaborate on why it is useful to have this control function? Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Surendra Kumar > (smkumar) > Envoy=E9=A0: jeudi 3 novembre 2016 00:46 > =C0=A0: Dave Dolson; Adrian Farrel; 'Joel M. Halpern'; sfc@ietf.org > Objet=A0: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > At the risk of spiraling (borrowing Adiran), this reasoning begs the > question - why even have non-classifier SFs touch the SI to start with ? > I would argue to leave it alone and treat SPI+SI as a forwarding state an= d > opaque to SFs. >=20 > Control plane can weave the same SF instance into thousands (well, it is = a > 24bit SPI) of SPIs and that shouldn't be a concern for the SF - consume > metadata and service traffic. >=20 > Allowing for control plane programmed decrement value is very reasonable > and useful. >=20 > Surendra. >=20 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Wednesday, November 02, 2016 1:51 AM > To: Adrian Farrel ; Surendra Kumar (smkumar) > ; 'Joel M. Halpern' ; sfc@ietf.or= g > Subject: Re: OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > Adrian, > Perhaps I'm making too fine a point, but I consider that if an SF does > anything other than decrementing the SI by 1, we've entered the realm of > reclassification, and it is a Classifier co-located with the SF that is > overriding the SPI/SI. >=20 > If you refer to Figure 8, path selection is not an action done by an SF. >=20 > Once reclassification is added to a deployment, we can have unicorns (and > also dragons); much more becomes possible, but it also becomes much more > difficult to reason about. >=20 > You can read in the (expired) draft-penno-sfc-packet-03 some ideas about > packet reversal that depending heavily on rigid SF decrement-by-one. I > don't know how to begin reasoning about reverse forwarding once > reclassification is added... >=20 > For those reasons, I would prefer to see the SF action limited to > decrement-by-one. If you require otherwise, co-locate a classifier with > the SF. >=20 >=20 > -Dave >=20 >=20 >=20 > Original Message > From: Adrian Farrel > Sent: Tuesday, November 1, 2016 9:52 PM > To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern'; > sfc@ietf.org Reply To: adrian@olddog.co.uk > Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing > service function path index] >=20 >=20 > Been thinking about this instead of sleeping. >=20 > Keep getting caught in rat-holes that say "no, but you could build produc= t > like this." But they are real rat-holes. What we need is a set of rule > that work for simple implementations *and* that do not preclude more > sophisticated implementations. >=20 > So... >=20 > When a packet arrives at an SFF the SPI/SI indicates the SFP and the next > hop on that SFP to be executed. >=20 > When an SF has finished processing a packet the default behavior is to > leave the SPI unchanged and to decrement the SI by 1. >=20 > However, and SF MAY know to make other changes to a the SPI and SI. How > that knowledge is installed in the SF is implementation dependent: > - it may be the result of configuration (for example, normally decrement > by > 1 but in event of a specific condition forward to a different chain) > - it may be the result of a policy and visibility of the SFP > - it may be based on information in the metadata > - there may be unicorns >=20 > There may be a classifier co-resident with the SF or in the path from SF > back to SFF so that the SPI/SI received by the SFF is not a simple > decrement of the SI. >=20 > There may be a classifier co-resident with the SFF that processes the > packet before the SFF performs forwarding so that the SPI/SI received by > the SFF is not a simple decrement of the SI. >=20 > The SFF's routing lookup may give it a choice of SFIs or SFFs to which to > send the packet for the given SPI/SI. How it resolves this choice is a > local matter (some policy that might be load balancing and could be > influenced by any manner of things if an implementation chooses without > prejudice to the interoperability of replaceability of SFFs). The fact of > the choice is a function of how the network has been built, and how SFIs > have been assigned, and how the SFPs have been constructed by the > controller - it is not a function of the NSH itself. >=20 > The SFF's forwarding instructions can be simple (look up SPI/SI and send > the packet out of interface X encapsulated in tunnel Y) or more complex > (make some form of choice and manipulate the packet) just as in most othe= r > modern forwarding paradigms. >=20 > An SFF that does not recognise the SPI/SI (i.e., has no forwarding state > for it) can only (read MUST) drop the packet. >=20 > What forwarding state an SFF has is a matter of: > - implementation > - control/management plane instructions > - visibility into the SFP (and other SFPs) >=20 >=20 > I believe this set of rules is consistent with 7665 and also supports wha= t > the WG wanted to achieve with the NSH draft without requiring any > limitation on processing. That is, a simple implementation as envisaged b= y > the proponents of "MUST decrement by one" is able to perform that functio= n > and still be conformant and interoperable. Similarly, a simple SFF as > suggested in this thread would have no problems interoperating. >=20 > Similarly, this behavior is flexible enough to allow for other uses and > implementations. It is consistent with draft-mackie-bess-nsh-bgp-control- > plane > (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all= ) > and allows a control plane to program an SFF to do more sophisticated > things. Of course, if the SFF cannot do those things then that will be OK > since it won't support those control plane instructions. >=20 > Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 > section > 4 as follows: >=20 > OLD > 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. > NEW > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > service index. By default the SF decrements the SI by 1, but it > MAY apply other decrements according to configuration and other > information available to it. If an SFF receives a packet with > an SPI and SI for which it does not have forwarding state, > it MUST be drop the packet, and SHOULD log the event subject to > rate limiting on such logs. > END >=20 > Similarly later in the same bullet... > OLD > 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. > NEW > 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. By default the SFC Proxy decrements the SI by 1, > but it MAY apply other decrements according to configuration and > other information available to it. > END >=20 > Furthermore, in section 3.3 since the term "egress NSH packet" is either > ambiguous or neglects the possibility of reclassification... >=20 > OLD > 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. > NEW > Service Index MUST be decremented by Service Functions or by SFC > Proxy nodes after performing required services as described in > Section 4. 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. > END >=20 >=20 > Now perhaps I can sleep :-) >=20 > Adrian >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 23:22 > > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern'; > > sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > I agree that the SF should be simple. > > But don't confuse decrementing the SI with complexity. > > There is absolutely no configuration required to have the SF decrement > > the SI > of > > every packet. > > And there is a lot of benefit to keeping the SFF from having rules > > about > packet > > source. > > > > As far as I'm concerned, the SF decrements the SI, and it has been > > described > this > > way for a long time. Furthermore, the forwarding is described as a > > lookup > table > > based on SPI/SI. There is no mention of the source in the forwarding > table. > > > > > > > > > > Original Message > > From: Surendra Kumar (smkumar) > > Sent: Tuesday, November 1, 2016 7:03 PM > > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > > > Since the forwarders already exists, they are logical components to > > support > and > > perform NSH based forwarding - forwarding on SFPs, rather than treat > > them as dumb forwarders. There is benefit to be had, offloads being > > one of them, on > top > > of end of chain forwarding, etc. needed. > > > > I would rather have SFs focus on servicing the traffic than be > > burdened with > SPI > > management (whether it is tens or thousands of SPIs) and the > > forwarding thereof. IOW, consume metadata and service traffic and > > leave the SFP management to the external forwarders. This not only > > simplifies the SFs, it > also > > reduces the control plane touch point as it concerns to the SPI > management. > > > > And you don't need complex logic to differentiate between traffic > > received > from > > one SFF or a SF, this is what we addressed in the forwarding draft - > > trivial > to > > implement even in hardware. > > > > Thanks, > > Surendra. > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: Tuesday, November 01, 2016 1:27 PM > > To: adrian@olddog.co.uk; 'Joel M. Halpern' ; > > sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > Adrian, > > Thank you for paraphrasing in a clear manner. > > > > Yes, I'm saying that the current (as I understand it) design permits > > the SFF > to be a > > simple forwarder, not needing to discriminate between packets from > > another SFF or returning from an SF. > > A single forwarding table handles both cases. > > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > > > So it could tell the difference, but doesn't need to. > > In some cases, an SFF can be a single-interface device, so "from SFF" > > or "from > SF" > > is not as simple as checking ingress interface, for example. > > > > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Tuesday, November 01, 2016 4:00 PM > > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > Just clarifying my understanding of what you said (not necessarily > > agreeing > ;-) > > > > You are saying that an SFF is simply a forwarder and cannot tell the > difference > > between a packet received on a transport tunnel from another SFF and a > > packet received (back) from an SF that it serves. > > > > Or, more precisely, you are saying that the SFF is simply a forwarder > > that cannot tell the difference between passing a packet to a local SF > > and passing > a > > packet on to a remote SFF. > > > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > > > Is that your point? > > > > Cheers, > > Adrian > > > > -- > > Support an author and your imagination. > > Tales from the Wood - Eighteen new fairy tales. > > More Tales from the Wood - Eighteen MORE new fairy tales. > > https://www.feedaread.com/profiles/8604/ > > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > > Or buy from me direct. > > > > > > > > > -----Original Message----- > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > Sent: 01 November 2016 19:35 > > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > > Subject: RE: [sfc] decrementing service function path index > > > > > > The SF decrements the index so that the SFF doesn't have to look at > > > the > packet > > > origin in order to determine whether or not to decrement it. > > > We don't want the SFF to have logic like: > > > If NSH packet is from one of addresses x, y z > > > Decrement SI > > > > > > As currently defined, the SFF simply routes packets by SPI/SI > > > without having > > to > > > do consider source address. > > > > > > > > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > > Sent: Tuesday, November 01, 2016 2:48 PM > > > To: 'Joel M. Halpern'; sfc@ietf.org > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > With regard to the architectural components, the NSH draft does > > > > not define those. It is using the architectural, logical, > > > > components and architecture defined by the SFC Architecture > documents. > > > > > > I'd like to understand where in 7665 it says that the SF is > > > responsible for moving the packet on to the next SF in the path, > rather than the SFF. > > > > > > I'd also like to understand why the NSH document (that tells us how > > > to encapsulate, and what to do at each hop in the path) needs to > > > divide the responsibility for bits of protocol work between > > > different logical > functional > > > entities. In short, why does the SF decrement the SI, why isn't this > > > an SFF function? What benefit comes from doing it this way or did a > > > choice simply > > have > > > to be made? > > > > > > 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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Nov 3 06:02:20 2016 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 B8B65129418 for ; Thu, 3 Nov 2016 06:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 uPv4FG_kNIFX for ; Thu, 3 Nov 2016 06:02:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5B012958E for ; Thu, 3 Nov 2016 06:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1478178133; x=1479387733; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NIcgAXtpcSLimU7srqtRLzztYMDK4B/lN/OGJaOKb90=; b=TzTDCJcOCQBKk0ZrQThwJDm2FS8Yxs7BdaJjiGEoZedVndNJReFnKxEB VIjcr7vg+DTFei9C06YlsUOGVz5kPbssyvce09JdNVpJA+ZJi61jmhtjW GSS59L2VwtsnF/yg9M3xaUtWtiJHt9/qkEtSWaS6TMpDFi0ZhlNsfk5tr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvAQDNNBtY/5JdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzABAQEBAR9YfAeNMJcAlEeCCB0LhXoCGoILPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEEAQEBIBE6GwIBCBoCIwMCAgIlCxQBEAIEARKIVg6tdo0CAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWBCYU2gX2CWIQ3gxQtgi8FmiABhjOKCYFuhG+JLYcnhXa?= =?us-ascii?q?EAwEeN2uDIx+BXXIBhm2BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,438,1473120000"; d="scan'208";a="167000570" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2016 13:02:03 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uA3D208a026161 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2016 13:02:00 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 08:01:59 -0500 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, 3 Nov 2016 08:01:59 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] NSH MD-1 description Thread-Index: AQHSNTNdPW364iTbUU++CFSiySTzt6DHJ9KAgAAjd4A= Date: Thu, 3 Nov 2016 13:01:59 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933009DA78EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DA78EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: text/plain; charset="utf-8" Content-ID: <9006D3974DB5A542AE17E9131899F6C1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH MD-1 description 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, 03 Nov 2016 13:02:19 -0000 SGkgTWVkLA0KDQpJIHdpbGwgcHJvY2VzcyB0aGUgdGlja2V0IGFuZCB1cGRhdGUgaXQuDQoNCkpp bQ0KDQoNCg0KT24gMTEvMy8xNiwgMjo1NSBBTSwgInNmYyBvbiBiZWhhbGYgb2YgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSIgPHNmYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KPkhpIEpvZWwsDQo+DQo+QWdy ZWUuIA0KPg0KPlBsZWFzZSBjb25zaWRlciBwcm9jZXNzaW5nIHRoaXMgdGlja2V0IHRvIHJlY29y ZCB0aGUgV0cgZmVlZGJhY2s6IGh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zZmMvdHJh Yy90aWNrZXQvMjIgDQo+DQo+VGhhbmsgeW91Lg0KPg0KPkNoZWVycywNCj5NZWQNCj4NCj4+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKb2VsIE0uIEhhbHBlcm4NCj4+IEVudm95w6kgOiBt ZXJjcmVkaSAyIG5vdmVtYnJlIDIwMTYgMTg6NTcNCj4+IMOAIDogc2ZjQGlldGYub3JnDQo+PiBP YmpldCA6IFtzZmNdIE5TSCBNRC0xIGRlc2NyaXB0aW9uDQo+PiANCj4+IDxzcGVha2luZyBhcyBh IHBhcnRpY2lwYW50Pg0KPj4gR2l2ZW4gdGhhdCB2YXJpb3VzIGV4aXN0aW5nIE1ELTEgcHJvcG9z YWxzIGJyZWFrIHVwIHRoZSAiNCIgZmllbGRzIGluDQo+PiB2YXJpb3VzIHdheXMsIGFuZCBnaXZl biB0aGF0IHdlIG1heSB3YW50IHRvIGFsbG93ICwgZm9yIGV4YW1wbGUsIGEgc2luZ2wNCj4+IDY0 IGJpdCBmaWVsZCBpbiBzb21lIE1ELTEgYWxsb2NhdGlvbiwgaXQgc2VlbXMgY2xlYW5lciBhbmQg bW9yZQ0KPj4gY29uc2lzdGVudCB0byBtZSB0byBkZXNjcmliZSB0aGUgTUQtMSBjb250ZW50IGFz IGEgYmxvY2sgb2YgMTYgYnl0ZXMNCj4+IHJhdGhlciB0aGFuIGFzIDQgNCBieXRlIHdvcmRzLg0K Pj4gDQo+PiBHaXZlbiB0aGF0IHRoaXMgaXMgcHVyZWx5IGRlc2NyaXB0aXZlIGZvciB0aGUgTlNI IGRvY3VtZW50LCBJIGRvIG5vdCBzZWUNCj4+IGEgZG93biBzaWRlLiAgWUFORyBtb2RlbHMgZm9y IG1ldGFkYXRhIGFyZSBhIG1vcmUgY29tcGxleCBxdWVzdGlvbiwgYnV0DQo+PiB0aGUgc2ltcGxl IDR4NCBieXRlIHJlcHJlc2VudGF0aW9uIGlzIHByb2JhYmx5IG5vdCB3YW50IHdlIHdhbnQgdGhl cmUNCj4+IGVpdGhlci4NCj4+IA0KPj4gWW91cnMsDQo+PiBKb2VsDQo+PiANCj4+IDwvc3BlYWtp bmcgYXMgYSBwYXJ0aWNpcGFudD4NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5n IGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0K From nobody Thu Nov 3 06:05:46 2016 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 C5B4812941E for ; Thu, 3 Nov 2016 06:05:45 -0700 (PDT) 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, 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 Rj-Wf1f38WQD for ; Thu, 3 Nov 2016 06:05:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA097129418 for ; Thu, 3 Nov 2016 06:05:38 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 6DE0C2DC1B9; Thu, 3 Nov 2016 14:05:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.42]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4B5E04C09A; Thu, 3 Nov 2016 14:05:37 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 14:05:37 +0100 From: To: "Roberta Maglione (robmgl)" Thread-Topic: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-radius-00.txt Thread-Index: AQHSLcmZLa6Ssga+Y0mKdc8a+TR+qKDFhEcwgAHDqIA= Date: Thu, 3 Nov 2016 13:05:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DABD03@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <147651526420.14954.691320262825038260.idtracker@ietfa.amsl.com> <7b056fd8879c42a0ad63417586dff2a4@XCH-RCD-009.cisco.com> <787AE7BB302AE849A7480A190F8B933009D96F6E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7ba24d5130e3472f9c8bbd94c2ebda57@XCH-RCD-009.cisco.com> In-Reply-To: <7ba24d5130e3472f9c8bbd94c2ebda57@XCH-RCD-009.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.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.3.123617 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-radius-00.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, 03 Nov 2016 13:05:45 -0000 Hi Roberta,=20 Thank you for taking care of my comments. Much Appreciated! I still have the following points that I want to discuss:=20 * Identify the control interface targeted by this solution in reference to = the SFC CP architecture defined in draft-ietf-sfc-control-plane * Call out explicitly (in a dedicated section, preferably) the control requ= irements that are not covered by this specification * Consider defining one "SFC Classification Control" RADIUS attribute. This= attribute may carry one or multiple SFC TLVs (SPI, SI, Metadata IDs, ...).= BTW, some of these TLVs may be used if someone wanted to define dedicated = RADIUS attributes used to control SFFs or SFC-aware SFs. Cheers, Med > -----Message d'origine----- > De=A0: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com] > Envoy=E9=A0: mercredi 2 novembre 2016 11:02 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: sfc@ietf.org > Objet=A0: RE: [sfc] FW: New Version Notification for draft-maglione-sfc-n= sh- > radius-00.txt >=20 > Hi Med, > We posted a new version of this draft to address your comments. > Best Regards > Roberta >=20 >=20 >=20 >=20 > Roberta Maglione > TECHNICAL SOLUTIONS ARCHITECT > GSP Architecture > robmgl@cisco.com > Tel: +39 039 629 5758 > Cisco Systems, Inc. > Via Torri Bianche 8 > VIMERCATE > 20871 > Italy > cisco.com >=20 >=20 > Think before you print. > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosur= e > by others is strictly prohibited. If you are not the intended recipient > (or authorized to receive for the recipient), please contact the sender b= y > reply email and delete all copies of this message. > Please click here for Company Registration Information. >=20 >=20 >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, October 24, 2016 9:38 AM > To: Roberta Maglione (robmgl) ; sfc@ietf.org > Subject: RE: [sfc] FW: New Version Notification for draft-maglione-sfc- > nsh-radius-00.txt >=20 > Hi Roberta, >=20 > Thank you for sharing this draft. Some comments below: >=20 > * You may consider the template in https://tools.ietf.org/html/draft-ietf= - > radext-datatypes-08#section-2.1.3 for defining the RADIUS attributes. >=20 > * This draft is an implementation of the "C1: Interface between SFC > Control Plane & SFC Classifier" interface: > https://tools.ietf.org/html/draft-ietf-sfc-control-plane-08#section-3.3.1= . > Having a reference to the CP architecture would be helpful. If you can > indicate which requirements from the CP document you are targeting, this > would be even appreciated. >=20 > * The draft focuses on two pieces of information that can be instructed > via the CP. I do agree those two are important ones, but I wonder whether > those are sufficient to cover SFC needs in the broadband case. For > example, how to demux among multiple services to be delivered to the same > subscriber? Do you assume that other control protocols are used to > instruct the classification rules or this is done by RADIUS? >=20 > * Because NSH-SI may be bound to a given path, the presence of NSH-SPI > attribute may be required. BTW, I wonder whether you can define a "SFC > Rule" RADIUS attribute that can convey one or many SFC-related TLVs (e.g.= , > NSH-SPI, NSH-SI, etc.). >=20 > Thank you. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Roberta Maglione > > (robmgl) > > Envoy=E9=A0: samedi 22 octobre 2016 11:52 > > =C0=A0: sfc@ietf.org > > Objet=A0: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh= - > > radius-00.txt > > > > Hello, > > We submitted this document about Radius attributes for NSH. > > The draft is targeted at addressing Broadband access use cases. > > Your comments are welcome. > > Best Regards > > Roberta > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Saturday, October 15, 2016 9:08 AM > > To: Guillermo Trueba (gtrueba) ; Roberta Maglione > > (robmgl) ; Carlos Pignataro (cpignata) > > > > Subject: New Version Notification for > > draft-maglione-sfc-nsh-radius-00.txt > > > > > > A new version of I-D, draft-maglione-sfc-nsh-radius-00.txt > > has been successfully submitted by Roberta Maglione and posted to the > > IETF repository. > > > > Name: draft-maglione-sfc-nsh-radius > > Revision: 00 > > Title: RADIUS Attributes for NSH > > Document date: 2016-10-14 > > Group: Individual Submission > > Pages: 10 > > URL: https://www.ietf.org/internet-drafts/draft-maglione-sfc= - > > nsh-radius-00.txt > > Status: https://datatracker.ietf.org/doc/draft-maglione-sfc-nsh= - > > radius/ > > Htmlized: https://tools.ietf.org/html/draft-maglione-sfc-nsh- > radius- > > 00 > > > > > > Abstract: > > Network Service Header (NSH) protocol defines the Service Function > > Chaining (SFC) encapsulation required to support the Service Functio= n > > Chaining (SFC) Architecture. One of the components of the Network > > Service Header (NSH) protocol is the Service Path Identifier (SPI), > > which identifies a service path, another important element of the NS= H > > protocol is the Service Index (SI), which provides location within > > the Service Path. > > > > When Service Providers would like to deliver customized services > > offers requiring Service Functions Chains, a different service chain > > may be required for each subscriber or group of subscribers. In > > order to simplify the service provisioning in this scenario, it woul= d > > be useful to be able to associate the Service Path Identifier (SPI), > > identifying the service chain, and the appropriate Service Index > > (SI), identifying the location in the service path, with the custome= r > > profile. > > > > In some Broadband networks, the customer profile information may be > > stored in Authentication, Authorization, and Accounting (AAA) > > servers. This document specifies two new Remote Authentication Dial= - > > In User Service (RADIUS) attributes to carry the Service Path > > Identifier (SPI) and the Service Index (SI). > > > > > > > > > > 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 Thu Nov 3 06:21:00 2016 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 71BBA1295B6 for ; Thu, 3 Nov 2016 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=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 BhuXNwG9N6BG for ; Thu, 3 Nov 2016 06:20:56 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0113.outbound.protection.outlook.com [104.47.40.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF8B129567 for ; Thu, 3 Nov 2016 06:20:56 -0700 (PDT) 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=vdNuINlsSB7pTMA1dxquga0hrWs3WPIoDZKW7QLFTL4=; b=kspcKHoq8icnheLq7O7mQJNOh6kwHsScAOEToZhFgzQNROZXzvzv6NwczJqcLDogHYu0pcjNOTHIgAFdTEkLpqMwlTJy9/KRtaFzbn/1uhhwz5mQ6wA0nVwBku1PKRu+Ije74BOlq3pnvuHdg7ZuekBvxX6/7XlEIgUfpRTfFGA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.33.219] (66.129.241.13) by SN1PR05MB2191.namprd05.prod.outlook.com (10.169.124.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Thu, 3 Nov 2016 13:20:53 +0000 To: Dave Dolson , Adrian Farrel , "'Surendra Kumar (smkumar)'" , "'Joel M. Halpern'" , "sfc@ietf.org" References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> From: Eric C Rosen Message-ID: <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> Date: Thu, 3 Nov 2016 09:20:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161102085050.5697621.72811.116410@sandvine.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CY1PR12CA0057.namprd12.prod.outlook.com (10.163.230.25) To SN1PR05MB2191.namprd05.prod.outlook.com (10.169.124.139) X-MS-Office365-Filtering-Correlation-Id: 54ed19a6-1489-41bf-180f-08d403ec3dc9 X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 2:irFyNMHWGYai2dvQoHdKmVzV43LAZhGFrCk+1Fp4r9B8xVQOSEVxcNtXCh3CCFgF3vwo/xpp7rudEjJNECpihMLxpeDr77TE6+ONIN0uajpJqlMJN/QZKEpBYpG4xO6PSPH3gdPgG6bTn/zGkGFGhFOqtqvITRv+n8h5t+nUNvIRoCXjFCjJq0TGUdqtNoNiCu9XpQe3NTcGHjmZk3E3xw==; 3:rhjme95haNgk7LPxnAbDcEw/PD1idtmmQZN9AsqwJ9pBk1VLWAVYHJoNnOaRMRIEA5GZIxuCcCLTcQdPGcOmYO0x+4elC93l0Hmg8QRcx0wo85RJTI3RkaiHxnHOQhxXgSTm5Tu4IE9O41Lyv9T6tA==; 25:zEmUROeSSYnR8ffJ24pC0VlBsyPhziGRWX7fU6y2vj/78GJrDgkRfT8D9BUBVXrl0vsHevOFIh6yWXIu/Ir7+nLFFm3ZsEKfrnWuO94lSA0xGxSMfYJhHaoa7xYY5G/UC+N+n0c9XYoSLyz1SnE2bLZJmmxZw5d0dA/MALx42dUIXVCs6C5GMEliNSOUtRxQCz0a7mJIuZRF1VxnY+mklByjXh7EHVX2oUqJOCBv95KI+tKtaWFao/ddbRl4gVdqboAX3NAdcdUv4HGGG3CbzT+gu69ulp7zog9hthUfIJ+2yLbiJBc/m+7sz5Xqi7bO44QrHalnn6cJBC5GJb19A/igweutHZNFSqHDB3kw2dXWkzYSO0bvdr278JcJ206fjkfEGfHQr0Aqf8pMkgn9swePqoThJ5dWxcFjiOZci7YWNc+ALfacbqTR+8Kd/MvG X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR05MB2191; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 31:aA+oCdc1n9yseOENe5Fe+kbr+RW3GXI4r7rdrdnKb8+YZnfiUzqVuJc1URsU0/ksImiVCbi7LtzPkb8c+V+DaH+zH2s3fhCminHFASMjdHtPM09Uee4LnFJ5sx2tcTf4ZdTpd6G9aBe0kgO8HzKkNHsQ26YgN9ZR1x3lyDDqRz2Fqdch5aLqgs+uEJcHRp1l5QsbrO+PFBW62eaP7zKngeggYASptlZRNrpcqcJ6CwkD6v6rIP0ltBiLdg063e9Lq+6RABwlvBJLhcZCNvDOWw==; 20:1nyqQ2KbnyPWn1x2uJ6UyJsZWLGsY/9eRTh8StbgUBcnt6k0xk/h/1wJx1d6vuR6VYmUKfcP704p1fBfhzgBOviT6Bk/s18SYtc1IeWYwWupAa2+ZT7/Abrt9g1/vgm7WfUD295wqY28XwwN7HrAqmIVrrcI5gVLTdOSe0HqWeWnF4Aw7UAsNcq0XqdGCB8I+nmYgIARWjAISE5RNO4pZDJzzVElpNZS1sDMv/7BtQ5MW4kqDUjSTOmzrjX2T944yk91P1OCqRcJHXerdFSVhdphRIaolqicHweWHUlCoDUpgvrU8Af9odbMRDZYSW9psE6n0v4e9RfU30iArQq/L7YrHHL0u314horm/CTFH8JlBW6fvYugaHCTK7jzkyIWgxQk74+AyknBRXzaHimQpoVBev5SaenvwXqblR6bKTOdj1cl3KJCoRkIZzzfHzI6iEhktsacUDbPLa9FYlSu5CmHZ0su4WWZYbtfaCWOqzMwfe8jy0QDbvdsUX5aieUb14fV6IIQydFY9DBA33Gjk6qlaO16y0+Qw/Hde8PGUusYXiJPGP5N/6wfNEap6JP9ddYu/QmdOgJkVVyNQXyoIitdgerfxPoy8E4leeTzSOk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(131327999870524); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:SN1PR05MB2191; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2191; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 4:JdnyEN/igCrNEtwRFVXHeaKXY7I5MxbNiV+1M/0/B6sFa1kBjA5OM82gsfYH5SeSgA7StaiDv7a+Lq+u98nTIX3Ii+HbaoEjB5LSzJmYgAj0msZ6KiscrrzndrNkrz2pvHr9nzwQ/HmFAsUO43LBpq9UZlZvK0kySlahTZIm9Khb8N3zClFgPsAHzRd/hwCVtpbOhSio2H6eGl7ych30qeFodfULWa/skTt1dDQggKwgPJZpDw9FzxsLq1afs2nDZWNQYJYFfw/PSFqkj/0yFDzX8IgV3hm9tDLGzDVcTKQE8XcmBFo3w+31nYDqq+TqtfN43vObKqiGqRqHJ58s1PfGI6OwPatRom4BKI7S0VXTBrFK4hkYmObvOOZKsTlLrPoDEUh0Peydu4uOnDPlQr6n5rh8Y5SIQmsWYz4QSOjneNz3emoScSYYHvyVMXE7lp3EJZJiEUuCSmxdbILtNg== X-Forefront-PRVS: 011579F31F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(189002)(377454003)(24454002)(7846002)(189998001)(68736007)(586003)(101416001)(50466002)(6116002)(31686004)(3846002)(65806001)(66066001)(47776003)(65956001)(31696002)(64126003)(33646002)(106356001)(77096005)(36756003)(86362001)(65826007)(42186005)(5660300001)(76176999)(8676002)(5001770100001)(81166006)(97736004)(50986999)(81156014)(105586002)(2906002)(54356999)(4001350100001)(107886002)(7736002)(305945005)(83506001)(92566002)(23746002)(230700001)(2501003)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2191; H:[172.29.33.219]; 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: =?Windows-1252?Q?1; SN1PR05MB2191; 23:ufeskTuEvcRPhZtF7o8UcBW5OQUAoH1Iqr8CY?= =?Windows-1252?Q?2GKEscOKx7acCc8vWn3SfSNdW1qgXsKmiZyi65UvVYYGsZ7wHeZjRmmM?= =?Windows-1252?Q?U+6gKW+EPcus1E39LWPP1M4Bg8uSi1XErBOUmHrjTBJM4gt5xlFlIhuY?= =?Windows-1252?Q?y3yx/w1Lu6zCXiMWemTfeQL2f95SKhHd7IU9KcE1XKnEs29PFRCC1A0j?= =?Windows-1252?Q?Bx9/6RMttW7sSF/JgFqof+/c1Y+Q07OqnImnZEEtcDBowtwaNf8QOAkH?= =?Windows-1252?Q?+a+Yp/+A65HSB+Ms56FNzcEqe2PIuYij8rswbF2Q6sf7cwQC9imgY9TG?= =?Windows-1252?Q?Fm2s60haIUOE4lh6RDMqOBchZHrBo4/MwL4HCcD9/r+mA1AEeWT334iR?= =?Windows-1252?Q?AtI+Jk/7QWfuQH51uBOJL6ibi+jmpW8zvOpWjJImTq7taTC7qfrMklTE?= =?Windows-1252?Q?JQEsykdyJ0mjVNmQHEoPICdDOEepMJvDKURzqN1+xoJq2sLlyYDMbZyQ?= =?Windows-1252?Q?F8Krw9MnZxJf3mePWMW2fUdxmteBS8XjbunRZvzXyy6uqKCjFWoFSnol?= =?Windows-1252?Q?hPjhYScIhN8zBo3AQKUELlz0/uW2p0F6fCK0jIAfpl2PdGmcHxL2R0D0?= =?Windows-1252?Q?3B0Mpyb0plHnJMhMKSPOie31YTM2V1YNpeal3PXRSX3A03vCoOREbfrQ?= =?Windows-1252?Q?4ynOdSAJ3mMHp8g0Q9A+OpNzP88Prgfl8tCQI5Zcudn+CzxS4sOZZzkf?= =?Windows-1252?Q?yMnFkoE3j2ogZF1Dpdc0fJElgIlXq4LyL5IcxpMPcTlOkTTeXA212kmX?= =?Windows-1252?Q?nreHnq8azMNsj03U1Vpcz0xuYfor91xFefxkyNbLqz5UyPl1a3rV5tNt?= =?Windows-1252?Q?6yqUH7fXGXLycu+puoaDl/a7tF/uDq4Tuxf6is/lw0HQAFY6Cxg3T70Z?= =?Windows-1252?Q?R9+hef3DCZJOGr/3f22iQB5FBEkI+ljyekLOFOLAERKvZu4knCqQEYXB?= =?Windows-1252?Q?z644oFn7rQRjrufMnPhzER0vKP4XP1kNFm+ROgXw1upBKUCRFtLwU21j?= =?Windows-1252?Q?Aa37xKw5mZJU1fH/6CwG8ps/CsaNqXHi2uN4dllv4xpheOcPLm0/lSU3?= =?Windows-1252?Q?PUan9v+sl/mA3uPmDjO5UAl/4c8po7RPA6K0v5bAbnDDdmNuK+TcbFT3?= =?Windows-1252?Q?HiyWleooa1dF+4Mnc+9HMc759iHFMWPwQEh8VUIzm26qUix/pa35usRT?= =?Windows-1252?Q?2W+F5qV594lREJSv4yvg2rLexizy8SX8sUCJgr/6Ge87CVHitk25AwGE?= =?Windows-1252?Q?8FB8GHtsCJTFKUPf1sW4c8OoA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 6:JyamdERkn7yLU3unlj6EkGkSrwFnZr3tItItlA+7Al5m/dGCeNihaFnBY+7Wg6tqkP5ZOAE/7eUa46xKZ4FjNyNvDEqleXi5OVMHMfUGB6zayRYSTDHngY6bFcuKtF1XoqQvv1mQG1w4qZR63kPgukigx+YYkOSdOGE91dQArVSHPXrwvhCfDq2t08NXzFwG53sBKCfpiefpAIZjwmDeUvzDDvw3B5UrHrsx3msFgFviWilPlKU00pDpuTOqklAm+XlzGrDE93mVGY1IMACX18ucxY8fH6hLpjbsVtRUP7zaefH2PTyzNRa21BO5n4XH+BEyQDZktxeBcx9X5MumG8XTEdPaLQySFp2JInV+Wlk=; 5:5Uf9E6MHHKM4Njx/vSsP//FBsEOtRpogL5sB/TO5mKek/yzZEXPv+r88N8f94xq0hyzuv1T9ynQUN62h7qs+L1M8uzZsTFoFtnKyuRWET6+Xw5mwWEA8OTqewrrMtcsk3j3rYO/OeHAXuDC5wrw9F8RNi2eAoYTp4KixKKxvtAg=; 24:HbTmzp1k+63q70oZWu5LKI6wHYJz1oy0HCOHH4KrUtwI70g35AB8bsLgrFM6/CKs4ke9ZyaZudqz8a0XqT9rBSoRZKTmX2ScM77rgEvnwEM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 7:3bXoU4XCmr79Mir4SODNNLtzVgusdoO+RJBIz9MUCeS84C+JjphbE/5O2Kqii9JLxT5JPKntxkdpGl376eJ3N0YsWHflxInN54oTk2ajBhhTjodhT4x4PvjioaRaLqcMJfAuDEPUqgli5OpBuKvP3v//2t2sFQ9C7iBN+L2rRpVwSKcPUUfqwhVoR1WS9z7/rzYEq3wUIbKr75eUrN6i+49zGki8NHwuZCENtrc64XQSqqFLl6pL9TIHZe5m+TAVUOmCHC4PRPucKxXYVPbjFdd9R4SXJqKA+OkZZwXoY/bmPSyIi/MhxuY+84xisX9btXX4Ce2X0k8FcVAfvHbnZ28YhBylLJyPGr83y+o1UN8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2016 13:20:53.9998 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2191 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 13:20:59 -0000 On 11/2/2016 4:50 AM, Dave Dolson wrote: > For those reasons, I would prefer to see the SF action limited to decrement-by-one. If you require otherwise, co-locate a classifier with the SF. From the perspective of draft-mackie-bess-nsh-bgp-control-plane, it doesn't matter whether the SPI/SI gets modified by the SF or by a co-resident classifier. The only thing that matters is what SPI/SI values the SFF will need to use as input to its forwarding engine. A slightly different issue is whether the successive elements of an SPI have to have successive integers as their respective SI's. That doesn't seem to be necessary for the proper functioning of the system, so we didn't want to assume it. By not using successive integers, it becomes easier to insert and/or delete entries. And if the SF knows the SI (call it "x") of the current element in the chain, it doesn't really have to know the SI of the next element in the chain, since the SFF can interpret "x-1" to mean "next after x", and can then modify the NSH to change the SI to the actual SI of the next element in the chain. Does this create a technical problem of some sort? From nobody Thu Nov 3 06:29:44 2016 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 B2D40129604 for ; Thu, 3 Nov 2016 06:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 YzeA6myQi_Kh for ; Thu, 3 Nov 2016 06:29:42 -0700 (PDT) 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 E7CEB1295F9 for ; Thu, 3 Nov 2016 06:29:31 -0700 (PDT) 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, 3 Nov 2016 09:29:31 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 09:29:30 -0400 From: Dave Dolson To: Eric C Rosen , Adrian Farrel , "'Surendra Kumar (smkumar)'" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAEQaggAACEFAoA== Date: Thu, 3 Nov 2016 13:29:29 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> In-Reply-To: <528f0001-817d-5887-1c78-eabc2d09e711@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 13:29:44 -0000 Eric, I was thinking that way originally, that the SI at each hop could be arbitr= ary. But can you please take a look at https://tools.ietf.org/html/draft-penno-s= fc-packet-03, unfortunately expired. In section 5.4, there are some "algorithmic" methods of reversing packets o= n a path that become quite elegant if one can assume each hop is SI-1 from = previous. If you wish to make each hop arbitrary, you must program each SF (not only = the SFFs) with full awareness of bidirectional paths (which is section 5.1)= . -Dave -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net]=20 Sent: Thursday, November 03, 2016 9:21 AM To: Dave Dolson; Adrian Farrel; 'Surendra Kumar (smkumar)'; 'Joel M. Halper= n'; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] On 11/2/2016 4:50 AM, Dave Dolson wrote: > For those reasons, I would prefer to see the SF action limited to decreme= nt-by-one. If you require otherwise, co-locate a classifier with the SF. From the perspective of draft-mackie-bess-nsh-bgp-control-plane, it=20 doesn't matter whether the SPI/SI gets modified by the SF or by a=20 co-resident classifier. The only thing that matters is what SPI/SI=20 values the SFF will need to use as input to its forwarding engine. A slightly different issue is whether the successive elements of an SPI=20 have to have successive integers as their respective SI's. That doesn't=20 seem to be necessary for the proper functioning of the system, so we=20 didn't want to assume it. By not using successive integers, it becomes=20 easier to insert and/or delete entries. And if the SF knows the SI=20 (call it "x") of the current element in the chain, it doesn't really=20 have to know the SI of the next element in the chain, since the SFF can=20 interpret "x-1" to mean "next after x", and can then modify the NSH to=20 change the SI to the actual SI of the next element in the chain. Does this create a technical problem of some sort? From nobody Thu Nov 3 06:54:17 2016 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 78F39129632 for ; Thu, 3 Nov 2016 06:53:52 -0700 (PDT) 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 2BUni9DLGVFY for ; Thu, 3 Nov 2016 06:53:43 -0700 (PDT) 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 2DDED129A12 for ; Thu, 3 Nov 2016 06:53:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1D284245C2D; Thu, 3 Nov 2016 06:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478181189; bh=tlXoaqnOIPJhBUF1JkwPLW/eQy8d7hq6VwUM6DqVpCs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cqHePUkiNFdD3wUL9xSh48MjXPlXhuhWQ6k5/v0Sx7tE3Fo5UKdAiQtz8KAEyhQCp oZrCjQM14b1zPF+qmkNTqdEbdj+oZHLPjMIqdES9DIug5aRqmrRDXd4SgxvD9ZTbL4 XJFMOGX2NSkBkmQnpiKCGD9+XYld9otcW1hmQH3A= 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 6499B240E0F; Thu, 3 Nov 2016 06:53:08 -0700 (PDT) To: Eric C Rosen , Dave Dolson , Adrian Farrel , "'Surendra Kumar (smkumar)'" , "'Joel M. Halpern'" , "sfc@ietf.org" References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> From: "Joel M. Halpern" Message-ID: Date: Thu, 3 Nov 2016 09:55:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 13:53:52 -0000 You ask whether using non-consecuitive integers for the SI in the path breaks something. It is not forbidden. You can, after all, reclassify at every hop. (And many current solutions do so.) However, it is misleading as to the intent and expected usage of SFC. While one can manage to make it work with monotonically decreasing but non-consecutive SI, it is significantly more complex. As far as I can tell, the place where this is an issue for the BGP SFC control draft is not in the protocol definition. Rather, it is in the examples which all treat non-consecutive as the normal case. This is confusing to readers and likely to drive folks towards assumptions about SFC behavior that will not work without additional mechanisms. Yours, Joel On 11/3/16 9:20 AM, Eric C Rosen wrote: > On 11/2/2016 4:50 AM, Dave Dolson wrote: >> For those reasons, I would prefer to see the SF action limited to >> decrement-by-one. If you require otherwise, co-locate a classifier >> with the SF. > > From the perspective of draft-mackie-bess-nsh-bgp-control-plane, it > doesn't matter whether the SPI/SI gets modified by the SF or by a > co-resident classifier. The only thing that matters is what SPI/SI > values the SFF will need to use as input to its forwarding engine. > > A slightly different issue is whether the successive elements of an SPI > have to have successive integers as their respective SI's. That doesn't > seem to be necessary for the proper functioning of the system, so we > didn't want to assume it. By not using successive integers, it becomes > easier to insert and/or delete entries. And if the SF knows the SI > (call it "x") of the current element in the chain, it doesn't really > have to know the SI of the next element in the chain, since the SFF can > interpret "x-1" to mean "next after x", and can then modify the NSH to > change the SI to the actual SI of the next element in the chain. > > Does this create a technical problem of some sort? > > > > > From nobody Thu Nov 3 07:53:00 2016 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 8BF9B1299E2 for ; Thu, 3 Nov 2016 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 vMXOTHwg8ZXJ for ; Thu, 3 Nov 2016 07:52:58 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F0912966A for ; Thu, 3 Nov 2016 07:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4028; q=dns/txt; s=iport; t=1478184777; x=1479394377; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Zp6yZgazbsm6kq0dExQlupE+rqlzmj0VXJ7WBe3rgLc=; b=Hc1W4xymfv+c3LEdqKclZ0hARAcyH3IEEGc7OdWYNySHmZDKCr46d3bs vVeznUVuPXd8apRib5BAorRQtqXWG7qfeOS4B9KbRQ/OzKV3XXpJlxZi6 tGbE/IBIjilIGXn1h9AEPPoxGlbxrEaRr+gi+v7NvgtUsj9oFgLUgmx2h 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQDsThtY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzABAQEBAR9YfAeNMJcAlEeCCB0LhXoCGoFmPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRiAQEEAQEBIBE6GwIBCBIGAgIfBwICAiULFQIOAgQBEhuIOw6uKY0EAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBFwWBCYU2gX2CWIQjJBeCbS2CLwWaIAGQPJAKjR2?= =?us-ascii?q?EAwEeN2uDWoFFcoU/gS+BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,587,1473120000"; d="scan'208";a="167046114" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2016 14:52:57 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uA3EquZa027120 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2016 14:52:57 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 09:52:56 -0500 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, 3 Nov 2016 09:52:56 -0500 From: "Jim Guichard (jguichar)" To: "Joel M. Halpern" , Eric C Rosen , Dave Dolson , Adrian Farrel , "Surendra Kumar (smkumar)" , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AQHSNOZBG5GoCglrWUm6r677zz7T56DHlDgAgAAJrwD//8z1AA== Date: Thu, 3 Nov 2016 14:52:56 +0000 Message-ID: <1074C8BE-A959-405B-BA6E-E15A19BEBFED@cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <528f0001-817d-5887-1c78-eabc2d09e711@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.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.99.184] Content-Type: text/plain; charset="utf-8" Content-ID: <8D538B4C9C21314FAD8179EA87F0019F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 14:52:59 -0000 W0NoYWlyIGhhdCBvZmbigKZdDQpHaXZlbiB0aGF0IHRoZSBjdXJyZW50bHkgZGVmaW5lZCBhcmNo aXRlY3R1cmUgYWxsb3dzIGZvciB0aGUgcmVxdWVzdGVkIGJlaGF2aW9yIHRocm91Z2ggcmVjbGFz c2lmaWNhdGlvbiwgSSBwZXJzb25hbGx5IHNlZSBubyByZWFzb24gZm9yIGEgY2hhbmdlIHRvIHRo ZSB3YXkgZGVjcmVtZW50IG9mIHNlcnZpY2UgaW5kZXggaXMgY3VycmVudGx5IGRlZmluZWQsIG90 aGVyIHRoYW4gbWFraW5nIGl0IGV4cGxpY2l0IHRoYXQgZGVjcmVtZW50IG1lYW5zIOKAnGJ5IDHi gJ0uDQoNCltDaGFpciBoYXQgb27igKZdDQpJIHdvdWxkIG5vdGUgdGhhdCB3ZSBhbHJlYWR5IGhh dmUgd29ya2luZyBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGN1cnJlbnQgTlNIIHNwZWNpZmljYXRp b24uIEFsc28sIHRoZSBpc3N1ZSBvZiB0aGUgZWFzZSBvZiBtb2RpZmljYXRpb24gb2YgU0ZQcyB3 YXMgcGFydCBvZiBlYXJsaWVyIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2lvbi4gIElzIHRoZXJlIG5l dyBpbmZvcm1hdGlvbiB0aGF0IHRob3NlIHJlcXVlc3RpbmcgYSBiZWhhdmlvcmFsIGNoYW5nZSB3 aXNoIHRvIGJyaW5nIGZvcndhcmQ/DQoNCkppbQ0KDQoNCg0KT24gMTEvMy8xNiwgOTo1NSBBTSwg InNmYyBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KDQo+WW91IGFzayB3aGV0 aGVyIHVzaW5nIG5vbi1jb25zZWN1aXRpdmUgaW50ZWdlcnMgZm9yIHRoZSBTSSBpbiB0aGUgcGF0 aCANCj5icmVha3Mgc29tZXRoaW5nLg0KPkl0IGlzIG5vdCBmb3JiaWRkZW4uICBZb3UgY2FuLCBh ZnRlciBhbGwsIHJlY2xhc3NpZnkgYXQgZXZlcnkgaG9wLiAgKEFuZCANCj5tYW55IGN1cnJlbnQg c29sdXRpb25zIGRvIHNvLikNCj4NCj5Ib3dldmVyLCBpdCBpcyBtaXNsZWFkaW5nIGFzIHRvIHRo ZSBpbnRlbnQgYW5kIGV4cGVjdGVkIHVzYWdlIG9mIFNGQy4gDQo+V2hpbGUgb25lIGNhbiBtYW5h Z2UgdG8gbWFrZSBpdCB3b3JrIHdpdGggbW9ub3RvbmljYWxseSBkZWNyZWFzaW5nIGJ1dCANCj5u b24tY29uc2VjdXRpdmUgU0ksIGl0IGlzIHNpZ25pZmljYW50bHkgbW9yZSBjb21wbGV4Lg0KPg0K PkFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGUgcGxhY2Ugd2hlcmUgdGhpcyBpcyBhbiBpc3N1ZSBm b3IgdGhlIEJHUCBTRkMgDQo+Y29udHJvbCBkcmFmdCBpcyBub3QgaW4gdGhlIHByb3RvY29sIGRl ZmluaXRpb24uICBSYXRoZXIsIGl0IGlzIGluIHRoZSANCj5leGFtcGxlcyB3aGljaCBhbGwgdHJl YXQgbm9uLWNvbnNlY3V0aXZlIGFzIHRoZSBub3JtYWwgY2FzZS4gIFRoaXMgaXMgDQo+Y29uZnVz aW5nIHRvIHJlYWRlcnMgYW5kIGxpa2VseSB0byBkcml2ZSBmb2xrcyB0b3dhcmRzIGFzc3VtcHRp b25zIGFib3V0IA0KPlNGQyBiZWhhdmlvciB0aGF0IHdpbGwgbm90IHdvcmsgd2l0aG91dCBhZGRp dGlvbmFsIG1lY2hhbmlzbXMuDQo+DQo+WW91cnMsDQo+Sm9lbA0KPg0KPk9uIDExLzMvMTYgOToy MCBBTSwgRXJpYyBDIFJvc2VuIHdyb3RlOg0KPj4gT24gMTEvMi8yMDE2IDQ6NTAgQU0sIERhdmUg RG9sc29uIHdyb3RlOg0KPj4+IEZvciB0aG9zZSByZWFzb25zLCBJIHdvdWxkIHByZWZlciB0byBz ZWUgdGhlIFNGIGFjdGlvbiBsaW1pdGVkIHRvDQo+Pj4gZGVjcmVtZW50LWJ5LW9uZS4gSWYgeW91 IHJlcXVpcmUgb3RoZXJ3aXNlLCBjby1sb2NhdGUgYSBjbGFzc2lmaWVyDQo+Pj4gd2l0aCB0aGUg U0YuDQo+Pg0KPj4gRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgZHJhZnQtbWFja2llLWJlc3MtbnNo LWJncC1jb250cm9sLXBsYW5lLCBpdA0KPj4gZG9lc24ndCBtYXR0ZXIgd2hldGhlciB0aGUgU1BJ L1NJIGdldHMgbW9kaWZpZWQgYnkgdGhlIFNGIG9yIGJ5IGENCj4+IGNvLXJlc2lkZW50IGNsYXNz aWZpZXIuICBUaGUgb25seSB0aGluZyB0aGF0IG1hdHRlcnMgaXMgd2hhdCBTUEkvU0kNCj4+IHZh bHVlcyB0aGUgU0ZGIHdpbGwgbmVlZCB0byB1c2UgYXMgaW5wdXQgdG8gaXRzIGZvcndhcmRpbmcg ZW5naW5lLg0KPj4NCj4+IEEgc2xpZ2h0bHkgZGlmZmVyZW50IGlzc3VlIGlzIHdoZXRoZXIgdGhl IHN1Y2Nlc3NpdmUgZWxlbWVudHMgb2YgYW4gU1BJDQo+PiBoYXZlIHRvIGhhdmUgc3VjY2Vzc2l2 ZSBpbnRlZ2VycyBhcyB0aGVpciByZXNwZWN0aXZlIFNJJ3MuICBUaGF0IGRvZXNuJ3QNCj4+IHNl ZW0gdG8gYmUgbmVjZXNzYXJ5IGZvciB0aGUgcHJvcGVyIGZ1bmN0aW9uaW5nIG9mIHRoZSBzeXN0 ZW0sIHNvIHdlDQo+PiBkaWRuJ3Qgd2FudCB0byBhc3N1bWUgaXQuICBCeSBub3QgdXNpbmcgc3Vj Y2Vzc2l2ZSBpbnRlZ2VycywgaXQgYmVjb21lcw0KPj4gZWFzaWVyIHRvIGluc2VydCBhbmQvb3Ig ZGVsZXRlIGVudHJpZXMuICBBbmQgaWYgdGhlIFNGIGtub3dzIHRoZSBTSQ0KPj4gKGNhbGwgaXQg IngiKSBvZiB0aGUgY3VycmVudCBlbGVtZW50IGluIHRoZSBjaGFpbiwgaXQgZG9lc24ndCByZWFs bHkNCj4+IGhhdmUgdG8ga25vdyB0aGUgU0kgb2YgdGhlIG5leHQgZWxlbWVudCBpbiB0aGUgY2hh aW4sIHNpbmNlIHRoZSBTRkYgY2FuDQo+PiBpbnRlcnByZXQgIngtMSIgdG8gbWVhbiAibmV4dCBh ZnRlciB4IiwgYW5kIGNhbiB0aGVuIG1vZGlmeSB0aGUgTlNIIHRvDQo+PiBjaGFuZ2UgdGhlIFNJ IHRvIHRoZSBhY3R1YWwgU0kgb2YgdGhlIG5leHQgZWxlbWVudCBpbiB0aGUgY2hhaW4uDQo+Pg0K Pj4gRG9lcyB0aGlzIGNyZWF0ZSBhIHRlY2huaWNhbCBwcm9ibGVtIG9mIHNvbWUgc29ydD8NCj4+ DQo+Pg0KPj4NCj4+DQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Thu Nov 3 09:04:16 2016 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 D512F129695 for ; Thu, 3 Nov 2016 09:04:14 -0700 (PDT) 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 8q6MvTzEtNOC for ; Thu, 3 Nov 2016 09:04:10 -0700 (PDT) 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 1018C129582 for ; Thu, 3 Nov 2016 09:04:09 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA3G47Ce005411 for ; Thu, 3 Nov 2016 16:04:07 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA3G46ev005393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 3 Nov 2016 16:04:07 GMT From: "Adrian Farrel" To: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> <1074C8BE-A959-405B-BA6E-E15A19BEBFED@cisco.com> In-Reply-To: <1074C8BE-A959-405B-BA6E-E15A19BEBFED@cisco.com> Date: Thu, 3 Nov 2016 16:04:00 -0000 Message-ID: <06ac01d235eb$e4627490$ad275db0$@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: AQHpo0mx8ZdyujIeUaNP1NloitCOPQIfaq3oAg4gK4MCuUGFuAJJlHtBoE8LjdA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22676.007 X-TM-AS-Result: No--29.343-10.0-31-10 X-imss-scan-details: No--29.343-10.0-31-10 X-TMASE-MatchedRID: u6ojmU07PKxq0U6EhO9EE8AmcZEx8XHJKx5ICGp/WtHagsZM0qVv11iN xVLlNmEJmhd3ObmK5N+ISleZ//blDZ9IQSR8n0Ff5cQFbdjxan4xXH/dlhvLvwjUDpYtiAkJika 0Ka6FTutRIhEk0jdQL7RK2nsr6fhI64YUNtZYBWEX2N9OpwN26Ld2noO4P7rALraGNlLRahhXVY XFNAu7+L6MDIdED2Dg8MeN4/x0Ua8yRohotsnq58FWmsryu9ZfLJm8FOE9WLVsmSfP7d/dpe9SC 4vr4MBRF16bSyysW+85wRlvI7O0BjsGUAvjXW8TSEQN/D/3cG5BYQa/eBpSZ2so23uKlCJjCpBB AsyHrqca03qUqg7CvaEyNcDSVcG2iRY7dy1ibPVHpZCc205uwn4yToAKzDgmncFP6l2MR7zKcBk 6JHKmQqN4IzQj/89lPk9yva2wVPxuOt28pPRUYh3EEAbn+GRbocSvEPKGO+cuYVZAyhKngRjZ3L V7kUp5lCAiBBQl50aLeS1jmVCrgiLE6me/PN6MlUgQqGVMqmydpTQE6s/cz1vym/gvSH4iCf2h9 A2gFAVTMzu+Yx3nRx8gTGk50GD1VPYguQfLAbIXrP0cYcrA2wd1gf75ubQY7bOeXnCQSYL+tnMv nQl+U49Zm8Ov7SprPDF4aOlLYwdKl5uDD6k69p4CIKY/Hg3AWQy9YC5qGvz6APa9i04WGCq2rl3 dzGQ1A/3R8k/14e0= Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 16:04:15 -0000 Gee shucks, Jim, Do you think changing "decrement" to "decrement by 1" is not a = behavioral change just because it is what you intended when (with your = chair hat off) you reviewed the document?=20 Or are you one of the people you are asking (with your chair hat on) to = bring forward new information? I, too, would like to see the NSH spec ship, but I would prefer to see = it right. Adrian PS If both you and Joel simultaneously remove your chair hats, will we = hit an iceberg? :-) PPS I find the discussion about what an SF does compared to what an SF = with a co-resident re-classifier does, to be dancing on the head of a = pin labelled "Functional Architecture". You are all welcome to implement = a functional architecture (and bless you for it), but that is not how = products are marked when they ship. You will not be selling "Firewall = with Added Reclassifier". Furthermore, the SFF will be entirely unaware = of whether reclassification took place. So (at the risk of repeating = myself), why is "SF MUST decrement by 1" a requirement in this spec, and = why is my proposed compromise text not acceptable? > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: 03 November 2016 14:53 > To: Joel M. Halpern; Eric C Rosen; Dave Dolson; Adrian Farrel; = Surendra Kumar > (smkumar); sfc@ietf.org > Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: = decrementing > service function path index] >=20 > [Chair hat off=E2=80=A6] > Given that the currently defined architecture allows for the requested = behavior > through reclassification, I personally see no reason for a change to = the way > decrement of service index is currently defined, other than making it = explicit that > decrement means =E2=80=9Cby 1=E2=80=9D. >=20 > [Chair hat on=E2=80=A6] > I would note that we already have working group agreement on the = current NSH > specification. Also, the issue of the ease of modification of SFPs was = part of > earlier working group discussion. Is there new information that those = requesting > a behavioral change wish to bring forward? >=20 > Jim >=20 >=20 >=20 > On 11/3/16, 9:55 AM, "sfc on behalf of Joel M. Halpern" = on behalf of jmh@joelhalpern.com> wrote: >=20 > >You ask whether using non-consecuitive integers for the SI in the = path > >breaks something. > >It is not forbidden. You can, after all, reclassify at every hop. = (And > >many current solutions do so.) > > > >However, it is misleading as to the intent and expected usage of SFC. > >While one can manage to make it work with monotonically decreasing = but > >non-consecutive SI, it is significantly more complex. > > > >As far as I can tell, the place where this is an issue for the BGP = SFC > >control draft is not in the protocol definition. Rather, it is in = the > >examples which all treat non-consecutive as the normal case. This is > >confusing to readers and likely to drive folks towards assumptions = about > >SFC behavior that will not work without additional mechanisms. > > > >Yours, > >Joel > > > >On 11/3/16 9:20 AM, Eric C Rosen wrote: > >> On 11/2/2016 4:50 AM, Dave Dolson wrote: > >>> For those reasons, I would prefer to see the SF action limited to > >>> decrement-by-one. If you require otherwise, co-locate a classifier > >>> with the SF. > >> > >> From the perspective of draft-mackie-bess-nsh-bgp-control-plane, it > >> doesn't matter whether the SPI/SI gets modified by the SF or by a > >> co-resident classifier. The only thing that matters is what SPI/SI > >> values the SFF will need to use as input to its forwarding engine. > >> > >> A slightly different issue is whether the successive elements of an = SPI > >> have to have successive integers as their respective SI's. That = doesn't > >> seem to be necessary for the proper functioning of the system, so = we > >> didn't want to assume it. By not using successive integers, it = becomes > >> easier to insert and/or delete entries. And if the SF knows the SI > >> (call it "x") of the current element in the chain, it doesn't = really > >> have to know the SI of the next element in the chain, since the SFF = can > >> interpret "x-1" to mean "next after x", and can then modify the NSH = to > >> change the SI to the actual SI of the next element in the chain. > >> > >> Does this create a technical problem of some sort? > >> > >> > >> > >> > >> > > > >_______________________________________________ > >sfc mailing list > >sfc@ietf.org > >https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Nov 3 09:18:05 2016 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 4FA891299EF for ; Thu, 3 Nov 2016 09:18:03 -0700 (PDT) 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 5XWIZhoQI49b for ; Thu, 3 Nov 2016 09:17:47 -0700 (PDT) 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 75DB6129A99 for ; Thu, 3 Nov 2016 09:17:39 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA3GHaZe019332; Thu, 3 Nov 2016 16:17:36 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA3GHYhk019287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2016 16:17:36 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> In-Reply-To: Date: Thu, 3 Nov 2016 16:17:28 -0000 Message-ID: <06c201d235ed$c6b752b0$5425f810$@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: AQHpo0mx8ZdyujIeUaNP1NloitCOPQIfaq3oAg4gK4MCuUGFuKBhWxoQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22676.007 X-TM-AS-Result: No--11.648-10.0-31-10 X-imss-scan-details: No--11.648-10.0-31-10 X-TMASE-MatchedRID: eVEkOcJu0F5q0U6EhO9EE/HkpkyUphL99ISHwCrIdS/9Ez/5IpHqp8dQ kfr/xU0bp8Etj0HS05ifppz9wZch4HajkeVVLImjgW5/KXM36b6EQiKo28GuY4hlq83HEbL+iO9 fzG806wvCabmDD3jjD0XXH7y2ZSql4dd+IyhmjBkER9Ta+6BEXdMGD8JuBXZPl1pBsCIx0luwgj 0/C3avGMamioxjJOTqRWEwCr8zg5wmCg+Lak4DCSpJjSywaLOw1kqyrcMalqXJYIv7y0tu9mPSx OujrIyYWVyrIuJ5LBZR4bAUYBLOxYmyWVlWymJbfoNDZMQOpmzo2Cux658RN2yZJ8/t392lHACU cDvcWyCxRNQwdoFWkYahreqt1BEa5UcZtwNsCroTNCcUsR4xSd0H8LFZNFG7bkV4e2xSge7iVrY e6xXaIdtvpFKmwKutL4ZsbTT5F4YZjOzMRARLRcWFcyN1Agmm Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 16:18:03 -0000 > You ask whether using non-consecuitive integers for the SI in the path > breaks something. > It is not forbidden. You can, after all, reclassify at every hop. = (And > many current solutions do so.) Good. We're agreed. > However, it is misleading as to the intent and expected usage of SFC. Where would the na=EFf reader find this intent and expected usage? = Clearly it doesn't show up in RFC 7665 and draft-ietf-sfc-nsh. Maybe it is in = another WG document? Anyway, perhaps that is the wrong question. Is diverging from this intent and expected usage going to break interop? = Or would it simply result in SFPs built in this unintended and unexpected = way not working for some implementations of SFFs?=20 If that is the scope of the problem then it might be worth calling out, = but it is also worth noting that central controllers need to be aware of the capabilities of the things they control - sad, but true. > While one can manage to make it work with monotonically decreasing but > non-consecutive SI, it is significantly more complex. Well, that might depend on your definition of "significant".=20 I suspect that one line of code might be enough. > As far as I can tell, the place where this is an issue for the BGP SFC > control draft is not in the protocol definition. Rather, it is in the > examples which all treat non-consecutive as the normal case. This is > confusing to readers and likely to drive folks towards assumptions = about > SFC behavior that will not work without additional mechanisms. Do you mean protocol mechanisms additional to the specifications, or = additional code mechanisms compared to something one might have coded based on an undocumented assumption of what the existing architecture means? Anyway (again), if your only concern is that the non-normative examples = do not include a use case where the SI values in the SFP are consecutive, then = I think we may be over-discussing the issue. It is easily fixed. Cheers, Adrian From nobody Thu Nov 3 09:21:25 2016 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 9069D1299F7 for ; Thu, 3 Nov 2016 09:21:24 -0700 (PDT) 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 9Q_XQxBW6QeI for ; Thu, 3 Nov 2016 09:21:22 -0700 (PDT) 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 B23E41296C3 for ; Thu, 3 Nov 2016 09:21:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9902C24B501; Thu, 3 Nov 2016 09:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478190082; bh=CD3LrbZtFIAXyIs2KHtdDlvBqNEBtLBzCPnzstwOp3Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=O7t9PmGxT1thRmjf9k1a8FIo4e/xB20/A2ieHu0l0weBoYoyp/zYUb6FDqVYbAKS7 EFVFgE9Q98ufLphWxoAeh6y14zV04+Eh1sMwcYLzeu+LV3Ppy9kVEqLvXwyfuBA4tX mDwvB5QCAYSz57k4zbyY6DbyQbBTO7MsgWoTrmT0= 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 1D9F3240E6E; Thu, 3 Nov 2016 09:21:22 -0700 (PDT) To: adrian@olddog.co.uk, sfc@ietf.org References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> <1074C8BE-A959-405B-BA6E-E15A19BEBFED@cisco.com> <06ac01d235eb$e4627490$ad275db0$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Thu, 3 Nov 2016 12:21:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <06ac01d235eb$e4627490$ad275db0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 16:21:24 -0000 Speaking from my discussions with folks about custoemr requirements (and thus not as a WG chair), the distinction between the SF and the classifier is important to at least some customers. We have had customers ask us about mechanisms to pevent SF from modifying the SPI or mis-modifying the SI. With a strong distinction in terminology and architecture I have the tools to have that discussion (including an Internet Draft I helped with on how an SFF can verify things if it chooses to). Without that distinction, it gets complicated to describe the restriction. Also, it seems that it is not just Jim and I that read the decrement as decrement by 1. While I am sure you can find contexts where decrement is used to mean any subtraction, there are also plenty of contexts where it is used to mean subtracting exactly one. Are you actually objecting that clarifying the intent is a change to the agreed meaning? Yours, Joel On 11/3/16 12:04 PM, Adrian Farrel wrote: > Gee shucks, Jim, > > Do you think changing "decrement" to "decrement by 1" is not a behavioral change just because it is what you intended when (with your chair hat off) you reviewed the document? > > Or are you one of the people you are asking (with your chair hat on) to bring forward new information? > > I, too, would like to see the NSH spec ship, but I would prefer to see it right. > > Adrian > > PS If both you and Joel simultaneously remove your chair hats, will we hit an iceberg? :-) > > PPS I find the discussion about what an SF does compared to what an SF with a co-resident re-classifier does, to be dancing on the head of a pin labelled "Functional Architecture". You are all welcome to implement a functional architecture (and bless you for it), but that is not how products are marked when they ship. You will not be selling "Firewall with Added Reclassifier". Furthermore, the SFF will be entirely unaware of whether reclassification took place. So (at the risk of repeating myself), why is "SF MUST decrement by 1" a requirement in this spec, and why is my proposed compromise text not acceptable? > >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: 03 November 2016 14:53 >> To: Joel M. Halpern; Eric C Rosen; Dave Dolson; Adrian Farrel; Surendra Kumar >> (smkumar); sfc@ietf.org >> Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing >> service function path index] >> >> [Chair hat off鈥 >> Given that the currently defined architecture allows for the requested behavior >> through reclassification, I personally see no reason for a change to the way >> decrement of service index is currently defined, other than making it explicit that >> decrement means 鈥渂y 1鈥. >> >> [Chair hat on鈥 >> I would note that we already have working group agreement on the current NSH >> specification. Also, the issue of the ease of modification of SFPs was part of >> earlier working group discussion. Is there new information that those requesting >> a behavioral change wish to bring forward? >> >> Jim >> >> >> >> On 11/3/16, 9:55 AM, "sfc on behalf of Joel M. Halpern" > on behalf of jmh@joelhalpern.com> wrote: >> >>> You ask whether using non-consecuitive integers for the SI in the path >>> breaks something. >>> It is not forbidden. You can, after all, reclassify at every hop. (And >>> many current solutions do so.) >>> >>> However, it is misleading as to the intent and expected usage of SFC. >>> While one can manage to make it work with monotonically decreasing but >>> non-consecutive SI, it is significantly more complex. >>> >>> As far as I can tell, the place where this is an issue for the BGP SFC >>> control draft is not in the protocol definition. Rather, it is in the >>> examples which all treat non-consecutive as the normal case. This is >>> confusing to readers and likely to drive folks towards assumptions about >>> SFC behavior that will not work without additional mechanisms. >>> >>> Yours, >>> Joel >>> >>> On 11/3/16 9:20 AM, Eric C Rosen wrote: >>>> On 11/2/2016 4:50 AM, Dave Dolson wrote: >>>>> For those reasons, I would prefer to see the SF action limited to >>>>> decrement-by-one. If you require otherwise, co-locate a classifier >>>>> with the SF. >>>> >>>> From the perspective of draft-mackie-bess-nsh-bgp-control-plane, it >>>> doesn't matter whether the SPI/SI gets modified by the SF or by a >>>> co-resident classifier. The only thing that matters is what SPI/SI >>>> values the SFF will need to use as input to its forwarding engine. >>>> >>>> A slightly different issue is whether the successive elements of an SPI >>>> have to have successive integers as their respective SI's. That doesn't >>>> seem to be necessary for the proper functioning of the system, so we >>>> didn't want to assume it. By not using successive integers, it becomes >>>> easier to insert and/or delete entries. And if the SF knows the SI >>>> (call it "x") of the current element in the chain, it doesn't really >>>> have to know the SI of the next element in the chain, since the SFF can >>>> interpret "x-1" to mean "next after x", and can then modify the NSH to >>>> change the SI to the actual SI of the next element in the chain. >>>> >>>> Does this create a technical problem of some sort? >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 Nov 3 09:21:45 2016 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 819A2129A9E for ; Thu, 3 Nov 2016 09:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 mDyNNWJlrFSP for ; Thu, 3 Nov 2016 09:21:40 -0700 (PDT) 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 7A174129656 for ; Thu, 3 Nov 2016 09:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7444; q=dns/txt; s=iport; t=1478190088; x=1479399688; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=snEi/fyMpgp6KsBsVziu05uMUVkfsKHvC27e130+cS4=; b=WACtVzrDKObx/TDqu6JPv4d3QYmFPqlwgbyFSsiD9rKa1AJ0mc9pDcbD xt7mVoEByOekiF5uY4pfFjZpa741W+9dbXkdyMXNH9oEdjGxKDcNbAIJ1 oUsUNBUCbdLCncu388o/YVNTiKR07yYrjhXHxWbDGaod7VcpDcO8S3O4v c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQCjYhtY/4YNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzABAQEBAR9YfAeNMJcAlEeCCB0LhXoCGoFoPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRhAQEBBAEBASAROhcEAgEIEQEDAQEBAgIfBAMCAgIlCxQBAgYIAgQBEhuIO?= =?us-ascii?q?w6uOYx+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBCYU2gX2CWIQjJBeCbS2CLwW?= =?us-ascii?q?aIAGQPJAKjR2EAwEeN2uDWoFFcoU/gS+BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,587,1473120000"; d="scan'208";a="169320844" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 16:21:26 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uA3GLQB1023350 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2016 16:21:26 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; Thu, 3 Nov 2016 11:21:26 -0500 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, 3 Nov 2016 11:21:26 -0500 From: "Jim Guichard (jguichar)" To: "adrian@olddog.co.uk" , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AQHSNOZBG5GoCglrWUm6r677zz7T56DHlDgAgAAJrwD//8z1AIAAVvAA///B0QA= Date: Thu, 3 Nov 2016 16:21:26 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> <1074C8BE-A959-405B-BA6E-E15A19BEBFED@cisco.com> <06ac01d235eb$e4627490$ad275db0$@olddog.co.uk> In-Reply-To: <06ac01d235eb$e4627490$ad275db0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.45.112] Content-Type: text/plain; charset="utf-8" Content-ID: <74DD6D44E37F7D45B072536D896240E3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 16:21:43 -0000 SGkgQWRyaWFuLA0KDQpXaGF0IEkgaW50ZW5kZWQgaGFzIG5vIGJlYXJpbmcgb24gdGhlIGRpc2N1 c3Npb24gYW5kIEkgYW0gc2ltcGx5IHBvaW50aW5nIG91dCB0aGF0IHRoZSBXRyBoYXMgbmV2ZXIg dG8gbXkga25vd2xlZGdlIGV4aGliaXRlZCBjb25mdXNpb24gb24gdGhpcyBwb2ludCBhbHRob3Vn aCBJIGFjY2VwdCB0aGF0IHRoZSBhc3N1bXB0aW9uIG9mIGRlY3JlbWVudCBieSAxIHNob3VsZCBi ZSBjbGFyaWZpZWQuIEkgbWlnaHQgYWxzbyBwb2ludCBvdXQgdGhhdCBudW1lcm91cyBpbXBsZW1l bnRhdGlvbnMgYXJlIGFscmVhZHkgZG9pbmcgdGhlIGRlY3JlbWVudCBieSAxIHNvIEkgZ3Vlc3Mg dGhlIGNvbmZ1c2lvbiB3YXMgbm90IHdpZGVzcHJlYWQuIFNvIGluIGFsbCBmYWlybmVzcyB3aHkg aXMgaXQgdW5yZWFzb25hYmxlIHRvIGFzayB3aHkgYSBiZWhhdmlvcmFsIGNoYW5nZSBpcyBuZWNl c3Nhcnkgd2hlbiB0aGUgZXhpc3RpbmcgYXJjaGl0ZWN0dXJlIGFscmVhZHkgc3VwcG9ydHMgd2hh dCBpcyBiZWluZyBhc2tlZCBmb3I/DQoNCkppbQ0KDQoNCk9uIDExLzMvMTYsIDEyOjA0IFBNLCAi c2ZjIG9uIGJlaGFsZiBvZiBBZHJpYW4gRmFycmVsIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mIGFkcmlhbkBvbGRkb2cuY28udWs+IHdyb3RlOg0KDQo+R2VlIHNodWNrcywgSmlt LA0KPg0KPkRvIHlvdSB0aGluayBjaGFuZ2luZyAiZGVjcmVtZW50IiB0byAiZGVjcmVtZW50IGJ5 IDEiIGlzIG5vdCBhIGJlaGF2aW9yYWwgY2hhbmdlIGp1c3QgYmVjYXVzZSBpdCBpcyB3aGF0IHlv dSBpbnRlbmRlZCB3aGVuICh3aXRoIHlvdXIgY2hhaXIgaGF0IG9mZikgeW91IHJldmlld2VkIHRo ZSBkb2N1bWVudD8gDQo+DQo+T3IgYXJlIHlvdSBvbmUgb2YgdGhlIHBlb3BsZSB5b3UgYXJlIGFz a2luZyAod2l0aCB5b3VyIGNoYWlyIGhhdCBvbikgdG8gYnJpbmcgZm9yd2FyZCBuZXcgaW5mb3Jt YXRpb24/DQo+DQo+SSwgdG9vLCB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgTlNIIHNwZWMgc2hpcCwg YnV0IEkgd291bGQgcHJlZmVyIHRvIHNlZSBpdCByaWdodC4NCj4NCj5BZHJpYW4NCj4NCj5QUyBJ ZiBib3RoIHlvdSBhbmQgSm9lbCBzaW11bHRhbmVvdXNseSByZW1vdmUgeW91ciBjaGFpciBoYXRz LCB3aWxsIHdlIGhpdCBhbiBpY2ViZXJnPyA6LSkNCj4NCj5QUFMgSSBmaW5kIHRoZSBkaXNjdXNz aW9uIGFib3V0IHdoYXQgYW4gU0YgZG9lcyBjb21wYXJlZCB0byB3aGF0IGFuIFNGIHdpdGggYSBj by1yZXNpZGVudCByZS1jbGFzc2lmaWVyIGRvZXMsIHRvIGJlIGRhbmNpbmcgb24gdGhlIGhlYWQg b2YgYSBwaW4gbGFiZWxsZWQgIkZ1bmN0aW9uYWwgQXJjaGl0ZWN0dXJlIi4gWW91IGFyZSBhbGwg d2VsY29tZSB0byBpbXBsZW1lbnQgYSBmdW5jdGlvbmFsIGFyY2hpdGVjdHVyZSAoYW5kIGJsZXNz IHlvdSBmb3IgaXQpLCBidXQgdGhhdCBpcyBub3QgaG93IHByb2R1Y3RzIGFyZSBtYXJrZWQgd2hl biB0aGV5IHNoaXAuIFlvdSB3aWxsIG5vdCBiZSBzZWxsaW5nICJGaXJld2FsbCB3aXRoIEFkZGVk IFJlY2xhc3NpZmllciIuIEZ1cnRoZXJtb3JlLCB0aGUgU0ZGIHdpbGwgYmUgZW50aXJlbHkgdW5h d2FyZSBvZiB3aGV0aGVyIHJlY2xhc3NpZmljYXRpb24gdG9vayBwbGFjZS4gU28gKGF0IHRoZSBy aXNrIG9mIHJlcGVhdGluZyBteXNlbGYpLCB3aHkgaXMgIlNGIE1VU1QgZGVjcmVtZW50IGJ5IDEi IGEgcmVxdWlyZW1lbnQgaW4gdGhpcyBzcGVjLCBhbmQgd2h5IGlzIG15IHByb3Bvc2VkIGNvbXBy b21pc2UgdGV4dCBub3QgYWNjZXB0YWJsZT8NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbV0NCj4+IFNlbnQ6IDAzIE5vdmVtYmVyIDIwMTYgMTQ6NTMNCj4+IFRvOiBKb2VsIE0u IEhhbHBlcm47IEVyaWMgQyBSb3NlbjsgRGF2ZSBEb2xzb247IEFkcmlhbiBGYXJyZWw7IFN1cmVu ZHJhIEt1bWFyDQo+PiAoc21rdW1hcik7IHNmY0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtz ZmNdIE9LLiBFbm91Z2ggd2l0aCB0aGUgbG9vcGluZyAoc3BpcmFsbGluZyA6LSkgW1dhczogZGVj cmVtZW50aW5nDQo+PiBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggaW5kZXhdDQo+PiANCj4+IFtDaGFp ciBoYXQgb2Zm4oCmXQ0KPj4gR2l2ZW4gdGhhdCB0aGUgY3VycmVudGx5IGRlZmluZWQgYXJjaGl0 ZWN0dXJlIGFsbG93cyBmb3IgdGhlIHJlcXVlc3RlZCBiZWhhdmlvcg0KPj4gdGhyb3VnaCByZWNs YXNzaWZpY2F0aW9uLCBJIHBlcnNvbmFsbHkgc2VlIG5vIHJlYXNvbiBmb3IgYSBjaGFuZ2UgdG8g dGhlIHdheQ0KPj4gZGVjcmVtZW50IG9mIHNlcnZpY2UgaW5kZXggaXMgY3VycmVudGx5IGRlZmlu ZWQsIG90aGVyIHRoYW4gbWFraW5nIGl0IGV4cGxpY2l0IHRoYXQNCj4+IGRlY3JlbWVudCBtZWFu cyDigJxieSAx4oCdLg0KPj4gDQo+PiBbQ2hhaXIgaGF0IG9u4oCmXQ0KPj4gSSB3b3VsZCBub3Rl IHRoYXQgd2UgYWxyZWFkeSBoYXZlIHdvcmtpbmcgZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBjdXJy ZW50IE5TSA0KPj4gc3BlY2lmaWNhdGlvbi4gQWxzbywgdGhlIGlzc3VlIG9mIHRoZSBlYXNlIG9m IG1vZGlmaWNhdGlvbiBvZiBTRlBzIHdhcyBwYXJ0IG9mDQo+PiBlYXJsaWVyIHdvcmtpbmcgZ3Jv dXAgZGlzY3Vzc2lvbi4gIElzIHRoZXJlIG5ldyBpbmZvcm1hdGlvbiB0aGF0IHRob3NlIHJlcXVl c3RpbmcNCj4+IGEgYmVoYXZpb3JhbCBjaGFuZ2Ugd2lzaCB0byBicmluZyBmb3J3YXJkPw0KPj4g DQo+PiBKaW0NCj4+IA0KPj4gDQo+PiANCj4+IE9uIDExLzMvMTYsIDk6NTUgQU0sICJzZmMgb24g YmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybiIgPHNmYy1ib3VuY2VzQGlldGYub3JnDQo+PiBvbiBi ZWhhbGYgb2Ygam1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+PiANCj4+ID5Zb3UgYXNrIHdo ZXRoZXIgdXNpbmcgbm9uLWNvbnNlY3VpdGl2ZSBpbnRlZ2VycyBmb3IgdGhlIFNJIGluIHRoZSBw YXRoDQo+PiA+YnJlYWtzIHNvbWV0aGluZy4NCj4+ID5JdCBpcyBub3QgZm9yYmlkZGVuLiAgWW91 IGNhbiwgYWZ0ZXIgYWxsLCByZWNsYXNzaWZ5IGF0IGV2ZXJ5IGhvcC4gIChBbmQNCj4+ID5tYW55 IGN1cnJlbnQgc29sdXRpb25zIGRvIHNvLikNCj4+ID4NCj4+ID5Ib3dldmVyLCBpdCBpcyBtaXNs ZWFkaW5nIGFzIHRvIHRoZSBpbnRlbnQgYW5kIGV4cGVjdGVkIHVzYWdlIG9mIFNGQy4NCj4+ID5X aGlsZSBvbmUgY2FuIG1hbmFnZSB0byBtYWtlIGl0IHdvcmsgd2l0aCBtb25vdG9uaWNhbGx5IGRl Y3JlYXNpbmcgYnV0DQo+PiA+bm9uLWNvbnNlY3V0aXZlIFNJLCBpdCBpcyBzaWduaWZpY2FudGx5 IG1vcmUgY29tcGxleC4NCj4+ID4NCj4+ID5BcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIHBsYWNl IHdoZXJlIHRoaXMgaXMgYW4gaXNzdWUgZm9yIHRoZSBCR1AgU0ZDDQo+PiA+Y29udHJvbCBkcmFm dCBpcyBub3QgaW4gdGhlIHByb3RvY29sIGRlZmluaXRpb24uICBSYXRoZXIsIGl0IGlzIGluIHRo ZQ0KPj4gPmV4YW1wbGVzIHdoaWNoIGFsbCB0cmVhdCBub24tY29uc2VjdXRpdmUgYXMgdGhlIG5v cm1hbCBjYXNlLiAgVGhpcyBpcw0KPj4gPmNvbmZ1c2luZyB0byByZWFkZXJzIGFuZCBsaWtlbHkg dG8gZHJpdmUgZm9sa3MgdG93YXJkcyBhc3N1bXB0aW9ucyBhYm91dA0KPj4gPlNGQyBiZWhhdmlv ciB0aGF0IHdpbGwgbm90IHdvcmsgd2l0aG91dCBhZGRpdGlvbmFsIG1lY2hhbmlzbXMuDQo+PiA+ DQo+PiA+WW91cnMsDQo+PiA+Sm9lbA0KPj4gPg0KPj4gPk9uIDExLzMvMTYgOToyMCBBTSwgRXJp YyBDIFJvc2VuIHdyb3RlOg0KPj4gPj4gT24gMTEvMi8yMDE2IDQ6NTAgQU0sIERhdmUgRG9sc29u IHdyb3RlOg0KPj4gPj4+IEZvciB0aG9zZSByZWFzb25zLCBJIHdvdWxkIHByZWZlciB0byBzZWUg dGhlIFNGIGFjdGlvbiBsaW1pdGVkIHRvDQo+PiA+Pj4gZGVjcmVtZW50LWJ5LW9uZS4gSWYgeW91 IHJlcXVpcmUgb3RoZXJ3aXNlLCBjby1sb2NhdGUgYSBjbGFzc2lmaWVyDQo+PiA+Pj4gd2l0aCB0 aGUgU0YuDQo+PiA+Pg0KPj4gPj4gRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgZHJhZnQtbWFja2ll LWJlc3MtbnNoLWJncC1jb250cm9sLXBsYW5lLCBpdA0KPj4gPj4gZG9lc24ndCBtYXR0ZXIgd2hl dGhlciB0aGUgU1BJL1NJIGdldHMgbW9kaWZpZWQgYnkgdGhlIFNGIG9yIGJ5IGENCj4+ID4+IGNv LXJlc2lkZW50IGNsYXNzaWZpZXIuICBUaGUgb25seSB0aGluZyB0aGF0IG1hdHRlcnMgaXMgd2hh dCBTUEkvU0kNCj4+ID4+IHZhbHVlcyB0aGUgU0ZGIHdpbGwgbmVlZCB0byB1c2UgYXMgaW5wdXQg dG8gaXRzIGZvcndhcmRpbmcgZW5naW5lLg0KPj4gPj4NCj4+ID4+IEEgc2xpZ2h0bHkgZGlmZmVy ZW50IGlzc3VlIGlzIHdoZXRoZXIgdGhlIHN1Y2Nlc3NpdmUgZWxlbWVudHMgb2YgYW4gU1BJDQo+ PiA+PiBoYXZlIHRvIGhhdmUgc3VjY2Vzc2l2ZSBpbnRlZ2VycyBhcyB0aGVpciByZXNwZWN0aXZl IFNJJ3MuICBUaGF0IGRvZXNuJ3QNCj4+ID4+IHNlZW0gdG8gYmUgbmVjZXNzYXJ5IGZvciB0aGUg cHJvcGVyIGZ1bmN0aW9uaW5nIG9mIHRoZSBzeXN0ZW0sIHNvIHdlDQo+PiA+PiBkaWRuJ3Qgd2Fu dCB0byBhc3N1bWUgaXQuICBCeSBub3QgdXNpbmcgc3VjY2Vzc2l2ZSBpbnRlZ2VycywgaXQgYmVj b21lcw0KPj4gPj4gZWFzaWVyIHRvIGluc2VydCBhbmQvb3IgZGVsZXRlIGVudHJpZXMuICBBbmQg aWYgdGhlIFNGIGtub3dzIHRoZSBTSQ0KPj4gPj4gKGNhbGwgaXQgIngiKSBvZiB0aGUgY3VycmVu dCBlbGVtZW50IGluIHRoZSBjaGFpbiwgaXQgZG9lc24ndCByZWFsbHkNCj4+ID4+IGhhdmUgdG8g a25vdyB0aGUgU0kgb2YgdGhlIG5leHQgZWxlbWVudCBpbiB0aGUgY2hhaW4sIHNpbmNlIHRoZSBT RkYgY2FuDQo+PiA+PiBpbnRlcnByZXQgIngtMSIgdG8gbWVhbiAibmV4dCBhZnRlciB4IiwgYW5k IGNhbiB0aGVuIG1vZGlmeSB0aGUgTlNIIHRvDQo+PiA+PiBjaGFuZ2UgdGhlIFNJIHRvIHRoZSBh Y3R1YWwgU0kgb2YgdGhlIG5leHQgZWxlbWVudCBpbiB0aGUgY2hhaW4uDQo+PiA+Pg0KPj4gPj4g RG9lcyB0aGlzIGNyZWF0ZSBhIHRlY2huaWNhbCBwcm9ibGVtIG9mIHNvbWUgc29ydD8NCj4+ID4+ DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPg0KPj4gPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4g PnNmY0BpZXRmLm9yZw0KPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Thu Nov 3 09:29:11 2016 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 A18C9129648 for ; Thu, 3 Nov 2016 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 StM81AROgZev for ; Thu, 3 Nov 2016 09:29:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0997912963A for ; Thu, 3 Nov 2016 09:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2436; q=dns/txt; s=iport; t=1478190548; x=1479400148; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cL+vSx9C/vgFq825O8rJvw4h+nP/wPvJ+Gjz2ogViyI=; b=A+INnLEHZMy6BNiC8iZlDVwoL3fSPDTsg3oadX7/DgnhHUAS8bkU1F3R GfjSC25L5ITQdo73qf4oC8k1o/liSaEIBETnKOOYGBE/y+32OWNgcpkiy Motp+zUBwN2Uski54CvZ1fWXxAIRH4uHCXe4QjrHnOW1vALuuE4XvkPwx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQBHZRtY/5FdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzABAQEBAR9YfAeNMJcAlEeCCB0LhXoCGoFoPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEEAQEBIBE6GwIBCBoCIwMCAgIlCxQBEAIEARKIVg6uRIx+AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWBCYU2gX0IglCEN4MULYIvBZRChV4BhjOKCYFuhG+JLYc?= =?us-ascii?q?nhXaEAwEeN2uDIx+BXXIBhm2BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,587,1473120000"; d="scan'208";a="164907169" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2016 16:29:08 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA3GT8FY025942 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2016 16:29: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; Thu, 3 Nov 2016 11:29:07 -0500 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, 3 Nov 2016 11:29:07 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] NSH MD-1 description Thread-Index: AQHSNTNdPW364iTbUU++CFSiySTzt6DHJ9KAgABdVoA= Date: Thu, 3 Nov 2016 16:29:07 +0000 Message-ID: <2EE9F654-2941-47C0-993E-E6AFEBB4E1F0@cisco.com> References: <787AE7BB302AE849A7480A190F8B933009DA78EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DA78EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.45.112] Content-Type: text/plain; charset="utf-8" Content-ID: <75FE0E86292D33459CBBE813F4E4033D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH MD-1 description 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, 03 Nov 2016 16:29:10 -0000 SGkgTWVkICYgU0ZDIFdHOg0KDQpIYXZpbmcgY29uc2lkZXJlZCB0aGUgV0cgZmVlZGJhY2sgdGhl IGNoYWlycyBmZWVsIHRoYXQgcm91Z2ggY29uc2Vuc3VzIGhhcyBiZWVuIHJlYWNoZWQgdG8gc3Vw cG9ydCB0aGlzIGNoYW5nZS4gDQoNClNGQyBlZGl0b3JzOg0KDQpQbGVhc2UgdXBkYXRlIHRoZSBy ZWxldmFudCB0ZXh0IGFzIHBlciBodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvc2ZjL3Ry YWMvdGlja2V0LzIyIGFuZCBwb3N0IGEgbmV3IHZlcnNpb24uDQoNClRoYW5rcyENCg0KSmltICYg Sm9lbA0KDQoNCg0KT24gMTEvMy8xNiwgMjo1NSBBTSwgInNmYyBvbiBiZWhhbGYgb2YgbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgPHNmYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KPkhpIEpvZWwsDQo+DQo+ QWdyZWUuIA0KPg0KPlBsZWFzZSBjb25zaWRlciBwcm9jZXNzaW5nIHRoaXMgdGlja2V0IHRvIHJl Y29yZCB0aGUgV0cgZmVlZGJhY2s6IGh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9zZmMv dHJhYy90aWNrZXQvMjIgDQo+DQo+VGhhbmsgeW91Lg0KPg0KPkNoZWVycywNCj5NZWQNCj4NCj4+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKb2VsIE0uIEhhbHBlcm4NCj4+IEVudm95w6kg OiBtZXJjcmVkaSAyIG5vdmVtYnJlIDIwMTYgMTg6NTcNCj4+IMOAIDogc2ZjQGlldGYub3JnDQo+ PiBPYmpldCA6IFtzZmNdIE5TSCBNRC0xIGRlc2NyaXB0aW9uDQo+PiANCj4+IDxzcGVha2luZyBh cyBhIHBhcnRpY2lwYW50Pg0KPj4gR2l2ZW4gdGhhdCB2YXJpb3VzIGV4aXN0aW5nIE1ELTEgcHJv cG9zYWxzIGJyZWFrIHVwIHRoZSAiNCIgZmllbGRzIGluDQo+PiB2YXJpb3VzIHdheXMsIGFuZCBn aXZlbiB0aGF0IHdlIG1heSB3YW50IHRvIGFsbG93ICwgZm9yIGV4YW1wbGUsIGEgc2luZ2wNCj4+ IDY0IGJpdCBmaWVsZCBpbiBzb21lIE1ELTEgYWxsb2NhdGlvbiwgaXQgc2VlbXMgY2xlYW5lciBh bmQgbW9yZQ0KPj4gY29uc2lzdGVudCB0byBtZSB0byBkZXNjcmliZSB0aGUgTUQtMSBjb250ZW50 IGFzIGEgYmxvY2sgb2YgMTYgYnl0ZXMNCj4+IHJhdGhlciB0aGFuIGFzIDQgNCBieXRlIHdvcmRz Lg0KPj4gDQo+PiBHaXZlbiB0aGF0IHRoaXMgaXMgcHVyZWx5IGRlc2NyaXB0aXZlIGZvciB0aGUg TlNIIGRvY3VtZW50LCBJIGRvIG5vdCBzZWUNCj4+IGEgZG93biBzaWRlLiAgWUFORyBtb2RlbHMg Zm9yIG1ldGFkYXRhIGFyZSBhIG1vcmUgY29tcGxleCBxdWVzdGlvbiwgYnV0DQo+PiB0aGUgc2lt cGxlIDR4NCBieXRlIHJlcHJlc2VudGF0aW9uIGlzIHByb2JhYmx5IG5vdCB3YW50IHdlIHdhbnQg dGhlcmUNCj4+IGVpdGhlci4NCj4+IA0KPj4gWW91cnMsDQo+PiBKb2VsDQo+PiANCj4+IDwvc3Bl YWtpbmcgYXMgYSBwYXJ0aWNpcGFudD4NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWls aW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0K From nobody Thu Nov 3 09:29:28 2016 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 C80CA129658 for ; Thu, 3 Nov 2016 09:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 j0G_vqA2i_Hq for ; Thu, 3 Nov 2016 09:29:25 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 D033212986F for ; Thu, 3 Nov 2016 09:29:22 -0700 (PDT) Received: from localhost ([::1]:34757 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c2KtD-0002Te-EM; Thu, 03 Nov 2016 09:29:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, jguichar@cisco.com X-Trac-Project: sfc Date: Thu, 03 Nov 2016 16:29:19 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/22#comment:2 Message-ID: <082.33c9a01dbf67f4533cfb7a80752fe4d5@tools.ietf.org> References: <067.55ac197d2cfc5db758628804bd525e3e@tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <067.55ac197d2cfc5db758628804bd525e3e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, jguichar@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20161103162922.D033212986F@ietfa.amsl.com> Resent-Date: Thu, 3 Nov 2016 09:29:22 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #22 (nsh): MD-1 with 16-bytes datablock 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, 03 Nov 2016 16:29:27 -0000 #22: MD-1 with 16-bytes datablock Comment (by jguichar@cisco.com): The following email has been sent to the SFC WG from the chairs - once this change is made this ticket can be closed as resolved: Hi Med & SFC WG: Having considered the WG feedback the chairs feel that rough consensus has been reached to support this change. SFC editors: Please update the relevant text as per https://trac.tools.ietf.org/wg/sfc/trac/ticket/22 and post a new version. Thanks! Jim & Joel -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Thu Nov 3 10:54:18 2016 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 A95E61296B4 for ; Thu, 3 Nov 2016 10:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 zc74E9RYx3JY for ; Thu, 3 Nov 2016 10:54:14 -0700 (PDT) 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 B1E57129546 for ; Thu, 3 Nov 2016 10:54:13 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 13:54:12 -0400 From: Dave Dolson To: "Jim Guichard (jguichar)" , "adrian@olddog.co.uk" , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAEQaggAAATXyAAACATIAAAJ7YgAAAJveAAAFsUrg Date: Thu, 3 Nov 2016 17:54:11 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> <1074C8BE-A959-405B-BA6E-E15A19BEBFED@cisco.com> <06ac01d235eb$e4627490$ad275db0$@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: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 17:54:16 -0000 SSBoYXZlIG5ldmVyIHVuZGVyc3Rvb2QgImluY3JlbWVudCIgb3IgImRlY3JlbWVudCIgdXNlZCBh bG9uZSB0byBtZWFuIGFueXRoaW5nIG90aGVyIHRoYW4gImJ5IDEiLg0KT25lIHdyaXRlcywgImRl Y3JlbWVudCBieSBYIiBpZiBYIGlzIG5vdCAxLg0KDQpUaGlzIGlzc3VlIG1hdHRlcnMgdG8gbWUg YmVjYXVzZSBTYW5kdmluZSBoYXMgYSBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgcGVyZm9ybXMgc2Vy dmljZSBpbmRleCBkZWNyZW1lbnRpbmcgKGJ5IG9uZSwgb2YgY291cnNlKSB3aXRob3V0IHJlcXVp cmluZyBjb250cm9sLXBsYW5lIGNvbmZpZ3VyYXRpb24uDQpUbyBtZSB0aGUgZnVuY3Rpb25hbCBz ZXBhcmF0aW9uIG9mIENsYXNzaWZpZXIgYW5kIFNlcnZpY2UgRnVuY3Rpb24gaXMgbm90IGFjYWRl bWljOyBpdCdzIHJlYWwsIGFuZCBpdCBpcyBhbiBlbGVnYW50IHNlcGFyYXRpb24gb2YgcmVzcG9u c2liaWxpdHkuDQoNClJlZmVycmluZyBhbHNvIHRvIGRyYWZ0LWlldGYtc2ZjLWNvbnRyb2wtcGxh bmUsIHRoZSBDMyBpbnRlcmZhY2UgdG8gdGhlIFNGIGRvZXMgbm90IGluY2x1ZGUgZm9yd2FyZGlu ZyBpbmZvcm1hdGlvbiAod2l0aCB0aGUgZXhjZXB0aW9uIG9mIGhvdyB0byBzZW5kIGEgcmV2ZXJz ZSBwYWNrZXQtLWJ1dCB0aGVyZSBhcmUgYWx0ZXJuYXRpdmVzKS4NCg0KU28gaW4gdGVybXMgb2Yg InNlZWluZyBpdCBkb25lIHJpZ2h0IiwgdGhlIGZ1bmN0aW9uYWwgc2VwYXJhdGlvbiBhbmQgc2lt cGxpY2l0eSBpcyAicmlnaHQiLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWlj aGFyZCAoamd1aWNoYXIpDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDMsIDIwMTYgMTI6MjEg UE0NClRvOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb c2ZjXSBPSy4gRW5vdWdoIHdpdGggdGhlIGxvb3BpbmcgKHNwaXJhbGxpbmcgOi0pIFtXYXM6IGRl Y3JlbWVudGluZyBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggaW5kZXhdDQoNCkhpIEFkcmlhbiwNCg0K V2hhdCBJIGludGVuZGVkIGhhcyBubyBiZWFyaW5nIG9uIHRoZSBkaXNjdXNzaW9uIGFuZCBJIGFt IHNpbXBseSBwb2ludGluZyBvdXQgdGhhdCB0aGUgV0cgaGFzIG5ldmVyIHRvIG15IGtub3dsZWRn ZSBleGhpYml0ZWQgY29uZnVzaW9uIG9uIHRoaXMgcG9pbnQgYWx0aG91Z2ggSSBhY2NlcHQgdGhh dCB0aGUgYXNzdW1wdGlvbiBvZiBkZWNyZW1lbnQgYnkgMSBzaG91bGQgYmUgY2xhcmlmaWVkLiBJ IG1pZ2h0IGFsc28gcG9pbnQgb3V0IHRoYXQgbnVtZXJvdXMgaW1wbGVtZW50YXRpb25zIGFyZSBh bHJlYWR5IGRvaW5nIHRoZSBkZWNyZW1lbnQgYnkgMSBzbyBJIGd1ZXNzIHRoZSBjb25mdXNpb24g d2FzIG5vdCB3aWRlc3ByZWFkLiBTbyBpbiBhbGwgZmFpcm5lc3Mgd2h5IGlzIGl0IHVucmVhc29u YWJsZSB0byBhc2sgd2h5IGEgYmVoYXZpb3JhbCBjaGFuZ2UgaXMgbmVjZXNzYXJ5IHdoZW4gdGhl IGV4aXN0aW5nIGFyY2hpdGVjdHVyZSBhbHJlYWR5IHN1cHBvcnRzIHdoYXQgaXMgYmVpbmcgYXNr ZWQgZm9yPw0KDQpKaW0NCg0KDQpPbiAxMS8zLzE2LCAxMjowNCBQTSwgInNmYyBvbiBiZWhhbGYg b2YgQWRyaWFuIEZhcnJlbCIgPHNmYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhZHJp YW5Ab2xkZG9nLmNvLnVrPiB3cm90ZToNCg0KPkdlZSBzaHVja3MsIEppbSwNCj4NCj5EbyB5b3Ug dGhpbmsgY2hhbmdpbmcgImRlY3JlbWVudCIgdG8gImRlY3JlbWVudCBieSAxIiBpcyBub3QgYSBi ZWhhdmlvcmFsIGNoYW5nZSBqdXN0IGJlY2F1c2UgaXQgaXMgd2hhdCB5b3UgaW50ZW5kZWQgd2hl biAod2l0aCB5b3VyIGNoYWlyIGhhdCBvZmYpIHlvdSByZXZpZXdlZCB0aGUgZG9jdW1lbnQ/IA0K Pg0KPk9yIGFyZSB5b3Ugb25lIG9mIHRoZSBwZW9wbGUgeW91IGFyZSBhc2tpbmcgKHdpdGggeW91 ciBjaGFpciBoYXQgb24pIHRvIGJyaW5nIGZvcndhcmQgbmV3IGluZm9ybWF0aW9uPw0KPg0KPkks IHRvbywgd291bGQgbGlrZSB0byBzZWUgdGhlIE5TSCBzcGVjIHNoaXAsIGJ1dCBJIHdvdWxkIHBy ZWZlciB0byBzZWUgaXQgcmlnaHQuDQo+DQo+QWRyaWFuDQo+DQo+UFMgSWYgYm90aCB5b3UgYW5k IEpvZWwgc2ltdWx0YW5lb3VzbHkgcmVtb3ZlIHlvdXIgY2hhaXIgaGF0cywgd2lsbCB3ZSBoaXQg YW4gaWNlYmVyZz8gOi0pDQo+DQo+UFBTIEkgZmluZCB0aGUgZGlzY3Vzc2lvbiBhYm91dCB3aGF0 IGFuIFNGIGRvZXMgY29tcGFyZWQgdG8gd2hhdCBhbiBTRiB3aXRoIGEgY28tcmVzaWRlbnQgcmUt Y2xhc3NpZmllciBkb2VzLCB0byBiZSBkYW5jaW5nIG9uIHRoZSBoZWFkIG9mIGEgcGluIGxhYmVs bGVkICJGdW5jdGlvbmFsIEFyY2hpdGVjdHVyZSIuIFlvdSBhcmUgYWxsIHdlbGNvbWUgdG8gaW1w bGVtZW50IGEgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUgKGFuZCBibGVzcyB5b3UgZm9yIGl0KSwg YnV0IHRoYXQgaXMgbm90IGhvdyBwcm9kdWN0cyBhcmUgbWFya2VkIHdoZW4gdGhleSBzaGlwLiBZ b3Ugd2lsbCBub3QgYmUgc2VsbGluZyAiRmlyZXdhbGwgd2l0aCBBZGRlZCBSZWNsYXNzaWZpZXIi LiBGdXJ0aGVybW9yZSwgdGhlIFNGRiB3aWxsIGJlIGVudGlyZWx5IHVuYXdhcmUgb2Ygd2hldGhl ciByZWNsYXNzaWZpY2F0aW9uIHRvb2sgcGxhY2UuIFNvIChhdCB0aGUgcmlzayBvZiByZXBlYXRp bmcgbXlzZWxmKSwgd2h5IGlzICJTRiBNVVNUIGRlY3JlbWVudCBieSAxIiBhIHJlcXVpcmVtZW50 IGluIHRoaXMgc3BlYywgYW5kIHdoeSBpcyBteSBwcm9wb3NlZCBjb21wcm9taXNlIHRleHQgbm90 IGFjY2VwdGFibGU/DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTog SmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+PiBT ZW50OiAwMyBOb3ZlbWJlciAyMDE2IDE0OjUzDQo+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBFcmlj IEMgUm9zZW47IERhdmUgRG9sc29uOyBBZHJpYW4gRmFycmVsOyBTdXJlbmRyYSBLdW1hcg0KPj4g KHNta3VtYXIpOyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBPSy4gRW5vdWdo IHdpdGggdGhlIGxvb3BpbmcgKHNwaXJhbGxpbmcgOi0pIFtXYXM6IGRlY3JlbWVudGluZw0KPj4g c2VydmljZSBmdW5jdGlvbiBwYXRoIGluZGV4XQ0KPj4gDQo+PiBbQ2hhaXIgaGF0IG9mZuKApl0N Cj4+IEdpdmVuIHRoYXQgdGhlIGN1cnJlbnRseSBkZWZpbmVkIGFyY2hpdGVjdHVyZSBhbGxvd3Mg Zm9yIHRoZSByZXF1ZXN0ZWQgYmVoYXZpb3INCj4+IHRocm91Z2ggcmVjbGFzc2lmaWNhdGlvbiwg SSBwZXJzb25hbGx5IHNlZSBubyByZWFzb24gZm9yIGEgY2hhbmdlIHRvIHRoZSB3YXkNCj4+IGRl Y3JlbWVudCBvZiBzZXJ2aWNlIGluZGV4IGlzIGN1cnJlbnRseSBkZWZpbmVkLCBvdGhlciB0aGFu IG1ha2luZyBpdCBleHBsaWNpdCB0aGF0DQo+PiBkZWNyZW1lbnQgbWVhbnMg4oCcYnkgMeKAnS4N Cj4+IA0KPj4gW0NoYWlyIGhhdCBvbuKApl0NCj4+IEkgd291bGQgbm90ZSB0aGF0IHdlIGFscmVh ZHkgaGF2ZSB3b3JraW5nIGdyb3VwIGFncmVlbWVudCBvbiB0aGUgY3VycmVudCBOU0gNCj4+IHNw ZWNpZmljYXRpb24uIEFsc28sIHRoZSBpc3N1ZSBvZiB0aGUgZWFzZSBvZiBtb2RpZmljYXRpb24g b2YgU0ZQcyB3YXMgcGFydCBvZg0KPj4gZWFybGllciB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb24u ICBJcyB0aGVyZSBuZXcgaW5mb3JtYXRpb24gdGhhdCB0aG9zZSByZXF1ZXN0aW5nDQo+PiBhIGJl aGF2aW9yYWwgY2hhbmdlIHdpc2ggdG8gYnJpbmcgZm9yd2FyZD8NCj4+IA0KPj4gSmltDQo+PiAN Cj4+IA0KPj4gDQo+PiBPbiAxMS8zLzE2LCA5OjU1IEFNLCAic2ZjIG9uIGJlaGFsZiBvZiBKb2Vs IE0uIEhhbHBlcm4iIDxzZmMtYm91bmNlc0BpZXRmLm9yZw0KPj4gb24gYmVoYWxmIG9mIGptaEBq b2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4gDQo+PiA+WW91IGFzayB3aGV0aGVyIHVzaW5nIG5v bi1jb25zZWN1aXRpdmUgaW50ZWdlcnMgZm9yIHRoZSBTSSBpbiB0aGUgcGF0aA0KPj4gPmJyZWFr cyBzb21ldGhpbmcuDQo+PiA+SXQgaXMgbm90IGZvcmJpZGRlbi4gIFlvdSBjYW4sIGFmdGVyIGFs bCwgcmVjbGFzc2lmeSBhdCBldmVyeSBob3AuICAoQW5kDQo+PiA+bWFueSBjdXJyZW50IHNvbHV0 aW9ucyBkbyBzby4pDQo+PiA+DQo+PiA+SG93ZXZlciwgaXQgaXMgbWlzbGVhZGluZyBhcyB0byB0 aGUgaW50ZW50IGFuZCBleHBlY3RlZCB1c2FnZSBvZiBTRkMuDQo+PiA+V2hpbGUgb25lIGNhbiBt YW5hZ2UgdG8gbWFrZSBpdCB3b3JrIHdpdGggbW9ub3RvbmljYWxseSBkZWNyZWFzaW5nIGJ1dA0K Pj4gPm5vbi1jb25zZWN1dGl2ZSBTSSwgaXQgaXMgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXgu DQo+PiA+DQo+PiA+QXMgZmFyIGFzIEkgY2FuIHRlbGwsIHRoZSBwbGFjZSB3aGVyZSB0aGlzIGlz IGFuIGlzc3VlIGZvciB0aGUgQkdQIFNGQw0KPj4gPmNvbnRyb2wgZHJhZnQgaXMgbm90IGluIHRo ZSBwcm90b2NvbCBkZWZpbml0aW9uLiAgUmF0aGVyLCBpdCBpcyBpbiB0aGUNCj4+ID5leGFtcGxl cyB3aGljaCBhbGwgdHJlYXQgbm9uLWNvbnNlY3V0aXZlIGFzIHRoZSBub3JtYWwgY2FzZS4gIFRo aXMgaXMNCj4+ID5jb25mdXNpbmcgdG8gcmVhZGVycyBhbmQgbGlrZWx5IHRvIGRyaXZlIGZvbGtz IHRvd2FyZHMgYXNzdW1wdGlvbnMgYWJvdXQNCj4+ID5TRkMgYmVoYXZpb3IgdGhhdCB3aWxsIG5v dCB3b3JrIHdpdGhvdXQgYWRkaXRpb25hbCBtZWNoYW5pc21zLg0KPj4gPg0KPj4gPllvdXJzLA0K Pj4gPkpvZWwNCj4+ID4NCj4+ID5PbiAxMS8zLzE2IDk6MjAgQU0sIEVyaWMgQyBSb3NlbiB3cm90 ZToNCj4+ID4+IE9uIDExLzIvMjAxNiA0OjUwIEFNLCBEYXZlIERvbHNvbiB3cm90ZToNCj4+ID4+ PiBGb3IgdGhvc2UgcmVhc29ucywgSSB3b3VsZCBwcmVmZXIgdG8gc2VlIHRoZSBTRiBhY3Rpb24g bGltaXRlZCB0bw0KPj4gPj4+IGRlY3JlbWVudC1ieS1vbmUuIElmIHlvdSByZXF1aXJlIG90aGVy d2lzZSwgY28tbG9jYXRlIGEgY2xhc3NpZmllcg0KPj4gPj4+IHdpdGggdGhlIFNGLg0KPj4gPj4N Cj4+ID4+IEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGRyYWZ0LW1hY2tpZS1iZXNzLW5zaC1iZ3At Y29udHJvbC1wbGFuZSwgaXQNCj4+ID4+IGRvZXNuJ3QgbWF0dGVyIHdoZXRoZXIgdGhlIFNQSS9T SSBnZXRzIG1vZGlmaWVkIGJ5IHRoZSBTRiBvciBieSBhDQo+PiA+PiBjby1yZXNpZGVudCBjbGFz c2lmaWVyLiAgVGhlIG9ubHkgdGhpbmcgdGhhdCBtYXR0ZXJzIGlzIHdoYXQgU1BJL1NJDQo+PiA+ PiB2YWx1ZXMgdGhlIFNGRiB3aWxsIG5lZWQgdG8gdXNlIGFzIGlucHV0IHRvIGl0cyBmb3J3YXJk aW5nIGVuZ2luZS4NCj4+ID4+DQo+PiA+PiBBIHNsaWdodGx5IGRpZmZlcmVudCBpc3N1ZSBpcyB3 aGV0aGVyIHRoZSBzdWNjZXNzaXZlIGVsZW1lbnRzIG9mIGFuIFNQSQ0KPj4gPj4gaGF2ZSB0byBo YXZlIHN1Y2Nlc3NpdmUgaW50ZWdlcnMgYXMgdGhlaXIgcmVzcGVjdGl2ZSBTSSdzLiAgVGhhdCBk b2Vzbid0DQo+PiA+PiBzZWVtIHRvIGJlIG5lY2Vzc2FyeSBmb3IgdGhlIHByb3BlciBmdW5jdGlv bmluZyBvZiB0aGUgc3lzdGVtLCBzbyB3ZQ0KPj4gPj4gZGlkbid0IHdhbnQgdG8gYXNzdW1lIGl0 LiAgQnkgbm90IHVzaW5nIHN1Y2Nlc3NpdmUgaW50ZWdlcnMsIGl0IGJlY29tZXMNCj4+ID4+IGVh c2llciB0byBpbnNlcnQgYW5kL29yIGRlbGV0ZSBlbnRyaWVzLiAgQW5kIGlmIHRoZSBTRiBrbm93 cyB0aGUgU0kNCj4+ID4+IChjYWxsIGl0ICJ4Iikgb2YgdGhlIGN1cnJlbnQgZWxlbWVudCBpbiB0 aGUgY2hhaW4sIGl0IGRvZXNuJ3QgcmVhbGx5DQo+PiA+PiBoYXZlIHRvIGtub3cgdGhlIFNJIG9m IHRoZSBuZXh0IGVsZW1lbnQgaW4gdGhlIGNoYWluLCBzaW5jZSB0aGUgU0ZGIGNhbg0KPj4gPj4g aW50ZXJwcmV0ICJ4LTEiIHRvIG1lYW4gIm5leHQgYWZ0ZXIgeCIsIGFuZCBjYW4gdGhlbiBtb2Rp ZnkgdGhlIE5TSCB0bw0KPj4gPj4gY2hhbmdlIHRoZSBTSSB0byB0aGUgYWN0dWFsIFNJIG9mIHRo ZSBuZXh0IGVsZW1lbnQgaW4gdGhlIGNoYWluLg0KPj4gPj4NCj4+ID4+IERvZXMgdGhpcyBjcmVh dGUgYSB0ZWNobmljYWwgcHJvYmxlbSBvZiBzb21lIHNvcnQ/DQo+PiA+Pg0KPj4gPj4NCj4+ID4+ DQo+PiA+Pg0KPj4gPj4NCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+ID5zZmNAaWV0Zi5vcmcN Cj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcg bGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K c2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0K From nobody Thu Nov 3 10:55:29 2016 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 A0003129AB7 for ; Thu, 3 Nov 2016 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 3lCW74Qd9Wu8 for ; Thu, 3 Nov 2016 10:55:26 -0700 (PDT) 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 A26EF1296DC for ; Thu, 3 Nov 2016 10:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5272; q=dns/txt; s=iport; t=1478195726; x=1479405326; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=r1ZOMgEfkfbJKc+wGC0P9fvy3qBM1Ih4kjUQ8P6s6Jo=; b=gl39lRz5Gp0sX+ZoV1TuhmeSw2ymwVll5tOWZG9yQFAaDUo9d+tVRpch QfkeY+tH6iQ1vAqvKHTaQyS0mozfMdU1QLA5JNJbz52gjefm/gjpQWAyF Tlsqceswf5R1fkuVNXYFVo7FDUOOb9zfcjzG4hfm09xNJbTxIUcmTpWop M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQBNeRtY/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzABAQEBAR9YfAeNMJcBlEeCCB0LhXoCGoFpPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRhAQEBBAEBASAROhcEAgEIEQEDAQEBAgIfBwICAiULFQIGCAEBBAESCBOIO?= =?us-ascii?q?w6uWox+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBCYoLhCM7gm2CXAWUQoVeAZA?= =?us-ascii?q?1kBGNHYQDAR43a4NagUVyhT+BL4EMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,587,1473120000"; d="scan'208";a="342021452" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 17:55:25 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uA3HtPPY007440 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2016 17:55:25 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 12:55:25 -0500 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; Thu, 3 Nov 2016 12:55:25 -0500 From: "Surendra Kumar (smkumar)" To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , Eric C Rosen , Dave Dolson , Adrian Farrel , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAEYy8wAAATXyAAACATIAAAR6VsA= Date: Thu, 3 Nov 2016 17:55:24 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <528f0001-817d-5887-1c78-eabc2d09e711@juniper.net> <1074C8BE-A959-405B-BA6E-E15A19BEBFED@cisco.com> In-Reply-To: <1074C8BE-A959-405B-BA6E-E15A19BEBFED@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.33.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 17:55:28 -0000 SGkgSmltLA0KDQpJbmxpbmUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBK aW0gR3VpY2hhcmQgKGpndWljaGFyKSANClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMywgMjAx NiA3OjUzIEFNDQpUbzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgRXJp YyBDIFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ+OyBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5k dmluZS5jb20+OyBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPjsgU3VyZW5kcmEg S3VtYXIgKHNta3VtYXIpIDxzbWt1bWFyQGNpc2NvLmNvbT47IHNmY0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtzZmNdIE9LLiBFbm91Z2ggd2l0aCB0aGUgbG9vcGluZyAoc3BpcmFsbGluZyA6LSkg W1dhczogZGVjcmVtZW50aW5nIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBpbmRleF0NCg0KW0NoYWly IGhhdCBvZmbigKZdDQpHaXZlbiB0aGF0IHRoZSBjdXJyZW50bHkgZGVmaW5lZCBhcmNoaXRlY3R1 cmUgYWxsb3dzIGZvciB0aGUgcmVxdWVzdGVkIGJlaGF2aW9yIHRocm91Z2ggcmVjbGFzc2lmaWNh dGlvbiwgSSBwZXJzb25hbGx5IHNlZSBubyByZWFzb24gZm9yIGEgY2hhbmdlIHRvIHRoZSB3YXkg ZGVjcmVtZW50IG9mIHNlcnZpY2UgaW5kZXggaXMgY3VycmVudGx5IGRlZmluZWQsIG90aGVyIHRo YW4gbWFraW5nIGl0IGV4cGxpY2l0IHRoYXQgZGVjcmVtZW50IG1lYW5zIOKAnGJ5IDHigJ0uDQpT Sz4gVGhlcmUgYXJlIG1hbnkgU0ZzIHRoYXQgZG8gbm90IHBlcmZvcm0gY2xhc3NpZmljYXRpb24u IFRoZXkgYXJlIHRyYW5zcGFyZW50bHkgaW5zZXJ0ZWQgYW5kIEkgYmVsaWV2ZSB0aGF0IGlzIG9u ZSBvZiB0aGUgbW90aXZhdGlvbnMgdG8gc3RlZXIgdHJhZmZpYyB0byB0aGVtIGluIFNGQywgdmlh IE5TSC4gVGhpcyBpcyBub3QgY2hhbmdpbmcgdGhlIChkZWZhdWx0KSBiZWhhdmlvciBvZiBOU0gs IGJ1dCBoYXZpbmcgTlNIIGJlIG1vcmUgYWNjb21tb2RhdGl2ZSBhbmQgaXQgaXMgbm90IHVucmVh c29uYWJsZS4NCg0KW0NoYWlyIGhhdCBvbuKApl0NCkkgd291bGQgbm90ZSB0aGF0IHdlIGFscmVh ZHkgaGF2ZSB3b3JraW5nIGdyb3VwIGFncmVlbWVudCBvbiB0aGUgY3VycmVudCBOU0ggc3BlY2lm aWNhdGlvbi4gQWxzbywgdGhlIGlzc3VlIG9mIHRoZSBlYXNlIG9mIG1vZGlmaWNhdGlvbiBvZiBT RlBzIHdhcyBwYXJ0IG9mIGVhcmxpZXIgd29ya2luZyBncm91cCBkaXNjdXNzaW9uLiAgSXMgdGhl cmUgbmV3IGluZm9ybWF0aW9uIHRoYXQgdGhvc2UgcmVxdWVzdGluZyBhIGJlaGF2aW9yYWwgY2hh bmdlIHdpc2ggdG8gYnJpbmcgZm9yd2FyZD8NClNLPiBXZSBoYXZlIGhhZCBkaXNjdXNzaW9ucyBv biB0aGUgJ1NJJyBvbiB0aGlzIGxpc3QgYnV0IGl0IHdhcyAqbmV2ZXIgY29uY2x1c2l2ZSouICBJ ZiBJIHJlY29sbGVjdCwgeW91ciBjaGFpciBoYXQgY2FtZSBkb3duIG9uIHVzIDotKQ0KDQpTdXJl bmRyYS4NCg0KSmltDQoNCg0KDQpPbiAxMS8zLzE2LCA5OjU1IEFNLCAic2ZjIG9uIGJlaGFsZiBv ZiBKb2VsIE0uIEhhbHBlcm4iIDxzZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam1o QGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQoNCj5Zb3UgYXNrIHdoZXRoZXIgdXNpbmcgbm9uLWNv bnNlY3VpdGl2ZSBpbnRlZ2VycyBmb3IgdGhlIFNJIGluIHRoZSBwYXRoIA0KPmJyZWFrcyBzb21l dGhpbmcuDQo+SXQgaXMgbm90IGZvcmJpZGRlbi4gIFlvdSBjYW4sIGFmdGVyIGFsbCwgcmVjbGFz c2lmeSBhdCBldmVyeSBob3AuICANCj4oQW5kIG1hbnkgY3VycmVudCBzb2x1dGlvbnMgZG8gc28u KQ0KPg0KPkhvd2V2ZXIsIGl0IGlzIG1pc2xlYWRpbmcgYXMgdG8gdGhlIGludGVudCBhbmQgZXhw ZWN0ZWQgdXNhZ2Ugb2YgU0ZDLiANCj5XaGlsZSBvbmUgY2FuIG1hbmFnZSB0byBtYWtlIGl0IHdv cmsgd2l0aCBtb25vdG9uaWNhbGx5IGRlY3JlYXNpbmcgYnV0IA0KPm5vbi1jb25zZWN1dGl2ZSBT SSwgaXQgaXMgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXguDQo+DQo+QXMgZmFyIGFzIEkgY2Fu IHRlbGwsIHRoZSBwbGFjZSB3aGVyZSB0aGlzIGlzIGFuIGlzc3VlIGZvciB0aGUgQkdQIFNGQyAN Cj5jb250cm9sIGRyYWZ0IGlzIG5vdCBpbiB0aGUgcHJvdG9jb2wgZGVmaW5pdGlvbi4gIFJhdGhl ciwgaXQgaXMgaW4gdGhlIA0KPmV4YW1wbGVzIHdoaWNoIGFsbCB0cmVhdCBub24tY29uc2VjdXRp dmUgYXMgdGhlIG5vcm1hbCBjYXNlLiAgVGhpcyBpcyANCj5jb25mdXNpbmcgdG8gcmVhZGVycyBh bmQgbGlrZWx5IHRvIGRyaXZlIGZvbGtzIHRvd2FyZHMgYXNzdW1wdGlvbnMgDQo+YWJvdXQgU0ZD IGJlaGF2aW9yIHRoYXQgd2lsbCBub3Qgd29yayB3aXRob3V0IGFkZGl0aW9uYWwgbWVjaGFuaXNt cy4NCj4NCj5Zb3VycywNCj5Kb2VsDQo+DQo+T24gMTEvMy8xNiA5OjIwIEFNLCBFcmljIEMgUm9z ZW4gd3JvdGU6DQo+PiBPbiAxMS8yLzIwMTYgNDo1MCBBTSwgRGF2ZSBEb2xzb24gd3JvdGU6DQo+ Pj4gRm9yIHRob3NlIHJlYXNvbnMsIEkgd291bGQgcHJlZmVyIHRvIHNlZSB0aGUgU0YgYWN0aW9u IGxpbWl0ZWQgdG8gDQo+Pj4gZGVjcmVtZW50LWJ5LW9uZS4gSWYgeW91IHJlcXVpcmUgb3RoZXJ3 aXNlLCBjby1sb2NhdGUgYSBjbGFzc2lmaWVyIA0KPj4+IHdpdGggdGhlIFNGLg0KPj4NCj4+IEZy b20gdGhlIHBlcnNwZWN0aXZlIG9mIGRyYWZ0LW1hY2tpZS1iZXNzLW5zaC1iZ3AtY29udHJvbC1w bGFuZSwgaXQgDQo+PiBkb2Vzbid0IG1hdHRlciB3aGV0aGVyIHRoZSBTUEkvU0kgZ2V0cyBtb2Rp ZmllZCBieSB0aGUgU0Ygb3IgYnkgYSANCj4+IGNvLXJlc2lkZW50IGNsYXNzaWZpZXIuICBUaGUg b25seSB0aGluZyB0aGF0IG1hdHRlcnMgaXMgd2hhdCBTUEkvU0kgDQo+PiB2YWx1ZXMgdGhlIFNG RiB3aWxsIG5lZWQgdG8gdXNlIGFzIGlucHV0IHRvIGl0cyBmb3J3YXJkaW5nIGVuZ2luZS4NCj4+ DQo+PiBBIHNsaWdodGx5IGRpZmZlcmVudCBpc3N1ZSBpcyB3aGV0aGVyIHRoZSBzdWNjZXNzaXZl IGVsZW1lbnRzIG9mIGFuIA0KPj4gU1BJIGhhdmUgdG8gaGF2ZSBzdWNjZXNzaXZlIGludGVnZXJz IGFzIHRoZWlyIHJlc3BlY3RpdmUgU0kncy4gIFRoYXQgDQo+PiBkb2Vzbid0IHNlZW0gdG8gYmUg bmVjZXNzYXJ5IGZvciB0aGUgcHJvcGVyIGZ1bmN0aW9uaW5nIG9mIHRoZSANCj4+IHN5c3RlbSwg c28gd2UgZGlkbid0IHdhbnQgdG8gYXNzdW1lIGl0LiAgQnkgbm90IHVzaW5nIHN1Y2Nlc3NpdmUg DQo+PiBpbnRlZ2VycywgaXQgYmVjb21lcyBlYXNpZXIgdG8gaW5zZXJ0IGFuZC9vciBkZWxldGUg ZW50cmllcy4gIEFuZCBpZiANCj4+IHRoZSBTRiBrbm93cyB0aGUgU0kgKGNhbGwgaXQgIngiKSBv ZiB0aGUgY3VycmVudCBlbGVtZW50IGluIHRoZSANCj4+IGNoYWluLCBpdCBkb2Vzbid0IHJlYWxs eSBoYXZlIHRvIGtub3cgdGhlIFNJIG9mIHRoZSBuZXh0IGVsZW1lbnQgaW4gDQo+PiB0aGUgY2hh aW4sIHNpbmNlIHRoZSBTRkYgY2FuIGludGVycHJldCAieC0xIiB0byBtZWFuICJuZXh0IGFmdGVy IHgiLCANCj4+IGFuZCBjYW4gdGhlbiBtb2RpZnkgdGhlIE5TSCB0byBjaGFuZ2UgdGhlIFNJIHRv IHRoZSBhY3R1YWwgU0kgb2YgdGhlIG5leHQgZWxlbWVudCBpbiB0aGUgY2hhaW4uDQo+Pg0KPj4g RG9lcyB0aGlzIGNyZWF0ZSBhIHRlY2huaWNhbCBwcm9ibGVtIG9mIHNvbWUgc29ydD8NCj4+DQo+ Pg0KPj4NCj4+DQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Thu Nov 3 11:26:05 2016 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 30DB21293E9 for ; Thu, 3 Nov 2016 11:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 tzq6NA-SLIBQ for ; Thu, 3 Nov 2016 11:26:01 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E015129697 for ; Thu, 3 Nov 2016 11:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17482; q=dns/txt; s=iport; t=1478197559; x=1479407159; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3Z5z1N5U6pVXSdaSGnJTio1+mD7cz8Ns60cphgsBOyo=; b=eEiFBx31PzqnsmmLCbHqBwek+wgy9xNiZ1eDxZTViCF1AeLn8bE0Cq4h GxHBkC4E5sHy2yizE2PlUpOnkYqAfU4wqSu5fjkuguEl6eflPnNXDjtqw KoPZaYqNUOodhijbDtPib2BjiR3NjNXis+UJy/zR81OPMSZWVBYAVCAtq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQCcgBtY/4ENJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzABAQEBAR9YfAeNMJcBlEeCCB0LgkSDNgKCAz8UAQIBAQEBAQEBYii?= =?us-ascii?q?EYQEBAQQBAQFrFwQCAQgRAQMBASgHJwsUAwYIAQEEARIIE4g7DrtnAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHIsUhCOGBAWEB4Q6hkuBAooSAYYzgwqGeIF1hG+DO4V?= =?us-ascii?q?yhyeFdoQDAR43a4MmHBiBRXKFP4EvgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,587,1473120000"; d="scan'208";a="165314896" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 18:25:58 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA3IPwDD012101 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2016 18:25:58 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 13:25:57 -0500 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; Thu, 3 Nov 2016 13:25:57 -0500 From: "Surendra Kumar (smkumar)" To: "mohamed.boucadair@orange.com" , Dave Dolson , Adrian Farrel , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAB8If2AADzdLoAAXSDUA Date: Thu, 3 Nov 2016 18:25:57 +0000 Message-ID: <31e80873bcd44153a4fef95948214f4c@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <15233159ac6a4f3792284537082dec7c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DA9905@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DA9905@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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.33.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 03 Nov 2016 18:26:04 -0000 Hi Med, It is relaxing the rigid requirement, requiring decrement by one and only o= ne. This would be too restrictive a language to put inside NSH. I can imagine implementations wanting to jump over an SF under policy contr= ol, either statically or dynamically, just as one simple example. This is n= ot reclassification. Whether the reasons are to prevent proliferation of SP= Is or to provide dynamic control, or something else, it is use case driven. It is increasingly a software defined infrastructure to put it mildly and I= would rather allow this while not affecting the default behavior. On the s= ame lines, there are already drafts that are carving the MD-Type1 allocatio= n on the fly - as per control plane - this is no different. Surendra. PS: A method to not even modify the 'SI' by SFs is described here: https://= datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/ -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Thursday, November 03, 2016 12:01 AM To: Surendra Kumar (smkumar) ; Dave Dolson ; Adrian Farrel ; 'Joel M. Halpern' ; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Surendra,=20 It seems to me that we are trying to modifyi the SFC data plane architectur= e to accommodate a given control plane solution proposal. As an editor of the SFC CP requirements I-D, I don't remember this "flexibi= lity" requirement was raised.=20 Can you please elaborate on why it is useful to have this control function? Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Surendra Kumar > (smkumar) > Envoy=E9=A0: jeudi 3 novembre 2016 00:46 > =C0=A0: Dave Dolson; Adrian Farrel; 'Joel M. Halpern'; sfc@ietf.org Objet= =A0 > : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > At the risk of spiraling (borrowing Adiran), this reasoning begs the=20 > question - why even have non-classifier SFs touch the SI to start with ? > I would argue to leave it alone and treat SPI+SI as a forwarding state=20 > and opaque to SFs. >=20 > Control plane can weave the same SF instance into thousands (well, it=20 > is a 24bit SPI) of SPIs and that shouldn't be a concern for the SF -=20 > consume metadata and service traffic. >=20 > Allowing for control plane programmed decrement value is very=20 > reasonable and useful. >=20 > Surendra. >=20 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Wednesday, November 02, 2016 1:51 AM > To: Adrian Farrel ; Surendra Kumar (smkumar)=20 > ; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > Adrian, > Perhaps I'm making too fine a point, but I consider that if an SF does=20 > anything other than decrementing the SI by 1, we've entered the realm=20 > of reclassification, and it is a Classifier co-located with the SF=20 > that is overriding the SPI/SI. >=20 > If you refer to Figure 8, path selection is not an action done by an SF. >=20 > Once reclassification is added to a deployment, we can have unicorns=20 > (and also dragons); much more becomes possible, but it also becomes=20 > much more difficult to reason about. >=20 > You can read in the (expired) draft-penno-sfc-packet-03 some ideas=20 > about packet reversal that depending heavily on rigid SF=20 > decrement-by-one. I don't know how to begin reasoning about reverse=20 > forwarding once reclassification is added... >=20 > For those reasons, I would prefer to see the SF action limited to=20 > decrement-by-one. If you require otherwise, co-locate a classifier=20 > with the SF. >=20 >=20 > -Dave >=20 >=20 >=20 > Original Message > From: Adrian Farrel > Sent: Tuesday, November 1, 2016 9:52 PM > To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern';=20 > sfc@ietf.org Reply To: adrian@olddog.co.uk > Subject: OK. Enough with the looping (spiralling :-) [Was:=20 > decrementing service function path index] >=20 >=20 > Been thinking about this instead of sleeping. >=20 > Keep getting caught in rat-holes that say "no, but you could build=20 > product like this." But they are real rat-holes. What we need is a set=20 > of rule that work for simple implementations *and* that do not=20 > preclude more sophisticated implementations. >=20 > So... >=20 > When a packet arrives at an SFF the SPI/SI indicates the SFP and the=20 > next hop on that SFP to be executed. >=20 > When an SF has finished processing a packet the default behavior is to=20 > leave the SPI unchanged and to decrement the SI by 1. >=20 > However, and SF MAY know to make other changes to a the SPI and SI.=20 > How that knowledge is installed in the SF is implementation dependent: > - it may be the result of configuration (for example, normally=20 > decrement by > 1 but in event of a specific condition forward to a different=20 > chain) > - it may be the result of a policy and visibility of the SFP > - it may be based on information in the metadata > - there may be unicorns >=20 > There may be a classifier co-resident with the SF or in the path from=20 > SF back to SFF so that the SPI/SI received by the SFF is not a simple=20 > decrement of the SI. >=20 > There may be a classifier co-resident with the SFF that processes the=20 > packet before the SFF performs forwarding so that the SPI/SI received=20 > by the SFF is not a simple decrement of the SI. >=20 > The SFF's routing lookup may give it a choice of SFIs or SFFs to which=20 > to send the packet for the given SPI/SI. How it resolves this choice=20 > is a local matter (some policy that might be load balancing and could=20 > be influenced by any manner of things if an implementation chooses=20 > without prejudice to the interoperability of replaceability of SFFs).=20 > The fact of the choice is a function of how the network has been=20 > built, and how SFIs have been assigned, and how the SFPs have been=20 > constructed by the controller - it is not a function of the NSH itself. >=20 > The SFF's forwarding instructions can be simple (look up SPI/SI and=20 > send the packet out of interface X encapsulated in tunnel Y) or more=20 > complex (make some form of choice and manipulate the packet) just as=20 > in most other modern forwarding paradigms. >=20 > An SFF that does not recognise the SPI/SI (i.e., has no forwarding=20 > state for it) can only (read MUST) drop the packet. >=20 > What forwarding state an SFF has is a matter of: > - implementation > - control/management plane instructions > - visibility into the SFP (and other SFPs) >=20 >=20 > I believe this set of rules is consistent with 7665 and also supports=20 > what the WG wanted to achieve with the NSH draft without requiring any=20 > limitation on processing. That is, a simple implementation as=20 > envisaged by the proponents of "MUST decrement by one" is able to=20 > perform that function and still be conformant and interoperable.=20 > Similarly, a simple SFF as suggested in this thread would have no problem= s interoperating. >=20 > Similarly, this behavior is flexible enough to allow for other uses=20 > and implementations. It is consistent with=20 > draft-mackie-bess-nsh-bgp-control- > plane > (indeed, that draft doesn't tell the SF what to do with the SPI/SI at=20 > all) and allows a control plane to program an SFF to do more=20 > sophisticated things. Of course, if the SFF cannot do those things=20 > then that will be OK since it won't support those control plane instructi= ons. >=20 > Can we put this to bed with the minimal change to=20 > draft-ietf-sfc-nsh-10 section > 4 as follows: >=20 > OLD > 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. > NEW > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > service index. By default the SF decrements the SI by 1, but it > MAY apply other decrements according to configuration and other > information available to it. If an SFF receives a packet with > an SPI and SI for which it does not have forwarding state, > it MUST be drop the packet, and SHOULD log the event subject to > rate limiting on such logs. > END >=20 > Similarly later in the same bullet... > OLD > 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. > NEW > 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. By default the SFC Proxy decrements the SI by 1, > but it MAY apply other decrements according to configuration and > other information available to it. > END >=20 > Furthermore, in section 3.3 since the term "egress NSH packet" is=20 > either ambiguous or neglects the possibility of reclassification... >=20 > OLD > 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. > NEW > Service Index MUST be decremented by Service Functions or by SFC > Proxy nodes after performing required services as described in > Section 4. 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. > END >=20 >=20 > Now perhaps I can sleep :-) >=20 > Adrian >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 23:22 > > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M.=20 > > Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > I agree that the SF should be simple. > > But don't confuse decrementing the SI with complexity. > > There is absolutely no configuration required to have the SF=20 > > decrement the SI > of > > every packet. > > And there is a lot of benefit to keeping the SFF from having rules=20 > > about > packet > > source. > > > > As far as I'm concerned, the SF decrements the SI, and it has been=20 > > described > this > > way for a long time. Furthermore, the forwarding is described as a=20 > > lookup > table > > based on SPI/SI. There is no mention of the source in the forwarding > table. > > > > > > > > > > Original Message > > From: Surendra Kumar (smkumar) > > Sent: Tuesday, November 1, 2016 7:03 PM > > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern';=20 > > sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > > > Since the forwarders already exists, they are logical components to=20 > > support > and > > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > > them as dumb forwarders. There is benefit to be had, offloads being=20 > > one of them, on > top > > of end of chain forwarding, etc. needed. > > > > I would rather have SFs focus on servicing the traffic than be=20 > > burdened with > SPI > > management (whether it is tens or thousands of SPIs) and the=20 > > forwarding thereof. IOW, consume metadata and service traffic and=20 > > leave the SFP management to the external forwarders. This not only=20 > > simplifies the SFs, it > also > > reduces the control plane touch point as it concerns to the SPI > management. > > > > And you don't need complex logic to differentiate between traffic=20 > > received > from > > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > > trivial > to > > implement even in hardware. > > > > Thanks, > > Surendra. > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > Sent: Tuesday, November 01, 2016 1:27 PM > > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > > sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > Adrian, > > Thank you for paraphrasing in a clear manner. > > > > Yes, I'm saying that the current (as I understand it) design permits=20 > > the SFF > to be a > > simple forwarder, not needing to discriminate between packets from=20 > > another SFF or returning from an SF. > > A single forwarding table handles both cases. > > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > > > So it could tell the difference, but doesn't need to. > > In some cases, an SFF can be a single-interface device, so "from SFF" > > or "from > SF" > > is not as simple as checking ingress interface, for example. > > > > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Tuesday, November 01, 2016 4:00 PM > > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > Just clarifying my understanding of what you said (not necessarily=20 > > agreeing > ;-) > > > > You are saying that an SFF is simply a forwarder and cannot tell the > difference > > between a packet received on a transport tunnel from another SFF and=20 > > a packet received (back) from an SF that it serves. > > > > Or, more precisely, you are saying that the SFF is simply a=20 > > forwarder that cannot tell the difference between passing a packet=20 > > to a local SF and passing > a > > packet on to a remote SFF. > > > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > > > Is that your point? > > > > Cheers, > > Adrian > > > > -- > > Support an author and your imagination. > > Tales from the Wood - Eighteen new fairy tales. > > More Tales from the Wood - Eighteen MORE new fairy tales. > > https://www.feedaread.com/profiles/8604/ > > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > > Or buy from me direct. > > > > > > > > > -----Original Message----- > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > Sent: 01 November 2016 19:35 > > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > > Subject: RE: [sfc] decrementing service function path index > > > > > > The SF decrements the index so that the SFF doesn't have to look=20 > > > at the > packet > > > origin in order to determine whether or not to decrement it. > > > We don't want the SFF to have logic like: > > > If NSH packet is from one of addresses x, y z > > > Decrement SI > > > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > > without having > > to > > > do consider source address. > > > > > > > > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > > Sent: Tuesday, November 01, 2016 2:48 PM > > > To: 'Joel M. Halpern'; sfc@ietf.org > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > With regard to the architectural components, the NSH draft does=20 > > > > not define those. It is using the architectural, logical,=20 > > > > components and architecture defined by the SFC Architecture > documents. > > > > > > I'd like to understand where in 7665 it says that the SF is=20 > > > responsible for moving the packet on to the next SF in the path, > rather than the SFF. > > > > > > I'd also like to understand why the NSH document (that tells us=20 > > > how to encapsulate, and what to do at each hop in the path) needs=20 > > > to divide the responsibility for bits of protocol work between=20 > > > different logical > functional > > > entities. In short, why does the SF decrement the SI, why isn't=20 > > > this an SFF function? What benefit comes from doing it this way or=20 > > > did a choice simply > > have > > > to be made? > > > > > > 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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Nov 3 11:39:42 2016 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 5870F129570 for ; Thu, 3 Nov 2016 11:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 W0RHIXVCpxkj for ; Thu, 3 Nov 2016 11:39:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2800129479 for ; Thu, 3 Nov 2016 11:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=912; q=dns/txt; s=iport; t=1478198380; x=1479407980; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yCG17bnsXHNvvRJEN6b1MFqL2FcqypfYKz/7A5pYMds=; b=CmwPx0ogJldNGSUGrP5023Q3/jmg0M35lnQ5ycFy9s9eJq/dlOq2td35 yCWjAzN70l31FqI0xvc1fVUPcS7MBDEa5+3UuP+TCuuXyZo21332qoNvk 2n2qP7xqcgPFDLjAPeoXlwvQNC6/QiXH8VaQsOBRqUfVQkJ2i1erzWaBi Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQB/gxtY/4MNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzABAQEBAR9YfAeNMJcBlEeCCB0LhXoCggM/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEDAQEBATc0CwULAgEIGB4QJwslAgQOBYhOCA67XAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARcFhj+BfQiCUIRHgzGCLwWUQoVeAZA8kAqNHYQDAR43a4MjH4F?= =?us-ascii?q?dcoZugQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,587,1473120000"; d="scan'208";a="167137506" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 18:39:39 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uA3IddIm024661 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2016 18:39: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; Thu, 3 Nov 2016 13:39:38 -0500 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, 3 Nov 2016 13:39:38 -0500 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] NSH MD-1 description Thread-Index: AQHSNTNd+aFHqNv0Y0+9hnZsBFV2iqDH7K0A Date: Thu, 3 Nov 2016 18:39:38 +0000 Message-ID: <92290849-D4D9-41F7-B6B0-2E63DD671322@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.19.17.235] Content-Type: text/plain; charset="us-ascii" Content-ID: <76CD877F685E544CA2399414D4EA1609@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH MD-1 description 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, 03 Nov 2016 18:39:41 -0000 Joel, That works for me. Paul > On Nov 2, 2016, at 1:57 PM, Joel M. Halpern wrote: >=20 > > Given that various existing MD-1 proposals break up the "4" fields in var= ious ways, and given that we may want to allow , for example, a singl 64 bi= t field in some MD-1 allocation, it seems cleaner and more consistent to me= to describe the MD-1 content as a block of 16 bytes rather than as 4 4 byt= e words. >=20 > Given that this is purely descriptive for the NSH document, I do not see = a down side. YANG models for metadata are a more complex question, but the= simple 4x4 byte representation is probably not want we want there either. >=20 > Yours, > Joel >=20 > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Nov 4 00:49:17 2016 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 001191293D6 for ; Fri, 4 Nov 2016 00:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 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=-1.497, 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 g98SyyvY6-WE for ; Fri, 4 Nov 2016 00:49:12 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.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 6361C127077 for ; Fri, 4 Nov 2016 00:49:12 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id AA75D1804C6; Fri, 4 Nov 2016 08:49:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 6CA741A0059; Fri, 4 Nov 2016 08:49:10 +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; Fri, 4 Nov 2016 08:49:10 +0100 From: To: "Surendra Kumar (smkumar)" , Dave Dolson , Adrian Farrel , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAB8If2AADzdLoAAXSDUAABsuotA= Date: Fri, 4 Nov 2016 07:49:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DAC4C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <15233159ac6a4f3792284537082dec7c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DA9905@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <31e80873bcd44153a4fef95948214f4c@XCH-RCD-020.cisco.com> In-Reply-To: <31e80873bcd44153a4fef95948214f4c@XCH-RCD-020.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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 04 Nov 2016 07:49:16 -0000 Hi Surendra,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Envoy=E9=A0: jeudi 3 novembre 2016 19:26 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Dave Dolson; Adrian Farrel; 'Joel M. > Halpern'; sfc@ietf.org > Objet=A0: RE: OK. Enough with the looping (spiralling :-) [Was: decrement= ing > service function path index] >=20 > Hi Med, >=20 > It is relaxing the rigid requirement, requiring decrement by one and only > one. This would be too restrictive a language to put inside NSH. [Med] SI is there to achieve two objectives: location within a chain + loop= detect. If we assume that the base SFC design is that a packet bound to a = given chain has to cross **all** the SF instances that compose that chain, = decrementing the index by one becomes trivial while decrementing by other v= alues is not justified. >=20 > I can imagine implementations wanting to jump over an SF under policy > control, either statically or dynamically, just as one simple example. [Med] We can consider this case from several perspectives, e.g.,:=20 (1) This is deployment-specific. There are other ways to achieve the same r= esult: create a new chain that does not involve that SF, for example. (2) This is implementation-specific. I hear that jumping over an SF can be = achieved relying on some optimization that will preserve the size of the cl= assification table. For example, a signal can be sent from an SF to its SFF= . Doing so requires modifications to both SF and SFF. One can consider that= the hook required in an SFF to honor a request from an SF is designed as a= service function ("Void SF" co-located with an SFF). Under that design, th= e Void SF will proceed in place of the SF to be jumped. No modification is = then required to the processing of SI in such design. > This is not reclassification. Whether the reasons are to prevent > proliferation of SPIs or to provide dynamic control, or something else, i= t > is use case driven. >=20 > It is increasingly a software defined infrastructure to put it mildly and > I would rather allow this while not affecting the default behavior. On th= e > same lines, there are already drafts that are carving the MD-Type1 > allocation on the fly - as per control plane - this is no different. [Med] I don't think we can put these two on the same level. Further, the co= ntrol of the metadata is a clear control plane requirement. As an editor of= the CP requirement draft, I'm still trying to understand if there is somet= hing that needs to be added to that document to capture a NEW requirement t= hat wasn't raised before. Thank you. >=20 > Surendra. > PS: A method to not even modify the 'SI' by SFs is described here: > https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/ >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, November 03, 2016 12:01 AM > To: Surendra Kumar (smkumar) ; Dave Dolson > ; Adrian Farrel ; 'Joel M. > Halpern' ; sfc@ietf.org > Subject: RE: OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > Hi Surendra, >=20 > It seems to me that we are trying to modifyi the SFC data plane > architecture to accommodate a given control plane solution proposal. >=20 > As an editor of the SFC CP requirements I-D, I don't remember this > "flexibility" requirement was raised. >=20 > Can you please elaborate on why it is useful to have this control > function? >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Surendra Kumar > > (smkumar) > > Envoy=E9=A0: jeudi 3 novembre 2016 00:46 > > =C0=A0: Dave Dolson; Adrian Farrel; 'Joel M. Halpern'; sfc@ietf.org Obj= et > > : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > At the risk of spiraling (borrowing Adiran), this reasoning begs the > > question - why even have non-classifier SFs touch the SI to start with = ? > > I would argue to leave it alone and treat SPI+SI as a forwarding state > > and opaque to SFs. > > > > Control plane can weave the same SF instance into thousands (well, it > > is a 24bit SPI) of SPIs and that shouldn't be a concern for the SF - > > consume metadata and service traffic. > > > > Allowing for control plane programmed decrement value is very > > reasonable and useful. > > > > Surendra. > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: Wednesday, November 02, 2016 1:51 AM > > To: Adrian Farrel ; Surendra Kumar (smkumar) > > ; 'Joel M. Halpern' ; > > sfc@ietf.org > > Subject: Re: OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > Adrian, > > Perhaps I'm making too fine a point, but I consider that if an SF does > > anything other than decrementing the SI by 1, we've entered the realm > > of reclassification, and it is a Classifier co-located with the SF > > that is overriding the SPI/SI. > > > > If you refer to Figure 8, path selection is not an action done by an SF= . > > > > Once reclassification is added to a deployment, we can have unicorns > > (and also dragons); much more becomes possible, but it also becomes > > much more difficult to reason about. > > > > You can read in the (expired) draft-penno-sfc-packet-03 some ideas > > about packet reversal that depending heavily on rigid SF > > decrement-by-one. I don't know how to begin reasoning about reverse > > forwarding once reclassification is added... > > > > For those reasons, I would prefer to see the SF action limited to > > decrement-by-one. If you require otherwise, co-locate a classifier > > with the SF. > > > > > > -Dave > > > > > > > > Original Message > > From: Adrian Farrel > > Sent: Tuesday, November 1, 2016 9:52 PM > > To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern'; > > sfc@ietf.org Reply To: adrian@olddog.co.uk > > Subject: OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > > > Been thinking about this instead of sleeping. > > > > Keep getting caught in rat-holes that say "no, but you could build > > product like this." But they are real rat-holes. What we need is a set > > of rule that work for simple implementations *and* that do not > > preclude more sophisticated implementations. > > > > So... > > > > When a packet arrives at an SFF the SPI/SI indicates the SFP and the > > next hop on that SFP to be executed. > > > > When an SF has finished processing a packet the default behavior is to > > leave the SPI unchanged and to decrement the SI by 1. > > > > However, and SF MAY know to make other changes to a the SPI and SI. > > How that knowledge is installed in the SF is implementation dependent: > > - it may be the result of configuration (for example, normally > > decrement by > > 1 but in event of a specific condition forward to a different > > chain) > > - it may be the result of a policy and visibility of the SFP > > - it may be based on information in the metadata > > - there may be unicorns > > > > There may be a classifier co-resident with the SF or in the path from > > SF back to SFF so that the SPI/SI received by the SFF is not a simple > > decrement of the SI. > > > > There may be a classifier co-resident with the SFF that processes the > > packet before the SFF performs forwarding so that the SPI/SI received > > by the SFF is not a simple decrement of the SI. > > > > The SFF's routing lookup may give it a choice of SFIs or SFFs to which > > to send the packet for the given SPI/SI. How it resolves this choice > > is a local matter (some policy that might be load balancing and could > > be influenced by any manner of things if an implementation chooses > > without prejudice to the interoperability of replaceability of SFFs). > > The fact of the choice is a function of how the network has been > > built, and how SFIs have been assigned, and how the SFPs have been > > constructed by the controller - it is not a function of the NSH itself. > > > > The SFF's forwarding instructions can be simple (look up SPI/SI and > > send the packet out of interface X encapsulated in tunnel Y) or more > > complex (make some form of choice and manipulate the packet) just as > > in most other modern forwarding paradigms. > > > > An SFF that does not recognise the SPI/SI (i.e., has no forwarding > > state for it) can only (read MUST) drop the packet. > > > > What forwarding state an SFF has is a matter of: > > - implementation > > - control/management plane instructions > > - visibility into the SFP (and other SFPs) > > > > > > I believe this set of rules is consistent with 7665 and also supports > > what the WG wanted to achieve with the NSH draft without requiring any > > limitation on processing. That is, a simple implementation as > > envisaged by the proponents of "MUST decrement by one" is able to > > perform that function and still be conformant and interoperable. > > Similarly, a simple SFF as suggested in this thread would have no > problems interoperating. > > > > Similarly, this behavior is flexible enough to allow for other uses > > and implementations. It is consistent with > > draft-mackie-bess-nsh-bgp-control- > > plane > > (indeed, that draft doesn't tell the SF what to do with the SPI/SI at > > all) and allows a control plane to program an SFF to do more > > sophisticated things. Of course, if the SFF cannot do those things > > then that will be OK since it won't support those control plane > instructions. > > > > Can we put this to bed with the minimal change to > > draft-ietf-sfc-nsh-10 section > > 4 as follows: > > > > OLD > > 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. > > NEW > > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > > service index. By default the SF decrements the SI by 1, but it > > MAY apply other decrements according to configuration and other > > information available to it. If an SFF receives a packet with > > an SPI and SI for which it does not have forwarding state, > > it MUST be drop the packet, and SHOULD log the event subject to > > rate limiting on such logs. > > END > > > > Similarly later in the same bullet... > > OLD > > 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. > > NEW > > 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. By default the SFC Proxy decrements the SI by 1, > > but it MAY apply other decrements according to configuration and > > other information available to it. > > END > > > > Furthermore, in section 3.3 since the term "egress NSH packet" is > > either ambiguous or neglects the possibility of reclassification... > > > > OLD > > 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. > > NEW > > Service Index MUST be decremented by Service Functions or by SFC > > Proxy nodes after performing required services as described in > > Section 4. 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 fo= r > > the resultant SPI. > > END > > > > > > Now perhaps I can sleep :-) > > > > Adrian > > > > > -----Original Message----- > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > Sent: 01 November 2016 23:22 > > > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. > > > Halpern'; sfc@ietf.org > > > Subject: Re: [sfc] decrementing service function path index > > > > > > I agree that the SF should be simple. > > > But don't confuse decrementing the SI with complexity. > > > There is absolutely no configuration required to have the SF > > > decrement the SI > > of > > > every packet. > > > And there is a lot of benefit to keeping the SFF from having rules > > > about > > packet > > > source. > > > > > > As far as I'm concerned, the SF decrements the SI, and it has been > > > described > > this > > > way for a long time. Furthermore, the forwarding is described as a > > > lookup > > table > > > based on SPI/SI. There is no mention of the source in the forwarding > > table. > > > > > > > > > > > > > > > Original Message > > > From: Surendra Kumar (smkumar) > > > Sent: Tuesday, November 1, 2016 7:03 PM > > > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; > > > sfc@ietf.org > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > > Since the forwarders already exists, they are logical components to > > > support > > and > > > perform NSH based forwarding - forwarding on SFPs, rather than treat > > > them as dumb forwarders. There is benefit to be had, offloads being > > > one of them, on > > top > > > of end of chain forwarding, etc. needed. > > > > > > I would rather have SFs focus on servicing the traffic than be > > > burdened with > > SPI > > > management (whether it is tens or thousands of SPIs) and the > > > forwarding thereof. IOW, consume metadata and service traffic and > > > leave the SFP management to the external forwarders. This not only > > > simplifies the SFs, it > > also > > > reduces the control plane touch point as it concerns to the SPI > > management. > > > > > > And you don't need complex logic to differentiate between traffic > > > received > > from > > > one SFF or a SF, this is what we addressed in the forwarding draft - > > > trivial > > to > > > implement even in hardware. > > > > > > Thanks, > > > Surendra. > > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > > Sent: Tuesday, November 01, 2016 1:27 PM > > > To: adrian@olddog.co.uk; 'Joel M. Halpern' ; > > > sfc@ietf.org > > > Subject: Re: [sfc] decrementing service function path index > > > > > > Adrian, > > > Thank you for paraphrasing in a clear manner. > > > > > > Yes, I'm saying that the current (as I understand it) design permits > > > the SFF > > to be a > > > simple forwarder, not needing to discriminate between packets from > > > another SFF or returning from an SF. > > > A single forwarding table handles both cases. > > > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > > > > > So it could tell the difference, but doesn't need to. > > > In some cases, an SFF can be a single-interface device, so "from SFF" > > > or "from > > SF" > > > is not as simple as checking ingress interface, for example. > > > > > > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: Tuesday, November 01, 2016 4:00 PM > > > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > > > Subject: RE: [sfc] decrementing service function path index > > > > > > Just clarifying my understanding of what you said (not necessarily > > > agreeing > > ;-) > > > > > > You are saying that an SFF is simply a forwarder and cannot tell the > > difference > > > between a packet received on a transport tunnel from another SFF and > > > a packet received (back) from an SF that it serves. > > > > > > Or, more precisely, you are saying that the SFF is simply a > > > forwarder that cannot tell the difference between passing a packet > > > to a local SF and passing > > a > > > packet on to a remote SFF. > > > > > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > > > > > Is that your point? > > > > > > Cheers, > > > Adrian > > > > > > -- > > > Support an author and your imagination. > > > Tales from the Wood - Eighteen new fairy tales. > > > More Tales from the Wood - Eighteen MORE new fairy tales. > > > https://www.feedaread.com/profiles/8604/ > > > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > > > Or buy from me direct. > > > > > > > > > > > > > -----Original Message----- > > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > > Sent: 01 November 2016 19:35 > > > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > The SF decrements the index so that the SFF doesn't have to look > > > > at the > > packet > > > > origin in order to determine whether or not to decrement it. > > > > We don't want the SFF to have logic like: > > > > If NSH packet is from one of addresses x, y z > > > > Decrement SI > > > > > > > > As currently defined, the SFF simply routes packets by SPI/SI > > > > without having > > > to > > > > do consider source address. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > > > Sent: Tuesday, November 01, 2016 2:48 PM > > > > To: 'Joel M. Halpern'; sfc@ietf.org > > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > > > With regard to the architectural components, the NSH draft does > > > > > not define those. It is using the architectural, logical, > > > > > components and architecture defined by the SFC Architecture > > documents. > > > > > > > > I'd like to understand where in 7665 it says that the SF is > > > > responsible for moving the packet on to the next SF in the path, > > rather than the SFF. > > > > > > > > I'd also like to understand why the NSH document (that tells us > > > > how to encapsulate, and what to do at each hop in the path) needs > > > > to divide the responsibility for bits of protocol work between > > > > different logical > > functional > > > > entities. In short, why does the SF decrement the SI, why isn't > > > > this an SFF function? What benefit comes from doing it this way or > > > > did a choice simply > > > have > > > > to be made? > > > > > > > > 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 Fri Nov 4 08:39:17 2016 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 D431112958A for ; Fri, 4 Nov 2016 08:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 CmGmd1yMmzpT for ; Fri, 4 Nov 2016 08:39:14 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 5D391129587 for ; Fri, 4 Nov 2016 08:39:09 -0700 (PDT) Received: from localhost ([::1]:40653 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c2gaC-0003mk-Ot; Fri, 04 Nov 2016 08:39:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Fri, 04 Nov 2016 15:39:07 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/21#comment:1 Message-ID: <082.4152732488650aa020cacfaa2cdfd99e@tools.ietf.org> References: <067.dc54e9d77c52259b570d6b5dd0ba201f@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <067.dc54e9d77c52259b570d6b5dd0ba201f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20161104153909.5D391129587@ietfa.amsl.com> Resent-Date: Fri, 4 Nov 2016 08:39:09 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #21 (nsh): MD#1 Interoperability text (Proposed by Lucy) 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: Fri, 04 Nov 2016 15:39:16 -0000 #21: MD#1 Interoperability text (Proposed by Lucy) Comment (by mohamed.boucadair@orange.com): An updated version of the text proposal: == This specification does not make any assumption about the content placed in the mandatory context field of the NSH header. Further, the NSH header does not reveal the structure of the data included in the mandatory context field. An SFC-aware SF MUST receive the data extraction schema first in order to get the data placed in the mandatory context field. How an SFC-aware SF gets that data extraction schema is outside the scope of this specification. Upon receiving an NSH MD#1 packet, if the SFC-aware SF is configured to use metadata but does not yet receive the data extraction schema for the mandatory context field, it MUST NOT process the packet and MUST log this error. == -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Fri Nov 4 10:43:04 2016 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 B0FCE1295ED for ; Fri, 4 Nov 2016 10:43:02 -0700 (PDT) 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 qYStYoHvCOYV for ; Fri, 4 Nov 2016 10:43:01 -0700 (PDT) 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 D6BA0129444 for ; Fri, 4 Nov 2016 10:43:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C462024092F for ; Fri, 4 Nov 2016 10:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478281381; bh=rzUEbAr3Ly+drBab8UeVd4FAvDdFOT7yXgFcN8w/ZTs=; h=To:From:Subject:Date:From; b=mTvlhFyHp0JFiEouLU1kicOaZk+6uIjgGLL1mf1Pm6ln2/qmm+1pXSjuh3ukUaJD8 fwHB6L48qxEqMU97BEDWqNlEYLDdQ227LzbjjYOM+pD3ac7Al6k9+KDJpDngoz5BAf B072aVQK1M/vuE6HIMz/Vyezyf5Mley5OpknjWOI= 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 64F9E24019F for ; Fri, 4 Nov 2016 10:43:01 -0700 (PDT) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: <4e7a4b73-72c3-76d9-81f5-8de804c0a419@joelhalpern.com> Date: Fri, 4 Nov 2016 13:43:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Meeting planning 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, 04 Nov 2016 17:43:03 -0000 Jim and I are working on the agenda for the Seoul meeting. Our apologies for being late with this information. As I am new to chairing this WG, I want to hear from folks on issues of concern to them regarding the working group. I am happy to meet individually with folks in Seoul. I am also happy to make time for phone or skype conversations outside of the IETF meeting. I am of course available by email at almost all times. Thank you, Joel From nobody Fri Nov 4 11:08:30 2016 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 7B7B712960D; Fri, 4 Nov 2016 11:07:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147828287649.17175.3224627694520916389.idtracker@ietfa.amsl.com> Date: Fri, 04 Nov 2016 11:07:56 -0700 Archived-At: Cc: sfc@ietf.org, ipr-announce@ietf.org Subject: [sfc] IPR Disclosure Cisco's Statement about IPR related to draft-ietf-sfc-nsh 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: Fri, 04 Nov 2016 18:07:56 -0000 Dear Paul Quinn, Uri Elzur: An IPR disclosure that pertains to your Internet-Draft entitled "Network Service Header" (draft-ietf-sfc-nsh) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2905/). The title of the IPR disclosure is "Cisco's Statement about IPR related to draft-ietf-sfc-nsh" Thank you IETF Secretariat From nobody Fri Nov 4 13:13:07 2016 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 0C1C51294F4 for ; Fri, 4 Nov 2016 13:13:06 -0700 (PDT) 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 pyz3SdRtX3Vi for ; Fri, 4 Nov 2016 13:13:04 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 E7A371293EB for ; Fri, 4 Nov 2016 13:13:03 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id o141so517143lff.1 for ; Fri, 04 Nov 2016 13:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DQnp0d1SpMQNQx4Sy76ACnAAkSQ4pucFA99wr6Me28A=; b=Pq9yuYEat1e5J4ubmMxGLnkMCL9zetMRSH+mDiMPLsDRd99k5J+UjZ9+CoSrd9AGn/ ileP5NCIPc/BfhpeseLfBha9+Rptxdln88PZgYN6MRDsIt9xZWSb7/rGAVe+xaohjUVd QTVyAx5w6Krr+qjyhx3YPbOYVmPKdkPu28tfp4b4RQQcQTZprDdtlKrUC8Uzb1iAb2W+ Bur+PZVTvYiqKvic02U8bfgc7a+7fpPgLTp395q5oK1hGwLP9jktvnc5X/jqBhc4Yce1 ryTvhRgtTkuKZsk5O6Oef7Ozb4Pvj6Gsp2Ee3sIf5/qMkc/PvUPr4h4i4T0f165Rk4QN st0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=DQnp0d1SpMQNQx4Sy76ACnAAkSQ4pucFA99wr6Me28A=; b=h4teYbx32ffrW5ZsXxfMusRmzpq9aPXCwjLX3pwSVzX1MwtOmrHmbMOEeU178NHcum 6Exxrx8r71M97pZNfVCxeoeGEvkh6N4llcSsIztWUMHjrkS3H2KkRUv7F9RzJJfbjc3G ntryqW+GzHqtf96+Yd3CFfkfnZpdUylGX3TGIkfLbz14QfxyHck8TtfI+oKVYO+KkhA2 GcxNT+vqFx3c2yv8SVpnJBnIw30XcpoRtzU7bXn/BEmZRDwVazYDnpQ4V480qdwu1BQD uCiawoR6yVbboT7zQRMpAh0x6T+KHts+geP5zL8fbcv06/ejhfr5lJjnjNsaOAiB2+ek x3LA== X-Gm-Message-State: ABUngvcOEL41+3bA3r8jFBjscTuHTs2iyPC6YS7oBSj1XZdlB08SerKhqHMfaAZVvdVIVXt7jSst9QoKD2FdDw== X-Received: by 10.25.18.90 with SMTP id h87mr8020101lfi.91.1478290381847; Fri, 04 Nov 2016 13:13:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.228.210 with HTTP; Fri, 4 Nov 2016 13:13:01 -0700 (PDT) In-Reply-To: References: From: Behcet Sarikaya Date: Fri, 4 Nov 2016 15:13:01 -0500 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH MD-1 description 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: Fri, 04 Nov 2016 20:13:06 -0000 I think that definitely some action is needed on the definition of metadata Type 1 draft-ietf-sfc-nsh-10 I have never been able to figure out why four Context Headers, 4-byte each, MUST be added immediately following the Service Path Header. What is the role of the number 4? It has not been explained in the document. Different use cases have different requirements and I have not seen 4 MD Type 1 defined in a sensible manner for each use case that we know so far. There is a proposal for the data center use case in draft-guichard which contains exactly 4 data types. That seems to be about it. For the mobility use there is a proposal but it defines 3 data not 4. I don't understand why this point waited so long (until Rev. 11) to get fixed? I think fixing it is not going to be easy, it should have been addressed much earlier. Regards Behcet On Wed, Nov 2, 2016 at 12:57 PM, Joel M. Halpern wrote: > > Given that various existing MD-1 proposals break up the "4" fields in > various ways, and given that we may want to allow , for example, a singl 64 > bit field in some MD-1 allocation, it seems cleaner and more consistent to > me to describe the MD-1 content as a block of 16 bytes rather than as 4 4 > byte words. > > Given that this is purely descriptive for the NSH document, I do not see a > down side. YANG models for metadata are a more complex question, but the > simple 4x4 byte representation is probably not want we want there either. > > Yours, > Joel > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Nov 4 13:25:22 2016 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 C6AA512944E for ; Fri, 4 Nov 2016 13:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 cXshWHs9awUM for ; Fri, 4 Nov 2016 13:25:19 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D149129615 for ; Fri, 4 Nov 2016 13:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3216; q=dns/txt; s=iport; t=1478291118; x=1479500718; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TX7iUp16jJmy8tDinrp+7vmqQ6fsqgQxa+QX6/fM1f4=; b=Pk33k5Aiq2epn9+QwnCXlaRPJ80qJcuASXj9NDiok33gihqlMttmmev/ k0G5+odB1VCizYiID/NwjXtxfnG1PWzGaQM2rbyBuWfP8pNmpkOPZpxiR g8VYWKyu6k8/bTL5QJ5rXYgWHK42bvG6gKHNeXHBHpte5Bmf65XNpekJW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAQA37hxY/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAR9YfAeNMZcAh2CMZoIIHQuFewIagX4/FAECAQEBAQE?= =?us-ascii?q?BAWIohGIBAQQBAQEgEToLEAIBCBgCAiYCAgIfBgsVEAIEAQ0FiD4DFw6vFYh8D?= =?us-ascii?q?YNuAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBCYU2gX2CWIJHgVIRAQyDFC2CLwW?= =?us-ascii?q?ZbjUBhjOGVoM2gW6Eb4ktiQGEIIQDAR43bIMlH4FdcgGFFoEhgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,445,1473120000"; d="scan'208";a="342882171" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2016 20:25:17 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA4KPHP3016168 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 20:25:17 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; Fri, 4 Nov 2016 15:25:16 -0500 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; Fri, 4 Nov 2016 15:25:16 -0500 From: "Jim Guichard (jguichar)" To: "sarikaya@ieee.org" , "Joel M. Halpern" Thread-Topic: [sfc] NSH MD-1 description Thread-Index: AQHSNTNdPW364iTbUU++CFSiySTzt6DJmRqA///AXgA= Date: Fri, 4 Nov 2016 20:25:16 +0000 Message-ID: <6EE30793-024B-4A4E-BE9F-CBCAB1950E62@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: text/plain; charset="utf-8" Content-ID: <9577464FA9B501409A43D8377D764A3F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH MD-1 description 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, 04 Nov 2016 20:25:21 -0000 SGkgQmVoY2V0LA0KDQpQbGVhc2Ugc2VlIG15IGVhcmxpZXIgZW1haWwgYW5kIGh0dHBzOi8vdHJh Yy50b29scy5pZXRmLm9yZy93Zy9zZmMvdHJhYy90aWNrZXQvMjIgd2hlcmUgcm91Z2ggY29uc2Vu c3VzIGhhcyBiZWVuIHJlYWNoZWQgdG8gY2hhbmdlIHRoZSA0IGNvbnRleHRzIHRvIGEgc2luZ2xl IDE2LWJ5dGUgZml4ZWQgY29udGV4dCBoZWFkZXIuIFRoaXMgY2hhbmdlIHdpbGwgYmUgcmVmbGVj dGVkIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBOU0ggZG9jdW1lbnQuDQoNCkppbQ0KDQoN Cg0KDQpPbiAxMS80LzE2LCA0OjEzIFBNLCAic2ZjIG9uIGJlaGFsZiBvZiBCZWhjZXQgU2FyaWth eWEiIDxzZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc2FyaWtheWEyMDEyQGdtYWls LmNvbT4gd3JvdGU6DQoNCj5JIHRoaW5rIHRoYXQgZGVmaW5pdGVseSBzb21lIGFjdGlvbiBpcyBu ZWVkZWQgb24gdGhlIGRlZmluaXRpb24gb2YNCj5tZXRhZGF0YSBUeXBlIDENCj4NCj5kcmFmdC1p ZXRmLXNmYy1uc2gtMTANCj4NCj5JIGhhdmUgbmV2ZXIgYmVlbiBhYmxlIHRvIGZpZ3VyZSBvdXQg d2h5DQo+DQo+Zm91ciBDb250ZXh0IEhlYWRlcnMsDQo+ICAgNC1ieXRlIGVhY2gsIE1VU1QgYmUg YWRkZWQgaW1tZWRpYXRlbHkgZm9sbG93aW5nIHRoZSBTZXJ2aWNlIFBhdGggSGVhZGVyLg0KPg0K PldoYXQgaXMgdGhlIHJvbGUgb2YgdGhlIG51bWJlciA0PyBJdCBoYXMgbm90IGJlZW4gZXhwbGFp bmVkIGluIHRoZSBkb2N1bWVudC4NCj4NCj5EaWZmZXJlbnQgdXNlIGNhc2VzIGhhdmUgZGlmZmVy ZW50IHJlcXVpcmVtZW50cyBhbmQgSSBoYXZlIG5vdCBzZWVuIDQNCj5NRCBUeXBlIDEgZGVmaW5l ZCBpbiBhIHNlbnNpYmxlIG1hbm5lciBmb3IgZWFjaCB1c2UgY2FzZSB0aGF0IHdlIGtub3cNCj5z byBmYXIuIFRoZXJlIGlzIGEgcHJvcG9zYWwgZm9yIHRoZSBkYXRhIGNlbnRlciB1c2UgY2FzZSBp bg0KPmRyYWZ0LWd1aWNoYXJkIHdoaWNoIGNvbnRhaW5zIGV4YWN0bHkgNCBkYXRhIHR5cGVzLiBU aGF0IHNlZW1zIHRvIGJlDQo+YWJvdXQgaXQuDQo+DQo+Rm9yIHRoZSBtb2JpbGl0eSB1c2UgdGhl cmUgaXMgYSBwcm9wb3NhbCBidXQgaXQgZGVmaW5lcyAzIGRhdGEgbm90IDQuDQo+DQo+SSBkb24n dCB1bmRlcnN0YW5kIHdoeSB0aGlzIHBvaW50IHdhaXRlZCBzbyBsb25nICh1bnRpbCBSZXYuIDEx KSB0byBnZXQgZml4ZWQ/DQo+DQo+SSB0aGluayBmaXhpbmcgaXQgaXMgbm90IGdvaW5nIHRvIGJl IGVhc3ksIGl0IHNob3VsZCBoYXZlIGJlZW4NCj5hZGRyZXNzZWQgbXVjaCBlYXJsaWVyLg0KPg0K PlJlZ2FyZHMNCj4NCj5CZWhjZXQNCj4NCj4NCj5PbiBXZWQsIE5vdiAyLCAyMDE2IGF0IDEyOjU3 IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4gPHNw ZWFraW5nIGFzIGEgcGFydGljaXBhbnQ+DQo+PiBHaXZlbiB0aGF0IHZhcmlvdXMgZXhpc3Rpbmcg TUQtMSBwcm9wb3NhbHMgYnJlYWsgdXAgdGhlICI0IiBmaWVsZHMgaW4NCj4+IHZhcmlvdXMgd2F5 cywgYW5kIGdpdmVuIHRoYXQgd2UgbWF5IHdhbnQgdG8gYWxsb3cgLCBmb3IgZXhhbXBsZSwgYSBz aW5nbCA2NA0KPj4gYml0IGZpZWxkIGluIHNvbWUgTUQtMSBhbGxvY2F0aW9uLCBpdCBzZWVtcyBj bGVhbmVyIGFuZCBtb3JlIGNvbnNpc3RlbnQgdG8NCj4+IG1lIHRvIGRlc2NyaWJlIHRoZSBNRC0x IGNvbnRlbnQgYXMgYSBibG9jayBvZiAxNiBieXRlcyByYXRoZXIgdGhhbiBhcyA0IDQNCj4+IGJ5 dGUgd29yZHMuDQo+Pg0KPj4gR2l2ZW4gdGhhdCB0aGlzIGlzIHB1cmVseSBkZXNjcmlwdGl2ZSBm b3IgdGhlIE5TSCBkb2N1bWVudCwgSSBkbyBub3Qgc2VlIGENCj4+IGRvd24gc2lkZS4gIFlBTkcg bW9kZWxzIGZvciBtZXRhZGF0YSBhcmUgYSBtb3JlIGNvbXBsZXggcXVlc3Rpb24sIGJ1dCB0aGUN Cj4+IHNpbXBsZSA0eDQgYnl0ZSByZXByZXNlbnRhdGlvbiBpcyBwcm9iYWJseSBub3Qgd2FudCB3 ZSB3YW50IHRoZXJlIGVpdGhlci4NCj4+DQo+PiBZb3VycywNCj4+IEpvZWwNCj4+DQo+PiA8L3Nw ZWFraW5nIGFzIGEgcGFydGljaXBhbnQ+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWls aW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0K From nobody Fri Nov 4 14:11:20 2016 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 013FA1296A2 for ; Fri, 4 Nov 2016 14:11:19 -0700 (PDT) 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 kHHZRqDcEhP8 for ; Fri, 4 Nov 2016 14:11:16 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 7D22C129579 for ; Fri, 4 Nov 2016 14:11:16 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id b14so73455875lfg.2 for ; Fri, 04 Nov 2016 14:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Vb0Ve4Rdncegi8xxhdh9jlJ4WZda5m4k5eZ/igUu3jY=; b=r7iEXuaz4yesyMVU67wlNXcnSIxgiN68tgAvWKAWaqN3Dsq/3nyROwMN97C70haYk3 EYzbCmmyZExoZtW+MdiiQTtAFq4mkTNQPnIxjgSFCmbYnHg1R8ZxyvPiHKjnv6wBjeJv OMofe77083yogvbI28pCezlwc/Z14xH2koPZOsfecYlu8tK1MMBlJH4KqCulKo3gbtis rZHboDh4+jmmaz6Ms4XzbNaH0UdHrlmknfg5y6zTaSQK2IbenyZO6zLeeZsU/1M9VeAV I8ddzmywcZMB6G+mb9USlABJpb0ux46qQgXGbRbcyR+WNrlNtFUNzEpHVth5wrIZyC0f +Yiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=Vb0Ve4Rdncegi8xxhdh9jlJ4WZda5m4k5eZ/igUu3jY=; b=lj2oTbgRYCar19TM/zhTy3O6t+wU+ydwQ840IRbWAZYq9VdGJojj1KB7gQDWriJXxM vGAWVbdWeLx2ZrhiS97LSK7ke9Fwelo0qIOphvwi1E2bRrwhXK1n95U7D39Vh8vSFf4R Kcb5efpT9TlVirfsajsS6W8XFLFs/x9y0aypW3j+cvWVMwLCkseXbV8Mg45058nMZujV e2MLCPzpUMHyJgCbg9XvE3fVfuaibAy4MYkYDNmj3HQHt2ZZ8Hb1ql6J1UAub95aMvfP OmltE2CVlPx2H7UzaO93ryc1RZqmMcrd53ie64eB105quXAHhkpYhB5KIJog1L020oqQ 17UQ== X-Gm-Message-State: ABUngvdq0CCiouhbtTKK8eYIqvalh9hwSlu0Cms84fHOsBWnhRCmujZkngWwgPAWr+ywd+P+1Qcdgehkzs92VA== X-Received: by 10.25.205.17 with SMTP id d17mr11021513lfg.29.1478293874224; Fri, 04 Nov 2016 14:11:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.228.210 with HTTP; Fri, 4 Nov 2016 14:11:13 -0700 (PDT) In-Reply-To: <6EE30793-024B-4A4E-BE9F-CBCAB1950E62@cisco.com> References: <6EE30793-024B-4A4E-BE9F-CBCAB1950E62@cisco.com> From: Behcet Sarikaya Date: Fri, 4 Nov 2016 16:11:13 -0500 Message-ID: To: "Jim Guichard (jguichar)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] NSH MD-1 description 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: Fri, 04 Nov 2016 21:11:19 -0000 Hi Jim, On Fri, Nov 4, 2016 at 3:25 PM, Jim Guichard (jguichar) wrote: > Hi Behcet, > > Please see my earlier email and https://trac.tools.ietf.org/wg/sfc/trac/t= icket/22 where rough consensus has been reached to change the 4 contexts to= a single 16-byte fixed context header. This change will be reflected in th= e next revision of the NSH document. > I am not sure. That might bring the question of why 1? I think that we need a more flexible mechanism. Regards, Behcet > Jim > > > > > On 11/4/16, 4:13 PM, "sfc on behalf of Behcet Sarikaya" wrote: > >>I think that definitely some action is needed on the definition of >>metadata Type 1 >> >>draft-ietf-sfc-nsh-10 >> >>I have never been able to figure out why >> >>four Context Headers, >> 4-byte each, MUST be added immediately following the Service Path Head= er. >> >>What is the role of the number 4? It has not been explained in the docume= nt. >> >>Different use cases have different requirements and I have not seen 4 >>MD Type 1 defined in a sensible manner for each use case that we know >>so far. There is a proposal for the data center use case in >>draft-guichard which contains exactly 4 data types. That seems to be >>about it. >> >>For the mobility use there is a proposal but it defines 3 data not 4. >> >>I don't understand why this point waited so long (until Rev. 11) to get f= ixed? >> >>I think fixing it is not going to be easy, it should have been >>addressed much earlier. >> >>Regards >> >>Behcet >> >> >>On Wed, Nov 2, 2016 at 12:57 PM, Joel M. Halpern wr= ote: >>> >>> Given that various existing MD-1 proposals break up the "4" fields in >>> various ways, and given that we may want to allow , for example, a sing= l 64 >>> bit field in some MD-1 allocation, it seems cleaner and more consistent= to >>> me to describe the MD-1 content as a block of 16 bytes rather than as 4= 4 >>> byte words. >>> >>> Given that this is purely descriptive for the NSH document, I do not se= e a >>> down side. YANG models for metadata are a more complex question, but t= he >>> simple 4x4 byte representation is probably not want we want there eithe= r. >>> >>> 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 Fri Nov 4 14:38:05 2016 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 B11631296C8 for ; Fri, 4 Nov 2016 14:38:04 -0700 (PDT) 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 7Qo54HmSygiV for ; Fri, 4 Nov 2016 14:38:03 -0700 (PDT) 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 E0F5C127058 for ; Fri, 4 Nov 2016 14:38:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C73E124EAAE; Fri, 4 Nov 2016 14:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478295482; bh=WsjSW2SGsspHQUsE3ONsM3Av0mBvrSaBVqHOLNPMJ6Y=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Cb90e17kI5rVzmApWZn/AEEGb0M5Z3quBhPRJ/MzkK/pqLkfHgJ1x9MwIP+NSWAlg oTT3myvuD+qIZ4XPwSfmmX4JPkTF2k85a6HZ6GcXUz/g7KE1gvis/NoUY7x8OvP0jx MLdqaXItFGIVE6mBZOxeFrsaM3K13uuItfYbAb4w= 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 4754E245B8D; Fri, 4 Nov 2016 14:38:02 -0700 (PDT) To: sarikaya@ieee.org, "Jim Guichard (jguichar)" References: <6EE30793-024B-4A4E-BE9F-CBCAB1950E62@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 4 Nov 2016 17:38:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH MD-1 description 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, 04 Nov 2016 21:38:04 -0000 I seem to be missing your point Behcet. Can I ask you to explain? The concern that was raised was that the description of the MD-1 data as being 4x4 bytes was confusing. The proposal, given the way we are using it, was to treat it as a 16 byte block. There seemed to be working group agreement on that, so Jim call the observed rough consensus. You seem to be arguing for some other aspects of the interpretation question, separate from the way we talk about the size of the fields. If you have some other concern, and have new information to raise relative to that concern, I would be happy to hear it. Yours, Joel On 11/4/16 5:11 PM, Behcet Sarikaya wrote: > Hi Jim, > > > On Fri, Nov 4, 2016 at 3:25 PM, Jim Guichard (jguichar) > wrote: >> Hi Behcet, >> >> Please see my earlier email and https://trac.tools.ietf.org/wg/sfc/trac/ticket/22 where rough consensus has been reached to change the 4 contexts to a single 16-byte fixed context header. This change will be reflected in the next revision of the NSH document. >> > > I am not sure. > > That might bring the question of why 1? > > I think that we need a more flexible mechanism. > > Regards, > > Behcet >> Jim >> >> >> >> >> On 11/4/16, 4:13 PM, "sfc on behalf of Behcet Sarikaya" wrote: >> >>> I think that definitely some action is needed on the definition of >>> metadata Type 1 >>> >>> draft-ietf-sfc-nsh-10 >>> >>> I have never been able to figure out why >>> >>> four Context Headers, >>> 4-byte each, MUST be added immediately following the Service Path Header. >>> >>> What is the role of the number 4? It has not been explained in the document. >>> >>> Different use cases have different requirements and I have not seen 4 >>> MD Type 1 defined in a sensible manner for each use case that we know >>> so far. There is a proposal for the data center use case in >>> draft-guichard which contains exactly 4 data types. That seems to be >>> about it. >>> >>> For the mobility use there is a proposal but it defines 3 data not 4. >>> >>> I don't understand why this point waited so long (until Rev. 11) to get fixed? >>> >>> I think fixing it is not going to be easy, it should have been >>> addressed much earlier. >>> >>> Regards >>> >>> Behcet >>> >>> >>> On Wed, Nov 2, 2016 at 12:57 PM, Joel M. Halpern wrote: >>>> >>>> Given that various existing MD-1 proposals break up the "4" fields in >>>> various ways, and given that we may want to allow , for example, a singl 64 >>>> bit field in some MD-1 allocation, it seems cleaner and more consistent to >>>> me to describe the MD-1 content as a block of 16 bytes rather than as 4 4 >>>> byte words. >>>> >>>> Given that this is purely descriptive for the NSH document, I do not see a >>>> down side. YANG models for metadata are a more complex question, but the >>>> simple 4x4 byte representation is probably not want we want there either. >>>> >>>> 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 Sun Nov 6 02:08:18 2016 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 6D0B81293F4 for ; Sun, 6 Nov 2016 02:08:16 -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 P2sq8pFiuyR8 for ; Sun, 6 Nov 2016 02:08:13 -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 1184A12007C for ; Sun, 6 Nov 2016 02:08:12 -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 uA6A8Ais013341; Sun, 6 Nov 2016 10:08:10 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA6A89xx013335 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 6 Nov 2016 10:08:09 GMT From: "Adrian Farrel" To: "'Dave Dolson'" , Date: Sun, 6 Nov 2016 10:08:08 -0000 Message-ID: <016e01d23815$ad464d20$07d2e760$@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: AdI4FZobFK0TNOpZR0WWLl340NDZJg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22682.006 X-TM-AS-Result: No--34.298-10.0-31-10 X-imss-scan-details: No--34.298-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtFq0U6EhO9EE521GZGE81yGPNzEhPDkO0mCsBeCv8CM/Vkx Gkh/RUoEDl3uGv81t/Cla42jBtiJJojBDGNfcKHMJXKk/roE/RCM45JzjPlCaDeMV7S3KMY98lM n1CNhSWtnrAni+XXP+ubOvW0qIvyw8+0KUSz2xPq0sO72q2op4Riue5Gf9pmprY9uF6odMlymnx 4c5gBftYpzPHGRYWxA4jwA/YvjolUx83kMUVUVOo6MisxJraxHAZn/4A9db2Q3Z3efQH+wj60Fw tUhUxjSy/B8I68Ejv/OebXL1YN2wWaJj9FQLhFe1yMJs9mBCcXAWTziWGaDPAlbhF7ZTanLv7DN jdz9BruZNPnc13LGivFPDHhQkgxyCFc8edUb9x6VUcz8XpiS9IEcpMn6x9cZFRv37Hu2zzz4hiR IXPhrIRRo/C+SKo57TWio0gMwaDzSVpsGoXr43khEDfw/93BuJNroBaGZ+LV6unVYJJS8BlYWGY 8tbKb+IfyCpsohwSVzZR2cqbiLPQ7AfikPXgOwmlaAItiONP21k3bRIdXVNLrfxlRjqBJ37aXGV bcCMAhKPYhy9nwUatl0IGAVhPD6AO3lldyYxrfiZjGZi5sMebKI25nOBDi8MpZ2pNziD5UGJDBU F6tQ9M2T/lUGWNYxH5Nt5YQWZdQi1YHCNuUBesqlR6dnL7KeQWEGv3gaUmf9Ez/5IpHqp8dQkfr /xU0bp8Etj0HS05ifppz9wZch4CclYcKm6OqbW7gz/Gbgpl6Xs1TRinYG/tWeXAweUHB1J21KnO KdRSpZXKsi4nksFlHhsBRgEs7FibJZWVbKYlueAiCmPx4NwFkMvWAuahr8ooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 06 Nov 2016 10:08:16 -0000 I'm wondering whether debating the dictionary definition of "decrement" = is going to be profitable (especially as you'll find it hard to discover = this verbized noun in a dictionary). In common usage it appears to mean = "decrease", and meaning of the noun "decrement" appears to imply a = general reduction. However, clearly in computing, when applied to a counter (such as a loop = counter), decrement is meant to mean "reduce by one". Now we *could* go into a discussion about whether the SI is a hop = counter and has as its main purpose being a TTL for the packet. Or we = c*could* argue about whether the SI's primary purpose is as a pointer = into the SFP. I don't believe any of that discussion is helpful. Some people read = "MUST decrement the SI" to mean reduce by one, and some thought it meant = apply a reduction. I don't even think it will help us to count up who = thought what. It is certain, I think, that introducing clarity to the spec is needed. = All we have to agree is what it should say. I want to enable and support your implementation, Dave.=20 It must be allowed for your implementation to automatically decrement SI = by 1. And it must be allowed for your implementation to not have to = support a configuration interface to vary that behavior. Hence the text = I proposed makes it clear that this is the default behavior. However, I cannot see why it is harmful to allow an SF to make a = different reduction in the value of SI. This will not break the SFF = because it provides generic processing based on the SPI/SI of the = received packet, and it doesn't break the SI itself. The only other = moving part is the Classifier and it, too, operates on the packet in = hand and has no expectations of the SI value.=20 If someone can show me how an SF that modifies the SI by other than -1 = would break the system or architecture, I will gladly shut up. BTW. Consider a firewall SF. It receives packets and either filters them = out or passes them on. Suppose that, instead of dropping the packets it = filters out it wants to send them to a different SF that performs = various security analysis tasks. To forward the packets it just needs to = decrement the SI and the packet will continue down the SPF. To pass the = filtered packets to the analysis SF it needs to change the SFP/SI - are = we saying that the firewall SF is not allowed to do this, but a = Classifier (co-resident or not) must be passed instructions (presumably = in metadata) to do this? Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 03 November 2016 17:54 > To: Jim Guichard (jguichar); adrian@olddog.co.uk; sfc@ietf.org > Subject: RE: [sfc] OK. Enough with the looping (spiralling :-) [Was: = decrementing > service function path index] >=20 > I have never understood "increment" or "decrement" used alone to mean > anything other than "by 1". > One writes, "decrement by X" if X is not 1. >=20 > This issue matters to me because Sandvine has a service function that = performs > service index decrementing (by one, of course) without requiring = control-plane > configuration. > To me the functional separation of Classifier and Service Function is = not academic; > it's real, and it is an elegant separation of responsibility. >=20 > Referring also to draft-ietf-sfc-control-plane, the C3 interface to = the SF does not > include forwarding information (with the exception of how to send a = reverse > packet--but there are alternatives). >=20 > So in terms of "seeing it done right", the functional separation and = simplicity is > "right". >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard = (jguichar) > Sent: Thursday, November 03, 2016 12:21 PM > To: adrian@olddog.co.uk; sfc@ietf.org > Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: = decrementing > service function path index] >=20 > Hi Adrian, >=20 > What I intended has no bearing on the discussion and I am simply = pointing out > that the WG has never to my knowledge exhibited confusion on this = point > although I accept that the assumption of decrement by 1 should be = clarified. I > might also point out that numerous implementations are already doing = the > decrement by 1 so I guess the confusion was not widespread. So in all = fairness > why is it unreasonable to ask why a behavioral change is necessary = when the > existing architecture already supports what is being asked for? >=20 > Jim >=20 >=20 > On 11/3/16, 12:04 PM, "sfc on behalf of Adrian Farrel" = behalf of adrian@olddog.co.uk> wrote: >=20 > >Gee shucks, Jim, > > > >Do you think changing "decrement" to "decrement by 1" is not a = behavioral > change just because it is what you intended when (with your chair hat = off) you > reviewed the document? > > > >Or are you one of the people you are asking (with your chair hat on) = to bring > forward new information? > > > >I, too, would like to see the NSH spec ship, but I would prefer to = see it right. > > > >Adrian > > > >PS If both you and Joel simultaneously remove your chair hats, will = we hit an > iceberg? :-) > > > >PPS I find the discussion about what an SF does compared to what an = SF with a > co-resident re-classifier does, to be dancing on the head of a pin = labelled > "Functional Architecture". You are all welcome to implement a = functional > architecture (and bless you for it), but that is not how products are = marked when > they ship. You will not be selling "Firewall with Added Reclassifier". = Furthermore, > the SFF will be entirely unaware of whether reclassification took = place. So (at the > risk of repeating myself), why is "SF MUST decrement by 1" a = requirement in this > spec, and why is my proposed compromise text not acceptable? > > > >> -----Original Message----- > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> Sent: 03 November 2016 14:53 > >> To: Joel M. Halpern; Eric C Rosen; Dave Dolson; Adrian Farrel; = Surendra Kumar > >> (smkumar); sfc@ietf.org > >> Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) = [Was: > decrementing > >> service function path index] > >> > >> [Chair hat off=E2=80=A6] > >> Given that the currently defined architecture allows for the = requested > behavior > >> through reclassification, I personally see no reason for a change = to the way > >> decrement of service index is currently defined, other than making = it explicit > that > >> decrement means =E2=80=9Cby 1=E2=80=9D. > >> > >> [Chair hat on=E2=80=A6] > >> I would note that we already have working group agreement on the = current > NSH > >> specification. Also, the issue of the ease of modification of SFPs = was part of > >> earlier working group discussion. Is there new information that = those > requesting > >> a behavioral change wish to bring forward? > >> > >> Jim > >> > >> > >> > >> On 11/3/16, 9:55 AM, "sfc on behalf of Joel M. Halpern" bounces@ietf.org > >> on behalf of jmh@joelhalpern.com> wrote: > >> > >> >You ask whether using non-consecuitive integers for the SI in the = path > >> >breaks something. > >> >It is not forbidden. You can, after all, reclassify at every hop. = (And > >> >many current solutions do so.) > >> > > >> >However, it is misleading as to the intent and expected usage of = SFC. > >> >While one can manage to make it work with monotonically decreasing = but > >> >non-consecutive SI, it is significantly more complex. > >> > > >> >As far as I can tell, the place where this is an issue for the BGP = SFC > >> >control draft is not in the protocol definition. Rather, it is in = the > >> >examples which all treat non-consecutive as the normal case. This = is > >> >confusing to readers and likely to drive folks towards assumptions = about > >> >SFC behavior that will not work without additional mechanisms. > >> > > >> >Yours, > >> >Joel > >> > > >> >On 11/3/16 9:20 AM, Eric C Rosen wrote: > >> >> On 11/2/2016 4:50 AM, Dave Dolson wrote: > >> >>> For those reasons, I would prefer to see the SF action limited = to > >> >>> decrement-by-one. If you require otherwise, co-locate a = classifier > >> >>> with the SF. > >> >> > >> >> From the perspective of draft-mackie-bess-nsh-bgp-control-plane, = it > >> >> doesn't matter whether the SPI/SI gets modified by the SF or by = a > >> >> co-resident classifier. The only thing that matters is what = SPI/SI > >> >> values the SFF will need to use as input to its forwarding = engine. > >> >> > >> >> A slightly different issue is whether the successive elements of = an SPI > >> >> have to have successive integers as their respective SI's. That = doesn't > >> >> seem to be necessary for the proper functioning of the system, = so we > >> >> didn't want to assume it. By not using successive integers, it = becomes > >> >> easier to insert and/or delete entries. And if the SF knows the = SI > >> >> (call it "x") of the current element in the chain, it doesn't = really > >> >> have to know the SI of the next element in the chain, since the = SFF can > >> >> interpret "x-1" to mean "next after x", and can then modify the = NSH to > >> >> change the SI to the actual SI of the next element in the chain. > >> >> > >> >> Does this create a technical problem of some sort? > >> >> > >> >> > >> >> > >> >> > >> >> > >> > > >> >_______________________________________________ > >> >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 Nov 6 02:56:21 2016 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 2F440129570 for ; Sun, 6 Nov 2016 02:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 CV3mLYU7fv2L for ; Sun, 6 Nov 2016 02:56:18 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA42129553 for ; Sun, 6 Nov 2016 02:56:18 -0800 (PST) Received: from [192.168.1.8] (unknown [49.146.50.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CB26D18013BE; Sun, 6 Nov 2016 11:56:14 +0100 (CET) To: adrian@olddog.co.uk, 'Dave Dolson' , sfc@ietf.org References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> From: Loa Andersson Message-ID: <71fee848-be00-9137-286f-4908125e62a5@pi.nu> Date: Sun, 6 Nov 2016 18:56:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 06 Nov 2016 10:56:20 -0000 Adrian, On 2016-11-06 18:08, Adrian Farrel wrote: > If someone can show me how an SF that modifies the SI by > other than -1 would break the system or architecture, I will > gladly shut up. I can't think of a case where it is harmful to decrement by another value than 1. OTOH hand have shown that it is useful? /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Nov 6 08:16:18 2016 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 1BEF01299A0 for ; Sun, 6 Nov 2016 08:16:18 -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 JBvP5oRzejk1 for ; Sun, 6 Nov 2016 08:16:15 -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 CBCD3129971 for ; Sun, 6 Nov 2016 08:16:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B2579304E76; Sun, 6 Nov 2016 08:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478448975; bh=/i1RaNdrztuXDmXwWQ59IhQ/VB+EaxYngJG+FrYKUA0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=q0w4aaUEnsZfQWYMdrBWOizWjoHqEGQttAswlYwpbTmZ2DeQFzO/uupVW09GEH7cM MUHD1KZIsfLgXotVMC8DHV1LzHsoEL4irSe1UgSXBsApLPJwFSj/SN3cov3Pj7agT5 mvhObj1aBIaWEql5pRixXJlLZWtUNimICKq2Emmc= 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 34B28304E73; Sun, 6 Nov 2016 08:16:15 -0800 (PST) To: adrian@olddog.co.uk, 'Dave Dolson' , sfc@ietf.org References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Sun, 6 Nov 2016 11:17:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 06 Nov 2016 16:16:18 -0000 With regard to your last question, the approach for security functions (which I agree is one of the common kinds of service functions to trigger branching), what we said in WG discussion was that conceptually, the SF adds metadeata indicating that this is a security-violating packet, and that a classifer marks the packet with the correct new SFP. That classifer can be colocated, or it can be adjacent. Separating this means that the needed control information for translating the metadata to the new SFP ID and Index is associated with the classification functionality. And by modeling it that way we allow the range of implementations without requiring control to know which implementation is being done. At least that was what I understand during the discussions (when I was a participant, not WG co-chair.) Yours, Joel On 11/6/16 5:08 AM, Adrian Farrel wrote: ... > BTW. Consider a firewall SF. It receives packets and either filters > them out or passes them on. Suppose that, instead of dropping the > packets it filters out it wants to send them to a different SF that > performs various security analysis tasks. To forward the packets it > just needs to decrement the SI and the packet will continue down the > SPF. To pass the filtered packets to the analysis SF it needs to > change the SFP/SI - are we saying that the firewall SF is not allowed > to do this, but a Classifier (co-resident or not) must be passed > instructions (presumably in metadata) to do this? > > Adrian From nobody Sun Nov 6 13:09:10 2016 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 8C01E129583 for ; Sun, 6 Nov 2016 13:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 tQHxYs-goSTB for ; Sun, 6 Nov 2016 13:09:07 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1810F12957C for ; Sun, 6 Nov 2016 13:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22172; q=dns/txt; s=iport; t=1478466546; x=1479676146; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PtLIsbJraSGDDh7HJQOwWdGLWoRFS42fQuqzUBT1kIU=; b=PnDohISy0kHMD/Ni0LJvP5kPiVHrouFzDD41/6/+AKu13P9m+Ev8lmjo 72H1Y84JEkEdI9F2746pVF/9l4CbMIczgIPaLhs0fxjWLfDz7FhRUJyo5 qVVJely/lmmR9uM664T7ANRtZyGn7x5X6NcQL4dlS/nBeoVVN1XNhtY8D 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQCMmx9Y/5FdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR9YfAeNMZcAlFKCBQMeC4JFgzYCggk/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEDAQEBARdUEAcEAgEIEQEDAQEoBycLFAMGCAIEARIIE4g1CA6ydIs4A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHIsThCMrMYUoBYQIhDyGS4ECihYBhjSDC4Z?= =?us-ascii?q?9gXWEcIM7hXeHL4V7hAUBHjd6G4MWHBiBRXKFQYEwgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,603,1473120000"; d="scan'208";a="168053071" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2016 21:09:05 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA6L95OH026481 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 6 Nov 2016 21:09:05 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; Sun, 6 Nov 2016 15:09:04 -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; Sun, 6 Nov 2016 15:09:05 -0600 From: "Surendra Kumar (smkumar)" To: "mohamed.boucadair@orange.com" , Dave Dolson , Adrian Farrel , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAB8If2AADzdLoAAXSDUAABsuotAAgEDW4A== Date: Sun, 6 Nov 2016 21:09:04 +0000 Message-ID: <7a68ae56c03a4fb5b0e9df5cde622d41@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <15233159ac6a4f3792284537082dec7c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DA9905@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <31e80873bcd44153a4fef95948214f4c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DAC4C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAC4C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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.24.21.127] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 06 Nov 2016 21:09:09 -0000 Hi Med, There is no debate about the need for "SI". is a tuple that repres= ents the SFC forwarding-state. [For simplicity of discussion, let's leave out the classifier SFs.] 1. While SFF and SF are both part of the SFC architecture, the benefits of = SF decrementing the SI as opposed to SFF decrementing is never articulated = other than mandating it. On the other hand a case is laid out in the draft = I mentioned earlier to have only SFF decrement the SI or SF to decrement by= zero. Whether it is SF or SFF stamping the forwarding state into NSH, it has to b= e under CP control. IOW, they have to have the forwarding table laid out by= CP. As was discussed many times in this list, changing the forwarding stat= e on a NSH packet, then becomes a lookup or an implicit decrement= . Once you have a CP controlled SFC forwarding table, you have a fully policy= compliant SPI traversal. And that policy can be anything, as per the use c= ase, while ensuring that the SI is monotonically going down to zero, for ot= her benefits. 2. It is a big assumption to make, to say *all* packets MUST always travers= e *all* SFs in a chain. It is not part of the architecture, unless I missed= that. 3. By having SFs manipulate the forwarding state on SFC packets, SFFs are e= ssentially being co-located with SFs. There are many SFs, which do not need= to deal with forwarding but only servicing. Thanks, Surendra. -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Friday, November 04, 2016 12:49 AM To: Surendra Kumar (smkumar) ; Dave Dolson ; Adrian Farrel ; 'Joel M. Halpern' ; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Surendra,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Envoy=E9=A0:=20 > jeudi 3 novembre 2016 19:26 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Dave=20 > Dolson; Adrian Farrel; 'Joel M. > Halpern'; sfc@ietf.org > Objet=A0: RE: OK. Enough with the looping (spiralling :-) [Was:=20 > decrementing service function path index] >=20 > Hi Med, >=20 > It is relaxing the rigid requirement, requiring decrement by one and=20 > only one. This would be too restrictive a language to put inside NSH. [Med] SI is there to achieve two objectives: location within a chain + loop= detect. If we assume that the base SFC design is that a packet bound to a = given chain has to cross **all** the SF instances that compose that chain, = decrementing the index by one becomes trivial while decrementing by other v= alues is not justified. >=20 > I can imagine implementations wanting to jump over an SF under policy=20 > control, either statically or dynamically, just as one simple example. [Med] We can consider this case from several perspectives, e.g.,:=20 (1) This is deployment-specific. There are other ways to achieve the same r= esult: create a new chain that does not involve that SF, for example. (2) This is implementation-specific. I hear that jumping over an SF can be = achieved relying on some optimization that will preserve the size of the cl= assification table. For example, a signal can be sent from an SF to its SFF= . Doing so requires modifications to both SF and SFF. One can consider that= the hook required in an SFF to honor a request from an SF is designed as a= service function ("Void SF" co-located with an SFF). Under that design, th= e Void SF will proceed in place of the SF to be jumped. No modification is = then required to the processing of SI in such design. > This is not reclassification. Whether the reasons are to prevent=20 > proliferation of SPIs or to provide dynamic control, or something=20 > else, it is use case driven. >=20 > It is increasingly a software defined infrastructure to put it mildly=20 > and I would rather allow this while not affecting the default=20 > behavior. On the same lines, there are already drafts that are carving=20 > the MD-Type1 allocation on the fly - as per control plane - this is no di= fferent. [Med] I don't think we can put these two on the same level. Further, the co= ntrol of the metadata is a clear control plane requirement. As an editor of= the CP requirement draft, I'm still trying to understand if there is somet= hing that needs to be added to that document to capture a NEW requirement t= hat wasn't raised before. Thank you. >=20 > Surendra. > PS: A method to not even modify the 'SI' by SFs is described here: > https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/ >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com=20 > [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, November 03, 2016 12:01 AM > To: Surendra Kumar (smkumar) ; Dave Dolson=20 > ; Adrian Farrel ; 'Joel M. > Halpern' ; sfc@ietf.org > Subject: RE: OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > Hi Surendra, >=20 > It seems to me that we are trying to modifyi the SFC data plane=20 > architecture to accommodate a given control plane solution proposal. >=20 > As an editor of the SFC CP requirements I-D, I don't remember this=20 > "flexibility" requirement was raised. >=20 > Can you please elaborate on why it is useful to have this control=20 > function? >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Surendra Kumar > > (smkumar) > > Envoy=E9=A0: jeudi 3 novembre 2016 00:46 =C0=A0: Dave Dolson; Adrian Fa= rrel;=20 > > 'Joel M. Halpern'; sfc@ietf.org Objet > > : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > At the risk of spiraling (borrowing Adiran), this reasoning begs the=20 > > question - why even have non-classifier SFs touch the SI to start with = ? > > I would argue to leave it alone and treat SPI+SI as a forwarding=20 > > state and opaque to SFs. > > > > Control plane can weave the same SF instance into thousands (well,=20 > > it is a 24bit SPI) of SPIs and that shouldn't be a concern for the=20 > > SF - consume metadata and service traffic. > > > > Allowing for control plane programmed decrement value is very=20 > > reasonable and useful. > > > > Surendra. > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: Wednesday, November 02, 2016 1:51 AM > > To: Adrian Farrel ; Surendra Kumar (smkumar)=20 > > ; 'Joel M. Halpern' ;=20 > > sfc@ietf.org > > Subject: Re: OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > Adrian, > > Perhaps I'm making too fine a point, but I consider that if an SF=20 > > does anything other than decrementing the SI by 1, we've entered the=20 > > realm of reclassification, and it is a Classifier co-located with=20 > > the SF that is overriding the SPI/SI. > > > > If you refer to Figure 8, path selection is not an action done by an SF= . > > > > Once reclassification is added to a deployment, we can have unicorns=20 > > (and also dragons); much more becomes possible, but it also becomes=20 > > much more difficult to reason about. > > > > You can read in the (expired) draft-penno-sfc-packet-03 some ideas=20 > > about packet reversal that depending heavily on rigid SF=20 > > decrement-by-one. I don't know how to begin reasoning about reverse=20 > > forwarding once reclassification is added... > > > > For those reasons, I would prefer to see the SF action limited to=20 > > decrement-by-one. If you require otherwise, co-locate a classifier=20 > > with the SF. > > > > > > -Dave > > > > > > > > Original Message > > From: Adrian Farrel > > Sent: Tuesday, November 1, 2016 9:52 PM > > To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern';=20 > > sfc@ietf.org Reply To: adrian@olddog.co.uk > > Subject: OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > > > Been thinking about this instead of sleeping. > > > > Keep getting caught in rat-holes that say "no, but you could build=20 > > product like this." But they are real rat-holes. What we need is a=20 > > set of rule that work for simple implementations *and* that do not=20 > > preclude more sophisticated implementations. > > > > So... > > > > When a packet arrives at an SFF the SPI/SI indicates the SFP and the=20 > > next hop on that SFP to be executed. > > > > When an SF has finished processing a packet the default behavior is=20 > > to leave the SPI unchanged and to decrement the SI by 1. > > > > However, and SF MAY know to make other changes to a the SPI and SI. > > How that knowledge is installed in the SF is implementation dependent: > > - it may be the result of configuration (for example, normally=20 > > decrement by > > 1 but in event of a specific condition forward to a different > > chain) > > - it may be the result of a policy and visibility of the SFP > > - it may be based on information in the metadata > > - there may be unicorns > > > > There may be a classifier co-resident with the SF or in the path=20 > > from SF back to SFF so that the SPI/SI received by the SFF is not a=20 > > simple decrement of the SI. > > > > There may be a classifier co-resident with the SFF that processes=20 > > the packet before the SFF performs forwarding so that the SPI/SI=20 > > received by the SFF is not a simple decrement of the SI. > > > > The SFF's routing lookup may give it a choice of SFIs or SFFs to=20 > > which to send the packet for the given SPI/SI. How it resolves this=20 > > choice is a local matter (some policy that might be load balancing=20 > > and could be influenced by any manner of things if an implementation=20 > > chooses without prejudice to the interoperability of replaceability of = SFFs). > > The fact of the choice is a function of how the network has been=20 > > built, and how SFIs have been assigned, and how the SFPs have been=20 > > constructed by the controller - it is not a function of the NSH itself. > > > > The SFF's forwarding instructions can be simple (look up SPI/SI and=20 > > send the packet out of interface X encapsulated in tunnel Y) or more=20 > > complex (make some form of choice and manipulate the packet) just as=20 > > in most other modern forwarding paradigms. > > > > An SFF that does not recognise the SPI/SI (i.e., has no forwarding=20 > > state for it) can only (read MUST) drop the packet. > > > > What forwarding state an SFF has is a matter of: > > - implementation > > - control/management plane instructions > > - visibility into the SFP (and other SFPs) > > > > > > I believe this set of rules is consistent with 7665 and also=20 > > supports what the WG wanted to achieve with the NSH draft without=20 > > requiring any limitation on processing. That is, a simple=20 > > implementation as envisaged by the proponents of "MUST decrement by=20 > > one" is able to perform that function and still be conformant and inter= operable. > > Similarly, a simple SFF as suggested in this thread would have no > problems interoperating. > > > > Similarly, this behavior is flexible enough to allow for other uses=20 > > and implementations. It is consistent with > > draft-mackie-bess-nsh-bgp-control- > > plane > > (indeed, that draft doesn't tell the SF what to do with the SPI/SI=20 > > at > > all) and allows a control plane to program an SFF to do more=20 > > sophisticated things. Of course, if the SFF cannot do those things=20 > > then that will be OK since it won't support those control plane > instructions. > > > > Can we put this to bed with the minimal change to > > draft-ietf-sfc-nsh-10 section > > 4 as follows: > > > > OLD > > 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. > > NEW > > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > > service index. By default the SF decrements the SI by 1, but it > > MAY apply other decrements according to configuration and other > > information available to it. If an SFF receives a packet with > > an SPI and SI for which it does not have forwarding state, > > it MUST be drop the packet, and SHOULD log the event subject to > > rate limiting on such logs. > > END > > > > Similarly later in the same bullet... > > OLD > > 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. > > NEW > > 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. By default the SFC Proxy decrements the SI by 1, > > but it MAY apply other decrements according to configuration and > > other information available to it. > > END > > > > Furthermore, in section 3.3 since the term "egress NSH packet" is=20 > > either ambiguous or neglects the possibility of reclassification... > > > > OLD > > 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. > > NEW > > Service Index MUST be decremented by Service Functions or by SFC > > Proxy nodes after performing required services as described in > > Section 4. 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 fo= r > > the resultant SPI. > > END > > > > > > Now perhaps I can sleep :-) > > > > Adrian > > > > > -----Original Message----- > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > Sent: 01 November 2016 23:22 > > > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. > > > Halpern'; sfc@ietf.org > > > Subject: Re: [sfc] decrementing service function path index > > > > > > I agree that the SF should be simple. > > > But don't confuse decrementing the SI with complexity. > > > There is absolutely no configuration required to have the SF=20 > > > decrement the SI > > of > > > every packet. > > > And there is a lot of benefit to keeping the SFF from having rules=20 > > > about > > packet > > > source. > > > > > > As far as I'm concerned, the SF decrements the SI, and it has been=20 > > > described > > this > > > way for a long time. Furthermore, the forwarding is described as a=20 > > > lookup > > table > > > based on SPI/SI. There is no mention of the source in the=20 > > > forwarding > > table. > > > > > > > > > > > > > > > Original Message > > > From: Surendra Kumar (smkumar) > > > Sent: Tuesday, November 1, 2016 7:03 PM > > > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern';=20 > > > sfc@ietf.org > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > > Since the forwarders already exists, they are logical components=20 > > > to support > > and > > > perform NSH based forwarding - forwarding on SFPs, rather than=20 > > > treat them as dumb forwarders. There is benefit to be had,=20 > > > offloads being one of them, on > > top > > > of end of chain forwarding, etc. needed. > > > > > > I would rather have SFs focus on servicing the traffic than be=20 > > > burdened with > > SPI > > > management (whether it is tens or thousands of SPIs) and the=20 > > > forwarding thereof. IOW, consume metadata and service traffic and=20 > > > leave the SFP management to the external forwarders. This not only=20 > > > simplifies the SFs, it > > also > > > reduces the control plane touch point as it concerns to the SPI > > management. > > > > > > And you don't need complex logic to differentiate between traffic=20 > > > received > > from > > > one SFF or a SF, this is what we addressed in the forwarding draft=20 > > > - trivial > > to > > > implement even in hardware. > > > > > > Thanks, > > > Surendra. > > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > > Sent: Tuesday, November 01, 2016 1:27 PM > > > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > > > sfc@ietf.org > > > Subject: Re: [sfc] decrementing service function path index > > > > > > Adrian, > > > Thank you for paraphrasing in a clear manner. > > > > > > Yes, I'm saying that the current (as I understand it) design=20 > > > permits the SFF > > to be a > > > simple forwarder, not needing to discriminate between packets from=20 > > > another SFF or returning from an SF. > > > A single forwarding table handles both cases. > > > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > > > > > So it could tell the difference, but doesn't need to. > > > In some cases, an SFF can be a single-interface device, so "from SFF" > > > or "from > > SF" > > > is not as simple as checking ingress interface, for example. > > > > > > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: Tuesday, November 01, 2016 4:00 PM > > > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > > > Subject: RE: [sfc] decrementing service function path index > > > > > > Just clarifying my understanding of what you said (not necessarily=20 > > > agreeing > > ;-) > > > > > > You are saying that an SFF is simply a forwarder and cannot tell=20 > > > the > > difference > > > between a packet received on a transport tunnel from another SFF=20 > > > and a packet received (back) from an SF that it serves. > > > > > > Or, more precisely, you are saying that the SFF is simply a=20 > > > forwarder that cannot tell the difference between passing a packet=20 > > > to a local SF and passing > > a > > > packet on to a remote SFF. > > > > > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > > > > > Is that your point? > > > > > > Cheers, > > > Adrian > > > > > > -- > > > Support an author and your imagination. > > > Tales from the Wood - Eighteen new fairy tales. > > > More Tales from the Wood - Eighteen MORE new fairy tales. > > > https://www.feedaread.com/profiles/8604/ > > > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > > > Or buy from me direct. > > > > > > > > > > > > > -----Original Message----- > > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > > Sent: 01 November 2016 19:35 > > > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > The SF decrements the index so that the SFF doesn't have to look=20 > > > > at the > > packet > > > > origin in order to determine whether or not to decrement it. > > > > We don't want the SFF to have logic like: > > > > If NSH packet is from one of addresses x, y z > > > > Decrement SI > > > > > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > > > without having > > > to > > > > do consider source address. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian=20 > > > > Farrel > > > > Sent: Tuesday, November 01, 2016 2:48 PM > > > > To: 'Joel M. Halpern'; sfc@ietf.org > > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > > > With regard to the architectural components, the NSH draft=20 > > > > > does not define those. It is using the architectural,=20 > > > > > logical, components and architecture defined by the SFC=20 > > > > > Architecture > > documents. > > > > > > > > I'd like to understand where in 7665 it says that the SF is=20 > > > > responsible for moving the packet on to the next SF in the path, > > rather than the SFF. > > > > > > > > I'd also like to understand why the NSH document (that tells us=20 > > > > how to encapsulate, and what to do at each hop in the path)=20 > > > > needs to divide the responsibility for bits of protocol work=20 > > > > between different logical > > functional > > > > entities. In short, why does the SF decrement the SI, why isn't=20 > > > > this an SFF function? What benefit comes from doing it this way=20 > > > > or did a choice simply > > > have > > > > to be made? > > > > > > > > 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 Sun Nov 6 15:43:46 2016 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 8DDC01294A2 for ; Sun, 6 Nov 2016 15:43:44 -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 cY0QJlFrXpOk for ; Sun, 6 Nov 2016 15:43:43 -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 54528129481 for ; Sun, 6 Nov 2016 15:43:43 -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 uA6Nhf5p014229; Sun, 6 Nov 2016 23:43:41 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA6NhetF014218 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 6 Nov 2016 23:43:40 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , "'Dave Dolson'" , References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> In-Reply-To: Date: Sun, 6 Nov 2016 23:43:39 -0000 Message-ID: <01d401d23887$9a46d740$ced485c0$@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: AQKm13ZRDV265y5H+hscqrb3B+OnpwIrz/eanxIBDkA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22684.003 X-TM-AS-Result: No--12.166-10.0-31-10 X-imss-scan-details: No--12.166-10.0-31-10 X-TMASE-MatchedRID: scwq2vQP8OFq0U6EhO9EE/HkpkyUphL91kqyrcMalqVrMbakJN8OebBX ud9Ra+w0ZHcRfUDRTLBQQ4c9J9HxDmJZXQNDzktSiUPZPmKZOQlgtOTOe8LZv8j0QMA/92m24pW FZ/8lJS4JzeX+ZLlK+yQ5mWjNfjbgG8xA8Y3ASHmaVoAi2I40/aFkxMQpsHd+f7RPWCFK8GL9dt G6aqesHTX66v509y5NamPFF/nRxpP2v8tc+AA4/i4uTw19Klh6fS0Ip2eEHnzWRN8STJpl3PoLR 4+zsDTtH/zyL+gBqiw2QPWItigVnxwaGbPRGgG6OS7dLzJ4xc/zjVN3rbxIEg== Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 06 Nov 2016 23:43:44 -0000 > With regard to your last question, the approach for security functions > (which I agree is one of the common kinds of service functions to > trigger branching), what we said in WG discussion was that = conceptually, > the SF adds metadeata indicating that this is a security-violating > packet, and that a classifer marks the packet with the correct new = SFP. Right, I see that in 4.8 of 7665. What we said in draft-mackie-bess-nsh-bgp-control-plane-01.txt was... An SFI may influence this choice process by passing additional information back along with the packet and NSH. I think this is aligned with "conceptual addition of metadata", so I = believe we are aligned. Is that OK? Adrian > That classifer can be colocated, or it can be adjacent. Separating = this > means that the needed control information for translating the metadata > to the new SFP ID and Index is associated with the classification > functionality. And by modeling it that way we allow the range of > implementations without requiring control to know which implementation > is being done. >=20 > At least that was what I understand during the discussions (when I was = a > participant, not WG co-chair.) >=20 > Yours, > Joel >=20 > On 11/6/16 5:08 AM, Adrian Farrel wrote: > ... > > BTW. Consider a firewall SF. It receives packets and either filters > > them out or passes them on. Suppose that, instead of dropping the > > packets it filters out it wants to send them to a different SF that > > performs various security analysis tasks. To forward the packets it > > just needs to decrement the SI and the packet will continue down the > > SPF. To pass the filtered packets to the analysis SF it needs to > > change the SFP/SI - are we saying that the firewall SF is not = allowed > > to do this, but a Classifier (co-resident or not) must be passed > > instructions (presumably in metadata) to do this? > > > > Adrian From nobody Mon Nov 7 05:27:54 2016 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 4876812950E for ; Mon, 7 Nov 2016 05:27:53 -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, 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 r2YGDxvwUKEe for ; Mon, 7 Nov 2016 05:27:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35D7129454 for ; Mon, 7 Nov 2016 05:27:48 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4A33832442A; Mon, 7 Nov 2016 14:27:46 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1574827C088; Mon, 7 Nov 2016 14:27:46 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 14:27:45 +0100 From: To: "Surendra Kumar (smkumar)" , Dave Dolson , Adrian Farrel , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAB8If2AADzdLoAAXSDUAABsuotAAgEDW4AAjdOrA Date: Mon, 7 Nov 2016 13:27:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DAD609@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <15233159ac6a4f3792284537082dec7c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DA9905@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <31e80873bcd44153a4fef95948214f4c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DAC4C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7a68ae56c03a4fb5b0e9df5cde622d41@XCH-RCD-020.cisco.com> In-Reply-To: <7a68ae56c03a4fb5b0e9df5cde622d41@XCH-RCD-020.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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 13:27:53 -0000 Hi Surendra,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Envoy=E9=A0: dimanche 6 novembre 2016 22:09 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Dave Dolson; Adrian Farrel; 'Joel M. > Halpern'; sfc@ietf.org > Objet=A0: RE: OK. Enough with the looping (spiralling :-) [Was: decrement= ing > service function path index] >=20 > Hi Med, >=20 > There is no debate about the need for "SI". is a tuple that > represents the SFC forwarding-state. >=20 > [For simplicity of discussion, let's leave out the classifier SFs.] > 1. While SFF and SF are both part of the SFC architecture, the benefits o= f > SF decrementing the SI as opposed to SFF decrementing is never articulate= d > other than mandating it. On the other hand a case is laid out in the draf= t > I mentioned earlier to have only SFF decrement the SI or SF to decrement > by zero. >=20 [Med] I tend to agree with you on this particular point. =20 > Whether it is SF or SFF stamping the forwarding state into NSH, it has to > be under CP control. IOW, they have to have the forwarding table laid out > by CP. As was discussed many times in this list, changing the forwarding > state on a NSH packet, then becomes a lookup or an implicit > decrement. > Once you have a CP controlled SFC forwarding table, [Med] We already have a "CP controlled SFC forwarding table". The consensus= of the WG on the forwarding table is as follows (CP draft): o SFP Forwarding Policy Table: this table reflects the SFP-specific traffic forwarding policy enforced by SFF components for every relevant incoming packet that is associated to one of the existing SFCs. The SFP Identifier (SFP-id) is used as a lookup key to determine forwarding action regardless of whether the SFC is fully constrained, partially constrained, or not constrained at all. Additional information such as a flow identifier, Service Index (SI), and/or other characteristics (e.g., the 5-tuple transport coordinates of the original packet) may be used for lookup purposes. The set of information to use for lookup purposes may be instructed by the control plane. And=20 SFFs make traffic forwarding decisions according to the entries maintained in their SFP Forwarding Policy Table. Such table is ^^^^^^^^^^^^ populated by the SFC control plane through the C2 interface. In^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ particular, this interface is used to instruct the SFF about the set ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ of information to use for lookup purposes (e.g., SFP-id, 5-tuple^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ transport coordinates). One or many entries may be installed using one single control message. Installing new entries in the SFP Forwarding Policy Table must be immediate. The status of enforcing such entries must be communicated to the control plane as part of the communication procedure. In particular, specific error codes must be returned to the Control Element in case an error is encountered during the enforcement procedure. you have a fully > policy compliant SPI traversal. And that policy can be anything, as per > the use case, while ensuring that the SI is monotonically going down to > zero, for other benefits. >=20 > 2. It is a big assumption to make, to say *all* packets MUST always > traverse *all* SFs in a chain. It is not part of the architecture, unless > I missed that. [Med] Hmm, isn't you who said the following in (https://tools.ietf.org/html= /draft-kumar-sfc-offloads-03):=20 Service Function Chaining (SFC) enables services to be delivered by selective traffic steering through an ordered set of service functions. Once classified into an SFC, the traffic for a given flow = =20 is steered through all the service functions of the SFC for the life ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ of the traffic flow even though this is often not necessary. >=20 > 3. By having SFs manipulate the forwarding state on SFC packets, SFFs are > essentially being co-located with SFs. There are many SFs, which do not > need to deal with forwarding but only servicing. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Friday, November 04, 2016 12:49 AM > To: Surendra Kumar (smkumar) ; Dave Dolson > ; Adrian Farrel ; 'Joel M. > Halpern' ; sfc@ietf.org > Subject: RE: OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > Hi Surendra, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Envoy=E9=A0: > > jeudi 3 novembre 2016 19:26 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Dave > > Dolson; Adrian Farrel; 'Joel M. > > Halpern'; sfc@ietf.org > > Objet=A0: RE: OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > Hi Med, > > > > It is relaxing the rigid requirement, requiring decrement by one and > > only one. This would be too restrictive a language to put inside NSH. >=20 > [Med] SI is there to achieve two objectives: location within a chain + > loop detect. If we assume that the base SFC design is that a packet bound > to a given chain has to cross **all** the SF instances that compose that > chain, decrementing the index by one becomes trivial while decrementing b= y > other values is not justified. >=20 > > > > I can imagine implementations wanting to jump over an SF under policy > > control, either statically or dynamically, just as one simple example. >=20 > [Med] We can consider this case from several perspectives, e.g.,: >=20 > (1) This is deployment-specific. There are other ways to achieve the same > result: create a new chain that does not involve that SF, for example. >=20 > (2) This is implementation-specific. I hear that jumping over an SF can b= e > achieved relying on some optimization that will preserve the size of the > classification table. For example, a signal can be sent from an SF to its > SFF. Doing so requires modifications to both SF and SFF. One can consider > that the hook required in an SFF to honor a request from an SF is designe= d > as a service function ("Void SF" co-located with an SFF). Under that > design, the Void SF will proceed in place of the SF to be jumped. No > modification is then required to the processing of SI in such design. >=20 >=20 > > This is not reclassification. Whether the reasons are to prevent > > proliferation of SPIs or to provide dynamic control, or something > > else, it is use case driven. > > > > It is increasingly a software defined infrastructure to put it mildly > > and I would rather allow this while not affecting the default > > behavior. On the same lines, there are already drafts that are carving > > the MD-Type1 allocation on the fly - as per control plane - this is no > different. >=20 > [Med] I don't think we can put these two on the same level. Further, the > control of the metadata is a clear control plane requirement. As an edito= r > of the CP requirement draft, I'm still trying to understand if there is > something that needs to be added to that document to capture a NEW > requirement that wasn't raised before. Thank you. >=20 > > > > Surendra. > > PS: A method to not even modify the 'SI' by SFs is described here: > > https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/ > > > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Thursday, November 03, 2016 12:01 AM > > To: Surendra Kumar (smkumar) ; Dave Dolson > > ; Adrian Farrel ; 'Joel M. > > Halpern' ; sfc@ietf.org > > Subject: RE: OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > Hi Surendra, > > > > It seems to me that we are trying to modifyi the SFC data plane > > architecture to accommodate a given control plane solution proposal. > > > > As an editor of the SFC CP requirements I-D, I don't remember this > > "flexibility" requirement was raised. > > > > Can you please elaborate on why it is useful to have this control > > function? > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Surendra Kumar > > > (smkumar) > > > Envoy=E9=A0: jeudi 3 novembre 2016 00:46 =C0=A0: Dave Dolson; Adrian = Farrel; > > > 'Joel M. Halpern'; sfc@ietf.org Objet > > > : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: > > > decrementing service function path index] > > > > > > At the risk of spiraling (borrowing Adiran), this reasoning begs the > > > question - why even have non-classifier SFs touch the SI to start wit= h > ? > > > I would argue to leave it alone and treat SPI+SI as a forwarding > > > state and opaque to SFs. > > > > > > Control plane can weave the same SF instance into thousands (well, > > > it is a 24bit SPI) of SPIs and that shouldn't be a concern for the > > > SF - consume metadata and service traffic. > > > > > > Allowing for control plane programmed decrement value is very > > > reasonable and useful. > > > > > > Surendra. > > > > > > -----Original Message----- > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > Sent: Wednesday, November 02, 2016 1:51 AM > > > To: Adrian Farrel ; Surendra Kumar (smkumar) > > > ; 'Joel M. Halpern' ; > > > sfc@ietf.org > > > Subject: Re: OK. Enough with the looping (spiralling :-) [Was: > > > decrementing service function path index] > > > > > > Adrian, > > > Perhaps I'm making too fine a point, but I consider that if an SF > > > does anything other than decrementing the SI by 1, we've entered the > > > realm of reclassification, and it is a Classifier co-located with > > > the SF that is overriding the SPI/SI. > > > > > > If you refer to Figure 8, path selection is not an action done by an > SF. > > > > > > Once reclassification is added to a deployment, we can have unicorns > > > (and also dragons); much more becomes possible, but it also becomes > > > much more difficult to reason about. > > > > > > You can read in the (expired) draft-penno-sfc-packet-03 some ideas > > > about packet reversal that depending heavily on rigid SF > > > decrement-by-one. I don't know how to begin reasoning about reverse > > > forwarding once reclassification is added... > > > > > > For those reasons, I would prefer to see the SF action limited to > > > decrement-by-one. If you require otherwise, co-locate a classifier > > > with the SF. > > > > > > > > > -Dave > > > > > > > > > > > > Original Message > > > From: Adrian Farrel > > > Sent: Tuesday, November 1, 2016 9:52 PM > > > To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern'; > > > sfc@ietf.org Reply To: adrian@olddog.co.uk > > > Subject: OK. Enough with the looping (spiralling :-) [Was: > > > decrementing service function path index] > > > > > > > > > Been thinking about this instead of sleeping. > > > > > > Keep getting caught in rat-holes that say "no, but you could build > > > product like this." But they are real rat-holes. What we need is a > > > set of rule that work for simple implementations *and* that do not > > > preclude more sophisticated implementations. > > > > > > So... > > > > > > When a packet arrives at an SFF the SPI/SI indicates the SFP and the > > > next hop on that SFP to be executed. > > > > > > When an SF has finished processing a packet the default behavior is > > > to leave the SPI unchanged and to decrement the SI by 1. > > > > > > However, and SF MAY know to make other changes to a the SPI and SI. > > > How that knowledge is installed in the SF is implementation dependent= : > > > - it may be the result of configuration (for example, normally > > > decrement by > > > 1 but in event of a specific condition forward to a different > > > chain) > > > - it may be the result of a policy and visibility of the SFP > > > - it may be based on information in the metadata > > > - there may be unicorns > > > > > > There may be a classifier co-resident with the SF or in the path > > > from SF back to SFF so that the SPI/SI received by the SFF is not a > > > simple decrement of the SI. > > > > > > There may be a classifier co-resident with the SFF that processes > > > the packet before the SFF performs forwarding so that the SPI/SI > > > received by the SFF is not a simple decrement of the SI. > > > > > > The SFF's routing lookup may give it a choice of SFIs or SFFs to > > > which to send the packet for the given SPI/SI. How it resolves this > > > choice is a local matter (some policy that might be load balancing > > > and could be influenced by any manner of things if an implementation > > > chooses without prejudice to the interoperability of replaceability o= f > SFFs). > > > The fact of the choice is a function of how the network has been > > > built, and how SFIs have been assigned, and how the SFPs have been > > > constructed by the controller - it is not a function of the NSH > itself. > > > > > > The SFF's forwarding instructions can be simple (look up SPI/SI and > > > send the packet out of interface X encapsulated in tunnel Y) or more > > > complex (make some form of choice and manipulate the packet) just as > > > in most other modern forwarding paradigms. > > > > > > An SFF that does not recognise the SPI/SI (i.e., has no forwarding > > > state for it) can only (read MUST) drop the packet. > > > > > > What forwarding state an SFF has is a matter of: > > > - implementation > > > - control/management plane instructions > > > - visibility into the SFP (and other SFPs) > > > > > > > > > I believe this set of rules is consistent with 7665 and also > > > supports what the WG wanted to achieve with the NSH draft without > > > requiring any limitation on processing. That is, a simple > > > implementation as envisaged by the proponents of "MUST decrement by > > > one" is able to perform that function and still be conformant and > interoperable. > > > Similarly, a simple SFF as suggested in this thread would have no > > problems interoperating. > > > > > > Similarly, this behavior is flexible enough to allow for other uses > > > and implementations. It is consistent with > > > draft-mackie-bess-nsh-bgp-control- > > > plane > > > (indeed, that draft doesn't tell the SF what to do with the SPI/SI > > > at > > > all) and allows a control plane to program an SFF to do more > > > sophisticated things. Of course, if the SFF cannot do those things > > > then that will be OK since it won't support those control plane > > instructions. > > > > > > Can we put this to bed with the minimal change to > > > draft-ietf-sfc-nsh-10 section > > > 4 as follows: > > > > > > OLD > > > 3. Update NSH: NSH-aware service functions (SF) MUST decrement th= e > > > 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. > > > NEW > > > 3. Update NSH: NSH-aware service functions (SF) MUST decrement th= e > > > service index. By default the SF decrements the SI by 1, but > it > > > MAY apply other decrements according to configuration and othe= r > > > information available to it. If an SFF receives a packet with > > > an SPI and SI for which it does not have forwarding state, > > > it MUST be drop the packet, and SHOULD log the event subject t= o > > > rate limiting on such logs. > > > END > > > > > > Similarly later in the same bullet... > > > OLD > > > 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. > > > NEW > > > 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. By default the SFC Proxy decrements the SI by > 1, > > > but it MAY apply other decrements according to configuration > and > > > other information available to it. > > > END > > > > > > Furthermore, in section 3.3 since the term "egress NSH packet" is > > > either ambiguous or neglects the possibility of reclassification... > > > > > > OLD > > > 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. > > > NEW > > > Service Index MUST be decremented by Service Functions or by SFC > > > Proxy nodes after performing required services as described in > > > Section 4. 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. > > > END > > > > > > > > > Now perhaps I can sleep :-) > > > > > > Adrian > > > > > > > -----Original Message----- > > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > > Sent: 01 November 2016 23:22 > > > > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. > > > > Halpern'; sfc@ietf.org > > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > > I agree that the SF should be simple. > > > > But don't confuse decrementing the SI with complexity. > > > > There is absolutely no configuration required to have the SF > > > > decrement the SI > > > of > > > > every packet. > > > > And there is a lot of benefit to keeping the SFF from having rules > > > > about > > > packet > > > > source. > > > > > > > > As far as I'm concerned, the SF decrements the SI, and it has been > > > > described > > > this > > > > way for a long time. Furthermore, the forwarding is described as a > > > > lookup > > > table > > > > based on SPI/SI. There is no mention of the source in the > > > > forwarding > > > table. > > > > > > > > > > > > > > > > > > > > Original Message > > > > From: Surendra Kumar (smkumar) > > > > Sent: Tuesday, November 1, 2016 7:03 PM > > > > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; > > > > sfc@ietf.org > > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > > > > > Since the forwarders already exists, they are logical components > > > > to support > > > and > > > > perform NSH based forwarding - forwarding on SFPs, rather than > > > > treat them as dumb forwarders. There is benefit to be had, > > > > offloads being one of them, on > > > top > > > > of end of chain forwarding, etc. needed. > > > > > > > > I would rather have SFs focus on servicing the traffic than be > > > > burdened with > > > SPI > > > > management (whether it is tens or thousands of SPIs) and the > > > > forwarding thereof. IOW, consume metadata and service traffic and > > > > leave the SFP management to the external forwarders. This not only > > > > simplifies the SFs, it > > > also > > > > reduces the control plane touch point as it concerns to the SPI > > > management. > > > > > > > > And you don't need complex logic to differentiate between traffic > > > > received > > > from > > > > one SFF or a SF, this is what we addressed in the forwarding draft > > > > - trivial > > > to > > > > implement even in hardware. > > > > > > > > Thanks, > > > > Surendra. > > > > > > > > -----Original Message----- > > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > > > Sent: Tuesday, November 01, 2016 1:27 PM > > > > To: adrian@olddog.co.uk; 'Joel M. Halpern' ; > > > > sfc@ietf.org > > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > > Adrian, > > > > Thank you for paraphrasing in a clear manner. > > > > > > > > Yes, I'm saying that the current (as I understand it) design > > > > permits the SFF > > > to be a > > > > simple forwarder, not needing to discriminate between packets from > > > > another SFF or returning from an SF. > > > > A single forwarding table handles both cases. > > > > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF= 2 > > > > > > > > So it could tell the difference, but doesn't need to. > > > > In some cases, an SFF can be a single-interface device, so "from > SFF" > > > > or "from > > > SF" > > > > is not as simple as checking ingress interface, for example. > > > > > > > > > > > > -----Original Message----- > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > Sent: Tuesday, November 01, 2016 4:00 PM > > > > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > Just clarifying my understanding of what you said (not necessarily > > > > agreeing > > > ;-) > > > > > > > > You are saying that an SFF is simply a forwarder and cannot tell > > > > the > > > difference > > > > between a packet received on a transport tunnel from another SFF > > > > and a packet received (back) from an SF that it serves. > > > > > > > > Or, more precisely, you are saying that the SFF is simply a > > > > forwarder that cannot tell the difference between passing a packet > > > > to a local SF and passing > > > a > > > > packet on to a remote SFF. > > > > > > > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > > > > > > > Is that your point? > > > > > > > > Cheers, > > > > Adrian > > > > > > > > -- > > > > Support an author and your imagination. > > > > Tales from the Wood - Eighteen new fairy tales. > > > > More Tales from the Wood - Eighteen MORE new fairy tales. > > > > https://www.feedaread.com/profiles/8604/ > > > > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > > > > Or buy from me direct. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > > > Sent: 01 November 2016 19:35 > > > > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > > > The SF decrements the index so that the SFF doesn't have to look > > > > > at the > > > packet > > > > > origin in order to determine whether or not to decrement it. > > > > > We don't want the SFF to have logic like: > > > > > If NSH packet is from one of addresses x, y z > > > > > Decrement SI > > > > > > > > > > As currently defined, the SFF simply routes packets by SPI/SI > > > > > without having > > > > to > > > > > do consider source address. > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian > > > > > Farrel > > > > > Sent: Tuesday, November 01, 2016 2:48 PM > > > > > To: 'Joel M. Halpern'; sfc@ietf.org > > > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > > > > > With regard to the architectural components, the NSH draft > > > > > > does not define those. It is using the architectural, > > > > > > logical, components and architecture defined by the SFC > > > > > > Architecture > > > documents. > > > > > > > > > > I'd like to understand where in 7665 it says that the SF is > > > > > responsible for moving the packet on to the next SF in the path, > > > rather than the SFF. > > > > > > > > > > I'd also like to understand why the NSH document (that tells us > > > > > how to encapsulate, and what to do at each hop in the path) > > > > > needs to divide the responsibility for bits of protocol work > > > > > between different logical > > > functional > > > > > entities. In short, why does the SF decrement the SI, why isn't > > > > > this an SFF function? What benefit comes from doing it this way > > > > > or did a choice simply > > > > have > > > > > to be made? > > > > > > > > > > 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 Mon Nov 7 05:37:03 2016 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 1B22112967D for ; Mon, 7 Nov 2016 05:37: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JDyeB5FHYOAA for ; Mon, 7 Nov 2016 05:36:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D0C1296AF for ; Mon, 7 Nov 2016 05:36:56 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B93FC3B4110; Mon, 7 Nov 2016 14:36:54 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8CA4E27C084; Mon, 7 Nov 2016 14:36:54 +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; Mon, 7 Nov 2016 14:36:54 +0100 From: To: "Joel M. Halpern" , "adrian@olddog.co.uk" , 'Dave Dolson' , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI4FZobFK0TNOpZR0WWLl340NDZJgAK0IOAAC6FmoA= Date: Mon, 7 Nov 2016 13:36:54 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DAD62F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> 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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.7.131517 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 13:37:02 -0000 Hi Joel, all, Another way to proceed, is what is documented in the CP draft: =3D=3D SFs may need to output some processing results of packets to the SFC control plane. This information can be used by the SFC control plane to update the SFC classification rules and the SFP Forwarding Policy Table entries. ... o 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. =3D=3D=3D Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > Envoy=E9=A0: dimanche 6 novembre 2016 17:17 > =C0=A0: adrian@olddog.co.uk; 'Dave Dolson'; sfc@ietf.org > Objet=A0: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > With regard to your last question, the approach for security functions > (which I agree is one of the common kinds of service functions to > trigger branching), what we said in WG discussion was that conceptually, > the SF adds metadeata indicating that this is a security-violating > packet, and that a classifer marks the packet with the correct new SFP. > That classifer can be colocated, or it can be adjacent. Separating this > means that the needed control information for translating the metadata > to the new SFP ID and Index is associated with the classification > functionality. And by modeling it that way we allow the range of > implementations without requiring control to know which implementation > is being done. >=20 > At least that was what I understand during the discussions (when I was a > participant, not WG co-chair.) >=20 > Yours, > Joel >=20 > On 11/6/16 5:08 AM, Adrian Farrel wrote: > ... > > BTW. Consider a firewall SF. It receives packets and either filters > > them out or passes them on. Suppose that, instead of dropping the > > packets it filters out it wants to send them to a different SF that > > performs various security analysis tasks. To forward the packets it > > just needs to decrement the SI and the packet will continue down the > > SPF. To pass the filtered packets to the analysis SF it needs to > > change the SFP/SI - are we saying that the firewall SF is not allowed > > to do this, but a Classifier (co-resident or not) must be passed > > instructions (presumably in metadata) to do this? > > > > Adrian >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 7 05:39:57 2016 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 C88431295AF for ; Mon, 7 Nov 2016 05:39:55 -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 MejwJun-W1Ic for ; Mon, 7 Nov 2016 05:39:54 -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 3BA39129494 for ; Mon, 7 Nov 2016 05:39:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2BD0F3C00A4; Mon, 7 Nov 2016 05:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478525994; bh=nHxFPzTAeDT3pnjpKy3/T3j0Hmk/bn3xD+wXtbiUtQY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MQg1b9R0RqR3ZGieJ56CaJCITvQ8fs2OVziTS6QcKsgMT5MIhGjXtaTLm7HHFSFP/ UBubPkFzM7bWXfX1MAvymlpvF/z4Kd7C7c3WOvCqnaUXRoPeamWcCEEK9hsKveHM/H 9BVe7nZATcmolfXOB87MgD8i8pCwo+SPK+3iymlM= 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 7FC783C0092; Mon, 7 Nov 2016 05:39:53 -0800 (PST) To: mohamed.boucadair@orange.com, "adrian@olddog.co.uk" , 'Dave Dolson' , "sfc@ietf.org" References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009DAD62F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <646ab39a-61ac-6f48-9a57-1059441b3512@joelhalpern.com> Date: Mon, 7 Nov 2016 08:41:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAD62F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 13:39:56 -0000 Yes, notifying control about classification of future packets in a flow is an allowed and useful security SF behavior. It is however not sufficient. We also need to allow (and do) local notification from the SF to the classifier using metadata in the packet. Yours, Joel On 11/7/16 8:36 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, all, > > Another way to proceed, is what is documented in the CP draft: > > == > SFs may need to output some processing results of packets to the SFC > control plane. This information can be used by the SFC control plane > to update the SFC classification rules and the SFP Forwarding Policy > Table entries. > > ... > > o 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. > === > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >> Envoy : dimanche 6 novembre 2016 17:17 >> : adrian@olddog.co.uk; 'Dave Dolson'; sfc@ietf.org >> Objet : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: >> decrementing service function path index] >> >> With regard to your last question, the approach for security functions >> (which I agree is one of the common kinds of service functions to >> trigger branching), what we said in WG discussion was that conceptually, >> the SF adds metadeata indicating that this is a security-violating >> packet, and that a classifer marks the packet with the correct new SFP. >> That classifer can be colocated, or it can be adjacent. Separating this >> means that the needed control information for translating the metadata >> to the new SFP ID and Index is associated with the classification >> functionality. And by modeling it that way we allow the range of >> implementations without requiring control to know which implementation >> is being done. >> >> At least that was what I understand during the discussions (when I was a >> participant, not WG co-chair.) >> >> Yours, >> Joel >> >> On 11/6/16 5:08 AM, Adrian Farrel wrote: >> ... >>> BTW. Consider a firewall SF. It receives packets and either filters >>> them out or passes them on. Suppose that, instead of dropping the >>> packets it filters out it wants to send them to a different SF that >>> performs various security analysis tasks. To forward the packets it >>> just needs to decrement the SI and the packet will continue down the >>> SPF. To pass the filtered packets to the analysis SF it needs to >>> change the SFP/SI - are we saying that the firewall SF is not allowed >>> to do this, but a Classifier (co-resident or not) must be passed >>> instructions (presumably in metadata) to do this? >>> >>> Adrian >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 7 06:08:25 2016 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 8D55E1295C0 for ; Mon, 7 Nov 2016 06:08:23 -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, 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 rae9j5vRCSkD for ; Mon, 7 Nov 2016 06:08:22 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF74129407 for ; Mon, 7 Nov 2016 06:08:21 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6CA8D32453C; Mon, 7 Nov 2016 15:08:20 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 402D94C085; Mon, 7 Nov 2016 15:08:20 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 15:08:19 +0100 From: To: "Joel M. Halpern" , "adrian@olddog.co.uk" , 'Dave Dolson' , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AQHSOPxusgU0lS2RSkqRDUSYBISoJaDNjl+g Date: Mon, 7 Nov 2016 14:08:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DAD671@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009DAD62F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <646ab39a-61ac-6f48-9a57-1059441b3512@joelhalpern.com> In-Reply-To: <646ab39a-61ac-6f48-9a57-1059441b3512@joelhalpern.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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 14:08:23 -0000 Joel, Can you please clarify what you meant by "We also need to allow (and do) lo= cal notification from the SF to the classifier using metadata in the packet." I'm not sure to parse that part correctly.=20 Do you mean that a forward classifier will consume metadata that will be in= serted by an SF or that a classifier will instruct an SF by means of some m= etadata to send notifications to the classifier? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: lundi 7 novembre 2016 14:41 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; adrian@olddog.co.uk; 'Dave Dolson'; > sfc@ietf.org > Objet=A0: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > Yes, notifying control about classification of future packets in a flow > is an allowed and useful security SF behavior. It is however not > sufficient. We also need to allow (and do) local notification from the > SF to the classifier using metadata in the packet. >=20 > Yours, > Joel >=20 > On 11/7/16 8:36 AM, mohamed.boucadair@orange.com wrote: > > Hi Joel, all, > > > > Another way to proceed, is what is documented in the CP draft: > > > > =3D=3D > > SFs may need to output some processing results of packets to the SFC > > control plane. This information can be used by the SFC control plan= e > > to update the SFC classification rules and the SFP Forwarding Policy > > Table entries. > > > > ... > > > > o 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. > > =3D=3D=3D > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > >> Envoy=E9 : dimanche 6 novembre 2016 17:17 > >> =C0 : adrian@olddog.co.uk; 'Dave Dolson'; sfc@ietf.org > >> Objet : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: > >> decrementing service function path index] > >> > >> With regard to your last question, the approach for security functions > >> (which I agree is one of the common kinds of service functions to > >> trigger branching), what we said in WG discussion was that > conceptually, > >> the SF adds metadeata indicating that this is a security-violating > >> packet, and that a classifer marks the packet with the correct new SFP= . > >> That classifer can be colocated, or it can be adjacent. Separating > this > >> means that the needed control information for translating the metadata > >> to the new SFP ID and Index is associated with the classification > >> functionality. And by modeling it that way we allow the range of > >> implementations without requiring control to know which implementation > >> is being done. > >> > >> At least that was what I understand during the discussions (when I was > a > >> participant, not WG co-chair.) > >> > >> Yours, > >> Joel > >> > >> On 11/6/16 5:08 AM, Adrian Farrel wrote: > >> ... > >>> BTW. Consider a firewall SF. It receives packets and either filters > >>> them out or passes them on. Suppose that, instead of dropping the > >>> packets it filters out it wants to send them to a different SF that > >>> performs various security analysis tasks. To forward the packets it > >>> just needs to decrement the SI and the packet will continue down the > >>> SPF. To pass the filtered packets to the analysis SF it needs to > >>> change the SFP/SI - are we saying that the firewall SF is not allowed > >>> to do this, but a Classifier (co-resident or not) must be passed > >>> instructions (presumably in metadata) to do this? > >>> > >>> Adrian > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 7 06:21:06 2016 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 1609C1295F5 for ; Mon, 7 Nov 2016 06:21:05 -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 U1Ey4CqStPom for ; Mon, 7 Nov 2016 06:21:03 -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 488261294DA for ; Mon, 7 Nov 2016 06:21:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 366841C0297; Mon, 7 Nov 2016 06:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478528463; bh=Tu1nuA3fmy10SE0tvd2XE7vPIVZCsEgd6x/xR+tAuFs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CrOpFRwdFDn9PA0PkJxnjLqyO5SSOKdATquRVSoiRjgl9O88AusOGRQlH/Oq0YyuS ZnMdreuvEN00qmKLCBnFMPQHWdYJ2fIQ01rgINCwM3EbxoeIcwKlmB6XemvfmrVSsK JYS8MuuN6NTqfPH4+6kEWBZeqHHSnHzREp5aEUgo= 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 862BD3C008A; Mon, 7 Nov 2016 06:21:02 -0800 (PST) To: mohamed.boucadair@orange.com, "adrian@olddog.co.uk" , 'Dave Dolson' , "sfc@ietf.org" References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009DAD62F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <646ab39a-61ac-6f48-9a57-1059441b3512@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933009DAD671@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <3e95f535-8780-8c18-fd97-29302f526673@joelhalpern.com> Date: Mon, 7 Nov 2016 09:22:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAD671@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 14:21:05 -0000 In a common case, the SF determines that the packet it is currently holding needs to be moved to a different chain. Changing the chain is done by a classifier. The conceptual model for this case is that the SF adds information to the metadata, and triggers reclassification. The classifier uses the metadata to determine what chain the packet belongs on. As an implementation, the classifier may be co-located with the SF, and the metadata may not actually appear anywhere. (Conceptually, the classifier chose to remove it, implementation-wise the interface was internal and could do whatever it needed. Another valid implementation is that the classifier is at the SFF, and the metadata is visible on the interface to the SFF / Classifier. Whatever the implementation, this behavior is usually (but not always) used in conjunction with the control notification that the packets of the flow belong on a different flow. Yours, Joel On 11/7/16 9:08 AM, mohamed.boucadair@orange.com wrote: > Joel, > > Can you please clarify what you meant by "We also need to allow (and do) local notification from the > SF to the classifier using metadata in the packet." > > I'm not sure to parse that part correctly. > > Do you mean that a forward classifier will consume metadata that will be inserted by an SF or that a classifier will instruct an SF by means of some metadata to send notifications to the classifier? > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoy : lundi 7 novembre 2016 14:41 >> : BOUCADAIR Mohamed IMT/OLN; adrian@olddog.co.uk; 'Dave Dolson'; >> sfc@ietf.org >> Objet : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: >> decrementing service function path index] >> >> Yes, notifying control about classification of future packets in a flow >> is an allowed and useful security SF behavior. It is however not >> sufficient. We also need to allow (and do) local notification from the >> SF to the classifier using metadata in the packet. >> >> Yours, >> Joel >> >> On 11/7/16 8:36 AM, mohamed.boucadair@orange.com wrote: >>> Hi Joel, all, >>> >>> Another way to proceed, is what is documented in the CP draft: >>> >>> == >>> SFs may need to output some processing results of packets to the SFC >>> control plane. This information can be used by the SFC control plane >>> to update the SFC classification rules and the SFP Forwarding Policy >>> Table entries. >>> >>> ... >>> >>> o 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. >>> === >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>> Envoy : dimanche 6 novembre 2016 17:17 >>>> : adrian@olddog.co.uk; 'Dave Dolson'; sfc@ietf.org >>>> Objet : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: >>>> decrementing service function path index] >>>> >>>> With regard to your last question, the approach for security functions >>>> (which I agree is one of the common kinds of service functions to >>>> trigger branching), what we said in WG discussion was that >> conceptually, >>>> the SF adds metadeata indicating that this is a security-violating >>>> packet, and that a classifer marks the packet with the correct new SFP. >>>> That classifer can be colocated, or it can be adjacent. Separating >> this >>>> means that the needed control information for translating the metadata >>>> to the new SFP ID and Index is associated with the classification >>>> functionality. And by modeling it that way we allow the range of >>>> implementations without requiring control to know which implementation >>>> is being done. >>>> >>>> At least that was what I understand during the discussions (when I was >> a >>>> participant, not WG co-chair.) >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/6/16 5:08 AM, Adrian Farrel wrote: >>>> ... >>>>> BTW. Consider a firewall SF. It receives packets and either filters >>>>> them out or passes them on. Suppose that, instead of dropping the >>>>> packets it filters out it wants to send them to a different SF that >>>>> performs various security analysis tasks. To forward the packets it >>>>> just needs to decrement the SI and the packet will continue down the >>>>> SPF. To pass the filtered packets to the analysis SF it needs to >>>>> change the SFP/SI - are we saying that the firewall SF is not allowed >>>>> to do this, but a Classifier (co-resident or not) must be passed >>>>> instructions (presumably in metadata) to do this? >>>>> >>>>> Adrian >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Nov 7 06:23:26 2016 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 995621296A5 for ; Mon, 7 Nov 2016 06:23: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, 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 4Fwhg-9AcNkr for ; Mon, 7 Nov 2016 06:23:20 -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 C6F931295F5 for ; Mon, 7 Nov 2016 06:23:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B317B3C0092; Mon, 7 Nov 2016 06:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478528600; bh=UKq1GbRdpTuBBDe14wrhtIZ9HHg39KYDcFTYfMNdTLc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bC5tZse+DQtpVpORwBY+eclpS83NgQJsqgp4EvkUJ+fvryRvW7c/uOqEmKoPx2tgP jVLE8k4nXqNxCIVP/XN+JDG3OqnwNC5cAFHIIh71ppsRC7W8dfLDdTZL1EhOMCJliJ cfOkcf8ROJmuwZJcVcK5SJD9i0+a6zujSzQ8jX18= 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 0DBB41C0297; Mon, 7 Nov 2016 06:23:19 -0800 (PST) To: mohamed.boucadair@orange.com, "adrian@olddog.co.uk" , 'Dave Dolson' , "sfc@ietf.org" References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009DAD62F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <646ab39a-61ac-6f48-9a57-1059441b3512@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933009DAD671@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3e95f535-8780-8c18-fd97-29302f526673@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <8c4b3164-b347-55d5-e6f7-6c847eae6e72@joelhalpern.com> Date: Mon, 7 Nov 2016 09:24:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3e95f535-8780-8c18-fd97-29302f526673@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 14:23:25 -0000 (For context, the note I just sent, retained below, is a recapitulation of earlier WG discussions. -- Joel) On 11/7/16 9:22 AM, Joel M. Halpern wrote: > In a common case, the SF determines that the packet it is currently > holding needs to be moved to a different chain. > Changing the chain is done by a classifier. > The conceptual model for this case is that the SF adds information to > the metadata, and triggers reclassification. The classifier uses the > metadata to determine what chain the packet belongs on. > > As an implementation, the classifier may be co-located with the SF, and > the metadata may not actually appear anywhere. (Conceptually, the > classifier chose to remove it, implementation-wise the interface was > internal and could do whatever it needed. > > Another valid implementation is that the classifier is at the SFF, and > the metadata is visible on the interface to the SFF / Classifier. > > Whatever the implementation, this behavior is usually (but not always) > used in conjunction with the control notification that the packets of > the flow belong on a different flow. > > Yours, > Joel > > On 11/7/16 9:08 AM, mohamed.boucadair@orange.com wrote: >> Joel, >> >> Can you please clarify what you meant by "We also need to allow (and >> do) local notification from the >> SF to the classifier using metadata in the packet." >> >> I'm not sure to parse that part correctly. >> >> Do you mean that a forward classifier will consume metadata that will >> be inserted by an SF or that a classifier will instruct an SF by means >> of some metadata to send notifications to the classifier? >> >> Thank you. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Envoy : lundi 7 novembre 2016 14:41 >>> : BOUCADAIR Mohamed IMT/OLN; adrian@olddog.co.uk; 'Dave Dolson'; >>> sfc@ietf.org >>> Objet : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: >>> decrementing service function path index] >>> >>> Yes, notifying control about classification of future packets in a flow >>> is an allowed and useful security SF behavior. It is however not >>> sufficient. We also need to allow (and do) local notification from the >>> SF to the classifier using metadata in the packet. >>> >>> Yours, >>> Joel >>> >>> On 11/7/16 8:36 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Joel, all, >>>> >>>> Another way to proceed, is what is documented in the CP draft: >>>> >>>> == >>>> SFs may need to output some processing results of packets to the SFC >>>> control plane. This information can be used by the SFC control >>>> plane >>>> to update the SFC classification rules and the SFP Forwarding Policy >>>> Table entries. >>>> >>>> ... >>>> >>>> o 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. >>>> === >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>>> Envoy : dimanche 6 novembre 2016 17:17 >>>>> : adrian@olddog.co.uk; 'Dave Dolson'; sfc@ietf.org >>>>> Objet : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: >>>>> decrementing service function path index] >>>>> >>>>> With regard to your last question, the approach for security functions >>>>> (which I agree is one of the common kinds of service functions to >>>>> trigger branching), what we said in WG discussion was that >>> conceptually, >>>>> the SF adds metadeata indicating that this is a security-violating >>>>> packet, and that a classifer marks the packet with the correct new >>>>> SFP. >>>>> That classifer can be colocated, or it can be adjacent. Separating >>> this >>>>> means that the needed control information for translating the metadata >>>>> to the new SFP ID and Index is associated with the classification >>>>> functionality. And by modeling it that way we allow the range of >>>>> implementations without requiring control to know which implementation >>>>> is being done. >>>>> >>>>> At least that was what I understand during the discussions (when I was >>> a >>>>> participant, not WG co-chair.) >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 11/6/16 5:08 AM, Adrian Farrel wrote: >>>>> ... >>>>>> BTW. Consider a firewall SF. It receives packets and either filters >>>>>> them out or passes them on. Suppose that, instead of dropping the >>>>>> packets it filters out it wants to send them to a different SF that >>>>>> performs various security analysis tasks. To forward the packets it >>>>>> just needs to decrement the SI and the packet will continue down the >>>>>> SPF. To pass the filtered packets to the analysis SF it needs to >>>>>> change the SFP/SI - are we saying that the firewall SF is not allowed >>>>>> to do this, but a Classifier (co-resident or not) must be passed >>>>>> instructions (presumably in metadata) to do this? >>>>>> >>>>>> 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 > From nobody Mon Nov 7 07:10:57 2016 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 257F31295B7 for ; Mon, 7 Nov 2016 07:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 JwwKEj9YAdhh for ; Mon, 7 Nov 2016 07:10:54 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E512E1294A3 for ; Mon, 7 Nov 2016 07:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1780; q=dns/txt; s=iport; t=1478531453; x=1479741053; h=from:to:subject:date:message-id:mime-version; bh=T7Pg8ETTMkVbFg/0WNHRDsV7ayG8Rhb1CDtMhIXhFpU=; b=jBFwgVW8Mi3K/ygNRIfEw13TC2npRudCsZvMs2gJTELvgcfumoIfXCqf kyc37QUtncHwMind8F7HwYHKdN9qrePgX1b4oBBzKdx/HHQwqkfT+uSiV 01ph8ob+s67UpC6EzJQgxDcBsp4CmqnldkjFPoOLgoAP1gU8erluvq5T+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgAmmSBY/5hdJa1dHAEBBAEBCgEBg?= =?us-ascii?q?nM7AQEBAQEfWIEDjTGmOYUagggphheBbz8UAQIBAQEBAQEBYh0LhFgQIwRkAQs?= =?us-ascii?q?BPgIEMCcEiGsOoWqPeoFuUos+AQEBAQEBBAEBAQEBAQEBARkFhj6BfYojLYIvB?= =?us-ascii?q?ZRHhWABhjSKD4FuhHCJMo0qhAUBHjd6hSqHb4EMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,606,1473120000"; d="scan'208,217";a="345374079" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2016 15:10:53 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uA7FArE3016607 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 7 Nov 2016 15:10:53 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 09:10:52 -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, 7 Nov 2016 09:10:52 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: IETF97 SFC WG Agenda Thread-Index: AQHSOQkhybCKbvMTTUukho3r4QYiGg== Date: Mon, 7 Nov 2016 15:10:52 +0000 Message-ID: <03D84EFF-19E6-4FE0-B60E-C34892DFE9DB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.78] Content-Type: multipart/alternative; boundary="_000_03D84EFF19E64FE0B60EC34892DFE9DBciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] IETF97 SFC WG Agenda 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, 07 Nov 2016 15:10:55 -0000 --_000_03D84EFF19E64FE0B60EC34892DFE9DBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRzoNCg0KUGxlYXNlIGZpbmQgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBwb3N0ZWQgaGVy ZSAtPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTcvYWdlbmRhL3NmYy8N Cg0KUHJlc2VudGVycywgcGxlYXNlIGZvcndhcmQgeW91ciBzbGlkZXMgdG8gdGhlIFdHIGNoYWly cyBieSBubyBsYXRlciB0aGFuIDExLzExLzIwMTYgNVBNIEVTVC4NCg0KVGhhbmsgeW91IQ0KDQpK aW0gJiBKb2VsDQo= --_000_03D84EFF19E64FE0B60EC34892DFE9DBciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIFdHOjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGxlYXNlIGZpbmQgdGhlIHByZWxpbWluYXJ5 IGFnZW5kYSBwb3N0ZWQgaGVyZSAtJmd0OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbWVldGluZy85Ny9hZ2VuZGEvc2ZjLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9tZWV0aW5nLzk3L2FnZW5kYS9zZmMvPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+UHJlc2VudGVycywgcGxlYXNlIGZvcndhcmQgeW91ciBzbGlkZXMgdG8gdGhlIFdH IGNoYWlycyBieSBubyBsYXRlciB0aGFuIDExLzExLzIwMTYgNVBNIEVTVC48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rIHlvdSE8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkppbSAmYW1wOyBKb2VsPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lH TkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_03D84EFF19E64FE0B60EC34892DFE9DBciscocom_-- From nobody Mon Nov 7 07:36:48 2016 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 879EB1299A3 for ; Mon, 7 Nov 2016 07:36:46 -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 x6QTuDsm4oIb for ; Mon, 7 Nov 2016 07:36:42 -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 F26611294D5 for ; Mon, 7 Nov 2016 07:36:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DC65F3E57E5 for ; Mon, 7 Nov 2016 07:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478533001; bh=d+mgXKTRi646mDOUqnuy0m+GgZqyqokhpUR+8e27m/g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=G78VPCYMzHAF26dy7NoLgHZiDrwQIhLuzfpYPPxtMQBLnz1pvGRytSLlsj+SYkuZU QtR43Ax/pk580tI6arWO1PvBbH5Kszl0xYtBYPntFBwnaI1oto5RTp1sg+ixN0elDT eK9bgf+/NOIQrHWBgBpvwDLfdyNIWqLqAxQ+mpwg= 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 84D0A1C0297 for ; Mon, 7 Nov 2016 07:36:41 -0800 (PST) To: "sfc@ietf.org" References: <03D84EFF-19E6-4FE0-B60E-C34892DFE9DB@cisco.com> From: "Joel M. Halpern" Message-ID: <8964ce09-54f2-1acd-c85c-0e5cb496f4c0@joelhalpern.com> Date: Mon, 7 Nov 2016 10:38:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <03D84EFF-19E6-4FE0-B60E-C34892DFE9DB@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] IETF97 SFC WG Agenda 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, 07 Nov 2016 15:36:46 -0000 In addition to the getting the presentation, we will need a minute taker for the SFC session. I would prefer not to sit there delaying the start of the meeting while I glare at folks until we get a minute taker. Moving forward, Jim and I would like to see about appointing a working group secretary. This person would take minutes at meetings and help us with tracking items between meetings. For example, making sure we notify each person who requests a slot whether they got one. Note that the two requests are not coupled. Offering to take minutes in Seoul does not mean you are also offering to be secretary. And you can offer to take on the role of secretary going forward even if you are missing Seoul, assuming that you expect to make most of the upcoming meetings. Yours, Joel On 11/7/16 10:10 AM, Jim Guichard (jguichar) wrote: > Dear WG: > > Please find the preliminary agenda posted here > -> https://datatracker.ietf.org/meeting/97/agenda/sfc/ > > Presenters, please forward your slides to the WG chairs by no later than > 11/11/2016 5PM EST. > > Thank you! > > Jim & Joel > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Nov 7 08:56:21 2016 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 161E4129953 for ; Mon, 7 Nov 2016 08:56:20 -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 422SHwqWd7ra for ; Mon, 7 Nov 2016 08:56:17 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 5F1991296C8 for ; Mon, 7 Nov 2016 08:56:17 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id t196so119161678lff.3 for ; Mon, 07 Nov 2016 08:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2Jf19xYrRquCHQDyRivTUBez2GHHMiab7J1CMOKZlvE=; b=UnEhDb0sJNI0i25blKD1FO11u7Nn0AhirYYS6mLsYoGekHQFb7LMPT4AI9KGuoXClt IEiPWgWpaTKJBJnBHBDkevqMA9xyjZVG8n2pOiNrb6sCLyBxVif3enst2ilVxTZHGsQF gYiZ7laFWsRsbiBXlbbsA+NyV+9o+S90DuqOjRbUBu2ESYpFJZ8C5cGj9S7Ax1exOr14 SS3jCUCJrFVKLlhYY6G31xb+US1Gnjwz/weg9BgR5qJoMm0VQMVdfmyQwCwo+K2gEpU/ yZezjAbBxrB6wQbwWZutzZeSSXK7X3iSLZ8Q+yyRRHm2vuvyt8NnfA/gdSVBuepZif1y PeGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=2Jf19xYrRquCHQDyRivTUBez2GHHMiab7J1CMOKZlvE=; b=BzInEAP3ue2RiYExVZbBhmNHnBGrEHGfV0ddNruB2JRQngbqF251kUXwKXaLrJ+O9h Q9E4xPxuBP6xsaOqbQQUyiwENnV9Ggtccbgv2Dhe8yH5HKIU7ylG7ElxiEW3SNYgHfhk PhrX0oOcGwVZZSJGMXE47jyBq/Ok33V/Ei6BHyFk+tKivIP0vsyixyijABIBD/VFF9eC gPducaTLJsrmxKoJmqjH+SGg2Y77fShoM2Ntsg8VGNZvPv3WmQQWJ8aMZxyBVUUlwPMI ffAs5PRgY/YjvnFzQRcaZjQFqIoU76JyRcv2W4qCOk14NIy3amAIJrZW7ax9boC61tLB j6fw== X-Gm-Message-State: ABUngvd8rK2LnPaI8UBiyq4eaCqrUWC0pJmWwCbXJ1c4Yv8cQB7W4iH2Kns5s37LOSKwZBOcjIHHv7KhPf81Dg== X-Received: by 10.25.202.73 with SMTP id h9mr261984lfj.8.1478537775303; Mon, 07 Nov 2016 08:56:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.228.210 with HTTP; Mon, 7 Nov 2016 08:56:14 -0800 (PST) In-Reply-To: References: <6EE30793-024B-4A4E-BE9F-CBCAB1950E62@cisco.com> From: Behcet Sarikaya Date: Mon, 7 Nov 2016 10:56:14 -0600 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH MD-1 description 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, 07 Nov 2016 16:56:20 -0000 On Fri, Nov 4, 2016 at 4:38 PM, Joel M. Halpern wrote: > I seem to be missing your point Behcet. Can I ask you to explain? > The concern that was raised was that the description of the MD-1 data as > being 4x4 bytes was confusing. The proposal, given the way we are using it, > was to treat it as a 16 byte block. There seemed to be working group > agreement on that, so Jim call the observed rough consensus. > > You seem to be arguing for some other aspects of the interpretation > question, separate from the way we talk about the size of the fields. If you > have some other concern, and have new information to raise relative to that > concern, I would be happy to hear it. > I suggest defining a delimiter and anything before that is Metadata Type 1 and after it is so called TLVs. In fact common way of defining data in IETF is TLVs. So before and after could be TLVs also. My 2cents. Behcet > Yours, > Joel > > > On 11/4/16 5:11 PM, Behcet Sarikaya wrote: >> >> Hi Jim, >> >> >> On Fri, Nov 4, 2016 at 3:25 PM, Jim Guichard (jguichar) >> wrote: >>> >>> Hi Behcet, >>> >>> Please see my earlier email and >>> https://trac.tools.ietf.org/wg/sfc/trac/ticket/22 where rough consensus has >>> been reached to change the 4 contexts to a single 16-byte fixed context >>> header. This change will be reflected in the next revision of the NSH >>> document. >>> >> >> I am not sure. >> >> That might bring the question of why 1? >> >> I think that we need a more flexible mechanism. >> >> Regards, >> >> Behcet >>> >>> Jim >>> >>> >>> >>> >>> On 11/4/16, 4:13 PM, "sfc on behalf of Behcet Sarikaya" >>> wrote: >>> >>>> I think that definitely some action is needed on the definition of >>>> metadata Type 1 >>>> >>>> draft-ietf-sfc-nsh-10 >>>> >>>> I have never been able to figure out why >>>> >>>> four Context Headers, >>>> 4-byte each, MUST be added immediately following the Service Path >>>> Header. >>>> >>>> What is the role of the number 4? It has not been explained in the >>>> document. >>>> >>>> Different use cases have different requirements and I have not seen 4 >>>> MD Type 1 defined in a sensible manner for each use case that we know >>>> so far. There is a proposal for the data center use case in >>>> draft-guichard which contains exactly 4 data types. That seems to be >>>> about it. >>>> >>>> For the mobility use there is a proposal but it defines 3 data not 4. >>>> >>>> I don't understand why this point waited so long (until Rev. 11) to get >>>> fixed? >>>> >>>> I think fixing it is not going to be easy, it should have been >>>> addressed much earlier. >>>> >>>> Regards >>>> >>>> Behcet >>>> >>>> >>>> On Wed, Nov 2, 2016 at 12:57 PM, Joel M. Halpern >>>> wrote: >>>>> >>>>> >>>>> Given that various existing MD-1 proposals break up the "4" fields in >>>>> various ways, and given that we may want to allow , for example, a >>>>> singl 64 >>>>> bit field in some MD-1 allocation, it seems cleaner and more consistent >>>>> to >>>>> me to describe the MD-1 content as a block of 16 bytes rather than as 4 >>>>> 4 >>>>> byte words. >>>>> >>>>> Given that this is purely descriptive for the NSH document, I do not >>>>> see a >>>>> down side. YANG models for metadata are a more complex question, but >>>>> the >>>>> simple 4x4 byte representation is probably not want we want there >>>>> either. >>>>> >>>>> 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 Nov 7 09:35:11 2016 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 A00901295AA for ; Mon, 7 Nov 2016 09:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 cGoy6PAWQ7Ea for ; Mon, 7 Nov 2016 09:35:04 -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 46CA81294B5 for ; Mon, 7 Nov 2016 09:35:04 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 12:35:02 -0500 From: Dave Dolson To: "Surendra Kumar (smkumar)" , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoA= Date: Mon, 7 Nov 2016 17:35:01 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> In-Reply-To: <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 17:35:09 -0000 Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D255 (already service= d) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=20 Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding.=20 Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI=20 However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with=20 an SPI and SI for which it does not have forwarding state,=20 it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in=20 Section 4. The initial Classifier MUST send the packet to the=20 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. >=20 > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. >=20 >=20 >=20 >=20 > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 >=20 > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. >=20 > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. >=20 > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > Adrian, > Thank you for paraphrasing in a clear manner. >=20 > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >=20 > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" > is not as simple as checking ingress interface, for example. >=20 >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) >=20 > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. >=20 > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. >=20 > And the SFF sees a packet n+1 times for an SFP with n local SFs. >=20 > Is that your point? >=20 > Cheers, > Adrian >=20 > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. >=20 >=20 >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 Nov 7 09:50:58 2016 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 DF0ED12965E for ; Mon, 7 Nov 2016 09:50:56 -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 wSOTT-qP-G_x for ; Mon, 7 Nov 2016 09:50:53 -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 999DB12952E for ; Mon, 7 Nov 2016 09:50:53 -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; Mon, 7 Nov 2016 09:50:52 -0800 From: Ron Parker To: Dave Dolson , "Surendra Kumar (smkumar)" , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AQHSNWI6DouBHonXEkedrmTqIlch1aDOVeCA//99dmA= Date: Mon, 7 Nov 2016 17:50:52 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> 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: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 17:50:57 -0000 Dave, I agree with your conclusion. Decrementing SI at SFF requires the From fi= eld in its forwarding table/logic. That being said, I'm not opposed to making SI decrement an SFF responsibili= ty, with an acknowledgement of the above consequence. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, November 7, 2016 12:35 PM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding.=20 Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with=20 an SPI and SI for which it does not have forwarding state,=20 it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in=20 Section 4. The initial Classifier MUST send the packet to the=20 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. >=20 > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. >=20 >=20 >=20 >=20 > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 >=20 > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. >=20 > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. >=20 > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > Adrian, > Thank you for paraphrasing in a clear manner. >=20 > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >=20 > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" > is not as simple as checking ingress interface, for example. >=20 >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) >=20 > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. >=20 > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. >=20 > And the SFF sees a packet n+1 times for an SFP with n local SFs. >=20 > Is that your point? >=20 > Cheers, > Adrian >=20 > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. >=20 >=20 >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 Mon Nov 7 10:46:50 2016 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 6CC0F129795 for ; Mon, 7 Nov 2016 10:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 PQ-FBjMHXoX9 for ; Mon, 7 Nov 2016 10:46:47 -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 09B89129739 for ; Mon, 7 Nov 2016 10:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16616; q=dns/txt; s=iport; t=1478544407; x=1479754007; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tgC45oPxbfBUj+rLw89CKz66ZqzOmykgNWipd4Pn+Ds=; b=kxyfb5xLqBOlwviwQ/7ilqQK+eGJUM7oaRETWk4ae9G9X6imPB0lLgwf XDRIujta1SyOrFEze3M1+TWmz33bB29iu2RqgvyHdbQSpzduWA0iA+xM0 t9vj5m/sFcz1NVVUkQRfUDchNn+wEqtWNt2bgm3erekXO6qgTXx6WRg+Z 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQDEyyBY/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAR9YfAeNMZcClFKCCB4LhXsCggs/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEDAQEBATc0CwUHBAIBCA4DAQMBAQEeBQQHJwsUAwYIAgQOBYhQCA60J?= =?us-ascii?q?os+AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY+gX2CWIRHgzGCLwWECIREkVsBhjS?= =?us-ascii?q?DC4cEgW6IK4V3hy+Fe4QFAR43ehuDFhwYgUVyAYY9gQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,606,1473120000"; d="scan'208";a="343595617" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2016 18:46:27 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uA7IkRBT018901 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 18:46:27 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 12:46:26 -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, 7 Nov 2016 12:46:26 -0600 From: "Paul Quinn (paulq)" To: Dave Dolson Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AQHSNWJAoVQbTjmmW0yt2DW0zX0VZ6DONFmAgAAT84A= Date: Mon, 7 Nov 2016 18:46:26 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> 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.131.118.77] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D472E01CB1C6C4187F16D2FF8394A41@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 18:46:49 -0000 Dave, In general, this whole scheme of "SFF decrement" is naive: it adds complexi= ty and changes the semantics of service completion. As you point out, decr= ementing on the SFF requires that the SFF know about the source "type" of p= acket: did it come from an SF, or an SFF. In effect, the SFF has some form= state that it tracks. Sure you can that state around, but then you've don= e nothing new. Perhaps more importantly, SI _means_ something. It means that the service = has completed it's task. This has a slew of benefits, ranging from simple = visibility, to trace, to security, particularly when/if crypto is applied. The current model, ensures both a simple SFF, and a consistent representati= on of service "done", and is implemented. Paul > On Nov 7, 2016, at 12:35 PM, Dave Dolson wrote: >=20 > Surendra, > When you would have the Service Function not modify the Service Index, ca= n you explain how the SFF is configured to discriminate between the two cas= es in this example? > 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requir= es forwarding to SF1) > 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D255 (already servi= ced) >=20 > Is it fair to say that there is a source-routing input to the SFF decisio= n, adding an new "From" column to the table of https://tools.ietf.org/html/= draft-ietf-sfc-nsh-10#section-7.1 ? >=20 > +-------------------------------------------------------------------+ > | FROM | SPI | SI | Next hop(s) | Transport | > +-------------------------------------------------------------------+ > | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | > +-------------------------------------------------------------------+ > | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | > +-------------------------------------------------------------------+ > ... > +-------------------------------------------------------------------+ >=20 >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=20 > Sent: Wednesday, November 02, 2016 7:38 PM > To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementi= ng service function path index] >=20 > Adrian, >=20 > This is a very good compromise. Completely agree on "Not preclude sophist= icated implementations" and IMO it is crucial to go beyond legacy forwardin= g methods and allow for, not only flexible implementations as you note, but= also for use-case evolution/innovation. >=20 > While I agree with the default behavior of SF decrementing by 1, in addit= ion to allowing for it to be decremented by a configured value, I would lik= e that to be extended to explicitly include a decrement value of zero (no d= ecrement). So, I support your modified verbiage below to allow for a decrem= ent value of *ZERO*. >=20 > This allows for control-plane/configuration dictated behavior and is flex= ible enough to support different methods of forwarding.=20 >=20 > Surendra. >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Tuesday, November 01, 2016 6:52 PM > To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org > Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing s= ervice function path index] >=20 > Been thinking about this instead of sleeping. >=20 > Keep getting caught in rat-holes that say "no, but you could build produc= t like this." But they are real rat-holes. What we need is a set of rule th= at work for simple implementations *and* that do not preclude more sophisti= cated implementations. >=20 > So... >=20 > When a packet arrives at an SFF the SPI/SI indicates the SFP and the next= hop on that SFP to be executed. >=20 > When an SF has finished processing a packet the default behavior is to le= ave the SPI unchanged and to decrement the SI by 1. > SK> Firstly, why even have SI=20 >=20 > However, and SF MAY know to make other changes to a the SPI and SI. How t= hat knowledge is installed in the SF is implementation dependent: > - it may be the result of configuration (for example, normally decrement = by > 1 but in event of a specific condition forward to a different chain) > - it may be the result of a policy and visibility of the SFP > - it may be based on information in the metadata > - there may be unicorns >=20 > There may be a classifier co-resident with the SF or in the path from SF = back to SFF so that the SPI/SI received by the SFF is not a simple decremen= t of the SI. > SK> Yes, absolutely. If SFs have co-located classifiers, they can restart= a chain or adjust the SI, all based on policy dictated by a higher level e= ntity. >=20 > There may be a classifier co-resident with the SFF that processes the pac= ket before the SFF performs forwarding so that the SPI/SI received by the S= FF is not a simple decrement of the SI. >=20 > The SFF's routing lookup may give it a choice of SFIs or SFFs to which to= send the packet for the given SPI/SI. How it resolves this choice is a loc= al matter (some policy that might be load balancing and could be influenced= by any manner of things if an implementation chooses without prejudice to = the interoperability of replaceability of SFFs). The fact of the choice is = a function of how the network has been built, and how SFIs have been assign= ed, and how the SFPs have been constructed by the controller - it is not a = function of the NSH itself. >=20 > The SFF's forwarding instructions can be simple (look up SPI/SI and send = the packet out of interface X encapsulated in tunnel Y) or more complex (ma= ke some form of choice and manipulate the packet) just as in most other mod= ern forwarding paradigms. >=20 > An SFF that does not recognise the SPI/SI (i.e., has no forwarding state = for it) can only (read MUST) drop the packet. >=20 > What forwarding state an SFF has is a matter of: > - implementation > - control/management plane instructions > - visibility into the SFP (and other SFPs) >=20 >=20 > I believe this set of rules is consistent with 7665 and also supports wha= t the WG wanted to achieve with the NSH draft without requiring any limitat= ion on processing. That is, a simple implementation as envisaged by the pro= ponents of "MUST decrement by one" is able to perform that function and sti= ll be conformant and interoperable. Similarly, a simple SFF as suggested in= this thread would have no problems interoperating. >=20 > Similarly, this behavior is flexible enough to allow for other uses and i= mplementations. It is consistent with draft-mackie-bess-nsh-bgp-control-pla= ne > (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all= ) and allows a control plane to program an SFF to do more sophisticated thi= ngs. Of course, if the SFF cannot do those things then that will be OK sinc= e it won't support those control plane instructions. >=20 > Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 s= ection > 4 as follows: >=20 > OLD > 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. > NEW > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > service index. By default the SF decrements the SI by 1, but it > MAY apply other decrements according to configuration and other > information available to it. If an SFF receives a packet with=20 > an SPI and SI for which it does not have forwarding state,=20 > it MUST be drop the packet, and SHOULD log the event subject to > rate limiting on such logs. > END >=20 > Similarly later in the same bullet... > OLD > 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. > NEW > 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. By default the SFC Proxy decrements the SI by 1, > but it MAY apply other decrements according to configuration and > other information available to it. > END >=20 > Furthermore, in section 3.3 since the term "egress NSH packet" is either = ambiguous or neglects the possibility of reclassification... >=20 > OLD > 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. > NEW > Service Index MUST be decremented by Service Functions or by SFC > Proxy nodes after performing required services as described in=20 > Section 4. The initial Classifier MUST send the packet to the=20 > 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. > END >=20 >=20 > Now perhaps I can sleep :-) >=20 > Adrian >=20 >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: 01 November 2016 23:22 >> To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 >> sfc@ietf.org >> Subject: Re: [sfc] decrementing service function path index >>=20 >> I agree that the SF should be simple. >> But don't confuse decrementing the SI with complexity. >> There is absolutely no configuration required to have the SF decrement=20 >> the SI > of >> every packet. >> And there is a lot of benefit to keeping the SFF from having rules=20 >> about > packet >> source. >>=20 >> As far as I'm concerned, the SF decrements the SI, and it has been=20 >> described > this >> way for a long time. Furthermore, the forwarding is described as a=20 >> lookup > table >> based on SPI/SI. There is no mention of the source in the forwarding tab= le. >>=20 >>=20 >>=20 >>=20 >> Original Message >> From: Surendra Kumar (smkumar) >> Sent: Tuesday, November 1, 2016 7:03 PM >> To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org >> Subject: RE: [sfc] decrementing service function path index >>=20 >>=20 >> Since the forwarders already exists, they are logical components to=20 >> support > and >> perform NSH based forwarding - forwarding on SFPs, rather than treat=20 >> them as dumb forwarders. There is benefit to be had, offloads being=20 >> one of them, on > top >> of end of chain forwarding, etc. needed. >>=20 >> I would rather have SFs focus on servicing the traffic than be=20 >> burdened with > SPI >> management (whether it is tens or thousands of SPIs) and the=20 >> forwarding thereof. IOW, consume metadata and service traffic and=20 >> leave the SFP management to the external forwarders. This not only=20 >> simplifies the SFs, it > also >> reduces the control plane touch point as it concerns to the SPI manageme= nt. >>=20 >> And you don't need complex logic to differentiate between traffic=20 >> received > from >> one SFF or a SF, this is what we addressed in the forwarding draft -=20 >> trivial > to >> implement even in hardware. >>=20 >> Thanks, >> Surendra. >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >> Sent: Tuesday, November 01, 2016 1:27 PM >> To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 >> sfc@ietf.org >> Subject: Re: [sfc] decrementing service function path index >>=20 >> Adrian, >> Thank you for paraphrasing in a clear manner. >>=20 >> Yes, I'm saying that the current (as I understand it) design permits=20 >> the SFF > to be a >> simple forwarder, not needing to discriminate between packets from=20 >> another SFF or returning from an SF. >> A single forwarding table handles both cases. >> E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >>=20 >> So it could tell the difference, but doesn't need to. >> In some cases, an SFF can be a single-interface device, so "from SFF"=20 >> or "from > SF" >> is not as simple as checking ingress interface, for example. >>=20 >>=20 >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Tuesday, November 01, 2016 4:00 PM >> To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org >> Subject: RE: [sfc] decrementing service function path index >>=20 >> Just clarifying my understanding of what you said (not necessarily=20 >> agreeing > ;-) >>=20 >> You are saying that an SFF is simply a forwarder and cannot tell the > difference >> between a packet received on a transport tunnel from another SFF and a=20 >> packet received (back) from an SF that it serves. >>=20 >> Or, more precisely, you are saying that the SFF is simply a forwarder=20 >> that cannot tell the difference between passing a packet to a local SF=20 >> and passing > a >> packet on to a remote SFF. >>=20 >> And the SFF sees a packet n+1 times for an SFP with n local SFs. >>=20 >> Is that your point? >>=20 >> Cheers, >> Adrian >>=20 >> -- >> Support an author and your imagination. >> Tales from the Wood - Eighteen new fairy tales. >> More Tales from the Wood - Eighteen MORE new fairy tales. >> https://www.feedaread.com/profiles/8604/ >> http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 >> Or buy from me direct. >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Dave Dolson [mailto:ddolson@sandvine.com] >>> Sent: 01 November 2016 19:35 >>> To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org >>> Subject: RE: [sfc] decrementing service function path index >>>=20 >>> The SF decrements the index so that the SFF doesn't have to look at=20 >>> the > packet >>> origin in order to determine whether or not to decrement it. >>> We don't want the SFF to have logic like: >>> If NSH packet is from one of addresses x, y z >>> Decrement SI >>>=20 >>> As currently defined, the SFF simply routes packets by SPI/SI=20 >>> without having >> to >>> do consider source address. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel >>> Sent: Tuesday, November 01, 2016 2:48 PM >>> To: 'Joel M. Halpern'; sfc@ietf.org >>> Subject: Re: [sfc] decrementing service function path index >>>=20 >>>> With regard to the architectural components, the NSH draft does=20 >>>> not define those. It is using the architectural, logical,=20 >>>> components and architecture defined by the SFC Architecture documents. >>>=20 >>> I'd like to understand where in 7665 it says that the SF is=20 >>> responsible for moving the packet on to the next SF in the path, rather= than the SFF. >>>=20 >>> I'd also like to understand why the NSH document (that tells us how=20 >>> to encapsulate, and what to do at each hop in the path) needs to=20 >>> divide the responsibility for bits of protocol work between=20 >>> different logical > functional >>> entities. In short, why does the SF decrement the SI, why isn't this=20 >>> an SFF function? What benefit comes from doing it this way or did a=20 >>> choice simply >> have >>> to be made? >>>=20 >>> Thanks, >>> Adrian >>>=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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 7 13:04:25 2016 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 4DA2012956F for ; Mon, 7 Nov 2016 13:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 5lGhG0OIrnyL for ; Mon, 7 Nov 2016 13:04: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 39EE512946A for ; Mon, 7 Nov 2016 13:04:21 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 16:04:19 -0500 From: Dave Dolson To: "Paul Quinn (paulq)" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAADW+xAAAGAYkw Date: Mon, 7 Nov 2016 21:04:19 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 21:04:24 -0000 Paul, Then I think we are in agreement. -Dave -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Monday, November 07, 2016 1:46 PM To: Dave Dolson Cc: sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, In general, this whole scheme of "SFF decrement" is naive: it adds complexi= ty and changes the semantics of service completion. As you point out, decr= ementing on the SFF requires that the SFF know about the source "type" of p= acket: did it come from an SF, or an SFF. In effect, the SFF has some form= state that it tracks. Sure you can that state around, but then you've don= e nothing new. Perhaps more importantly, SI _means_ something. It means that the service = has completed it's task. This has a slew of benefits, ranging from simple = visibility, to trace, to security, particularly when/if crypto is applied. The current model, ensures both a simple SFF, and a consistent representati= on of service "done", and is implemented. Paul > On Nov 7, 2016, at 12:35 PM, Dave Dolson wrote: >=20 > Surendra, > When you would have the Service Function not modify the Service Index, ca= n you explain how the SFF is configured to discriminate between the two cas= es in this example? > 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requir= es forwarding to SF1) > 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D255 (already servi= ced) >=20 > Is it fair to say that there is a source-routing input to the SFF decisio= n, adding an new "From" column to the table of https://tools.ietf.org/html/= draft-ietf-sfc-nsh-10#section-7.1 ? >=20 > +-------------------------------------------------------------------+ > | FROM | SPI | SI | Next hop(s) | Transport | > +-------------------------------------------------------------------+ > | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | > +-------------------------------------------------------------------+ > | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | > +-------------------------------------------------------------------+ > ... > +-------------------------------------------------------------------+ >=20 >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=20 > Sent: Wednesday, November 02, 2016 7:38 PM > To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementi= ng service function path index] >=20 > Adrian, >=20 > This is a very good compromise. Completely agree on "Not preclude sophist= icated implementations" and IMO it is crucial to go beyond legacy forwardin= g methods and allow for, not only flexible implementations as you note, but= also for use-case evolution/innovation. >=20 > While I agree with the default behavior of SF decrementing by 1, in addit= ion to allowing for it to be decremented by a configured value, I would lik= e that to be extended to explicitly include a decrement value of zero (no d= ecrement). So, I support your modified verbiage below to allow for a decrem= ent value of *ZERO*. >=20 > This allows for control-plane/configuration dictated behavior and is flex= ible enough to support different methods of forwarding.=20 >=20 > Surendra. >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Tuesday, November 01, 2016 6:52 PM > To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org > Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing s= ervice function path index] >=20 > Been thinking about this instead of sleeping. >=20 > Keep getting caught in rat-holes that say "no, but you could build produc= t like this." But they are real rat-holes. What we need is a set of rule th= at work for simple implementations *and* that do not preclude more sophisti= cated implementations. >=20 > So... >=20 > When a packet arrives at an SFF the SPI/SI indicates the SFP and the next= hop on that SFP to be executed. >=20 > When an SF has finished processing a packet the default behavior is to le= ave the SPI unchanged and to decrement the SI by 1. > SK> Firstly, why even have SI=20 >=20 > However, and SF MAY know to make other changes to a the SPI and SI. How t= hat knowledge is installed in the SF is implementation dependent: > - it may be the result of configuration (for example, normally decrement = by > 1 but in event of a specific condition forward to a different chain) > - it may be the result of a policy and visibility of the SFP > - it may be based on information in the metadata > - there may be unicorns >=20 > There may be a classifier co-resident with the SF or in the path from SF = back to SFF so that the SPI/SI received by the SFF is not a simple decremen= t of the SI. > SK> Yes, absolutely. If SFs have co-located classifiers, they can restart= a chain or adjust the SI, all based on policy dictated by a higher level e= ntity. >=20 > There may be a classifier co-resident with the SFF that processes the pac= ket before the SFF performs forwarding so that the SPI/SI received by the S= FF is not a simple decrement of the SI. >=20 > The SFF's routing lookup may give it a choice of SFIs or SFFs to which to= send the packet for the given SPI/SI. How it resolves this choice is a loc= al matter (some policy that might be load balancing and could be influenced= by any manner of things if an implementation chooses without prejudice to = the interoperability of replaceability of SFFs). The fact of the choice is = a function of how the network has been built, and how SFIs have been assign= ed, and how the SFPs have been constructed by the controller - it is not a = function of the NSH itself. >=20 > The SFF's forwarding instructions can be simple (look up SPI/SI and send = the packet out of interface X encapsulated in tunnel Y) or more complex (ma= ke some form of choice and manipulate the packet) just as in most other mod= ern forwarding paradigms. >=20 > An SFF that does not recognise the SPI/SI (i.e., has no forwarding state = for it) can only (read MUST) drop the packet. >=20 > What forwarding state an SFF has is a matter of: > - implementation > - control/management plane instructions > - visibility into the SFP (and other SFPs) >=20 >=20 > I believe this set of rules is consistent with 7665 and also supports wha= t the WG wanted to achieve with the NSH draft without requiring any limitat= ion on processing. That is, a simple implementation as envisaged by the pro= ponents of "MUST decrement by one" is able to perform that function and sti= ll be conformant and interoperable. Similarly, a simple SFF as suggested in= this thread would have no problems interoperating. >=20 > Similarly, this behavior is flexible enough to allow for other uses and i= mplementations. It is consistent with draft-mackie-bess-nsh-bgp-control-pla= ne > (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all= ) and allows a control plane to program an SFF to do more sophisticated thi= ngs. Of course, if the SFF cannot do those things then that will be OK sinc= e it won't support those control plane instructions. >=20 > Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 s= ection > 4 as follows: >=20 > OLD > 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. > NEW > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > service index. By default the SF decrements the SI by 1, but it > MAY apply other decrements according to configuration and other > information available to it. If an SFF receives a packet with=20 > an SPI and SI for which it does not have forwarding state,=20 > it MUST be drop the packet, and SHOULD log the event subject to > rate limiting on such logs. > END >=20 > Similarly later in the same bullet... > OLD > 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. > NEW > 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. By default the SFC Proxy decrements the SI by 1, > but it MAY apply other decrements according to configuration and > other information available to it. > END >=20 > Furthermore, in section 3.3 since the term "egress NSH packet" is either = ambiguous or neglects the possibility of reclassification... >=20 > OLD > 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. > NEW > Service Index MUST be decremented by Service Functions or by SFC > Proxy nodes after performing required services as described in=20 > Section 4. The initial Classifier MUST send the packet to the=20 > 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. > END >=20 >=20 > Now perhaps I can sleep :-) >=20 > Adrian >=20 >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: 01 November 2016 23:22 >> To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 >> sfc@ietf.org >> Subject: Re: [sfc] decrementing service function path index >>=20 >> I agree that the SF should be simple. >> But don't confuse decrementing the SI with complexity. >> There is absolutely no configuration required to have the SF decrement=20 >> the SI > of >> every packet. >> And there is a lot of benefit to keeping the SFF from having rules=20 >> about > packet >> source. >>=20 >> As far as I'm concerned, the SF decrements the SI, and it has been=20 >> described > this >> way for a long time. Furthermore, the forwarding is described as a=20 >> lookup > table >> based on SPI/SI. There is no mention of the source in the forwarding tab= le. >>=20 >>=20 >>=20 >>=20 >> Original Message >> From: Surendra Kumar (smkumar) >> Sent: Tuesday, November 1, 2016 7:03 PM >> To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org >> Subject: RE: [sfc] decrementing service function path index >>=20 >>=20 >> Since the forwarders already exists, they are logical components to=20 >> support > and >> perform NSH based forwarding - forwarding on SFPs, rather than treat=20 >> them as dumb forwarders. There is benefit to be had, offloads being=20 >> one of them, on > top >> of end of chain forwarding, etc. needed. >>=20 >> I would rather have SFs focus on servicing the traffic than be=20 >> burdened with > SPI >> management (whether it is tens or thousands of SPIs) and the=20 >> forwarding thereof. IOW, consume metadata and service traffic and=20 >> leave the SFP management to the external forwarders. This not only=20 >> simplifies the SFs, it > also >> reduces the control plane touch point as it concerns to the SPI manageme= nt. >>=20 >> And you don't need complex logic to differentiate between traffic=20 >> received > from >> one SFF or a SF, this is what we addressed in the forwarding draft -=20 >> trivial > to >> implement even in hardware. >>=20 >> Thanks, >> Surendra. >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >> Sent: Tuesday, November 01, 2016 1:27 PM >> To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 >> sfc@ietf.org >> Subject: Re: [sfc] decrementing service function path index >>=20 >> Adrian, >> Thank you for paraphrasing in a clear manner. >>=20 >> Yes, I'm saying that the current (as I understand it) design permits=20 >> the SFF > to be a >> simple forwarder, not needing to discriminate between packets from=20 >> another SFF or returning from an SF. >> A single forwarding table handles both cases. >> E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >>=20 >> So it could tell the difference, but doesn't need to. >> In some cases, an SFF can be a single-interface device, so "from SFF"=20 >> or "from > SF" >> is not as simple as checking ingress interface, for example. >>=20 >>=20 >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Tuesday, November 01, 2016 4:00 PM >> To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org >> Subject: RE: [sfc] decrementing service function path index >>=20 >> Just clarifying my understanding of what you said (not necessarily=20 >> agreeing > ;-) >>=20 >> You are saying that an SFF is simply a forwarder and cannot tell the > difference >> between a packet received on a transport tunnel from another SFF and a=20 >> packet received (back) from an SF that it serves. >>=20 >> Or, more precisely, you are saying that the SFF is simply a forwarder=20 >> that cannot tell the difference between passing a packet to a local SF=20 >> and passing > a >> packet on to a remote SFF. >>=20 >> And the SFF sees a packet n+1 times for an SFP with n local SFs. >>=20 >> Is that your point? >>=20 >> Cheers, >> Adrian >>=20 >> -- >> Support an author and your imagination. >> Tales from the Wood - Eighteen new fairy tales. >> More Tales from the Wood - Eighteen MORE new fairy tales. >> https://www.feedaread.com/profiles/8604/ >> http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 >> Or buy from me direct. >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Dave Dolson [mailto:ddolson@sandvine.com] >>> Sent: 01 November 2016 19:35 >>> To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org >>> Subject: RE: [sfc] decrementing service function path index >>>=20 >>> The SF decrements the index so that the SFF doesn't have to look at=20 >>> the > packet >>> origin in order to determine whether or not to decrement it. >>> We don't want the SFF to have logic like: >>> If NSH packet is from one of addresses x, y z >>> Decrement SI >>>=20 >>> As currently defined, the SFF simply routes packets by SPI/SI=20 >>> without having >> to >>> do consider source address. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel >>> Sent: Tuesday, November 01, 2016 2:48 PM >>> To: 'Joel M. Halpern'; sfc@ietf.org >>> Subject: Re: [sfc] decrementing service function path index >>>=20 >>>> With regard to the architectural components, the NSH draft does=20 >>>> not define those. It is using the architectural, logical,=20 >>>> components and architecture defined by the SFC Architecture documents. >>>=20 >>> I'd like to understand where in 7665 it says that the SF is=20 >>> responsible for moving the packet on to the next SF in the path, rather= than the SFF. >>>=20 >>> I'd also like to understand why the NSH document (that tells us how=20 >>> to encapsulate, and what to do at each hop in the path) needs to=20 >>> divide the responsibility for bits of protocol work between=20 >>> different logical > functional >>> entities. In short, why does the SF decrement the SI, why isn't this=20 >>> an SFF function? What benefit comes from doing it this way or did a=20 >>> choice simply >> have >>> to be made? >>>=20 >>> Thanks, >>> Adrian >>>=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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 7 14:36:46 2016 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 A4A75129A87 for ; Mon, 7 Nov 2016 14:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 PRgYJ_6h7E0p for ; Mon, 7 Nov 2016 14:36:42 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00501129A48 for ; Mon, 7 Nov 2016 14:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27518; q=dns/txt; s=iport; t=1478558202; x=1479767802; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=E/x1nGTemkBt0NY1nKlTSyy0djEXhkE+yJiXYy9d+g4=; b=l1+kdqgDF/iR8yuK0A/TWQTMFhD2uNKEhMgqMUVYhPQ7fhwUjsVMgve/ OkRKH200jtd0/g97RH6zjwftrpnqSSgeZccaNf1bqlGuyFDwEjNEclcw1 HBLvylWH41pbbTQiMdW7PjwJJyRhpCmmzyb5er8rAbnxyN5zVGaVFU8lq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQB5ASFY/4UNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR9YfAeNMZcBlFKCBQMeC4JFgzYCghU/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEDAQEBARdUEAcEAgEIEQEDAQEoBycLFAMGCAIEARIIEQKINQgOtD6LP?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBARyLE4QjKzGFKAWECIQ8hkuBAoQ2hWABhjS?= =?us-ascii?q?DC4Z9gXWEcIM7hXeHL4V7hAUBHjd6G4MWHBiBRXKFDoEwgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,459,1473120000"; d="scan'208";a="344742373" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2016 22:36:39 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uA7Mada1020449 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 22:36:39 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 16:36:39 -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; Mon, 7 Nov 2016 16:36:39 -0600 From: "Surendra Kumar (smkumar)" To: "mohamed.boucadair@orange.com" , Dave Dolson , Adrian Farrel , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAB8If2AADzdLoAAXSDUAABsuotAAgEDW4AAjdOrAABN5r/A= Date: Mon, 7 Nov 2016 22:36:39 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <15233159ac6a4f3792284537082dec7c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DA9905@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <31e80873bcd44153a4fef95948214f4c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DAC4C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7a68ae56c03a4fb5b0e9df5cde622d41@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DAD609@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAD609@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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.33.116] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 22:36:45 -0000 Hi Med, Some comments inline, please see SK> Rgds, Surendra. -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Monday, November 07, 2016 5:28 AM To: Surendra Kumar (smkumar) ; Dave Dolson ; Adrian Farrel ; 'Joel M. Halpern' ; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Surendra,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Envoy=E9=A0:=20 > dimanche 6 novembre 2016 22:09 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Dave=20 > Dolson; Adrian Farrel; 'Joel M. > Halpern'; sfc@ietf.org > Objet=A0: RE: OK. Enough with the looping (spiralling :-) [Was:=20 > decrementing service function path index] >=20 > Hi Med, >=20 > There is no debate about the need for "SI". is a tuple that=20 > represents the SFC forwarding-state. >=20 > [For simplicity of discussion, let's leave out the classifier SFs.] 1.=20 > While SFF and SF are both part of the SFC architecture, the benefits=20 > of SF decrementing the SI as opposed to SFF decrementing is never=20 > articulated other than mandating it. On the other hand a case is laid=20 > out in the draft I mentioned earlier to have only SFF decrement the SI=20 > or SF to decrement by zero. >=20 [Med] I tend to agree with you on this particular point. =20 > Whether it is SF or SFF stamping the forwarding state into NSH, it has=20 > to be under CP control. IOW, they have to have the forwarding table=20 > laid out by CP. As was discussed many times in this list, changing the=20 > forwarding state on a NSH packet, then becomes a lookup or=20 > an implicit decrement. > Once you have a CP controlled SFC forwarding table, [Med] We already have a "CP controlled SFC forwarding table". The consensus= of the WG on the forwarding table is as follows (CP draft): SK> Thanks for this information. So, SPI is a primary key and probably SI and other information are addition= al keys. It does not however mandate a specific values for SI. I will take = this to mean, CP draft already allows any SI value to be programmed. Please= let me now if this is incorrect interpretation. o SFP Forwarding Policy Table: this table reflects the SFP-specific traffic forwarding policy enforced by SFF components for every relevant incoming packet that is associated to one of the existing SFCs. The SFP Identifier (SFP-id) is used as a lookup key to determine forwarding action regardless of whether the SFC is fully constrained, partially constrained, or not constrained at all. Additional information such as a flow identifier, Service Index (SI), and/or other characteristics (e.g., the 5-tuple transport coordinates of the original packet) may be used for lookup purposes. The set of information to use for lookup purposes may be instructed by the control plane. And=20 SFFs make traffic forwarding decisions according to the entries maintained in their SFP Forwarding Policy Table. Such table is ^^^^^^^^^^^^ populated by the SFC control plane through the C2 interface. In^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ particular, this interface is used to instruct the SFF about the set ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ of information to use for lookup purposes (e.g., SFP-id, 5-tuple^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ transport coordinates). One or many entries may be installed using one single control message. Installing new entries in the SFP Forwarding Policy Table must be immediate. The status of enforcing such entries must be communicated to the control plane as part of the communication procedure. In particular, specific error codes must be returned to the Control Element in case an error is encountered during the enforcement procedure. you have a fully > policy compliant SPI traversal. And that policy can be anything, as=20 > per the use case, while ensuring that the SI is monotonically going=20 > down to zero, for other benefits. >=20 > 2. It is a big assumption to make, to say *all* packets MUST always=20 > traverse *all* SFs in a chain. It is not part of the architecture,=20 > unless I missed that. [Med] Hmm, isn't you who said the following in (https://tools.ietf.org/html= /draft-kumar-sfc-offloads-03):=20 SK> this is a general explanation of the functionality to set the context f= or offloads and not to mandate a certain way of forwarding, obviously that = does not belong in the offloads draft. Service Function Chaining (SFC) enables services to be delivered by selective traffic steering through an ordered set of service functions. Once classified into an SFC, the traffic for a given flow = =20 is steered through all the service functions of the SFC for the life ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ of the traffic flow even though this is often not necessary. >=20 > 3. By having SFs manipulate the forwarding state on SFC packets, SFFs=20 > are essentially being co-located with SFs. There are many SFs, which=20 > do not need to deal with forwarding but only servicing. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com=20 > [mailto:mohamed.boucadair@orange.com] > Sent: Friday, November 04, 2016 12:49 AM > To: Surendra Kumar (smkumar) ; Dave Dolson=20 > ; Adrian Farrel ; 'Joel M. > Halpern' ; sfc@ietf.org > Subject: RE: OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > Hi Surendra, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Envoy=E9=A0: > > jeudi 3 novembre 2016 19:26 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Dave=20 > > Dolson; Adrian Farrel; 'Joel M. > > Halpern'; sfc@ietf.org > > Objet=A0: RE: OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > Hi Med, > > > > It is relaxing the rigid requirement, requiring decrement by one and=20 > > only one. This would be too restrictive a language to put inside NSH. >=20 > [Med] SI is there to achieve two objectives: location within a chain +=20 > loop detect. If we assume that the base SFC design is that a packet=20 > bound to a given chain has to cross **all** the SF instances that=20 > compose that chain, decrementing the index by one becomes trivial=20 > while decrementing by other values is not justified. >=20 > > > > I can imagine implementations wanting to jump over an SF under=20 > > policy control, either statically or dynamically, just as one simple ex= ample. >=20 > [Med] We can consider this case from several perspectives, e.g.,: >=20 > (1) This is deployment-specific. There are other ways to achieve the=20 > same > result: create a new chain that does not involve that SF, for example. >=20 > (2) This is implementation-specific. I hear that jumping over an SF=20 > can be achieved relying on some optimization that will preserve the=20 > size of the classification table. For example, a signal can be sent=20 > from an SF to its SFF. Doing so requires modifications to both SF and=20 > SFF. One can consider that the hook required in an SFF to honor a=20 > request from an SF is designed as a service function ("Void SF"=20 > co-located with an SFF). Under that design, the Void SF will proceed=20 > in place of the SF to be jumped. No modification is then required to the = processing of SI in such design. >=20 >=20 > > This is not reclassification. Whether the reasons are to prevent=20 > > proliferation of SPIs or to provide dynamic control, or something=20 > > else, it is use case driven. > > > > It is increasingly a software defined infrastructure to put it=20 > > mildly and I would rather allow this while not affecting the default=20 > > behavior. On the same lines, there are already drafts that are=20 > > carving the MD-Type1 allocation on the fly - as per control plane -=20 > > this is no > different. >=20 > [Med] I don't think we can put these two on the same level. Further,=20 > the control of the metadata is a clear control plane requirement. As=20 > an editor of the CP requirement draft, I'm still trying to understand=20 > if there is something that needs to be added to that document to=20 > capture a NEW requirement that wasn't raised before. Thank you. >=20 > > > > Surendra. > > PS: A method to not even modify the 'SI' by SFs is described here: > > https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/ > > > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Thursday, November 03, 2016 12:01 AM > > To: Surendra Kumar (smkumar) ; Dave Dolson=20 > > ; Adrian Farrel ; 'Joel M. > > Halpern' ; sfc@ietf.org > > Subject: RE: OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > Hi Surendra, > > > > It seems to me that we are trying to modifyi the SFC data plane=20 > > architecture to accommodate a given control plane solution proposal. > > > > As an editor of the SFC CP requirements I-D, I don't remember this=20 > > "flexibility" requirement was raised. > > > > Can you please elaborate on why it is useful to have this control=20 > > function? > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Surendra=20 > > > Kumar > > > (smkumar) > > > Envoy=E9=A0: jeudi 3 novembre 2016 00:46 =C0=A0: Dave Dolson; Adrian= =20 > > > Farrel; 'Joel M. Halpern'; sfc@ietf.org Objet > > > : Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: > > > decrementing service function path index] > > > > > > At the risk of spiraling (borrowing Adiran), this reasoning begs=20 > > > the question - why even have non-classifier SFs touch the SI to=20 > > > start with > ? > > > I would argue to leave it alone and treat SPI+SI as a forwarding=20 > > > state and opaque to SFs. > > > > > > Control plane can weave the same SF instance into thousands (well,=20 > > > it is a 24bit SPI) of SPIs and that shouldn't be a concern for the=20 > > > SF - consume metadata and service traffic. > > > > > > Allowing for control plane programmed decrement value is very=20 > > > reasonable and useful. > > > > > > Surendra. > > > > > > -----Original Message----- > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > Sent: Wednesday, November 02, 2016 1:51 AM > > > To: Adrian Farrel ; Surendra Kumar (smkumar)=20 > > > ; 'Joel M. Halpern' ;=20 > > > sfc@ietf.org > > > Subject: Re: OK. Enough with the looping (spiralling :-) [Was: > > > decrementing service function path index] > > > > > > Adrian, > > > Perhaps I'm making too fine a point, but I consider that if an SF=20 > > > does anything other than decrementing the SI by 1, we've entered=20 > > > the realm of reclassification, and it is a Classifier co-located=20 > > > with the SF that is overriding the SPI/SI. > > > > > > If you refer to Figure 8, path selection is not an action done by=20 > > > an > SF. > > > > > > Once reclassification is added to a deployment, we can have=20 > > > unicorns (and also dragons); much more becomes possible, but it=20 > > > also becomes much more difficult to reason about. > > > > > > You can read in the (expired) draft-penno-sfc-packet-03 some ideas=20 > > > about packet reversal that depending heavily on rigid SF=20 > > > decrement-by-one. I don't know how to begin reasoning about=20 > > > reverse forwarding once reclassification is added... > > > > > > For those reasons, I would prefer to see the SF action limited to=20 > > > decrement-by-one. If you require otherwise, co-locate a classifier=20 > > > with the SF. > > > > > > > > > -Dave > > > > > > > > > > > > Original Message > > > From: Adrian Farrel > > > Sent: Tuesday, November 1, 2016 9:52 PM > > > To: Dave Dolson; 'Surendra Kumar (smkumar)'; 'Joel M. Halpern';=20 > > > sfc@ietf.org Reply To: adrian@olddog.co.uk > > > Subject: OK. Enough with the looping (spiralling :-) [Was: > > > decrementing service function path index] > > > > > > > > > Been thinking about this instead of sleeping. > > > > > > Keep getting caught in rat-holes that say "no, but you could build=20 > > > product like this." But they are real rat-holes. What we need is a=20 > > > set of rule that work for simple implementations *and* that do not=20 > > > preclude more sophisticated implementations. > > > > > > So... > > > > > > When a packet arrives at an SFF the SPI/SI indicates the SFP and=20 > > > the next hop on that SFP to be executed. > > > > > > When an SF has finished processing a packet the default behavior=20 > > > is to leave the SPI unchanged and to decrement the SI by 1. > > > > > > However, and SF MAY know to make other changes to a the SPI and SI. > > > How that knowledge is installed in the SF is implementation dependent= : > > > - it may be the result of configuration (for example, normally=20 > > > decrement by > > > 1 but in event of a specific condition forward to a different > > > chain) > > > - it may be the result of a policy and visibility of the SFP > > > - it may be based on information in the metadata > > > - there may be unicorns > > > > > > There may be a classifier co-resident with the SF or in the path=20 > > > from SF back to SFF so that the SPI/SI received by the SFF is not=20 > > > a simple decrement of the SI. > > > > > > There may be a classifier co-resident with the SFF that processes=20 > > > the packet before the SFF performs forwarding so that the SPI/SI=20 > > > received by the SFF is not a simple decrement of the SI. > > > > > > The SFF's routing lookup may give it a choice of SFIs or SFFs to=20 > > > which to send the packet for the given SPI/SI. How it resolves=20 > > > this choice is a local matter (some policy that might be load=20 > > > balancing and could be influenced by any manner of things if an=20 > > > implementation chooses without prejudice to the interoperability=20 > > > of replaceability of > SFFs). > > > The fact of the choice is a function of how the network has been=20 > > > built, and how SFIs have been assigned, and how the SFPs have been=20 > > > constructed by the controller - it is not a function of the NSH > itself. > > > > > > The SFF's forwarding instructions can be simple (look up SPI/SI=20 > > > and send the packet out of interface X encapsulated in tunnel Y)=20 > > > or more complex (make some form of choice and manipulate the=20 > > > packet) just as in most other modern forwarding paradigms. > > > > > > An SFF that does not recognise the SPI/SI (i.e., has no forwarding=20 > > > state for it) can only (read MUST) drop the packet. > > > > > > What forwarding state an SFF has is a matter of: > > > - implementation > > > - control/management plane instructions > > > - visibility into the SFP (and other SFPs) > > > > > > > > > I believe this set of rules is consistent with 7665 and also=20 > > > supports what the WG wanted to achieve with the NSH draft without=20 > > > requiring any limitation on processing. That is, a simple=20 > > > implementation as envisaged by the proponents of "MUST decrement=20 > > > by one" is able to perform that function and still be conformant=20 > > > and > interoperable. > > > Similarly, a simple SFF as suggested in this thread would have no > > problems interoperating. > > > > > > Similarly, this behavior is flexible enough to allow for other=20 > > > uses and implementations. It is consistent with > > > draft-mackie-bess-nsh-bgp-control- > > > plane > > > (indeed, that draft doesn't tell the SF what to do with the SPI/SI=20 > > > at > > > all) and allows a control plane to program an SFF to do more=20 > > > sophisticated things. Of course, if the SFF cannot do those things=20 > > > then that will be OK since it won't support those control plane > > instructions. > > > > > > Can we put this to bed with the minimal change to > > > draft-ietf-sfc-nsh-10 section > > > 4 as follows: > > > > > > OLD > > > 3. Update NSH: NSH-aware service functions (SF) MUST decrement th= e > > > 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. > > > NEW > > > 3. Update NSH: NSH-aware service functions (SF) MUST decrement th= e > > > service index. By default the SF decrements the SI by 1,=20 > > > but > it > > > MAY apply other decrements according to configuration and othe= r > > > information available to it. If an SFF receives a packet with > > > an SPI and SI for which it does not have forwarding state, > > > it MUST be drop the packet, and SHOULD log the event subject t= o > > > rate limiting on such logs. > > > END > > > > > > Similarly later in the same bullet... > > > OLD > > > When the SFC > > > Proxy receives a packet back from an NSH unaware SF, it=20 > > > MUST > re- > > > encapsulates it with the correct NSH, and MUST decrement the > > > Service Index. > > > NEW > > > When the SFC > > > Proxy receives a packet back from an NSH unaware SF, it=20 > > > MUST > re- > > > encapsulates it with the correct NSH, and MUST decrement the > > > Service Index. By default the SFC Proxy decrements the SI=20 > > > by > 1, > > > but it MAY apply other decrements according to=20 > > > configuration > and > > > other information available to it. > > > END > > > > > > Furthermore, in section 3.3 since the term "egress NSH packet" is=20 > > > either ambiguous or neglects the possibility of reclassification... > > > > > > OLD > > > 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. > > > NEW > > > Service Index MUST be decremented by Service Functions or by SFC > > > Proxy nodes after performing required services as described in > > > Section 4. 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=20 > > > classifier > for > > > the resultant SPI. > > > END > > > > > > > > > Now perhaps I can sleep :-) > > > > > > Adrian > > > > > > > -----Original Message----- > > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > > Sent: 01 November 2016 23:22 > > > > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. > > > > Halpern'; sfc@ietf.org > > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > > I agree that the SF should be simple. > > > > But don't confuse decrementing the SI with complexity. > > > > There is absolutely no configuration required to have the SF=20 > > > > decrement the SI > > > of > > > > every packet. > > > > And there is a lot of benefit to keeping the SFF from having=20 > > > > rules about > > > packet > > > > source. > > > > > > > > As far as I'm concerned, the SF decrements the SI, and it has=20 > > > > been described > > > this > > > > way for a long time. Furthermore, the forwarding is described as=20 > > > > a lookup > > > table > > > > based on SPI/SI. There is no mention of the source in the=20 > > > > forwarding > > > table. > > > > > > > > > > > > > > > > > > > > Original Message > > > > From: Surendra Kumar (smkumar) > > > > Sent: Tuesday, November 1, 2016 7:03 PM > > > > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern';=20 > > > > sfc@ietf.org > > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > > > > > Since the forwarders already exists, they are logical components=20 > > > > to support > > > and > > > > perform NSH based forwarding - forwarding on SFPs, rather than=20 > > > > treat them as dumb forwarders. There is benefit to be had,=20 > > > > offloads being one of them, on > > > top > > > > of end of chain forwarding, etc. needed. > > > > > > > > I would rather have SFs focus on servicing the traffic than be=20 > > > > burdened with > > > SPI > > > > management (whether it is tens or thousands of SPIs) and the=20 > > > > forwarding thereof. IOW, consume metadata and service traffic=20 > > > > and leave the SFP management to the external forwarders. This=20 > > > > not only simplifies the SFs, it > > > also > > > > reduces the control plane touch point as it concerns to the SPI > > > management. > > > > > > > > And you don't need complex logic to differentiate between=20 > > > > traffic received > > > from > > > > one SFF or a SF, this is what we addressed in the forwarding=20 > > > > draft > > > > - trivial > > > to > > > > implement even in hardware. > > > > > > > > Thanks, > > > > Surendra. > > > > > > > > -----Original Message----- > > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > > > > Sent: Tuesday, November 01, 2016 1:27 PM > > > > To: adrian@olddog.co.uk; 'Joel M. Halpern'=20 > > > > ; sfc@ietf.org > > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > > Adrian, > > > > Thank you for paraphrasing in a clear manner. > > > > > > > > Yes, I'm saying that the current (as I understand it) design=20 > > > > permits the SFF > > > to be a > > > > simple forwarder, not needing to discriminate between packets=20 > > > > from another SFF or returning from an SF. > > > > A single forwarding table handles both cases. > > > > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF= 2 > > > > > > > > So it could tell the difference, but doesn't need to. > > > > In some cases, an SFF can be a single-interface device, so "from > SFF" > > > > or "from > > > SF" > > > > is not as simple as checking ingress interface, for example. > > > > > > > > > > > > -----Original Message----- > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > Sent: Tuesday, November 01, 2016 4:00 PM > > > > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > Just clarifying my understanding of what you said (not=20 > > > > necessarily agreeing > > > ;-) > > > > > > > > You are saying that an SFF is simply a forwarder and cannot tell=20 > > > > the > > > difference > > > > between a packet received on a transport tunnel from another SFF=20 > > > > and a packet received (back) from an SF that it serves. > > > > > > > > Or, more precisely, you are saying that the SFF is simply a=20 > > > > forwarder that cannot tell the difference between passing a=20 > > > > packet to a local SF and passing > > > a > > > > packet on to a remote SFF. > > > > > > > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > > > > > > > Is that your point? > > > > > > > > Cheers, > > > > Adrian > > > > > > > > -- > > > > Support an author and your imagination. > > > > Tales from the Wood - Eighteen new fairy tales. > > > > More Tales from the Wood - Eighteen MORE new fairy tales. > > > > https://www.feedaread.com/profiles/8604/ > > > > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > > > > Or buy from me direct. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > > > > Sent: 01 November 2016 19:35 > > > > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > > > > Subject: RE: [sfc] decrementing service function path index > > > > > > > > > > The SF decrements the index so that the SFF doesn't have to=20 > > > > > look at the > > > packet > > > > > origin in order to determine whether or not to decrement it. > > > > > We don't want the SFF to have logic like: > > > > > If NSH packet is from one of addresses x, y z > > > > > Decrement SI > > > > > > > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > > > > without having > > > > to > > > > > do consider source address. > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian=20 > > > > > Farrel > > > > > Sent: Tuesday, November 01, 2016 2:48 PM > > > > > To: 'Joel M. Halpern'; sfc@ietf.org > > > > > Subject: Re: [sfc] decrementing service function path index > > > > > > > > > > > With regard to the architectural components, the NSH draft=20 > > > > > > does not define those. It is using the architectural,=20 > > > > > > logical, components and architecture defined by the SFC=20 > > > > > > Architecture > > > documents. > > > > > > > > > > I'd like to understand where in 7665 it says that the SF is=20 > > > > > responsible for moving the packet on to the next SF in the=20 > > > > > path, > > > rather than the SFF. > > > > > > > > > > I'd also like to understand why the NSH document (that tells=20 > > > > > us how to encapsulate, and what to do at each hop in the path)=20 > > > > > needs to divide the responsibility for bits of protocol work=20 > > > > > between different logical > > > functional > > > > > entities. In short, why does the SF decrement the SI, why=20 > > > > > isn't this an SFF function? What benefit comes from doing it=20 > > > > > this way or did a choice simply > > > > have > > > > > to be made? > > > > > > > > > > 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 Mon Nov 7 14:39:40 2016 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 ECAE71299F3 for ; Mon, 7 Nov 2016 14:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 FDkX29uuewzN for ; Mon, 7 Nov 2016 14:39:36 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC69D129664 for ; Mon, 7 Nov 2016 14:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15759; q=dns/txt; s=iport; t=1478558375; x=1479767975; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6QZ2lOShwRoiGvyLt/u8j9ZRRZzaf5gkFr+SUCmcXbM=; b=ESGo4lnlev6KSaweFSik6jS8fG8tKs7A82NvocZbEJLiWtCac0Ai5/d/ 7s7o692asy8M7fhzNQEZeFOJsNGFhvK0B/y1rHEpbEIrrSK0kjYdMzMfX RPFPPR0Isob6xHw0DArB7MeGHuHDX3fjfgfrgz8Z7uRLI0dnXAm+qafaP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQD8ASFY/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAR9YfAeNMZcBlFKCCB4LhXsCghU/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEEAQEBNzQXBAIBCA4DAQMBAR8JBycLFAMGCAEBBAESCIhQDrRCiz4BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEcixOETjGFKAWECIREi3uFYAGGNIMLhn2BdYR?= =?us-ascii?q?wgzuFd4cvhXuEBQEeN3obgxYcGIFFcgGGPYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,459,1473120000"; d="scan'208";a="166803111" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2016 22:39:34 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uA7MdYBU018188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 22:39:34 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 16:39:33 -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; Mon, 7 Nov 2016 16:39:33 -0600 From: "Surendra Kumar (smkumar)" To: Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAACwOCAA== Date: Mon, 7 Nov 2016 22:39:33 +0000 Message-ID: <54abb6abc48c40399fc34382a69ebe76@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> 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.155.33.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 22:39:39 -0000 Hi Dave, Please look at https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forward= ing/ It is discussed in detail. It uses a single bit, managed by SFs, to make the opaque to SFs. T= his single bit is needed only because it is not the default behavior in NSH= . Surendra. -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Monday, November 07, 2016 9:35 AM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding.=20 Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with=20 an SPI and SI for which it does not have forwarding state,=20 it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in=20 Section 4. The initial Classifier MUST send the packet to the=20 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. >=20 > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. >=20 >=20 >=20 >=20 > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 >=20 > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. >=20 > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. >=20 > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > Adrian, > Thank you for paraphrasing in a clear manner. >=20 > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >=20 > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" > is not as simple as checking ingress interface, for example. >=20 >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) >=20 > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. >=20 > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. >=20 > And the SFF sees a packet n+1 times for an SFP with n local SFs. >=20 > Is that your point? >=20 > Cheers, > Adrian >=20 > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. >=20 >=20 >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 Nov 7 14:50:09 2016 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 AED8E1296A4 for ; Mon, 7 Nov 2016 14:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 iWUz1FWS03Oo for ; Mon, 7 Nov 2016 14:50:05 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818091295F8 for ; Mon, 7 Nov 2016 14:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16873; q=dns/txt; s=iport; t=1478559005; x=1479768605; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TZ4t9ykbuq/2K1ZivSaR0reAJ7TkWiZQLnIRTj/9w6w=; b=lU/r2b5T2Ape7+lWIPyknvdmpNpcNIXmhOIeZdiita4qoaDa4kyk4RKW 29P8ReaPw8N7hYLLBi/TJZMDXDOVdSsJt2yVyxWEq3obASV7IAjUH+jWv 92pDfHLicKKxcntjbJ+oHWT+i9i/E98KIilkXMuiAIP+HbPDNOymgVDQV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDGBCFY/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAR9YfAeNMZcBlFKCCB4LhXsCghU/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEEAQEBNzQXBAIBCBEBAwEBHwkHJwsUAwYIAQEEARIIiFAOtDmLPwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARyLE4ROMYUoBYQIhESLe4VgAYY0gwuGfYF1iCu?= =?us-ascii?q?Fd4cvhXuEBQEeN3obgxYcGIFFcgGGPYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,459,1473120000"; d="scan'208";a="168623854" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2016 22:50:04 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uA7Mo3TW027431 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 22:50:03 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 16:50:03 -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; Mon, 7 Nov 2016 16:50:03 -0600 From: "Surendra Kumar (smkumar)" To: Ron Parker , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAADZdUAAACdzjA Date: Mon, 7 Nov 2016 22:50:03 +0000 Message-ID: <9a1019fe979f498492669e1f044160d5@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> 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.155.33.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 22:50:08 -0000 Hi Ron, As Adrian proposed and as I already agreed to, default behavior is ok as lo= ng as we are not precluding sophisticated implementations. Two changes being sought, both does not affect the default behavior: 1. Allow SFFs and only SFFs to manage the , while having the defaul= t behavior of what it is now 2. Allow the decrement to be anything other than 'one', as per CP policy I think you agree with this. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, November 07, 2016 9:51 AM To: Dave Dolson ; Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, I agree with your conclusion. Decrementing SI at SFF requires the From fi= eld in its forwarding table/logic. That being said, I'm not opposed to making SI decrement an SFF responsibili= ty, with an acknowledgement of the above consequence. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, November 7, 2016 12:35 PM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding.=20 Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with=20 an SPI and SI for which it does not have forwarding state,=20 it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in=20 Section 4. The initial Classifier MUST send the packet to the=20 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. >=20 > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. >=20 >=20 >=20 >=20 > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 >=20 > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. >=20 > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. >=20 > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > Adrian, > Thank you for paraphrasing in a clear manner. >=20 > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >=20 > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" > is not as simple as checking ingress interface, for example. >=20 >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) >=20 > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. >=20 > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. >=20 > And the SFF sees a packet n+1 times for an SFP with n local SFs. >=20 > Is that your point? >=20 > Cheers, > Adrian >=20 > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. >=20 >=20 >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 7 14:55:15 2016 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 7320F129B82 for ; Mon, 7 Nov 2016 14:55:13 -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 CslRnnvZ4ZD2 for ; Mon, 7 Nov 2016 14:55:10 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC899129B67 for ; Mon, 7 Nov 2016 14:55:01 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 14:55:01 -0800 From: Ron Parker To: "Surendra Kumar (smkumar)" , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AQHSNWI6DouBHonXEkedrmTqIlch1aDOVeCA//99dmCAANqPgP//eptg Date: Mon, 7 Nov 2016 22:55:00 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> <9a1019fe979f498492669e1f044160d5@XCH-RCD-020.cisco.com> In-Reply-To: <9a1019fe979f498492669e1f044160d5@XCH-RCD-020.cisco.com> 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: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 22:55:13 -0000 I think #1 could be complicated in practice, since you need coordination be= tween all SFFs and SFs as to whose responsibility it is to perform the decr= ement. I'd prefer to stick with the default as the sole solution rather t= han introduce this complexity. Regarding #2, I think it is fine for an SF= to decrement by more than 1, thereby deciding to skip over subsequent SF(s= ). I'm also ok saying that an SF that does that is also behaving as a cla= ssifier. Ron -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=20 Sent: Monday, November 7, 2016 5:50 PM To: Ron Parker ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Ron, As Adrian proposed and as I already agreed to, default behavior is ok as lo= ng as we are not precluding sophisticated implementations. Two changes being sought, both does not affect the default behavior: 1. Allow SFFs and only SFFs to manage the , while having the defaul= t behavior of what it is now 2. Allow the decrement to be anything other th= an 'one', as per CP policy I think you agree with this. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, November 07, 2016 9:51 AM To: Dave Dolson ; Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, I agree with your conclusion. Decrementing SI at SFF requires the From fi= eld in its forwarding table/logic. That being said, I'm not opposed to making SI decrement an SFF responsibili= ty, with an acknowledgement of the above consequence. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, November 7, 2016 12:35 PM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding.=20 Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with=20 an SPI and SI for which it does not have forwarding state,=20 it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in=20 Section 4. The initial Classifier MUST send the packet to the=20 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. >=20 > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. >=20 >=20 >=20 >=20 > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 >=20 > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. >=20 > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. >=20 > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > Adrian, > Thank you for paraphrasing in a clear manner. >=20 > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >=20 > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" > is not as simple as checking ingress interface, for example. >=20 >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) >=20 > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. >=20 > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. >=20 > And the SFF sees a packet n+1 times for an SFP with n local SFs. >=20 > Is that your point? >=20 > Cheers, > Adrian >=20 > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. >=20 >=20 >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 7 14:55:42 2016 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 55267129B8F for ; Mon, 7 Nov 2016 14:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 Jl54FbSmCBf1 for ; Mon, 7 Nov 2016 14:55:39 -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 91327129B85 for ; Mon, 7 Nov 2016 14:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16375; q=dns/txt; s=iport; t=1478559322; x=1479768922; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hQP97cyB8FSd+5thtygZDqTCZJBpTzDPM9VX+jBm6jg=; b=cjdWDAg8KoGyCvWy7iymAeGX9oIHiBXzFc3IhK3ydJ/m/xp80OsS6nP/ 7smrTmaFUGg+GgKmSWbE7CK6KMWwwGnPaIl3A/VZkkjUE0FqIXC760wJ5 af9+5yA00ffeuhVYNZB9RtexbFZB6shEpaobRxZgrEYR6IewxXKbqs/5o Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBfBSFY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAR9YfAeNMZcBlFKCCB4LhXsCghU/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEEAQEBNzQXBAIBCA4DAQMBAR8JBycLFAMGCAEBBAESCIhQDrQ4iz8BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEcixOETjGFKAWECIREi3uFYAGGNIMLhn2BdYR?= =?us-ascii?q?wgzuFd4cvhXuEBQEeN3obgxYcGIFFcgGGPYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,459,1473120000"; d="scan'208";a="343709725" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2016 22:55:21 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA7MtLdU016020 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 22:55:21 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 16:55:20 -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; Mon, 7 Nov 2016 16:55:20 -0600 From: "Surendra Kumar (smkumar)" To: Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAACwOCAAAAmGeA Date: Mon, 7 Nov 2016 22:55:20 +0000 Message-ID: <05ce1bdcddd14e21a700066bf663b739@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> <54abb6abc48c40399fc34382a69ebe76@XCH-RCD-020.cisco.com> In-Reply-To: <54abb6abc48c40399fc34382a69ebe76@XCH-RCD-020.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.33.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 22:55:41 -0000 I meant to say, it had to be specified outside of NSH as it is not the defa= ult behavior. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkuma= r) Sent: Monday, November 07, 2016 2:40 PM To: Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpe= rn' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Hi Dave, Please look at https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forward= ing/ It is discussed in detail. It uses a single bit, managed by SFs, to make the opaque to SFs. T= his single bit is needed only because it is not the default behavior in NSH= . Surendra. -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Monday, November 07, 2016 9:35 AM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding.=20 Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with=20 an SPI and SI for which it does not have forwarding state,=20 it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in=20 Section 4. The initial Classifier MUST send the packet to the=20 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. >=20 > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. >=20 >=20 >=20 >=20 > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 >=20 > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. >=20 > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. >=20 > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > Adrian, > Thank you for paraphrasing in a clear manner. >=20 > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >=20 > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" > is not as simple as checking ingress interface, for example. >=20 >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) >=20 > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. >=20 > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. >=20 > And the SFF sees a packet n+1 times for an SFP with n local SFs. >=20 > Is that your point? >=20 > Cheers, > Adrian >=20 > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. >=20 >=20 >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 Mon Nov 7 15:02:02 2016 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 920DB129B70 for ; Mon, 7 Nov 2016 15:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 cIqry39coEhc for ; Mon, 7 Nov 2016 15:01:59 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E91129B82 for ; Mon, 7 Nov 2016 15:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18645; q=dns/txt; s=iport; t=1478559719; x=1479769319; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=atxJkGlUl3BLoQ0/3tkE9DHAdCGDjBOxnKaa3Hl2RSQ=; b=mmaqADRj5CHREwDYiz8BUxNGKRh06dwQ3OfJk/Ww6nwjt8iFN0+5KSIu uWFuFXy7tLaqZvaCbAYFs8ovybIhsPzRWGv6bh/XzExXwPI5URViWfvO5 VyLl891NtiNZ6NsV/2upGF7p398kgWLzWSnfok0H7lbljITFrLspqQOF1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQCMByFY/51dJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR9YfAeNMZcBlFKCCB4LhXsCghU/FAECAQEBAQEBAWIohGE?= =?us-ascii?q?BAQEEAQEBNzQXBAIBCBEBAwEBHwkHJwsUAwYIAgQBEggTiD0OtDaLPwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARyLE4ROMYUoBYQIhESLe4VgAYY0gwuGfYF1iCuFd4c?= =?us-ascii?q?vhXuEBQEeN3obgxYcGIFFcgGGPYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,459,1473120000"; d="scan'208";a="345423020" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2016 23:01:57 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uA7N1vRp028664 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 23:01:57 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 17:01:56 -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; Mon, 7 Nov 2016 17:01:57 -0600 From: "Surendra Kumar (smkumar)" To: Ron Parker , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAADZdUAAACdzjAAAgn8gAADIGIYA== Date: Mon, 7 Nov 2016 23:01:57 +0000 Message-ID: <6cd477a406e24f62b0af2f059f853da0@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> <9a1019fe979f498492669e1f044160d5@XCH-RCD-020.cisco.com> 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.155.33.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 23:02:01 -0000 I am afraid we will spiral on this one.=20 It is not complicated, but only makes it simpler by having SFF manage the f= orwarding while SF deliver the service. I would imagine there would be less number of SFFs to program (the forwardi= ng state) than SFs, to start with. And SFs do not have to deal with forward= ing state. If we would like to remove the lines between the SF and the SFF, the SFC ar= chitecture can do away with SFF. Surendra. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Monday, November 07, 2016 2:55 PM To: Surendra Kumar (smkumar) ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I think #1 could be complicated in practice, since you need coordination be= tween all SFFs and SFs as to whose responsibility it is to perform the decr= ement. I'd prefer to stick with the default as the sole solution rather t= han introduce this complexity. Regarding #2, I think it is fine for an SF= to decrement by more than 1, thereby deciding to skip over subsequent SF(s= ). I'm also ok saying that an SF that does that is also behaving as a cla= ssifier. Ron -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Monday, November 7, 2016 5:50 PM To: Ron Parker ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Ron, As Adrian proposed and as I already agreed to, default behavior is ok as lo= ng as we are not precluding sophisticated implementations. Two changes being sought, both does not affect the default behavior: 1. Allow SFFs and only SFFs to manage the , while having the defaul= t behavior of what it is now 2. Allow the decrement to be anything other th= an 'one', as per CP policy I think you agree with this. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, November 07, 2016 9:51 AM To: Dave Dolson ; Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, I agree with your conclusion. Decrementing SI at SFF requires the From fi= eld in its forwarding table/logic. That being said, I'm not opposed to making SI decrement an SFF responsibili= ty, with an acknowledgement of the above consequence. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, November 7, 2016 12:35 PM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding.=20 Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with=20 an SPI and SI for which it does not have forwarding state,=20 it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in=20 Section 4. The initial Classifier MUST send the packet to the=20 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. >=20 > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. >=20 >=20 >=20 >=20 > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 >=20 > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. >=20 > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. >=20 > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. >=20 > Thanks, > Surendra. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > Adrian, > Thank you for paraphrasing in a clear manner. >=20 > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >=20 > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" > is not as simple as checking ingress interface, for example. >=20 >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) >=20 > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. >=20 > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. >=20 > And the SFF sees a packet n+1 times for an SFP with n local SFs. >=20 > Is that your point? >=20 > Cheers, > Adrian >=20 > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. >=20 >=20 >=20 > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > Thanks, > > Adrian > > > > _______________________________________________ > > 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 7 15:10:31 2016 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 B5FAC129B8F for ; Mon, 7 Nov 2016 15:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 IOMWJm7hyDKx for ; Mon, 7 Nov 2016 15:10:27 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5FD129B8D for ; Mon, 7 Nov 2016 15:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17584; q=dns/txt; s=iport; t=1478560226; x=1479769826; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Wxx30zGs4kwnX+kX6NwSRqTGvy2eoZ7skFIy4IAEWIY=; b=EnpV0InVdJRU7/bVPBbMdHByZazwY6GznPIK5Qv/ooYzhOVpay2gW2GP FMITKWLBgzEFjDf/Z49r8L88Hwew8Jqg4V4xpcyzJStuaGij/iuiEgo0e ndwyf4kDdydj7UVpqgZ7Phw32DTH+diGmLsyucAvq/Gh2CyLQWYjJYZp+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDrCCFY/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAR9YfAeNMZcBlFKCCB4LhXsCghU/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEDAQEBATc0CwUHBAIBCBEBAwEBAR4FBAcnCxQDBggBAQQBDQUIiEgID?= =?us-ascii?q?rQ6iz8BAQEBAQEBAQEBAQEBAQEBAQEBAQEcixOETjGFKAWECIREi3uFYAGGNIM?= =?us-ascii?q?Lhn2BdYgrhXeHL4V7hAUBHjd6G4MWHBiBRXIBhj2BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,459,1473120000"; d="scan'208";a="166454175" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2016 23:10:25 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uA7NAPMD005542 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 23:10:25 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 17:10:24 -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; Mon, 7 Nov 2016 17:10:24 -0600 From: "Surendra Kumar (smkumar)" To: "Paul Quinn (paulq)" , Dave Dolson Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAAD4giAAADl/fg Date: Mon, 7 Nov 2016 23:10:24 +0000 Message-ID: References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> 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.155.33.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 23:10:29 -0000 Comments inline. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Monday, November 07, 2016 10:46 AM To: Dave Dolson Cc: sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, In general, this whole scheme of "SFF decrement" is naive: it adds complexi= ty and changes the semantics of service completion. As you point out, decr= ementing on the SFF requires that the SFF know about the source "type" of p= acket: did it come from an SF, or an SFF. In effect, the SFF has some form= state that it tracks. Sure you can that state around, but then you've don= e nothing new. SK> A single bit, in the packet, if that is what you call the state - nothi= ng in the SFF. We already have 32 bits of state - in NSH. This additional bit ca= n even be carved out of the same 32 bits, if that simplifies ? Perhaps more importantly, SI _means_ something. It means that the service = has completed it's task. This has a slew of benefits, ranging from simple = visibility, to trace, to security, particularly when/if crypto is applied. SK> SI=3D=3Dwhere you are on the chain. The benefits are discussed in https= ://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/ The current model, ensures both a simple SFF, and a consistent representati= on of service "done", and is implemented. SK> SFF stays very simple with SFF decrements while SF becomes even simpler= w.r.t forwarding. Paul > On Nov 7, 2016, at 12:35 PM, Dave Dolson wrote: >=20 > Surendra, > When you would have the Service Function not modify the Service Index, ca= n you explain how the SFF is configured to discriminate between the two cas= es in this example? > 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255=20 > (requires forwarding to SF1) 2. NSH packet arrives from SF1 with=20 > SPI=3D10 and SI=3D255 (already serviced) >=20 > Is it fair to say that there is a source-routing input to the SFF decisio= n, adding an new "From" column to the table of https://tools.ietf.org/html/= draft-ietf-sfc-nsh-10#section-7.1 ? >=20 > +-------------------------------------------------------------------+ > | FROM | SPI | SI | Next hop(s) | Transport | > +-------------------------------------------------------------------+ > | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | > +-------------------------------------------------------------------+ > | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | > +-------------------------------------------------------------------+ > ... > +-------------------------------------------------------------------+ >=20 >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: Wednesday, November 02, 2016 7:38 PM > To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: OK. Enough with the looping (spiralling :-) [Was:=20 > decrementing service function path index] >=20 > Adrian, >=20 > This is a very good compromise. Completely agree on "Not preclude sophist= icated implementations" and IMO it is crucial to go beyond legacy forwardin= g methods and allow for, not only flexible implementations as you note, but= also for use-case evolution/innovation. >=20 > While I agree with the default behavior of SF decrementing by 1, in addit= ion to allowing for it to be decremented by a configured value, I would lik= e that to be extended to explicitly include a decrement value of zero (no d= ecrement). So, I support your modified verbiage below to allow for a decrem= ent value of *ZERO*. >=20 > This allows for control-plane/configuration dictated behavior and is flex= ible enough to support different methods of forwarding.=20 >=20 > Surendra. >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 6:52 PM > To: 'Dave Dolson' ; Surendra Kumar (smkumar)=20 > ; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: OK. Enough with the looping (spiralling :-) [Was:=20 > decrementing service function path index] >=20 > Been thinking about this instead of sleeping. >=20 > Keep getting caught in rat-holes that say "no, but you could build produc= t like this." But they are real rat-holes. What we need is a set of rule th= at work for simple implementations *and* that do not preclude more sophisti= cated implementations. >=20 > So... >=20 > When a packet arrives at an SFF the SPI/SI indicates the SFP and the next= hop on that SFP to be executed. >=20 > When an SF has finished processing a packet the default behavior is to le= ave the SPI unchanged and to decrement the SI by 1. > SK> Firstly, why even have SI >=20 > However, and SF MAY know to make other changes to a the SPI and SI. How t= hat knowledge is installed in the SF is implementation dependent: > - it may be the result of configuration (for example, normally decrement = by > 1 but in event of a specific condition forward to a different chain) > - it may be the result of a policy and visibility of the SFP > - it may be based on information in the metadata > - there may be unicorns >=20 > There may be a classifier co-resident with the SF or in the path from SF = back to SFF so that the SPI/SI received by the SFF is not a simple decremen= t of the SI. > SK> Yes, absolutely. If SFs have co-located classifiers, they can restart= a chain or adjust the SI, all based on policy dictated by a higher level e= ntity. >=20 > There may be a classifier co-resident with the SFF that processes the pac= ket before the SFF performs forwarding so that the SPI/SI received by the S= FF is not a simple decrement of the SI. >=20 > The SFF's routing lookup may give it a choice of SFIs or SFFs to which to= send the packet for the given SPI/SI. How it resolves this choice is a loc= al matter (some policy that might be load balancing and could be influenced= by any manner of things if an implementation chooses without prejudice to = the interoperability of replaceability of SFFs). The fact of the choice is = a function of how the network has been built, and how SFIs have been assign= ed, and how the SFPs have been constructed by the controller - it is not a = function of the NSH itself. >=20 > The SFF's forwarding instructions can be simple (look up SPI/SI and send = the packet out of interface X encapsulated in tunnel Y) or more complex (ma= ke some form of choice and manipulate the packet) just as in most other mod= ern forwarding paradigms. >=20 > An SFF that does not recognise the SPI/SI (i.e., has no forwarding state = for it) can only (read MUST) drop the packet. >=20 > What forwarding state an SFF has is a matter of: > - implementation > - control/management plane instructions > - visibility into the SFP (and other SFPs) >=20 >=20 > I believe this set of rules is consistent with 7665 and also supports wha= t the WG wanted to achieve with the NSH draft without requiring any limitat= ion on processing. That is, a simple implementation as envisaged by the pro= ponents of "MUST decrement by one" is able to perform that function and sti= ll be conformant and interoperable. Similarly, a simple SFF as suggested in= this thread would have no problems interoperating. >=20 > Similarly, this behavior is flexible enough to allow for other uses=20 > and implementations. It is consistent with=20 > draft-mackie-bess-nsh-bgp-control-plane > (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all= ) and allows a control plane to program an SFF to do more sophisticated thi= ngs. Of course, if the SFF cannot do those things then that will be OK sinc= e it won't support those control plane instructions. >=20 > Can we put this to bed with the minimal change to=20 > draft-ietf-sfc-nsh-10 section > 4 as follows: >=20 > OLD > 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. > NEW > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > service index. By default the SF decrements the SI by 1, but it > MAY apply other decrements according to configuration and other > information available to it. If an SFF receives a packet with=20 > an SPI and SI for which it does not have forwarding state,=20 > it MUST be drop the packet, and SHOULD log the event subject to > rate limiting on such logs. > END >=20 > Similarly later in the same bullet... > OLD > 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. > NEW > 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. By default the SFC Proxy decrements the SI by 1, > but it MAY apply other decrements according to configuration and > other information available to it. > END >=20 > Furthermore, in section 3.3 since the term "egress NSH packet" is either = ambiguous or neglects the possibility of reclassification... >=20 > OLD > 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. > NEW > Service Index MUST be decremented by Service Functions or by SFC > Proxy nodes after performing required services as described in=20 > Section 4. The initial Classifier MUST send the packet to the=20 > 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. > END >=20 >=20 > Now perhaps I can sleep :-) >=20 > Adrian >=20 >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: 01 November 2016 23:22 >> To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 >> sfc@ietf.org >> Subject: Re: [sfc] decrementing service function path index >>=20 >> I agree that the SF should be simple. >> But don't confuse decrementing the SI with complexity. >> There is absolutely no configuration required to have the SF=20 >> decrement the SI > of >> every packet. >> And there is a lot of benefit to keeping the SFF from having rules=20 >> about > packet >> source. >>=20 >> As far as I'm concerned, the SF decrements the SI, and it has been=20 >> described > this >> way for a long time. Furthermore, the forwarding is described as a=20 >> lookup > table >> based on SPI/SI. There is no mention of the source in the forwarding tab= le. >>=20 >>=20 >>=20 >>=20 >> Original Message >> From: Surendra Kumar (smkumar) >> Sent: Tuesday, November 1, 2016 7:03 PM >> To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org >> Subject: RE: [sfc] decrementing service function path index >>=20 >>=20 >> Since the forwarders already exists, they are logical components to=20 >> support > and >> perform NSH based forwarding - forwarding on SFPs, rather than treat=20 >> them as dumb forwarders. There is benefit to be had, offloads being=20 >> one of them, on > top >> of end of chain forwarding, etc. needed. >>=20 >> I would rather have SFs focus on servicing the traffic than be=20 >> burdened with > SPI >> management (whether it is tens or thousands of SPIs) and the=20 >> forwarding thereof. IOW, consume metadata and service traffic and=20 >> leave the SFP management to the external forwarders. This not only=20 >> simplifies the SFs, it > also >> reduces the control plane touch point as it concerns to the SPI manageme= nt. >>=20 >> And you don't need complex logic to differentiate between traffic=20 >> received > from >> one SFF or a SF, this is what we addressed in the forwarding draft -=20 >> trivial > to >> implement even in hardware. >>=20 >> Thanks, >> Surendra. >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >> Sent: Tuesday, November 01, 2016 1:27 PM >> To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 >> sfc@ietf.org >> Subject: Re: [sfc] decrementing service function path index >>=20 >> Adrian, >> Thank you for paraphrasing in a clear manner. >>=20 >> Yes, I'm saying that the current (as I understand it) design permits=20 >> the SFF > to be a >> simple forwarder, not needing to discriminate between packets from=20 >> another SFF or returning from an SF. >> A single forwarding table handles both cases. >> E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 >>=20 >> So it could tell the difference, but doesn't need to. >> In some cases, an SFF can be a single-interface device, so "from SFF"=20 >> or "from > SF" >> is not as simple as checking ingress interface, for example. >>=20 >>=20 >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Tuesday, November 01, 2016 4:00 PM >> To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org >> Subject: RE: [sfc] decrementing service function path index >>=20 >> Just clarifying my understanding of what you said (not necessarily=20 >> agreeing > ;-) >>=20 >> You are saying that an SFF is simply a forwarder and cannot tell the > difference >> between a packet received on a transport tunnel from another SFF and=20 >> a packet received (back) from an SF that it serves. >>=20 >> Or, more precisely, you are saying that the SFF is simply a forwarder=20 >> that cannot tell the difference between passing a packet to a local=20 >> SF and passing > a >> packet on to a remote SFF. >>=20 >> And the SFF sees a packet n+1 times for an SFP with n local SFs. >>=20 >> Is that your point? >>=20 >> Cheers, >> Adrian >>=20 >> -- >> Support an author and your imagination. >> Tales from the Wood - Eighteen new fairy tales. >> More Tales from the Wood - Eighteen MORE new fairy tales. >> https://www.feedaread.com/profiles/8604/ >> http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 >> Or buy from me direct. >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Dave Dolson [mailto:ddolson@sandvine.com] >>> Sent: 01 November 2016 19:35 >>> To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org >>> Subject: RE: [sfc] decrementing service function path index >>>=20 >>> The SF decrements the index so that the SFF doesn't have to look at=20 >>> the > packet >>> origin in order to determine whether or not to decrement it. >>> We don't want the SFF to have logic like: >>> If NSH packet is from one of addresses x, y z >>> Decrement SI >>>=20 >>> As currently defined, the SFF simply routes packets by SPI/SI=20 >>> without having >> to >>> do consider source address. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel >>> Sent: Tuesday, November 01, 2016 2:48 PM >>> To: 'Joel M. Halpern'; sfc@ietf.org >>> Subject: Re: [sfc] decrementing service function path index >>>=20 >>>> With regard to the architectural components, the NSH draft does not=20 >>>> define those. It is using the architectural, logical, components=20 >>>> and architecture defined by the SFC Architecture documents. >>>=20 >>> I'd like to understand where in 7665 it says that the SF is=20 >>> responsible for moving the packet on to the next SF in the path, rather= than the SFF. >>>=20 >>> I'd also like to understand why the NSH document (that tells us how=20 >>> to encapsulate, and what to do at each hop in the path) needs to=20 >>> divide the responsibility for bits of protocol work between=20 >>> different logical > functional >>> entities. In short, why does the SF decrement the SI, why isn't this=20 >>> an SFF function? What benefit comes from doing it this way or did a=20 >>> choice simply >> have >>> to be made? >>>=20 >>> Thanks, >>> Adrian >>>=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 > _______________________________________________ > 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 Nov 7 15:11:52 2016 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 4CF71129B8D for ; Mon, 7 Nov 2016 15:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 dCT0h9yQd3lW for ; Mon, 7 Nov 2016 15:11:48 -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 4E778129BCE for ; Mon, 7 Nov 2016 15:11:48 -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; Mon, 7 Nov 2016 18:11:46 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 18:11:47 -0500 From: Dave Dolson To: "Surendra Kumar (smkumar)" , Ron Parker , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAAC37jAAAKcuiAAAAsQgAAAD4jgP//rusF Date: Mon, 7 Nov 2016 23:11:45 +0000 Message-ID: <20161107231144.5697621.14742.117688@sandvine.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> <9a1019fe979f498492669e1f044160d5@XCH-RCD-020.cisco.com> , <6cd477a406e24f62b0af2f059f853da0@XCH-RCD-020.cisco.com> In-Reply-To: <6cd477a406e24f62b0af2f059f853da0@XCH-RCD-020.cisco.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 23:11:51 -0000 Surendra, I think it is misleading to imply SFs need to be programmed to decrement SI= by 1. This behavior can be (and should be, IMO) hard-coded. Furthermore, t= here is not any extra "forwarding state". So it is false to say that decrementing the SI in the SFF is easier to conf= igure. In fact it is harder to configure due to the source routing requirem= ents mentioned earlier. -Dave Original Message From: Surendra Kumar (smkumar) Sent: Monday, November 7, 2016 6:02 PM To: Ron Parker; Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ie= tf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I am afraid we will spiral on this one. It is not complicated, but only makes it simpler by having SFF manage the f= orwarding while SF deliver the service. I would imagine there would be less number of SFFs to program (the forwardi= ng state) than SFs, to start with. And SFs do not have to deal with forward= ing state. If we would like to remove the lines between the SF and the SFF, the SFC ar= chitecture can do away with SFF. Surendra. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, November 07, 2016 2:55 PM To: Surendra Kumar (smkumar) ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I think #1 could be complicated in practice, since you need coordination be= tween all SFFs and SFs as to whose responsibility it is to perform the decr= ement. I'd prefer to stick with the default as the sole solution rather t= han introduce this complexity. Regarding #2, I think it is fine for an SF= to decrement by more than 1, thereby deciding to skip over subsequent SF(s= ). I'm also ok saying that an SF that does that is also behaving as a cla= ssifier. Ron -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Monday, November 7, 2016 5:50 PM To: Ron Parker ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Ron, As Adrian proposed and as I already agreed to, default behavior is ok as lo= ng as we are not precluding sophisticated implementations. Two changes being sought, both does not affect the default behavior: 1. Allow SFFs and only SFFs to manage the , while having the defaul= t behavior of what it is now 2. Allow the decrement to be anything other th= an 'one', as per CP policy I think you agree with this. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, November 07, 2016 9:51 AM To: Dave Dolson ; Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, I agree with your conclusion. Decrementing SI at SFF requires the From fi= eld in its forwarding table/logic. That being said, I'm not opposed to making SI decrement an SFF responsibili= ty, with an acknowledgement of the above consequence. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, November 7, 2016 12:35 PM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding. Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with an SPI and SI for which it does not have forwarding state, it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in Section 4. 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern'; > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules > about packet > source. > > As far as I'm concerned, the SF decrements the SI, and it has been > described this > way for a long time. Furthermore, the forwarding is described as a > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. > > > > > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Since the forwarders already exists, they are logical components to > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat > them as dumb forwarders. There is benefit to be had, offloads being > one of them, on top > of end of chain forwarding, etc. needed. > > I would rather have SFs focus on servicing the traffic than be > burdened with SPI > management (whether it is tens or thousands of SPIs) and the > forwarding thereof. IOW, consume metadata and service traffic and > leave the SFP management to the external forwarders. This not only > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. > > And you don't need complex logic to differentiate between traffic > received from > one SFF or a SF, this is what we addressed in the forwarding draft - > trivial to > implement even in hardware. > > Thanks, > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ; > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Adrian, > Thank you for paraphrasing in a clear manner. > > Yes, I'm saying that the current (as I understand it) design permits > the SFF to be a > simple forwarder, not needing to discriminate between packets from > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF" > or "from SF" > is not as simple as checking ingress interface, for example. > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > Just clarifying my understanding of what you said (not necessarily > agreeing ;-) > > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a > packet received (back) from an SF that it serves. > > Or, more precisely, you are saying that the SFF is simply a forwarder > that cannot tell the difference between passing a packet to a local SF > and passing a > packet on to a remote SFF. > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > Is that your point? > > Cheers, > Adrian > > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does > > > not define those. It is using the architectural, logical, > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how > > to encapsulate, and what to do at each hop in the path) needs to > > divide the responsibility for bits of protocol work between > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this > > an SFF function? What benefit comes from doing it this way or did a > > choice simply > have > > to be made? > > > > 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 Mon Nov 7 15:23:10 2016 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 A100F12964E for ; Mon, 7 Nov 2016 15:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 vaIsQLfn7iGp for ; Mon, 7 Nov 2016 15:23:05 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D1F129423 for ; Mon, 7 Nov 2016 15:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20008; q=dns/txt; s=iport; t=1478560978; x=1479770578; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gGFBmP67JuevIHhw2w9tc2AzCG6h3IssBeqQfKuPoFk=; b=PlU4ZLAsX7s3lyZUqanhcRyPiTNWtyXhtpabnthjyfYUATdzsTORZb7L v5zufUc5xeYDTIWS10qhc27/PubpqEEsNJ9x137vbNW216WXbN+oW5dl7 gT6LOfTNsqkXiJtjj4zk9n26FE7AhPJshCTqLVRzUmdK0JjKbnB1BoUFx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQA7DCFY/4sNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR9YfAeNMZcBlFKCCB4LhXsCghY/FAECAQEBAQEBAWIohGE?= =?us-ascii?q?BAQEEAQEBNzQXBAIBCA4DAQMBAR8JBycLFAMGCAIEARIIE4g9DrQ9iz8BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEcixOETjGFKAWECIREi3uFYAGGNIMLhn2BdYgrhXe?= =?us-ascii?q?HL4V7hAUBHjd6G4MWHBiBRXIBhj2BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,459,1473120000"; d="scan'208";a="345430951" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2016 23:22:56 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uA7NMugi018681 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 23:22:56 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 17:22:56 -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; Mon, 7 Nov 2016 17:22:56 -0600 From: "Surendra Kumar (smkumar)" To: Dave Dolson , Ron Parker , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAADZdUAAACdzjAAAgn8gAADIGIYP//oKGAgABj5qA= Date: Mon, 7 Nov 2016 23:22:56 +0000 Message-ID: <6ba68e971db14db583bac0b6d70e5080@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> <9a1019fe979f498492669e1f044160d5@XCH-RCD-020.cisco.com> , <6cd477a406e24f62b0af2f059f853da0@XCH-RCD-020.cisco.com> <20161107231144.5697621.14742.117688@sandvine.com> In-Reply-To: <20161107231144.5697621.14742.117688@sandvine.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.33.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 07 Nov 2016 23:23:08 -0000 Dave, It is very misleading to say is not a forwarding state. It is fal= se to say "source routing" unless you mean entire SFC is a source-route, be= cause it is already fully specified. Then, why not have SFC (architecture) go from CF to SF to SF ... and not ha= ve the SFF demarcation, over dumb forwarders/infrastructure? Surendra. -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Monday, November 07, 2016 3:12 PM To: Surendra Kumar (smkumar) ; Ron Parker ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sfc@ietf.org Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Surendra, I think it is misleading to imply SFs need to be programmed to decrement SI= by 1. This behavior can be (and should be, IMO) hard-coded. Furthermore, t= here is not any extra "forwarding state". So it is false to say that decrementing the SI in the SFF is easier to conf= igure. In fact it is harder to configure due to the source routing requirem= ents mentioned earlier. -Dave Original Message From: Surendra Kumar (smkumar) Sent: Monday, November 7, 2016 6:02 PM To: Ron Parker; Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ie= tf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I am afraid we will spiral on this one. It is not complicated, but only makes it simpler by having SFF manage the f= orwarding while SF deliver the service. I would imagine there would be less number of SFFs to program (the forwardi= ng state) than SFs, to start with. And SFs do not have to deal with forward= ing state. If we would like to remove the lines between the SF and the SFF, the SFC ar= chitecture can do away with SFF. Surendra. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, November 07, 2016 2:55 PM To: Surendra Kumar (smkumar) ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I think #1 could be complicated in practice, since you need coordination be= tween all SFFs and SFs as to whose responsibility it is to perform the decr= ement. I'd prefer to stick with the default as the sole solution rather t= han introduce this complexity. Regarding #2, I think it is fine for an SF= to decrement by more than 1, thereby deciding to skip over subsequent SF(s= ). I'm also ok saying that an SF that does that is also behaving as a cla= ssifier. Ron -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Monday, November 7, 2016 5:50 PM To: Ron Parker ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Ron, As Adrian proposed and as I already agreed to, default behavior is ok as lo= ng as we are not precluding sophisticated implementations. Two changes being sought, both does not affect the default behavior: 1. Allow SFFs and only SFFs to manage the , while having the defaul= t behavior of what it is now 2. Allow the decrement to be anything other th= an 'one', as per CP policy I think you agree with this. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, November 07, 2016 9:51 AM To: Dave Dolson ; Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, I agree with your conclusion. Decrementing SI at SFF requires the From fi= eld in its forwarding table/logic. That being said, I'm not opposed to making SI decrement an SFF responsibili= ty, with an acknowledgement of the above consequence. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, November 7, 2016 12:35 PM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding. Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with an SPI and SI for which it does not have forwarding state, it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in Section 4. 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. > > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. > > > > > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. > > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. > > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. > > Thanks, > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Adrian, > Thank you for paraphrasing in a clear manner. > > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF" > or "from SF" > is not as simple as checking ingress interface, for example. > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) > > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. > > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > Is that your point? > > Cheers, > Adrian > > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > 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 Mon Nov 7 18:32:26 2016 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 75CFC1294EC for ; Mon, 7 Nov 2016 18:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 P516eJKazT6z for ; Mon, 7 Nov 2016 18:32:21 -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 C28BC1294B9 for ; Mon, 7 Nov 2016 18:32:20 -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 CZX04346; Tue, 08 Nov 2016 02:32:17 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Nov 2016 02:32:17 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Mon, 7 Nov 2016 18:32:13 -0800 From: Lucy yong To: "Surendra Kumar (smkumar)" , Dave Dolson , Ron Parker , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAADZdUAAACdzjAAAxY1AAAAD4jgAAAV5+AAABj/AAAC2NKwA== Date: Tue, 8 Nov 2016 02:32:13 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572EA443@dfweml501-mbb> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> <9a1019fe979f498492669e1f044160d5@XCH-RCD-020.cisco.com> , <6cd477a406e24f62b0af2f059f853da0@XCH-RCD-020.cisco.com> <20161107231144.5697621.14742.117688@sandvine.com> <6ba68e971db14db583bac0b6d70e5080@XCH-RCD-020.cisco.com> In-Reply-To: <6ba68e971db14db583bac0b6d70e5080@XCH-RCD-020.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58213932.011D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6b977752ec0574a36fad9d81e6f456d7 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 08 Nov 2016 02:32:25 -0000 Surendra, "2. Allow the decrement to be anything other than 'one', as per CP policy." I am not sure what SFC use case demands this implementation.=20 Having one rule to set SI value (i.e. SF decrements by one) provides clear = and simple implementation in which SFs do not need to maintain "decrement v= alue" state per a SPI basis, which is great benefit for implementation and = operation.=20 I prefer not adding this complexity to NSH.=20 Regards, Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkuma= r) Sent: Monday, November 07, 2016 5:23 PM To: Dave Dolson; Ron Parker; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ie= tf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, It is very misleading to say is not a forwarding state. It is fal= se to say "source routing" unless you mean entire SFC is a source-route, be= cause it is already fully specified. Then, why not have SFC (architecture) go from CF to SF to SF ... and not ha= ve the SFF demarcation, over dumb forwarders/infrastructure? Surendra. -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Monday, November 07, 2016 3:12 PM To: Surendra Kumar (smkumar) ; Ron Parker ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sfc@ietf.org Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Surendra, I think it is misleading to imply SFs need to be programmed to decrement SI= by 1. This behavior can be (and should be, IMO) hard-coded. Furthermore, t= here is not any extra "forwarding state". So it is false to say that decrementing the SI in the SFF is easier to conf= igure. In fact it is harder to configure due to the source routing requirem= ents mentioned earlier. -Dave Original Message From: Surendra Kumar (smkumar) Sent: Monday, November 7, 2016 6:02 PM To: Ron Parker; Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ie= tf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I am afraid we will spiral on this one. It is not complicated, but only makes it simpler by having SFF manage the f= orwarding while SF deliver the service. I would imagine there would be less number of SFFs to program (the forwardi= ng state) than SFs, to start with. And SFs do not have to deal with forward= ing state. If we would like to remove the lines between the SF and the SFF, the SFC ar= chitecture can do away with SFF. Surendra. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, November 07, 2016 2:55 PM To: Surendra Kumar (smkumar) ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I think #1 could be complicated in practice, since you need coordination be= tween all SFFs and SFs as to whose responsibility it is to perform the decr= ement. I'd prefer to stick with the default as the sole solution rather t= han introduce this complexity. Regarding #2, I think it is fine for an SF= to decrement by more than 1, thereby deciding to skip over subsequent SF(s= ). I'm also ok saying that an SF that does that is also behaving as a cla= ssifier. Ron -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Monday, November 7, 2016 5:50 PM To: Ron Parker ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Ron, As Adrian proposed and as I already agreed to, default behavior is ok as lo= ng as we are not precluding sophisticated implementations. Two changes being sought, both does not affect the default behavior: 1. Allow SFFs and only SFFs to manage the , while having the defaul= t behavior of what it is now 2. Allow the decrement to be anything other th= an 'one', as per CP policy I think you agree with this. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, November 07, 2016 9:51 AM To: Dave Dolson ; Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, I agree with your conclusion. Decrementing SI at SFF requires the From fi= eld in its forwarding table/logic. That being said, I'm not opposed to making SI decrement an SFF responsibili= ty, with an acknowledgement of the above consequence. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, November 7, 2016 12:35 PM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding. Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with an SPI and SI for which it does not have forwarding state, it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in Section 4. 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. > > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. > > > > > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. > > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. > > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. > > Thanks, > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Adrian, > Thank you for paraphrasing in a clear manner. > > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF" > or "from SF" > is not as simple as checking ingress interface, for example. > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) > > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. > > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > Is that your point? > > Cheers, > Adrian > > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 7 22:26:32 2016 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 46CFE129A74 for ; Mon, 7 Nov 2016 22:26:29 -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, 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 zXB36lpUtopr for ; Mon, 7 Nov 2016 22:26:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8C7129A89 for ; Mon, 7 Nov 2016 22:26:25 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id F01843247A0; Tue, 8 Nov 2016 07:26:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.3]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CB75E23807C; Tue, 8 Nov 2016 07:26:23 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0319.002; Tue, 8 Nov 2016 07:26:23 +0100 From: To: "Surendra Kumar (smkumar)" , Dave Dolson , Adrian Farrel , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAOpICmAB8If2AADzdLoAAXSDUAABsuotAAgEDW4AAjdOrAABN5r/AAEKuJcA== Date: Tue, 8 Nov 2016 06:26:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DADE86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <20161102085050.5697621.72811.116410@sandvine.com> <15233159ac6a4f3792284537082dec7c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DA9905@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <31e80873bcd44153a4fef95948214f4c@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DAC4C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7a68ae56c03a4fb5b0e9df5cde622d41@XCH-RCD-020.cisco.com> <787AE7BB302AE849A7480A190F8B933009DAD609@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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.8.54517 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 08 Nov 2016 06:26:29 -0000 Hi Surendra,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Envoy=E9=A0: lundi 7 novembre 2016 23:37 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Dave Dolson; Adrian Farrel; 'Joel M. > Halpern'; sfc@ietf.org > Objet=A0: RE: OK. Enough with the looping (spiralling :-) [Was: decrement= ing > service function path index] >=20 > Hi Med, >=20 > Some comments inline, please see SK> >=20 > Rgds, > Surendra. >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, November 07, 2016 5:28 AM > To: Surendra Kumar (smkumar) ; Dave Dolson > ; Adrian Farrel ; 'Joel M. > Halpern' ; sfc@ietf.org > Subject: RE: OK. Enough with the looping (spiralling :-) [Was: > decrementing service function path index] >=20 > Hi Surendra, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Envoy=E9=A0: > > dimanche 6 novembre 2016 22:09 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Dave > > Dolson; Adrian Farrel; 'Joel M. > > Halpern'; sfc@ietf.org > > Objet=A0: RE: OK. Enough with the looping (spiralling :-) [Was: > > decrementing service function path index] > > > > Hi Med, > > > > There is no debate about the need for "SI". is a tuple that > > represents the SFC forwarding-state. > > > > [For simplicity of discussion, let's leave out the classifier SFs.] 1. > > While SFF and SF are both part of the SFC architecture, the benefits > > of SF decrementing the SI as opposed to SFF decrementing is never > > articulated other than mandating it. On the other hand a case is laid > > out in the draft I mentioned earlier to have only SFF decrement the SI > > or SF to decrement by zero. > > >=20 > [Med] I tend to agree with you on this particular point. >=20 >=20 > > Whether it is SF or SFF stamping the forwarding state into NSH, it has > > to be under CP control. IOW, they have to have the forwarding table > > laid out by CP. As was discussed many times in this list, changing the > > forwarding state on a NSH packet, then becomes a lookup or > > an implicit decrement. > > Once you have a CP controlled SFC forwarding table, >=20 > [Med] We already have a "CP controlled SFC forwarding table". The > consensus of the WG on the forwarding table is as follows (CP draft): > SK> Thanks for this information. > So, SPI is a primary key and probably SI and other information are > additional keys. It does not however mandate a specific values for SI. I > will take this to mean, CP draft already allows any SI value to be > programmed. Please let me now if this is incorrect interpretation. >=20 [Med] The only setting of SI called out in the CP draft is the following:=20 The control plane must instruct the classifier about the initial values of the Service Index (SI). The processing of SI by other SFC-aware nodes is complaint to the data plan= e documents (read SFC architecture, SFC NSH). From nobody Mon Nov 7 22:36:56 2016 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 844E71296BD for ; Mon, 7 Nov 2016 22:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 maOKzzR8xUMd for ; Mon, 7 Nov 2016 22:36:52 -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 AB4C81295FD for ; Mon, 7 Nov 2016 22:36:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZX31240; Tue, 08 Nov 2016 06:36:49 +0000 (GMT) Received: from SZXEMI402-HUB.china.huawei.com (10.82.75.34) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Nov 2016 06:36:48 +0000 Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.48]) by SZXEMI402-HUB.china.huawei.com ([10.83.65.54]) with mapi id 14.03.0235.001; Tue, 8 Nov 2016 14:36:43 +0800 From: Gaurav agrawal To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] IETF97 SFC WG Agenda Thread-Index: AQHSOQkhybCKbvMTTUukho3r4QYiGqDNIa0AgAGAAYA= Date: Tue, 8 Nov 2016 06:36:42 +0000 Message-ID: <2F2059F256F9B24F82EAC5EE47F446C6E76C1307@szxemi502-mbx.china.huawei.com> References: <03D84EFF-19E6-4FE0-B60E-C34892DFE9DB@cisco.com> <8964ce09-54f2-1acd-c85c-0e5cb496f4c0@joelhalpern.com> In-Reply-To: <8964ce09-54f2-1acd-c85c-0e5cb496f4c0@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.250.69] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58217281.01B1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.48, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: db22976a8941b34c3b73f08cb2378548 Archived-At: Subject: Re: [sfc] IETF97 SFC WG Agenda 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, 08 Nov 2016 06:36:54 -0000 SGkgSm9lbCwNCg0KSSB3b3VsZCBsaWtlIHRvIHZvbHVudGVlciBmb3IgdGhlIHNhbWUuDQoNClRo YW5rcyBhbmQgUmVnYXJkcywNCkdhdXJhdg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2Vs IE0uIEhhbHBlcm4NClNlbnQ6IDIwMTbE6jEx1MI3yNUgMjE6MDgNClRvOiBzZmNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbc2ZjXSBJRVRGOTcgU0ZDIFdHIEFnZW5kYQ0KDQpJbiBhZGRpdGlvbiB0 byB0aGUgZ2V0dGluZyB0aGUgcHJlc2VudGF0aW9uLCB3ZSB3aWxsIG5lZWQgYSBtaW51dGUgdGFr ZXIgZm9yIHRoZSBTRkMgc2Vzc2lvbi4NCg0KSSB3b3VsZCBwcmVmZXIgbm90IHRvIHNpdCB0aGVy ZSBkZWxheWluZyB0aGUgc3RhcnQgb2YgdGhlIG1lZXRpbmcgd2hpbGUgSSBnbGFyZSBhdCBmb2xr cyB1bnRpbCB3ZSBnZXQgYSBtaW51dGUgdGFrZXIuDQoNCk1vdmluZyBmb3J3YXJkLCBKaW0gYW5k IEkgd291bGQgbGlrZSB0byBzZWUgYWJvdXQgYXBwb2ludGluZyBhIHdvcmtpbmcgZ3JvdXAgc2Vj cmV0YXJ5LiAgVGhpcyBwZXJzb24gd291bGQgdGFrZSBtaW51dGVzIGF0IG1lZXRpbmdzIGFuZCBo ZWxwIHVzIHdpdGggdHJhY2tpbmcgaXRlbXMgYmV0d2VlbiBtZWV0aW5ncy4gIEZvciBleGFtcGxl LCBtYWtpbmcgc3VyZSB3ZSBub3RpZnkgZWFjaCBwZXJzb24gd2hvIHJlcXVlc3RzIGEgc2xvdCB3 aGV0aGVyIHRoZXkgZ290IG9uZS4NCg0KTm90ZSB0aGF0IHRoZSB0d28gcmVxdWVzdHMgYXJlIG5v dCBjb3VwbGVkLiAgT2ZmZXJpbmcgdG8gdGFrZSBtaW51dGVzIGluIFNlb3VsIGRvZXMgbm90IG1l YW4geW91IGFyZSBhbHNvIG9mZmVyaW5nIHRvIGJlIHNlY3JldGFyeS4gIEFuZCB5b3UgY2FuIG9m ZmVyIHRvIHRha2Ugb24gdGhlIHJvbGUgb2Ygc2VjcmV0YXJ5IGdvaW5nIGZvcndhcmQgZXZlbiBp ZiB5b3UgYXJlIG1pc3NpbmcgU2VvdWwsIGFzc3VtaW5nIHRoYXQgeW91IGV4cGVjdCB0byBtYWtl IG1vc3Qgb2YgdGhlIHVwY29taW5nIG1lZXRpbmdzLg0KDQpZb3VycywNCkpvZWwNCg0KT24gMTEv Ny8xNiAxMDoxMCBBTSwgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgd3JvdGU6DQo+IERlYXIgV0c6 DQo+DQo+IFBsZWFzZSBmaW5kIHRoZSBwcmVsaW1pbmFyeSBhZ2VuZGEgcG9zdGVkIGhlcmUNCj4g LT4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk3L2FnZW5kYS9zZmMvDQo+ DQo+IFByZXNlbnRlcnMsIHBsZWFzZSBmb3J3YXJkIHlvdXIgc2xpZGVzIHRvIHRoZSBXRyBjaGFp cnMgYnkgbm8gbGF0ZXIgDQo+IHRoYW4NCj4gMTEvMTEvMjAxNiA1UE0gRVNULg0KPg0KPiBUaGFu ayB5b3UhDQo+DQo+IEppbSAmIEpvZWwNCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5n IGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCg== From nobody Tue Nov 8 10:01:27 2016 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 EA3931299B6 for ; Tue, 8 Nov 2016 10:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 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=-1.497, 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 s727O0ulK1NE for ; Tue, 8 Nov 2016 10:01:26 -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 C8840129643 for ; Tue, 8 Nov 2016 10:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9210; q=dns/txt; s=iport; t=1478628085; x=1479837685; h=from:to:subject:date:message-id:mime-version; bh=KNVG5t7OFbQJp0WlpMNaMvl7XEPvQsUe4s+FzpR0W4w=; b=fhovoQVdcuZaBZf4m8AB3TvCxlCO/4SYNhqNS5eLObAwxGYsixDV/Z3O vqbE8GK/LEz7XFVo5FyjsagqAjXTkTG/+1LZC7fQZBsoP6xqIfp41SWUy Pi4D/1uvL9in51WbiFuq/DJisMkqlhVTknpkFjArnUtLG0hauoL87WGTM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQD7ESJY/5RdJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgnM8AQEBAQEfWIEGjTKmPoUagggphheBdj8UAQIBAQEBAQEBYh0LhGgjaAF?= =?us-ascii?q?KAgQwJwSIbw6iFo96gkCLSQEBAQEBAQEDAQEBAQEBAQEBARgFhj6BfYQXAYJ6g?= =?us-ascii?q?xQtgi8FlE2FYgGGNYMLhweBboRyiAqBKocyigMBHjd6G4MjP4EthyCBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,462,1473120000"; d="scan'208,217";a="344120809" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2016 18:01:24 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uA8I1NRh021864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Nov 2016 18:01:23 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; Tue, 8 Nov 2016 12:01:23 -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, 8 Nov 2016 12:01:23 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSOeoddhBvoux3dU2uL7kFD+H1Lg== Date: Tue, 8 Nov 2016 18:01:23 +0000 Message-ID: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_3C8518413FC8430B93BEE96C63B8EC55ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 08 Nov 2016 18:01:27 -0000 --_000_3C8518413FC8430B93BEE96C63B8EC55ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBTRkMgV0c6DQoNCkFmdGVyIG11Y2ggZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB3aXRoIHJl Z2FyZCB0byB0aWNrZXQgIzIxIHRoZSBmb2xsb3dpbmcgdGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0 byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNzIGFuZCBzbyBmb3J0aC4gUGxlYXNlIHJl dmlldyBhbmQgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90KSBzbyB0aGF0IHRoZSBjaGFpcnMgY2Fu IGRldGVybWluZSBjb25zZW5zdXMgYW5kIHVwZGF0ZSB0aGUgdGlja2V0IGFjY29yZGluZ2x5Lg0K DQpUaGFuayB5b3UhDQoNCkppbSAmIEpvZWwNCg0KIyMjIyMjIyMjIw0KDQpORVcgZm9yIHNlY3Rp b24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24g YWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBv ZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3Ig bWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuDQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNU IHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNzIGZpcnN0IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhl IGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNl bWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmlu ZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRh IHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoN ClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJl IFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBu b3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250 ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRo aXMgZXJyb3IuDQoNCltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4 YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0 aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuDQoNCk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41 LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91 dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUg bWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVzZSBjb25zaWRlcmF0aW9ucyBhcmUgZGVwbG95bWVu dC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250cm9sIHBsYW5lIGNhbiBpbnN0cnVjdCBTRkMt YXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJlIG9mIFRMVnMgdG9nZXRoZXIgd2l0aCB0 aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBvZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wt cGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2 ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQg cGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQg TVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KSWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3Mg VExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFuZSBNQVkg aW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBvcmRlciB0byBjb25zdW1lIHRoZXNl IFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNG IE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5IGFwcGVhciBpbiB0aGUg TlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUg aW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExW IGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNz IHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQo= --_000_3C8518413FC8430B93BEE96C63B8EC55ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7A2DD4BF702E2F4E82B55351A93E4E7C@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+RGVhciBTRkMgV0c6PC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5BZnRlciBtdWNoIGRp c2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0ICMyMSB0aGUgZm9sbG93 aW5nIHRleHQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5IG1ldGFkYXRhIHNlbWFu dGljcyBhbmQgc28gZm9ydGguIFBsZWFzZSByZXZpZXcgYW5kIGluZGljYXRlIHN1cHBvcnQgKG9y IG5vdCkgc28gdGhhdCB0aGUgY2hhaXJzIGNhbg0KIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHVw ZGF0ZSB0aGUgdGlja2V0IGFjY29yZGluZ2x5LiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+VGhhbmsgeW91ITwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+SmltICZhbXA7IEpvZWw8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPiMjIyMjIyMjIyM8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGI+PGJy Pg0KPC9iPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7 Ij48Yj5ORVcgZm9yIHNlY3Rpb24gMy40PC9iPjo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2Ug YW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkg Y29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRo ZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuICZuYnNwOzwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+QW4gU0ZD LWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIg dG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxk LiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRp b24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4NCiBIb3cgYW4g U0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAt d2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zdGFuZGFyZDsiPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0 LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2Yg bWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3Ig dGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNr ZXQgYW5kDQogTVVTVCBsb2cgdGhpcyBlcnJvci48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHByb3Zp ZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0YSBj b252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48Yj5ORVcgZm9yIGVuZCBvZiBzZWN0 aW9uIDMuNS4xPC9iPjo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0 YW5kYXJkOyI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24g YWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQg YXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiZuYnNwOyZuYnNwO1RoZXNlIGNvbnNpZGVyYXRpb25z IGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiZuYnNwOyZuYnNwO0hvd2V2ZXIsIHRoZSBjb250cm9s IHBsYW5lIGNhbiBpbnN0cnVjdA0KIFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1 cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4z IG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRo YXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBp cyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nl c3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci48L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPklmIG11bHRpcGxlIG1hbmRhdG9yeS10 by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wg cGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29u c3VtZSB0aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlk ZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzDQogdGhlc2UgVExWcyBpbiB0aGUgb3Jk ZXIgdGhleTxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnBy ZSI+DQo8L3NwYW4+YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0LjwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9m IHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZp bml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBT RiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3C8518413FC8430B93BEE96C63B8EC55ciscocom_-- From nobody Tue Nov 8 10:17:54 2016 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 7A51D129CEF for ; Tue, 8 Nov 2016 10:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CEjFqBCVqpho for ; Tue, 8 Nov 2016 10:17: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 829CA129CD4 for ; Tue, 8 Nov 2016 10:16:40 -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; Tue, 8 Nov 2016 10:16:39 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSOeoddhBvoux3dU2uL7kFD+H1LqDPZE2w Date: Tue, 8 Nov 2016 18:16:38 +0000 Message-ID: References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> In-Reply-To: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> 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: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B83905783MBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 08 Nov 2016 18:17:53 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B83905783MBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLg0KDQpJIHN1cHBvcnQgdGhlIHRleHQuDQoNCk9uZSBlZGl0b3JpYWwgbml0IOKAkyDi gJxVcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmfigJ0gLS0+IOKAnFVwb24gcmVj ZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZ3PigJ0uDQoNCiAgIFJvbg0KDQoNCkZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJk IChqZ3VpY2hhcikNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDgsIDIwMTYgMTowMSBQTQ0KVG86 IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv c2ZjL3RpY2tldC8yMQ0KDQpEZWFyIFNGQyBXRzoNCg0KQWZ0ZXIgbXVjaCBkaXNjdXNzaW9uIG9u IHRoZSBsaXN0IHdpdGggcmVnYXJkIHRvIHRpY2tldCAjMjEgdGhlIGZvbGxvd2luZyB0ZXh0IGhh cyBiZWVuIHByb3Bvc2VkIHRvIGhlbHAgY2xhcmlmeSBtZXRhZGF0YSBzZW1hbnRpY3MgYW5kIHNv IGZvcnRoLiBQbGVhc2UgcmV2aWV3IGFuZCBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIHNvIHRo YXQgdGhlIGNoYWlycyBjYW4gZGV0ZXJtaW5lIGNvbnNlbnN1cyBhbmQgdXBkYXRlIHRoZSB0aWNr ZXQgYWNjb3JkaW5nbHkuDQoNClRoYW5rIHlvdSENCg0KSmltICYgSm9lbA0KDQojIyMjIyMjIyMj DQoNCk5FVyBmb3Igc2VjdGlvbiAzLjQ6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFr ZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9y eSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUg dGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4NCg0KQW4g U0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3Jk ZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZp ZWxkLiAgVGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hl bWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJl IFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg c3BlY2lmaWNhdGlvbi4NCg0KVXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQs IGlmIHRoZSBTRkMtYXdhcmUgU0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBt ZXRhZGF0YSBidXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIGZvciB0 aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tl dCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KW2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10g cHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRoZSBk YXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCg0KTkVXIGZvciBl bmQgb2Ygc2VjdGlvbiAzLjUuMToNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFu eSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBv ciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gIFRoZXNlIGNvbnNpZGVyYXRp b25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiAgSG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUg Y2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExW cyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQu aWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLg0KDQpVcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhh dCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlz IG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2Vz cyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpJZiBtdWx0aXBsZSBtYW5k YXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBj b250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVy IHRvIGNvbnN1bWUgdGhlc2UgVExWcy4gIElmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlkZWQs IHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRo ZXkNCmFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9m IHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZp bml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBT RiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B83905783MBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3Rh bmRhcmQ7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SGkgSmltLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBzdXBw b3J0IHRoZSB0ZXh0LiZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5PbmUgZWRpdG9yaWFsIG5pdCDigJMg4oCcPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssc2VyaWY7Y29sb3I6YmxhY2siPlVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9u Z+KAnQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oldp bmdkaW5ncztjb2xvcjpibGFjayI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+IOKAnFVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZzxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+czwvc3Bhbj7igJ0uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90Oyxz ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IFJvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KaW0gR3VpY2hhcmQg KGpndWljaGFyKTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciA4LCAyMDE2IDE6 MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBb c2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5EZWFyIFNGQyBXRzo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNr Ij5BZnRlciBtdWNoIGRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0 ICMyMSB0aGUgZm9sbG93aW5nIHRleHQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5 IG1ldGFkYXRhIHNlbWFudGljcyBhbmQgc28gZm9ydGguIFBsZWFzZSByZXZpZXcNCiBhbmQgaW5k aWNhdGUgc3VwcG9ydCAob3Igbm90KSBzbyB0aGF0IHRoZSBjaGFpcnMgY2FuIGRldGVybWluZSBj b25zZW5zdXMgYW5kIHVwZGF0ZSB0aGUgdGlja2V0IGFjY29yZGluZ2x5LiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPlRoYW5rIHlvdSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5KaW0gJmFtcDsgSm9l bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssc2VyaWY7Y29sb3I6YmxhY2siPiMjIyMjIyMjIyM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5O RVcgZm9yIHNlY3Rpb24gMy40PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJs YWNrIj46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+VGhpcyBzcGVjaWZpY2F0 aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2Vk IGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRv ZXMgbm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUNCiBvciBtZWFuaW5nIG9mIHRoZSBpbmNsdWRl ZCBtZXRhZGF0YS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1V U1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0 aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZuYnNw O1RoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlDQogYWxsb2NhdGlvbiBzY2hlbWEg YW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNG IGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5VcG9uIHJlY2VpdmluZyBhbiBOU0ggTUQt dHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBtYW5k YXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0YSBz ZW1hbnRpY3MgZm9yIHRoZQ0KIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBw cm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90 OyxzZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+W2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMg dG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRoZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5k YXRvcnkgY29udGV4dCBmaWVsZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5ORVcgZm9yIGVuZCBv ZiBzZWN0aW9uIDMuNS4xPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNr Ij46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+VGhpcyBzcGVjaWZpY2F0aW9u IGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRv cnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiZu YnNwOyZuYnNwO1RoZXNlIGNvbnNpZGVyYXRpb25zIGFyZQ0KIGRlcGxveW1lbnQtc3BlY2lmaWMu Jm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGluc3RydWN0IFNGQy1h d2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRo ZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1w bGFuZV0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPlVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0 IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMg bWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNz IHRoZSBwYWNrZXQgYW5kDQogTVVTVCBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNr Ij5JZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3Ig YSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJl IFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1bWUgdGhlc2UgVExWcy4mbmJzcDsmbmJzcDtJZg0K IG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9j ZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRoZXk8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5hcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtp dC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90 OyxzZXJpZjtjb2xvcjpibGFjayI+SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRM ViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRo YXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBw cm9jZXNzDQogdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B83905783MBX021W3CA2exch_-- From nobody Tue Nov 8 10:44:57 2016 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 E599E1296CB for ; Tue, 8 Nov 2016 10:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 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=-1.497, 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 UcwPm1H9WM9N for ; Tue, 8 Nov 2016 10:44:54 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550E6129881 for ; Tue, 8 Nov 2016 10:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8841; q=dns/txt; s=iport; t=1478630691; x=1479840291; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mU0a1ifR5Dw8nRxxn0IgO9gBova5f8GLW7oOcZSxRkc=; b=hUxKAIwv6F249VxbwF+uaKI/oSDtETz+V9FHRQWazChekVp6sXs3z+tQ iNo2P51fzpj0r9rUMvlFC89Oyc1tFUthUTEv9Si7rKy/erO69hM7K037W GdOpiWdatVVlh7FhmrASp/zk51GtdCnYGCqJpIDemQd12UzoVI3pKfDkU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAQCLHCJY/5xdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM8AQEBAQEfWG8QB40ypj6FGoIIHgEKhXsCghI/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGIBAQQBAQFrCxACAQg/BycLFBECBA4FiFwOtFeLSQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARcFhj6BfQiCUoE9AYJ6RoJ7gi8FlE2FYgGGNYMLhweBboRyiAqBKoc?= =?us-ascii?q?yhX6EBQEeN3obgyM/gS1yhi6BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,611,1473120000"; d="scan'208,217";a="344484374" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2016 18:44:50 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uA8IioRi013477 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Nov 2016 18:44:50 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 8 Nov 2016 12:44:49 -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, 8 Nov 2016 12:44:49 -0600 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSOeoddhBvoux3dU2uL7kFD+H1LqDP0R0A Date: Tue, 8 Nov 2016 18:44:49 +0000 Message-ID: <9F32D993-E3FF-43B4-8287-EA8A27E6822E@cisco.com> References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> In-Reply-To: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.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.131.118.43] Content-Type: multipart/alternative; boundary="_000_9F32D993E3FF43B48287EA8A27E6822Eciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 08 Nov 2016 18:44:56 -0000 --_000_9F32D993E3FF43B48287EA8A27E6822Eciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems reasonable to me. Paul On Nov 8, 2016, at 1:01 PM, Jim Guichard (jguichar) > wrote: Dear SFC WG: After much discussion on the list with regard to ticket #21 the following t= ext has been proposed to help clarify metadata semantics and so forth. Plea= se review and indicate support (or not) so that the chairs can determine co= nsensus and update the ticket accordingly. Thank you! Jim & Joel ########## NEW for section 3.4: 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 s= tructure or meaning of the included metadata. An SFC-aware SF MUST receive the data semantics first in order to process t= he data placed in the mandatory context field. The data semantics include = both the allocation schema and the meaning of the included data. How an SFC= -aware SF gets the data semantics is outside the scope of this specificatio= n. Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured f= or mandatory use of metadata but has not yet received the data semantics fo= r the mandatory context field, it MUST NOT process the packet and MUST log = this error. [dcalloc] and [broadalloc] provide sample examples to associate a meaning w= ith the data conveyed in the mandatory context field. NEW for end of section 3.5.1: This specification does not make any assumption about TLVs that are mandato= ry-to-implement or those that are mandatory-to-process. These consideratio= ns are deployment-specific. However, the control plane can instruct SFC-aw= are SFs with the data structure of TLVs together with their scoping (See Se= ction 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-proc= ess TLV is missing in that packet, the SFC-aware SF MUST NOT process the pa= cket and MUST log this error. If multiple mandatory-to-process TLVs are required for a given SFP, the con= trol plane MAY instruct the SFC-aware SF with the order to consume these TL= Vs. If no instructions are provided, the SFC-aware SF MUST process these T= LVs in the order they appear in the NSH packet. If multiple instances of the same TLV are included in an NSH packet, but th= e definition of that TLV does not allow for it, the SFC-aware SF MUST NOT p= rocess the packet and MUST log this error. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_9F32D993E3FF43B48287EA8A27E6822Eciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Seems reasonable to me.

Paul

On Nov 8, 2016, at 1:01 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wr= ote:

Dear SFC WG:

After much discuss= ion on the list with regard to ticket #21 the following text has been propo= sed to help clarify metadata semantics and so forth. Please review and indi= cate support (or not) so that the chairs can determine consensus and update the ticket accordingly. 

Thank you!

Jim & Joel

##########

NEW = for section 3.4:
This specification= does not make any assumption about the content placed in the mandatory con= text field of the NSH header, and does not describe the structure or meanin= g of the included metadata.  

An SFC-aware SF MU= ST receive the data semantics first in order to process the data placed in = the mandatory context field.  The data semantics include both the= allocation schema and the meaning of the included data. How an SFC-aware SF gets the data semantics is outside the scope of = this specification.

Upon receiving an = NSH MD-type 1 packet, if the SFC-aware SF is configured for mandatory use o= f metadata but has not yet received the data semantics for the mandatory co= ntext field, it MUST NOT process the packet and MUST log this error.

[dcalloc] and [bro= adalloc] provide sample examples to associate a meaning with the data conve= yed in the mandatory context field.

NEW = for end of section 3.5.1:
This specification= does not make any assumption about TLVs that are mandatory-to-implement or= those that are mandatory-to-process.  These considerations are d= eployment-specific.  However, the control plane can instruct SFC-aware SFs with the data structure of TLVs together with t= heir 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 = this error.

If multiple mandat= ory-to-process TLVs are required for a given SFP, the control plane MAY ins= truct 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 they appear in the NSH packet.

If multiple instan= ces of the same TLV are included in an NSH packet, but the definition of th= at TLV does not allow for it, the SFC-aware SF MUST NOT process the packet = and MUST log this error.
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_9F32D993E3FF43B48287EA8A27E6822Eciscocom_-- From nobody Tue Nov 8 11:05:25 2016 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 84B9612945E for ; Tue, 8 Nov 2016 11:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 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=-1.497] 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_PxnBzv0eEh for ; Tue, 8 Nov 2016 11:05:23 -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 6FFA8129531 for ; Tue, 8 Nov 2016 11:05:22 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Tue, 8 Nov 2016 14:05:21 -0500 From: Dave Dolson To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSOeoddhBvoux3dU2uL7kFD+H1LqDPcWVg Date: Tue, 8 Nov 2016 19:05:20 +0000 Message-ID: References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> In-Reply-To: <3C851841-3FC8-430B-93BE-E96C63B8EC55@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_E8355113905631478EFF04F5AA706E983115472Fwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 08 Nov 2016 19:05:24 -0000 --_000_E8355113905631478EFF04F5AA706E983115472Fwtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gc2V2ZXJhbCBwbGFjZXMsIHRoZSB0ZXh0IHNheXMsIOKAnOKApiBhbmQgTVVTVCBsb2cgdGhp cyBlcnJvci7igJ0NCg0KKGEpICAgIE11c3QgbG9nIHdoYXQgZXhhY3RseT8NCg0KKGIpICAgSSBk b27igJl0IHRoaW5rIGl0IGlzIGdvb2QgcHJhY3RpY2UgdG8gbG9nIHNvbWV0aGluZyBmb3IgZXZl cnkgcGFja2V0IHJlY2VpdmVkLiBXaGF0IGlzIHJlcXVpcmVkIGlzIG5vdCBsb2dnaW5nLCByYXRo ZXIgY291bnRpbmcuDQoNCihjKSAgICBCZXR0ZXIgdG8gbWFrZSB0aGlzIOKAnOKApiBhbmQgU0hP VUxEIHByb3ZpZGUgZGlhZ25vc3RpY3Mu4oCdID8NCg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikN ClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA4LCAyMDE2IDE6MDEgUE0NClRvOiBzZmNAaWV0Zi5v cmcNClN1YmplY3Q6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQv MjENCg0KRGVhciBTRkMgV0c6DQoNCkFmdGVyIG11Y2ggZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB3 aXRoIHJlZ2FyZCB0byB0aWNrZXQgIzIxIHRoZSBmb2xsb3dpbmcgdGV4dCBoYXMgYmVlbiBwcm9w b3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNzIGFuZCBzbyBmb3J0aC4gUGxl YXNlIHJldmlldyBhbmQgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90KSBzbyB0aGF0IHRoZSBjaGFp cnMgY2FuIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHVwZGF0ZSB0aGUgdGlja2V0IGFjY29yZGlu Z2x5Lg0KDQpUaGFuayB5b3UhDQoNCkppbSAmIEpvZWwNCg0KIyMjIyMjIyMjIw0KDQpORVcgZm9y IHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3Vt cHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBm aWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1 cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuDQoNCkFuIFNGQy1hd2FyZSBT RiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNzIGZpcnN0IGluIG9yZGVyIHRvIHByb2Nl c3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4gIFRoZSBk YXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24gc2NoZW1hIGFuZCB0aGUg bWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRo ZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRp b24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZD LWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0 IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlIG1hbmRhdG9y eSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1Qg bG9nIHRoaXMgZXJyb3IuDQoNCltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2Ft cGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0YSBjb252ZXll ZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuDQoNCk5FVyBmb3IgZW5kIG9mIHNlY3Rp b24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlv biBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhh dCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVzZSBjb25zaWRlcmF0aW9ucyBhcmUgZGVw bG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250cm9sIHBsYW5lIGNhbiBpbnN0cnVj dCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJlIG9mIFRMVnMgdG9nZXRoZXIg d2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBvZiBbSS1ELmlldGYtc2ZjLWNv bnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRv IGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGlu IHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tl dCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KSWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXBy b2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFu ZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBvcmRlciB0byBjb25zdW1l IHRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3 YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5DQphcHBlYXIg aW4gdGhlIE5TSCBwYWNrZXQuDQoNCklmIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBU TFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0 aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1Qg cHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0K --_000_E8355113905631478EFF04F5AA706E983115472Fwtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUt bmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTYzMTI3NzI1NDsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTkwOTg5NTkwMiAxOTE5MDA0MzggNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiJcKCUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JbiBzZXZlcmFsIHBsYWNlcywgdGhlIHRleHQgc2F5cywg4oCc4oCmIGFuZCBN VVNUIGxvZyB0aGlzIGVycm9yLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+KGEpPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXVzdCBsb2cgd2hhdCBleGFjdGx5PzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+KGIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0 IHRoaW5rIGl0IGlzIGdvb2QgcHJhY3RpY2UgdG8gbG9nIHNvbWV0aGluZyBmb3IgZXZlcnkgcGFj a2V0IHJlY2VpdmVkLiBXaGF0IGlzIHJlcXVpcmVkIGlzIG5vdCBsb2dnaW5nLCByYXRoZXIgY291 bnRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4oYyk8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5CZXR0ZXIgdG8gbWFrZSB0aGlzIOKAnOKApiBhbmQgU0hPVUxEIHByb3ZpZGUg ZGlhZ25vc3RpY3Mu4oCdID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KaW0g R3VpY2hhcmQgKGpndWljaGFyKTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAw OCwgMjAxNiAxOjAxIFBNPGJyPg0KPGI+VG86PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtp dC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGVhciBTRkMg V0c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtp dC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QWZ0ZXIgbXVj aCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IHdpdGggcmVnYXJkIHRvIHRpY2tldCAjMjEgdGhlIGZv bGxvd2luZyB0ZXh0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGhlbHAgY2xhcmlmeSBtZXRhZGF0YSBz ZW1hbnRpY3MgYW5kIHNvIGZvcnRoLiBQbGVhc2UgcmV2aWV3DQogYW5kIGluZGljYXRlIHN1cHBv cnQgKG9yIG5vdCkgc28gdGhhdCB0aGUgY2hhaXJzIGNhbiBkZXRlcm1pbmUgY29uc2Vuc3VzIGFu ZCB1cGRhdGUgdGhlIHRpY2tldCBhY2NvcmRpbmdseS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SmltICZhbXA7IEpvZWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4jIyMjIyMjIyMjPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TkVXIGZvciBzZWN0aW9uIDMuNDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+OjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgc3BlY2lmaWNhdGlvbiBk b2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0 aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5v dCBkZXNjcmliZSB0aGUgc3RydWN0dXJlDQogb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0 YWRhdGEuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNzIGZpcnN0IGlu IG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4 dCBmaWVsZC4mbmJzcDsmbmJzcDtUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoDQogdGhl IGFsbG9jYXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4g SG93IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQs IGlmIHRoZSBTRkMtYXdhcmUgU0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBt ZXRhZGF0YSBidXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIGZvciB0 aGUNCiBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFj a2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxl IGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0YSBjb252ZXllZCBp biB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+TkVXIGZvciBlbmQgb2Ygc2VjdGlvbiAzLjUuMTwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtp dC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgbWFuZGF0 b3J5LXRvLWltcGxlbWVudCBvciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4m bmJzcDsmbmJzcDtUaGVzZSBjb25zaWRlcmF0aW9ucyBhcmUNCiBkZXBsb3ltZW50LXNwZWNpZmlj LiZuYnNwOyZuYnNwO0hvd2V2ZXIsIHRoZSBjb250cm9sIHBsYW5lIGNhbiBpbnN0cnVjdCBTRkMt YXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJlIG9mIFRMVnMgdG9nZXRoZXIgd2l0aCB0 aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBvZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wt cGxhbmVdKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDst d2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5VcG9u IHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFu ZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMt YXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0DQogYW5kIE1VU1QgbG9nIHRoaXMg ZXJyb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SWYgbXVs dGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4g U0ZQLCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRo IHRoZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuJm5ic3A7Jm5ic3A7SWYNCiBubyBpbnN0 cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVz ZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+YXBwZWFyIGluIHRoZSBOU0ggcGFj a2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIG11bHRp cGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNr ZXQsIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQs IHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2Vzcw0KIHRoZSBwYWNrZXQgYW5kIE1VU1Qg bG9nIHRoaXMgZXJyb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E8355113905631478EFF04F5AA706E983115472Fwtlexchp2sandvi_-- From nobody Tue Nov 8 14:07:57 2016 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 C90ED129464 for ; Tue, 8 Nov 2016 14:07: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, 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 Xh_u3h8UJN_C for ; Tue, 8 Nov 2016 14:07:53 -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 5876C12943C for ; Tue, 8 Nov 2016 13:59:45 -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 uA8LxeJm004380; Tue, 8 Nov 2016 21:59:40 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA8Lxc45004367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 8 Nov 2016 21:59:39 GMT From: "Adrian Farrel" To: "'Dave Dolson'" , "'Jim Guichard \(jguichar\)'" , References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> In-Reply-To: Date: Tue, 8 Nov 2016 21:59:37 -0000 Message-ID: <05ab01d23a0b$6639f010$32add030$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05AC_01D23A0B.663CD640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLPRbTHsOQmTK0hylcDpm24VzucmwF/8NkinsmLm2A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22688.003 X-TM-AS-Result: No--16.576-10.0-31-10 X-imss-scan-details: No--16.576-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCa0OJ7qQIs8+LdprnA5EQRoprEeoZHCQKZX93ioyYcx2rr AGyO72KP+H5zDDs0S2q1DFouV/G2T5/yorkJXkCF6/xAZojbl7c026H7nOZLr9r10nvSulUKR3l PPm80k3sb7ifYusSVqaAKXXLlJCb1r9Xz9yCPONJ8Uw4r8ep8BmEF8bGZ0cKCMxVjmK1sOgMGk2 pTPAu+9/LcU4VI+9cs5ca8Qs7DHSB/+iognrDBocRS0pbiOfKbCI3p+Ju8mqr4JyR+b5tvoBuZz KYuzZD8833+dZf8lepkWiwb8D86imKztShDQzFu71Wx2uUbPLdDr8MVm6DK3TA4N9SXuYkp/hkB Sy3LYQ2q/r7ujTTNh4sWCfP6Gmv5dbSgks66AoGPVEZA4HZW+f0ZphLMH+yHol3uZzZ1GLegSjO tq5sfafHqAX4A3hCO4F7lBGYh+K8/Btxv8I1Q6XC8PJ2EFS7IIBcsXIuEvlbkZ1myTXKoFyqh5c Uye3iVIm6fKcuFyK8oR0K3DJ8mwtZXwwpvfhGVFlT/KggLyj0lWygvtTclwFj/amLs8rQSADRMo ifoBfkzmpYx+UKjh3C2KyYp/H7vWYqLLUX2mAu6kMgL3jbYOtMxD/3e8TxdRtqpRW8sWyJqRyrZ EAcpymQpArkdH4Ik6uAmoYaXRSAh3ud9DyO68ORw69tAYXNGl2F9+KxZd8cno0smd1GLZPbd6Km nTTHRMcaFYqwxgsi5lJgO2YMTulsMw6s/MEEafxzygoxuBhiSiza26cvwNLslj/J76NnPu8iyJC yNt6l2+AZuxakJy3inb860CrQowPo8GP7TYNueAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyIzqx6Dt fVZtgDaKM/bqKGRK2jCyNeDpjjLqYpj0oRlu5KwWRJMLYdDapDgqVAniJRVboRnPTdKBeJHLbno hBRKqXJdh3GJ+HmhQC79j/XIIRQxj+tlv7/y Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 08 Nov 2016 22:07:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05AC_01D23A0B.663CD640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dave is right. =20 "MUST log" would be a DoS vector. =20 Adrian =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: 08 November 2016 19:05 To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 =20 In several places, the text says, =E2=80=9C=E2=80=A6 and MUST log this = error.=E2=80=9D (a) Must log what exactly? (b) I don=E2=80=99t think it is good practice to log something for = every packet received. What is required is not logging, rather counting. (c) Better to make this =E2=80=9C=E2=80=A6 and SHOULD provide = diagnostics.=E2=80=9D ? =20 =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard = (jguichar) Sent: Tuesday, November 08, 2016 1:01 PM To: sfc@ietf.org Subject: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 =20 Dear SFC WG: =20 After much discussion on the list with regard to ticket #21 the = following text has been proposed to help clarify metadata semantics and = so forth. Please review and indicate support (or not) so that the chairs = can determine consensus and update the ticket accordingly.=20 =20 Thank you! =20 Jim & Joel =20 ########## =20 NEW for section 3.4: 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. =20 =20 An SFC-aware SF MUST receive the data semantics first in order to = process the data placed in the mandatory context field. The data = semantics include both the allocation schema and the meaning of the = included data. How an SFC-aware SF gets the data semantics is outside = the scope of this specification. =20 Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is = configured for mandatory use of metadata but has not yet received the = data semantics for the mandatory context field, it MUST NOT process the = packet and MUST log this error. =20 [dcalloc] and [broadalloc] provide sample examples to associate a = meaning with the data conveyed in the mandatory context field. =20 NEW for end of section 3.5.1: 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 can = 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]). =20 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 this error. =20 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 they appear in the NSH packet. =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 this error. ------=_NextPart_000_05AC_01D23A0B.663CD640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dave is = right.

 

"MUST log" would be = a DoS vector.

 

Adrian

 

From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Dave = Dolson
Sent: 08 November 2016 19:05
To: Jim Guichard = (jguichar); sfc@ietf.org
Subject: Re: [sfc] = https://trac.ietf.org/trac/sfc/ticket/21

 

In several places, the text says, = =E2=80=9C=E2=80=A6 and MUST log this = error.=E2=80=9D

(a)    = Must log what = exactly?

(b)   = I don=E2=80=99t think it is good practice to = log something for every packet received. What is required is not = logging, rather counting.

(c)    = Better to make this =E2=80=9C=E2=80=A6 and = SHOULD provide diagnostics.=E2=80=9D ?

 

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim = Guichard (jguichar)
Sent: Tuesday, November 08, 2016 1:01 = PM
To: sfc@ietf.org
Subject: [sfc] = https://trac.ietf.org/trac/sfc/ticket/21

 

<= p class=3DMsoNormal>Dear SFC = WG:

 

After much discussion on the list with = regard to ticket #21 the following text has been proposed to help = clarify metadata semantics and so forth. Please review and indicate = support (or not) so that the chairs can determine consensus and update = the ticket accordingly. 

 

Thank = you!

 

Jim & = Joel

 

##########

<= p class=3DMsoNormal> 

NEW for section 3.4:

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.  

 

An SFC-aware SF MUST receive the data = semantics first in order to process the data placed in the mandatory = context field.  The data semantics include both the allocation = schema and the meaning of the included data. How an SFC-aware SF gets = the data semantics is outside the scope of this = specification.

 

Upon receiving an NSH MD-type 1 packet, if = the SFC-aware SF is configured for mandatory use of metadata but has not = yet received the data semantics for the mandatory context field, it MUST = NOT process the packet and MUST log this = error.

 

[dcalloc] and [broadalloc] provide sample = examples to associate a meaning with the data conveyed in the mandatory = context field.

 

NEW for end of section = 3.5.1:

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 can 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 this = error.

 

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 = they

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 this = error.

------=_NextPart_000_05AC_01D23A0B.663CD640-- From nobody Tue Nov 8 15:52:15 2016 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 D3FE9129690 for ; Tue, 8 Nov 2016 15:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 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=-1.497, 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 BNHohONHxM6o for ; Tue, 8 Nov 2016 15:52:11 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E5F12968D for ; Tue, 8 Nov 2016 15:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21844; q=dns/txt; s=iport; t=1478649131; x=1479858731; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/kR4NURIK5CDaPF5VBLYiwzYTWKDyorIceG35J+gT3o=; b=NfgFsYSYbhFYPBMPe2dFJ15z83P+0+kfE2ZHqca8l8p5M3KuFnUSBTGq w2BWy89hKN6dm3kA2RdkHsC49XcF4wFAA3PFssJWnERsc0ociXZhsazTi bcrA2Tr70EJJ+i65lJOWZFLHWVWSEKj/eGlCh4HKxgPVU9oo/o4Qk28r4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQClYiJY/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy8BAQEBAR9YfweNMpcGlFOCBQMeC4V7AoILPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRhAQEBBAEBARcgNBcEAgEIEQEDAQEfCQcnCxQDBggCBAESCBOIQQ60T4tLA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHIoQgQWETzGFKAWEC4REi36FYgGGNYMLhwC?= =?us-ascii?q?BdYgthXmHMoV+hAUBHjd6G4MWHBiBRXIBhi2BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,611,1473120000"; d="scan'208";a="346171552" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2016 23:52:10 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA8NqASl020631 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Nov 2016 23:52:10 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 8 Nov 2016 17:52:09 -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; Tue, 8 Nov 2016 17:52:09 -0600 From: "Surendra Kumar (smkumar)" To: Lucy yong , Dave Dolson , "Ron Parker" , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAADZdUAAACdzjAAAgn8gAADIGIYP//oKGAgABj5qD//9QdgP//AL7g Date: Tue, 8 Nov 2016 23:52:09 +0000 Message-ID: <272aae8ff8d0458a9862369a1af33951@XCH-RCD-020.cisco.com> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> <9a1019fe979f498492669e1f044160d5@XCH-RCD-020.cisco.com> , <6cd477a406e24f62b0af2f059f853da0@XCH-RCD-020.cisco.com> <20161107231144.5697621.14742.117688@sandvine.com> <6ba68e971db14db583bac0b6d70e5080@XCH-RCD-020.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D572EA443@dfweml501-mbb> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572EA443@dfweml501-mbb> 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.33.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 08 Nov 2016 23:52:14 -0000 Hi Lucy, See comments inline. -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Monday, November 07, 2016 6:32 PM To: Surendra Kumar (smkumar) ; Dave Dolson ; Ron Parker ; adrian@olddog.co.u= k; 'Joel M. Halpern' ; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Surendra, "2. Allow the decrement to be anything other than 'one', as per CP policy." I am not sure what SFC use case demands this implementation.=20 SK> we talked about a couple. It is better not to preclude other/future imp= lementations, just the same way there exists '8-bits' for SI. As an example= , are there use cases with service chains that long, right now ? Having one rule to set SI value (i.e. SF decrements by one) provides clear = and simple implementation in which SFs do not need to maintain "decrement v= alue" state per a SPI basis, which is great benefit for implementation and = operation.=20 SK> It can be made even easier by having SFs NOT do anything with SI, exten= ding the benefit you bring up. SK> Moreover, this is a non-default behavior. Thanks, Surendra. I prefer not adding this complexity to NSH.=20 Regards, Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkuma= r) Sent: Monday, November 07, 2016 5:23 PM To: Dave Dolson; Ron Parker; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ie= tf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, It is very misleading to say is not a forwarding state. It is fal= se to say "source routing" unless you mean entire SFC is a source-route, be= cause it is already fully specified. Then, why not have SFC (architecture) go from CF to SF to SF ... and not ha= ve the SFF demarcation, over dumb forwarders/infrastructure? Surendra. -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Monday, November 07, 2016 3:12 PM To: Surendra Kumar (smkumar) ; Ron Parker ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sfc@ietf.org Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Surendra, I think it is misleading to imply SFs need to be programmed to decrement SI= by 1. This behavior can be (and should be, IMO) hard-coded. Furthermore, t= here is not any extra "forwarding state". So it is false to say that decrementing the SI in the SFF is easier to conf= igure. In fact it is harder to configure due to the source routing requirem= ents mentioned earlier. -Dave Original Message From: Surendra Kumar (smkumar) Sent: Monday, November 7, 2016 6:02 PM To: Ron Parker; Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ie= tf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I am afraid we will spiral on this one. It is not complicated, but only makes it simpler by having SFF manage the f= orwarding while SF deliver the service. I would imagine there would be less number of SFFs to program (the forwardi= ng state) than SFs, to start with. And SFs do not have to deal with forward= ing state. If we would like to remove the lines between the SF and the SFF, the SFC ar= chitecture can do away with SFF. Surendra. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, November 07, 2016 2:55 PM To: Surendra Kumar (smkumar) ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I think #1 could be complicated in practice, since you need coordination be= tween all SFFs and SFs as to whose responsibility it is to perform the decr= ement. I'd prefer to stick with the default as the sole solution rather t= han introduce this complexity. Regarding #2, I think it is fine for an SF= to decrement by more than 1, thereby deciding to skip over subsequent SF(s= ). I'm also ok saying that an SF that does that is also behaving as a cla= ssifier. Ron -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Monday, November 7, 2016 5:50 PM To: Ron Parker ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Ron, As Adrian proposed and as I already agreed to, default behavior is ok as lo= ng as we are not precluding sophisticated implementations. Two changes being sought, both does not affect the default behavior: 1. Allow SFFs and only SFFs to manage the , while having the defaul= t behavior of what it is now 2. Allow the decrement to be anything other th= an 'one', as per CP policy I think you agree with this. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, November 07, 2016 9:51 AM To: Dave Dolson ; Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, I agree with your conclusion. Decrementing SI at SFF requires the From fi= eld in its forwarding table/logic. That being said, I'm not opposed to making SI decrement an SFF responsibili= ty, with an acknowledgement of the above consequence. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, November 7, 2016 12:35 PM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding. Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with an SPI and SI for which it does not have forwarding state, it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in Section 4. 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. > > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. > > > > > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. > > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. > > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. > > Thanks, > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Adrian, > Thank you for paraphrasing in a clear manner. > > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF" > or "from SF" > is not as simple as checking ingress interface, for example. > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) > > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. > > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > Is that your point? > > Cheers, > Adrian > > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 8 21:43:32 2016 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 5B19212955E for ; Tue, 8 Nov 2016 21:43:31 -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 VMxUIMvn5xJ3 for ; Tue, 8 Nov 2016 21:43:28 -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 1BD34129479 for ; Tue, 8 Nov 2016 21:43:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0151D241139; Tue, 8 Nov 2016 21:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478670208; bh=lCwhQLCjcNglChvI5bxmaawU/IktAW2H4uNqsW4tylU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ez5EOsHqtqbupyebeujdMtKgvI96OFwF9viUbpZx11aaVIfgbBnQYLDrYJe/ISkga SvXClHoBwUinn8BcPMC+Ivfls/cIYbMa7g/rp8dz5GY5iSjVbazzuqVsX0r5CNZwLr i/U3cI+kG4rCo72UFE3ezmoXNonsnRhGid9lmshg= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [12.238.14.250]) (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 B7744240CCD; Tue, 8 Nov 2016 21:43:27 -0800 (PST) To: Dave Dolson , "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 9 Nov 2016 00:43:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.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] https://trac.ietf.org/trac/sfc/ticket/21 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, 09 Nov 2016 05:43:31 -0000 I think I understand your point. At the same time, without a log entry it will be next to impossible to determine what arriving value caused the drop. In this context, that ability seems important, but I could be missing something. Yours, Joel On 11/8/16 2:05 PM, Dave Dolson wrote: > In several places, the text says, 搮 and MUST log this error. > > (a) Must log what exactly? > > (b) I don抰 think it is good practice to log something for every > packet received. What is required is not logging, rather counting. > > (c) Better to make this 搮 and SHOULD provide diagnostics. ? > > > > > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* Tuesday, November 08, 2016 1:01 PM > *To:* sfc@ietf.org > *Subject:* [sfc] https://trac.ietf.org/trac/sfc/ticket/21 > > > > Dear SFC WG: > > > > After much discussion on the list with regard to ticket #21 the > following text has been proposed to help clarify metadata semantics and > so forth. Please review and indicate support (or not) so that the chairs > can determine consensus and update the ticket accordingly. > > > > Thank you! > > > > Jim & Joel > > > > ########## > > > > *NEW for section 3.4*: > > 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. > > > > An SFC-aware SF MUST receive the data semantics first in order to > process the data placed in the mandatory context field. The data > semantics include both the allocation schema and the meaning of the > included data. How an SFC-aware SF gets the data semantics is outside > the scope of this specification. > > > > Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is > configured for mandatory use of metadata but has not yet received the > data semantics for the mandatory context field, it MUST NOT process the > packet and MUST log this error. > > > > [dcalloc] and [broadalloc] provide sample examples to associate a > meaning with the data conveyed in the mandatory context field. > > > > *NEW for end of section 3.5.1*: > > 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 can > 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 this error. > > > > 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 they > > 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 this error. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Nov 8 22:12:46 2016 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 331691295C6 for ; Tue, 8 Nov 2016 22:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.096 X-Spam-Level: X-Spam-Status: No, score=-4.096 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_H2=-0.001, RP_MATCHES_RCVD=-1.497, 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 17kYYcD60Gtk for ; Tue, 8 Nov 2016 22:12:43 -0800 (PST) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D76129479 for ; Tue, 8 Nov 2016 22:12:43 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id D2939180629; Wed, 9 Nov 2016 07:12:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id A61244006D; Wed, 9 Nov 2016 07:12:41 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0319.002; Wed, 9 Nov 2016 07:12:41 +0100 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSOeoddhBvoux3dU2uL7kFD+H1LqDQLIaw Date: Wed, 9 Nov 2016 06:12:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DAE70C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> In-Reply-To: <3C851841-3FC8-430B-93BE-E96C63B8EC55@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_787AE7BB302AE849A7480A190F8B933009DAE70COPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 09 Nov 2016 06:12:45 -0000 --_000_787AE7BB302AE849A7480A190F8B933009DAE70COPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLCBhbGwsDQoNCkkgc3VwcG9ydCB0aGlzIGNoYW5nZS4NCg0KQ2hlZXJzLA0KTWVkDQoN CkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmlt IEd1aWNoYXJkIChqZ3VpY2hhcikNCkVudm95w6kgOiBtYXJkaSA4IG5vdmVtYnJlIDIwMTYgMTk6 MDENCsOAIDogc2ZjQGlldGYub3JnDQpPYmpldCA6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL3NmYy90aWNrZXQvMjENCg0KRGVhciBTRkMgV0c6DQoNCkFmdGVyIG11Y2ggZGlzY3Vz c2lvbiBvbiB0aGUgbGlzdCB3aXRoIHJlZ2FyZCB0byB0aWNrZXQgIzIxIHRoZSBmb2xsb3dpbmcg dGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNz IGFuZCBzbyBmb3J0aC4gUGxlYXNlIHJldmlldyBhbmQgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90 KSBzbyB0aGF0IHRoZSBjaGFpcnMgY2FuIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHVwZGF0ZSB0 aGUgdGlja2V0IGFjY29yZGluZ2x5Lg0KDQpUaGFuayB5b3UhDQoNCkppbSAmIEpvZWwNCg0KIyMj IyMjIyMjIw0KDQpORVcgZm9yIHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMg bm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBt YW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRl c2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEu DQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNzIGZpcnN0 IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29u dGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRp b24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93IGFuIFNG Qy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBv ZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEg cGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1 c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGlj cyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRo ZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQoNCltkY2FsbG9jXSBhbmQgW2Jyb2Fk YWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0 aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuDQoNCk5F VyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg bWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBs ZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVzZSBjb25z aWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250cm9s IHBsYW5lIGNhbiBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJl IG9mIFRMVnMgdG9nZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBv ZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9mIGEgcGFj a2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNz IFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9U IHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KSWYgbXVsdGlw bGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQ LCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRo ZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHBy b3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBv cmRlciB0aGV5DQphcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuDQoNCklmIG11bHRpcGxlIGluc3Rh bmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0 aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMt YXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVy cm9yLg0K --_000_787AE7BB302AE849A7480A190F8B933009DAE70COPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAu ODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+SGkgSmltLCBhbGwsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgc3VwcG9ydCB0 aGlzIGNoYW5nZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5N ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gSmltIEd1aWNoYXJkIChqZ3VpY2hhcik8YnI+ DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkgOCBub3ZlbWJyZSAyMDE2IDE5OjAxPGJyPg0K PGI+w4AmbmJzcDs6PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtz ZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgU0ZDIFdHOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFmdGVyIG11Y2ggZGlzY3Vzc2lv biBvbiB0aGUgbGlzdCB3aXRoIHJlZ2FyZCB0byB0aWNrZXQgIzIxIHRoZSBmb2xsb3dpbmcgdGV4 dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNzIGFu ZCBzbyBmb3J0aC4gUGxlYXNlIHJldmlldw0KIGFuZCBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3Qp IHNvIHRoYXQgdGhlIGNoYWlycyBjYW4gZGV0ZXJtaW5lIGNvbnNlbnN1cyBhbmQgdXBkYXRlIHRo ZSB0aWNrZXQgYWNjb3JkaW5nbHkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+VGhhbmsgeW91ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkppbSAmYW1wOyBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+IyMjIyMjIyMjIzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFr ZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9y eSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUg dGhlIHN0cnVjdHVyZQ0KIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLiAmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0 LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbiBTRkMtYXdh cmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBw cm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuJm5i c3A7Jm5ic3A7VGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aA0KIHRoZSBhbGxvY2F0aW9u IHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMt YXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZD LWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0 IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlDQogbWFuZGF0 b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVT VCBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0 byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRh dG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg bWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBs ZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7 VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlDQogZGVwbG95bWVudC1zcGVjaWZpYy4mbmJzcDsmbmJz cDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3 aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGlu ZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFu ZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9m IGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1w cm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1V U1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldA0KIGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3Rh bmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIG1hbmRh dG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNv bnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIg dG8gY29uc3VtZSB0aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmDQogbm8gaW5zdHJ1Y3Rpb25zIGFy ZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0 aGUgb3JkZXIgdGhleTxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PG86cD48L286cD48L3Nw YW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBpbnN0YW5j ZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhl IGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3 YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVy cm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933009DAE70COPEXCLILMA3corp_-- From nobody Wed Nov 9 00:21:38 2016 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 9F44A1296C1 for ; Wed, 9 Nov 2016 00:21: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, 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 7sRdkhdhEvGV for ; Wed, 9 Nov 2016 00:21:35 -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 3FBDF1294C4 for ; Wed, 9 Nov 2016 00:21:34 -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 uA98LT3O016167; Wed, 9 Nov 2016 08:21:29 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA98LSWL016152 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 9 Nov 2016 08:21:29 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , "'Dave Dolson'" , "'Jim Guichard \(jguichar\)'" , References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> In-Reply-To: Date: Wed, 9 Nov 2016 08:21:27 -0000 Message-ID: <063b01d23a62$44f63d80$cee2b880$@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: AQLPRbTHsOQmTK0hylcDpm24VzucmwF/8NkiAtOz5xies5sx8A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22688.006 X-TM-AS-Result: No--23.939-10.0-31-10 X-imss-scan-details: No--23.939-10.0-31-10 X-TMASE-MatchedRID: vbSD0OnL8/Ka0OJ7qQIs81CIU02oW+3VZhJeJk69iY/HDN5dgHIXhsLm p4jPUF8tRFsqph676uAXEaT5uhkwzF0ieHN50/kHQ1OcCEvT+bfWSrKtwxqWpSG8WMGwsRk0dmu 5Abn/U/vDxdTxsvNP0sRI5qv0fQC1n/KiuQleQIXr/EBmiNuXtzTbofuc5kuv2vXSe9K6VQpHeU 8+bzSTexvuJ9i6xJWpoApdcuUkJvWv1fP3II840nxTDivx6nwGYQXxsZnRwoIzFWOYrWw6AwaTa lM8C7738txThUj71yzlxrxCzsMdIH/6KiCesMGhxFLSluI58psIjen4m7yaqvgnJH5vm2+gG5nM pi7NkPzzff51l/yV6mRaLBvwPzqKYrO1KENDMW6puD25aEtgt0GV2YNiPCWm51ONI4UL++qjxYy RBa/qJX3mXSdV7KK4WKD2QKkwR8ILbigRnpKlKT4yqD4LKu3A Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 09 Nov 2016 08:21:36 -0000 I think the usual formulation is "SHOULD log and MUST apply rate limiting to any logging" A > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 09 November 2016 05:43 > To: Dave Dolson; Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 > > I think I understand your point. > At the same time, without a log entry it will be next to impossible to > determine what arriving value caused the drop. In this context, that > ability seems important, but I could be missing something. > > Yours, > Joel > > On 11/8/16 2:05 PM, Dave Dolson wrote: > > In several places, the text says, ". and MUST log this error." > > > > (a) Must log what exactly? > > > > (b) I don't think it is good practice to log something for every > > packet received. What is required is not logging, rather counting. > > > > (c) Better to make this ". and SHOULD provide diagnostics." ? > > > > > > > > > > > > > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > > (jguichar) > > *Sent:* Tuesday, November 08, 2016 1:01 PM > > *To:* sfc@ietf.org > > *Subject:* [sfc] https://trac.ietf.org/trac/sfc/ticket/21 > > > > > > > > Dear SFC WG: > > > > > > > > After much discussion on the list with regard to ticket #21 the > > following text has been proposed to help clarify metadata semantics and > > so forth. Please review and indicate support (or not) so that the chairs > > can determine consensus and update the ticket accordingly. > > > > > > > > Thank you! > > > > > > > > Jim & Joel > > > > > > > > ########## > > > > > > > > *NEW for section 3.4*: > > > > 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. > > > > > > > > An SFC-aware SF MUST receive the data semantics first in order to > > process the data placed in the mandatory context field. The data > > semantics include both the allocation schema and the meaning of the > > included data. How an SFC-aware SF gets the data semantics is outside > > the scope of this specification. > > > > > > > > Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is > > configured for mandatory use of metadata but has not yet received the > > data semantics for the mandatory context field, it MUST NOT process the > > packet and MUST log this error. > > > > > > > > [dcalloc] and [broadalloc] provide sample examples to associate a > > meaning with the data conveyed in the mandatory context field. > > > > > > > > *NEW for end of section 3.5.1*: > > > > 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 can > > 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 this error. > > > > > > > > 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 they > > > > 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 this error. > > > > > > > > _______________________________________________ > > 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 Wed Nov 9 04:02:40 2016 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 C3F24129C15 for ; Wed, 9 Nov 2016 04:02:39 -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, 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 DsAzc8dI2qNf for ; Wed, 9 Nov 2016 04:02:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74ED7129C11 for ; Wed, 9 Nov 2016 04:02:37 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 916883B4588; Wed, 9 Nov 2016 13:02:35 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6B78A27C078; Wed, 9 Nov 2016 13:02:35 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Wed, 9 Nov 2016 13:02:35 +0100 From: To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , 'Dave Dolson' , "'Jim Guichard (jguichar)'" , "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQLPRbTHsOQmTK0hylcDpm24VzucmwF/8NkiAtOz5xies5sx8IAAKFfw Date: Wed, 9 Nov 2016 12:02:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DAE87A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> <063b01d23a62$44f63d80$cee2b880$@olddog.co.uk> In-Reply-To: <063b01d23a62$44f63d80$cee2b880$@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.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.9.111517 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 09 Nov 2016 12:02:40 -0000 Hi Adrian, all, I do prefer the "MUST log .." wording because it is critical to detect when= a mandatory piece is missing to deliver the service. The proposed text is about SFC-aware SFs. If the attack vector is a DoS, it= is likely that the border nodes/classifiers will be the first victims. Imp= lementing measures to protect against DoS at the boundaries would be a firs= t guard.=20 If the DoS is from within the SFC domain, despite this is a valid threat ve= ctor and misbehaving nodes may happen (software bugs, etc.), I thought the = security model of NSH assumes that all involved nodes are trusted.=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > Envoy=E9=A0: mercredi 9 novembre 2016 09:21 > =C0=A0: 'Joel M. Halpern'; 'Dave Dolson'; 'Jim Guichard (jguichar)'; > sfc@ietf.org > Objet=A0: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 >=20 > I think the usual formulation is "SHOULD log and MUST apply rate limiting > to any > logging" >=20 > A >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: 09 November 2016 05:43 > > To: Dave Dolson; Jim Guichard (jguichar); sfc@ietf.org > > Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 > > > > I think I understand your point. > > At the same time, without a log entry it will be next to impossible to > > determine what arriving value caused the drop. In this context, that > > ability seems important, but I could be missing something. > > > > Yours, > > Joel > > > > On 11/8/16 2:05 PM, Dave Dolson wrote: > > > In several places, the text says, ". and MUST log this error." > > > > > > (a) Must log what exactly? > > > > > > (b) I don't think it is good practice to log something for every > > > packet received. What is required is not logging, rather counting. > > > > > > (c) Better to make this ". and SHOULD provide diagnostics." ? > > > > > > > > > > > > > > > > > > > > > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > > > (jguichar) > > > *Sent:* Tuesday, November 08, 2016 1:01 PM > > > *To:* sfc@ietf.org > > > *Subject:* [sfc] https://trac.ietf.org/trac/sfc/ticket/21 > > > > > > > > > > > > Dear SFC WG: > > > > > > > > > > > > After much discussion on the list with regard to ticket #21 the > > > following text has been proposed to help clarify metadata semantics > and > > > so forth. Please review and indicate support (or not) so that the > chairs > > > can determine consensus and update the ticket accordingly. > > > > > > > > > > > > Thank you! > > > > > > > > > > > > Jim & Joel > > > > > > > > > > > > ########## > > > > > > > > > > > > *NEW for section 3.4*: > > > > > > 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. > > > > > > > > > > > > An SFC-aware SF MUST receive the data semantics first in order to > > > process the data placed in the mandatory context field. The data > > > semantics include both the allocation schema and the meaning of the > > > included data. How an SFC-aware SF gets the data semantics is outside > > > the scope of this specification. > > > > > > > > > > > > Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is > > > configured for mandatory use of metadata but has not yet received the > > > data semantics for the mandatory context field, it MUST NOT process > the > > > packet and MUST log this error. > > > > > > > > > > > > [dcalloc] and [broadalloc] provide sample examples to associate a > > > meaning with the data conveyed in the mandatory context field. > > > > > > > > > > > > *NEW for end of section 3.5.1*: > > > > > > 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 > can > > > 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 this error. > > > > > > > > > > > > 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 they > > > > > > 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 this error. > > > > > > > > > > > > _______________________________________________ > > > 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 Wed Nov 9 05:39:08 2016 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 9B402129978 for ; Wed, 9 Nov 2016 05:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 jqp1VC8_WxCI for ; Wed, 9 Nov 2016 05:39:03 -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 31BD51294DD for ; Wed, 9 Nov 2016 05:38:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAA73491; Wed, 09 Nov 2016 13:38:55 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 13:38:54 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 05:38:51 -0800 From: Lucy yong To: "Surendra Kumar (smkumar)" , Dave Dolson , Ron Parker , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI0q6STRZCLqSXLQzOUvbtSwnTj2AAsommAAO9OjoAADZdUAAACdzjAAAxY1AAAAD4jgAAAV5+AAABj/AAAC2NKwAAn7IiAAAabykA= Date: Wed, 9 Nov 2016 13:38:50 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572EBE49@dfweml501-mbb> References: <02e601d234ab$b69648c0$23c2da40$@olddog.co.uk> <0c152b3eda0241dfb2f79e072d477cb9@XCH-RCD-020.cisco.com> <9a1019fe979f498492669e1f044160d5@XCH-RCD-020.cisco.com> , <6cd477a406e24f62b0af2f059f853da0@XCH-RCD-020.cisco.com> <20161107231144.5697621.14742.117688@sandvine.com> <6ba68e971db14db583bac0b6d70e5080@XCH-RCD-020.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D572EA443@dfweml501-mbb> <272aae8ff8d0458a9862369a1af33951@XCH-RCD-020.cisco.com> In-Reply-To: <272aae8ff8d0458a9862369a1af33951@XCH-RCD-020.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.582326F0.003D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6b977752ec0574a36fad9d81e6f456d7 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 09 Nov 2016 13:39:07 -0000 Surendra, See inline. -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=20 Sent: Tuesday, November 08, 2016 5:52 PM To: Lucy yong; Dave Dolson; Ron Parker; adrian@olddog.co.uk; 'Joel M. Halpe= rn'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Lucy, See comments inline. -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Monday, November 07, 2016 6:32 PM To: Surendra Kumar (smkumar) ; Dave Dolson ; Ron Parker ; adrian@olddog.co.u= k; 'Joel M. Halpern' ; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Surendra, "2. Allow the decrement to be anything other than 'one', as per CP policy." I am not sure what SFC use case demands this implementation.=20 SK> we talked about a couple. It is better not to preclude other/future imp= lementations, just the same way there exists '8-bits' for SI. As an example= , are there use cases with service chains that long, right now ? [Lucy] "It is better not to preclude other/future implementations", that is= not always better. IMO: A protocol is to preclude some other implementatio= ns. No desire to debate on this. Having one rule to set SI value (i.e. SF decrements by one) provides clear = and simple implementation in which SFs do not need to maintain "decrement v= alue" state per a SPI basis, which is great benefit for implementation and = operation.=20 SK> It can be made even easier by having SFs NOT do anything with SI, exten= ding the benefit you bring up. [Lucy] As Dave mentioned, people had quite debates on whether SF or SFF sho= uld decrement SI value and the WG agreed to let SI doing it.=20 SK> Moreover, this is a non-default behavior. [Lucy] supporting multiple behavior introduces complex. Unless the use case= s require that, no need to introduce complexity. Lucy=20 Thanks, Surendra. I prefer not adding this complexity to NSH.=20 Regards, Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkuma= r) Sent: Monday, November 07, 2016 5:23 PM To: Dave Dolson; Ron Parker; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ie= tf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, It is very misleading to say is not a forwarding state. It is fal= se to say "source routing" unless you mean entire SFC is a source-route, be= cause it is already fully specified. Then, why not have SFC (architecture) go from CF to SF to SF ... and not ha= ve the SFF demarcation, over dumb forwarders/infrastructure? Surendra. -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Monday, November 07, 2016 3:12 PM To: Surendra Kumar (smkumar) ; Ron Parker ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sfc@ietf.org Subject: Re: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Surendra, I think it is misleading to imply SFs need to be programmed to decrement SI= by 1. This behavior can be (and should be, IMO) hard-coded. Furthermore, t= here is not any extra "forwarding state". So it is false to say that decrementing the SI in the SFF is easier to conf= igure. In fact it is harder to configure due to the source routing requirem= ents mentioned earlier. -Dave Original Message From: Surendra Kumar (smkumar) Sent: Monday, November 7, 2016 6:02 PM To: Ron Parker; Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ie= tf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I am afraid we will spiral on this one. It is not complicated, but only makes it simpler by having SFF manage the f= orwarding while SF deliver the service. I would imagine there would be less number of SFFs to program (the forwardi= ng state) than SFs, to start with. And SFs do not have to deal with forward= ing state. If we would like to remove the lines between the SF and the SFF, the SFC ar= chitecture can do away with SFF. Surendra. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, November 07, 2016 2:55 PM To: Surendra Kumar (smkumar) ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] I think #1 could be complicated in practice, since you need coordination be= tween all SFFs and SFs as to whose responsibility it is to perform the decr= ement. I'd prefer to stick with the default as the sole solution rather t= han introduce this complexity. Regarding #2, I think it is fine for an SF= to decrement by more than 1, thereby deciding to skip over subsequent SF(s= ). I'm also ok saying that an SF that does that is also behaving as a cla= ssifier. Ron -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Monday, November 7, 2016 5:50 PM To: Ron Parker ; Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Hi Ron, As Adrian proposed and as I already agreed to, default behavior is ok as lo= ng as we are not precluding sophisticated implementations. Two changes being sought, both does not affect the default behavior: 1. Allow SFFs and only SFFs to manage the , while having the defaul= t behavior of what it is now 2. Allow the decrement to be anything other th= an 'one', as per CP policy I think you agree with this. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, November 07, 2016 9:51 AM To: Dave Dolson ; Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joel M. Halpern' ; sf= c@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Dave, I agree with your conclusion. Decrementing SI at SFF requires the From fi= eld in its forwarding table/logic. That being said, I'm not opposed to making SI decrement an SFF responsibili= ty, with an acknowledgement of the above consequence. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, November 7, 2016 12:35 PM To: Surendra Kumar (smkumar) ; adrian@olddog.co.uk; 'Joe= l M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] Surendra, When you would have the Service Function not modify the Service Index, can = you explain how the SFF is configured to discriminate between the two cases= in this example? 1. NSH packet arrives from another SFF with SPI=3D10 and SI=3D255 (requires= forwarding to SF1) 2. NSH packet arrives from SF1 with SPI=3D10 and SI=3D2= 55 (already serviced) Is it fair to say that there is a source-routing input to the SFF decision,= adding an new "From" column to the table of https://tools.ietf.org/html/dr= aft-ietf-sfc-nsh-10#section-7.1 ? +-------------------------------------------------------------------+ | FROM | SPI | SI | Next hop(s) | Transport | +-------------------------------------------------------------------+ | SFF1 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | +-------------------------------------------------------------------+ | 192.0.2.1 | 10 | 255 | 198.51.100.10 | GRE | +-------------------------------------------------------------------+ ... +-------------------------------------------------------------------+ -Dave -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 02, 2016 7:38 PM To: adrian@olddog.co.uk; Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org Subject: RE: OK. Enough with the looping (spiralling :-) [Was: decrementing= service function path index] Adrian, This is a very good compromise. Completely agree on "Not preclude sophistic= ated implementations" and IMO it is crucial to go beyond legacy forwarding = methods and allow for, not only flexible implementations as you note, but a= lso for use-case evolution/innovation. While I agree with the default behavior of SF decrementing by 1, in additio= n to allowing for it to be decremented by a configured value, I would like = that to be extended to explicitly include a decrement value of zero (no dec= rement). So, I support your modified verbiage below to allow for a decremen= t value of *ZERO*. This allows for control-plane/configuration dictated behavior and is flexib= le enough to support different methods of forwarding. Surendra. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 01, 2016 6:52 PM To: 'Dave Dolson' ; Surendra Kumar (smkumar) ; 'Joel M. Halpern' ; sfc@ietf.org Subject: OK. Enough with the looping (spiralling :-) [Was: decrementing ser= vice function path index] Been thinking about this instead of sleeping. Keep getting caught in rat-holes that say "no, but you could build product = like this." But they are real rat-holes. What we need is a set of rule that= work for simple implementations *and* that do not preclude more sophistica= ted implementations. So... When a packet arrives at an SFF the SPI/SI indicates the SFP and the next h= op on that SFP to be executed. When an SF has finished processing a packet the default behavior is to leav= e the SPI unchanged and to decrement the SI by 1. SK> Firstly, why even have SI However, and SF MAY know to make other changes to a the SPI and SI. How tha= t knowledge is installed in the SF is implementation dependent: - it may be the result of configuration (for example, normally decrement by 1 but in event of a specific condition forward to a different chain) - it may be the result of a policy and visibility of the SFP - it may be based on information in the metadata - there may be unicorns There may be a classifier co-resident with the SF or in the path from SF ba= ck to SFF so that the SPI/SI received by the SFF is not a simple decrement = of the SI. SK> Yes, absolutely. If SFs have co-located classifiers, they can restart a= chain or adjust the SI, all based on policy dictated by a higher level ent= ity. There may be a classifier co-resident with the SFF that processes the packe= t before the SFF performs forwarding so that the SPI/SI received by the SFF= is not a simple decrement of the SI. The SFF's routing lookup may give it a choice of SFIs or SFFs to which to s= end the packet for the given SPI/SI. How it resolves this choice is a local= matter (some policy that might be load balancing and could be influenced b= y any manner of things if an implementation chooses without prejudice to th= e interoperability of replaceability of SFFs). The fact of the choice is a = function of how the network has been built, and how SFIs have been assigned= , and how the SFPs have been constructed by the controller - it is not a fu= nction of the NSH itself. The SFF's forwarding instructions can be simple (look up SPI/SI and send th= e packet out of interface X encapsulated in tunnel Y) or more complex (make= some form of choice and manipulate the packet) just as in most other moder= n forwarding paradigms. An SFF that does not recognise the SPI/SI (i.e., has no forwarding state fo= r it) can only (read MUST) drop the packet. What forwarding state an SFF has is a matter of: - implementation - control/management plane instructions - visibility into the SFP (and other SFPs) I believe this set of rules is consistent with 7665 and also supports what = the WG wanted to achieve with the NSH draft without requiring any limitatio= n on processing. That is, a simple implementation as envisaged by the propo= nents of "MUST decrement by one" is able to perform that function and still= be conformant and interoperable. Similarly, a simple SFF as suggested in t= his thread would have no problems interoperating. Similarly, this behavior is flexible enough to allow for other uses and imp= lementations. It is consistent with draft-mackie-bess-nsh-bgp-control-plane (indeed, that draft doesn't tell the SF what to do with the SPI/SI at all) = and allows a control plane to program an SFF to do more sophisticated thing= s. Of course, if the SFF cannot do those things then that will be OK since = it won't support those control plane instructions. Can we put this to bed with the minimal change to draft-ietf-sfc-nsh-10 sec= tion 4 as follows: OLD 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. NEW 3. Update NSH: NSH-aware service functions (SF) MUST decrement the service index. By default the SF decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. If an SFF receives a packet with an SPI and SI for which it does not have forwarding state, it MUST be drop the packet, and SHOULD log the event subject to rate limiting on such logs. END Similarly later in the same bullet... OLD 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. NEW 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. By default the SFC Proxy decrements the SI by 1, but it MAY apply other decrements according to configuration and other information available to it. END Furthermore, in section 3.3 since the term "egress NSH packet" is either am= biguous or neglects the possibility of reclassification... OLD 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. NEW Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services as described in Section 4. 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. END Now perhaps I can sleep :-) Adrian > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: 01 November 2016 23:22 > To: Surendra Kumar (smkumar); adrian@olddog.co.uk; 'Joel M. Halpern';=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > I agree that the SF should be simple. > But don't confuse decrementing the SI with complexity. > There is absolutely no configuration required to have the SF decrement=20 > the SI of > every packet. > And there is a lot of benefit to keeping the SFF from having rules=20 > about packet > source. > > As far as I'm concerned, the SF decrements the SI, and it has been=20 > described this > way for a long time. Furthermore, the forwarding is described as a=20 > lookup table > based on SPI/SI. There is no mention of the source in the forwarding tabl= e. > > > > > Original Message > From: Surendra Kumar (smkumar) > Sent: Tuesday, November 1, 2016 7:03 PM > To: Dave Dolson; adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Since the forwarders already exists, they are logical components to=20 > support and > perform NSH based forwarding - forwarding on SFPs, rather than treat=20 > them as dumb forwarders. There is benefit to be had, offloads being=20 > one of them, on top > of end of chain forwarding, etc. needed. > > I would rather have SFs focus on servicing the traffic than be=20 > burdened with SPI > management (whether it is tens or thousands of SPIs) and the=20 > forwarding thereof. IOW, consume metadata and service traffic and=20 > leave the SFP management to the external forwarders. This not only=20 > simplifies the SFs, it also > reduces the control plane touch point as it concerns to the SPI managemen= t. > > And you don't need complex logic to differentiate between traffic=20 > received from > one SFF or a SF, this is what we addressed in the forwarding draft -=20 > trivial to > implement even in hardware. > > Thanks, > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, November 01, 2016 1:27 PM > To: adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Adrian, > Thank you for paraphrasing in a clear manner. > > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a > simple forwarder, not needing to discriminate between packets from=20 > another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 > > So it could tell the difference, but doesn't need to. > In some cases, an SFF can be a single-interface device, so "from SFF" > or "from SF" > is not as simple as checking ingress interface, for example. > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, November 01, 2016 4:00 PM > To: Dave Dolson; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > Just clarifying my understanding of what you said (not necessarily=20 > agreeing ;-) > > You are saying that an SFF is simply a forwarder and cannot tell the difference > between a packet received on a transport tunnel from another SFF and a=20 > packet received (back) from an SF that it serves. > > Or, more precisely, you are saying that the SFF is simply a forwarder=20 > that cannot tell the difference between passing a packet to a local SF=20 > and passing a > packet on to a remote SFF. > > And the SFF sees a packet n+1 times for an SFP with n local SFs. > > Is that your point? > > Cheers, > Adrian > > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: 01 November 2016 19:35 > > To: adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] decrementing service function path index > > > > The SF decrements the index so that the SFF doesn't have to look at=20 > > the packet > > origin in order to determine whether or not to decrement it. > > We don't want the SFF to have logic like: > > If NSH packet is from one of addresses x, y z > > Decrement SI > > > > As currently defined, the SFF simply routes packets by SPI/SI=20 > > without having > to > > do consider source address. > > > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 01, 2016 2:48 PM > > To: 'Joel M. Halpern'; sfc@ietf.org > > Subject: Re: [sfc] decrementing service function path index > > > > > With regard to the architectural components, the NSH draft does=20 > > > not define those. It is using the architectural, logical,=20 > > > components and architecture defined by the SFC Architecture documents= . > > > > I'd like to understand where in 7665 it says that the SF is=20 > > responsible for moving the packet on to the next SF in the path, rather= than the SFF. > > > > I'd also like to understand why the NSH document (that tells us how=20 > > to encapsulate, and what to do at each hop in the path) needs to=20 > > divide the responsibility for bits of protocol work between=20 > > different logical functional > > entities. In short, why does the SF decrement the SI, why isn't this=20 > > an SFF function? What benefit comes from doing it this way or did a=20 > > choice simply > have > > to be made? > > > > 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Nov 9 06:38:53 2016 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 C64271294BA for ; Wed, 9 Nov 2016 06:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 9OKsf7qu64_j for ; Wed, 9 Nov 2016 06:38:49 -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 B15081294D8 for ; Wed, 9 Nov 2016 06:38:49 -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; Wed, 9 Nov 2016 06:38:49 -0800 From: Ron Parker To: "mohamed.boucadair@orange.com" , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , 'Dave Dolson' , "'Jim Guichard (jguichar)'" , "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSOeoddhBvoux3dU2uL7kFD+H1LqDPcWVggAE5RwCAACwkgIAAPccA//+lRfA= Date: Wed, 9 Nov 2016 14:38:47 +0000 Message-ID: References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> <063b01d23a62$44f63d80$cee2b880$@olddog.co.uk> <787AE7BB302AE849A7480A190F8B933009DAE87A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAE87A@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: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 09 Nov 2016 14:38:52 -0000 Some have interpreted MUST log as on a per-packet basis. I interpreted it= more loosely. Perhaps we could say "MUST log in an appropriate manner...= " Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Wednesday, November 9, 2016 7:03 AM To: adrian@olddog.co.uk; 'Joel M. Halpern' ; 'Dave Dol= son' ; 'Jim Guichard (jguichar)' = ; sfc@ietf.org Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Hi Adrian, all, I do prefer the "MUST log .." wording because it is critical to detect when= a mandatory piece is missing to deliver the service. The proposed text is about SFC-aware SFs. If the attack vector is a DoS, it= is likely that the border nodes/classifiers will be the first victims. Imp= lementing measures to protect against DoS at the boundaries would be a firs= t guard.=20 If the DoS is from within the SFC domain, despite this is a valid threat ve= ctor and misbehaving nodes may happen (software bugs, etc.), I thought the = security model of NSH assumes that all involved nodes are trusted.=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel=20 > Envoy=E9=A0: mercredi 9 novembre 2016 09:21 =C0=A0: 'Joel M. Halpern'; 'D= ave=20 > Dolson'; 'Jim Guichard (jguichar)'; sfc@ietf.org Objet=A0: Re: [sfc]=20 > https://trac.ietf.org/trac/sfc/ticket/21 >=20 > I think the usual formulation is "SHOULD log and MUST apply rate=20 > limiting to any logging" >=20 > A >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: 09 November 2016 05:43 > > To: Dave Dolson; Jim Guichard (jguichar); sfc@ietf.org > > Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 > > > > I think I understand your point. > > At the same time, without a log entry it will be next to impossible=20 > > to determine what arriving value caused the drop. In this context,=20 > > that ability seems important, but I could be missing something. > > > > Yours, > > Joel > > > > On 11/8/16 2:05 PM, Dave Dolson wrote: > > > In several places, the text says, ". and MUST log this error." > > > > > > (a) Must log what exactly? > > > > > > (b) I don't think it is good practice to log something for every > > > packet received. What is required is not logging, rather counting. > > > > > > (c) Better to make this ". and SHOULD provide diagnostics." ? > > > > > > > > > > > > > > > > > > > > > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim=20 > > > Guichard > > > (jguichar) > > > *Sent:* Tuesday, November 08, 2016 1:01 PM > > > *To:* sfc@ietf.org > > > *Subject:* [sfc] https://trac.ietf.org/trac/sfc/ticket/21 > > > > > > > > > > > > Dear SFC WG: > > > > > > > > > > > > After much discussion on the list with regard to ticket #21 the=20 > > > following text has been proposed to help clarify metadata=20 > > > semantics > and > > > so forth. Please review and indicate support (or not) so that the > chairs > > > can determine consensus and update the ticket accordingly. > > > > > > > > > > > > Thank you! > > > > > > > > > > > > Jim & Joel > > > > > > > > > > > > ########## > > > > > > > > > > > > *NEW for section 3.4*: > > > > > > 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. > > > > > > > > > > > > An SFC-aware SF MUST receive the data semantics first in order to=20 > > > process the data placed in the mandatory context field. The data=20 > > > semantics include both the allocation schema and the meaning of=20 > > > the included data. How an SFC-aware SF gets the data semantics is=20 > > > outside the scope of this specification. > > > > > > > > > > > > Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is=20 > > > configured for mandatory use of metadata but has not yet received=20 > > > the data semantics for the mandatory context field, it MUST NOT=20 > > > process > the > > > packet and MUST log this error. > > > > > > > > > > > > [dcalloc] and [broadalloc] provide sample examples to associate a=20 > > > meaning with the data conveyed in the mandatory context field. > > > > > > > > > > > > *NEW for end of section 3.5.1*: > > > > > > This specification does not make any assumption about TLVs that=20 > > > are mandatory-to-implement or those that are mandatory-to-process. =20 > > > These considerations are deployment-specific. However, the=20 > > > control plane > can > > > instruct SFC-aware SFs with the data structure of TLVs together=20 > > > 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=20 > > > mandatory-to-process TLV is missing in that packet, the SFC-aware=20 > > > SF MUST NOT process the packet and MUST log this error. > > > > > > > > > > > > If multiple mandatory-to-process TLVs are required for a given=20 > > > SFP, > the > > > control plane MAY instruct the SFC-aware SF with the order to=20 > > > consume these TLVs. If no instructions are provided, the=20 > > > SFC-aware SF MUST process these TLVs in the order they > > > > > > appear in the NSH packet. > > > > > > > > > > > > If multiple instances of the same TLV are included in an NSH=20 > > > packet, > but > > > the definition of that TLV does not allow for it, the SFC-aware SF > MUST > > > NOT process the packet and MUST log this error. > > > > > > > > > > > > _______________________________________________ > > > 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 Wed Nov 9 07:12:56 2016 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 4685F129525 for ; Wed, 9 Nov 2016 07:12:54 -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=unavailable 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 23VfCTVHCRoM for ; Wed, 9 Nov 2016 07:12:50 -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 7A7A9129454 for ; Wed, 9 Nov 2016 07:03:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2C74E1C0C2B; Wed, 9 Nov 2016 07:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478703804; bh=RAj+VnrFM74FmtfOEIlRb1WaxZ+0s5B9pFVDyXEw1FI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WB1/kJGbCRbTFCBmsQjG9F+ngkGvdpulicLtB5PHEFU4qOfc99o9+cCsq2iQSTOfz fujxxr/anISrtO8x/7aXy3JzTpKHdW7meC/LZeKD/f3HJTvjuPQlZ8KRvFcuOVfUlN KSl+mfr+uzKOtfmoiB827i/nSPv30O+3AZ31zFFs= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [12.238.14.250]) (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 E015F1C012A; Wed, 9 Nov 2016 07:03:23 -0800 (PST) To: adrian@olddog.co.uk, 'Dave Dolson' , "'Jim Guichard (jguichar)'" , sfc@ietf.org References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> <063b01d23a62$44f63d80$cee2b880$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: <58f35afb-ebb6-65e7-9963-a45e5f885e4c@joelhalpern.com> Date: Wed, 9 Nov 2016 10:03:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <063b01d23a62$44f63d80$cee2b880$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 09 Nov 2016 15:12:54 -0000 That works for me. Yours, Joel On 11/9/16 3:21 AM, Adrian Farrel wrote: > I think the usual formulation is "SHOULD log and MUST apply rate limiting to any > logging" > > A > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: 09 November 2016 05:43 >> To: Dave Dolson; Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 >> >> I think I understand your point. >> At the same time, without a log entry it will be next to impossible to >> determine what arriving value caused the drop. In this context, that >> ability seems important, but I could be missing something. >> >> Yours, >> Joel >> >> On 11/8/16 2:05 PM, Dave Dolson wrote: >>> In several places, the text says, ". and MUST log this error." >>> >>> (a) Must log what exactly? >>> >>> (b) I don't think it is good practice to log something for every >>> packet received. What is required is not logging, rather counting. >>> >>> (c) Better to make this ". and SHOULD provide diagnostics." ? >>> >>> >>> >>> >>> >>> >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>> (jguichar) >>> *Sent:* Tuesday, November 08, 2016 1:01 PM >>> *To:* sfc@ietf.org >>> *Subject:* [sfc] https://trac.ietf.org/trac/sfc/ticket/21 >>> >>> >>> >>> Dear SFC WG: >>> >>> >>> >>> After much discussion on the list with regard to ticket #21 the >>> following text has been proposed to help clarify metadata semantics and >>> so forth. Please review and indicate support (or not) so that the chairs >>> can determine consensus and update the ticket accordingly. >>> >>> >>> >>> Thank you! >>> >>> >>> >>> Jim & Joel >>> >>> >>> >>> ########## >>> >>> >>> >>> *NEW for section 3.4*: >>> >>> 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. >>> >>> >>> >>> An SFC-aware SF MUST receive the data semantics first in order to >>> process the data placed in the mandatory context field. The data >>> semantics include both the allocation schema and the meaning of the >>> included data. How an SFC-aware SF gets the data semantics is outside >>> the scope of this specification. >>> >>> >>> >>> Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is >>> configured for mandatory use of metadata but has not yet received the >>> data semantics for the mandatory context field, it MUST NOT process the >>> packet and MUST log this error. >>> >>> >>> >>> [dcalloc] and [broadalloc] provide sample examples to associate a >>> meaning with the data conveyed in the mandatory context field. >>> >>> >>> >>> *NEW for end of section 3.5.1*: >>> >>> 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 can >>> 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 this error. >>> >>> >>> >>> 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 they >>> >>> 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 this error. >>> >>> >>> >>> _______________________________________________ >>> 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 Wed Nov 9 11:04:33 2016 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 6C35F129559 for ; Wed, 9 Nov 2016 11:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 FGTg4huYC-n3 for ; Wed, 9 Nov 2016 11:04: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 D6239129643 for ; Wed, 9 Nov 2016 11:04:01 -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 DAB17060; Wed, 09 Nov 2016 19:03:59 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 19:03:58 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 11:03:55 -0800 From: Lucy yong To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSOeoddhBvoux3dU2uL7kFD+H1LqDRAmMQ Date: Wed, 9 Nov 2016 19:03:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572EC085@dfweml501-mbb> References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> In-Reply-To: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.19] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D572EC085dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5823731F.00E5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fd99cc6355449e692f473decfb5b35ff Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 09 Nov 2016 19:04:08 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D572EC085dfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGZvbGxvd2luZyB0ZXh0IGZvciB0aGUgc2VjdGlvbnMgYW5kIGFncmVlIHRoYXQg c29tZSBtaW5vciB0d2VhayBpcyBuZWNlc3NhcnkgdG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0KDQpU aGFua3MsDQpMdWN5DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNClNlbnQ6IFR1ZXNkYXksIE5vdmVt YmVyIDA4LCAyMDE2IDEyOjAxIFBNDQpUbzogc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBbc2ZjXSBo dHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxDQoNCkRlYXIgU0ZDIFdHOg0K DQpBZnRlciBtdWNoIGRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0 ICMyMSB0aGUgZm9sbG93aW5nIHRleHQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5 IG1ldGFkYXRhIHNlbWFudGljcyBhbmQgc28gZm9ydGguIFBsZWFzZSByZXZpZXcgYW5kIGluZGlj YXRlIHN1cHBvcnQgKG9yIG5vdCkgc28gdGhhdCB0aGUgY2hhaXJzIGNhbiBkZXRlcm1pbmUgY29u c2Vuc3VzIGFuZCB1cGRhdGUgdGhlIHRpY2tldCBhY2NvcmRpbmdseS4NCg0KVGhhbmsgeW91IQ0K DQpKaW0gJiBKb2VsDQoNCiMjIyMjIyMjIyMNCg0KTkVXIGZvciBzZWN0aW9uIDMuNDoNClRoaXMg c3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250 ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFk ZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhl IGluY2x1ZGVkIG1ldGFkYXRhLg0KDQpBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBk YXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBp biB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuICBUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVk ZSBib3RoIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1 ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9uIHJlY2Vpdmlu ZyBhbiBOU0ggTUQtdHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1 cmVkIGZvciBtYW5kYXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZl ZCB0aGUgZGF0YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQg TVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpb ZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3Nv Y2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBj b250ZXh0IGZpZWxkLg0KDQpORVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xOg0KVGhpcyBzcGVj aWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFy ZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1w cm9jZXNzLiAgVGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuICBI b3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRo IHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAo U2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuDQoNClVw b24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBt YW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNG Qy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMg ZXJyb3IuDQoNCklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVp cmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBT RkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiAgSWYgbm8g aW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3Mg dGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleQ0KYXBwZWFyIGluIHRoZSBOU0ggcGFja2V0Lg0K DQpJZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBh biBOU0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxs b3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBh bmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg== --_000_2691CE0099834E4A9C5044EEC662BB9D572EC085dfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAw IDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10YWIt c3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IHN1cHBvcnQgZm9sbG93aW5nIHRleHQgZm9yIHRoZSBzZWN0aW9ucyBhbmQgYWdyZWUgdGhhdCBz b21lIG1pbm9yIHR3ZWFrIGlzIG5lY2Vzc2FyeSB0byBtYWtlIGl0IG1vcmUgY2xlYXIuPG86cD48 L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkx1Y3k8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KaW0gR3VpY2hhcmQgKGpn dWljaGFyKTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNiAxMjow MSBQTTxicj4NCjxiPlRvOjwvYj4gc2ZjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtz ZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgU0ZDIFdHOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFmdGVyIG11Y2ggZGlzY3Vzc2lv biBvbiB0aGUgbGlzdCB3aXRoIHJlZ2FyZCB0byB0aWNrZXQgIzIxIHRoZSBmb2xsb3dpbmcgdGV4 dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNzIGFu ZCBzbyBmb3J0aC4gUGxlYXNlIHJldmlldw0KIGFuZCBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3Qp IHNvIHRoYXQgdGhlIGNoYWlycyBjYW4gZGV0ZXJtaW5lIGNvbnNlbnN1cyBhbmQgdXBkYXRlIHRo ZSB0aWNrZXQgYWNjb3JkaW5nbHkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+VGhhbmsgeW91ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkppbSAmYW1wOyBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+IyMjIyMjIyMjIzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFr ZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9y eSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUg dGhlIHN0cnVjdHVyZQ0KIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLiAmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0 LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbiBTRkMtYXdh cmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBw cm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuJm5i c3A7Jm5ic3A7VGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aA0KIHRoZSBhbGxvY2F0aW9u IHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMt YXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZD LWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0 IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlDQogbWFuZGF0 b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVT VCBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0 byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRh dG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg bWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBs ZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7 VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlDQogZGVwbG95bWVudC1zcGVjaWZpYy4mbmJzcDsmbmJz cDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3 aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGlu ZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFu ZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9m IGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1w cm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1V U1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldA0KIGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3Rh bmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIG1hbmRh dG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNv bnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIg dG8gY29uc3VtZSB0aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmDQogbm8gaW5zdHJ1Y3Rpb25zIGFy ZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0 aGUgb3JkZXIgdGhleTxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PG86cD48L286cD48L3Nw YW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBpbnN0YW5j ZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhl IGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3 YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVy cm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_2691CE0099834E4A9C5044EEC662BB9D572EC085dfweml501mbb_-- From nobody Wed Nov 9 18:45:27 2016 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 1D1971298AC; Wed, 9 Nov 2016 18:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.697 X-Spam-Level: X-Spam-Status: No, score=-105.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 oWLPZcxufu7h; Wed, 9 Nov 2016 18:45:23 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DBBFE1298D5; Wed, 9 Nov 2016 18:45:19 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 7B2AE3E04683E; Thu, 10 Nov 2016 10:45:15 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 16BF89DDA8FF0; Thu, 10 Nov 2016 10:45:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uAA2ixGE099377; Thu, 10 Nov 2016 10:44:59 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> To: "Jim Guichard (jguichar)" MIME-Version: 1.0 X-KeepSent: 42D1BD34:BA000303-48258066:00353444; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.cui1@zte.com.cn Date: Thu, 10 Nov 2016 10:45:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-11-10 10:44:59, Serialize complete at 2016-11-10 10:44:59 Content-Type: multipart/alternative; boundary="=_alternative 000F1BBC48258067_=" X-MAIL: mse01.zte.com.cn uAA2ixGE099377 Archived-At: Cc: sfc , "sfc@ietf.org" Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 02:45:26 -0000 This is a multipart message in MIME format. --=_alternative 000F1BBC48258067_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBKaW0gJiBKb2VsLA0KDQogICBUaGUgdGV4dCBzYWlkOiAndGhlIGRhdGEgc2VtYW50aWNz IGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgDQphbmQgdGhlIG1lYW5pbmcgb2Yg dGhlIGluY2x1ZGVkIGRhdGEuJyANCiAgIEkgYWdyZWUgd2l0aCAndGhlIGFsbG9jYXRpb24gc2No ZW1hJyBjYW4gaGVscCB0aGUgU0ZDLWF3YXJlIFNGIHRvIGtub3cgDQpob3cgdG8gaW50ZXJwcmV0 IHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4gSG93ZXZlciwNCiAgIENvdWxkIHlvdSBjbGFy aWZ5IHdoYXQgaXMgJ3RoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhJyBhbmQgaG93IHRv IA0KZGVzY3JpYmUnIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhJz8gDQoNCiAgIFRo YW5rcyB2ZXJ5IG11Y2ggOikNCg0KQlJzDQpMaW5kYSBXYW5nDQogDQoNCg0KIA0KDQoNCg0KIkpp bSBHdWljaGFyZCAoamd1aWNoYXIpIiA8amd1aWNoYXJAY2lzY28uY29tPiANCreivP7IyzogICJz ZmMiIDxzZmMtYm91bmNlc0BpZXRmLm9yZz4NCjIwMTYvMTEvMDkgMDI6MDENCg0KytW8/sjLDQoi c2ZjQGlldGYub3JnIiA8c2ZjQGlldGYub3JnPiwgDQqzrcvNDQoNCtb3zOINCltzZmNdIGh0dHBz Oi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCg0KDQoNCg0KDQoNCkRlYXIgU0ZD IFdHOg0KDQpBZnRlciBtdWNoIGRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8g dGlja2V0ICMyMSB0aGUgZm9sbG93aW5nIA0KdGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxw IGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNzIGFuZCBzbyBmb3J0aC4gDQpQbGVhc2UgcmV2aWV3 IGFuZCBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIHNvIHRoYXQgdGhlIGNoYWlycyBjYW4gDQpk ZXRlcm1pbmUgY29uc2Vuc3VzIGFuZCB1cGRhdGUgdGhlIHRpY2tldCBhY2NvcmRpbmdseS4gDQoN ClRoYW5rIHlvdSENCg0KSmltICYgSm9lbA0KDQojIyMjIyMjIyMjDQoNCk5FVyBmb3Igc2VjdGlv biAzLjQ6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBh Ym91dCB0aGUgY29udGVudCBwbGFjZWQgDQppbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQg b2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmliZSANCnRoZSBzdHJ1Y3R1cmUg b3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuIA0KDQpBbiBTRkMtYXdhcmUgU0Yg TVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNz IA0KdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4gIFRoZSBk YXRhIHNlbWFudGljcyANCmluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRo ZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiANCkhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0 cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyANCnNwZWNp ZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0 aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgDQpmb3IgbWFuZGF0b3J5IHVzZSBvZiBtZXRh ZGF0YSBidXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIA0KZm9yIHRo ZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0 IGFuZCBNVVNUIA0KbG9nIHRoaXMgZXJyb3IuDQoNCltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2Nd IHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgDQp3aXRoIHRo ZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCg0KTkVXIGZv ciBlbmQgb2Ygc2VjdGlvbiAzLjUuMToNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtl IGFueSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgDQptYW5kYXRvcnktdG8taW1wbGVt ZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiAgVGhlc2UgDQpjb25z aWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250cm9s IHBsYW5lIGNhbiANCmluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1 cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIA0Kc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4z LjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuDQoNClVwb24gcmVjZWlwdCBvZiBh IHBhY2tldCB0aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSANCm1hbmRhdG9yeS10by1w cm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1V U1QgDQpOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpJ ZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBn aXZlbiBTRlAsIHRoZSANCmNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUg U0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSANCnRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVj dGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgDQpwcm9jZXNzIHRoZXNl IFRMVnMgaW4gdGhlIG9yZGVyIHRoZXkgYXBwZWFyIGluIHRoZSBOU0ggcGFja2V0Lg0KDQpJZiBt dWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0gg cGFja2V0LCBidXQgDQp0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBm b3IgaXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCANCk5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5k IE1VU1QgbG9nIHRoaXMgZXJyb3IuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoNCg== --=_alternative 000F1BBC48258067_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkRlYXIgSmltICZhbXA7IEpvZWwsPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7VGhlIHRl eHQgc2FpZDogJ3RoZSBkYXRhIHNlbWFudGljcw0KaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0aW9u IHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuJw0KPC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7SSBhZ3JlZSB3aXRo ICd0aGUgYWxsb2NhdGlvbg0Kc2NoZW1hJyBjYW4gaGVscCB0aGUgU0ZDLWF3YXJlIFNGIHRvIGtu b3cgaG93IHRvIGludGVycHJldCB0aGUgbWFuZGF0b3J5DQpjb250ZXh0IGZpZWxkLiBIb3dldmVy LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO0Nv dWxkIHlvdSBjbGFyaWZ5IHdoYXQgaXMNCid0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0 YScgYW5kIGhvdyB0byBkZXNjcmliZScgdGhlIG1lYW5pbmcgb2YNCnRoZSBpbmNsdWRlZCBkYXRh Jz8gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDsg Jm5ic3A7VGhhbmtzIHZlcnkgbXVjaCA6KTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0iQ2FsaWJyaSI+QlJzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJp Ij5MaW5kYSBXYW5nPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJz cDsgPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPiZxdW90O0ppbSBHdWljaGFyZCAoamd1aWNoYXIpJnF1b3Q7DQombHQ7amd1aWNoYXJA Y2lzY28uY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj63orz+yMs6ICZuYnNwOyZxdW90O3NmYyZxdW90OyAmbHQ7c2ZjLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYvMTEv MDkgMDI6MDE8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+JnF1b3Q7c2ZjQGlldGYub3JnJnF1b3Q7ICZsdDtzZmNAaWV0Zi5vcmcmZ3Q7LA0K PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5bc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxPC9mb250Pjwv dGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxl Pg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPkRlYXIgU0ZDIFdH OjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+QWZ0ZXIgbXVjaCBkaXNjdXNzaW9uIG9u IHRoZSBsaXN0IHdpdGggcmVnYXJkIHRvIHRpY2tldA0KIzIxIHRoZSBmb2xsb3dpbmcgdGV4dCBo YXMgYmVlbiBwcm9wb3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNzDQphbmQg c28gZm9ydGguIFBsZWFzZSByZXZpZXcgYW5kIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgc28g dGhhdCB0aGUgY2hhaXJzDQpjYW4gZGV0ZXJtaW5lIGNvbnNlbnN1cyBhbmQgdXBkYXRlIHRoZSB0 aWNrZXQgYWNjb3JkaW5nbHkuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+VGhhbmsg eW91ITwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+SmltICZhbXA7IEpvZWw8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPiMjIyMjIyMjIyM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yPjxiPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L2I+OjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJv dXQNCnRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2Yg dGhlIE5TSCBoZWFkZXIsIGFuZA0KZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBvciBt ZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4gJm5ic3A7PC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9Mj5BbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFu dGljcyBmaXJzdA0KaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1h bmRhdG9yeSBjb250ZXh0IGZpZWxkLiAmbmJzcDtUaGUNCmRhdGEgc2VtYW50aWNzIGluY2x1ZGUg Ym90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZQ0KaW5jbHVk ZWQgZGF0YS4gSG93IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBv dXRzaWRlIHRoZQ0Kc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTI+VXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlm IHRoZSBTRkMtYXdhcmUNClNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0 YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkDQp0aGUgZGF0YSBzZW1hbnRpY3MgZm9yIHRo ZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2Vzcw0KdGhlIHBhY2tl dCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y PltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvDQph c3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9y eSBjb250ZXh0IGZpZWxkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PGI+TkVXIGZv ciBlbmQgb2Ygc2VjdGlvbiAzLjUuMTwvYj46PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj5UaGlz IHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dA0KVExWcyB0 aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9y eS10by1wcm9jZXNzLg0KJm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQt c3BlY2lmaWMuICZuYnNwO0hvd2V2ZXIsIHRoZQ0KY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3Qg U0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzDQp0b2dldGhlciB3 aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtY29u dHJvbC1wbGFuZV0pLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+VXBvbiByZWNlaXB0 IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZg0KYSBtYW5kYXRvcnkt dG8tcHJvY2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBT Rg0KTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+SWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXBy b2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yDQphIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxh bmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXINCnRvIGNvbnN1 bWUgdGhlc2UgVExWcy4gJm5ic3A7SWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhl IFNGQy1hd2FyZQ0KU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRoZXkg YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+ SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4NCmFu IE5TSCBwYWNrZXQsIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxv dyBmb3IgaXQsIHRoZQ0KU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBh bmQgTVVTVCBsb2cgdGhpcyBlcnJvci48L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxp c3Q8YnI+DQpzZmNAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250 IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 000F1BBC48258067_=-- From nobody Thu Nov 10 05:15:38 2016 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 0290012953F; Thu, 10 Nov 2016 05:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 OUXIGTav9DmU; Thu, 10 Nov 2016 05:15:35 -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 37E9412962B; Thu, 10 Nov 2016 05:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16414; q=dns/txt; s=iport; t=1478783734; x=1479993334; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fiojpU0zLNUKviMYCVg3W3NK/cre/ygwKe3MLsRgPTE=; b=cCNZmpsxmTDcHDoO+BUQVnWBMxCigc5l6E+fsb8q92yV4mSIVk47R0ii OdsCnQOqSesoREv6xW3GmShcOxftTYujv0a9sl33DjaPeKmcD7maaA2Ej SbyWUFYqVMfUWSr6+CX5dLee+eRouOEhDJ44l20EQGp9apWL0uedoUIqk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQDbcSRY/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnM9AQEBAQEfWH8HjTaXC489hRuCBx4BCoV7AhqCCj8UAQIBAQE?= =?us-ascii?q?BAQEBYh0LhGEBAQEEAQEBIEQHCxACAQYCEQMBAigDAgICJQsUCQgCBA4FiF8Ok?= =?us-ascii?q?mOdRYJAi0MBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYY+gX0IglWBPQGCeicJFoJ?= =?us-ascii?q?OLYIwBZRUhWMBhjiDDocMgW6EdIgPgSuHN4YFhAYBHjeBAByDHw0PMIEtcocLg?= =?us-ascii?q?QwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,619,1473120000"; d="scan'208,217";a="173363075" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2016 13:15:33 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uAADFWDC032767 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Nov 2016 13:15:32 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 07:15:32 -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, 10 Nov 2016 07:15:32 -0600 From: "Jim Guichard (jguichar)" To: "wang.cui1@zte.com.cn" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSOeoddhBvoux3dU2uL7kFD+H1LqDR6b4AgABcOAA= Date: Thu, 10 Nov 2016 13:15:32 +0000 Message-ID: <9C8B3B99-1938-4B49-844F-C65F53A48725@cisco.com> References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_9C8B3B9919384B49844FC65F53A48725ciscocom_" MIME-Version: 1.0 Archived-At: Cc: sfc , "sfc@ietf.org" Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 13:15:37 -0000 --_000_9C8B3B9919384B49844FC65F53A48725ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGluZGEsDQoNCkJ5IHRoaXMgd2UgbWVhbiBob3cgdGhlIFNGIGlzIHRvIGludGVycHJldCB0 aGUgZGF0YSBjYXJyaWVkIHdpdGhpbiB0aGUgbWV0YWRhdGEuIEZvciBleGFtcGxlLCB0aGUgYWxs b2NhdGlvbiBzY2hlbWEgbWlnaHQgc2F5IOKAnHRlbmFudC1pZCBjYXJyaWVkIGF0IG9mZnNldCA8 YmxhaD7igKbigJ0gYnV0IHRoZW4gdGhlIFNGIG5lZWRzIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUg ZXh0cmFjdGVkIHZhbHVlIGZyb20gdGhlIG1ldGFkYXRhIGNvcnJlc3BvbmRzIHRvIGluIHRlcm1z IG9mIHdoaWNoIHRlbmFudCBlLmcuIHZhbHVlIDEwMSBtaWdodCBtZWFuIOKAnGNva2XigJ0uIOKA nGNva2XigJ0gaW4gdGhpcyBleGFtcGxlIGlzIG5vdCBjYXJyaWVkIHdpdGhpbiB0aGUgbWV0YWRh dGEgc28gdGhlIFNGIG5lZWRzIHRvIG1hcCB0aGUgdmFsdWUgZnJvbSB0aGUgbWV0YWRhdGEgdG8g YSBtZWFuaW5nZnVsIHRlbmFudCBpZGVudGlmaWNhdGlvbi4NCg0KSG9wZSB0aGlzIGNsYXJpZmll cyAuLg0KDQpKaW0NCg0KRnJvbTogIndhbmcuY3VpMUB6dGUuY29tLmNuPG1haWx0bzp3YW5nLmN1 aTFAenRlLmNvbS5jbj4iIDx3YW5nLmN1aTFAenRlLmNvbS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0 ZS5jb20uY24+Pg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciA5LCAyMDE2IGF0IDk6NDUgUE0N ClRvOiBKaW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lz Y28uY29tPj4NCkNjOiAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Piwgc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzZmNdIGh0dHBzOi8v dHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCg0KRGVhciBKaW0gJiBKb2VsLA0KDQog ICBUaGUgdGV4dCBzYWlkOiAndGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxs b2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLicNCiAg IEkgYWdyZWUgd2l0aCAndGhlIGFsbG9jYXRpb24gc2NoZW1hJyBjYW4gaGVscCB0aGUgU0ZDLWF3 YXJlIFNGIHRvIGtub3cgaG93IHRvIGludGVycHJldCB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmll bGQuIEhvd2V2ZXIsDQogICBDb3VsZCB5b3UgY2xhcmlmeSB3aGF0IGlzICd0aGUgbWVhbmluZyBv ZiB0aGUgaW5jbHVkZWQgZGF0YScgYW5kIGhvdyB0byBkZXNjcmliZScgdGhlIG1lYW5pbmcgb2Yg dGhlIGluY2x1ZGVkIGRhdGEnPw0KDQogICBUaGFua3MgdmVyeSBtdWNoIDopDQoNCkJScw0KTGlu ZGEgV2FuZw0KDQoNCg0KDQoNCg0KIkppbSBHdWljaGFyZCAoamd1aWNoYXIpIiA8amd1aWNoYXJA Y2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0K5Y+R5Lu25Lq6OiAgInNmYyIg PHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+DQoNCjIw MTYvMTEvMDkgMDI6MDENCg0KDQrmlLbku7bkuroNCiAgICAgICAgInNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4sDQrm ioTpgIENCg0K5Li76aKYDQogICAgICAgIFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L3NmYy90aWNrZXQvMjENCg0KDQoNCg0KDQoNCg0KRGVhciBTRkMgV0c6DQoNCkFmdGVyIG11Y2gg ZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB3aXRoIHJlZ2FyZCB0byB0aWNrZXQgIzIxIHRoZSBmb2xs b3dpbmcgdGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2Vt YW50aWNzIGFuZCBzbyBmb3J0aC4gUGxlYXNlIHJldmlldyBhbmQgaW5kaWNhdGUgc3VwcG9ydCAo b3Igbm90KSBzbyB0aGF0IHRoZSBjaGFpcnMgY2FuIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHVw ZGF0ZSB0aGUgdGlja2V0IGFjY29yZGluZ2x5Lg0KDQpUaGFuayB5b3UhDQoNCkppbSAmIEpvZWwN Cg0KIyMjIyMjIyMjIw0KDQpORVcgZm9yIHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9u IGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGlu IHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMg bm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0 YWRhdGEuDQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNz IGZpcnN0IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRv cnkgY29udGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFs bG9jYXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93 IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10 eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRh dG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNl bWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9j ZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQoNCltkY2FsbG9jXSBhbmQg W2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5p bmcgd2l0aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQu DQoNCk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9l cyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10 by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVz ZSBjb25zaWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBj b250cm9sIHBsYW5lIGNhbiBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3Ry dWN0dXJlIG9mIFRMVnMgdG9nZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAz LjMuMyBvZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9m IGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1w cm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1V U1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KSWYg bXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2 ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3 aXRoIHRoZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMg YXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGlu IHRoZSBvcmRlciB0aGV5IGFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUg aW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwg YnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhl IFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRo aXMgZXJyb3IuX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K --_000_9C8B3B9919384B49844FC65F53A48725ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <94E4B2C64BCDB449A4976E86CA039C03@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkhpIExpbmRhLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QnkgdGhpcyB3ZSBt ZWFuIGhvdyB0aGUgU0YgaXMgdG8gaW50ZXJwcmV0IHRoZSBkYXRhIGNhcnJpZWQgd2l0aGluIHRo ZSBtZXRhZGF0YS4gRm9yIGV4YW1wbGUsIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBtaWdodCBzYXkg 4oCcdGVuYW50LWlkIGNhcnJpZWQgYXQgb2Zmc2V0ICZsdDtibGFoJmd0O+KApuKAnSBidXQgdGhl biB0aGUgU0YgbmVlZHMgdG8gdW5kZXJzdGFuZCB3aGF0IHRoZSBleHRyYWN0ZWQgdmFsdWUgZnJv bSB0aGUgbWV0YWRhdGEgY29ycmVzcG9uZHMNCiB0byBpbiB0ZXJtcyBvZiB3aGljaCB0ZW5hbnQg ZS5nLiB2YWx1ZSAxMDEgbWlnaHQgbWVhbiDigJxjb2tl4oCdLiDigJxjb2tl4oCdIGluIHRoaXMg ZXhhbXBsZSBpcyBub3QgY2FycmllZCB3aXRoaW4gdGhlIG1ldGFkYXRhIHNvIHRoZSBTRiBuZWVk cyB0byBtYXAgdGhlIHZhbHVlIGZyb20gdGhlIG1ldGFkYXRhIHRvIGEgbWVhbmluZ2Z1bCB0ZW5h bnQgaWRlbnRpZmljYXRpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ib3BlIHRo aXMgY2xhcmlmaWVzIC4uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5KaW08L2Rpdj4N CjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJw dDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElO Ry1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg c29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJt YWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24iPndhbmcuY3VpMUB6dGUuY29tLmNuPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuIj53YW5nLmN1aTFAenRl LmNvbS5jbjwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6 IDwvc3Bhbj5XZWRuZXNkYXksIE5vdmVtYmVyIDksIDIwMTYgYXQgOTo0NSBQTTxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkppbSBHdWljaGFyZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZn dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Oywgc2ZjICZs dDs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2VzQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDog PC9zcGFuPlJlOiBbc2ZjXSA8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMv dGlja2V0LzIxIj4NCmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjE8L2E+ PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+DQo8ZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIzIiBmYWNlPSJD YWxpYnJpIj5EZWFyIEppbSAmYW1wOyBKb2VsLDwvZm9udD4gPGJyPg0KPGJyPg0KPGZvbnQgc2l6 ZT0iMyIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO1RoZSB0ZXh0IHNhaWQ6ICd0aGUgZGF0 YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1l YW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuJw0KPC9mb250Pjxicj4NCjxmb250IHNpemU9IjMi IGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtJIGFncmVlIHdpdGggJ3RoZSBhbGxvY2F0aW9u IHNjaGVtYScgY2FuIGhlbHAgdGhlIFNGQy1hd2FyZSBTRiB0byBrbm93IGhvdyB0byBpbnRlcnBy ZXQgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiBIb3dldmVyLDwvZm9udD48YnI+DQo8Zm9u dCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7Q291bGQgeW91IGNsYXJpZnkg d2hhdCBpcyAndGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEnIGFuZCBob3cgdG8gZGVz Y3JpYmUnIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhJz8NCjwvZm9udD48YnI+DQo8 YnI+DQo8Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7VGhhbmtzIHZl cnkgbXVjaCA6KTwvZm9udD4gPGJyPg0KPGJyPg0KPGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJy aSI+QlJzPC9mb250PiA8YnI+DQo8Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIj5MaW5kYSBX YW5nPC9mb250PiA8YnI+DQo8Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgPC9m b250Pjxicj4NCjxicj4NCjxicj4NCjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyA8L2ZvbnQ+PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPSIxMDAlIj4NCjx0Ym9k eT4NCjx0ciB2YWxpZ249InRvcCI+DQo8dGQgd2lkdGg9IjM2JSI+PGZvbnQgc2l6ZT0iMSIgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7SmltIEd1aWNoYXJkIChqZ3VpY2hhcikmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwv YT4mZ3Q7PC9iPjwvZm9udD48YnI+DQo8Zm9udCBzaXplPSIxIiBmYWNlPSJzYW5zLXNlcmlmIj7l j5Hku7bkuro6ICZuYnNwOyZxdW90O3NmYyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0iMSIgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNi8xMS8wOSAwMjowMTwvZm9udD4g PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNjMlIj4NCjx0YWJsZSB3aWR0aD0iMTAwJSI+DQo8dGJv ZHk+DQo8dHIgdmFsaWduPSJ0b3AiPg0KPHRkPg0KPGRpdiBhbGlnbj0icmlnaHQiPjxmb250IHNp emU9IjEiIGZhY2U9InNhbnMtc2VyaWYiPuaUtuS7tuS6ujwvZm9udD48L2Rpdj4NCjwvdGQ+DQo8 dGQ+PGZvbnQgc2l6ZT0iMSIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7PGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDssDQo8L2ZvbnQ+PC90ZD4NCjwvdHI+ DQo8dHIgdmFsaWduPSJ0b3AiPg0KPHRkPg0KPGRpdiBhbGlnbj0icmlnaHQiPjxmb250IHNpemU9 IjEiIGZhY2U9InNhbnMtc2VyaWYiPuaKhOmAgTwvZm9udD48L2Rpdj4NCjwvdGQ+DQo8dGQ+PC90 ZD4NCjwvdHI+DQo8dHIgdmFsaWduPSJ0b3AiPg0KPHRkPg0KPGRpdiBhbGlnbj0icmlnaHQiPjxm b250IHNpemU9IjEiIGZhY2U9InNhbnMtc2VyaWYiPuS4u+mimDwvZm9udD48L2Rpdj4NCjwvdGQ+ DQo8dGQ+PGZvbnQgc2l6ZT0iMSIgZmFjZT0ic2Fucy1zZXJpZiI+W3NmY10gPGEgaHJlZj0iaHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+DQpodHRwczovL3RyYWMuaWV0 Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxPC9hPjwvZm9udD48L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRib2R5Pg0KPHRyIHZhbGlnbj0idG9wIj4NCjx0 ZD48L3RkPg0KPHRkPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8YnI+DQo8L3Rk Pg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGZvbnQgc2l6 ZT0iMiI+RGVhciBTRkMgV0c6PC9mb250PiA8YnI+DQo8YnI+DQo8Zm9udCBzaXplPSIyIj5BZnRl ciBtdWNoIGRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0ICMyMSB0 aGUgZm9sbG93aW5nIHRleHQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5IG1ldGFk YXRhIHNlbWFudGljcyBhbmQgc28gZm9ydGguIFBsZWFzZSByZXZpZXcgYW5kIGluZGljYXRlIHN1 cHBvcnQgKG9yIG5vdCkgc28gdGhhdCB0aGUgY2hhaXJzIGNhbiBkZXRlcm1pbmUgY29uc2Vuc3Vz IGFuZCB1cGRhdGUNCiB0aGUgdGlja2V0IGFjY29yZGluZ2x5LiA8L2ZvbnQ+PGJyPg0KPGJyPg0K PGZvbnQgc2l6ZT0iMiI+VGhhbmsgeW91ITwvZm9udD4gPGJyPg0KPGJyPg0KPGZvbnQgc2l6ZT0i MiI+SmltICZhbXA7IEpvZWw8L2ZvbnQ+IDxicj4NCjxicj4NCjxmb250IHNpemU9IjIiPiMjIyMj IyMjIyM8L2ZvbnQ+IDxicj4NCjxicj4NCjxmb250IHNpemU9IjIiPjxiPk5FVyBmb3Igc2VjdGlv biAzLjQ8L2I+OjwvZm9udD4gPGJyPg0KPGZvbnQgc2l6ZT0iMiI+VGhpcyBzcGVjaWZpY2F0aW9u IGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGlu IHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMg bm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0 YWRhdGEuICZuYnNwOzwvZm9udD48YnI+DQo8YnI+DQo8Zm9udCBzaXplPSIyIj5BbiBTRkMtYXdh cmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBw cm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuICZu YnNwO1RoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24gc2NoZW1h IGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93IGFuIFNGQy1hd2FyZSBT RiBnZXRzIHRoZQ0KIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg c3BlY2lmaWNhdGlvbi48L2ZvbnQ+IDxicj4NCjxicj4NCjxmb250IHNpemU9IjIiPlVwb24gcmVj ZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNv bmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJl Y2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxk LCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3Iu PC9mb250Pjxicj4NCjxicj4NCjxmb250IHNpemU9IjIiPltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxs b2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0 aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuPC9mb250Pjxi cj4NCjxicj4NCjxmb250IHNpemU9IjIiPjxiPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE8 L2I+OjwvZm9udD4gPGJyPg0KPGZvbnQgc2l6ZT0iMiI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMg bm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8t aW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiAmbmJzcDtU aGVzZSBjb25zaWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gJm5ic3A7SG93ZXZl ciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUN CiBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2Vl IFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPC9mb250Pjxi cj4NCjxicj4NCjxmb250IHNpemU9IjIiPlVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJl bG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMgbWlz c2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRo ZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuPC9mb250Pjxicj4NCjxicj4NCjxmb250 IHNpemU9IjIiPklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVp cmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBT RkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiAmbmJzcDtJ ZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJv Y2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlcg0KIHRoZXkgYXBwZWFyIGluIHRoZSBOU0ggcGFj a2V0LjwvZm9udD4gPGJyPg0KPGJyPg0KPGZvbnQgc2l6ZT0iMiI+SWYgbXVsdGlwbGUgaW5zdGFu Y2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRo ZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1h d2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJy b3IuPC9mb250Pjx0dD48Zm9udCBzaXplPSIyIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPC9mb250PjwvdHQ+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPjx0dD48Zm9u dCBzaXplPSIyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvZm9u dD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0iMiI+PGJyPg0KPC9mb250PjwvdHQ+PGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvc3Bhbj48L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9C8B3B9919384B49844FC65F53A48725ciscocom_-- From nobody Thu Nov 10 05:22:29 2016 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 D8D7812958E for ; Thu, 10 Nov 2016 05:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 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=-1.497, 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 xSFQwnIKoDzX for ; Thu, 10 Nov 2016 05:22:26 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A878129503 for ; Thu, 10 Nov 2016 05:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19658; q=dns/txt; s=iport; t=1478784145; x=1479993745; h=from:to:subject:date:message-id:mime-version; bh=BuNZMYx3yRRMCyoBilYBrx1ZD9GW3xy7s2OyrAsw2wU=; b=S7ZJoOvSsf9XRWqDI3nF6Ua5AOqYPB7fkN0rTTe5wOqtxowFs+fuvmR6 BcyHicBKu9WZEH8hMCg6GAU/8C3Nb5eeuIfY2wN3SV7BV9b81UpO1TBz+ ITOkcWPpsu73YfAYeJ/fj8gbdYw+f+/oVcBOXREX5s0OYy74IptYWJmxp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQAudCRY/4gNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM9AQEBAQEfWH8HjTaXC489hRuCBymFewIaggo/FAECAQEBAQEBAWI?= =?us-ascii?q?dC4RhAQEFI0sdAQgRAwECKAMCBDAUCQoEE4hfDqAyj3yCQItEAQEBAQEBAQMBA?= =?us-ascii?q?QEBAQEBAQEBGAWGPoF9CIJVgT0BgnowFoJOLYIwBZRUhWMBhjiDDocMgW6EdIg?= =?us-ascii?q?PgSuHN4YFhAYBHjeBAByDLD+BLXKHC4EMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,619,1473120000"; d="scan'208,217";a="167899967" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2016 13:22:24 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uAADMOYa024718 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Nov 2016 13:22:25 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 07:22:24 -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, 10 Nov 2016 07:22:24 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5dhBvoux3dU2uL7kFD+H1Lg== Date: Thu, 10 Nov 2016 13:22:24 +0000 Message-ID: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_8CBEC11CEF7C4EEB81238C0CE4B0BF25ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 13:22:28 -0000 --_000_8CBEC11CEF7C4EEB81238C0CE4B0BF25ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBTRkMgV0c6DQoNCkdpdmVuIHRoZSByZWNlbnQgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGlu ZyBsaXN0LCB1cGRhdGVkIHRleHQgKHdpdGggY2hhbmdlcyBpbiBSRUQpIGFzIGZvbGxvd3M6DQoN Ck5FVyBmb3Igc2VjdGlvbiAzLjQ6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBh bnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBj b250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUgdGhl IHN0cnVjdHVyZSBvciBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4NCg0KQW4gU0ZD LWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIg dG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxk LiAgVGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEg YW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNG IGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4NCg0KVXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlm IHRoZSBTRkMtYXdhcmUgU0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBtZXRh ZGF0YSBidXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIGZvciB0aGUg bWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCwg aXQgU0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRv IGFueSBsb2dnaW5nLg0KDQpbZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBs ZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQg aW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLg0KDQpORVcgZm9yIGVuZCBvZiBzZWN0aW9u IDMuNS4xOg0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24g YWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQg YXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiAgVGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIGRlcGxv eW1lbnQtc3BlY2lmaWMuICBIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3Qg U0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdp dGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250 cm9sLXBsYW5lXSkuDQoNClVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZyB0byBh IGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0 aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQg YW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQoNCklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9j ZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUg TUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0 aGVzZSBUTFZzLiAgSWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2Fy ZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0 aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBh cmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQg VExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9j ZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkg cmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KRnJvbTogc2ZjIDxzZmMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmltIEd1 aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQpE YXRlOiBUdWVzZGF5LCBOb3ZlbWJlciA4LCAyMDE2IGF0IDE6MDEgUE0NClRvOiAic2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+Pg0KU3ViamVjdDogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tl dC8yMQ0KDQpEZWFyIFNGQyBXRzoNCg0KQWZ0ZXIgbXVjaCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0 IHdpdGggcmVnYXJkIHRvIHRpY2tldCAjMjEgdGhlIGZvbGxvd2luZyB0ZXh0IGhhcyBiZWVuIHBy b3Bvc2VkIHRvIGhlbHAgY2xhcmlmeSBtZXRhZGF0YSBzZW1hbnRpY3MgYW5kIHNvIGZvcnRoLiBQ bGVhc2UgcmV2aWV3IGFuZCBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIHNvIHRoYXQgdGhlIGNo YWlycyBjYW4gZGV0ZXJtaW5lIGNvbnNlbnN1cyBhbmQgdXBkYXRlIHRoZSB0aWNrZXQgYWNjb3Jk aW5nbHkuDQoNClRoYW5rIHlvdSENCg0KSmltICYgSm9lbA0KDQojIyMjIyMjIyMjDQoNCk5FVyBm b3Igc2VjdGlvbiAzLjQ6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNz dW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0 IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVj dHVyZSBvciBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4NCg0KQW4gU0ZDLWF3YXJl IFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJv Y2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiAgVGhl IGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRo ZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMg dGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNh dGlvbi4NCg0KVXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlmIHRoZSBT RkMtYXdhcmUgU0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBtZXRhZGF0YSBi dXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIGZvciB0aGUgbWFuZGF0 b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVT VCBsb2cgdGhpcyBlcnJvci4NCg0KW2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBz YW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRoZSBkYXRhIGNvbnZl eWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCg0KTkVXIGZvciBlbmQgb2Ygc2Vj dGlvbiAzLjUuMToNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0 aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBvciB0aG9zZSB0 aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gIFRoZXNlIGNvbnNpZGVyYXRpb25zIGFyZSBk ZXBsb3ltZW50LXNwZWNpZmljLiAgSG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGluc3Ry dWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0b2dldGhl ciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMt Y29udHJvbC1wbGFuZV0pLg0KDQpVcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcg dG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlzIG1pc3Npbmcg aW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFj a2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpJZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8t cHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBs YW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1 bWUgdGhlc2UgVExWcy4gIElmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRoZSBTRkMt YXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRoZXlhcHBlYXIg aW4gdGhlIE5TSCBwYWNrZXQuDQoNCklmIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBU TFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0 aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1Qg cHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0K --_000_8CBEC11CEF7C4EEB81238C0CE4B0BF25ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7Ij5EZWFyIFNGQyBXRzo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij5HaXZlbiB0 aGUgcmVjZW50IGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCwgdXBkYXRlZCB0ZXh0ICh3 aXRoIGNoYW5nZXMgaW4gUkVEKSBhcyBmb2xsb3dzOjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsiPjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGI+TkVXIGZvciBz ZWN0aW9uIDMuNDwvYj46PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPlRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5v dCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFu ZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNj cmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLg0K ICZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+QW4gU0ZDLWF3YXJl IFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJv Y2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNw OyZuYnNwO1RoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24gc2No ZW1hIGFuZCB0aGUgbWVhbmluZw0KIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3 YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMgc3BlY2lmaWNhdGlvbi48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBN RC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1h bmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRh IHNlbWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBw cm9jZXNzIHRoZSBwYWNrZXQ8Zm9udCBjb2xvcj0iI2ZmMDAwMCI+LA0KIGl0PC9mb250PiA8Zm9u dCBjb2xvcj0iI2ZmMDAwMCI+U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSBy YXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9mb250Pi48L2Rpdj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogLXdl YmtpdC1zdGFuZGFyZDsiPltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxl IGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0YSBjb252ZXllZCBp biB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IC13ZWJraXQt c3RhbmRhcmQ7Ij48Yj5ORVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xPC9iPjo8L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5k YXJkOyI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJv dXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJl IG1hbmRhdG9yeS10by1wcm9jZXNzLiZuYnNwOyZuYnNwO1RoZXNlIGNvbnNpZGVyYXRpb25zIGFy ZSBkZXBsb3ltZW50LXNwZWNpZmljLiZuYnNwOyZuYnNwO0hvd2V2ZXIsIHRoZQ0KIGNvbnRyb2wg cGxhbmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUg b2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9m IFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0 LXN0YW5kYXJkOyI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2 ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQg cGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQg TVVTVCBsb2cgdGhpcyBlcnJvci48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsi PklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBh IGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUg U0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmIG5v IGluc3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRoZQ0KIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nl c3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleTxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3Bh biIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij48L3NwYW4+YXBwZWFyIGluIHRoZSBOU0ggcGFj a2V0LjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiAtd2Via2l0LXN0YW5kYXJkOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij5J ZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBO U0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cg Zm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bh bj48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+LA0KIGl0Jm5ic3A7PC9mb250Pjxmb250IGNvbG9yPSIj ZmYwMDAwIj5TSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRp bmcgdG8gYW55IGxvZ2dpbmc8L2ZvbnQ+LjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyI+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij48YnI+ DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6 ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRp dW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQ QURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRm IDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPnNmYyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBOb3ZlbWJlciA4LCAy MDE2IGF0IDE6MDEgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwv c3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ W3NmY10gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+ DQpodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxPC9hPjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13 ZWJraXQtc3RhbmRhcmQ7Ij5EZWFyIFNGQyBXRzo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPkFmdGVyIG11Y2ggZGlzY3Vzc2lvbiBvbiB0aGUgbGlz dCB3aXRoIHJlZ2FyZCB0byB0aWNrZXQgIzIxIHRoZSBmb2xsb3dpbmcgdGV4dCBoYXMgYmVlbiBw cm9wb3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNzIGFuZCBzbyBmb3J0aC4g UGxlYXNlIHJldmlldyBhbmQgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90KSBzbyB0aGF0IHRoZSBj aGFpcnMgY2FuDQogZGV0ZXJtaW5lIGNvbnNlbnN1cyBhbmQgdXBkYXRlIHRoZSB0aWNrZXQgYWNj b3JkaW5nbHkuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1z dGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQt c3RhbmRhcmQ7Ij5UaGFuayB5b3UhPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdl YmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13 ZWJraXQtc3RhbmRhcmQ7Ij5KaW0gJmFtcDsgSm9lbDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+IyMjIyMjIyMjIzwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48Yj48YnI+DQo8L2I+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxiPk5FVyBmb3Igc2VjdGlv biAzLjQ8L2I+OjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRh cmQ7Ij5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91 dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRo ZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBvciBtZWFu aW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4gJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5BbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNl aXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRh IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuJm5ic3A7Jm5ic3A7VGhlIGRh dGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBt ZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLg0KIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0 aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0 aW9uLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+ VXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlmIHRoZSBTRkMtYXdhcmUg U0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBtZXRhZGF0YSBidXQgaGFzIG5v dCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIGZvciB0aGUgbWFuZGF0b3J5IGNvbnRl eHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQNCiBNVVNUIGxvZyB0 aGlzIGVycm9yLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRh cmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5k YXJkOyI+W2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMg dG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRoZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5k YXRvcnkgY29udGV4dCBmaWVsZC48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdl YmtpdC1zdGFuZGFyZDsiPjxiPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE8L2I+OjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5UaGlzIHNwZWNp ZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJl IG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXBy b2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3Bl Y2lmaWMuJm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGluc3RydWN0 DQogU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVy IHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1j b250cm9sLXBsYW5lXSkuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1z dGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQt c3RhbmRhcmQ7Ij5VcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZl biBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBw YWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBN VVNUIGxvZyB0aGlzIGVycm9yLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJr aXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN0YW5kYXJkOyI+SWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUg cmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3Qg dGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuJm5i c3A7Jm5ic3A7SWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBT RiBNVVNUIHByb2Nlc3MNCiB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5PHNwYW4gY2xhc3M9 IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+YXBwZWFyIGlu IHRoZSBOU0ggcGFja2V0LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQt c3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0 LXN0YW5kYXJkOyI+SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5j bHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRv ZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRo ZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGlkPSIiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvc3Bhbj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8CBEC11CEF7C4EEB81238C0CE4B0BF25ciscocom_-- From nobody Thu Nov 10 05:28:17 2016 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 74168129651 for ; Thu, 10 Nov 2016 05:28:16 -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, 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 jxCwzwpOv8XN for ; Thu, 10 Nov 2016 05:28:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C5A129618 for ; Thu, 10 Nov 2016 05:28:13 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 978042DC5C0; Thu, 10 Nov 2016 14:28:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7886335C060; Thu, 10 Nov 2016 14:28:11 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Thu, 10 Nov 2016 14:28:11 +0100 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5dhBvoux3dU2uL7kFD+H1LqDSNVJQ Date: Thu, 10 Nov 2016 13:28:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DAF48D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> In-Reply-To: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@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.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DAF48DOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.10.124815 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 13:28:16 -0000 --_000_787AE7BB302AE849A7480A190F8B933009DAF48DOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLA0KDQpJIGRpc2FncmVlIHdpdGggdGhlIGNoYW5nZSBpbiBSRUQgZm9yIHRoZSByZWFz b25zIEkgY2xhcmlmaWVkIGluIGEgcHJldmlvdXMgZW1haWxzLg0KDQo9PQ0KDQpJIGRvIHByZWZl ciB0aGUgIk1VU1QgbG9nIC4uIiB3b3JkaW5nIGJlY2F1c2UgaXQgaXMgY3JpdGljYWwgdG8gZGV0 ZWN0IHdoZW4gYSBtYW5kYXRvcnkgcGllY2UgaXMgbWlzc2luZyB0byBkZWxpdmVyIHRoZSBzZXJ2 aWNlLg0KDQoNCg0KVGhlIHByb3Bvc2VkIHRleHQgaXMgYWJvdXQgU0ZDLWF3YXJlIFNGcy4gSWYg dGhlIGF0dGFjayB2ZWN0b3IgaXMgYSBEb1MsIGl0IGlzIGxpa2VseSB0aGF0IHRoZSBib3JkZXIg bm9kZXMvY2xhc3NpZmllcnMgd2lsbCBiZSB0aGUgZmlyc3QgdmljdGltcy4gSW1wbGVtZW50aW5n IG1lYXN1cmVzIHRvIHByb3RlY3QgYWdhaW5zdCBEb1MgYXQgdGhlIGJvdW5kYXJpZXMgd291bGQg YmUgYSBmaXJzdCBndWFyZC4NCg0KDQoNCklmIHRoZSBEb1MgaXMgZnJvbSB3aXRoaW4gdGhlIFNG QyBkb21haW4sIGRlc3BpdGUgdGhpcyBpcyBhIHZhbGlkIHRocmVhdCB2ZWN0b3IgYW5kIG1pc2Jl aGF2aW5nIG5vZGVzIG1heSBoYXBwZW4gKHNvZnR3YXJlIGJ1Z3MsIGV0Yy4pLCBJIHRob3VnaHQg dGhlIHNlY3VyaXR5IG1vZGVsIG9mIE5TSCBhc3N1bWVzIHRoYXQgYWxsIGludm9sdmVkIG5vZGVz IGFyZSB0cnVzdGVkLg0KPT0NCg0KVGhhbmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0gR3VpY2hh cmQgKGpndWljaGFyKQ0KRW52b3nDqSA6IGpldWRpIDEwIG5vdmVtYnJlIDIwMTYgMTQ6MjINCsOA IDogc2ZjQGlldGYub3JnDQpPYmpldCA6IFJlOiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcv dHJhYy9zZmMvdGlja2V0LzIxDQoNCkRlYXIgU0ZDIFdHOg0KDQpHaXZlbiB0aGUgcmVjZW50IGRp c2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCwgdXBkYXRlZCB0ZXh0ICh3aXRoIGNoYW5nZXMg aW4gUkVEKSBhcyBmb2xsb3dzOg0KDQpORVcgZm9yIHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZp Y2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxh Y2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5k IGRvZXMgbm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVk ZWQgbWV0YWRhdGEuDQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2Vt YW50aWNzIGZpcnN0IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBt YW5kYXRvcnkgY29udGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGgg dGhlIGFsbG9jYXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0 YS4gSG93IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5T SCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9y IG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBk YXRhIHNlbWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5P VCBwcm9jZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1Qg YXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KW2RjYWxsb2NdIGFuZCBbYnJv YWRhbGxvY10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3 aXRoIHRoZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCg0K TkVXIGZvciBlbmQgb2Ygc2VjdGlvbiAzLjUuMToNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5v dCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWlt cGxlbWVudCBvciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gIFRoZXNlIGNv bnNpZGVyYXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiAgSG93ZXZlciwgdGhlIGNvbnRy b2wgcGxhbmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1 cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4z IG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLg0KDQpVcG9uIHJlY2VpcHQgb2YgYSBw YWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nl c3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBO T1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpJZiBtdWx0 aXBsZSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBT RlAsIHRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGgg dGhlIG9yZGVyIHRvIGNvbnN1bWUgdGhlc2UgVExWcy4gIElmIG5vIGluc3RydWN0aW9ucyBhcmUg cHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhl IG9yZGVyIHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuDQoNCklmIG11bHRpcGxlIGluc3Rh bmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0 aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMt YXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMg ZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCkZy b206IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn Pj4gb24gYmVoYWxmIG9mIEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpq Z3VpY2hhckBjaXNjby5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgOCwgMjAxNiBhdCAx OjAxIFBNDQpUbzogInNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClN1YmplY3Q6IFtzZmNdIGh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCg0KRGVhciBTRkMgV0c6DQoNCkFmdGVyIG11Y2gg ZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB3aXRoIHJlZ2FyZCB0byB0aWNrZXQgIzIxIHRoZSBmb2xs b3dpbmcgdGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2Vt YW50aWNzIGFuZCBzbyBmb3J0aC4gUGxlYXNlIHJldmlldyBhbmQgaW5kaWNhdGUgc3VwcG9ydCAo b3Igbm90KSBzbyB0aGF0IHRoZSBjaGFpcnMgY2FuIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHVw ZGF0ZSB0aGUgdGlja2V0IGFjY29yZGluZ2x5Lg0KDQpUaGFuayB5b3UhDQoNCkppbSAmIEpvZWwN Cg0KIyMjIyMjIyMjIw0KDQpORVcgZm9yIHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9u IGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGlu IHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMg bm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0 YWRhdGEuDQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNz IGZpcnN0IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRv cnkgY29udGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFs bG9jYXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93 IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10 eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRh dG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNl bWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9j ZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQoNCltkY2FsbG9jXSBhbmQg W2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5p bmcgd2l0aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQu DQoNCk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9l cyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10 by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVz ZSBjb25zaWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBj b250cm9sIHBsYW5lIGNhbiBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3Ry dWN0dXJlIG9mIFRMVnMgdG9nZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAz LjMuMyBvZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9m IGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1w cm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1V U1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KSWYg bXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2 ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3 aXRoIHRoZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMg YXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGlu IHRoZSBvcmRlciB0aGV5YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0Lg0KDQpJZiBtdWx0aXBsZSBp bnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBi dXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUg U0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhp cyBlcnJvci4NCg== --_000_787AE7BB302AE849A7480A190F8B933009DAF48DOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGJydXQgQ2FyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTQuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVM7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5h cHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLlRl eHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVz IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls ZTpub3JtYWw7fQ0Kc3Bhbi5UZXh0ZWJydXRDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGJy dXQgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRl IGJydXQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0 IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkhpIEppbSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PkkgZGlzYWdyZWUgd2l0aCB0aGUgY2hhbmdlIGluIFJFRCBmb3IgdGhlIHJlYXNvbnMgSSBjbGFy aWZpZWQgaW4gYSBwcmV2aW91cyBlbWFpbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPj09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZG8gcHJlZmVyIHRoZSAmcXVvdDtN VVNUIGxvZyAuLiZxdW90OyB3b3JkaW5nIGJlY2F1c2UgaXQgaXMgY3JpdGljYWwgdG8gZGV0ZWN0 IHdoZW4gYSBtYW5kYXRvcnkgcGllY2UgaXMgbWlzc2luZyB0byBkZWxpdmVyIHRoZSBzZXJ2aWNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHByb3Bvc2VkIHRleHQgaXMgYWJvdXQgU0ZD LWF3YXJlIFNGcy4gSWYgdGhlIGF0dGFjayB2ZWN0b3IgaXMgYSBEb1MsIGl0IGlzIGxpa2VseSB0 aGF0IHRoZSBib3JkZXIgbm9kZXMvY2xhc3NpZmllcnMgd2lsbCBiZSB0aGUgZmlyc3QgdmljdGlt cy4gSW1wbGVtZW50aW5nIG1lYXN1cmVzIHRvIHByb3RlY3QgYWdhaW5zdCBEb1MgYXQgdGhlIGJv dW5kYXJpZXMgd291bGQNCiBiZSBhIGZpcnN0IGd1YXJkLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPklmIHRoZSBEb1MgaXMgZnJvbSB3aXRoaW4gdGhlIFNGQyBkb21haW4sIGRlc3BpdGUgdGhp cyBpcyBhIHZhbGlkIHRocmVhdCB2ZWN0b3IgYW5kIG1pc2JlaGF2aW5nIG5vZGVzIG1heSBoYXBw ZW4gKHNvZnR3YXJlIGJ1Z3MsIGV0Yy4pLCBJIHRob3VnaHQgdGhlIHNlY3VyaXR5IG1vZGVsIG9m IE5TSCBhc3N1bWVzIHRoYXQgYWxsIGludm9sdmVkIG5vZGVzIGFyZSB0cnVzdGVkLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj49PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gSmltIEd1aWNoYXJkIChqZ3VpY2hh cik8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMTAgbm92ZW1icmUgMjAxNiAxNDoy Mjxicj4NCjxiPsOAJm5ic3A7OjwvYj4gc2ZjQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6 PC9iPiBSZTogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWFyIFNGQyBXRzo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R2l2ZW4gdGhlIHJlY2VudCBkaXNj dXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHVwZGF0ZWQgdGV4dCAod2l0aCBjaGFuZ2VzIGlu IFJFRCkgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5ORVcgZm9yIHNlY3Rpb24gMy40PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55 IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29u dGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBz dHJ1Y3R1cmUNCiBvciBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4gJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFu ZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNG IE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2Vz cyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZu YnNwO1RoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGgNCiB0aGUgYWxsb2NhdGlvbiBzY2hl bWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJl IFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg c3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5VcG9uIHJlY2Vp dmluZyBhbiBOU0ggTUQtdHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25m aWd1cmVkIGZvciBtYW5kYXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNl aXZlZCB0aGUgZGF0YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkNCiBjb250ZXh0IGZpZWxk LCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQ8c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4s IGl0PC9zcGFuPg0KPHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+U0hPVUxEIGxvZyB0aGlzIGVycm9y LCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFti cm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5n IHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3IgZW5k IG9mIHNlY3Rpb24gMy41LjE8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBh Ym91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBh cmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMg YXJlDQogZGVwbG95bWVudC1zcGVjaWZpYy4mbmJzcDsmbmJzcDtIb3dldmVyLCB0aGUgY29udHJv bCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVy ZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMg b2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25n IHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5n IGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBh Y2tldA0KIGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMg YXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3Ry dWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZz LiZuYnNwOyZuYnNwO0lmDQogbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1h d2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBp biB0aGUgTlNIIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5JZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBp biBhbiBOU0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3Qg YWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFj a2V0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj4sIGl0 Jm5ic3A7U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5n IHRvIGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnNmYyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hh ckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PlR1ZXNkYXksIE5vdmVtYmVyIDgsIDIwMTYgYXQgMTowMSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+W3NmY10gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvc2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8y MTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkRlYXIgU0ZDIFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkFmdGVyIG11Y2ggZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB3aXRoIHJlZ2FyZCB0 byB0aWNrZXQgIzIxIHRoZSBmb2xsb3dpbmcgdGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxw IGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNzIGFuZCBzbyBmb3J0aC4gUGxlYXNlIHJldmlldw0K IGFuZCBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIHNvIHRoYXQgdGhlIGNoYWlycyBjYW4gZGV0 ZXJtaW5lIGNvbnNlbnN1cyBhbmQgdXBkYXRlIHRoZSB0aWNrZXQgYWNjb3JkaW5nbHkuJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtp dC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91ITxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3Rh bmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkppbSAmYW1wOyBKb2Vs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtp dC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IyMjIyMjIyMjIzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2Vj dGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5U aGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUg Y29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0gg aGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVjdHVyZQ0KIG9yIG1lYW5pbmcg b2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5BbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRh IHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0 aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuJm5ic3A7Jm5ic3A7VGhlIGRhdGEgc2VtYW50aWNz IGluY2x1ZGUgYm90aA0KIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2Yg dGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1h bnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5T SCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9y IG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBk YXRhIHNlbWFudGljcyBmb3IgdGhlDQogbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1Qg Tk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFs bG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGgg dGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3IgZW5kIG9mIHNl Y3Rpb24gMy41LjE8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBU TFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFu ZGF0b3J5LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlDQog ZGVwbG95bWVudC1zcGVjaWZpYy4mbmJzcDsmbmJzcDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFu ZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBU TFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0kt RC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEg Z2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRo YXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldA0K IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJl cXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRo ZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiZuYnNw OyZuYnNwO0lmDQogbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBT RiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUg TlNIIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5J ZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBO U0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cg Zm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFja2V0IGFu ZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933009DAF48DOPEXCLILMA3corp_-- From nobody Thu Nov 10 05:28:32 2016 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 C8EDA12969B for ; Thu, 10 Nov 2016 05:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 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=-1.497, 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 hnnk0kBt9hJM for ; Thu, 10 Nov 2016 05:28:17 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C39129618 for ; Thu, 10 Nov 2016 05:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29652; q=dns/txt; s=iport; t=1478784496; x=1479994096; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ynBw/RpFUVHEjXIMuMol2UjsDoWWAzAlSt+yQEHubvw=; b=T1AzoNdE1nQS68m4PvQh/JWrvA/YSp0cZwX/JsKfsE0AdX+lYKm2kK0d cksl7rHWq47E5IuJZ5MJy7nWPOrHJhR0nNGaZWIXdLzlhq0alFn3Y2d/L VDo+cdrMn3DDf79H5o1kmhsPOWPKzuNWCG5BQ8Zk43UOpBoD9fmV3nmHo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQCadCRY/5BdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM9AQEBAQEfWH8HjTaXC5RYggcphXsCGoIKPxQBAgEBAQEBAQFiHQu?= =?us-ascii?q?EYQEBAQQjSxsCAQgRAwECKAMCAgIwFAkIAgQTiF8OsDKCQItEAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWGPoF9CIJVgT0BgnowFoJOLYIwBZRUhWMBhjiDDocMgW6?= =?us-ascii?q?EdIgPgSuHN4YFhAYBHjeBAByDLD+BLXKHC4EMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,619,1473120000"; d="scan'208,217";a="172735634" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Nov 2016 13:28:15 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uAADSFSa003327 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Nov 2016 13:28:15 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 07:28:15 -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, 10 Nov 2016 07:28:14 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5dhBvoux3dU2uL7kFD+H1LqDSRqwA Date: Thu, 10 Nov 2016 13:28:14 +0000 Message-ID: References: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> In-Reply-To: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_B0AA0BD6F11E44559BA1D07245C5A5B3ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 13:28:20 -0000 --_000_B0AA0BD6F11E44559BA1D07245C5A5B3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBTRkMgV0c6DQoNCkFwb2xvZ2llcywgaXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQg SSBtaXNzZWQgYWRkaW5nIHRoZSB0ZXh0IGF0IGEgdGhpcmQgbG9jYXRpb24uIENvcnJlY3QgdGV4 dCBhcyBmb2xsb3dzOg0KDQpORVcgZm9yIHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9u IGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGlu IHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMg bm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0 YWRhdGEuDQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNz IGZpcnN0IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRv cnkgY29udGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFs bG9jYXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93 IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10 eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRh dG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNl bWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9j ZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkg cmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KW2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxv Y10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRo ZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCg0KTkVXIGZv ciBlbmQgb2Ygc2VjdGlvbiAzLjUuMToNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtl IGFueSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWltcGxlbWVu dCBvciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gIFRoZXNlIGNvbnNpZGVy YXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiAgSG93ZXZlciwgdGhlIGNvbnRyb2wgcGxh bmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2Yg VExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJ LUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLg0KDQpVcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQg dGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExW IGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJv Y2VzcyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5 IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCklmIG11bHRpcGxlIG1hbmRhdG9yeS10 by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wg cGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29u c3VtZSB0aGVzZSBUTFZzLiAgSWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNG Qy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVh ciBpbiB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1l IFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9m IHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5P VCBwcm9jZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1Qg YXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KRnJvbTogc2ZjIDxzZmMtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2Yg SmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNv bT4+DQpEYXRlOiBUaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgYXQgODoyMiBBTQ0KVG86ICJz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvc2ZjL3RpY2tldC8yMQ0KDQpEZWFyIFNGQyBXRzoNCg0KR2l2ZW4gdGhlIHJlY2VudCBkaXNj dXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHVwZGF0ZWQgdGV4dCAod2l0aCBjaGFuZ2VzIGlu IFJFRCkgYXMgZm9sbG93czoNCg0KTkVXIGZvciBzZWN0aW9uIDMuNDoNClRoaXMgc3BlY2lmaWNh dGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNl ZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBk b2VzIG5vdCBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVk IG1ldGFkYXRhLg0KDQpBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFu dGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFu ZGF0b3J5IGNvbnRleHQgZmllbGQuICBUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRo ZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEu IEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9uIHJlY2VpdmluZyBhbiBOU0gg TUQtdHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBt YW5kYXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0 YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1Qg cHJvY2VzcyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFw cGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCltkY2FsbG9jXSBhbmQgW2Jyb2Fk YWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0 aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuDQoNCk5F VyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg bWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBs ZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVzZSBjb25z aWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250cm9s IHBsYW5lIGNhbiBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJl IG9mIFRMVnMgdG9nZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBv ZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9mIGEgcGFj a2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNz IFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9U IHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KSWYgbXVsdGlw bGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQ LCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRo ZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHBy b3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBv cmRlciB0aGV5YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0Lg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5j ZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhl IGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3 YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVy cm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nLg0KDQpGcm9t OiBzZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1 aWNoYXJAY2lzY28uY29tPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDgsIDIwMTYgYXQgMTow MSBQTQ0KVG86ICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbc2ZjXSBodHRwczovL3RyYWMuaWV0 Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxDQoNCkRlYXIgU0ZDIFdHOg0KDQpBZnRlciBtdWNoIGRp c2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0ICMyMSB0aGUgZm9sbG93 aW5nIHRleHQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5IG1ldGFkYXRhIHNlbWFu dGljcyBhbmQgc28gZm9ydGguIFBsZWFzZSByZXZpZXcgYW5kIGluZGljYXRlIHN1cHBvcnQgKG9y IG5vdCkgc28gdGhhdCB0aGUgY2hhaXJzIGNhbiBkZXRlcm1pbmUgY29uc2Vuc3VzIGFuZCB1cGRh dGUgdGhlIHRpY2tldCBhY2NvcmRpbmdseS4NCg0KVGhhbmsgeW91IQ0KDQpKaW0gJiBKb2VsDQoN CiMjIyMjIyMjIyMNCg0KTkVXIGZvciBzZWN0aW9uIDMuNDoNClRoaXMgc3BlY2lmaWNhdGlvbiBk b2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0 aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5v dCBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFk YXRhLg0KDQpBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBm aXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5 IGNvbnRleHQgZmllbGQuICBUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRoZSBhbGxv Y2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBh biBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9uIHJlY2VpdmluZyBhbiBOU0ggTUQtdHlw ZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBtYW5kYXRv cnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0YSBzZW1h bnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2Vz cyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpbZGNhbGxvY10gYW5kIFti cm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5n IHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLg0K DQpORVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xOg0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMg bm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8t aW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiAgVGhlc2Ug Y29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuICBIb3dldmVyLCB0aGUgY29u dHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVj dHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4z LjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuDQoNClVwb24gcmVjZWlwdCBvZiBh IHBhY2tldCB0aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJv Y2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNU IE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQoNCklmIG11 bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVu IFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0 aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiAgSWYgbm8gaW5zdHJ1Y3Rpb25zIGFy ZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0 aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5z dGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0 IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNG Qy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMg ZXJyb3IuDQo= --_000_B0AA0BD6F11E44559BA1D07245C5A5B3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2E3E49E901E91446AFC7829E0E1BE74A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+RGVh ciBTRkMgV0c6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BcG9sb2dpZXMsIGl0IHdh cyBwb2ludGVkIG91dCB0byBtZSB0aGF0IEkgbWlzc2VkIGFkZGluZyB0aGUgdGV4dCBhdCBhIHRo aXJkIGxvY2F0aW9uLiBDb3JyZWN0IHRleHQgYXMgZm9sbG93czo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7 Ij48Yj5ORVcgZm9yIHNlY3Rpb24gMy40PC9iPjo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2Ug YW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkg Y29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRo ZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuICZuYnNwOzwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+QW4gU0ZD LWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIg dG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxk LiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRp b24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4NCiBIb3cgYW4g U0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAt d2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zdGFuZGFyZDsiPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0 LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2Yg bWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3Ig dGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNr ZXQ8Zm9udCBjb2xvcj0iI2ZmMDAwMCI+LA0KIGl0PC9mb250PiZuYnNwOzxmb250IGNvbG9yPSIj ZmYwMDAwIj5TSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRp bmcgdG8gYW55IGxvZ2dpbmc8L2ZvbnQ+LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiAtd2Via2l0LXN0YW5kYXJkOyI+W2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBz YW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRoZSBkYXRhIGNvbnZl eWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC48L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxiPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24g My41LjE8L2I+OjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRh cmQ7Ij5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91 dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUg bWFuZGF0b3J5LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJl IGRlcGxveW1lbnQtc3BlY2lmaWMuJm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhlIGNvbnRyb2wgcGxh bmUgY2FuIGluc3RydWN0DQogU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBv ZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2Yg W0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5VcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBi ZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlzIG1p c3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0 aGUgcGFja2V0PGZvbnQgY29sb3I9IiNmZjAwMDAiPiwgaXQ8L2ZvbnQ+Jm5ic3A7PGZvbnQgY29s b3I9IiNmZjAwMDAiPlNIT1VMRA0KIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRl IGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9mb250Pi48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9j ZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUg TUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0 aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRo ZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzDQogdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhl eTxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij48 L3NwYW4+YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBz YW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9u IG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNU IE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQ8Zm9udCBjb2xvcj0iI2ZmMDAwMCI+LCBpdCZuYnNwOzwv Zm9udD48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+U0hPVUxEDQogbG9nIHRoaXMgZXJyb3IsIGFuZCBN VVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmc8L2ZvbnQ+LjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPnNmYyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9u IGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNj by5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgYXQg ODoyMiBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZx dW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3Nm Y10gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+DQpo dHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxPC9hPjxicj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPkRlYXIgU0ZDIFdHOjwvZGl2 Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPkdpdmVuIHRoZSByZWNlbnQgZGlzY3Vzc2lvbiBv biB0aGUgbWFpbGluZyBsaXN0LCB1cGRhdGVkIHRleHQgKHdpdGggY2hhbmdlcyBpbiBSRUQpIGFz IGZvbGxvd3M6PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyI+PGJyPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48Yj5ORVcgZm9yIHNlY3Rpb24gMy40PC9iPjo8L2Rpdj4N CjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0 YW5kYXJkOyI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24g YWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBv ZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3Ig bWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuDQogJm5ic3A7PC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsi Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5BbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBk YXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBp biB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuJm5ic3A7Jm5ic3A7VGhlIGRhdGEgc2VtYW50 aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nDQog b2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBz ZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjwvZGl2 Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IC13ZWJraXQt c3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0 LXN0YW5kYXJkOyI+VXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlmIHRo ZSBTRkMtYXdhcmUgU0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBtZXRhZGF0 YSBidXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIGZvciB0aGUgbWFu ZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDxmb250 IGNvbG9yPSIjZmYwMDAwIj4sDQogaXQ8L2ZvbnQ+IDxmb250IGNvbG9yPSIjZmYwMDAwIj5TSE9V TEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxv Z2dpbmc8L2ZvbnQ+LjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+W2RjYWxs b2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRl IGEgbWVhbmluZyB3aXRoIHRoZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4 dCBmaWVsZC48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxiPk5FVyBmb3Ig ZW5kIG9mIHNlY3Rpb24gMy41LjE8L2I+OjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5UaGlzIHNwZWNpZmljYXRp b24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRh dG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3Mu Jm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMu Jm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhlDQogY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZD LWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGgg dGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9s LXBsYW5lXSkuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5VcG9uIHJlY2Vp cHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5 LXRvLXByb2Nlc3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUg U0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjwv ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IC13ZWJr aXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+SWYgbXVsdGlwbGUgbWFuZGF0b3J5 LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0aGUgY29udHJv bCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBvcmRlciB0byBj b25zdW1lIHRoZXNlIFRMVnMuJm5ic3A7Jm5ic3A7SWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92 aWRlZCwgdGhlDQogU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBv cmRlciB0aGV5PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 IHByZTsiPjwvc3Bhbj5hcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuPC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPklmIG11bHRpcGxlIGluc3RhbmNlcyBv ZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0aGUgZGVm aW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMtYXdhcmUg U0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0PC9zcGFuPjxmb250IGNvbG9yPSIjZmYwMDAw Ij4sDQogaXQmbmJzcDs8L2ZvbnQ+PGZvbnQgY29sb3I9IiNmZjAwMDAiPlNIT1VMRCBsb2cgdGhp cyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZzwvZm9u dD4uPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxk aXYgaWQ9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsiPjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRF Ui1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkct Qk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRF Ui1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURE SU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3Nw YW4+c2ZjICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEppbSBHdWljaGFyZCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDs8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXks IE5vdmVtYmVyIDgsIDIwMTYgYXQgMTowMSBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1 YmplY3Q6IDwvc3Bhbj5bc2ZjXSA8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9z ZmMvdGlja2V0LzIxIj4NCmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjE8 L2E+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPkRlYXIgU0ZDIFdHOjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+QWZ0ZXIgbXVjaCBkaXNjdXNz aW9uIG9uIHRoZSBsaXN0IHdpdGggcmVnYXJkIHRvIHRpY2tldCAjMjEgdGhlIGZvbGxvd2luZyB0 ZXh0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGhlbHAgY2xhcmlmeSBtZXRhZGF0YSBzZW1hbnRpY3Mg YW5kIHNvIGZvcnRoLiBQbGVhc2UgcmV2aWV3IGFuZCBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3Qp IHNvIHRoYXQgdGhlIGNoYWlycyBjYW4NCiBkZXRlcm1pbmUgY29uc2Vuc3VzIGFuZCB1cGRhdGUg dGhlIHRpY2tldCBhY2NvcmRpbmdseS4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPlRoYW5rIHlvdSE8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPkppbSAmYW1wOyBKb2VsPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij4jIyMjIyMjIyMjPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxiPjxicj4NCjwv Yj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGI+ TkVXIGZvciBzZWN0aW9uIDMuNDwvYj46PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zdGFuZGFyZDsiPlRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBh c3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRl eHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmliZSB0aGUgc3Ry dWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLiAmbmJzcDs8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPkFuIFNGQy1hd2Fy ZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNzIGZpcnN0IGluIG9yZGVyIHRvIHBy b2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4mbmJz cDsmbmJzcDtUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0aW9uIHNj aGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuDQogSG93IGFuIFNGQy1h d2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIHNwZWNpZmljYXRpb24uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtp dC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJr aXQtc3RhbmRhcmQ7Ij5VcG9uIHJlY2VpdmluZyBhbiBOU0ggTUQtdHlwZSAxIHBhY2tldCwgaWYg dGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBtYW5kYXRvcnkgdXNlIG9mIG1ldGFk YXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0YSBzZW1hbnRpY3MgZm9yIHRoZSBt YW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFu ZA0KIE1VU1QgbG9nIHRoaXMgZXJyb3IuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IC13ZWJraXQtc3RhbmRhcmQ7Ij5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNh bXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5 ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGI+TkVXIGZvciBlbmQgb2Ygc2VjdGlvbiAz LjUuMTwvYj46PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFy ZDsiPlRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0 IFRMVnMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBvciB0aG9zZSB0aGF0IGFyZSBt YW5kYXRvcnktdG8tcHJvY2Vzcy4mbmJzcDsmbmJzcDtUaGVzZSBjb25zaWRlcmF0aW9ucyBhcmUg ZGVwbG95bWVudC1zcGVjaWZpYy4mbmJzcDsmbmJzcDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFu ZSBjYW4gaW5zdHJ1Y3QNCiBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJlIG9m IFRMVnMgdG9nZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBvZiBb SS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPlVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJl bG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMgbWlz c2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRo ZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5JZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJv Y2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBsYW5l IE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1bWUg dGhlc2UgVExWcy4mbmJzcDsmbmJzcDtJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0 aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2Vzcw0KIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRo ZXk8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwv c3Bhbj5hcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5JZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNh bWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24g b2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1Qg Tk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci48L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9zcGFuPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_B0AA0BD6F11E44559BA1D07245C5A5B3ciscocom_-- From nobody Thu Nov 10 06:49:09 2016 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 0CACE1294A8 for ; Thu, 10 Nov 2016 06:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 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=-1.497] 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 0b-KufcJ9o4i for ; Thu, 10 Nov 2016 06:49:05 -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 3CCCD129435 for ; Thu, 10 Nov 2016 06:49:05 -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, 10 Nov 2016 09:49:04 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0319.002; Thu, 10 Nov 2016 09:49:04 -0500 From: Dave Dolson To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5dhBvoux3dU2uL7kFD+H1LqDSRqwAgAAFRGA= Date: Thu, 10 Nov 2016 14:49:03 +0000 Message-ID: References: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.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.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E983115801Awtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 14:49:08 -0000 --_000_E8355113905631478EFF04F5AA706E983115801Awtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmltLA0KSSBhZ3JlZSB3aXRoIHRoaXMgd29yZGluZy4NClRoaXMgYWxsb3dzIHRoZSBpbXBsZW1l bnRlciB0byBjaG9vc2UgYW4gYXBwcm9hY2ggdGhhdCBkb2VzIG5vdCBvdmVyd2hlbG0gdGhlIGRl dmljZSB3aGVuIHRoZSBzeXN0ZW0gaXMgY29uZmlndXJlZCBpbXByb3Blcmx5Lg0KDQpJZiBpdCB3 ZXJlIOKAnE1VU1TigJ0sIEkgd291bGQgZXhwZWN0IG1vcmUgZGV0YWlscyBhYm91dCB3aGF0IGV4 YWN0bHkgc2hvdWxkIGJlIGxvZ2dlZC4gT3RoZXJ3aXNlLCBob3cgY291bGQgb25lIHRlc3QgY29t cGxpYW5jZT8NCg0KLURhdmUNCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpTZW50OiBUaHVyc2Rh eSwgTm92ZW1iZXIgMTAsIDIwMTYgODoyOCBBTQ0KVG86IHNmY0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCg0KRGVh ciBTRkMgV0c6DQoNCkFwb2xvZ2llcywgaXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQgSSBt aXNzZWQgYWRkaW5nIHRoZSB0ZXh0IGF0IGEgdGhpcmQgbG9jYXRpb24uIENvcnJlY3QgdGV4dCBh cyBmb2xsb3dzOg0KDQpORVcgZm9yIHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9uIGRv ZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRo ZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90 IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRh dGEuDQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNzIGZp cnN0IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkg Y29udGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9j YXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93IGFu IFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBl IDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9y eSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFu dGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNz IHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0 ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KW2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10g cHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRoZSBk YXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCg0KTkVXIGZvciBl bmQgb2Ygc2VjdGlvbiAzLjUuMToNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFu eSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBv ciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gIFRoZXNlIGNvbnNpZGVyYXRp b25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiAgSG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUg Y2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExW cyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQu aWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLg0KDQpVcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhh dCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlz IG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2Vz cyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJh dGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1w cm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxh bmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3Vt ZSB0aGVzZSBUTFZzLiAgSWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1h d2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBp biB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRM ViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRo YXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBw cm9jZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBw bHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KRnJvbTogc2ZjIDxzZmMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmlt IEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+ DQpEYXRlOiBUaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgYXQgODoyMiBBTQ0KVG86ICJzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv c2ZjL3RpY2tldC8yMQ0KDQpEZWFyIFNGQyBXRzoNCg0KR2l2ZW4gdGhlIHJlY2VudCBkaXNjdXNz aW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHVwZGF0ZWQgdGV4dCAod2l0aCBjaGFuZ2VzIGluIFJF RCkgYXMgZm9sbG93czoNCg0KTkVXIGZvciBzZWN0aW9uIDMuNDoNClRoaXMgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBp biB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2Vz IG5vdCBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1l dGFkYXRhLg0KDQpBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGlj cyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0 b3J5IGNvbnRleHQgZmllbGQuICBUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRoZSBh bGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhv dyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUg c2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9uIHJlY2VpdmluZyBhbiBOU0ggTUQt dHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBtYW5k YXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0YSBz ZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJv Y2VzcyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5 IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxs b2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0 aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuDQoNCk5FVyBm b3IgZW5kIG9mIHNlY3Rpb24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFr ZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1l bnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVzZSBjb25zaWRl cmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250cm9sIHBs YW5lIGNhbiBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJlIG9m IFRMVnMgdG9nZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBvZiBb SS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9mIGEgcGFja2V0 IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRM ViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHBy b2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KSWYgbXVsdGlwbGUg bWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0 aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBv cmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3Zp ZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRl ciB0aGV5YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0Lg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5jZXMg b2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhlIGRl ZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJl IFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVycm9y LCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nLg0KDQpGcm9tOiBz ZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNo YXJAY2lzY28uY29tPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDgsIDIwMTYgYXQgMTowMSBQ TQ0KVG86ICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5v cmcvdHJhYy9zZmMvdGlja2V0LzIxDQoNCkRlYXIgU0ZDIFdHOg0KDQpBZnRlciBtdWNoIGRpc2N1 c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0ICMyMSB0aGUgZm9sbG93aW5n IHRleHQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5IG1ldGFkYXRhIHNlbWFudGlj cyBhbmQgc28gZm9ydGguIFBsZWFzZSByZXZpZXcgYW5kIGluZGljYXRlIHN1cHBvcnQgKG9yIG5v dCkgc28gdGhhdCB0aGUgY2hhaXJzIGNhbiBkZXRlcm1pbmUgY29uc2Vuc3VzIGFuZCB1cGRhdGUg dGhlIHRpY2tldCBhY2NvcmRpbmdseS4NCg0KVGhhbmsgeW91IQ0KDQpKaW0gJiBKb2VsDQoNCiMj IyMjIyMjIyMNCg0KTkVXIGZvciBzZWN0aW9uIDMuNDoNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2Vz IG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUg bWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBk ZXNjcmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRh Lg0KDQpBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJz dCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNv bnRleHQgZmllbGQuICBUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0 aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBT RkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUg b2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9uIHJlY2VpdmluZyBhbiBOU0ggTUQtdHlwZSAx IHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBtYW5kYXRvcnkg dXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0YSBzZW1hbnRp Y3MgZm9yIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0 aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpbZGNhbGxvY10gYW5kIFticm9h ZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdp dGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLg0KDQpO RVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xOg0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90 IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1w bGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiAgVGhlc2UgY29u c2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuICBIb3dldmVyLCB0aGUgY29udHJv bCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVy ZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMg b2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuDQoNClVwb24gcmVjZWlwdCBvZiBhIHBh Y2tldCB0aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2Vz cyBUTFYgaXMgbWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5P VCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQoNCklmIG11bHRp cGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNG UCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0 aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiAgSWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBw cm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUg b3JkZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFu Y2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRo ZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1h d2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJy b3IuDQo= --_000_E8355113905631478EFF04F5AA706E983115801Awtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KaW0sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCB0aGlzIHdvcmRpbmcuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoaXMgYWxsb3dzIHRoZSBpbXBsZW1lbnRlciB0byBjaG9vc2UgYW4gYXBwcm9h Y2ggdGhhdCBkb2VzIG5vdCBvdmVyd2hlbG0gdGhlIGRldmljZSB3aGVuIHRoZSBzeXN0ZW0gaXMg Y29uZmlndXJlZCBpbXByb3Blcmx5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBpdCB3ZXJlIOKAnE1VU1TigJ0s IEkgd291bGQgZXhwZWN0IG1vcmUgZGV0YWlscyBhYm91dCB3aGF0IGV4YWN0bHkgc2hvdWxkIGJl IGxvZ2dlZC4gT3RoZXJ3aXNlLCBob3cgY291bGQgb25lIHRlc3QgY29tcGxpYW5jZT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPi1EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5KaW0gR3VpY2hhcmQgKGpndWljaGFyKTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgTm92ZW1iZXIgMTAsIDIwMTYgODoyOCBBTTxicj4NCjxiPlRvOjwvYj4gc2ZjQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJh Yy9zZmMvdGlja2V0LzIxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPkRlYXIgU0ZDIFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BcG9s b2dpZXMsIGl0IHdhcyBwb2ludGVkIG91dCB0byBtZSB0aGF0IEkgbWlzc2VkIGFkZGluZyB0aGUg dGV4dCBhdCBhIHRoaXJkIGxvY2F0aW9uLiBDb3JyZWN0IHRleHQgYXMgZm9sbG93czo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJk O2NvbG9yOmJsYWNrIj5ORVcgZm9yIHNlY3Rpb24gMy40PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNr Ij46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1z dGFuZGFyZDtjb2xvcjpibGFjayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55 IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29u dGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBz dHJ1Y3R1cmUgb3IgbWVhbmluZw0KIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4gJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFy ZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1V U1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0 aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZuYnNw O1RoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24NCiBzY2hlbWEg YW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNG IGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5VcG9u IHJlY2VpdmluZyBhbiBOU0ggTUQtdHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBp cyBjb25maWd1cmVkIGZvciBtYW5kYXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHll dCByZWNlaXZlZCB0aGUgZGF0YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkNCiBjb250ZXh0 IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQ8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpyZWQi PiwgaXQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdl YmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6cmVkIj5TSE9V TEQNCiBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkg bG9nZ2luZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFy ZDtjb2xvcjpibGFjayI+W2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBzYW1wbGUg ZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRoZSBkYXRhIGNvbnZleWVkIGlu IHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj5ORVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJk O2NvbG9yOmJsYWNrIj46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMg bm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8t aW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiZuYnNwOyZu YnNwO1RoZXNlIGNvbnNpZGVyYXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiZuYnNwOyZu YnNwO0hvd2V2ZXIsDQogdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBT RnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNj b3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0p LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3Rh bmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPlVwb24gcmVjZWlwdCBv ZiBhIHBhY2tldCB0aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8t cHJvY2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBN VVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpyZWQiPiwNCiBpdDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpyZWQiPlNIT1VMRCBsb2cgdGhp cyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFj ayI+SWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9y IGEgZ2l2ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2Fy ZSBTRiB3aXRoIHRoZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuJm5ic3A7Jm5ic3A7SWYg bm8gaW5zdHJ1Y3Rpb25zDQogYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJv Y2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3Rh bmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIGlu c3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1 dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBT RkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6cmVk Ij4sDQogaXQmbmJzcDtTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUg bGltaXRpbmcgdG8gYW55IGxvZ2dpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbToNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+c2ZjICZsdDs8YSBocmVmPSJtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVo YWxmIG9mIEppbSBHdWljaGFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNv bSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXks IE5vdmVtYmVyIDEwLCAyMDE2IGF0IDg6MjIgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDogPC9iPlJlOiBbc2ZjXSA8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9z ZmMvdGlja2V0LzIxIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5EZWFyIFNGQyBXRzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R2l2ZW4g dGhlIHJlY2VudCBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHVwZGF0ZWQgdGV4dCAo d2l0aCBjaGFuZ2VzIGluIFJFRCkgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5ORVcg Zm9yIHNlY3Rpb24gMy40PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj46PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFj ayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQg dGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUg TlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmlu Zw0KIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1z dGFuZGFyZDtjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0 YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4g dGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNlbWFudGlj cyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24NCiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9m IHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2Vt YW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5VcG9uIHJlY2VpdmluZyBhbiBOU0gg TUQtdHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBt YW5kYXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0 YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkNCiBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5P VCBwcm9jZXNzIHRoZSBwYWNrZXQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpyZWQiPiwgaXQ8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xv cjpibGFjayI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpyZWQiPlNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5k IE1VU1QgYXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJs YWNrIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtp dC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+W2RjYWxsb2Nd IGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEg bWVhbmluZyB3aXRoIHRoZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBm aWVsZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0 LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5ORVcgZm9y IGVuZCBvZiBzZWN0aW9uIDMuNS4xPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj46PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xv cjpibGFjayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24g YWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQg YXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiZuYnNwOyZuYnNwO1RoZXNlIGNvbnNpZGVyYXRpb25z IGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiZuYnNwOyZuYnNwO0hvd2V2ZXIsDQogdGhlIGNvbnRy b2wgcGxhbmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1 cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4z IG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3Rh bmRhcmQ7Y29sb3I6YmxhY2siPlVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZyB0 byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMgbWlzc2luZyBp biB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNr ZXQgYW5kIE1VU1QNCiBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJk O2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSBy ZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0 aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1bWUgdGhlc2UgVExWcy4mbmJz cDsmbmJzcDtJZiBubyBpbnN0cnVjdGlvbnMNCiBhcmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUg U0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRoZXlhcHBlYXIgaW4gdGhl IE5TSCBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+SWYg bXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNI IHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZv ciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFy ZDtjb2xvcjpyZWQiPiwNCiBpdCZuYnNwO1NIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1Qg YXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5zZmMgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNo YXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UdWVzZGF5LCBOb3ZlbWJlciA4LCAyMDE2IGF0IDE6MDEgUE08YnI+DQo8Yj5UbzogPC9iPiZx dW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPltzZmNdIDxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90 cmFjL3NmYy90aWNrZXQvMjEiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQv MjE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5EZWFyIFNGQyBXRzo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5BZnRlciBtdWNoIGRpc2N1c3Npb24g b24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0ICMyMSB0aGUgZm9sbG93aW5nIHRleHQg aGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5IG1ldGFkYXRhIHNlbWFudGljcyBhbmQg c28gZm9ydGguIFBsZWFzZSByZXZpZXcgYW5kDQogaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90KSBz byB0aGF0IHRoZSBjaGFpcnMgY2FuIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHVwZGF0ZSB0aGUg dGlja2V0IGFjY29yZGluZ2x5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29s b3I6YmxhY2siPlRoYW5rIHlvdSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJs YWNrIj5KaW0gJmFtcDsgSm9lbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPiMjIyMjIyMjIyM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNr Ij5ORVcgZm9yIHNlY3Rpb24gMy40PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj46PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xv cjpibGFjayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24g YWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBv ZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3Ig bWVhbmluZw0KIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4gJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdl YmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0 aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFj ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNl bWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24NCiBzY2hlbWEgYW5kIHRoZSBtZWFu aW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRh dGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5VcG9uIHJlY2VpdmluZyBh biBOU0ggTUQtdHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVk IGZvciBtYW5kYXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0 aGUgZGF0YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkNCiBjb250ZXh0IGZpZWxkLCBpdCBN VVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+W2RjYWxsb2NdIGFuZCBbYnJvYWRh bGxvY10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRo IHRoZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5ORVcgZm9yIGVuZCBvZiBzZWN0 aW9uIDMuNS4xPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj46PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+VGhp cyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0 aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9y eS10by1wcm9jZXNzLiZuYnNwOyZuYnNwO1RoZXNlIGNvbnNpZGVyYXRpb25zIGFyZSBkZXBsb3lt ZW50LXNwZWNpZmljLiZuYnNwOyZuYnNwO0hvd2V2ZXIsDQogdGhlIGNvbnRyb2wgcGxhbmUgY2Fu IGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0 b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0 Zi1zZmMtY29udHJvbC1wbGFuZV0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6 YmxhY2siPlVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNG UCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0aGF0IHBhY2tl dCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QN CiBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNr Ij5JZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3Ig YSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJl IFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1bWUgdGhlc2UgVExWcy4mbmJzcDsmbmJzcDtJZiBu byBpbnN0cnVjdGlvbnMNCiBhcmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9j ZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFu ZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+SWYgbXVsdGlwbGUgaW5z dGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0 IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNG Qy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQNCiBhbmQgTVVTVCBsb2cgdGhp cyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E8355113905631478EFF04F5AA706E983115801Awtlexchp2sandvi_-- From nobody Thu Nov 10 07:02:07 2016 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 78CB81294A8 for ; Thu, 10 Nov 2016 07:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.115 X-Spam-Level: X-Spam-Status: No, score=-4.115 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=-1.497, 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 eRMJccBOeG8C for ; Thu, 10 Nov 2016 07:02:03 -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 377C3129424 for ; Thu, 10 Nov 2016 07:02:03 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 559C4C0D01; Thu, 10 Nov 2016 16:02:01 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 1C0601A0078; Thu, 10 Nov 2016 16:02:01 +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; Thu, 10 Nov 2016 16:02:00 +0100 From: To: Dave Dolson , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5dhBvoux3dU2uL7kFD+H1LqDSRqwAgAAFRGCAAALUIA== Date: Thu, 10 Nov 2016 15:02:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DAF5CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DAF5CEOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 15:02:05 -0000 --_000_787AE7BB302AE849A7480A190F8B933009DAF5CEOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2ZSwNCg0KVGhlIGltcGxlbWVudGF0aW9uIG11c3QgZGVmaW5pdGVseSBsb2cgdGhlIGVy cm9yOiB0aGF0IGlzLCB0aGVyZSBpcyBhIG1pc3NpbmcgbWFuZGF0b3J5IG1ldGFkYXRhIGZvciBh IGNoYWluLiBJdCBkb2VzIG5vdCBuZWVkIHRvIGFkZCBhbiBlbnRyeSBwZXIgcGFja2V0IGFzIHdh cyByaWdodGZ1bGx5IG1lbnRpb25lZCBieSBSb24uDQoNCkhvdyB0byBwcm90ZWN0IGFuIGltcGxl bWVudGF0aW9uIGZyb20gbWlzY29uZmlndXJhdGlvbiBpcyBub3Qgc3BlY2lmaWMgdG8gdGhlIGxv Z2dpbmcgZmVhdHVyZSwgYnV0IGl0IGlzIGEgZ2VuZXRpYyBjb25jZXJuIElNSE8uDQoNCkNoZWVy cywNCk1lZA0KDQpEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBw YXJ0IGRlIERhdmUgRG9sc29uDQpFbnZvecOpIDogamV1ZGkgMTAgbm92ZW1icmUgMjAxNiAxNTo0 OQ0Kw4AgOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnDQpPYmpldCA6IFJl OiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxDQoNCkppbSwN CkkgYWdyZWUgd2l0aCB0aGlzIHdvcmRpbmcuDQpUaGlzIGFsbG93cyB0aGUgaW1wbGVtZW50ZXIg dG8gY2hvb3NlIGFuIGFwcHJvYWNoIHRoYXQgZG9lcyBub3Qgb3ZlcndoZWxtIHRoZSBkZXZpY2Ug d2hlbiB0aGUgc3lzdGVtIGlzIGNvbmZpZ3VyZWQgaW1wcm9wZXJseS4NCg0KSWYgaXQgd2VyZSDi gJxNVVNU4oCdLCBJIHdvdWxkIGV4cGVjdCBtb3JlIGRldGFpbHMgYWJvdXQgd2hhdCBleGFjdGx5 IHNob3VsZCBiZSBsb2dnZWQuIE90aGVyd2lzZSwgaG93IGNvdWxkIG9uZSB0ZXN0IGNvbXBsaWFu Y2U/DQoNCi1EYXZlDQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KU2VudDogVGh1cnNkYXksIE5v dmVtYmVyIDEwLCAyMDE2IDg6MjggQU0NClRvOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMv dGlja2V0LzIxDQoNCkRlYXIgU0ZDIFdHOg0KDQpBcG9sb2dpZXMsIGl0IHdhcyBwb2ludGVkIG91 dCB0byBtZSB0aGF0IEkgbWlzc2VkIGFkZGluZyB0aGUgdGV4dCBhdCBhIHRoaXJkIGxvY2F0aW9u LiBDb3JyZWN0IHRleHQgYXMgZm9sbG93czoNCg0KTkVXIGZvciBzZWN0aW9uIDMuNDoNClRoaXMg c3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250 ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFk ZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhl IGluY2x1ZGVkIG1ldGFkYXRhLg0KDQpBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBk YXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBp biB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuICBUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVk ZSBib3RoIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1 ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9uIHJlY2Vpdmlu ZyBhbiBOU0ggTUQtdHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1 cmVkIGZvciBtYW5kYXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZl ZCB0aGUgZGF0YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQg TVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFu ZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCltkY2FsbG9jXSBh bmQgW2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1l YW5pbmcgd2l0aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmll bGQuDQoNCk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24g ZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9y eS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBU aGVzZSBjb25zaWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRo ZSBjb250cm9sIHBsYW5lIGNhbiBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEg c3RydWN0dXJlIG9mIFRMVnMgdG9nZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlv biAzLjMuMyBvZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0 IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10 by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNG IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVycm9yLCBh bmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nLg0KDQpJZiBtdWx0aXBs ZSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAs IHRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhl IG9yZGVyIHRvIGNvbnN1bWUgdGhlc2UgVExWcy4gIElmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJv dmlkZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9y ZGVyIHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuDQoNCklmIG11bHRpcGxlIGluc3RhbmNl cyBvZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0aGUg ZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMtYXdh cmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJy b3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCkZyb206 IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mIEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDE2IGF0IDg6 MjIgQU0NClRvOiAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzZmNdIGh0dHBzOi8vdHJh Yy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCg0KRGVhciBTRkMgV0c6DQoNCkdpdmVuIHRo ZSByZWNlbnQgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0LCB1cGRhdGVkIHRleHQgKHdp dGggY2hhbmdlcyBpbiBSRUQpIGFzIGZvbGxvd3M6DQoNCk5FVyBmb3Igc2VjdGlvbiAzLjQ6DQpU aGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUg Y29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0gg aGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nIG9m IHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4NCg0KQW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0 aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFj ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiAgVGhlIGRhdGEgc2VtYW50aWNzIGlu Y2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBp bmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNz IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KVXBvbiByZWNl aXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlmIHRoZSBTRkMtYXdhcmUgU0YgaXMgY29u ZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBtZXRhZGF0YSBidXQgaGFzIG5vdCB5ZXQgcmVj ZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIGZvciB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQs IGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVycm9y LCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nLg0KDQpbZGNhbGxv Y10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUg YSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0 IGZpZWxkLg0KDQpORVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xOg0KVGhpcyBzcGVjaWZpY2F0 aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5k YXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNz LiAgVGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuICBIb3dldmVy LCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBk YXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNl Y3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuDQoNClVwb24gcmVj ZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRv cnktdG8tcHJvY2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2Fy ZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3Iu DQoNCklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZv ciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdh cmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiAgSWYgbm8gaW5zdHJ1 Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2Ug VExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVs dGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBh Y2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBp dCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VM RCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9n Z2luZy4NCg0KRnJvbTogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5j b208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBOb3ZlbWJlciA4 LCAyMDE2IGF0IDE6MDEgUE0NClRvOiAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NmY10gaHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMQ0KDQpEZWFyIFNGQyBXRzoNCg0K QWZ0ZXIgbXVjaCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IHdpdGggcmVnYXJkIHRvIHRpY2tldCAj MjEgdGhlIGZvbGxvd2luZyB0ZXh0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGhlbHAgY2xhcmlmeSBt ZXRhZGF0YSBzZW1hbnRpY3MgYW5kIHNvIGZvcnRoLiBQbGVhc2UgcmV2aWV3IGFuZCBpbmRpY2F0 ZSBzdXBwb3J0IChvciBub3QpIHNvIHRoYXQgdGhlIGNoYWlycyBjYW4gZGV0ZXJtaW5lIGNvbnNl bnN1cyBhbmQgdXBkYXRlIHRoZSB0aWNrZXQgYWNjb3JkaW5nbHkuDQoNClRoYW5rIHlvdSENCg0K SmltICYgSm9lbA0KDQojIyMjIyMjIyMjDQoNCk5FVyBmb3Igc2VjdGlvbiAzLjQ6DQpUaGlzIHNw ZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVu dCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVy LCBhbmQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nIG9mIHRoZSBp bmNsdWRlZCBtZXRhZGF0YS4NCg0KQW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0 YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4g dGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiAgVGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUg Ym90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRl ZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91 dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KVXBvbiByZWNlaXZpbmcg YW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlmIHRoZSBTRkMtYXdhcmUgU0YgaXMgY29uZmlndXJl ZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBtZXRhZGF0YSBidXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQg dGhlIGRhdGEgc2VtYW50aWNzIGZvciB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1V U1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KW2Rj YWxsb2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2Np YXRlIGEgbWVhbmluZyB3aXRoIHRoZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29u dGV4dCBmaWVsZC4NCg0KTkVXIGZvciBlbmQgb2Ygc2VjdGlvbiAzLjUuMToNClRoaXMgc3BlY2lm aWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUg bWFuZGF0b3J5LXRvLWltcGxlbWVudCBvciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJv Y2Vzcy4gIFRoZXNlIGNvbnNpZGVyYXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiAgSG93 ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0 aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNl ZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLg0KDQpVcG9u IHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFu ZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMt YXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVy cm9yLg0KDQpJZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJl ZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZD LWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1bWUgdGhlc2UgVExWcy4gIElmIG5vIGlu c3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRo ZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuDQoNCklm IG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5T SCBwYWNrZXQsIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBm b3IgaXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBN VVNUIGxvZyB0aGlzIGVycm9yLg0K --_000_787AE7BB302AE849A7480A190F8B933009DAF5CEOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJ e21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxl LW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQsIGRp di5CYWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv bnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhp IERhdmUsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgaW1wbGVt ZW50YXRpb24gbXVzdCBkZWZpbml0ZWx5IGxvZyB0aGUgZXJyb3I6IHRoYXQgaXMsIHRoZXJlIGlz IGEgbWlzc2luZyBtYW5kYXRvcnkgbWV0YWRhdGEgZm9yIGEgY2hhaW4uIEl0IGRvZXMgbm90IG5l ZWQgdG8gYWRkIGFuIGVudHJ5IHBlciBwYWNrZXQNCiBhcyB3YXMgcmlnaHRmdWxseSBtZW50aW9u ZWQgYnkgUm9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+SG93IHRvIHByb3RlY3QgYW4gaW1wbGVtZW50YXRpb24gZnJvbSBtaXNjb25maWd1cmF0 aW9uIGlzIG5vdCBzcGVjaWZpYyB0byB0aGUgbG9nZ2luZyBmZWF0dXJlLCBidXQgaXQgaXMgYSBn ZW5ldGljIGNvbmNlcm4gSU1ITy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5E ZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgPC9iPjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cGFydCBkZTwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEYXZlIERvbHNvbjxicj4NCjxiPkVudm95w6kmbmJzcDs6 PC9iPiBqZXVkaSAxMCBub3ZlbWJyZSAyMDE2IDE1OjQ5PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBK aW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6 PC9iPiBSZTogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmltLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIHRoaXMgd29y ZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgYWxs b3dzIHRoZSBpbXBsZW1lbnRlciB0byBjaG9vc2UgYW4gYXBwcm9hY2ggdGhhdCBkb2VzIG5vdCBv dmVyd2hlbG0gdGhlIGRldmljZSB3aGVuIHRoZSBzeXN0ZW0gaXMgY29uZmlndXJlZCBpbXByb3Bl cmx5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIGl0IHdlcmUg4oCc TVVTVOKAnSwgSSB3b3VsZCBleHBlY3QgbW9yZSBkZXRhaWxzIGFib3V0IHdoYXQgZXhhY3RseSBz aG91bGQgYmUgbG9nZ2VkLiBPdGhlcndpc2UsIGhvdyBjb3VsZCBvbmUgdGVzdCBjb21wbGlhbmNl PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFs8YSBocmVmPSJtYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkppbSBHdWljaGFyZCAoamd1aWNoYXIpPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgMjAxNiA4OjI4IEFNPGJyPg0KPGI+VG86PC9i PiA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSA8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJh Yy9zZmMvdGlja2V0LzIxIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIx PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWFyIFNGQyBXRzo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BcG9sb2dp ZXMsIGl0IHdhcyBwb2ludGVkIG91dCB0byBtZSB0aGF0IEkgbWlzc2VkIGFkZGluZyB0aGUgdGV4 dCBhdCBhIHRoaXJkIGxvY2F0aW9uLiBDb3JyZWN0IHRleHQgYXMgZm9sbG93czo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgc3BlY2lm aWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBs YWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFu ZCBkb2VzIG5vdCBkZXNjcmliZQ0KIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5j bHVkZWQgbWV0YWRhdGEuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1VU1Qg cmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUg ZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZuYnNwO1Ro ZSBkYXRhIHNlbWFudGljcw0KIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5k IHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdl dHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lm aWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFj a2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ug b2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcw0K IGZvciB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhl IHBhY2tldDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpyZWQiPiwgaXQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFy ZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpyZWQiPlNIT1VMRA0KIGxvZyB0aGlzIGVy cm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBl eGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4g dGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TkVXIGZvciBlbmQg b2Ygc2VjdGlvbiAzLjUuMTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMg bm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8t aW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiZuYnNwOyZu YnNwO1RoZXNlIGNvbnNpZGVyYXRpb25zDQogYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuJm5ic3A7 Jm5ic3A7SG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBT RnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNj b3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0p LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEg Z2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRo YXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFja2V0 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OnJlZCI+LCBpdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+U0hPVUxEDQogbG9nIHRoaXMgZXJyb3IsIGFu ZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmc8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVk IGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMt YXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZQ0KIHRoZXNlIFRMVnMuJm5ic3A7Jm5i c3A7SWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNU IHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBh Y2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYg YXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0 IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVA0KIE5PVCBw cm9jZXNzIHRoZSBwYWNrZXQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj4sIGl0Jm5ic3A7U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBh bmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5zZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgSmltIEd1 aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBj aXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMTAs IDIwMTYgYXQgODoyMiBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtzZmNdIDxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjEi Pmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjE8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+RGVhciBTRkMgV0c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R2l2ZW4gdGhlIHJlY2VudCBkaXNjdXNz aW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHVwZGF0ZWQgdGV4dCAod2l0aCBjaGFuZ2VzIGluIFJF RCkgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPlRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0 aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmll bGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmliZQ0KIHRoZSBzdHJ1Y3R1 cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuICZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+QW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3Qg aW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250 ZXh0IGZpZWxkLiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNlbWFudGljcw0KIGluY2x1ZGUgYm90aCB0 aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRh LiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlVwb24gcmVjZWl2 aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZp Z3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2Vp dmVkIHRoZSBkYXRhIHNlbWFudGljcw0KIGZvciB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQs IGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFy ZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpyZWQiPiwgaXQ8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+ U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFu eSBsb2dnaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9j XSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhl IGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+TkVXIGZvciBlbmQgb2Ygc2VjdGlvbiAzLjUuMTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBz cGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0 IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10 by1wcm9jZXNzLiZuYnNwOyZuYnNwO1RoZXNlIGNvbnNpZGVyYXRpb25zDQogYXJlIGRlcGxveW1l bnQtc3BlY2lmaWMuJm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGlu c3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0b2dl dGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1z ZmMtY29udHJvbC1wbGFuZV0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0 IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRM ViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHBy b2Nlc3MNCiB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0 LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ SWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEg Z2l2ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBT RiB3aXRoIHRoZSBvcmRlciB0byBjb25zdW1lDQogdGhlc2UgVExWcy4mbmJzcDsmbmJzcDtJZiBu byBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2Vz cyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5j bHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRv ZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUDQogTk9UIHByb2Nlc3Mg dGhlIHBhY2tldDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpyZWQiPiwgaXQmbmJzcDtTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNU IGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3Rh bmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPnNmYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn Ij5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQg Jmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE5vdmVtYmVyIDgsIDIwMTYgYXQg MTowMSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W3NmY10gPGEgaHJl Zj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90cmFj LmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+RGVhciBTRkMgV0c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BZnRlciBtdWNoIGRpc2N1c3Npb24gb24g dGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0ICMyMSB0aGUgZm9sbG93aW5nIHRleHQgaGFz IGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5IG1ldGFkYXRhIHNlbWFudGljcyBhbmQgc28g Zm9ydGguDQogUGxlYXNlIHJldmlldyBhbmQgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90KSBzbyB0 aGF0IHRoZSBjaGFpcnMgY2FuIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHVwZGF0ZSB0aGUgdGlj a2V0IGFjY29yZGluZ2x5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91ITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+SmltICZhbXA7IEpvZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiMjIyMjIyMjIyM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgc3BlY2lmaWNhdGlvbiBk b2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0 aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5v dCBkZXNjcmliZQ0KIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0 YWRhdGEuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0 aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFj ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNl bWFudGljcw0KIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFu aW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRh dGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0 aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRh dGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcw0KIGZvciB0aGUg bWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBh bmQgTVVTVCBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltkY2FsbG9jXSBhbmQgW2Jyb2Fk YWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0 aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5ORVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xPC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdl YmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+OjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5U aGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZz IHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0 b3J5LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMNCiBhcmUgZGVw bG95bWVudC1zcGVjaWZpYy4mbmJzcDsmbmJzcDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBj YW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZz IHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5p ZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5VcG9uIHJlY2VpcHQgb2YgYSBw YWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nl c3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBO T1QgcHJvY2Vzcw0KIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5JZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBm b3IgYSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3 YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1bWUNCiB0aGVzZSBUTFZzLiZuYnNwOyZuYnNw O0lmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBw cm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNr ZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFy ZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBU TFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QNCiBOT1QgcHJv Y2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933009DAF5CEOPEXCLILMA3corp_-- From nobody Thu Nov 10 07:11:34 2016 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 9389E1296F6 for ; Thu, 10 Nov 2016 07:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 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, RP_MATCHES_RCVD=-1.497] 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 dbgZSLm82q-N for ; Thu, 10 Nov 2016 07:11:30 -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 B8BDA129676 for ; Thu, 10 Nov 2016 07:11:29 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0319.002; Thu, 10 Nov 2016 10:11:28 -0500 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5dhBvoux3dU2uL7kFD+H1LqDSRqwAgAAFRGCAAALUIIAAA+fw Date: Thu, 10 Nov 2016 15:11:27 +0000 Message-ID: References: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> <787AE7BB302AE849A7480A190F8B933009DAF5CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAF5CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9831158210wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 15:11:32 -0000 --_000_E8355113905631478EFF04F5AA706E9831158210wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28geW91IHdvdWxkIHNheSwg4oCcTVVTVCBsb2cgYXQgbGVhc3Qgb25jZSBwZXIgdHlwZSBvZiBt aXNzaW5nIG1hbmRhdG9yeSBtZXRhZGF0YeKAnSA/DQoNCg0KDQpGcm9tOiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NClNl bnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgMjAxNiAxMDowMiBBTQ0KVG86IERhdmUgRG9sc29u OyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3Nm Y10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMQ0KDQpIaSBEYXZlLA0K DQpUaGUgaW1wbGVtZW50YXRpb24gbXVzdCBkZWZpbml0ZWx5IGxvZyB0aGUgZXJyb3I6IHRoYXQg aXMsIHRoZXJlIGlzIGEgbWlzc2luZyBtYW5kYXRvcnkgbWV0YWRhdGEgZm9yIGEgY2hhaW4uIEl0 IGRvZXMgbm90IG5lZWQgdG8gYWRkIGFuIGVudHJ5IHBlciBwYWNrZXQgYXMgd2FzIHJpZ2h0ZnVs bHkgbWVudGlvbmVkIGJ5IFJvbi4NCg0KSG93IHRvIHByb3RlY3QgYW4gaW1wbGVtZW50YXRpb24g ZnJvbSBtaXNjb25maWd1cmF0aW9uIGlzIG5vdCBzcGVjaWZpYyB0byB0aGUgbG9nZ2luZyBmZWF0 dXJlLCBidXQgaXQgaXMgYSBnZW5ldGljIGNvbmNlcm4gSU1ITy4NCg0KQ2hlZXJzLA0KTWVkDQoN CkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgRGF2 ZSBEb2xzb24NCkVudm95w6kgOiBqZXVkaSAxMCBub3ZlbWJyZSAyMDE2IDE1OjQ5DQrDgCA6IEpp bSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Ck9iamV0IDogUmU6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQv MjENCg0KSmltLA0KSSBhZ3JlZSB3aXRoIHRoaXMgd29yZGluZy4NClRoaXMgYWxsb3dzIHRoZSBp bXBsZW1lbnRlciB0byBjaG9vc2UgYW4gYXBwcm9hY2ggdGhhdCBkb2VzIG5vdCBvdmVyd2hlbG0g dGhlIGRldmljZSB3aGVuIHRoZSBzeXN0ZW0gaXMgY29uZmlndXJlZCBpbXByb3Blcmx5Lg0KDQpJ ZiBpdCB3ZXJlIOKAnE1VU1TigJ0sIEkgd291bGQgZXhwZWN0IG1vcmUgZGV0YWlscyBhYm91dCB3 aGF0IGV4YWN0bHkgc2hvdWxkIGJlIGxvZ2dlZC4gT3RoZXJ3aXNlLCBob3cgY291bGQgb25lIHRl c3QgY29tcGxpYW5jZT8NCg0KLURhdmUNCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpTZW50OiBU aHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgODoyOCBBTQ0KVG86IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL3NmYy90aWNrZXQvMjENCg0KRGVhciBTRkMgV0c6DQoNCkFwb2xvZ2llcywgaXQgd2Fz IHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQgSSBtaXNzZWQgYWRkaW5nIHRoZSB0ZXh0IGF0IGEgdGhp cmQgbG9jYXRpb24uIENvcnJlY3QgdGV4dCBhcyBmb2xsb3dzOg0KDQpORVcgZm9yIHNlY3Rpb24g My40Og0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJv dXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0 aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVh bmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuDQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJl Y2VpdmUgdGhlIGRhdGEgc2VtYW50aWNzIGZpcnN0IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRh dGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFu dGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBv ZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNl bWFudGljcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClVw b24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNG IGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3Qg eWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0 IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhp cyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0K W2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNz b2NpYXRlIGEgbWVhbmluZyB3aXRoIHRoZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkg Y29udGV4dCBmaWVsZC4NCg0KTkVXIGZvciBlbmQgb2Ygc2VjdGlvbiAzLjUuMToNClRoaXMgc3Bl Y2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBh cmUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBvciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8t cHJvY2Vzcy4gIFRoZXNlIGNvbnNpZGVyYXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiAg SG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0 aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3Bpbmcg KFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLg0KDQpV cG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEg bWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBT RkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRo aXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoN CklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBh IGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUg U0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiAgSWYgbm8gaW5zdHJ1Y3Rp b25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExW cyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlw bGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tl dCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwg dGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBs b2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2lu Zy4NCg0KRnJvbTogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208 bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgTm92ZW1iZXIgMTAs IDIwMTYgYXQgODoyMiBBTQ0KVG86ICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4i IDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10g aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMQ0KDQpEZWFyIFNGQyBXRzoN Cg0KR2l2ZW4gdGhlIHJlY2VudCBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHVwZGF0 ZWQgdGV4dCAod2l0aCBjaGFuZ2VzIGluIFJFRCkgYXMgZm9sbG93czoNCg0KTkVXIGZvciBzZWN0 aW9uIDMuNDoNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9u IGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQg b2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9y IG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLg0KDQpBbiBTRkMtYXdhcmUgU0YgTVVT VCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRo ZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuICBUaGUgZGF0YSBz ZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5p bmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0 YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0K DQpVcG9uIHJlY2VpdmluZyBhbiBOU0ggTUQtdHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2Fy ZSBTRiBpcyBjb25maWd1cmVkIGZvciBtYW5kYXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMg bm90IHlldCByZWNlaXZlZCB0aGUgZGF0YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkgY29u dGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9n IHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcu DQoNCltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRv IGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0 b3J5IGNvbnRleHQgZmllbGQuDQoNCk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE6DQpUaGlz IHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRo YXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5 LXRvLXByb2Nlc3MuICBUaGVzZSBjb25zaWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZp Yy4gIEhvd2V2ZXIsIHRoZSBjb250cm9sIHBsYW5lIGNhbiBpbnN0cnVjdCBTRkMtYXdhcmUgU0Zz IHdpdGggdGhlIGRhdGEgc3RydWN0dXJlIG9mIFRMVnMgdG9nZXRoZXIgd2l0aCB0aGVpciBzY29w aW5nIChTZWUgU2VjdGlvbiAzLjMuMyBvZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4N Cg0KVXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBp ZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0 aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cg dGhpcyBlcnJvci4NCg0KSWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUg cmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3Qg dGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuICBJ ZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJv Y2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0 Lg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBp biBhbiBOU0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3Qg YWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tl dCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5n IHRvIGFueSBsb2dnaW5nLg0KDQpGcm9tOiBzZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgPGpndWlj aGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4NCkRhdGU6IFR1ZXNkYXks IE5vdmVtYmVyIDgsIDIwMTYgYXQgMTowMSBQTQ0KVG86ICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0 OiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxDQoNCkRlYXIg U0ZDIFdHOg0KDQpBZnRlciBtdWNoIGRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQg dG8gdGlja2V0ICMyMSB0aGUgZm9sbG93aW5nIHRleHQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVs cCBjbGFyaWZ5IG1ldGFkYXRhIHNlbWFudGljcyBhbmQgc28gZm9ydGguIFBsZWFzZSByZXZpZXcg YW5kIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgc28gdGhhdCB0aGUgY2hhaXJzIGNhbiBkZXRl cm1pbmUgY29uc2Vuc3VzIGFuZCB1cGRhdGUgdGhlIHRpY2tldCBhY2NvcmRpbmdseS4NCg0KVGhh bmsgeW91IQ0KDQpKaW0gJiBKb2VsDQoNCiMjIyMjIyMjIyMNCg0KTkVXIGZvciBzZWN0aW9uIDMu NDoNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0 IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhl IE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5p bmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLg0KDQpBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNl aXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRh IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuICBUaGUgZGF0YSBzZW1hbnRp Y3MgaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2Yg dGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1h bnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9u IHJlY2VpdmluZyBhbiBOU0ggTUQtdHlwZSAxIHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBp cyBjb25maWd1cmVkIGZvciBtYW5kYXRvcnkgdXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHll dCByZWNlaXZlZCB0aGUgZGF0YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkgY29udGV4dCBm aWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVy cm9yLg0KDQpbZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxl cyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1h bmRhdG9yeSBjb250ZXh0IGZpZWxkLg0KDQpORVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xOg0K VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExW cyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRh dG9yeS10by1wcm9jZXNzLiAgVGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3Bl Y2lmaWMuICBIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJl IFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIg c2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5l XSkuDQoNClVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNG UCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMgbWlzc2luZyBpbiB0aGF0IHBhY2tl dCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1Qg bG9nIHRoaXMgZXJyb3IuDQoNCklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMg YXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3Ry dWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZz LiAgSWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNU IHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBh Y2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVk ZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMg bm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBw YWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQo= --_000_E8355113905631478EFF04F5AA706E9831158210wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLlRleHRlZGVi dWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1u YW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMg Q2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5U ZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxl cyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtdGFi LXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxl MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4u RW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIHlvdSB3b3VsZCBz YXksIOKAnE1VU1QgbG9nIGF0IGxlYXN0IG9uY2UgcGVyIHR5cGUgb2YgbWlzc2luZyBtYW5kYXRv cnkgbWV0YWRhdGHigJ0gPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDE2IDEw OjAyIEFNPGJyPg0KPGI+VG86PC9iPiBEYXZlIERvbHNvbjsgSmltIEd1aWNoYXJkIChqZ3VpY2hh cik7IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NmY10gaHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkg RGF2ZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBpbXBsZW1lbnRh dGlvbiBtdXN0IGRlZmluaXRlbHkgbG9nIHRoZSBlcnJvcjogdGhhdCBpcywgdGhlcmUgaXMgYSBt aXNzaW5nIG1hbmRhdG9yeSBtZXRhZGF0YSBmb3IgYSBjaGFpbi4gSXQgZG9lcyBub3QgbmVlZCB0 byBhZGQgYW4gZW50cnkgcGVyIHBhY2tldCBhcyB3YXMgcmlnaHRmdWxseQ0KIG1lbnRpb25lZCBi eSBSb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SG93IHRvIHByb3RlY3QgYW4gaW1wbGVt ZW50YXRpb24gZnJvbSBtaXNjb25maWd1cmF0aW9uIGlzIG5vdCBzcGVjaWZpYyB0byB0aGUgbG9n Z2luZyBmZWF0dXJlLCBidXQgaXQgaXMgYSBnZW5ldGljIGNvbmNlcm4gSU1ITy4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgPC9iPjwvc3Bhbj48Yj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnBhcnQgZGU8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERhdmUgRG9sc29uPGJyPg0KPGI+RW52 b3nDqSZuYnNwOzo8L2I+IGpldWRpIDEwIG5vdmVtYnJlIDIwMTYgMTU6NDk8YnI+DQo8Yj7DgCZu YnNwOzo8L2I+IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyA8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Nm Y10gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+aHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KaW0sPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCB0aGlzIHdvcmRpbmcuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgYWxsb3dzIHRoZSBpbXBsZW1lbnRlciB0byBjaG9vc2Ug YW4gYXBwcm9hY2ggdGhhdCBkb2VzIG5vdCBvdmVyd2hlbG0gdGhlIGRldmljZSB3aGVuIHRoZSBz eXN0ZW0gaXMgY29uZmlndXJlZCBpbXByb3Blcmx5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBpdCB3ZXJlIOKA nE1VU1TigJ0sIEkgd291bGQgZXhwZWN0IG1vcmUgZGV0YWlscyBhYm91dCB3aGF0IGV4YWN0bHkg c2hvdWxkIGJlIGxvZ2dlZC4gT3RoZXJ3aXNlLCBob3cgY291bGQgb25lIHRlc3QgY29tcGxpYW5j ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi1EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5KaW0gR3VpY2hhcmQgKGpndWljaGFyKTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92 ZW1iZXIgMTAsIDIwMTYgODoyOCBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nm Y10gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+aHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGVhciBTRkMgV0c6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkFwb2xvZ2llcywgaXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1l IHRoYXQgSSBtaXNzZWQgYWRkaW5nIHRoZSB0ZXh0IGF0IGEgdGhpcmQgbG9jYXRpb24uIENvcnJl Y3QgdGV4dCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAz LjQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13 ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNp ZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBw bGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBh bmQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nDQogb2YgdGhlIGlu Y2x1ZGVkIG1ldGFkYXRhLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9y OmJsYWNrIj5BbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBm aXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5 IGNvbnRleHQgZmllbGQuJm5ic3A7Jm5ic3A7VGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90 aCB0aGUgYWxsb2NhdGlvbg0KIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVk IGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0 c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7Y29sb3I6YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFj a2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ug b2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBm b3IgdGhlIG1hbmRhdG9yeQ0KIGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhl IHBhY2tldDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOnJlZCI+LCBpdDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtp dC1zdGFuZGFyZDtjb2xvcjpyZWQiPlNIT1VMRA0KIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBh cHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFti cm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5n IHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRh cmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPk5FVyBmb3IgZW5kIG9m IHNlY3Rpb24gMy41LjE8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNr Ij5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBU TFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFu ZGF0b3J5LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIGRl cGxveW1lbnQtc3BlY2lmaWMuJm5ic3A7Jm5ic3A7SG93ZXZlciwNCiB0aGUgY29udHJvbCBwbGFu ZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBU TFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0kt RC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2 ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQg cGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOnJlZCI+LA0KIGl0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJk O2NvbG9yOnJlZCI+U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxp bWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJv Y2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBsYW5l IE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1bWUg dGhlc2UgVExWcy4mbmJzcDsmbmJzcDtJZiBubyBpbnN0cnVjdGlvbnMNCiBhcmUgcHJvdmlkZWQs IHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRo ZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjayI+SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5j bHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRv ZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzIHRo ZSBwYWNrZXQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpyZWQiPiwNCiBpdCZuYnNwO1NIT1VMRCBsb2cgdGhpcyBl cnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJk O2NvbG9yOmJsYWNrIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5zZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJkICZsdDs8YSBocmVm PSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgYXQgODoyMiBBTTxi cj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIDxhIGhyZWY9Imh0 dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjEiPmh0dHBzOi8vdHJhYy5pZXRm Lm9yZy90cmFjL3NmYy90aWNrZXQvMjE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgU0ZDIFdHOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5HaXZlbiB0aGUgcmVjZW50IGRpc2N1c3Npb24gb24gdGhlIG1h aWxpbmcgbGlzdCwgdXBkYXRlZCB0ZXh0ICh3aXRoIGNoYW5nZXMgaW4gUkVEKSBhcyBmb2xsb3dz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29s b3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg bWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRh dG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3Jp YmUgdGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nDQogb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLiAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0 LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5BbiBTRkMtYXdh cmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBw cm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuJm5i c3A7Jm5ic3A7VGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbg0K IHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMt YXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3 YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhh cyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeQ0K IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2Nv bG9yOnJlZCI+LCBpdDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOnJlZCI+ U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFu eSBsb2dnaW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBs ZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQg aW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3Rh bmRhcmQ7Y29sb3I6YmxhY2siPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRh cmQ7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9l cyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10 by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuJm5ic3A7 Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuJm5ic3A7 Jm5ic3A7SG93ZXZlciwNCiB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJl IFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIg c2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5l XSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1z dGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0 IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10 by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNG IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVA0KIGxvZyB0aGlzIGVycm9yLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRh cmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIG1hbmRh dG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNv bnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIg dG8gY29uc3VtZSB0aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmIG5vIGluc3RydWN0aW9ucw0KIGFy ZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0 aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0 LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUg VExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2Yg dGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9U IHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOnJlZCI+LA0KIGl0Jm5ic3A7U0hPVUxE IGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dn aW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJr aXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPnNmYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn Ij5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQg Jmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE5vdmVtYmVyIDgsIDIwMTYgYXQg MTowMSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W3NmY10gPGEgaHJl Zj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90cmFj LmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6 YmxhY2siPkRlYXIgU0ZDIFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPkFmdGVyIG11Y2ggZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB3aXRoIHJlZ2FyZCB0byB0aWNr ZXQgIzIxIHRoZSBmb2xsb3dpbmcgdGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxwIGNsYXJp ZnkgbWV0YWRhdGEgc2VtYW50aWNzIGFuZCBzbyBmb3J0aC4gUGxlYXNlIHJldmlldyBhbmQNCiBp bmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIHNvIHRoYXQgdGhlIGNoYWlycyBjYW4gZGV0ZXJtaW5l IGNvbnNlbnN1cyBhbmQgdXBkYXRlIHRoZSB0aWNrZXQgYWNjb3JkaW5nbHkuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+VGhhbmsgeW91ITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPkppbSAmYW1wOyBKb2VsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+IyMjIyMjIyMjIzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13 ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRh cmQ7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9l cyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhl IG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3Qg ZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nDQogb2YgdGhlIGluY2x1ZGVkIG1ldGFk YXRhLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5BbiBT RkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRl ciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmll bGQuJm5ic3A7Jm5ic3A7VGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2Nh dGlvbg0KIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBh biBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29s b3I6YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUg U0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEg YnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlIG1hbmRh dG9yeQ0KIGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQg TVVTVCBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJs YWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0 byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRh dG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6 YmxhY2siPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0 LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBh bnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQg b3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2Ug Y29uc2lkZXJhdGlvbnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuJm5ic3A7Jm5ic3A7SG93ZXZl ciwNCiB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRo ZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2Vl IFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0 IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRM ViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHBy b2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVA0KIGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13 ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9j ZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUg TUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0 aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmIG5vIGluc3RydWN0aW9ucw0KIGFyZSBwcm92aWRlZCwg dGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhl eWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2Nv bG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNs dWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9l cyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhl IHBhY2tldA0KIGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E8355113905631478EFF04F5AA706E9831158210wtlexchp2sandvi_-- From nobody Thu Nov 10 07:20:57 2016 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 D67CC129722 for ; Thu, 10 Nov 2016 07:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.115 X-Spam-Level: X-Spam-Status: No, score=-4.115 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=-1.497, 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 NJCCZdJ8fQPH for ; Thu, 10 Nov 2016 07:20:53 -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 4424A1296FD for ; Thu, 10 Nov 2016 07:20:53 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 02616180A72; Thu, 10 Nov 2016 16:20:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id C19AE20068; Thu, 10 Nov 2016 16:20:51 +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; Thu, 10 Nov 2016 16:20:51 +0100 From: To: Dave Dolson , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5dhBvoux3dU2uL7kFD+H1LqDSRqwAgAAFRGCAAALUIIAAA+fwgAABi0A= Date: Thu, 10 Nov 2016 15:20:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DAF632@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> <787AE7BB302AE849A7480A190F8B933009DAF5CE@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DAF632OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 15:20:56 -0000 --_000_787AE7BB302AE849A7480A190F8B933009DAF632OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpJIHdvdWxkIHNheTog4oCcTVVTVCBsb2cgYXQgbGVhc3Qgb25jZSBwZXIgU0ZQIGZv ciB3aGljaCBhIG1hbmRhdG9yeSBtZXRhZGF0YSBpcyBtaXNzaW5n4oCdLg0KDQpCZXR0ZXI/DQoN CkNoZWVycywNCk1lZA0KDQpEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIERhdmUgRG9sc29uDQpFbnZvecOpIDogamV1ZGkgMTAgbm92ZW1icmUgMjAx NiAxNjoxMQ0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKTsgc2ZjQGlldGYub3JnDQpPYmpldCA6IFJlOiBbc2ZjXSBodHRwczovL3RyYWMuaWV0 Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxDQoNClNvIHlvdSB3b3VsZCBzYXksIOKAnE1VU1QgbG9n IGF0IGxlYXN0IG9uY2UgcGVyIHR5cGUgb2YgbWlzc2luZyBtYW5kYXRvcnkgbWV0YWRhdGHigJ0g Pw0KDQoNCg0KRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDE2IDEwOjAyIEFNDQpUbzogRGF2 ZSBEb2xzb247IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJh Yy9zZmMvdGlja2V0LzIxDQoNCkhpIERhdmUsDQoNClRoZSBpbXBsZW1lbnRhdGlvbiBtdXN0IGRl ZmluaXRlbHkgbG9nIHRoZSBlcnJvcjogdGhhdCBpcywgdGhlcmUgaXMgYSBtaXNzaW5nIG1hbmRh dG9yeSBtZXRhZGF0YSBmb3IgYSBjaGFpbi4gSXQgZG9lcyBub3QgbmVlZCB0byBhZGQgYW4gZW50 cnkgcGVyIHBhY2tldCBhcyB3YXMgcmlnaHRmdWxseSBtZW50aW9uZWQgYnkgUm9uLg0KDQpIb3cg dG8gcHJvdGVjdCBhbiBpbXBsZW1lbnRhdGlvbiBmcm9tIG1pc2NvbmZpZ3VyYXRpb24gaXMgbm90 IHNwZWNpZmljIHRvIHRoZSBsb2dnaW5nIGZlYXR1cmUsIGJ1dCBpdCBpcyBhIGdlbmV0aWMgY29u Y2VybiBJTUhPLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBEYXZlIERvbHNvbg0KRW52b3nDqSA6IGpldWRpIDEw IG5vdmVtYnJlIDIwMTYgMTU6NDkNCsOAIDogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW3NmY10gaHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMQ0KDQpKaW0sDQpJIGFncmVlIHdpdGggdGhp cyB3b3JkaW5nLg0KVGhpcyBhbGxvd3MgdGhlIGltcGxlbWVudGVyIHRvIGNob29zZSBhbiBhcHBy b2FjaCB0aGF0IGRvZXMgbm90IG92ZXJ3aGVsbSB0aGUgZGV2aWNlIHdoZW4gdGhlIHN5c3RlbSBp cyBjb25maWd1cmVkIGltcHJvcGVybHkuDQoNCklmIGl0IHdlcmUg4oCcTVVTVOKAnSwgSSB3b3Vs ZCBleHBlY3QgbW9yZSBkZXRhaWxzIGFib3V0IHdoYXQgZXhhY3RseSBzaG91bGQgYmUgbG9nZ2Vk LiBPdGhlcndpc2UsIGhvdyBjb3VsZCBvbmUgdGVzdCBjb21wbGlhbmNlPw0KDQotRGF2ZQ0KDQoN CkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmlt IEd1aWNoYXJkIChqZ3VpY2hhcikNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgMjAxNiA4 OjI4IEFNDQpUbzogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMQ0KDQpEZWFy IFNGQyBXRzoNCg0KQXBvbG9naWVzLCBpdCB3YXMgcG9pbnRlZCBvdXQgdG8gbWUgdGhhdCBJIG1p c3NlZCBhZGRpbmcgdGhlIHRleHQgYXQgYSB0aGlyZCBsb2NhdGlvbi4gQ29ycmVjdCB0ZXh0IGFz IGZvbGxvd3M6DQoNCk5FVyBmb3Igc2VjdGlvbiAzLjQ6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9l cyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhl IG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3Qg ZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0 YS4NCg0KQW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmly c3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBj b250ZXh0IGZpZWxkLiAgVGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2Nh dGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4g U0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KVXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUg MSBwYWNrZXQsIGlmIHRoZSBTRkMtYXdhcmUgU0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5 IHVzZSBvZiBtZXRhZGF0YSBidXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50 aWNzIGZvciB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3Mg dGhlIHBhY2tldCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRl IGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nLg0KDQpbZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBw cm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRh dGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLg0KDQpORVcgZm9yIGVu ZCBvZiBzZWN0aW9uIDMuNS4xOg0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55 IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9y IHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiAgVGhlc2UgY29uc2lkZXJhdGlv bnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuICBIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBj YW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZz IHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5p ZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuDQoNClVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0 IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMg bWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNz IHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0 ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KSWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXBy b2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFu ZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBvcmRlciB0byBjb25zdW1l IHRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3 YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5YXBwZWFyIGlu IHRoZSBOU0ggcGFja2V0Lg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExW IGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhh dCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHBy b2Nlc3MgdGhlIHBhY2tldCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBs eSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nLg0KDQpGcm9tOiBzZmMgPHNmYy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBKaW0g R3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4N CkRhdGU6IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgMjAxNiBhdCA4OjIyIEFNDQpUbzogInNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9z ZmMvdGlja2V0LzIxDQoNCkRlYXIgU0ZDIFdHOg0KDQpHaXZlbiB0aGUgcmVjZW50IGRpc2N1c3Np b24gb24gdGhlIG1haWxpbmcgbGlzdCwgdXBkYXRlZCB0ZXh0ICh3aXRoIGNoYW5nZXMgaW4gUkVE KSBhcyBmb2xsb3dzOg0KDQpORVcgZm9yIHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9u IGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGlu IHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMg bm90IGRlc2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0 YWRhdGEuDQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNz IGZpcnN0IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRv cnkgY29udGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFs bG9jYXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93 IGFuIFNGQy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10 eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRh dG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNl bWFudGljcyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9j ZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkg cmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KW2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxv Y10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRo ZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCg0KTkVXIGZv ciBlbmQgb2Ygc2VjdGlvbiAzLjUuMToNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtl IGFueSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWltcGxlbWVu dCBvciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gIFRoZXNlIGNvbnNpZGVy YXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiAgSG93ZXZlciwgdGhlIGNvbnRyb2wgcGxh bmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2Yg VExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJ LUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLg0KDQpVcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQg dGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExW IGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJv Y2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpJZiBtdWx0aXBsZSBt YW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRo ZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9y ZGVyIHRvIGNvbnN1bWUgdGhlc2UgVExWcy4gIElmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlk ZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVy IHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuDQoNCklmIG11bHRpcGxlIGluc3RhbmNlcyBv ZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0aGUgZGVm aW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMtYXdhcmUg U0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3Is IGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCkZyb206IHNm YyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4gb24g YmVoYWxmIG9mIEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hh ckBjaXNjby5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgOCwgMjAxNiBhdCAxOjAxIFBN DQpUbzogInNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPj4NClN1YmplY3Q6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL3NmYy90aWNrZXQvMjENCg0KRGVhciBTRkMgV0c6DQoNCkFmdGVyIG11Y2ggZGlzY3Vz c2lvbiBvbiB0aGUgbGlzdCB3aXRoIHJlZ2FyZCB0byB0aWNrZXQgIzIxIHRoZSBmb2xsb3dpbmcg dGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNz IGFuZCBzbyBmb3J0aC4gUGxlYXNlIHJldmlldyBhbmQgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90 KSBzbyB0aGF0IHRoZSBjaGFpcnMgY2FuIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHVwZGF0ZSB0 aGUgdGlja2V0IGFjY29yZGluZ2x5Lg0KDQpUaGFuayB5b3UhDQoNCkppbSAmIEpvZWwNCg0KIyMj IyMjIyMjIw0KDQpORVcgZm9yIHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMg bm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBt YW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRl c2NyaWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEu DQoNCkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNzIGZpcnN0 IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29u dGV4dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRp b24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93IGFuIFNG Qy1hd2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBv ZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEg cGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1 c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGlj cyBmb3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRo ZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQoNCltkY2FsbG9jXSBhbmQgW2Jyb2Fk YWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0 aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuDQoNCk5F VyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg bWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBs ZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVzZSBjb25z aWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250cm9s IHBsYW5lIGNhbiBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJl IG9mIFRMVnMgdG9nZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBv ZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9mIGEgcGFj a2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNz IFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9U IHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KSWYgbXVsdGlw bGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQ LCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRo ZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHBy b3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBv cmRlciB0aGV5YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0Lg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5j ZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhl IGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3 YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJv ci4NCg== --_000_787AE7BB302AE849A7480A190F8B933009DAF632OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLlRleHRlZGVidWxsZXND YXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRl eHQsIGRpdi5CYWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWIt c3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9u dC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWln aHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5SZS0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgd291bGQgc2F5OiDigJxNVVNUIGxvZyBhdCBsZWFz dCBvbmNlIHBlciBTRlAgZm9yIHdoaWNoIGEgbWFuZGF0b3J5IG1ldGFkYXRhIGlzIG1pc3Npbmfi gJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkJl dHRlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxi PkRlIGxhIHBhcnQgZGU8L2I+IERhdmUgRG9sc29uPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+ IGpldWRpIDEwIG5vdmVtYnJlIDIwMTYgMTY6MTE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNB REFJUiBNb2hhbWVkIElNVC9PTE47IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5v cmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5v cmcvdHJhYy9zZmMvdGlja2V0LzIxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TbyB5b3Ugd291bGQgc2F5LCDigJxNVVNUIGxvZyBhdCBsZWFzdCBvbmNlIHBl ciB0eXBlIG9mIG1pc3NpbmcgbWFuZGF0b3J5IG1ldGFkYXRh4oCdID88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiBbPGEg aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg Tm92ZW1iZXIgMTAsIDIwMTYgMTA6MDIgQU08YnI+DQo8Yj5Ubzo8L2I+IERhdmUgRG9sc29uOyBK aW0gR3VpY2hhcmQgKGpndWljaGFyKTsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2Zj QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NmY10gPGEgaHJlZj0iaHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90cmFjLmlldGYu b3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5IaSBEYXZlLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ VGhlIGltcGxlbWVudGF0aW9uIG11c3QgZGVmaW5pdGVseSBsb2cgdGhlIGVycm9yOiB0aGF0IGlz LCB0aGVyZSBpcyBhIG1pc3NpbmcgbWFuZGF0b3J5IG1ldGFkYXRhIGZvciBhIGNoYWluLiBJdCBk b2VzIG5vdCBuZWVkIHRvIGFkZCBhbiBlbnRyeSBwZXIgcGFja2V0DQogYXMgd2FzIHJpZ2h0ZnVs bHkgbWVudGlvbmVkIGJ5IFJvbi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPkhvdyB0byBwcm90ZWN0IGFuIGltcGxlbWVudGF0aW9uIGZyb20gbWlz Y29uZmlndXJhdGlvbiBpcyBub3Qgc3BlY2lmaWMgdG8gdGhlIGxvZ2dpbmcgZmVhdHVyZSwgYnV0 IGl0IGlzIGEgZ2VuZXRpYyBjb25jZXJuIElNSE8uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxhIDwvYj48L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnBhcnQgZGU8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gRGF2ZSBEb2xzb248YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4g amV1ZGkgMTAgbm92ZW1icmUgMjAxNiAxNTo0OTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gSmltIEd1 aWNoYXJkIChqZ3VpY2hhcik7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbc2ZjXSA8YSBocmVmPSJodHRw czovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxIj5odHRwczovL3RyYWMuaWV0Zi5v cmcvdHJhYy9zZmMvdGlja2V0LzIxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SmltLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBhZ3JlZSB3aXRoIHRoaXMgd29yZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgYWxsb3dzIHRoZSBpbXBsZW1lbnRlciB0byBjaG9vc2Ug YW4gYXBwcm9hY2ggdGhhdCBkb2VzIG5vdCBvdmVyd2hlbG0gdGhlIGRldmljZSB3aGVuIHRoZSBz eXN0ZW0gaXMgY29uZmlndXJlZCBpbXByb3Blcmx5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPklmIGl0IHdlcmUg4oCcTVVTVOKAnSwgSSB3b3VsZCBleHBlY3QgbW9yZSBk ZXRhaWxzIGFib3V0IHdoYXQgZXhhY3RseSBzaG91bGQgYmUgbG9nZ2VkLiBPdGhlcndpc2UsIGhv dyBjb3VsZCBvbmUgdGVzdCBjb21wbGlhbmNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkppbSBHdWlj aGFyZCAoamd1aWNoYXIpPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwg MjAxNiA4OjI4IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSA8YSBocmVm PSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxIj5odHRwczovL3RyYWMu aWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5EZWFyIFNGQyBXRzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5BcG9sb2dpZXMsIGl0IHdhcyBwb2ludGVkIG91dCB0byBtZSB0 aGF0IEkgbWlzc2VkIGFkZGluZyB0aGUgdGV4dCBhdCBhIHRoaXJkIGxvY2F0aW9uLiBDb3JyZWN0 IHRleHQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1 bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQg ZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmliZQ0KIHRoZSBzdHJ1 Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuICZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDst d2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmly c3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBj b250ZXh0IGZpZWxkLiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNlbWFudGljcw0KIGluY2x1ZGUgYm90 aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBk YXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNp ZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFy ZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlVwb24gcmVj ZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNv bmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJl Y2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcw0KIGZvciB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmll bGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFu ZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpyZWQiPiwgaXQ8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpyZWQiPlNIT1VMRA0KIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0 aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFti cm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5n IHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+TkVXIGZvciBlbmQgb2Ygc2VjdGlvbiAzLjUuMTwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQg VExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1h bmRhdG9yeS10by1wcm9jZXNzLiZuYnNwOyZuYnNwO1RoZXNlIGNvbnNpZGVyYXRpb25zDQogYXJl IGRlcGxveW1lbnQtc3BlY2lmaWMuJm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhlIGNvbnRyb2wgcGxh bmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2Yg VExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJ LUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFu ZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9m IGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1w cm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1V U1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFja2V0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+LCBpdDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+ U0hPVUxEDQogbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8g YW55IGxvZ2dpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIG1hbmRhdG9yeS10 by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wg cGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29u c3VtZQ0KIHRoZXNlIFRMVnMuJm5ic3A7Jm5ic3A7SWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92 aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3Jk ZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQt c3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIG11bHRpcGxl IGluc3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQs IGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRo ZSBTRkMtYXdhcmUgU0YgTVVTVA0KIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQ8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj4sIGl0Jm5i c3A7U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRv IGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5zZmMgJmx0Ozxh IGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0OyBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1 aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgYXQgODoyMiBBTTxicj4NCjxiPlRvOiA8 L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIDxhIGhyZWY9Imh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjEiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3Nm Yy90aWNrZXQvMjE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGVhciBTRkMgV0c6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+R2l2ZW4gdGhlIHJlY2VudCBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHVwZGF0 ZWQgdGV4dCAod2l0aCBjaGFuZ2VzIGluIFJFRCkgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBp biB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2Vz IG5vdCBkZXNjcmliZQ0KIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQg bWV0YWRhdGEuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2 ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBw bGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZuYnNwO1RoZSBkYXRh IHNlbWFudGljcw0KIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBt ZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhl IGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBp ZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0 YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcw0KIGZvciB0 aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tl dDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpyZWQiPiwgaXQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVT VCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBh c3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9y eSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TkVXIGZvciBlbmQgb2Ygc2VjdGlvbiAz LjUuMTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55 IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9y IHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiZuYnNwOyZuYnNwO1RoZXNlIGNv bnNpZGVyYXRpb25zDQogYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuJm5ic3A7Jm5ic3A7SG93ZXZl ciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUg ZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBT ZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBp ZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0 aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFja2V0IGFuZCBNVVNUIGxv ZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nl c3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFuZSBN QVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBvcmRlciB0byBjb25zdW1lDQog dGhlc2UgVExWcy4mbmJzcDsmbmJzcDtJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0 aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5 YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFy ZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SWYgbXVsdGlwbGUgaW5zdGFu Y2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRo ZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1h d2FyZSBTRiBNVVNUDQogTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1z dGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpyZWQiPiwgaXQmbmJzcDtTSE9V TEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxv Z2dpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnNmYyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBj aXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1 ZXNkYXksIE5vdmVtYmVyIDgsIDIwMTYgYXQgMTowMSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+W3NmY10gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv c2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGVhciBTRkMgV0c6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5BZnRlciBtdWNoIGRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0 ICMyMSB0aGUgZm9sbG93aW5nIHRleHQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5 IG1ldGFkYXRhIHNlbWFudGljcyBhbmQgc28gZm9ydGguDQogUGxlYXNlIHJldmlldyBhbmQgaW5k aWNhdGUgc3VwcG9ydCAob3Igbm90KSBzbyB0aGF0IHRoZSBjaGFpcnMgY2FuIGRldGVybWluZSBj b25zZW5zdXMgYW5kIHVwZGF0ZSB0aGUgdGlja2V0IGFjY29yZGluZ2x5LiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDst d2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+VGhhbmsgeW91ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SmltICZhbXA7IEpvZWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtp dC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiMjIyMjIyMjIyM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPlRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFi b3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2Yg dGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmliZQ0KIHRoZSBzdHJ1Y3R1cmUgb3Ig bWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QW4g U0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3Jk ZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZp ZWxkLiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNlbWFudGljcw0KIGluY2x1ZGUgYm90aCB0aGUgYWxs b2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cg YW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlVwb24gcmVjZWl2aW5nIGFu IE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQg Zm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRo ZSBkYXRhIHNlbWFudGljcw0KIGZvciB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1V U1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVz IHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFu ZGF0b3J5IGNvbnRleHQgZmllbGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5ORVcgZm9yIGVuZCBvZiBzZWN0 aW9uIDMuNS4xPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFr ZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1l bnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7VGhl c2UgY29uc2lkZXJhdGlvbnMNCiBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4mbmJzcDsmbmJzcDtI b3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRo IHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAo U2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5VcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBT RlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNr ZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2Vzcw0KIHRoZSBwYWNrZXQgYW5kIE1V U1QgbG9nIHRoaXMgZXJyb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8t cHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBs YW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1 bWUNCiB0aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlk ZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVy IHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBp bnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBi dXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUg U0ZDLWF3YXJlIFNGIE1VU1QNCiBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0 aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933009DAF632OPEXCLILMA3corp_-- From nobody Thu Nov 10 07:22:59 2016 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 3BCF712953A for ; Thu, 10 Nov 2016 07:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 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=-1.497, 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 08uHNgfYQ9lm for ; Thu, 10 Nov 2016 07:22:56 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BA4129424 for ; Thu, 10 Nov 2016 07:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25171; q=dns/txt; s=iport; t=1478791375; x=1480000975; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L6b/IQzhrziPC2bScaSPriNTNsUEkIxhH2C14waHP0Y=; b=iAptjLvn8hCV+IrIyOULj/hgDMavSXgS0J1C5Rhr0gT+OaNooGckJtvq Qe9+mEhGFb3fiNVGEpRfGZG1LbArVBU1w4vE5L9tCEf7T+qbPrc57smeQ D7hM5Q1PMH1wbBn7KiIiA7QSN2wJLIPDtJnmUiRT+01wvkIkDD/9XoNgU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQCXjyRY/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnM9AQEBAQEfWG8QB402lwuUWIIHHgEKhXsCghE/FAECAQEBAQE?= =?us-ascii?q?BAWIohGEBAQEEAQEBC1cJCxACAQgRAwECIQcHJwsUCQgCBA4FiF8OsyGLQgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARcFhj6BfQiCVYE9AYJ6MBaCe4IwBZRUhWMBhji?= =?us-ascii?q?DDocMgW6EdIgPgSuHN4YFhAYBHjeBAByDLD+BLXKHC4EMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,619,1473120000"; d="scan'208,217";a="172773525" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Nov 2016 15:22:54 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uAAFMslo016206 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Nov 2016 15:22:54 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 09:22:53 -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, 10 Nov 2016 09:22:53 -0600 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5dhBvoux3dU2uL7kFD+H1LqDSRqwAgABz2QA= Date: Thu, 10 Nov 2016 15:22:53 +0000 Message-ID: <7C9A05D0-CEB7-4438-B537-022F90EF4255@cisco.com> References: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> 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.131.118.79] Content-Type: multipart/alternative; boundary="_000_7C9A05D0CEB74438B537022F90EF4255ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 15:22:58 -0000 --_000_7C9A05D0CEB74438B537022F90EF4255ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, I'm fine with this, strikes the balance between guidance and implementation= reality. Paul On Nov 10, 2016, at 8:28 AM, Jim Guichard (jguichar) > wrote: Dear SFC WG: Apologies, it was pointed out to me that I missed adding the text at a thir= d location. Correct text as follows: NEW for section 3.4: 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 s= tructure or meaning of the included metadata. An SFC-aware SF MUST receive the data semantics first in order to process t= he data placed in the mandatory context field. The data semantics include = both the allocation schema and the meaning of the included data. How an SFC= -aware SF gets the data semantics is outside the scope of this specificatio= n. Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured f= or mandatory use of metadata but has not yet received the data semantics fo= r the mandatory context field, it MUST NOT process the packet, it SHOULD lo= g this error, and MUST apply rate limiting to any logging. [dcalloc] and [broadalloc] provide sample examples to associate a meaning w= ith the data conveyed in the mandatory context field. NEW for end of section 3.5.1: This specification does not make any assumption about TLVs that are mandato= ry-to-implement or those that are mandatory-to-process. These consideratio= ns are deployment-specific. However, the control plane can instruct SFC-aw= are SFs with the data structure of TLVs together with their scoping (See Se= ction 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-proc= ess TLV is missing in that packet, the SFC-aware SF MUST NOT process the pa= cket, it SHOULD log this error, and MUST apply rate limiting to any logging= . If multiple mandatory-to-process TLVs are required for a given SFP, the con= trol plane MAY instruct the SFC-aware SF with the order to consume these TL= Vs. If no instructions are provided, the SFC-aware SF MUST process these T= LVs in the order theyappear in the NSH packet. If multiple instances of the same TLV are included in an NSH packet, but th= e definition of that TLV does not allow for it, the SFC-aware SF MUST NOT p= rocess the packet, it SHOULD log this error, and MUST apply rate limiting t= o any logging. From: sfc > on behalf of = Jim Guichard > Date: Thursday, November 10, 2016 at 8:22 AM To: "sfc@ietf.org" > Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Dear SFC WG: Given the recent discussion on the mailing list, updated text (with changes= in RED) as follows: NEW for section 3.4: 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 s= tructure or meaning of the included metadata. An SFC-aware SF MUST receive the data semantics first in order to process t= he data placed in the mandatory context field. The data semantics include = both the allocation schema and the meaning of the included data. How an SFC= -aware SF gets the data semantics is outside the scope of this specificatio= n. Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured f= or mandatory use of metadata but has not yet received the data semantics fo= r the mandatory context field, it MUST NOT process the packet, it SHOULD lo= g this error, and MUST apply rate limiting to any logging. [dcalloc] and [broadalloc] provide sample examples to associate a meaning w= ith the data conveyed in the mandatory context field. NEW for end of section 3.5.1: This specification does not make any assumption about TLVs that are mandato= ry-to-implement or those that are mandatory-to-process. These consideratio= ns are deployment-specific. However, the control plane can instruct SFC-aw= are SFs with the data structure of TLVs together with their scoping (See Se= ction 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-proc= ess TLV is missing in that packet, the SFC-aware SF MUST NOT process the pa= cket and MUST log this error. If multiple mandatory-to-process TLVs are required for a given SFP, the con= trol plane MAY instruct the SFC-aware SF with the order to consume these TL= Vs. If no instructions are provided, the SFC-aware SF MUST process these T= LVs in the order theyappear in the NSH packet. If multiple instances of the same TLV are included in an NSH packet, but th= e definition of that TLV does not allow for it, the SFC-aware SF MUST NOT p= rocess the packet, it SHOULD log this error, and MUST apply rate limiting t= o any logging. From: sfc > on behalf of = Jim Guichard > Date: Tuesday, November 8, 2016 at 1:01 PM To: "sfc@ietf.org" > Subject: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Dear SFC WG: After much discussion on the list with regard to ticket #21 the following t= ext has been proposed to help clarify metadata semantics and so forth. Plea= se review and indicate support (or not) so that the chairs can determine co= nsensus and update the ticket accordingly. Thank you! Jim & Joel ########## NEW for section 3.4: 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 s= tructure or meaning of the included metadata. An SFC-aware SF MUST receive the data semantics first in order to process t= he data placed in the mandatory context field. The data semantics include = both the allocation schema and the meaning of the included data. How an SFC= -aware SF gets the data semantics is outside the scope of this specificatio= n. Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured f= or mandatory use of metadata but has not yet received the data semantics fo= r the mandatory context field, it MUST NOT process the packet and MUST log = this error. [dcalloc] and [broadalloc] provide sample examples to associate a meaning w= ith the data conveyed in the mandatory context field. NEW for end of section 3.5.1: This specification does not make any assumption about TLVs that are mandato= ry-to-implement or those that are mandatory-to-process. These consideratio= ns are deployment-specific. However, the control plane can instruct SFC-aw= are SFs with the data structure of TLVs together with their scoping (See Se= ction 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-proc= ess TLV is missing in that packet, the SFC-aware SF MUST NOT process the pa= cket and MUST log this error. If multiple mandatory-to-process TLVs are required for a given SFP, the con= trol plane MAY instruct the SFC-aware SF with the order to consume these TL= Vs. If no instructions are provided, the SFC-aware SF MUST process these T= LVs in the order theyappear in the NSH packet. If multiple instances of the same TLV are included in an NSH packet, but th= e definition of that TLV does not allow for it, the SFC-aware SF MUST NOT p= rocess the packet and MUST log this error. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_7C9A05D0CEB74438B537022F90EF4255ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <42423B02AA937D4F8C4357D70AC38706@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Jim,

I'm fine with this, strikes the balance between guidance an= d implementation reality.

Paul

On Nov 10, 2016, at 8:28 AM, Jim Guichard (jguichar) <jguichar@cisco.com> w= rote:

Dear SFC WG:

Apologies, it was pointed out to me that I missed adding th= e text at a third location. Correct text as follows:

NEW = for section 3.4:
This specification= does not make any assumption about the content placed in the mandatory con= text field of the NSH header, and does not describe the structure or meanin= g of the included metadata.  

An SFC-aware SF MU= ST receive the data semantics first in order to process the data placed in = the mandatory context field.  The data semantics include both the= allocation schema and the meaning of the included data. How an SFC-aware SF gets the data semantics is outside the scope of = this specification.

Upon receiving an = NSH MD-type 1 packet, if the SFC-aware SF is configured for mandatory use o= f metadata but has not yet received the data semantics for the mandatory co= ntext field, it MUST NOT process the packet, it SHOULD log this error, and MUST apply rate limiting to a= ny logging.

[dcalloc] and [bro= adalloc] provide sample examples to associate a meaning with the data conve= yed in the mandatory context field.

NEW = for end of section 3.5.1:
This specification= does not make any assumption about TLVs that are mandatory-to-implement or= those that are mandatory-to-process.  These considerations are d= eployment-specific.  However, the control plane can instruct SFC-aware SFs with the data structure of TLVs together with t= heir 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, it SH= OULD log this error, and MUST apply rate limiting to any logging.

If multiple mandat= ory-to-process TLVs are required for a given SFP, the control plane MAY ins= truct 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 theyappear in the NSH packet.

If multiple instan= ces of the same TLV are included in an NSH packet, but the definition of th= at TLV does not allow for it, the SFC-aware SF MUST NOT process the packet<= font color=3D"#ff0000" class=3D"">, it SHOULD log this error, and MUST apply rate limiting to any logging.

From: sfc <sfc-bounces@ietf.org> on be= half of Jim Guichard <j= guichar@cisco.com>
Date: Thursday, November= 10, 2016 at 8:22 AM
To: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

Given the recent discussion on the mailing list,= updated text (with changes in RED) as follows:

NEW = for section 3.4:
This specification= does not make any assumption about the content placed in the mandatory con= text field of the NSH header, and does not describe the structure or meanin= g of the included metadata.  

An SFC-aware SF MU= ST receive the data semantics first in order to process the data placed in = the mandatory context field.  The data semantics include both the= allocation schema and the meaning of the included data. How an SFC-aware SF gets the data semantics is outside the scope of = this specification.

Upon receiving an = NSH MD-type 1 packet, if the SFC-aware SF is configured for mandatory use o= f metadata but has not yet received the data semantics for the mandatory co= ntext field, it MUST NOT process the packet, it SHOULD log this error, and MUST apply rate limiting to any logging.<= /div>

[dcalloc] and [bro= adalloc] provide sample examples to associate a meaning with the data conve= yed in the mandatory context field.

NEW = for end of section 3.5.1:
This specification= does not make any assumption about TLVs that are mandatory-to-implement or= those that are mandatory-to-process.  These considerations are d= eployment-specific.  However, the control plane can instruct SFC-aware SFs with the data structure of TLVs together with t= heir 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 = this error.

If multiple mandat= ory-to-process TLVs are required for a given SFP, the control plane MAY ins= truct 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 theyappear in the NSH packet.

If multiple instances of the same TLV are included in an NSH pack= et, but the definition of that TLV does not allow for it, the SFC-aware SF = MUST NOT process the packet, it SHOULD log this error, a= nd MUST apply rate limiting to any logging.

From: sfc <sfc-bounces@ietf.org> on be= half of Jim Guichard <j= guichar@cisco.com>
Date: Tuesday, November = 8, 2016 at 1:01 PM
To: "sfc@ietf.org" <sfc@ietf.org>
Subject: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

After much discuss= ion on the list with regard to ticket #21 the following text has been propo= sed to help clarify metadata semantics and so forth. Please review and indi= cate support (or not) so that the chairs can determine consensus and update the ticket accordingly. 

Thank you!

Jim & Joel

##########

NEW = for section 3.4:
This specification= does not make any assumption about the content placed in the mandatory con= text field of the NSH header, and does not describe the structure or meanin= g of the included metadata.  

An SFC-aware SF MU= ST receive the data semantics first in order to process the data placed in = the mandatory context field.  The data semantics include both the= allocation schema and the meaning of the included data. How an SFC-aware SF gets the data semantics is outside the scope of = this specification.

Upon receiving an = NSH MD-type 1 packet, if the SFC-aware SF is configured for mandatory use o= f metadata but has not yet received the data semantics for the mandatory co= ntext field, it MUST NOT process the packet and MUST log this error.

[dcalloc] and [bro= adalloc] provide sample examples to associate a meaning with the data conve= yed in the mandatory context field.

NEW = for end of section 3.5.1:
This specification= does not make any assumption about TLVs that are mandatory-to-implement or= those that are mandatory-to-process.  These considerations are d= eployment-specific.  However, the control plane can instruct SFC-aware SFs with the data structure of TLVs together with t= heir 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 = this error.

If multiple mandat= ory-to-process TLVs are required for a given SFP, the control plane MAY ins= truct 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 theyappear in the NSH packet.

If multiple instan= ces of the same TLV are included in an NSH packet, but the definition of th= at TLV does not allow for it, the SFC-aware SF MUST NOT process the packet = and MUST log this error.
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_7C9A05D0CEB74438B537022F90EF4255ciscocom_-- From nobody Thu Nov 10 07:42:48 2016 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 2EE2A129854 for ; Thu, 10 Nov 2016 07:42:46 -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 8wSNTMhxOMNu for ; Thu, 10 Nov 2016 07:42:44 -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 7273D1297DE for ; Thu, 10 Nov 2016 07:42:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 60F6424ED00; Thu, 10 Nov 2016 07:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478792564; bh=lB56IRyL64QCwnftaKcGVHc0LKUiVGOcGYzjfQCCvb8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kvNUHZ3qpddUnQg0xX7IIm3LT9Xp1BZUtE11mvsAQhkfyoWBpGdaLQxO5F093odfg 80zd3vgbxJm5cgNW1YkVZFBvcX9FJotydMk57t8pGMNYEM95AZ77GNTlF02Sf7d2Nv BoOL8tPK3Zvonp5hX0j/lYlcrfN8uTV6W2lATHII= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [12.238.14.250]) (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 20FB624B45F; Thu, 10 Nov 2016 07:42:44 -0800 (PST) To: "Jim Guichard (jguichar)" , "wang.cui1@zte.com.cn" References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> <9C8B3B99-1938-4B49-844F-C65F53A48725@cisco.com> From: "Joel M. Halpern" Message-ID: <2df5c8d8-ae75-85ac-7940-cd4264a960e8@joelhalpern.com> Date: Thu, 10 Nov 2016 10:42:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9C8B3B99-1938-4B49-844F-C65F53A48725@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 15:42:46 -0000 (This is the case where even the chairs meant slightly different things, so thanks for making sure we are clear.) Personally, I think that the mapping between value and meaning is going to be handled via indirection. I do not think that the control system will ever say that value 101 means "coke". Rather, I think that the control system will provide enough information that the SF can determine how to interpret 101. The difference is that what the SF needs to know is not "coke", but rather what data set it can use the given value as a key into, and what mechanism (pre-provisioned data set 3, radius, diameter, LDAP, ...) it can use to get the information it needs to do its job using that key. While for some SF, being told "use DC allocation" will be sufficient, I expect in many cases that what the SF needs to be told is that bytes 7 - 9 are the index it needs to use as the key for getting the subscribers content filtering policy. So we have to allow both the general and the specific representation. Yours, Joel On 11/10/16 8:15 AM, Jim Guichard (jguichar) wrote: > Hi Linda, > > By this we mean how the SF is to interpret the data carried within the > metadata. For example, the allocation schema might say 鈥渢enant-id > carried at offset 鈥︹ but then the SF needs to understand what the > extracted value from the metadata corresponds to in terms of which > tenant e.g. value 101 might mean 鈥渃oke鈥. 鈥渃oke鈥 in this example is not > carried within the metadata so the SF needs to map the value from the > metadata to a meaningful tenant identification. > > Hope this clarifies .. > > Jim > > From: "wang.cui1@zte.com.cn " > > > Date: Wednesday, November 9, 2016 at 9:45 PM > To: Jim Guichard > > Cc: "sfc@ietf.org " >, sfc > > Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 > > Dear Jim & Joel, > > The text said: 'the data semantics include both the allocation schema > and the meaning of the included data.' > I agree with 'the allocation schema' can help the SFC-aware SF to > know how to interpret the mandatory context field. However, > Could you clarify what is 'the meaning of the included data' and how > to describe' the meaning of the included data'? > > Thanks very much :) > > BRs > Linda Wang > > > > > > > *"Jim Guichard (jguichar)" >* > 鍙戜欢浜: "sfc" > > > 2016/11/09 02:01 > > > 鏀朵欢浜 > "sfc@ietf.org " >, > 鎶勯 > > 涓婚 > [sfc] https://trac.ietf.org/trac/sfc/ticket/21 > > > > > > > > > Dear SFC WG: > > After much discussion on the list with regard to ticket #21 the > following text has been proposed to help clarify metadata semantics and > so forth. Please review and indicate support (or not) so that the chairs > can determine consensus and update the ticket accordingly. > > Thank you! > > Jim & Joel > > ########## > > *NEW for section 3.4*: > 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. > > An SFC-aware SF MUST receive the data semantics first in order to > process the data placed in the mandatory context field. The data > semantics include both the allocation schema and the meaning of the > included data. How an SFC-aware SF gets the data semantics is outside > the scope of this specification. > > Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is > configured for mandatory use of metadata but has not yet received the > data semantics for the mandatory context field, it MUST NOT process the > packet and MUST log this error. > > [dcalloc] and [broadalloc] provide sample examples to associate a > meaning with the data conveyed in the mandatory context field. > > *NEW for end of section 3.5.1*: > 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 can > 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 this error. > > 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 they 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 this > error._______________________________________________ > 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 Nov 10 09:09:43 2016 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 8A0B412957A for ; Thu, 10 Nov 2016 09:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 Uhh4nitHO7ew for ; Thu, 10 Nov 2016 09:09:38 -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 0F86B12978B for ; Thu, 10 Nov 2016 09:09:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUX59883; Thu, 10 Nov 2016 17:09:32 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Nov 2016 17:09:26 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 09:09:22 -0800 From: Lucy yong To: "mohamed.boucadair@orange.com" , Dave Dolson , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5al9t2EP53k26GM4GNxjWzKDSvAUAgAAWlICAAAOeAIAAAqSAgAACoYD//5cW4A== Date: Thu, 10 Nov 2016 17:09:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572EC4DD@dfweml501-mbb> References: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> <787AE7BB302AE849A7480A190F8B933009DAF5CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009DAF632@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAF632@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.74] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D572EC4DDdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5824A9CE.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 45d35c5370c54f01ecf5df5d5e4ee637 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 17:09:41 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D572EC4DDdfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gZmF2b3Igb2YgTWVk4oCZcyB0ZXh0LiAgSG93IGFib3V0IDogTVVTVCBsb2cgYXQgbGVhc3Qg b25jZSBwZXIgdGhlIFNQSSBmb3Igd2hpY2ggYSBtYW5kYXRvcnkgbWV0YWRhdGEgaXMgbWlzc2lu Zy4NCg0KTHVjeQ0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NClNlbnQ6IFRodXJzZGF5LCBO b3ZlbWJlciAxMCwgMjAxNiA5OjIxIEFNDQpUbzogRGF2ZSBEb2xzb247IEppbSBHdWljaGFyZCAo amd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBodHRwczovL3RyYWMu aWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxDQoNClJlLSwNCg0KSSB3b3VsZCBzYXk6IOKAnE1V U1QgbG9nIGF0IGxlYXN0IG9uY2UgcGVyIFNGUCBmb3Igd2hpY2ggYSBtYW5kYXRvcnkgbWV0YWRh dGEgaXMgbWlzc2luZ+KAnS4NCg0KQmV0dGVyPw0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBEYXZlIERvbHNvbg0K RW52b3nDqSA6IGpldWRpIDEwIG5vdmVtYnJlIDIwMTYgMTY6MTENCsOAIDogQk9VQ0FEQUlSIE1v aGFtZWQgSU1UL09MTjsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3Jn L3RyYWMvc2ZjL3RpY2tldC8yMQ0KDQpTbyB5b3Ugd291bGQgc2F5LCDigJxNVVNUIGxvZyBhdCBs ZWFzdCBvbmNlIHBlciB0eXBlIG9mIG1pc3NpbmcgbWFuZGF0b3J5IG1ldGFkYXRh4oCdID8NCg0K DQoNCkZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0N ClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgMjAxNiAxMDowMiBBTQ0KVG86IERhdmUgRG9s c29uOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2Zj L3RpY2tldC8yMQ0KDQpIaSBEYXZlLA0KDQpUaGUgaW1wbGVtZW50YXRpb24gbXVzdCBkZWZpbml0 ZWx5IGxvZyB0aGUgZXJyb3I6IHRoYXQgaXMsIHRoZXJlIGlzIGEgbWlzc2luZyBtYW5kYXRvcnkg bWV0YWRhdGEgZm9yIGEgY2hhaW4uIEl0IGRvZXMgbm90IG5lZWQgdG8gYWRkIGFuIGVudHJ5IHBl ciBwYWNrZXQgYXMgd2FzIHJpZ2h0ZnVsbHkgbWVudGlvbmVkIGJ5IFJvbi4NCg0KSG93IHRvIHBy b3RlY3QgYW4gaW1wbGVtZW50YXRpb24gZnJvbSBtaXNjb25maWd1cmF0aW9uIGlzIG5vdCBzcGVj aWZpYyB0byB0aGUgbG9nZ2luZyBmZWF0dXJlLCBidXQgaXQgaXMgYSBnZW5ldGljIGNvbmNlcm4g SU1ITy4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgRGF2ZSBEb2xzb24NCkVudm95w6kgOiBqZXVkaSAxMCBub3Zl bWJyZSAyMDE2IDE1OjQ5DQrDgCA6IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtzZmNdIGh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCg0KSmltLA0KSSBhZ3JlZSB3aXRoIHRoaXMgd29y ZGluZy4NClRoaXMgYWxsb3dzIHRoZSBpbXBsZW1lbnRlciB0byBjaG9vc2UgYW4gYXBwcm9hY2gg dGhhdCBkb2VzIG5vdCBvdmVyd2hlbG0gdGhlIGRldmljZSB3aGVuIHRoZSBzeXN0ZW0gaXMgY29u ZmlndXJlZCBpbXByb3Blcmx5Lg0KDQpJZiBpdCB3ZXJlIOKAnE1VU1TigJ0sIEkgd291bGQgZXhw ZWN0IG1vcmUgZGV0YWlscyBhYm91dCB3aGF0IGV4YWN0bHkgc2hvdWxkIGJlIGxvZ2dlZC4gT3Ro ZXJ3aXNlLCBob3cgY291bGQgb25lIHRlc3QgY29tcGxpYW5jZT8NCg0KLURhdmUNCg0KDQpGcm9t OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWlj aGFyZCAoamd1aWNoYXIpDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgODoyOCBB TQ0KVG86IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtz ZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCg0KRGVhciBTRkMg V0c6DQoNCkFwb2xvZ2llcywgaXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQgSSBtaXNzZWQg YWRkaW5nIHRoZSB0ZXh0IGF0IGEgdGhpcmQgbG9jYXRpb24uIENvcnJlY3QgdGV4dCBhcyBmb2xs b3dzOg0KDQpORVcgZm9yIHNlY3Rpb24gMy40Og0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90 IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5k YXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2Ny aWJlIHRoZSBzdHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuDQoN CkFuIFNGQy1hd2FyZSBTRiBNVVNUIHJlY2VpdmUgdGhlIGRhdGEgc2VtYW50aWNzIGZpcnN0IGlu IG9yZGVyIHRvIHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4 dCBmaWVsZC4gIFRoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24g c2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgZGF0YS4gSG93IGFuIFNGQy1h d2FyZSBTRiBnZXRzIHRoZSBkYXRhIHNlbWFudGljcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIHNwZWNpZmljYXRpb24uDQoNClVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFj a2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ug b2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBm b3IgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLCBpdCBNVVNUIE5PVCBwcm9jZXNzIHRoZSBw YWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0ZSBsaW1p dGluZyB0byBhbnkgbG9nZ2luZy4NCg0KW2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlk ZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRoZSBkYXRhIGNv bnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCg0KTkVXIGZvciBlbmQgb2Yg c2VjdGlvbiAzLjUuMToNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1 bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBvciB0aG9z ZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gIFRoZXNlIGNvbnNpZGVyYXRpb25zIGFy ZSBkZXBsb3ltZW50LXNwZWNpZmljLiAgSG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGlu c3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0b2dl dGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1z ZmMtY29udHJvbC1wbGFuZV0pLg0KDQpVcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxv bmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlzIG1pc3Np bmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUg cGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGlt aXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNz IFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZ IGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVz ZSBUTFZzLiAgSWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBT RiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUg TlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUg aW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExW IGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNz IHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkgcmF0 ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KRnJvbTogc2ZjIDxzZmMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmltIEd1aWNo YXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQpEYXRl OiBUaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgYXQgODoyMiBBTQ0KVG86ICJzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSZTogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3Rp Y2tldC8yMQ0KDQpEZWFyIFNGQyBXRzoNCg0KR2l2ZW4gdGhlIHJlY2VudCBkaXNjdXNzaW9uIG9u IHRoZSBtYWlsaW5nIGxpc3QsIHVwZGF0ZWQgdGV4dCAod2l0aCBjaGFuZ2VzIGluIFJFRCkgYXMg Zm9sbG93czoNCg0KTkVXIGZvciBzZWN0aW9uIDMuNDoNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2Vz IG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUg bWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBk ZXNjcmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRh Lg0KDQpBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJz dCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNv bnRleHQgZmllbGQuICBUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0 aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBT RkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUg b2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9uIHJlY2VpdmluZyBhbiBOU0ggTUQtdHlwZSAx IHBhY2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBtYW5kYXRvcnkg dXNlIG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0YSBzZW1hbnRp Y3MgZm9yIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0 aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUg bGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHBy b3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0 YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuDQoNCk5FVyBmb3IgZW5k IG9mIHNlY3Rpb24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkg YXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3Ig dGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVzZSBjb25zaWRlcmF0aW9u cyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250cm9sIHBsYW5lIGNh biBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJlIG9mIFRMVnMg dG9nZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBvZiBbSS1ELmll dGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQg YmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBt aXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3Mg dGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KSWYgbXVsdGlwbGUgbWFuZGF0 b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0aGUgY29u dHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBvcmRlciB0 byBjb25zdW1lIHRoZXNlIFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0 aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5 YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0Lg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhl IHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhlIGRlZmluaXRp b24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIE1V U1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQg TVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nLg0KDQpGcm9tOiBzZmMgPHNm Yy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFs ZiBvZiBKaW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lz Y28uY29tPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDgsIDIwMTYgYXQgMTowMSBQTQ0KVG86 ICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJh Yy9zZmMvdGlja2V0LzIxDQoNCkRlYXIgU0ZDIFdHOg0KDQpBZnRlciBtdWNoIGRpc2N1c3Npb24g b24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0ICMyMSB0aGUgZm9sbG93aW5nIHRleHQg aGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5IG1ldGFkYXRhIHNlbWFudGljcyBhbmQg c28gZm9ydGguIFBsZWFzZSByZXZpZXcgYW5kIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgc28g dGhhdCB0aGUgY2hhaXJzIGNhbiBkZXRlcm1pbmUgY29uc2Vuc3VzIGFuZCB1cGRhdGUgdGhlIHRp Y2tldCBhY2NvcmRpbmdseS4NCg0KVGhhbmsgeW91IQ0KDQpKaW0gJiBKb2VsDQoNCiMjIyMjIyMj IyMNCg0KTkVXIGZvciBzZWN0aW9uIDMuNDoNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBt YWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFuZGF0 b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNjcmli ZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLg0KDQpB biBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBv cmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQg ZmllbGQuICBUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0aW9uIHNj aGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdh cmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp cyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9uIHJlY2VpdmluZyBhbiBOU0ggTUQtdHlwZSAxIHBhY2tl dCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBtYW5kYXRvcnkgdXNlIG9m IG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0YSBzZW1hbnRpY3MgZm9y IHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFj a2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpbZGNhbGxvY10gYW5kIFticm9hZGFsbG9j XSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhl IGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLg0KDQpORVcgZm9y IGVuZCBvZiBzZWN0aW9uIDMuNS4xOg0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2Ug YW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50 IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiAgVGhlc2UgY29uc2lkZXJh dGlvbnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuICBIb3dldmVyLCB0aGUgY29udHJvbCBwbGFu ZSBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBU TFZzIHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0kt RC5pZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuDQoNClVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0 aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYg aXMgbWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9j ZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQoNCklmIG11bHRpcGxlIG1h bmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhl IGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3Jk ZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiAgSWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRl ZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIg dGhleWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9m IHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZp bml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBT RiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQo= --_000_2691CE0099834E4A9C5044EEC662BB9D572EC4DDdfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAw IDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVi dWxsZXMNCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxp bms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRl eHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bh bjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1z dHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6Izk5MzM2NjsNCglmb250LXN0eWxlOml0YWxpYzt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTMzNjYiPkluIGZhdm9yIG9mIE1lZOKA mXMgdGV4dC4gJm5ic3A7SG93IGFib3V0IDoNCjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPk1VU1QgbG9nIGF0IGxlYXN0IG9uY2UgcGVyDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVk Ij50aGUgU1BJPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4gZm9yIHdoaWNoIGEgbWFuZGF0 b3J5IG1ldGFkYXRhIGlzIG1pc3NpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkx1Y3k8 L3NwYW4+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTMzNjYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk5MzM2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9pPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDE2IDk6MjEgQU08YnI+DQo8 Yj5Ubzo8L2I+IERhdmUgRG9sc29uOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcv dHJhYy9zZmMvdGlja2V0LzIxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPkkgd291bGQgc2F5OiDigJxNVVNUIGxvZyBhdCBsZWFzdCBvbmNlIHBlciBTRlAgZm9yIHdo aWNoIGEgbWFuZGF0b3J5IG1ldGFkYXRhIGlzIG1pc3NpbmfigJ0uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5CZXR0ZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si Pk1lZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZu YnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNm YyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gRGF2ZSBEb2xzb248YnI+DQo8 Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMTAgbm92ZW1icmUgMjAxNiAxNjoxMTxicj4NCjxi PsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSmltIEd1aWNoYXJkIChq Z3VpY2hhcik7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9h Pjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtzZmNdIDxhIGhyZWY9Imh0dHBzOi8vdHJh Yy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjEiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L3NmYy90aWNrZXQvMjE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+U28geW91IHdvdWxkIHNheSwg4oCcTVVTVCBsb2cgYXQgbGVhc3Qg b25jZSBwZXIgdHlwZSBvZiBtaXNzaW5nIG1hbmRhdG9yeSBtZXRhZGF0YeKAnSA/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+IFs8YSBo cmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBO b3ZlbWJlciAxMCwgMjAxNiAxMDowMiBBTTxicj4NCjxiPlRvOjwvYj4gRGF2ZSBEb2xzb247IEpp bSBHdWljaGFyZCAoamd1aWNoYXIpOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc2ZjXSA8YSBocmVmPSJodHRw czovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxIj5odHRwczovL3RyYWMuaWV0Zi5v cmcvdHJhYy9zZmMvdGlja2V0LzIxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgRGF2ZSwN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBpbXBsZW1lbnRhdGlvbiBt dXN0IGRlZmluaXRlbHkgbG9nIHRoZSBlcnJvcjogdGhhdCBpcywgdGhlcmUgaXMgYSBtaXNzaW5n IG1hbmRhdG9yeSBtZXRhZGF0YSBmb3IgYSBjaGFpbi4gSXQgZG9lcyBub3QgbmVlZCB0byBhZGQg YW4gZW50cnkgcGVyIHBhY2tldCBhcyB3YXMgcmlnaHRmdWxseQ0KIG1lbnRpb25lZCBieSBSb24u IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SG93IHRvIHByb3RlY3QgYW4gaW1wbGVtZW50YXRp b24gZnJvbSBtaXNjb25maWd1cmF0aW9uIGlzIG5vdCBzcGVjaWZpYyB0byB0aGUgbG9nZ2luZyBm ZWF0dXJlLCBidXQgaXQgaXMgYSBnZW5ldGljIGNvbmNlcm4gSU1ITy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgPC9iPjwvc3Bhbj48Yj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnBhcnQgZGU8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERhdmUgRG9sc29uPGJyPg0KPGI+RW52b3nDqSZu YnNwOzo8L2I+IGpldWRpIDEwIG5vdmVtYnJlIDIwMTYgMTU6NDk8YnI+DQo8Yj7DgCZuYnNwOzo8 L2I+IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3NmY10gPGEg aHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KaW0sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCB0aGlzIHdvcmRpbmcuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoaXMgYWxsb3dzIHRoZSBpbXBsZW1lbnRlciB0byBjaG9vc2UgYW4gYXBw cm9hY2ggdGhhdCBkb2VzIG5vdCBvdmVyd2hlbG0gdGhlIGRldmljZSB3aGVuIHRoZSBzeXN0ZW0g aXMgY29uZmlndXJlZCBpbXByb3Blcmx5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBpdCB3ZXJlIOKAnE1VU1Ti gJ0sIEkgd291bGQgZXhwZWN0IG1vcmUgZGV0YWlscyBhYm91dCB3aGF0IGV4YWN0bHkgc2hvdWxk IGJlIGxvZ2dlZC4gT3RoZXJ3aXNlLCBob3cgY291bGQgb25lIHRlc3QgY29tcGxpYW5jZT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPi1EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KaW0g R3VpY2hhcmQgKGpndWljaGFyKTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIg MTAsIDIwMTYgODoyOCBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gPGEg aHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGVhciBTRkMgV0c6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkFwb2xvZ2llcywgaXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQg SSBtaXNzZWQgYWRkaW5nIHRoZSB0ZXh0IGF0IGEgdGhpcmQgbG9jYXRpb24uIENvcnJlY3QgdGV4 dCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNz dW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0 IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVj dHVyZQ0KIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLiAmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbiBTRkMtYXdhcmUgU0YgTVVT VCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRo ZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuJm5ic3A7Jm5ic3A7 VGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aA0KIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBh bmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0Yg Z2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVj aWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlVw b24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNG IGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3Qg eWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlDQogbWFuZGF0b3J5IGNvbnRl eHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+LCBpdDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpyZWQiPlNIT1VMRA0KIGxvZyB0aGlzIGVycm9yLCBh bmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92 aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEg Y29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41 LjE8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Vi a2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNw ZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQg YXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRv LXByb2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlDQogZGVwbG95bWVu dC1zcGVjaWZpYy4mbmJzcDsmbmJzcDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5z dHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0 aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNm Yy1jb250cm9sLXBsYW5lXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQ LCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0 LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+LA0KIGl0PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRh cmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+U0hPVUxEIGxvZyB0aGlzIGVy cm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3Rh bmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8t cHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBs YW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1 bWUgdGhlc2UgVExWcy4mbmJzcDsmbmJzcDtJZg0KIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlk ZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVy IHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBh cmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQg VExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9j ZXNzDQogdGhlIHBhY2tldDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOnJlZCI+LCBpdCZuYnNwO1NIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5kIE1VU1QgYXBwbHkg cmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5zZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+ c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJkICZs dDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgYXQg ODoyMiBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIDxh IGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjEiPmh0dHBzOi8v dHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjE8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgU0ZDIFdHOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5HaXZlbiB0aGUgcmVjZW50IGRpc2N1c3Npb24g b24gdGhlIG1haWxpbmcgbGlzdCwgdXBkYXRlZCB0ZXh0ICh3aXRoIGNoYW5nZXMgaW4gUkVEKSBh cyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1w dGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZp ZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVjdHVy ZQ0KIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLiAmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbiBTRkMtYXdhcmUgU0YgTVVTVCBy ZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBk YXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuJm5ic3A7Jm5ic3A7VGhl IGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aA0KIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQg dGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0 cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlVwb24g cmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlz IGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0 IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3IgdGhlDQogbWFuZGF0b3J5IGNvbnRleHQg ZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+LCBpdDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBh cHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRlIHNhbXBs ZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQg aW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRp b24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRh dG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3Mu Jm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlDQogZGVwbG95bWVudC1zcGVjaWZp Yy4mbmJzcDsmbmJzcDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZD LWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGgg dGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9s LXBsYW5lXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VXBv biByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1h bmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZD LWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldA0KIGFuZCBNVVNUIGxvZyB0aGlz IGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIG11 bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVu IFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0 aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmDQogbm8gaW5z dHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhl c2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5k YXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJk JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBpbnN0YW5j ZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBidXQgdGhl IGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3 YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFja2V0PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj4sIGl0Jm5ic3A7U0hPVUxEIGxvZyB0aGlzIGVy cm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3Rh bmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnNmYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiBKaW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20i PmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE5v dmVtYmVyIDgsIDIwMTYgYXQgMTowMSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+W3NmY10gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tl dC8yMSI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRl YXIgU0ZDIFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFm dGVyIG11Y2ggZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB3aXRoIHJlZ2FyZCB0byB0aWNrZXQgIzIx IHRoZSBmb2xsb3dpbmcgdGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0byBoZWxwIGNsYXJpZnkgbWV0 YWRhdGEgc2VtYW50aWNzIGFuZCBzbyBmb3J0aC4gUGxlYXNlIHJldmlldw0KIGFuZCBpbmRpY2F0 ZSBzdXBwb3J0IChvciBub3QpIHNvIHRoYXQgdGhlIGNoYWlycyBjYW4gZGV0ZXJtaW5lIGNvbnNl bnN1cyBhbmQgdXBkYXRlIHRoZSB0aWNrZXQgYWNjb3JkaW5nbHkuJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91ITxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkppbSAmYW1wOyBKb2VsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IyMjIyMjIyMjIzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13 ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmlj YXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFj ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQg ZG9lcyBub3QgZGVzY3JpYmUgdGhlIHN0cnVjdHVyZQ0KIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1 ZGVkIG1ldGFkYXRhLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5BbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBm aXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5 IGNvbnRleHQgZmllbGQuJm5ic3A7Jm5ic3A7VGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90 aA0KIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVk IGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0 c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEg cGFja2V0LCBpZiB0aGUgU0ZDLWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1 c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGlj cyBmb3IgdGhlDQogbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3Mg dGhlIHBhY2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBwcm92aWRl IHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29u dmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5FVyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjE8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0 LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNp ZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJl IG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXBy b2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlDQogZGVwbG95bWVudC1z cGVjaWZpYy4mbmJzcDsmbmJzcDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1 Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVy IHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1j b250cm9sLXBsYW5lXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBp ZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0 aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldA0KIGFuZCBNVVNUIGxv ZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBh IGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUg U0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiZuYnNwOyZuYnNwO0lmDQog bm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nl c3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0 LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0 YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBp bnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFja2V0LCBi dXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUg U0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0 aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_2691CE0099834E4A9C5044EEC662BB9D572EC4DDdfweml501mbb_-- From nobody Thu Nov 10 09:10:55 2016 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 5E5AD129434 for ; Thu, 10 Nov 2016 09:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 nlZAWy-0d9Xl for ; Thu, 10 Nov 2016 09:10:52 -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 89F5D1294D5 for ; Thu, 10 Nov 2016 09:10:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAC90513; Thu, 10 Nov 2016 17:10:48 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Nov 2016 17:10:37 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 09:10:31 -0800 From: Lucy yong To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , "wang.cui1@zte.com.cn" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSOvyOal9t2EP53k26GM4GNxjWzKDSuSoAgAApLwD//5IhsA== Date: Thu, 10 Nov 2016 17:10:30 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572EC4F4@dfweml501-mbb> References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> <9C8B3B99-1938-4B49-844F-C65F53A48725@cisco.com> <2df5c8d8-ae75-85ac-7940-cd4264a960e8@joelhalpern.com> In-Reply-To: <2df5c8d8-ae75-85ac-7940-cd4264a960e8@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5824AA18.03D2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6171c8b3024d230cb6eaf47f5df20e07 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 10 Nov 2016 17:10:53 -0000 IldoaWxlIGZvciBzb21lIFNGLCBiZWluZyB0b2xkICJ1c2UgREMgYWxsb2NhdGlvbiIgd2lsbCBi ZSBzdWZmaWNpZW50LCBJIGV4cGVjdCBpbiBtYW55IGNhc2VzIHRoYXQgd2hhdCB0aGUgU0YgbmVl ZHMgdG8gYmUgdG9sZCBpcyB0aGF0IGJ5dGVzIDcgLQ0KOSBhcmUgdGhlIGluZGV4IGl0IG5lZWRz IHRvIHVzZSBhcyB0aGUga2V5IGZvciBnZXR0aW5nIHRoZSBzdWJzY3JpYmVycyBjb250ZW50IGZp bHRlcmluZyBwb2xpY3kuICBTbyB3ZSBoYXZlIHRvIGFsbG93IGJvdGggdGhlIGdlbmVyYWwgYW5k IHRoZSBzcGVjaWZpYyByZXByZXNlbnRhdGlvbi4iDQoNCkFncmVlLg0KTHVjeQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJl ciAxMCwgMjAxNiA5OjQzIEFNDQpUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHdhbmcuY3Vp MUB6dGUuY29tLmNuDQpDYzogc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gaHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMQ0KDQooVGhpcyBpcyB0aGUgY2FzZSB3 aGVyZSBldmVuIHRoZSBjaGFpcnMgbWVhbnQgc2xpZ2h0bHkgZGlmZmVyZW50IHRoaW5ncywgc28g dGhhbmtzIGZvciBtYWtpbmcgc3VyZSB3ZSBhcmUgY2xlYXIuKQ0KDQpQZXJzb25hbGx5LCBJIHRo aW5rIHRoYXQgdGhlIG1hcHBpbmcgYmV0d2VlbiB2YWx1ZSBhbmQgbWVhbmluZyBpcyBnb2luZyB0 byBiZSBoYW5kbGVkIHZpYSBpbmRpcmVjdGlvbi4gIEkgZG8gbm90IHRoaW5rIHRoYXQgdGhlIGNv bnRyb2wgc3lzdGVtIHdpbGwgZXZlciBzYXkgdGhhdCB2YWx1ZSAxMDEgbWVhbnMgImNva2UiLiAg UmF0aGVyLCBJIHRoaW5rIHRoYXQgdGhlIGNvbnRyb2wgc3lzdGVtIHdpbGwgcHJvdmlkZSBlbm91 Z2ggaW5mb3JtYXRpb24gdGhhdCB0aGUgU0YgY2FuIGRldGVybWluZSBob3cgdG8gaW50ZXJwcmV0 IDEwMS4gIFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgd2hhdCB0aGUgU0YgbmVlZHMgdG8ga25vdyBp cyBub3QgImNva2UiLCBidXQgcmF0aGVyIHdoYXQgZGF0YSBzZXQgaXQgY2FuIHVzZSB0aGUgZ2l2 ZW4gdmFsdWUgYXMgYSBrZXkgaW50bywgYW5kIHdoYXQgbWVjaGFuaXNtIChwcmUtcHJvdmlzaW9u ZWQgZGF0YSBzZXQgMywgcmFkaXVzLCBkaWFtZXRlciwgTERBUCwgLi4uKSBpdCBjYW4gdXNlIHRv IGdldCB0aGUgaW5mb3JtYXRpb24gaXQgbmVlZHMgdG8gZG8gaXRzIGpvYiB1c2luZyB0aGF0IGtl eS4NCg0KV2hpbGUgZm9yIHNvbWUgU0YsIGJlaW5nIHRvbGQgInVzZSBEQyBhbGxvY2F0aW9uIiB3 aWxsIGJlIHN1ZmZpY2llbnQsIEkgZXhwZWN0IGluIG1hbnkgY2FzZXMgdGhhdCB3aGF0IHRoZSBT RiBuZWVkcyB0byBiZSB0b2xkIGlzIHRoYXQgYnl0ZXMgNyAtDQo5IGFyZSB0aGUgaW5kZXggaXQg bmVlZHMgdG8gdXNlIGFzIHRoZSBrZXkgZm9yIGdldHRpbmcgdGhlIHN1YnNjcmliZXJzIGNvbnRl bnQgZmlsdGVyaW5nIHBvbGljeS4gIFNvIHdlIGhhdmUgdG8gYWxsb3cgYm90aCB0aGUgZ2VuZXJh bCBhbmQgdGhlIHNwZWNpZmljIHJlcHJlc2VudGF0aW9uLg0KDQpZb3VycywNCkpvZWwNCg0KT24g MTEvMTAvMTYgODoxNSBBTSwgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgd3JvdGU6DQo+IEhpIExp bmRhLA0KPg0KPiBCeSB0aGlzIHdlIG1lYW4gaG93IHRoZSBTRiBpcyB0byBpbnRlcnByZXQgdGhl IGRhdGEgY2FycmllZCB3aXRoaW4gdGhlIA0KPiBtZXRhZGF0YS4gRm9yIGV4YW1wbGUsIHRoZSBh bGxvY2F0aW9uIHNjaGVtYSBtaWdodCBzYXkg4oCcdGVuYW50LWlkIA0KPiBjYXJyaWVkIGF0IG9m ZnNldCA8YmxhaD7igKbigJ0gYnV0IHRoZW4gdGhlIFNGIG5lZWRzIHRvIHVuZGVyc3RhbmQgd2hh dCANCj4gdGhlIGV4dHJhY3RlZCB2YWx1ZSBmcm9tIHRoZSBtZXRhZGF0YSBjb3JyZXNwb25kcyB0 byBpbiB0ZXJtcyBvZiB3aGljaCANCj4gdGVuYW50IGUuZy4gdmFsdWUgMTAxIG1pZ2h0IG1lYW4g 4oCcY29rZeKAnS4g4oCcY29rZeKAnSBpbiB0aGlzIGV4YW1wbGUgaXMgbm90IA0KPiBjYXJyaWVk IHdpdGhpbiB0aGUgbWV0YWRhdGEgc28gdGhlIFNGIG5lZWRzIHRvIG1hcCB0aGUgdmFsdWUgZnJv bSB0aGUgDQo+IG1ldGFkYXRhIHRvIGEgbWVhbmluZ2Z1bCB0ZW5hbnQgaWRlbnRpZmljYXRpb24u DQo+DQo+IEhvcGUgdGhpcyBjbGFyaWZpZXMgLi4NCj4NCj4gSmltDQo+DQo+IEZyb206ICJ3YW5n LmN1aTFAenRlLmNvbS5jbiA8bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPiINCj4gPHdhbmcu Y3VpMUB6dGUuY29tLmNuIDxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+Pg0KPiBEYXRlOiBX ZWRuZXNkYXksIE5vdmVtYmVyIDksIDIwMTYgYXQgOTo0NSBQTQ0KPiBUbzogSmltIEd1aWNoYXJk IDxqZ3VpY2hhckBjaXNjby5jb20gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KPiBDYzog InNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmcgDQo+IDxt YWlsdG86c2ZjQGlldGYub3JnPj4sIHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmcgDQo+IDxtYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBSZTogW3NmY10gaHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMQ0KPg0KPiBEZWFyIEppbSAmIEpvZWwsDQo+ DQo+ICAgIFRoZSB0ZXh0IHNhaWQ6ICd0aGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRo ZSBhbGxvY2F0aW9uIA0KPiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBk YXRhLicNCj4gICAgSSBhZ3JlZSB3aXRoICd0aGUgYWxsb2NhdGlvbiBzY2hlbWEnIGNhbiBoZWxw IHRoZSBTRkMtYXdhcmUgU0YgdG8gDQo+IGtub3cgaG93IHRvIGludGVycHJldCB0aGUgbWFuZGF0 b3J5IGNvbnRleHQgZmllbGQuIEhvd2V2ZXIsDQo+ICAgIENvdWxkIHlvdSBjbGFyaWZ5IHdoYXQg aXMgJ3RoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhJyBhbmQgDQo+IGhvdyB0byBkZXNj cmliZScgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEnPw0KPg0KPiAgICBUaGFua3Mg dmVyeSBtdWNoIDopDQo+DQo+IEJScw0KPiBMaW5kYSBXYW5nDQo+DQo+DQo+DQo+DQo+DQo+DQo+ ICoiSmltIEd1aWNoYXJkIChqZ3VpY2hhcikiIDxqZ3VpY2hhckBjaXNjby5jb20gDQo+IDxtYWls dG86amd1aWNoYXJAY2lzY28uY29tPj4qDQo+IOWPkeS7tuS6ujogICJzZmMiIDxzZmMtYm91bmNl c0BpZXRmLm9yZyA8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4NCj4NCj4gMjAxNi8xMS8w OSAwMjowMQ0KPg0KPiAJDQo+IOaUtuS7tuS6ug0KPiAJInNmY0BpZXRmLm9yZyA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmcgDQo+IDxtYWlsdG86c2ZjQGlldGYub3JnPj4sDQo+ IOaKhOmAgQ0KPiAJDQo+IOS4u+mimA0KPiAJW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvc2ZjL3RpY2tldC8yMQ0KPg0KPg0KPiAJDQo+DQo+DQo+DQo+DQo+DQo+IERlYXIgU0ZDIFdH Og0KPg0KPiBBZnRlciBtdWNoIGRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8g dGlja2V0ICMyMSB0aGUgDQo+IGZvbGxvd2luZyB0ZXh0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGhl bHAgY2xhcmlmeSBtZXRhZGF0YSBzZW1hbnRpY3MgDQo+IGFuZCBzbyBmb3J0aC4gUGxlYXNlIHJl dmlldyBhbmQgaW5kaWNhdGUgc3VwcG9ydCAob3Igbm90KSBzbyB0aGF0IHRoZSANCj4gY2hhaXJz IGNhbiBkZXRlcm1pbmUgY29uc2Vuc3VzIGFuZCB1cGRhdGUgdGhlIHRpY2tldCBhY2NvcmRpbmds eS4NCj4NCj4gVGhhbmsgeW91IQ0KPg0KPiBKaW0gJiBKb2VsDQo+DQo+ICMjIyMjIyMjIyMNCj4N Cj4gKk5FVyBmb3Igc2VjdGlvbiAzLjQqOg0KPiBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg bWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCANCj4gcGxhY2VkIGluIHRoZSBt YW5kYXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IA0K PiBkZXNjcmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFk YXRhLg0KPg0KPiBBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGlj cyBmaXJzdCBpbiBvcmRlciB0byANCj4gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1h bmRhdG9yeSBjb250ZXh0IGZpZWxkLiAgVGhlIGRhdGEgDQo+IHNlbWFudGljcyBpbmNsdWRlIGJv dGggdGhlIGFsbG9jYXRpb24gc2NoZW1hIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgDQo+IGluY2x1 ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMg b3V0c2lkZSANCj4gdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCj4NCj4gVXBvbiBy ZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlmIHRoZSBTRkMtYXdhcmUgU0YgaXMg DQo+IGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3Qg eWV0IHJlY2VpdmVkIHRoZSANCj4gZGF0YSBzZW1hbnRpY3MgZm9yIHRoZSBtYW5kYXRvcnkgY29u dGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyANCj4gdGhlIHBhY2tldCBhbmQgTVVTVCBs b2cgdGhpcyBlcnJvci4NCj4NCj4gW2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10gcHJvdmlkZSBz YW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgDQo+IG1lYW5pbmcgd2l0aCB0aGUgZGF0YSBj b252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuDQo+DQo+ICpORVcgZm9yIGVu ZCBvZiBzZWN0aW9uIDMuNS4xKjoNCj4gVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2Ug YW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSANCj4gbWFuZGF0b3J5LXRvLWltcGxl bWVudCBvciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gIFRoZXNlIA0KPiBj b25zaWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250 cm9sIHBsYW5lIA0KPiBjYW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0 cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIA0KPiB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0 aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLg0KPg0KPiBVcG9uIHJl Y2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgDQo+IG1h bmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZD LWF3YXJlIFNGIA0KPiBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRo aXMgZXJyb3IuDQo+DQo+IElmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJl IHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgDQo+IHRoZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0 cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIA0KPiBjb25zdW1lIHRoZXNl IFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNG IA0KPiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleSBhcHBlYXIgaW4g dGhlIE5TSCBwYWNrZXQuDQo+DQo+IElmIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBU TFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIA0KPiBidXQgdGhlIGRlZmluaXRpb24g b2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGIA0KPiBN VVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgDQo+IGVycm9yLl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWls aW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0 DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Thu Nov 10 10:36:09 2016 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 5C004129478 for ; Thu, 10 Nov 2016 10:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=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 3vbnuiJiO31V for ; Thu, 10 Nov 2016 10:36:06 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0109.outbound.protection.outlook.com [104.47.34.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF88612943F for ; Thu, 10 Nov 2016 10:36:06 -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=EfFSzJxmjtUPnwfEAwYKdVv4F7e98SBxIckjfuSA7Zs=; b=Lx9IJaGVV1p8r3xrAQMRnRhh/pNxfg5Sj3eSyGsEOtJXm6iYHbONOIsdyTrXNA/CQLZP0kcA/KpGkS96WEYscyDrzd7CHrvw++MOYu9WK6aJqI0tiAZeh/FN8jP2pxzcVh43xYo6zsJ6qGbbR4qaks86ESN6lY2TQtWVwy+Adi8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.92] (66.129.241.13) by CY1PR05MB2185.namprd05.prod.outlook.com (10.166.192.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Thu, 10 Nov 2016 18:36:04 +0000 To: Loa Andersson , , 'Dave Dolson' , References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <71fee848-be00-9137-286f-4908125e62a5@pi.nu> From: Eric C Rosen Message-ID: Date: Thu, 10 Nov 2016 13:35:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <71fee848-be00-9137-286f-4908125e62a5@pi.nu> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY1PR10CA0021.namprd10.prod.outlook.com (10.160.197.31) To CY1PR05MB2185.namprd05.prod.outlook.com (10.166.192.9) X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 2:w4hY3Q1lbrA8mJa9wz5X2o8Je5VxuHpUXT3GN/wHcbzVxoE2pv3cBzAP/lqSRTrTQi0cggtoLWtm81qlq3d428GulweWF1EqhrTpVSxzm5/oPyFHUNmiMMQ/7hKK8OSIoIOtM46tZ7Q2Y4u+cAdXUbrqvV2W+3F2C5PiTI9jYBA=; 3:BsHrfoxNKZtLY7MOe7hYtrmsATUWSgrScj/Y4QffzR2q2Vdn8ZakIz/6DN7MvB0H73o+tfjKVex7ICXvFkwh1zQ4kSoOfB+2UpGCCzLKHA+kNP3TRSb9sD8MZZI+ukcBAXUzkG2B4E1kovCv3iELiVxRdZnG+HnFKQIip8aSjwU=; 25:qtqb8AdY1CcxMWVU9eLQdfH5mwqzM7R7Pk3YUEoMlOVVTdoI85Zh2/IfSxjD4eGKUncGZqmcfKThyrfAZhkQwIcKOAk81iZeAqSuHUbrcx4raaPJJtlFcvkgwXYzpcF8ihebS3XvTgYy2vtff7RanZH116WiqR3reLXI9mfoZKptaRG6rqGNrSPuTeA7BJlrOW2d62HJI33/r5FQI99qejfrwq4M3oBS+IreHhctSAlQm/rZWDYDkneTUYDAyFGMd3FCNZ1OFNb1O0LUsMNvozSmi6cdTEUSI/s4rFDyNkkXwx2n7ajfksAbCR24FdhvyJvsmesxRaI0G4TM9jxNJoSKmsAXy0arkIMqQRIvbDCLWMiWjw1uOE5/lw7KtidLGV56peXZ1ylCiFgAZZyOcAmGRwTQWRk7iHYTHTdfNDsf5N7aHM+ks5w0oYxDWaso X-MS-Office365-Filtering-Correlation-Id: 76054d24-f97f-4c48-dbb2-08d409986e29 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2185; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 31:hZrELcLmb8Pp1QReZ9BRaQuYg+u4362yQJpIQyeKnEFTKrGWmTQFqWELghAgtmJHGauQsW9BrKHyv80/MsqcRbIKpVTfjQ6r0uRIwEGwkXUpmwnH2Zi2N4xnbDJTD+786wklQttGORakiu8/CMnrqioj3ADl91fGybNNhUckv1iQf7fCFIPjeIXATkyUghb/ZmJzLTB/5G0VjM4dx+oFhHWLO61Z6sCNUuLT0QFWIce1VX0fX+T5GU/Hh3bVhq9X9rA2VBnA0i8F0Stc5NTDjA==; 20:WlP9vFQuQIxwaeo7ocNXRYrnyQcUBYYbOfbhaU7CAuUPGmptARpQJ3m9YzQRwI2ITW/CQ7JkGGEogPRJN2TQgtQYGarqG/IUeHnU6hMNnnL7uO76D5Oh/eu6RJ0+3lwWc4nk7oA14Z4Fz0JLxjX6Tbj+4/0r9QWwrD5CyB8wMWtGM1Hkimw0d/aqB1GZ9BnqzttXHq6LhIeXT12EIRycTayfMffI4H8nC1RhMjrSAfIYyLAAD04yV/BNHyVFyl0hzAsRRFYcaNcAth3XL8Pe8rjb8IV9kvzNfm9obrPHSJOacY4bqsgjcOpzT+U2C9Zkau8JATRTY4v14+FwAQ4W8n84h/Sl9j9iahDR5Z+veSTTomvUrXKRHUs8MUpg4rRDKnfylRgLlMCS9PhH47q6VY3piaCeQmKDFK31zV1OZO/6BN72tNebag8NBfuRhcngPyTyDlicrARDRSdqpn5IAoANVYGLCgwWFX0RyqwtSO8DYPmKc8q04o2QuhGDH5GovKrzNTWrXlvFYwJQfgOY6tMHlouLs7MYy3jkfQmGVCQxgAj9rHqFRGUP5uUlYQk1uY7dkevHJ8uy47tXBLdV7B4wU3IzIHuM7yU122ESvqY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(131327999870524); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2185; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2185; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 4:mod11zZgsZ9Q4ZBh2At9W2UluapyqgeWPm+orL/rJqkcP2+H0fDGBgenoVr7Yw9AgxmH0l0v/srJAJtDLk4OuPSestLhC6UYdeogJ1cj4j9DZ9FtH73Twg4sO0CSyqCb7h+fRGwLCoVlvQv3+Ha79z/qAwMTwZqMnoOfn/d6kHOQrHd//F7lMyOcWfUMda0QsMFi7wabiAMCr4EySevwwiwUeyYM96LFuDkA69XMcTNRWNfypPUrvWbMm1Ms+3tVelb2ly0R/PZHFgrRW6eWC1894VhzJKBOO5wgxpMVpsSBnY0qOmay/JcsgKGE1QRs8BOxQyLyfh6azOzWsugnn/LIIBrQTImQ6Gw+xbhEdxHfDMwvWcCaASCJNJLIAgtDz7ulk7+Ac4nrLnJRpaaEiOZiNAUsMmi6fbuPJHs8mSf+pGLF9GrfSjS9ljA1JAcigYAr7Mkq13/k4kjwEbeRgA== X-Forefront-PRVS: 01221E3973 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(24454002)(189002)(377454003)(199003)(65806001)(2906002)(5001770100001)(66066001)(65956001)(33646002)(8676002)(81166006)(81156014)(64126003)(101416001)(305945005)(47776003)(7736002)(7846002)(50986999)(77096005)(76176999)(230700001)(54356999)(97736004)(4001350100001)(86362001)(31696002)(50466002)(107886002)(23746002)(65826007)(5660300001)(83506001)(3846002)(6116002)(586003)(105586002)(189998001)(106356001)(92566002)(68736007)(36756003)(229853002)(31686004)(6666003)(42186005)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2185; H:[172.29.35.92]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR05MB2185; 23:viwzRAoLwl1NuvkpqQzDFz/h2ReACa0XFNdWQ?= =?Windows-1252?Q?VITiY3SOkCNOkyZ+RpgvUUFZBCdKV5OKL0ltEsJ7iqcF5lhj2Ifc5o3H?= =?Windows-1252?Q?HKHOGbGnr9vT2RBf2mE9rNR6Ya0Lj4VjQxXjnoH6nBK94xPgm49wNzew?= =?Windows-1252?Q?VL8qmSCrdOYpf72D3pAGFejIfQgWhY0JB3SyiyRuR5drVN54BzQbWhwu?= =?Windows-1252?Q?bZZmv/OeA7F/DTOHrgU3Oap+391VZV207UW9U9hk2LIPYSOW472nB6qp?= =?Windows-1252?Q?jJNTl3NhfAHk74VDpkfyas3yG4JX2iEupy4qwlodhryZSotlkuiS5oYm?= =?Windows-1252?Q?iwkPZcGB842J/HCanoClNlRBYlwtOOGRHapzWEwRad/foqKu7DL4vgTt?= =?Windows-1252?Q?RCOoZ1rgCC7+Jgfa+TwLLdK6balWhfQtsPhowXS/1jFig+ysdbkbCAMn?= =?Windows-1252?Q?mpsN9Jzpmed5uUHMavdukcc+3eBwFd0KoJDsHWHfqyIcVjuEumqt+MBU?= =?Windows-1252?Q?B9BaOJXjLxcbdbQidGEAcmyN9kge+7O5hagKFe9LBG23YDM64I5bWUwl?= =?Windows-1252?Q?rcArhXOaHiesMMa+DyDrTGAAEYEFuP5t17KXRZqaRoz014ank/fovcRN?= =?Windows-1252?Q?qtpq38jQYtINgE47CggH26JZstZYuO63i64j2AELlmaJ1z3ibH63sNFR?= =?Windows-1252?Q?GxWGqBHHg384v4k4wTShtcM8Oy/9AhAOKnVp5npI4IZj5TLKGSgYLnNs?= =?Windows-1252?Q?f5J82HETl3K/EYo/QSs30Je+yAIMRPDAVu6T7kku8Y0JgQHySRi83H3G?= =?Windows-1252?Q?HUmIT0BMIcgx6RqfsKGoh3v8xfZRjip4VP69OZgW5EZSx3aoZ/LHl8Vq?= =?Windows-1252?Q?V0IL2aCjsxxe0tBRIdcUKjJvvcxnXq/epumUwjdZmet/XZAP+umjuHr2?= =?Windows-1252?Q?4PFoAewCLMxvdULOUxymtME7j26pSPPbwclqpY3dmUzKX4bnmKNZ4JtY?= =?Windows-1252?Q?1efNREHJT6KroY82zcMbzD+VmOWNV/bGDM/H7QiUf8bjZp2eYY98FPZy?= =?Windows-1252?Q?w5NPEMS0w22uvxNobHDozbBcTHYLd8YCM0hleN2LE+g5r3UBdBtURwcg?= =?Windows-1252?Q?4ml8gHmgjlbVYDtFeLtsHWGCGiD1kd23tFepYOj9qhV+d6c2SH7SgV8T?= =?Windows-1252?Q?2x5ItdVHkSVfaHwMo44qEGGw6ZpORNxAnUiAjkj2AQWTydWAVCYT7Zin?= =?Windows-1252?Q?UBSrWiANoAGtUQYhrO58JOWqE0DlCoe03zeJ3gJt3RDjdtri6roglUEs?= =?Windows-1252?Q?7J1YfvUyTOjI3odPcWMcg0qojWzFaZwnVa5lp6SRD31uC8=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 6:7oxCLFdB6mg2flZ3MDxkW0mG0GYJUatQ5fDYpXzOA9+zWNZCNMT7ty7d/K87ar1aw1jamiOD2Ph7JfI8FtMQsaa1tou47escPbrv0hPJ/1ymbwTKyRxsmCgrWIOcgixoiJV5W+NBCGjsYzdA8hAB+q9zcpmKvQMMHQEtww2LSBbj4JuOByGEA/uBQK0XKTGLGfk30DKS2qnU59Rn3aNOWjBMKQFclV59/m+z3Q+xNSurEQHWyTYxBn0oSmLke0sFxUFDuYHS5c7TwIqDU01wDvECJ73rEZsDlJV3PmDZYy4vHMQwYdzw7+FNbOkpfeYmK4ra8JtEduugj+eqkCRahaTHU1u8ShimFFAm+TQUvNU=; 5:4jKbAwzoxFL+7ktEJjXeTnm0VvDmVNG2CDvDVV22dcVJrWD5QK6FGUVSLIs9J7fX0mgR6u7D8rWVTXyNveNNzO3jw3E0ebNrYwfw2LmBLMaLkrNkOngIlu3FL+ThyKIDTgcWgUnM6DMBm+zsX2gW1w==; 24:tcm4nFIwbwUxRNAU+EhEy9VfRVFv9RwKj7D8ht6n2on/DJPliUMvTWxm6h+B7POfUmISWDNvrZ0W5tQaqyMKCX0DK6BD16X9RQ3w//vkU6c= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 7:5l0A3976raSgouqDgSjNGP9lfxFf0XddlwLNW4jMP0B9Ea/nABwkgDnxNjhtYC+1dd+W6pSnyVjlJ9Mm1iA8rRSFgytvbn0/hEjEzXk3S/8rSOpDHD7Afk4j7ON8sC5OsN5fZhy+yN2assbaO/XDqh31PrvTygYEPMF5XlDG9zzqc1IrDiPmt8bzjJ23Y64F53q+fz2lrZasgf2IMF9wvbpe0hPdHB6xvblq8IOfmQZTLvt4q2n3bjjINAs6lA9AKWUIt6tzqOynPIbhihNjTWNEC96+XFWOm35NMWC2JFOR/0ib8NO1KwZdef8mUPnZGvHeiJrgUqHCyJo9fOKhlkpQz6qezn40hNz4zF3MdVU= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2016 18:36:04.3099 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2185 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 10 Nov 2016 18:36:08 -0000 On 11/6/2016 5:56 AM, Loa Andersson wrote: > I can't think of a case where it is harmful to decrement by another > value than 1. > > OTOH hand have shown that it is useful? I think there is a real issue here, but I don't think it has been captured well in this discussion. IMHO the real issue is whether the successive elements (SFIs) in a service path (as identified by a specific SPI) are required to have successive integers as their SIs. I don't think this has much to do with the behavior of the SF. I understand that the SF needs a way to mark the NSH to indicate "I'm done with this packet". Apparently the only way for the SF to do this is to decrement the SI by something. And we'd like the SF to be able to indicate "I'm done" without knowing anything about the SPI. This implies that the decrement needs to be a fixed value. And if it's going to be a fixed value, it might as well be 1. It wouldn't make sense to have an option to configure an SF to "decrement by 5", say, because if we don't want to require the successive elements of the SPI to have successive integers as their respective SIs, we also don't want to require that they have successive multiples of 5 as their SIs. If we wanted the SF to do anything other than decrement by 1, we'd really need to pass it enough information about the SPI to enable it to identify the next hop. That seems undesirable. So suppose the SPI has two elements, one with SI=3 and one with SI=5. If an SF gets a packet with SI=5 in the NSH, it processes the packet, sets the SI to 4, and sends the packet to the SFF. Initially I thought that the SFF could interpret "SI=4" as meaning "the next hop after SI=5". The SFF knows the SPI, can see that the next hop after 5 is 3, and thus could change the SI in the NSH to 3, and then forward the packet. However, I've been told that the SFF isn't supposed to do stuff like this, because only a classifier can modify the SPI/SI at this point. So instead we'd have to say that the SFF has a co-resident classifier that modifies the SI as described. Of course, if you deploy SFFs that don't have the co-resident classifier then you wouldn't be able to deploy SPIs with non-successive integers as the SIs. Well, if you want to deploy an optional feature, you need to deploy software that supports that feature. I've only seen one really interesting argument against creating SPIs with non-successive SIs, the argument that says that that would make it more difficult to figure out the "reverse" of an SPI. This will require some further thought. Now to Loa's question (or my reinterpretation of it) of whether there is an advantage to having non-successive SIs in an SPI, I'd say yes. If you think that SPIs may get modified (by insertion or deletion of elements) dynamically, and that such modifications need to be distributed dynamically, it seems like a good idea to be able to make these modifications without changing the SIs of the elements that were present before the modification. After all, one can think of an SPI/SI as an address of an SFI. You want to be able to add/remove SFIs from an SPI without changing the addresses of all the SFIs. This will get you much more consistent/predictable behavior during the convergence period where not everyone knows about the change yet. (Imagine if you couldn't add or remove a system from the network without changing the addresses of all the other systems.) Of course, someone will say that the WG has already determined that the SPIs never need to be modified dynamically. But that's really a deployment decision, not a decision that should be forced by the architecture or the protocol design. From nobody Thu Nov 10 13:50:06 2016 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 EC5F71295CA for ; Thu, 10 Nov 2016 13:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.518 X-Spam-Level: X-Spam-Status: No, score=-8.518 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=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 y3EHldtZW-9K for ; Thu, 10 Nov 2016 13:50:04 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073D6129566 for ; Thu, 10 Nov 2016 13:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1478814604; x=1510350604; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=jyvXr0legivJ4nEUfB/dvvNaH5KtLrWBz0Crg9j25Jg=; b=ZuWjVg08gg3FzXr5fmn4IDm1Crk6VsN8c2E8RBe+A5fPypdBp+7Qfmfl d/K2rVQgK3PQoxQaoHZgfmUejIlSjR8VP3JNFU8mlD+/scxwck303SwNQ Z/OrPnNXjI31YDHt4Xdz+XPxOjVJS0wKbZLkP41gP5+bPO249EsZAdU9W 8=; X-IronPort-AV: E=McAfee;i="5700,7163,8345"; a="254324756" X-IronPort-AV: E=Sophos;i="5.31,620,1473120000"; d="scan'208";a="254324756" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 10 Nov 2016 21:50:03 +0000 Received: from SE3CCPEMS02.olympus.F5Net.com (172.23.161.13) by seaexchmbx01.olympus.F5Net.com (192.168.15.223) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 10 Nov 2016 13:50:01 -0800 Received: from SE3CCPEMS05.olympus.F5Net.com (172.23.161.16) by SE3CCPEMS02.olympus.F5Net.com (172.23.161.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Thu, 10 Nov 2016 13:50:00 -0800 Received: from SE3CCPEMS05.olympus.F5Net.com ([fe80::50f9:a657:ac15:1c1f]) by SE3CCPEMS05.olympus.F5Net.com ([fe80::50f9:a657:ac15:1c1f%18]) with mapi id 15.01.0544.027; Thu, 10 Nov 2016 13:50:00 -0800 From: Sumandra Majee To: "Surendra Kumar (smkumar)" , "mohamed.boucadair@orange.com" , Dave Dolson , Adrian Farrel , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AQHSO5xiLeuFLsOdI0OyLd3dexy9YQ== Date: Thu, 10 Nov 2016 21:50:00 +0000 Message-ID: <97DED7FB-29F9-41D2-8212-D0EEB437C37D@f5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.168.15.218] Content-Type: text/plain; charset="utf-8" Content-ID: <85CC68D37188774CAC28C568F99CD749@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 10 Nov 2016 21:50:05 -0000 4oCcW01lZF0gV2UgYWxyZWFkeSBoYXZlIGEgIkNQIGNvbnRyb2xsZWQgU0ZDIGZvcndhcmRpbmcg dGFibGUiLiBUaGUgY29uc2Vuc3VzIG9mIHRoZSBXRyBvbiB0aGUgZm9yd2FyZGluZyB0YWJsZSBp cyBhcyBmb2xsb3dzIChDUCBkcmFmdCk6DQpTSz4gVGhhbmtzIGZvciB0aGlzIGluZm9ybWF0aW9u Lg0KU28sIFNQSSBpcyBhIHByaW1hcnkga2V5IGFuZCBwcm9iYWJseSBTSSBhbmQgb3RoZXIgaW5m b3JtYXRpb24gYXJlIGFkZGl0aW9uYWwga2V5cy4gSXQgZG9lcyBub3QgaG93ZXZlciBtYW5kYXRl IGEgc3BlY2lmaWMgdmFsdWVzIGZvciBTSS4gSSB3aWxsIHRha2UgdGhpcyB0byBtZWFuLCBDUCBk cmFmdCBhbHJlYWR5IGFsbG93cyBhbnkgU0kgdmFsdWUgdG8gYmUgcHJvZ3JhbW1lZC4gUGxlYXNl IGxldCBtZSBub3cgaWYgdGhpcyBpcyBpbmNvcnJlY3QgaW50ZXJwcmV0YXRpb24u4oCdDQoNCkkg aGF2ZSBhbHdheXMgaW50ZXJwcmV0ZWQgKGF0IGxlYXN0IGltcGxlbWVudGVkKSB3aXRoIFNQSSBi ZWluZyB0aGUgcHJpbWFyeSBrZXkgYWxvbmcgd2l0aCBwb3NpdGlvbi9vcmRpbmFsIG51bWJlciBv ZiBTRiB3aGljaCBpcyBjYW4gYmUgZGVyaXZlZCBmcm9tIGludGVyZmFjZS9wb3J0L3ZsYW4gZXRj LiANCk5leHRfaG9wID0gdGFibGVbU1BJXVtwb3NpdGlvbl0NCg0KSWYgdGhlIHBvc2l0aW9uIG9m IHRoZSBTRiBjYW4gYWxtb3N0IGFsd2F5cyBiZSBkZXJpdmVkIGluZGVwZW5kZW50IG9mIFNJLiBU aGUgU0kgaXMgbm90IHRoZSBvcmRpbmFsIG51bWJlciBvZiBzZXJ2aWNlIG5vZGUgaW4gYSBnaXZl biBwYXRoLCB0byBtZSBpdCBtZWFucywNCmEpIEEgU0YgaGFzIHJlbmRlcmVkIHNlcnZpY2UNCmIp IFRoaXMgcGF0aCBoYXMgYSBsb29wLiANCg0KSSBkb27igJl0IHRoaW5rIG9uZSBzaG91bGQgZGVw ZW5kIFNJIHRvIGZpZ3VyZSBvdXQgdGhlIGVuZCBvZiBjaGFpbiBlaXRoZXIuDQoNCg0KDQpPbiAx MS83LzE2LCAyOjM2IFBNLCAic2ZjIG9uIGJlaGFsZiBvZiBTdXJlbmRyYSBLdW1hciAoc21rdW1h cikiIDxzZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc21rdW1hckBjaXNjby5jb20+ IHdyb3RlOg0KDQogICAgW01lZF0gV2UgYWxyZWFkeSBoYXZlIGEgIkNQIGNvbnRyb2xsZWQgU0ZD IGZvcndhcmRpbmcgdGFibGUiLiBUaGUgY29uc2Vuc3VzIG9mIHRoZSBXRyBvbiB0aGUgZm9yd2Fy ZGluZyB0YWJsZSBpcyBhcyBmb2xsb3dzIChDUCBkcmFmdCk6DQogICAgU0s+IFRoYW5rcyBmb3Ig dGhpcyBpbmZvcm1hdGlvbi4NCiAgICBTbywgU1BJIGlzIGEgcHJpbWFyeSBrZXkgYW5kIHByb2Jh Ymx5IFNJIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBhcmUgYWRkaXRpb25hbCBrZXlzLiBJdCBkb2Vz IG5vdCBob3dldmVyIG1hbmRhdGUgYSBzcGVjaWZpYyB2YWx1ZXMgZm9yIFNJLiBJIHdpbGwgdGFr ZSB0aGlzIHRvIG1lYW4sIENQIGRyYWZ0IGFscmVhZHkgYWxsb3dzIGFueSBTSSB2YWx1ZSB0byBi ZSBwcm9ncmFtbWVkLiBQbGVhc2UgbGV0IG1lIG5vdyBpZiB0aGlzIGlzIGluY29ycmVjdCBpbnRl cnByZXRhdGlvbi4NCiAgICANCiAgICANCg0K From nobody Thu Nov 10 17:41:21 2016 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 9D0CA129401 for ; Thu, 10 Nov 2016 17:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 6IxzEFyscLnL for ; Thu, 10 Nov 2016 17:41:19 -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 982051294BB for ; Thu, 10 Nov 2016 17:41:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAD36537; Fri, 11 Nov 2016 01:41:14 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Nov 2016 01:41:13 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 17:41:10 -0800 From: Lucy yong To: Eric C Rosen , Loa Andersson , "adrian@olddog.co.uk" , "'Dave Dolson'" , "sfc@ietf.org" Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AQHSO4FaY8YV84spjUiOGZ9XHFZjy6DS+GVA Date: Fri, 11 Nov 2016 01:41:09 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572EC726@dfweml501-mbb> References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <71fee848-be00-9137-286f-4908125e62a5@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.18] Content-Type: text/plain; charset="us-ascii" 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.582521BA.0108, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 83e882b722359074257fda14b7bd0c53 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 11 Nov 2016 01:41:20 -0000 Hi Eric, "You want to be able to add/remove SFIs from an SPI without changing the ad= dresses of all the SFIs." Long time ago, we argued that using SPI/SI to indicate SI's location on a S= FC path has the nature where adding/removing a SI to an SFC results the cha= nge of some SIs locations (those after the SI), thus SFFs have to be update= d accordingly. We thought that is bad design. The counter argument then was= that, adding/removing a SI to an existing SFC is considered as a new SFC t= hat will be given a new SPI, configuring SFFs for a new SPC is a normal ope= ration. Not sure what convergence concern you have. Do you want that, if an SFF can= 't reach an SF temporarily due to a failure, allow the SFF to resets SI and= forward to next SI? =20 Regards, Lucy=20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Thursday, November 10, 2016 12:36 PM To: Loa Andersson; adrian@olddog.co.uk; 'Dave Dolson'; sfc@ietf.org Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrem= enting service function path index] On 11/6/2016 5:56 AM, Loa Andersson wrote: > I can't think of a case where it is harmful to decrement by another=20 > value than 1. > > OTOH hand have shown that it is useful?=20 I think there is a real issue here, but I don't think it has been captured = well in this discussion. IMHO the real issue is whether the successive elements (SFIs) in a service = path (as identified by a specific SPI) are required to have successive inte= gers as their SIs. I don't think this has much to do with the behavior of the SF. I=20 understand that the SF needs a way to mark the NSH to indicate "I'm done=20 with this packet". Apparently the only way for the SF to do this is to=20 decrement the SI by something. And we'd like the SF to be able to indicate= "I'm done" without knowing anything about the SPI. This implies that the = decrement needs to be a fixed value. And if it's going to be a fixed value,= it might as well be 1. It wouldn't make sense to have an option to configure an SF to "decrement b= y 5", say, because if we don't want to require the successive elements of t= he SPI to have successive integers as their respective SIs, we also don't w= ant to require that they have successive multiples of 5 as their SIs. If w= e wanted the SF to do anything other than decrement by 1, we'd really need = to pass it enough information about the SPI to enable it to identify the ne= xt hop. That seems undesirable. So suppose the SPI has two elements, one with SI=3D3 and one with SI=3D5. = =20 If an SF gets a packet with SI=3D5 in the NSH, it processes the packet, set= s the SI to 4, and sends the packet to the SFF. Initially I thought that the SFF could interpret "SI=3D4" as meaning "the n= ext hop after SI=3D5". The SFF knows the SPI, can see that the next hop af= ter 5 is 3, and thus could change the SI in the NSH to 3, and then=20 forward the packet. However, I've been told that the SFF isn't=20 supposed to do stuff like this, because only a classifier can modify the SP= I/SI at this point. So instead we'd have to say that the SFF has a=20 co-resident classifier that modifies the SI as described. Of course,=20 if you deploy SFFs that don't have the co-resident classifier then you woul= dn't be able to deploy SPIs with non-successive integers as the SIs. Well,= if you want to deploy an optional feature, you need to deploy software tha= t supports that feature. I've only seen one really interesting argument against creating SPIs with n= on-successive SIs, the argument that says that that would make it more diff= icult to figure out the "reverse" of an SPI. This will require some furthe= r thought. Now to Loa's question (or my reinterpretation of it) of whether there is an= advantage to having non-successive SIs in an SPI, I'd say yes. If you thi= nk that SPIs may get modified (by insertion or deletion of elements) dynamically, and that such modifications need to be distributed d= ynamically, it seems like a good idea to be able to make these modification= s without changing the SIs of the elements that were=20 present before the modification. After all, one can think of an SPI/SI=20 as an address of an SFI. You want to be able to add/remove SFIs from an SP= I without changing the addresses of all the SFIs. This will get you much m= ore consistent/predictable behavior during the convergence period where not= everyone knows about the change yet. (Imagine if you couldn't add or remo= ve a system from the network without changing the addresses of all the othe= r systems.) Of course, someone will say that the WG has already determined that the SPI= s never need to be modified dynamically. But that's really a deployment de= cision, not a decision that should be forced by the architecture or the pro= tocol design. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Nov 11 08:58:35 2016 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 197D11294BD for ; Fri, 11 Nov 2016 08:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=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 orinPI51-tlw for ; Fri, 11 Nov 2016 08:58:31 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0096.outbound.protection.outlook.com [104.47.40.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6375A1297C3 for ; Fri, 11 Nov 2016 08:58:29 -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=3st8XKblm/ucWqvJSZRQ+sTlyEG2AINBY2nx12Z65og=; b=OAQf26dQ0jmmzFSstly4M+U1gnJXm9NlNu6S2MDb4FaovASJWuCIbiWvNuQrAPvwC278/0QbYD4JD29yAXw7BIkJxVZyNoa+W49Loo4HptNhlJ/RLAzcilqQM3JVLpyhcr1YZZEHmOPq5fb3RX8d8Br4w1Z0aprUspuZ10eDJ5Y= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.92] (66.129.241.13) by BY2PR05MB2182.namprd05.prod.outlook.com (10.166.112.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Fri, 11 Nov 2016 16:58:27 +0000 To: Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> From: Eric C Rosen Message-ID: <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> Date: Fri, 11 Nov 2016 11:58:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY1PR19CA0020.namprd19.prod.outlook.com (10.162.139.158) To BY2PR05MB2182.namprd05.prod.outlook.com (10.166.112.10) X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 2:HOg1v2WdNygFpyttBhXhykI0I9iGNM++3h9zFgeWVfX1Da9Kg7pWFVBIKF8Ly9UwpaNJG/lBxd1Oky8lDb+yhynwOY7hgypby3hrMAEPlTaJz/ZuhcsZQtOyD+mHErLQuE+bwcqOw4LRjoIO9dx2C6RS6ZPNCV7KXDcEpzI1aNk=; 3:n3QgDrPu+998gUBpUEIBI7A1V9LXi/gJ7RvCXCr+cax8oLz63kWMdBPUhrpyPlktscsMNstVmK8MSzhHYf6vnPuuyyyilrd3pPINSUOKM5bgx4unlwnDRMYHdLhl0a3SqsqEW11ERssUoUTLt+35y/M8DLuHOPkvt83XL2E1KVU=; 25:W9Ba8WyYpUnXKs763ozN4FiugqYi+JQxiVz2N7Z/u2Sv44wx6p20rLmOaTsHUZkxI7m2G4MAP0CkhmBEfq7bAv6AfRNZ/BQaSyegWtqYnvWM93FfaL8VsqO2a0w3lBHcGF3/UFPBZrL/mtOvHrO5CM37H1bIdtLiMRtE/+yoGrQ7szWe4JyQrjPciu6dE5yLsTqXbCVgulfl4MI+eiWzzR+Dq9MLlxjK39EP8bk4+ouDoEVW9/Lczzw8zxJSIwr2EawiVQ23IgdeoJ2RzCjBAwnK2YqfOYoWqTjUWzKonOTzbp+45fdIT6ihDxAoq4J2Vym4nQSTy9PjTDNEgNBdKfLNQk8uxhBrKwP9KKAXOJ4qG5fXbGx2lKJjT9QdZGnkRsi2fZV1ws0BZArS0Fr7SBZckio31TZHjZWz90qxMKcXouVv1YBbEUyphi+lkTys X-MS-Office365-Filtering-Correlation-Id: 9ca4e53b-2eb1-4e91-50f6-08d40a53f52b X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR05MB2182; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 31:pEPYGXZIouxRYelerqtKsxtzfHAZP5rqY9kcihjbmSrm/+V65jZe5WT2s0QwHiGmZVQPmfQX0yOzPfz54HbhpFdqKW5l5YJZc4tLTKpC8zZEibIPB/o/H3rYijiSt9bShzFnbUm1O8Jcw74AmenB+oFZXFERmMagmqIod7rDt0kaODHMgvEDccPBbZ/RST2Qlb55Zfi/I5aqSV83L3rmi6pp8UKhE+NGR1NL8dG90JKBLrJljbTdbm3V40z2sUrS; 20:0xR3+qKmr7tomoVR2t224ng9Bxua33wcr9JhGdeOLG9i3RP0PI6vtarK5mc+KMKP0SlfXDMVQMK1kZCcqeEHWfHZ4Ixq7UtN5gqNyKOwOh2vvrlvRWasFCjI9xqWl0gmJNhzmHV1F4i6x6bju0V2mdmcfLP0VDSVrSxi2fv9E42w3S2O9q1sOFkeD4owIb4bCODxarW11vwKtDWRdTIHrZpNmSw8bd0q/Ns8SxDYZdTy5u549vh7VauqLJKDNWNTTEq3m0Qh8bbyTSbrXWAqpLu1lRs8+5akh9dQfr4HuuttfgjBQ0/tOlV+fX957efxWQF6gT7v6OTm0MomkAZJU0iPg6akPZFGqubXoMfVvsr2ElPvSas51o2c6d4DGU9PNukUoR9rh4Rywkmv9989HKngSRsE/PHIXF/7J1V2/9MLqnjDghIDFTcdNBIcocvjxw6IgO/c5uojw1RSJzZklIVFrEj/FiccwCh7C4Q/asGiIx+azJLwHVx5eM/7KZkZKURpzPsJtg0oXH0v8G07svyAZJsz3Xrbf7125GlWRR7Qqu761zCHH2CbjmiJtp6FJszcCJJJMX2W4UHzedA1Av4PNi+z6ytzSPMNg1QPZpo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BY2PR05MB2182; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2182; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 4:F3nCQuyis3FXAOn3i8y6VN4Uw5TB794TkDZWLwREuCWM0sYz/9IByn/susAJiIsBHhTzooAptvoXD49/FBX6i68H0ywwUdm5lFKtNjPttBIe5ik+4GQAIMUQRamtBrFbYsAQ0ttbBMenZP+OwsGSfm5hPTNO5LLUtoudhi65vlKHEhHm6Z/KpWaqhtRPFRLKRvo1tqpdM8j0dsJzIUHch0JzjEJEwZPgQrr6Gc40Ghw3CO0NNNtbTjRh9UerNPW5sLF353eiN9/VC8ltAdQX9OBwBXjMfrJKQM+IY6ESpnW797hyaXtqog2yO+HP3L1o7V6Eu/AYjwJMJ5Wsc43dpQMiCucGSMk0oji0aL8FzAHn5CV0eBpex7Qcx7tIqi67TzUSk6CUfySpLiKkIlHXtiqzb9COqpV/JeWcFln86Mg= X-Forefront-PRVS: 012349AD1C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(377454003)(24454002)(199003)(64126003)(105586002)(106356001)(81166006)(6666003)(81156014)(31696002)(2906002)(92566002)(86362001)(8676002)(23746002)(107886002)(97736004)(229853002)(5890100001)(33646002)(2950100002)(93886004)(50466002)(77096005)(65826007)(189998001)(4001350100001)(2501003)(68736007)(7736002)(305945005)(7846002)(5001770100001)(36756003)(5660300001)(50986999)(47776003)(66066001)(65806001)(586003)(83506001)(3846002)(101416001)(76176999)(54356999)(65956001)(230700001)(31686004)(6116002)(42186005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2182; H:[172.29.35.92]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR05MB2182; 23:dKEXGxPqhaK3g/TCD59NCxgAgaxXzRbk97tpm?= =?Windows-1252?Q?0ejXA+7RTQmT5SyZ2N2TZsxAk9HnAW7qxkuoZ6RlXBYj97xbuApYSg4C?= =?Windows-1252?Q?O3xemhY35IplHvU8IDY03/pDUdXISi9cUGF1y9NjCipuqAavzSTjwstd?= =?Windows-1252?Q?sQ3cP+SeHIJnzTE3+rtFElpRtlvEquSTq1CenOAhep38ZFE4b5OxyGd3?= =?Windows-1252?Q?F9nKDoTE9M2MKu/zyZj3OPHMYwtoNZCHNO7jhmyE0MOqJ1y1dA50CSk2?= =?Windows-1252?Q?bgZLooRoHWP1byfR46KRaYCH+y441Bn4lCB6D+BfuGBsWsLvkutc1hqs?= =?Windows-1252?Q?TRGWTmH5mcyMJaCkTBtM3HIgteKozZCaGG5zHhkHB5vnnjZaf3m7/Kw/?= =?Windows-1252?Q?QtX8oivUSZpYuTPbdw7j+neQNIJU15UOETwUivplZFssgHu6E6CHySQT?= =?Windows-1252?Q?YvDs5wGVdTwqr52wcGZ2oBZl9PHw/rxFGD32mHiuhvmzxV2VilMWTU7E?= =?Windows-1252?Q?DAEv2QyDRnQAO7i5lJBQokTXU3WQrEChATa2EZQj9QltTuJ0DGKpyBsa?= =?Windows-1252?Q?v7bzS8V1nt/F79/bUiH26GIe1VHFcgm+JWqLHz/2UBZkbZ+OAAQhVLXU?= =?Windows-1252?Q?jPSHHQZb2bBF3msfZEFGhglE6eUXs/6yBsj18rfzMMgJrcskuj9Aqim4?= =?Windows-1252?Q?2hXkFRK2aos2cS+9Xukl4jjrYAiufsNKkvEm7Dxu9UObZQuubUeyK1VV?= =?Windows-1252?Q?YtqltxP76V4aiEL2EVy8qJpuKUM5fCMV8FvXT7orzNULRDpKEhMfkm8h?= =?Windows-1252?Q?gHBCEL5FZroBNk47SpMzJKPfiCDW5Z5QQSWbjA9LuAwNGdBAt5brqO83?= =?Windows-1252?Q?YEbgzSIX0HwMkEN9hZAd5yNa4SiM5QxMULQ0sz/Vjscukp816WXX2WCD?= =?Windows-1252?Q?y6Vh/onv6Kcma1uwq5uYzxmWbaDXXo3ShCwyTcGA5kD3rJ53ZikNK3uf?= =?Windows-1252?Q?x5b4IklA0b9xkzJ6xiHdadsPnzpWoXaxyJ2/tsR95OCJOc1iJZn4Dy7Q?= =?Windows-1252?Q?3KCeLhPlGVGE1Sxx6U7oEShxu7DDCtEKvz/fzhz/ztjShsRfqXWV6kmW?= =?Windows-1252?Q?tVO4smQEncc8tBbbeoz5dWnkRb8wJ7SZKPt4hJPRiZIqY+Ah0vz2P3Np?= =?Windows-1252?Q?dNUqT2SX5uufAokf8hSTex30Px5i7IieO6nmMm+je6iY6Zz75G0Ibmpi?= =?Windows-1252?Q?HGCup4BkQ4ZkmCKdNWJvcXGe2h6WLz3k7C+hO93QKW+a98lrzHiTYboI?= =?Windows-1252?Q?oaml8zOf7v6YLHPim1gm8s4ZCigQZAZVAocddAFYmqIw/0wbLqrAG3Sc?= =?Windows-1252?Q?cyxvmPptHyInL1VCU2X7i+mKp3J/NL6Xp8tkzllBR9sL9my7KG5xpE?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 6:Sy5okiXkT4WSxtsZKBv0aHEcs+zaoRlaxyhccMm2t5JosncoxBRD7hehgmBqkB2onE1Wp0Vvom9TIbUx1r8Tsd3paRwZ/rkQ9e1ysR/9LyVJ6u6TnhDRz/RJ8sAqgrPJzKzyur/8U0dm2dpFs2VzirMlDGZF5EaACXiNByFvuYyvwN4nlrEkbaqpwznJKqYRg7EhTOKO774AXdlxM3C3y79rH+HOxPXMGtZwNUwAX1sZJYUkAcfmWzC6bqlkX/BwlFeCYaWM8BtZO5I3B4+FLQn+E5pCum+qpEcaip3Xf0aT7Wb5pcYFJe76AVrijzSun3Bd+fhHXEKg4Gm+eu8ivwxpZfiN83xXkVy6xfHEfB4=; 5:XDbsO1zH18QaoEpdDUcydQjdd5sF43alIFD2cy5/g1e/By/q2gxJDUUirBjV92AnzrLgWdk1h2eYQb58l4ymQXB9Gi82m7pJ1qL7GTk5kgiBspgCzUoaDl2bLIVEdb1eih4+cZaabUVVShNSur6ARw==; 24:5qS1z/m1f9VZy3HVuFWo57HCti8N3OvtrukZQPgyqr+sULs71JtgiqyUFnhX5lWRehv4NXXDJj05zXvQUFoQ9NOsN60Fa+EBwCWFqlDVrTc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 7:DUTAnsrrU4jme6BrZfrPZGYicWb/UB9o2WMQdfzYWiYCUnlrnKefCpUOW1d6K+wFeoA24Yrgi52MLJyPMs/tb7mX7E/ZBP7k7R7CK9i9xR5jUtafDmGT1fTpokzsArYr4bb2j87wlK+ntVJkRYC+by9TSilI8Xeuj2ivcydYO+A+X0FvemY0cNCdsv3R714o/rX10CopwCjMGf5STDhi/OzEstoNxCV5MAE9VPM33GQMiahMEKmD81vmn0CYQMBtlKZzviXgIgug5lHAmCtA3P6zRjXxM5ihXHYQpbRGs4gMa6SBidjtMD0p4KXXf3mkC7pZ3EJO9yfTSn8qz0Kv7sMIWJORVfF3GEF3jJ0fKss= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2016 16:58:27.0096 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2182 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 11 Nov 2016 16:58:33 -0000 On 11/1/2016 4:26 PM, Dave Dolson wrote: > Yes, I'm saying that the current (as I understand it) design permits the SFF to be a simple forwarder, > not needing to discriminate between packets from another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=x, send to SF1; when SI=x+1, send to SFF2 I wonder what the WG has decided about the following case. Suppose Node 1 contains SFF1 and SF1-1, while Node 2 contains SFF2 and SF1-2, where SF1-1 and SF1-2 are two instances of of the same service function (SF1). So SFF1 is attached locally to SF1-1, and SFF2 is attached locally to SF1-2, Now suppose that the SPI/SI value "x/y" means "SF1". When SFF1 sees "x/y" in the NSH, it may choose to load balance between SF1-1 and SF1-2. This means it may forward either locally to SF1-1 or over the network to SF1-2. Suppose SFF1 chooses SF1-2. It then needs to tunnel the packet through the underlay to Node 2. What happens when the packet arrives at Node 2? If the packet is seen by SFF2, SFF2 will see "x/y" in the NSH, and may choose to forward either locally to SF1-2 or over the network to SF1-1. Since SFF2 doesn't know that the packet came from another SFF, nothing stops it from choosing SF1-1. That is, SFF1 chooses to use SF1-2, and SFF2 chooses to use SF1-1, thus forming a loop. Since this loop is between the two SFFs, the SI never gets decremented. Presumably this type of load-balancing is allowed, but the loop must be prevented. One way to prevent the loop is for SFF2 to know whether a packet with "x/y" in the NSH has already been seen by another forwarder or not. > In some cases, an SFF can be a single-interface device, so "from SFF" or "from SF" is not as simple > as checking ingress interface, for example. Presumably there's a tunnel of some sort, through the underlay, that leads from SFF1 to SFF2. This tunnel could be regarded as a virtula ingress interface. Alternatively, SFF1 could tunnel a packet directly to SF1-2, bypassing SFF2 entirely. SFF2 then wouldn't actually process the packet until SF1-2 has finished with it. The load balancing decision would be made only once (by SFF1). in this case, the SFFs don't need to know about a packet's ingress "interface" because SFFs don't get packets from each other directly. This requires only that the tunnel through the underlay contain demultiplexing information that will cause the packet, once it arrives at Node 2, to be delivered directly to SF1-2, bypassing SFF2. This latter model seems to be what is required by section 5.5 of RFC7665, but the RFC is not very explicit about it. From nobody Fri Nov 11 09:04:12 2016 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 282B5129452 for ; Fri, 11 Nov 2016 09:04:10 -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, HTML_MESSAGE=0.001, 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 bJMxNu0BJYDJ for ; Fri, 11 Nov 2016 09:04:08 -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 E7C07129630 for ; Fri, 11 Nov 2016 09:04:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D8E056218B5; Fri, 11 Nov 2016 09:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478883848; bh=Be/EXf//3yadCbTka9sKhYaFKX3doA7SIxtz900ClY4=; h=Date:Subject:From:To:From; b=Ppr6lLwdXTY5dB+i8GcSKR4IkNV3qcdoZ5xEyBqXPHdRMKiFvEoaf1nub13qa5hRK H9FuyjI4MNnXJcK/0CLrZipN/qEuxFNH8+g3o45hWagiOk5qkKSt1t5j7XtyRDr4CG IOm/nKmq/v05k9NW0BGwt8x4px4tVKrD+92bmLek= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.169.196.122] (mobile-166-137-178-216.mycingular.net [166.137.178.216]) (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 C8F626218A6; Fri, 11 Nov 2016 09:04:06 -0800 (PST) Date: Fri, 11 Nov 2016 09:04:02 -0800 Message-ID: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> Importance: normal From: "jmh.direct" To: Eric C Rosen , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1587267911628420" Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 11 Nov 2016 17:04:10 -0000 ----_com.samsung.android.email_1587267911628420 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWN0dWFsbHksIEkgaGFkIHByZXN1bWVkIHRoYXQgdGhlIHBhcnRpY3VsYXIgbGlhZGVuIGJhbGFu Y2luZyB5b3UgZGVzY3JpYmUgd2FzIG5vdCBleHBlY3RlZCB0byB3b3JrLgpPbmUgb2YgbXkgY29u Y2VybnMgd2l0aCB0aGUgcHJvcG9zZWQgQkdQIGVuY29kaW5nIGlzIHRoYXQgaXQgY2FuIHJlcHJl c2VudCBtYW55IHRoaW5ncyB0aGF0IHdpbGwgbm90IHdvcmsuIMKgVGhpcyBzZWVtcyB0byBtYWtl IGl0IGZyYWdpbGUuCllvdXJzLEpvZWwKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgU8Ku IDYsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAt LS0tLS0tLUZyb206IEVyaWMgQyBSb3NlbiA8ZXJvc2VuQGp1bmlwZXIubmV0PiBEYXRlOiAxMS8x MS8xNiAgMDg6NTggIChHTVQtMDg6MDApIFRvOiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmlu ZS5jb20+LCBhZHJpYW5Ab2xkZG9nLmNvLnVrLCAiJ0pvZWwgTS4gSGFscGVybiciIDxqbWhAam9l bGhhbHBlcm4uY29tPiwgc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbc2ZjXSBkZWNyZW1lbnRp bmcgc2VydmljZSBmdW5jdGlvbiBwYXRoIGluZGV4IApPbiAxMS8xLzIwMTYgNDoyNiBQTSwgRGF2 ZSBEb2xzb24gd3JvdGU6Cj4gWWVzLCBJJ20gc2F5aW5nIHRoYXQgdGhlIGN1cnJlbnQgKGFzIEkg dW5kZXJzdGFuZCBpdCkgZGVzaWduIHBlcm1pdHMgdGhlIFNGRiB0byBiZSBhIHNpbXBsZSBmb3J3 YXJkZXIsCj4gbm90IG5lZWRpbmcgdG8gZGlzY3JpbWluYXRlIGJldHdlZW4gcGFja2V0cyBmcm9t IGFub3RoZXIgU0ZGIG9yIHJldHVybmluZyBmcm9tIGFuIFNGLgo+IEEgc2luZ2xlIGZvcndhcmRp bmcgdGFibGUgaGFuZGxlcyBib3RoIGNhc2VzLgo+IEUuZy4sIGF0IFNGRjEsIHdoZW4gU0k9eCwg c2VuZCB0byBTRjE7IHdoZW4gU0k9eCsxLCBzZW5kIHRvIFNGRjIKSSB3b25kZXIgd2hhdCB0aGUg V0cgaGFzIGRlY2lkZWQgYWJvdXQgdGhlIGZvbGxvd2luZyBjYXNlLgoKU3VwcG9zZSBOb2RlIDEg Y29udGFpbnMgU0ZGMSBhbmQgU0YxLTEsIHdoaWxlIE5vZGUgMiBjb250YWlucyBTRkYyIGFuZCAK U0YxLTIsIHdoZXJlIFNGMS0xIGFuZCBTRjEtMiBhcmUgdHdvIGluc3RhbmNlcyBvZiBvZiB0aGUg c2FtZSBzZXJ2aWNlIApmdW5jdGlvbiAoU0YxKS4KClNvIFNGRjEgaXMgYXR0YWNoZWQgbG9jYWxs eSB0byBTRjEtMSwgYW5kIFNGRjIgaXMgYXR0YWNoZWQgbG9jYWxseSB0byBTRjEtMiwKCk5vdyBz dXBwb3NlIHRoYXQgdGhlIFNQSS9TSSB2YWx1ZSAieC95IiBtZWFucyAiU0YxIi4KCldoZW4gU0ZG MSBzZWVzICJ4L3kiIGluIHRoZSBOU0gsIGl0IG1heSBjaG9vc2UgdG8gbG9hZCBiYWxhbmNlIGJl dHdlZW4gClNGMS0xIGFuZCBTRjEtMi7CoCBUaGlzIG1lYW5zIGl0IG1heSBmb3J3YXJkIGVpdGhl ciBsb2NhbGx5IHRvIFNGMS0xIG9yIApvdmVyIHRoZSBuZXR3b3JrIHRvIFNGMS0yLgoKU3VwcG9z ZSBTRkYxIGNob29zZXMgU0YxLTIuwqAgSXQgdGhlbiBuZWVkcyB0byB0dW5uZWwgdGhlIHBhY2tl dCB0aHJvdWdoIAp0aGUgdW5kZXJsYXkgdG8gTm9kZSAyLgoKV2hhdCBoYXBwZW5zIHdoZW4gdGhl IHBhY2tldCBhcnJpdmVzIGF0IE5vZGUgMj/CoCBJZiB0aGUgcGFja2V0IGlzIHNlZW4gCmJ5IFNG RjIsIFNGRjIgd2lsbCBzZWUgIngveSIgaW4gdGhlIE5TSCwgYW5kIG1heSBjaG9vc2UgdG8gZm9y d2FyZCAKZWl0aGVyIGxvY2FsbHkgdG8gU0YxLTIgb3Igb3ZlciB0aGUgbmV0d29yayB0byBTRjEt MS4gU2luY2UgU0ZGMiBkb2Vzbid0IAprbm93IHRoYXQgdGhlIHBhY2tldCBjYW1lIGZyb20gYW5v dGhlciBTRkYsIG5vdGhpbmcgc3RvcHMgaXQgZnJvbSAKY2hvb3NpbmcgU0YxLTEuCgpUaGF0IGlz LMKgIFNGRjEgY2hvb3NlcyB0byB1c2UgU0YxLTIsIGFuZCBTRkYyIGNob29zZXMgdG8gdXNlIFNG MS0xLCB0aHVzIApmb3JtaW5nIGEgbG9vcC7CoCBTaW5jZSB0aGlzIGxvb3AgaXMgYmV0d2VlbiB0 aGUgdHdvIFNGRnMsIHRoZSBTSSBuZXZlciAKZ2V0cyBkZWNyZW1lbnRlZC4KClByZXN1bWFibHkg dGhpcyB0eXBlIG9mIGxvYWQtYmFsYW5jaW5nIGlzIGFsbG93ZWQsIGJ1dCB0aGUgbG9vcCBtdXN0 IGJlIApwcmV2ZW50ZWQuCgpPbmUgd2F5IHRvIHByZXZlbnQgdGhlIGxvb3AgaXMgZm9yIFNGRjIg dG8ga25vdyB3aGV0aGVyIGEgcGFja2V0IHdpdGggCiJ4L3kiIGluIHRoZSBOU0ggaGFzIGFscmVh ZHkgYmVlbiBzZWVuIGJ5IGFub3RoZXIgZm9yd2FyZGVyIG9yIG5vdC4KCj4gSW4gc29tZSBjYXNl cywgYW4gU0ZGIGNhbiBiZSBhIHNpbmdsZS1pbnRlcmZhY2UgZGV2aWNlLCBzbyAiZnJvbSBTRkYi IG9yICJmcm9tIFNGIiBpcyBub3QgYXMgc2ltcGxlCj4gYXMgY2hlY2tpbmcgaW5ncmVzcyBpbnRl cmZhY2UsIGZvciBleGFtcGxlLgoKUHJlc3VtYWJseSB0aGVyZSdzIGEgdHVubmVsIG9mIHNvbWUg c29ydCwgdGhyb3VnaCB0aGUgdW5kZXJsYXksIHRoYXQgCmxlYWRzIGZyb20gU0ZGMSB0byBTRkYy LsKgwqAgVGhpcyB0dW5uZWwgY291bGQgYmUgcmVnYXJkZWQgYXMgYSB2aXJ0dWxhIAppbmdyZXNz IGludGVyZmFjZS4KCkFsdGVybmF0aXZlbHksIFNGRjEgY291bGQgdHVubmVsIGEgcGFja2V0IGRp cmVjdGx5IHRvIFNGMS0yLCBieXBhc3NpbmcgClNGRjIgZW50aXJlbHkuwqAgU0ZGMiB0aGVuIHdv dWxkbid0IGFjdHVhbGx5IHByb2Nlc3MgdGhlIHBhY2tldCB1bnRpbCAKU0YxLTIgaGFzIGZpbmlz aGVkIHdpdGggaXQuwqAgVGhlIGxvYWQgYmFsYW5jaW5nIGRlY2lzaW9uIHdvdWxkIGJlIG1hZGUg Cm9ubHkgb25jZSAoYnkgU0ZGMSkuwqAgaW4gdGhpcyBjYXNlLCB0aGUgU0ZGcyBkb24ndCBuZWVk IHRvIGtub3cgYWJvdXQgYSAKcGFja2V0J3MgaW5ncmVzcyAiaW50ZXJmYWNlIiBiZWNhdXNlIFNG RnMgZG9uJ3QgZ2V0IHBhY2tldHMgZnJvbSBlYWNoIApvdGhlciBkaXJlY3RseS4KClRoaXMgcmVx dWlyZXMgb25seSB0aGF0IHRoZSB0dW5uZWwgdGhyb3VnaCB0aGUgdW5kZXJsYXkgY29udGFpbiAK ZGVtdWx0aXBsZXhpbmcgaW5mb3JtYXRpb24gdGhhdCB3aWxsIGNhdXNlIHRoZSBwYWNrZXQsIG9u Y2UgaXQgYXJyaXZlcyAKYXQgTm9kZSAyLCB0byBiZSBkZWxpdmVyZWQgZGlyZWN0bHkgdG8gU0Yx LTIsIGJ5cGFzc2luZyBTRkYyLgoKVGhpcyBsYXR0ZXIgbW9kZWwgc2VlbXMgdG8gYmUgd2hhdCBp cyByZXF1aXJlZCBieSBzZWN0aW9uIDUuNSBvZiAKUkZDNzY2NSwgYnV0IHRoZSBSRkMgaXMgbm90 IHZlcnkgZXhwbGljaXQgYWJvdXQgaXQuCg== ----_com.samsung.android.email_1587267911628420 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkFjdHVhbGx5LCBJIGhhZCBw cmVzdW1lZCB0aGF0IHRoZSBwYXJ0aWN1bGFyIGxpYWRlbiBiYWxhbmNpbmcgeW91IGRlc2NyaWJl IHdhcyBub3QgZXhwZWN0ZWQgdG8gd29yay48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9uZSBv ZiBteSBjb25jZXJucyB3aXRoIHRoZSBwcm9wb3NlZCBCR1AgZW5jb2RpbmcgaXMgdGhhdCBpdCBj YW4gcmVwcmVzZW50IG1hbnkgdGhpbmdzIHRoYXQgd2lsbCBub3Qgd29yay4gJm5ic3A7VGhpcyBz ZWVtcyB0byBtYWtlIGl0IGZyYWdpbGUuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Zb3Vycyw8 L2Rpdj48ZGl2PkpvZWw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTo4NSU7Y29sb3I6IzU3NTc1NyIgZGlyPSJhdXRvIj5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxh eHkgU8KuIDYsIGFuIEFUJmFtcDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBv cmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0t PC9kaXY+PGRpdj5Gcm9tOiBFcmljIEMgUm9zZW4gJmx0O2Vyb3NlbkBqdW5pcGVyLm5ldCZndDsg PC9kaXY+PGRpdj5EYXRlOiAxMS8xMS8xNiAgMDg6NTggIChHTVQtMDg6MDApIDwvZGl2PjxkaXY+ VG86IERhdmUgRG9sc29uICZsdDtkZG9sc29uQHNhbmR2aW5lLmNvbSZndDssIGFkcmlhbkBvbGRk b2cuY28udWssICInSm9lbCBNLiBIYWxwZXJuJyIgJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7 LCBzZmNAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogW3NmY10gZGVjcmVtZW50aW5n IHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBpbmRleCA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5P biAxMS8xLzIwMTYgNDoyNiBQTSwgRGF2ZSBEb2xzb24gd3JvdGU6PGJyPiZndDsgWWVzLCBJJ20g c2F5aW5nIHRoYXQgdGhlIGN1cnJlbnQgKGFzIEkgdW5kZXJzdGFuZCBpdCkgZGVzaWduIHBlcm1p dHMgdGhlIFNGRiB0byBiZSBhIHNpbXBsZSBmb3J3YXJkZXIsPGJyPiZndDsgbm90IG5lZWRpbmcg dG8gZGlzY3JpbWluYXRlIGJldHdlZW4gcGFja2V0cyBmcm9tIGFub3RoZXIgU0ZGIG9yIHJldHVy bmluZyBmcm9tIGFuIFNGLjxicj4mZ3Q7IEEgc2luZ2xlIGZvcndhcmRpbmcgdGFibGUgaGFuZGxl cyBib3RoIGNhc2VzLjxicj4mZ3Q7IEUuZy4sIGF0IFNGRjEsIHdoZW4gU0k9eCwgc2VuZCB0byBT RjE7IHdoZW4gU0k9eCsxLCBzZW5kIHRvIFNGRjI8YnI+SSB3b25kZXIgd2hhdCB0aGUgV0cgaGFz IGRlY2lkZWQgYWJvdXQgdGhlIGZvbGxvd2luZyBjYXNlLjxicj48YnI+U3VwcG9zZSBOb2RlIDEg Y29udGFpbnMgU0ZGMSBhbmQgU0YxLTEsIHdoaWxlIE5vZGUgMiBjb250YWlucyBTRkYyIGFuZCA8 YnI+U0YxLTIsIHdoZXJlIFNGMS0xIGFuZCBTRjEtMiBhcmUgdHdvIGluc3RhbmNlcyBvZiBvZiB0 aGUgc2FtZSBzZXJ2aWNlIDxicj5mdW5jdGlvbiAoU0YxKS48YnI+PGJyPlNvIFNGRjEgaXMgYXR0 YWNoZWQgbG9jYWxseSB0byBTRjEtMSwgYW5kIFNGRjIgaXMgYXR0YWNoZWQgbG9jYWxseSB0byBT RjEtMiw8YnI+PGJyPk5vdyBzdXBwb3NlIHRoYXQgdGhlIFNQSS9TSSB2YWx1ZSAieC95IiBtZWFu cyAiU0YxIi48YnI+PGJyPldoZW4gU0ZGMSBzZWVzICJ4L3kiIGluIHRoZSBOU0gsIGl0IG1heSBj aG9vc2UgdG8gbG9hZCBiYWxhbmNlIGJldHdlZW4gPGJyPlNGMS0xIGFuZCBTRjEtMi4mbmJzcDsg VGhpcyBtZWFucyBpdCBtYXkgZm9yd2FyZCBlaXRoZXIgbG9jYWxseSB0byBTRjEtMSBvciA8YnI+ b3ZlciB0aGUgbmV0d29yayB0byBTRjEtMi48YnI+PGJyPlN1cHBvc2UgU0ZGMSBjaG9vc2VzIFNG MS0yLiZuYnNwOyBJdCB0aGVuIG5lZWRzIHRvIHR1bm5lbCB0aGUgcGFja2V0IHRocm91Z2ggPGJy PnRoZSB1bmRlcmxheSB0byBOb2RlIDIuPGJyPjxicj5XaGF0IGhhcHBlbnMgd2hlbiB0aGUgcGFj a2V0IGFycml2ZXMgYXQgTm9kZSAyPyZuYnNwOyBJZiB0aGUgcGFja2V0IGlzIHNlZW4gPGJyPmJ5 IFNGRjIsIFNGRjIgd2lsbCBzZWUgIngveSIgaW4gdGhlIE5TSCwgYW5kIG1heSBjaG9vc2UgdG8g Zm9yd2FyZCA8YnI+ZWl0aGVyIGxvY2FsbHkgdG8gU0YxLTIgb3Igb3ZlciB0aGUgbmV0d29yayB0 byBTRjEtMS4gU2luY2UgU0ZGMiBkb2Vzbid0IDxicj5rbm93IHRoYXQgdGhlIHBhY2tldCBjYW1l IGZyb20gYW5vdGhlciBTRkYsIG5vdGhpbmcgc3RvcHMgaXQgZnJvbSA8YnI+Y2hvb3NpbmcgU0Yx LTEuPGJyPjxicj5UaGF0IGlzLCZuYnNwOyBTRkYxIGNob29zZXMgdG8gdXNlIFNGMS0yLCBhbmQg U0ZGMiBjaG9vc2VzIHRvIHVzZSBTRjEtMSwgdGh1cyA8YnI+Zm9ybWluZyBhIGxvb3AuJm5ic3A7 IFNpbmNlIHRoaXMgbG9vcCBpcyBiZXR3ZWVuIHRoZSB0d28gU0ZGcywgdGhlIFNJIG5ldmVyIDxi cj5nZXRzIGRlY3JlbWVudGVkLjxicj48YnI+UHJlc3VtYWJseSB0aGlzIHR5cGUgb2YgbG9hZC1i YWxhbmNpbmcgaXMgYWxsb3dlZCwgYnV0IHRoZSBsb29wIG11c3QgYmUgPGJyPnByZXZlbnRlZC48 YnI+PGJyPk9uZSB3YXkgdG8gcHJldmVudCB0aGUgbG9vcCBpcyBmb3IgU0ZGMiB0byBrbm93IHdo ZXRoZXIgYSBwYWNrZXQgd2l0aCA8YnI+IngveSIgaW4gdGhlIE5TSCBoYXMgYWxyZWFkeSBiZWVu IHNlZW4gYnkgYW5vdGhlciBmb3J3YXJkZXIgb3Igbm90Ljxicj48YnI+Jmd0OyBJbiBzb21lIGNh c2VzLCBhbiBTRkYgY2FuIGJlIGEgc2luZ2xlLWludGVyZmFjZSBkZXZpY2UsIHNvICJmcm9tIFNG RiIgb3IgImZyb20gU0YiIGlzIG5vdCBhcyBzaW1wbGU8YnI+Jmd0OyBhcyBjaGVja2luZyBpbmdy ZXNzIGludGVyZmFjZSwgZm9yIGV4YW1wbGUuPGJyPjxicj5QcmVzdW1hYmx5IHRoZXJlJ3MgYSB0 dW5uZWwgb2Ygc29tZSBzb3J0LCB0aHJvdWdoIHRoZSB1bmRlcmxheSwgdGhhdCA8YnI+bGVhZHMg ZnJvbSBTRkYxIHRvIFNGRjIuJm5ic3A7Jm5ic3A7IFRoaXMgdHVubmVsIGNvdWxkIGJlIHJlZ2Fy ZGVkIGFzIGEgdmlydHVsYSA8YnI+aW5ncmVzcyBpbnRlcmZhY2UuPGJyPjxicj5BbHRlcm5hdGl2 ZWx5LCBTRkYxIGNvdWxkIHR1bm5lbCBhIHBhY2tldCBkaXJlY3RseSB0byBTRjEtMiwgYnlwYXNz aW5nIDxicj5TRkYyIGVudGlyZWx5LiZuYnNwOyBTRkYyIHRoZW4gd291bGRuJ3QgYWN0dWFsbHkg cHJvY2VzcyB0aGUgcGFja2V0IHVudGlsIDxicj5TRjEtMiBoYXMgZmluaXNoZWQgd2l0aCBpdC4m bmJzcDsgVGhlIGxvYWQgYmFsYW5jaW5nIGRlY2lzaW9uIHdvdWxkIGJlIG1hZGUgPGJyPm9ubHkg b25jZSAoYnkgU0ZGMSkuJm5ic3A7IGluIHRoaXMgY2FzZSwgdGhlIFNGRnMgZG9uJ3QgbmVlZCB0 byBrbm93IGFib3V0IGEgPGJyPnBhY2tldCdzIGluZ3Jlc3MgImludGVyZmFjZSIgYmVjYXVzZSBT RkZzIGRvbid0IGdldCBwYWNrZXRzIGZyb20gZWFjaCA8YnI+b3RoZXIgZGlyZWN0bHkuPGJyPjxi cj5UaGlzIHJlcXVpcmVzIG9ubHkgdGhhdCB0aGUgdHVubmVsIHRocm91Z2ggdGhlIHVuZGVybGF5 IGNvbnRhaW4gPGJyPmRlbXVsdGlwbGV4aW5nIGluZm9ybWF0aW9uIHRoYXQgd2lsbCBjYXVzZSB0 aGUgcGFja2V0LCBvbmNlIGl0IGFycml2ZXMgPGJyPmF0IE5vZGUgMiwgdG8gYmUgZGVsaXZlcmVk IGRpcmVjdGx5IHRvIFNGMS0yLCBieXBhc3NpbmcgU0ZGMi48YnI+PGJyPlRoaXMgbGF0dGVyIG1v ZGVsIHNlZW1zIHRvIGJlIHdoYXQgaXMgcmVxdWlyZWQgYnkgc2VjdGlvbiA1LjUgb2YgPGJyPlJG Qzc2NjUsIGJ1dCB0aGUgUkZDIGlzIG5vdCB2ZXJ5IGV4cGxpY2l0IGFib3V0IGl0Ljxicj48L2Jv ZHk+PC9odG1sPg== ----_com.samsung.android.email_1587267911628420-- From nobody Fri Nov 11 09:33:30 2016 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 1B83612995E for ; Fri, 11 Nov 2016 09:33:23 -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 FZrEC3mdtnt7 for ; Fri, 11 Nov 2016 09:33:19 -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 36294129BA3 for ; Fri, 11 Nov 2016 09:33:19 -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, 11 Nov 2016 09:33:18 -0800 From: Ron Parker To: Eric C Rosen , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [GRAYMAIL] Re: [sfc] decrementing service function path index Thread-Index: AQHSNGTbvy1CrU96Tkag20viKWCKTqDE4NYAgAABlICAAAr9AIAADSKAgAAHDYCAAAd2gIAPjeOA//9+zXA= Date: Fri, 11 Nov 2016 17:33:17 +0000 Message-ID: References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> In-Reply-To: <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> 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: Subject: Re: [sfc] [GRAYMAIL] Re: decrementing service function path index 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, 11 Nov 2016 17:33:23 -0000 Eric, I agree with your analysis. Especially around: Presumably this type of load-balancing is allowed, but the loop must be = prevented. One way to prevent the loop is for SFF2 to know whether a packet with "x= /y" in the NSH has already been seen by another forwarder or not. Do you think that an SFF could/should discern this by examining the source = IP of the packet it receives, or do you think we need some sort of "source = id" in the NSH base header, itself? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Friday, November 11, 2016 11:58 AM To: Dave Dolson ; adrian@olddog.co.uk; 'Joel M. Halpe= rn' ; sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] decrementing service function path index On 11/1/2016 4:26 PM, Dave Dolson wrote: > Yes, I'm saying that the current (as I understand it) design permits=20 > the SFF to be a simple forwarder, not needing to discriminate between pac= kets from another SFF or returning from an SF. > A single forwarding table handles both cases. > E.g., at SFF1, when SI=3Dx, send to SF1; when SI=3Dx+1, send to SFF2 I wonder what the WG has decided about the following case. Suppose Node 1 contains SFF1 and SF1-1, while Node 2 contains SFF2 and SF1-= 2, where SF1-1 and SF1-2 are two instances of of the same service function = (SF1). So SFF1 is attached locally to SF1-1, and SFF2 is attached locally to SF1-2= , Now suppose that the SPI/SI value "x/y" means "SF1". When SFF1 sees "x/y" in the NSH, it may choose to load balance between SF1-1 and SF1-2. This means it may forward either locally to SF1-1 or over= the network to SF1-2. Suppose SFF1 chooses SF1-2. It then needs to tunnel the packet through the= underlay to Node 2. What happens when the packet arrives at Node 2? If the packet is seen by S= FF2, SFF2 will see "x/y" in the NSH, and may choose to forward either local= ly to SF1-2 or over the network to SF1-1. Since SFF2 doesn't know that the = packet came from another SFF, nothing stops it from choosing SF1-1. That is, SFF1 chooses to use SF1-2, and SFF2 chooses to use SF1-1, thus fo= rming a loop. Since this loop is between the two SFFs, the SI never gets d= ecremented. Presumably this type of load-balancing is allowed, but the loop must be pre= vented. One way to prevent the loop is for SFF2 to know whether a packet with "x/y"= in the NSH has already been seen by another forwarder or not. > In some cases, an SFF can be a single-interface device, so "from SFF"=20 > or "from SF" is not as simple as checking ingress interface, for example. Presumably there's a tunnel of some sort, through the underlay, that=20 leads from SFF1 to SFF2. This tunnel could be regarded as a virtula=20 ingress interface. Alternatively, SFF1 could tunnel a packet directly to SF1-2, bypassing SFF2 entirely. SFF2 then wouldn't actually process the packet until SF1-2 has finished with it. The load balancing decision would be made only= once (by SFF1). in this case, the SFFs don't need to know about a packet'= s ingress "interface" because SFFs don't get packets from each other direct= ly. This requires only that the tunnel through the underlay contain demultiplex= ing information that will cause the packet, once it arrives at Node 2, to b= e delivered directly to SF1-2, bypassing SFF2. This latter model seems to be what is required by section 5.5 of RFC7665, b= ut the RFC is not very explicit about it. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Nov 11 09:35:58 2016 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 153F1129BA5 for ; Fri, 11 Nov 2016 09:35:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RdGVRfjq9RYC for ; Fri, 11 Nov 2016 09:35:52 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D43129BB6 for ; Fri, 11 Nov 2016 09:35:48 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0319.002; Fri, 11 Nov 2016 09:35:47 -0800 From: Ron Parker To: jmh.direct , Eric C Rosen , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSPD2hh5D2p41OyUSZLF3yD9bwDKDUCvlg Date: Fri, 11 Nov 2016 17:35:45 +0000 Message-ID: References: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> In-Reply-To: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> 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: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B83907AB8MBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 11 Nov 2016 17:35:56 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B83907AB8MBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9lbCwNCg0KSWYgeW91IHJlY2FsbCBvdXIgZGlzY3Vzc2lvbnMgYXJvdW5kIFJlbmRlcmVkIFNl cnZpY2UgUGF0aHMgKFJTUHMpLCBJIGhhZCBhIGZ1bGwgZXhwZWN0YXRpb24gdGhhdCB0aGlzIHR5 cGUgb2YgbG9hZCBiYWxhbmNpbmcgd291bGQgd29yay4gICBGdXJ0aGVyLCB3ZSBoYWQgc29tZSBk aXNjdXNzaW9uIG9mIHdoZXRoZXIgdGhlIE5TSCBoZWFkZXIgc2hvdWxkIGNvbW11bmljYXRlZCBT RlAgSUQgb3IgUlNQIElEIHdoZXJlIHRoZSBmb3JtZXIgaXMgbm9uLXNwZWNpZmljIGFyb3VuZCB0 aGUgYWN0dWFsIGxvYWQgYmFsYW5jZWQgc2VsZWN0aW9uIG9mIFNGSXMgYW5kIHRoZSBsYXR0ZXIg aXMgY29tcGxldGVseSBjb25jcmV0ZSBpbiB0ZXJtcyBvZiB0aGUgYWN0dWFsIHNlbGVjdGVkIFNG SXMuDQoNCiAgIFJvbg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2Ygam1oLmRpcmVjdA0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxMSwgMjAx NiAxMjowNCBQTQ0KVG86IEVyaWMgQyBSb3NlbiA8ZXJvc2VuQGp1bmlwZXIubmV0PjsgRGF2ZSBE b2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPjsgYWRyaWFuQG9sZGRvZy5jby51azsgJ0pvZWwg TS4gSGFscGVybicgPGptaEBqb2VsaGFscGVybi5jb20+OyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbc2ZjXSBkZWNyZW1lbnRpbmcgc2VydmljZSBmdW5jdGlvbiBwYXRoIGluZGV4DQoNCkFj dHVhbGx5LCBJIGhhZCBwcmVzdW1lZCB0aGF0IHRoZSBwYXJ0aWN1bGFyIGxpYWRlbiBiYWxhbmNp bmcgeW91IGRlc2NyaWJlIHdhcyBub3QgZXhwZWN0ZWQgdG8gd29yay4NCg0KT25lIG9mIG15IGNv bmNlcm5zIHdpdGggdGhlIHByb3Bvc2VkIEJHUCBlbmNvZGluZyBpcyB0aGF0IGl0IGNhbiByZXBy ZXNlbnQgbWFueSB0aGluZ3MgdGhhdCB3aWxsIG5vdCB3b3JrLiAgVGhpcyBzZWVtcyB0byBtYWtl IGl0IGZyYWdpbGUuDQoNCllvdXJzLA0KSm9lbA0KDQoNCg0KU2VudCB2aWEgdGhlIFNhbXN1bmcg R2FsYXh5IFPCriA2LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lDQoNCi0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS0NCkZyb206IEVyaWMgQyBSb3NlbiA8ZXJvc2VuQGp1bmlwZXIu bmV0PG1haWx0bzplcm9zZW5AanVuaXBlci5uZXQ+Pg0KRGF0ZTogMTEvMTEvMTYgMDg6NTggKEdN VC0wODowMCkNClRvOiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRk b2xzb25Ac2FuZHZpbmUuY29tPj4sIGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBv bGRkb2cuY28udWs+LCAiJ0pvZWwgTS4gSGFscGVybiciIDxqbWhAam9lbGhhbHBlcm4uY29tPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sIHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIGRlY3JlbWVudGluZyBzZXJ2aWNlIGZ1bmN0aW9uIHBh dGggaW5kZXgNCg0KT24gMTEvMS8yMDE2IDQ6MjYgUE0sIERhdmUgRG9sc29uIHdyb3RlOg0KPiBZ ZXMsIEknbSBzYXlpbmcgdGhhdCB0aGUgY3VycmVudCAoYXMgSSB1bmRlcnN0YW5kIGl0KSBkZXNp Z24gcGVybWl0cyB0aGUgU0ZGIHRvIGJlIGEgc2ltcGxlIGZvcndhcmRlciwNCj4gbm90IG5lZWRp bmcgdG8gZGlzY3JpbWluYXRlIGJldHdlZW4gcGFja2V0cyBmcm9tIGFub3RoZXIgU0ZGIG9yIHJl dHVybmluZyBmcm9tIGFuIFNGLg0KPiBBIHNpbmdsZSBmb3J3YXJkaW5nIHRhYmxlIGhhbmRsZXMg Ym90aCBjYXNlcy4NCj4gRS5nLiwgYXQgU0ZGMSwgd2hlbiBTST14LCBzZW5kIHRvIFNGMTsgd2hl biBTST14KzEsIHNlbmQgdG8gU0ZGMg0KSSB3b25kZXIgd2hhdCB0aGUgV0cgaGFzIGRlY2lkZWQg YWJvdXQgdGhlIGZvbGxvd2luZyBjYXNlLg0KDQpTdXBwb3NlIE5vZGUgMSBjb250YWlucyBTRkYx IGFuZCBTRjEtMSwgd2hpbGUgTm9kZSAyIGNvbnRhaW5zIFNGRjIgYW5kDQpTRjEtMiwgd2hlcmUg U0YxLTEgYW5kIFNGMS0yIGFyZSB0d28gaW5zdGFuY2VzIG9mIG9mIHRoZSBzYW1lIHNlcnZpY2UN CmZ1bmN0aW9uIChTRjEpLg0KDQpTbyBTRkYxIGlzIGF0dGFjaGVkIGxvY2FsbHkgdG8gU0YxLTEs IGFuZCBTRkYyIGlzIGF0dGFjaGVkIGxvY2FsbHkgdG8gU0YxLTIsDQoNCk5vdyBzdXBwb3NlIHRo YXQgdGhlIFNQSS9TSSB2YWx1ZSAieC95IiBtZWFucyAiU0YxIi4NCg0KV2hlbiBTRkYxIHNlZXMg IngveSIgaW4gdGhlIE5TSCwgaXQgbWF5IGNob29zZSB0byBsb2FkIGJhbGFuY2UgYmV0d2Vlbg0K U0YxLTEgYW5kIFNGMS0yLiAgVGhpcyBtZWFucyBpdCBtYXkgZm9yd2FyZCBlaXRoZXIgbG9jYWxs eSB0byBTRjEtMSBvcg0Kb3ZlciB0aGUgbmV0d29yayB0byBTRjEtMi4NCg0KU3VwcG9zZSBTRkYx IGNob29zZXMgU0YxLTIuICBJdCB0aGVuIG5lZWRzIHRvIHR1bm5lbCB0aGUgcGFja2V0IHRocm91 Z2gNCnRoZSB1bmRlcmxheSB0byBOb2RlIDIuDQoNCldoYXQgaGFwcGVucyB3aGVuIHRoZSBwYWNr ZXQgYXJyaXZlcyBhdCBOb2RlIDI/ICBJZiB0aGUgcGFja2V0IGlzIHNlZW4NCmJ5IFNGRjIsIFNG RjIgd2lsbCBzZWUgIngveSIgaW4gdGhlIE5TSCwgYW5kIG1heSBjaG9vc2UgdG8gZm9yd2FyZA0K ZWl0aGVyIGxvY2FsbHkgdG8gU0YxLTIgb3Igb3ZlciB0aGUgbmV0d29yayB0byBTRjEtMS4gU2lu Y2UgU0ZGMiBkb2Vzbid0DQprbm93IHRoYXQgdGhlIHBhY2tldCBjYW1lIGZyb20gYW5vdGhlciBT RkYsIG5vdGhpbmcgc3RvcHMgaXQgZnJvbQ0KY2hvb3NpbmcgU0YxLTEuDQoNClRoYXQgaXMsICBT RkYxIGNob29zZXMgdG8gdXNlIFNGMS0yLCBhbmQgU0ZGMiBjaG9vc2VzIHRvIHVzZSBTRjEtMSwg dGh1cw0KZm9ybWluZyBhIGxvb3AuICBTaW5jZSB0aGlzIGxvb3AgaXMgYmV0d2VlbiB0aGUgdHdv IFNGRnMsIHRoZSBTSSBuZXZlcg0KZ2V0cyBkZWNyZW1lbnRlZC4NCg0KUHJlc3VtYWJseSB0aGlz IHR5cGUgb2YgbG9hZC1iYWxhbmNpbmcgaXMgYWxsb3dlZCwgYnV0IHRoZSBsb29wIG11c3QgYmUN CnByZXZlbnRlZC4NCg0KT25lIHdheSB0byBwcmV2ZW50IHRoZSBsb29wIGlzIGZvciBTRkYyIHRv IGtub3cgd2hldGhlciBhIHBhY2tldCB3aXRoDQoieC95IiBpbiB0aGUgTlNIIGhhcyBhbHJlYWR5 IGJlZW4gc2VlbiBieSBhbm90aGVyIGZvcndhcmRlciBvciBub3QuDQoNCj4gSW4gc29tZSBjYXNl cywgYW4gU0ZGIGNhbiBiZSBhIHNpbmdsZS1pbnRlcmZhY2UgZGV2aWNlLCBzbyAiZnJvbSBTRkYi IG9yICJmcm9tIFNGIiBpcyBub3QgYXMgc2ltcGxlDQo+IGFzIGNoZWNraW5nIGluZ3Jlc3MgaW50 ZXJmYWNlLCBmb3IgZXhhbXBsZS4NCg0KUHJlc3VtYWJseSB0aGVyZSdzIGEgdHVubmVsIG9mIHNv bWUgc29ydCwgdGhyb3VnaCB0aGUgdW5kZXJsYXksIHRoYXQNCmxlYWRzIGZyb20gU0ZGMSB0byBT RkYyLiAgIFRoaXMgdHVubmVsIGNvdWxkIGJlIHJlZ2FyZGVkIGFzIGEgdmlydHVsYQ0KaW5ncmVz cyBpbnRlcmZhY2UuDQoNCkFsdGVybmF0aXZlbHksIFNGRjEgY291bGQgdHVubmVsIGEgcGFja2V0 IGRpcmVjdGx5IHRvIFNGMS0yLCBieXBhc3NpbmcNClNGRjIgZW50aXJlbHkuICBTRkYyIHRoZW4g d291bGRuJ3QgYWN0dWFsbHkgcHJvY2VzcyB0aGUgcGFja2V0IHVudGlsDQpTRjEtMiBoYXMgZmlu aXNoZWQgd2l0aCBpdC4gIFRoZSBsb2FkIGJhbGFuY2luZyBkZWNpc2lvbiB3b3VsZCBiZSBtYWRl DQpvbmx5IG9uY2UgKGJ5IFNGRjEpLiAgaW4gdGhpcyBjYXNlLCB0aGUgU0ZGcyBkb24ndCBuZWVk IHRvIGtub3cgYWJvdXQgYQ0KcGFja2V0J3MgaW5ncmVzcyAiaW50ZXJmYWNlIiBiZWNhdXNlIFNG RnMgZG9uJ3QgZ2V0IHBhY2tldHMgZnJvbSBlYWNoDQpvdGhlciBkaXJlY3RseS4NCg0KVGhpcyBy ZXF1aXJlcyBvbmx5IHRoYXQgdGhlIHR1bm5lbCB0aHJvdWdoIHRoZSB1bmRlcmxheSBjb250YWlu DQpkZW11bHRpcGxleGluZyBpbmZvcm1hdGlvbiB0aGF0IHdpbGwgY2F1c2UgdGhlIHBhY2tldCwg b25jZSBpdCBhcnJpdmVzDQphdCBOb2RlIDIsIHRvIGJlIGRlbGl2ZXJlZCBkaXJlY3RseSB0byBT RjEtMiwgYnlwYXNzaW5nIFNGRjIuDQoNClRoaXMgbGF0dGVyIG1vZGVsIHNlZW1zIHRvIGJlIHdo YXQgaXMgcmVxdWlyZWQgYnkgc2VjdGlvbiA1LjUgb2YNClJGQzc2NjUsIGJ1dCB0aGUgUkZDIGlz IG5vdCB2ZXJ5IGV4cGxpY2l0IGFib3V0IGl0Lg0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B83907AB8MBX021W3CA2exch_ 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 c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Kb2VsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SWYgeW91IHJlY2FsbCBvdXIgZGlzY3Vzc2lvbnMgYXJvdW5kIFJlbmRl cmVkIFNlcnZpY2UgUGF0aHMgKFJTUHMpLCBJIGhhZCBhIGZ1bGwgZXhwZWN0YXRpb24gdGhhdCB0 aGlzIHR5cGUgb2YgbG9hZCBiYWxhbmNpbmcgd291bGQgd29yay4mbmJzcDsmbmJzcDsgRnVydGhl ciwgd2UgaGFkIHNvbWUNCiBkaXNjdXNzaW9uIG9mIHdoZXRoZXIgdGhlIE5TSCBoZWFkZXIgc2hv dWxkIGNvbW11bmljYXRlZCBTRlAgSUQgb3IgUlNQIElEIHdoZXJlIHRoZSBmb3JtZXIgaXMgbm9u LXNwZWNpZmljIGFyb3VuZCB0aGUgYWN0dWFsIGxvYWQgYmFsYW5jZWQgc2VsZWN0aW9uIG9mIFNG SXMgYW5kIHRoZSBsYXR0ZXIgaXMgY29tcGxldGVseSBjb25jcmV0ZSBpbiB0ZXJtcyBvZiB0aGUg YWN0dWFsIHNlbGVjdGVkIFNGSXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsgUm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29t cG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPmptaC5kaXJlY3Q8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciAxMSwg MjAxNiAxMjowNCBQTTxicj4NCjxiPlRvOjwvYj4gRXJpYyBDIFJvc2VuICZsdDtlcm9zZW5AanVu aXBlci5uZXQmZ3Q7OyBEYXZlIERvbHNvbiAmbHQ7ZGRvbHNvbkBzYW5kdmluZS5jb20mZ3Q7OyBh ZHJpYW5Ab2xkZG9nLmNvLnVrOyAnSm9lbCBNLiBIYWxwZXJuJyAmbHQ7am1oQGpvZWxoYWxwZXJu LmNvbSZndDs7IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gZGVj cmVtZW50aW5nIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBpbmRleDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY3R1YWxseSwgSSBoYWQgcHJlc3Vt ZWQgdGhhdCB0aGUgcGFydGljdWxhciBsaWFkZW4gYmFsYW5jaW5nIHlvdSBkZXNjcmliZSB3YXMg bm90IGV4cGVjdGVkIHRvIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvZiBteSBjb25jZXJucyB3aXRoIHRoZSBwcm9wb3NlZCBC R1AgZW5jb2RpbmcgaXMgdGhhdCBpdCBjYW4gcmVwcmVzZW50IG1hbnkgdGhpbmdzIHRoYXQgd2ls bCBub3Qgd29yay4gJm5ic3A7VGhpcyBzZWVtcyB0byBtYWtlIGl0IGZyYWdpbGUuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXJzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9lbDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2NvbG9yOiM1NzU3NTciPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQm YW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+RnJvbTogRXJpYyBDIFJvc2VuICZsdDs8YSBocmVmPSJtYWlsdG86 ZXJvc2VuQGp1bmlwZXIubmV0Ij5lcm9zZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ow0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5EYXRlOiAxMS8xMS8xNiAwODo1OCAoR01ULTA4OjAwKSA8bzpw Pg0KPC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VG86IERhdmUgRG9sc29uICZsdDs8YSBocmVmPSJt YWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20iPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPiZndDss DQo8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFuQG9sZGRvZy5jby51 azwvYT4sICZxdW90OydKb2VsIE0uIEhhbHBlcm4nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LA0KPGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlN1YmplY3Q6IFJlOiBbc2ZjXSBkZWNyZW1lbnRpbmcgc2VydmljZSBmdW5j dGlvbiBwYXRoIGluZGV4DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biAxMS8xLzIwMTYgNDoyNiBQTSwgRGF2ZSBEb2xzb24gd3JvdGU6PGJyPg0KJmd0OyBZZXMsIEkn bSBzYXlpbmcgdGhhdCB0aGUgY3VycmVudCAoYXMgSSB1bmRlcnN0YW5kIGl0KSBkZXNpZ24gcGVy bWl0cyB0aGUgU0ZGIHRvIGJlIGEgc2ltcGxlIGZvcndhcmRlciw8YnI+DQomZ3Q7IG5vdCBuZWVk aW5nIHRvIGRpc2NyaW1pbmF0ZSBiZXR3ZWVuIHBhY2tldHMgZnJvbSBhbm90aGVyIFNGRiBvciBy ZXR1cm5pbmcgZnJvbSBhbiBTRi48YnI+DQomZ3Q7IEEgc2luZ2xlIGZvcndhcmRpbmcgdGFibGUg aGFuZGxlcyBib3RoIGNhc2VzLjxicj4NCiZndDsgRS5nLiwgYXQgU0ZGMSwgd2hlbiBTST14LCBz ZW5kIHRvIFNGMTsgd2hlbiBTST14JiM0MzsxLCBzZW5kIHRvIFNGRjI8YnI+DQpJIHdvbmRlciB3 aGF0IHRoZSBXRyBoYXMgZGVjaWRlZCBhYm91dCB0aGUgZm9sbG93aW5nIGNhc2UuPGJyPg0KPGJy Pg0KU3VwcG9zZSBOb2RlIDEgY29udGFpbnMgU0ZGMSBhbmQgU0YxLTEsIHdoaWxlIE5vZGUgMiBj b250YWlucyBTRkYyIGFuZCA8YnI+DQpTRjEtMiwgd2hlcmUgU0YxLTEgYW5kIFNGMS0yIGFyZSB0 d28gaW5zdGFuY2VzIG9mIG9mIHRoZSBzYW1lIHNlcnZpY2UgPGJyPg0KZnVuY3Rpb24gKFNGMSku PGJyPg0KPGJyPg0KU28gU0ZGMSBpcyBhdHRhY2hlZCBsb2NhbGx5IHRvIFNGMS0xLCBhbmQgU0ZG MiBpcyBhdHRhY2hlZCBsb2NhbGx5IHRvIFNGMS0yLDxicj4NCjxicj4NCk5vdyBzdXBwb3NlIHRo YXQgdGhlIFNQSS9TSSB2YWx1ZSAmcXVvdDt4L3kmcXVvdDsgbWVhbnMgJnF1b3Q7U0YxJnF1b3Q7 Ljxicj4NCjxicj4NCldoZW4gU0ZGMSBzZWVzICZxdW90O3gveSZxdW90OyBpbiB0aGUgTlNILCBp dCBtYXkgY2hvb3NlIHRvIGxvYWQgYmFsYW5jZSBiZXR3ZWVuIDxicj4NClNGMS0xIGFuZCBTRjEt Mi4mbmJzcDsgVGhpcyBtZWFucyBpdCBtYXkgZm9yd2FyZCBlaXRoZXIgbG9jYWxseSB0byBTRjEt MSBvciA8YnI+DQpvdmVyIHRoZSBuZXR3b3JrIHRvIFNGMS0yLjxicj4NCjxicj4NClN1cHBvc2Ug U0ZGMSBjaG9vc2VzIFNGMS0yLiZuYnNwOyBJdCB0aGVuIG5lZWRzIHRvIHR1bm5lbCB0aGUgcGFj a2V0IHRocm91Z2ggPGJyPg0KdGhlIHVuZGVybGF5IHRvIE5vZGUgMi48YnI+DQo8YnI+DQpXaGF0 IGhhcHBlbnMgd2hlbiB0aGUgcGFja2V0IGFycml2ZXMgYXQgTm9kZSAyPyZuYnNwOyBJZiB0aGUg cGFja2V0IGlzIHNlZW4gPGJyPg0KYnkgU0ZGMiwgU0ZGMiB3aWxsIHNlZSAmcXVvdDt4L3kmcXVv dDsgaW4gdGhlIE5TSCwgYW5kIG1heSBjaG9vc2UgdG8gZm9yd2FyZCA8YnI+DQplaXRoZXIgbG9j YWxseSB0byBTRjEtMiBvciBvdmVyIHRoZSBuZXR3b3JrIHRvIFNGMS0xLiBTaW5jZSBTRkYyIGRv ZXNuJ3QgPGJyPg0Ka25vdyB0aGF0IHRoZSBwYWNrZXQgY2FtZSBmcm9tIGFub3RoZXIgU0ZGLCBu b3RoaW5nIHN0b3BzIGl0IGZyb20gPGJyPg0KY2hvb3NpbmcgU0YxLTEuPGJyPg0KPGJyPg0KVGhh dCBpcywmbmJzcDsgU0ZGMSBjaG9vc2VzIHRvIHVzZSBTRjEtMiwgYW5kIFNGRjIgY2hvb3NlcyB0 byB1c2UgU0YxLTEsIHRodXMgPGJyPg0KZm9ybWluZyBhIGxvb3AuJm5ic3A7IFNpbmNlIHRoaXMg bG9vcCBpcyBiZXR3ZWVuIHRoZSB0d28gU0ZGcywgdGhlIFNJIG5ldmVyIDxicj4NCmdldHMgZGVj cmVtZW50ZWQuPGJyPg0KPGJyPg0KUHJlc3VtYWJseSB0aGlzIHR5cGUgb2YgbG9hZC1iYWxhbmNp bmcgaXMgYWxsb3dlZCwgYnV0IHRoZSBsb29wIG11c3QgYmUgPGJyPg0KcHJldmVudGVkLjxicj4N Cjxicj4NCk9uZSB3YXkgdG8gcHJldmVudCB0aGUgbG9vcCBpcyBmb3IgU0ZGMiB0byBrbm93IHdo ZXRoZXIgYSBwYWNrZXQgd2l0aCA8YnI+DQomcXVvdDt4L3kmcXVvdDsgaW4gdGhlIE5TSCBoYXMg YWxyZWFkeSBiZWVuIHNlZW4gYnkgYW5vdGhlciBmb3J3YXJkZXIgb3Igbm90Ljxicj4NCjxicj4N CiZndDsgSW4gc29tZSBjYXNlcywgYW4gU0ZGIGNhbiBiZSBhIHNpbmdsZS1pbnRlcmZhY2UgZGV2 aWNlLCBzbyAmcXVvdDtmcm9tIFNGRiZxdW90OyBvciAmcXVvdDtmcm9tIFNGJnF1b3Q7IGlzIG5v dCBhcyBzaW1wbGU8YnI+DQomZ3Q7IGFzIGNoZWNraW5nIGluZ3Jlc3MgaW50ZXJmYWNlLCBmb3Ig ZXhhbXBsZS48YnI+DQo8YnI+DQpQcmVzdW1hYmx5IHRoZXJlJ3MgYSB0dW5uZWwgb2Ygc29tZSBz b3J0LCB0aHJvdWdoIHRoZSB1bmRlcmxheSwgdGhhdCA8YnI+DQpsZWFkcyBmcm9tIFNGRjEgdG8g U0ZGMi4mbmJzcDsmbmJzcDsgVGhpcyB0dW5uZWwgY291bGQgYmUgcmVnYXJkZWQgYXMgYSB2aXJ0 dWxhIDxicj4NCmluZ3Jlc3MgaW50ZXJmYWNlLjxicj4NCjxicj4NCkFsdGVybmF0aXZlbHksIFNG RjEgY291bGQgdHVubmVsIGEgcGFja2V0IGRpcmVjdGx5IHRvIFNGMS0yLCBieXBhc3NpbmcgPGJy Pg0KU0ZGMiBlbnRpcmVseS4mbmJzcDsgU0ZGMiB0aGVuIHdvdWxkbid0IGFjdHVhbGx5IHByb2Nl c3MgdGhlIHBhY2tldCB1bnRpbCA8YnI+DQpTRjEtMiBoYXMgZmluaXNoZWQgd2l0aCBpdC4mbmJz cDsgVGhlIGxvYWQgYmFsYW5jaW5nIGRlY2lzaW9uIHdvdWxkIGJlIG1hZGUgPGJyPg0Kb25seSBv bmNlIChieSBTRkYxKS4mbmJzcDsgaW4gdGhpcyBjYXNlLCB0aGUgU0ZGcyBkb24ndCBuZWVkIHRv IGtub3cgYWJvdXQgYSA8YnI+DQpwYWNrZXQncyBpbmdyZXNzICZxdW90O2ludGVyZmFjZSZxdW90 OyBiZWNhdXNlIFNGRnMgZG9uJ3QgZ2V0IHBhY2tldHMgZnJvbSBlYWNoIDxicj4NCm90aGVyIGRp cmVjdGx5Ljxicj4NCjxicj4NClRoaXMgcmVxdWlyZXMgb25seSB0aGF0IHRoZSB0dW5uZWwgdGhy b3VnaCB0aGUgdW5kZXJsYXkgY29udGFpbiA8YnI+DQpkZW11bHRpcGxleGluZyBpbmZvcm1hdGlv biB0aGF0IHdpbGwgY2F1c2UgdGhlIHBhY2tldCwgb25jZSBpdCBhcnJpdmVzIDxicj4NCmF0IE5v ZGUgMiwgdG8gYmUgZGVsaXZlcmVkIGRpcmVjdGx5IHRvIFNGMS0yLCBieXBhc3NpbmcgU0ZGMi48 YnI+DQo8YnI+DQpUaGlzIGxhdHRlciBtb2RlbCBzZWVtcyB0byBiZSB3aGF0IGlzIHJlcXVpcmVk IGJ5IHNlY3Rpb24gNS41IG9mIDxicj4NClJGQzc2NjUsIGJ1dCB0aGUgUkZDIGlzIG5vdCB2ZXJ5 IGV4cGxpY2l0IGFib3V0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B83907AB8MBX021W3CA2exch_-- From nobody Fri Nov 11 09:39:38 2016 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 C2C6E12958B for ; Fri, 11 Nov 2016 09:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 qxAqt4lv23Rm for ; Fri, 11 Nov 2016 09:39:35 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF812129526 for ; Fri, 11 Nov 2016 09:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5928; q=dns/txt; s=iport; t=1478885974; x=1480095574; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1ud+QOZHhWfDBOxoxDVW+UMDcAxEF6TXYJK+OUzCNpQ=; b=EEqJ1UHfcPNPlkHOf+Oee99fSSM1teCZQ15GunrNQlIkzry+AxG6fTeE BOA4IUtS7UHjpjbLYhNjGL0HpQzYLqZ05LXcQAj5VQ5qQ62M29izARpHI uPhqek1QLc6Yn1IfWVqMri0ywjqEpjeQ3UXDijvxUZx7vfPALH3os0s1P I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQApASZY/4sNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygLAQEBAQEfWIEAB403lwuUW4IHHQuFewIagXA/FAECAQEBAQE?= =?us-ascii?q?BAWIohGEBAQEEAQEBCxURMQkXBAIBCBEEAQEBAgIjAwICAiULFAEICAIEARKIX?= =?us-ascii?q?w6uK4Ipi1MBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEJhTWBfYJdhEgXFYJYLYI?= =?us-ascii?q?wBZo8AZBckB6NPoQIAR43gQIchRhyhmWBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,621,1473120000"; d="scan'208";a="347406907" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Nov 2016 17:39:33 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uABHdXC4016856 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Nov 2016 17:39:33 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; Fri, 11 Nov 2016 11:39:33 -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; Fri, 11 Nov 2016 11:39:33 -0600 From: "Jim Guichard (jguichar)" To: Ron Parker , Eric C Rosen , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] [GRAYMAIL] Re: decrementing service function path index Thread-Index: AQHSPEHB8a0Hq40QfkScgaSupXQ6v6DUHV8A Date: Fri, 11 Nov 2016 17:39:32 +0000 Message-ID: <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@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.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] [GRAYMAIL] Re: decrementing service function path index 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, 11 Nov 2016 17:39:37 -0000 V2VsbCB1bmxlc3MgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyBTRkYyIGluIHRoaXMgZXhhbXBsZSB3 aWxsIG5ldmVyIHNlZSB0aGUgTlNIIGFzIFNGRjEgd2lsbCB0dW5uZWwgdGhlIHBhY2tldCBkaXJl Y3RseSB0byBTRjEtMiB1c2luZyB3aGF0ZXZlciB0cmFuc3BvcnQgaXMgaW4gcGxheS4gUmVtZW1i ZXIgdGhhdCB0aGUgU0ZGIHdpbGwgb25seSBmb3J3YXJkIGJhc2VkIG9uIE5TSCBpZiBpdCBzZWVz IGl0IChpLmUuIHRoZSBvdXRlciB0cmFuc3BvcnQgdGVybWluYXRlcyBhdCB0aGUgU0ZGKSBidXQg aW4gdGhpcyBjYXNlIGl0IHdpbGwgc2ltcGx5IHNlZSBhbiBJUCBwYWNrZXQgb24gaXRzIG1lcnJ5 IHdheSB0byBTRjEtMi4gDQoNCkppbQ0KDQoNCg0KDQpPbiAxMS8xMS8xNiwgMTI6MzMgUE0sICJz ZmMgb24gYmVoYWxmIG9mIFJvbiBQYXJrZXIiIDxzZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQoNCj5FcmljLA0K Pg0KPkkgYWdyZWUgd2l0aCB5b3VyIGFuYWx5c2lzLiAgIEVzcGVjaWFsbHkgYXJvdW5kOg0KPg0K PiAgIFByZXN1bWFibHkgdGhpcyB0eXBlIG9mIGxvYWQtYmFsYW5jaW5nIGlzIGFsbG93ZWQsIGJ1 dCB0aGUgbG9vcCBtdXN0IGJlIHByZXZlbnRlZC4NCj4NCj4gICBPbmUgd2F5IHRvIHByZXZlbnQg dGhlIGxvb3AgaXMgZm9yIFNGRjIgdG8ga25vdyB3aGV0aGVyIGEgcGFja2V0IHdpdGggIngveSIg aW4gdGhlIE5TSCBoYXMgYWxyZWFkeSBiZWVuIHNlZW4gYnkgYW5vdGhlciBmb3J3YXJkZXIgb3Ig bm90Lg0KPg0KPkRvIHlvdSB0aGluayB0aGF0IGFuIFNGRiBjb3VsZC9zaG91bGQgZGlzY2VybiB0 aGlzIGJ5IGV4YW1pbmluZyB0aGUgc291cmNlIElQIG9mIHRoZSBwYWNrZXQgaXQgcmVjZWl2ZXMs IG9yIGRvIHlvdSB0aGluayB3ZSBuZWVkIHNvbWUgc29ydCBvZiAic291cmNlIGlkIiBpbiB0aGUg TlNIIGJhc2UgaGVhZGVyLCBpdHNlbGY/DQo+DQo+ICAgUm9uDQo+DQo+DQo+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEVyaWMgQyBSb3Nlbg0KPlNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTEsIDIw MTYgMTE6NTggQU0NCj5UbzogRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPjsgYWRy aWFuQG9sZGRvZy5jby51azsgJ0pvZWwgTS4gSGFscGVybicgPGptaEBqb2VsaGFscGVybi5jb20+ OyBzZmNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBbR1JBWU1BSUxdIFJlOiBbc2ZjXSBkZWNyZW1lbnRp bmcgc2VydmljZSBmdW5jdGlvbiBwYXRoIGluZGV4DQo+DQo+T24gMTEvMS8yMDE2IDQ6MjYgUE0s IERhdmUgRG9sc29uIHdyb3RlOg0KPj4gWWVzLCBJJ20gc2F5aW5nIHRoYXQgdGhlIGN1cnJlbnQg KGFzIEkgdW5kZXJzdGFuZCBpdCkgZGVzaWduIHBlcm1pdHMgDQo+PiB0aGUgU0ZGIHRvIGJlIGEg c2ltcGxlIGZvcndhcmRlciwgbm90IG5lZWRpbmcgdG8gZGlzY3JpbWluYXRlIGJldHdlZW4gcGFj a2V0cyBmcm9tIGFub3RoZXIgU0ZGIG9yIHJldHVybmluZyBmcm9tIGFuIFNGLg0KPj4gQSBzaW5n bGUgZm9yd2FyZGluZyB0YWJsZSBoYW5kbGVzIGJvdGggY2FzZXMuDQo+PiBFLmcuLCBhdCBTRkYx LCB3aGVuIFNJPXgsIHNlbmQgdG8gU0YxOyB3aGVuIFNJPXgrMSwgc2VuZCB0byBTRkYyDQo+SSB3 b25kZXIgd2hhdCB0aGUgV0cgaGFzIGRlY2lkZWQgYWJvdXQgdGhlIGZvbGxvd2luZyBjYXNlLg0K Pg0KPlN1cHBvc2UgTm9kZSAxIGNvbnRhaW5zIFNGRjEgYW5kIFNGMS0xLCB3aGlsZSBOb2RlIDIg Y29udGFpbnMgU0ZGMiBhbmQgU0YxLTIsIHdoZXJlIFNGMS0xIGFuZCBTRjEtMiBhcmUgdHdvIGlu c3RhbmNlcyBvZiBvZiB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIChTRjEpLg0KPg0KPlNvIFNG RjEgaXMgYXR0YWNoZWQgbG9jYWxseSB0byBTRjEtMSwgYW5kIFNGRjIgaXMgYXR0YWNoZWQgbG9j YWxseSB0byBTRjEtMiwNCj4NCj5Ob3cgc3VwcG9zZSB0aGF0IHRoZSBTUEkvU0kgdmFsdWUgIngv eSIgbWVhbnMgIlNGMSIuDQo+DQo+V2hlbiBTRkYxIHNlZXMgIngveSIgaW4gdGhlIE5TSCwgaXQg bWF5IGNob29zZSB0byBsb2FkIGJhbGFuY2UgYmV0d2Vlbg0KPlNGMS0xIGFuZCBTRjEtMi4gIFRo aXMgbWVhbnMgaXQgbWF5IGZvcndhcmQgZWl0aGVyIGxvY2FsbHkgdG8gU0YxLTEgb3Igb3ZlciB0 aGUgbmV0d29yayB0byBTRjEtMi4NCj4NCj5TdXBwb3NlIFNGRjEgY2hvb3NlcyBTRjEtMi4gIEl0 IHRoZW4gbmVlZHMgdG8gdHVubmVsIHRoZSBwYWNrZXQgdGhyb3VnaCB0aGUgdW5kZXJsYXkgdG8g Tm9kZSAyLg0KPg0KPldoYXQgaGFwcGVucyB3aGVuIHRoZSBwYWNrZXQgYXJyaXZlcyBhdCBOb2Rl IDI/ICBJZiB0aGUgcGFja2V0IGlzIHNlZW4gYnkgU0ZGMiwgU0ZGMiB3aWxsIHNlZSAieC95IiBp biB0aGUgTlNILCBhbmQgbWF5IGNob29zZSB0byBmb3J3YXJkIGVpdGhlciBsb2NhbGx5IHRvIFNG MS0yIG9yIG92ZXIgdGhlIG5ldHdvcmsgdG8gU0YxLTEuIFNpbmNlIFNGRjIgZG9lc24ndCBrbm93 IHRoYXQgdGhlIHBhY2tldCBjYW1lIGZyb20gYW5vdGhlciBTRkYsIG5vdGhpbmcgc3RvcHMgaXQg ZnJvbSBjaG9vc2luZyBTRjEtMS4NCj4NCj5UaGF0IGlzLCAgU0ZGMSBjaG9vc2VzIHRvIHVzZSBT RjEtMiwgYW5kIFNGRjIgY2hvb3NlcyB0byB1c2UgU0YxLTEsIHRodXMgZm9ybWluZyBhIGxvb3Au ICBTaW5jZSB0aGlzIGxvb3AgaXMgYmV0d2VlbiB0aGUgdHdvIFNGRnMsIHRoZSBTSSBuZXZlciBn ZXRzIGRlY3JlbWVudGVkLg0KPg0KPlByZXN1bWFibHkgdGhpcyB0eXBlIG9mIGxvYWQtYmFsYW5j aW5nIGlzIGFsbG93ZWQsIGJ1dCB0aGUgbG9vcCBtdXN0IGJlIHByZXZlbnRlZC4NCj4NCj5PbmUg d2F5IHRvIHByZXZlbnQgdGhlIGxvb3AgaXMgZm9yIFNGRjIgdG8ga25vdyB3aGV0aGVyIGEgcGFj a2V0IHdpdGggIngveSIgaW4gdGhlIE5TSCBoYXMgYWxyZWFkeSBiZWVuIHNlZW4gYnkgYW5vdGhl ciBmb3J3YXJkZXIgb3Igbm90Lg0KPg0KPj4gSW4gc29tZSBjYXNlcywgYW4gU0ZGIGNhbiBiZSBh IHNpbmdsZS1pbnRlcmZhY2UgZGV2aWNlLCBzbyAiZnJvbSBTRkYiIA0KPj4gb3IgImZyb20gU0Yi IGlzIG5vdCBhcyBzaW1wbGUgYXMgY2hlY2tpbmcgaW5ncmVzcyBpbnRlcmZhY2UsIGZvciBleGFt cGxlLg0KPg0KPlByZXN1bWFibHkgdGhlcmUncyBhIHR1bm5lbCBvZiBzb21lIHNvcnQsIHRocm91 Z2ggdGhlIHVuZGVybGF5LCB0aGF0IA0KPmxlYWRzIGZyb20gU0ZGMSB0byBTRkYyLiAgIFRoaXMg dHVubmVsIGNvdWxkIGJlIHJlZ2FyZGVkIGFzIGEgdmlydHVsYSANCj5pbmdyZXNzIGludGVyZmFj ZS4NCj4NCj5BbHRlcm5hdGl2ZWx5LCBTRkYxIGNvdWxkIHR1bm5lbCBhIHBhY2tldCBkaXJlY3Rs eSB0byBTRjEtMiwgYnlwYXNzaW5nDQo+U0ZGMiBlbnRpcmVseS4gIFNGRjIgdGhlbiB3b3VsZG4n dCBhY3R1YWxseSBwcm9jZXNzIHRoZSBwYWNrZXQgdW50aWwNCj5TRjEtMiBoYXMgZmluaXNoZWQg d2l0aCBpdC4gIFRoZSBsb2FkIGJhbGFuY2luZyBkZWNpc2lvbiB3b3VsZCBiZSBtYWRlIG9ubHkg b25jZSAoYnkgU0ZGMSkuICBpbiB0aGlzIGNhc2UsIHRoZSBTRkZzIGRvbid0IG5lZWQgdG8ga25v dyBhYm91dCBhIHBhY2tldCdzIGluZ3Jlc3MgImludGVyZmFjZSIgYmVjYXVzZSBTRkZzIGRvbid0 IGdldCBwYWNrZXRzIGZyb20gZWFjaCBvdGhlciBkaXJlY3RseS4NCj4NCj5UaGlzIHJlcXVpcmVz IG9ubHkgdGhhdCB0aGUgdHVubmVsIHRocm91Z2ggdGhlIHVuZGVybGF5IGNvbnRhaW4gZGVtdWx0 aXBsZXhpbmcgaW5mb3JtYXRpb24gdGhhdCB3aWxsIGNhdXNlIHRoZSBwYWNrZXQsIG9uY2UgaXQg YXJyaXZlcyBhdCBOb2RlIDIsIHRvIGJlIGRlbGl2ZXJlZCBkaXJlY3RseSB0byBTRjEtMiwgYnlw YXNzaW5nIFNGRjIuDQo+DQo+VGhpcyBsYXR0ZXIgbW9kZWwgc2VlbXMgdG8gYmUgd2hhdCBpcyBy ZXF1aXJlZCBieSBzZWN0aW9uIDUuNSBvZiBSRkM3NjY1LCBidXQgdGhlIFJGQyBpcyBub3QgdmVy eSBleHBsaWNpdCBhYm91dCBpdC4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNm Y0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Fri Nov 11 12:25:12 2016 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 89BEF12998F for ; Fri, 11 Nov 2016 12:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=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 FcFG_6e6mblR for ; Fri, 11 Nov 2016 12:25:08 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0114.outbound.protection.outlook.com [104.47.32.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7091B129999 for ; Fri, 11 Nov 2016 12:25:08 -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=UEEyhFjWIG3R37YyELYbslGrMnu4k31pc1ScsHs2fxQ=; b=HiHQxmZQWoAIyoD11EC1gKdxsxwdQDl7/cP6u5AbG0atwFRCGXnw6W2PoamBo6raoggyeJZ5JEKczJ9rhoVRgz4EKMUbSO5cHIlKknU79GT3fNOlB1Sf7Q+6Muyp9AYk3zLgkZ05dhYt1NWELwbvlREdnAMey0RhBbT/hNh4C40= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.92] (66.129.241.13) by BY2PR05MB2181.namprd05.prod.outlook.com (10.166.112.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Fri, 11 Nov 2016 20:25:04 +0000 To: "Jim Guichard (jguichar)" , Ron Parker , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> From: Eric C Rosen Message-ID: Date: Fri, 11 Nov 2016 15:25:00 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY1PR17CA0011.namprd17.prod.outlook.com (10.162.18.149) To BY2PR05MB2181.namprd05.prod.outlook.com (10.166.112.9) X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 2:Bj20Q9fQa1mV7fYbc8aI5gSWJivmIGlFc8/A7CAQA/myBfWOh/2dOpkJ+hfUMG0U9k0roYFr5PX+QZY8h5nOiNGNRMP3OVsHZQ8DWvjDbAdCN55Q5x65PgrtcHTJeyy7ZSe9K3ab6DbN8idHDx/voMRb7WxgIqF2hofmZeQVizo=; 3:pyriWlhJ4MX1g6Xshz0zCrj4bL431ecMbw2gykUsYnaCGGVY4YQ3JjcxYBZP8htEA2wUeGepIvfRHgKAyPWPDj+PHWSniQIhdQc0GABhtgcE61D6tPIhyR/A51fv063Mu58O/TBu2nnwIUaeBXM+MP8GsPzmSecg9zmtFtHXmWg= X-MS-Office365-Filtering-Correlation-Id: 930d85ec-bebb-4dea-2b3a-08d40a70d2d9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR05MB2181; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 25:tMRSN/cPMgM+39a7U+aW6Sn4Q0hkKSpzoJEVaPL8WEGtaqigzEwIBAFSN2byZPCBxzfTaD7JvUTuyTJN5OcFN8V/QNoWzT/A0ZigM+21MF3iKY2XbbYGrBI7QfguMhWE07tkmNBYZz5+hzcwiJQEx5rjNOkKkvLwk/Ws+S+pqBODlJ4//0mZUlelsP/45ySa9U+b5d4DtD6J9ZqNUEOoJBY5s/RENh5okDj+GZoB4GZ+LfNQXUaExHl/HJ3Iz/w5hWTiuFrMgzGTV+U++XvZ7RwcFSCUEVEyc+sTOxQ1sL2gs5iiMHZqXv+4NFMvO2V5znqQPh1KQMfnU6LbVnzTRCWIXXruwuIXHd3S7WkaDPX6RwuSPTuh07XBbmwt/BIFKaEZbhHSVT7bGYETCf/G0usnCimcy1NNfWyrCii0fjbIIZJXkSdKh3PoKbim72kA+znG/fji79uV4NRx8zzgET9B2ivcw4MDfxOg5c3er9dH82sa5oS/ptoS8WSkoIhB/QKezm93rVRBFNV5dPhPSiKrUXG1eyADt8g2x8JNT6Qeiir4zhhPA4n37tEJWpM+glUDw6CJV5SPkH6cQtOWx7uCEtk+mi8Lmcj2bwic/NgY7K/FB5Ue8x5NhPfXWqnwFQ9t+agYbFCgswgd22m+dncrZA9ownkZa0YHmI+K4JViPD1gp9tZv0Tqd38siwGtqRiSKQPKKkhf7pP0FkLhezWCcHLliVW8qpY4wsjqI2Q= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 31:+fpEEr44eWFi1EuQJPn/kFQKqkoiXWSjm4+/GLRSSTrvJN43x0Ykmomygf5u3FrA95cGs2jiCavYBSjkbuT+L8YQVH1jLLYDNkb2lQUwWVuwebBc5bQlJnHLZ7DMV70nrS8wB3ARNrRjzfjLNFORCI1YAgcyQvPdtiYYhKbvoWI5kP/1sgQBYqeAqxMXTvi82qo7qrHLWEVMRpx5mO38sdGN6F6eGm9dPRtr4x70AE+HHFLYFiV8j97OsAeRf5WN; 20:4faxOq5/LWj83RbiTI9vY9U/vOct12jCeI4qtbIQkLfseD7wHdfNc+RKXXXpOKG9BJuzEe9MFmqf82m8sxYlXxOKcNQwsQikOC4uvw9rPmHefLvxVXeEHcINGh88lyykKJZGWz7PV35O4B9QcXHAQ2Udi3vdFZpznavALMZGRd5dZzXNov509QG946TgU1gJV7gI8iD3/RguO63ooUYpLYg3Xon6ArpKZYxLAkykfT/fd77LyLnWcJQ9YPXvJciP+0yostjLzKr6xHgucMI3bPlDLZuTZmvFLlg+EIj+4GcgC3zCqSSyZoy9OCrcamXf9tKjfpACVKM54qQ5CBFgTuANjAxm+4fERLNch7/qUO42gTyqdkalbTQE+rdTHIfHFyORkx+xxDFmKpcfEmtax/yBWqX4TkRlUe2NuDNz72efZMnk+tsOgfoAJWOG/H1W0cd9KYJgqbD3lADy1hj5uypaONkUJBDJNJYU+HSPet8kNsp5Eh6/6ugqjOOiJv9TgfXqicie5ekoKXkWfSXOEiliV6dCeKmSnd2aXs0kCIgNq+Zr9q3UOUY9cYsl+sr7D6TMS5Ih86qfj/ytu1j/y4et06oK9h1EqM01Ox0RI2o= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(21532816269658); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY2PR05MB2181; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2181; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 4:IYqKHSpzM1pqPGQAu5YU5cnwZ1MlIQixxtjc3wT6MO6v/q98JypiEK49eDg/KwZQB3+tdoowLa4zSWhQZoDqm3zV7eX3t0UAeUzQExj2qENHxLhMZ8GcNpywlMBA2G4ErR2qS3dVXTWsrdwAu/Im+B6cP4+WnjxejffLTGRtdN6RCYmmqH/HvsSt7SSe2SmkEXmB5kek58Vf+aF4bHx7nGSzwhGGhV3RsVOO+Q+SApEu1lm+fI8dlK6QSGOKedwpm+GmF2X2StGk345i7CoL/4SUFmUB+APlReI3VtP2Ofznrqq6Xd6S/iz4VCS4D9dXZcpeM0kJIMhqf+zPODQuC4Qzokn3msY+Qm/Tl/lh0rSTf9OGuSpnbEJLaPqCQ/VRkuCDL8DNSyUev5gCyYHpQBX0YsXeMIGI6g+YioHMqv5qVFK1OrYH6UG0Ljn+OcClPtCYRrTeF/OOE7gwly9VGA== X-Forefront-PRVS: 012349AD1C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(199003)(93886004)(107886002)(229853002)(36756003)(33646002)(54356999)(106356001)(2501003)(66066001)(64126003)(2906002)(101416001)(77096005)(31686004)(3846002)(5660300001)(586003)(42186005)(47776003)(6116002)(65806001)(50466002)(65826007)(65956001)(97736004)(6666003)(81166006)(105586002)(81156014)(7736002)(305945005)(50986999)(189998001)(68736007)(5001770100001)(4001350100001)(2950100002)(8676002)(92566002)(31696002)(23676002)(83506001)(230700001)(86362001)(7846002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2181; H:[172.29.35.92]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1TUIyMTgxOzIzOkZRT2FtdGhEbFRZMWxiRHRsSXg4UjB6dzFh?= =?utf-8?B?dUt6MXE2QjhNZDZBWE9QaWI3cElxcE9KU2RSV2E2ZUlTc0svTS9aZVArQk1Z?= =?utf-8?B?c0RtYzdPKzFwR2tsVjQ1TGxFa1hRU2dEZXhYaU4xb1g3M0V4ZDFBSEs2Vk5v?= =?utf-8?B?OTcvcVNUa3huQmRmVGtqNm9ud3VnL3MyRnBnTXl2cHZJdWp4NXl4UTQ4N1Zk?= =?utf-8?B?eEE2SFI2a3B6d1A1b2VySkpmOTAwYllkaWNmLzZ0am5iTTNZcm9tTTgvWjRG?= =?utf-8?B?ZENxcEZGR1BCb0pUY2I4K3lZVm1KU1pPbHBxYkV1bTY1OUVzZWNjMVNUVUVs?= =?utf-8?B?MXZTUXI4OEExYi8rOENsWUVsTk9WcGV4RFVpMmp3NUZGQkNhaEVFTmtRcWtv?= =?utf-8?B?Yit3NzhROHZsN1MwL3ZBMFM0VlZPcndkNi9lYm1leUpqSDE1enM2WCtwdnMv?= =?utf-8?B?WVhMSm0wZ0pvMTY2amhHNFhBa3BGZ013dEZLUi8yM1g3L0dVS3BVb3dsZlNI?= =?utf-8?B?OURRMzJEVFVDR2tYbzUyVmNIb0ZLd0ZPSWNwclFncTVLdEdwSGhXeXo3N2NO?= =?utf-8?B?c0NMaWRpK2tISnoxL3VCUGExV3UwYXZ0ZVpodEdSd0Rxc1BtNkJYbVIzb1ZH?= =?utf-8?B?N3REUG5KOC84RlVUaDdkQk03Z3UxYXJsVXh0SEVxVFlvSFhoYWNTQVJXdjYx?= =?utf-8?B?UUphQU5laGtJK3lkMHFTN0gvbVBYK2o1K0wwMFZOOGVZU0lHM1ZuY0lJTnZU?= =?utf-8?B?UWY3MEtDS0tPSlp1Y1JXUWNXK25tU3NrZXZzRU9oZHFVRks0VEh2Q3ppSW5z?= =?utf-8?B?Y0RNWCsxTGpleDVIUjdRMnM5UmRDaFcvQ0dyV1B0dkZBTmJWSUNyNDVjNURL?= =?utf-8?B?d1c2VGxrcUNyNHd3RnluWWFWWHE4SCtaVjkxdzBDZW9DUGtLNTZhTXBGdEpB?= =?utf-8?B?SjFKdzNEWlhEQUN6QUlqY0FXMkxwa25rYzdLU2hWeTJXdUhld1FydHBPekRZ?= =?utf-8?B?eFIrR1ZwZG5vU0VNVzdiR21tSEFOZVgrdE5hbjFjd0NFZTlvK3hELzJDUmxu?= =?utf-8?B?SWsrVGIwMVF2WGRnYXpzQzF3bnp2blRXYjdHWkpxVFE4N09xelNXb25OVEtl?= =?utf-8?B?d3kvOTBYWm80UXJ3OG9RVTlPY0kyNStRN1BkUGZ5ck0yY0JBaGtYS2FQMHlE?= =?utf-8?B?MUgyV1JzYndwRUlwbVJ5eGJqdE5xS3ZXWGpVTGkwOC9kbHNnQnNJaDUxbi9R?= =?utf-8?B?Zlp5OHVCWVg3Y2F5OGFjOWh1b09OU2dOQ2twMEZVeWZISTErdjVRUkpZTys1?= =?utf-8?B?ZkZaTFpBdlhRbDRKN1BTeWZEMnpDZjc2b1pKTUR2K1h4c1BISDhYNlZjZkU4?= =?utf-8?B?ZlJuTGxWOXQxSnI4VTRETzZWL21LdzRXWTVYb2JiUGs4KzhkeEVHZ3gwNU9S?= =?utf-8?B?akR4aWZQTVpwS3VjL3ZDSTBvN1pmejhNY21XREhJbUUwVmowN1cwdnNBOEYy?= =?utf-8?B?Wm1HREtVVDc0RXBrRCtOTHIySnB6Y0hvbHQ3WWlUNkorMDBYdWhMekxiT3Nx?= =?utf-8?B?cDZja0J4cUkwZzF2YkVRM2pIeTZSWG1ZS0YxckdFeGNzREFXanlJTG1jcWhm?= =?utf-8?B?VHh6MjFkTmh1K0E5aUlTaElVTHNiSDh6M0ZER0VjSmRqQTNPeTRFR2hUMVRo?= =?utf-8?Q?7lntGFqNTSJha05Hw8=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 6:LBHf+ZBIT0OiOHbgO3FbcNReU5WwyPDSyC69x3YuhLmxHRF71nnu1A7lZUdE4PHfnztYrXxtRVUIZBlxQ0aU04Lr9x+XCuHw9EqRNpH470VkdoYdaChyywx53PGxWVJw5NdKm7O74qnZX7xq5sRsGcU5S56kyjdMsMQg/imICw19fscS5IHCYukbIenoLZRKHOaa8wMOhzuCEuSq9JPie4BQzpNLzrnH+Ld/4SIu7MP4nFEPH7dZHvPIJLKP/o4cl/Gbbh1qOdr95CX5QJ77oDRRpNFzi4ShzuDMfo594YX/RdPVzkqbaNKocSz8e8oF8y4+gbsczpKbvxbgN2NN3CrGn6pFDhkxM8hp7eNAoqg=; 5:1+eUPlXh3z053O5YJJjZKi1quSZ5oaHVrQlMnkXM2XYtt/EQUeFF3Gg+88hvk4Hs4msX7J/cuVnYW3hQKmZFoDtyVMKz8soRaOWOi3oojo1US7Ote0/RaKSndKmyZ7Uj3eGLHysDuMBrv7wWAy94yw==; 24:0idB9So8SVRD0ofNFYRI2oOrsDxM6uCvzmeO4rZx/FYj222H5pgYTXwa4BvqEMyPgyNsiGCmWxxo2PoXJPYumVYSWcaD8tJ4+O73mfgJ7Lk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 7:SZdQoUDO4srv+bNPkOpS3f85SqYIwcoxBQw5vtBeA9GwTT45kbMXRbEeZEQb4RzB659cvHdN2zKoL5ZU1GcPNxBOJwGOysrJr/DZf4NkZ21COJWKMCrwU3kKOtS6g+OKpPCY/M1eAKWw3U/zAmiR9dti8gEmhvFRuZKsumkFXI1loULTaOIwQNgy2uQCCwJ5Zbh59SLCucrlT0H/QD/WDi+CSDZJf51NQj965/I/FprvjCABhkQRST85OkrXoudcurrKzdaoLcDeIk3QOw33CC1vBSxISODVyBavAFt/m0Arxo+2BTCdaIfPf2ApJTIFK64fHx6pua37lfJ9OOznBQDjxnLrjJ2ai8TTaFrNHsc= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2016 20:25:04.6307 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2181 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 11 Nov 2016 20:25:11 -0000 Jim> Well unless I am missing something SFF2 in this example will never see the NSH as SFF1 will tunnel the packet directly to SF1-2 using whatever transport is in play. That is exactly my point; for this sort of load balancing to work with NSH as it is, one needs to have a transport tunnel from each SFF to each remote SFI that the SFF may select as the next hop in a service path. This means that for every type of transport that might be "in play", you have to figure out what to put in the transport header in order to identify a particular SFI. The fact that the transport tunnels connect SFFs to SFIs rather than connecting SFFs to each other is something that I don't think is apparent from the documents or from some of the recent threads on the mailing list. (Luckily, draft-mackie-bess-nsh-bgp-control-plane handles this well, because it provides encapsulation information on a per-SFI basis.) Ron> Do you think that an SFF could/should discern this by examining the source IP of the packet it receives, or do you think we need some sort of "source id" in the NSH base header, itself If we wanted to require that transport tunnels only go between SFFs, I think it would be sufficient just to have a flag in the NSH that means "the load balancing decision has already been made". I don't think a source id is needed. But I'm not proposing changes to NSH, just exploring the ramifications of some of the existing design decisions. From nobody Fri Nov 11 12:49:58 2016 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 9FA6A129686 for ; Fri, 11 Nov 2016 12:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=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 vfmQ_JwBKHrb for ; Fri, 11 Nov 2016 12:49:55 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0114.outbound.protection.outlook.com [104.47.40.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA71129680 for ; Fri, 11 Nov 2016 12:49:55 -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=ZrEc+O5o+ZAXiGpFvSUSkjq9GKTO4NGWEcy95xL5Z04=; b=JolryisJjBg2GlGwqftPmEm1gTiYYQuN//EQ1cc7OP/ghIIQKl/+WKGo73E/3eplDS0SZAak/44/Bbq9AWNV+PjVWeLdTaJdz4aecHVm6c9sHj/3iSu1OifrvO/DcaOP41fH583YIDaj+sii2/9wW7J4LyNrVvzV3LH4a7Z4rfE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.35.92] (66.129.241.13) by CY1PR05MB2185.namprd05.prod.outlook.com (10.166.192.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Fri, 11 Nov 2016 20:49:52 +0000 To: jmh.direct , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" References: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> From: Eric C Rosen Message-ID: Date: Fri, 11 Nov 2016 15:49:50 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: DM5PR09CA0007.namprd09.prod.outlook.com (10.172.32.17) To CY1PR05MB2185.namprd05.prod.outlook.com (10.166.192.9) X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 2:UJSe5hnEkWiIivGnJn4miJOzfDGdp7v+wYLKMB2FrTI/MbJdHT5D/RicYbr8UReh23qNl2bU9y3h70epRnACrb7Vqz7zG7JmBBqYS6WJzC0wNDPSAKWQocT+QYAEYwtf8S70A6DSjueNwYLMFCW3HpBU4LKvG3kAAricXDEvx74=; 3:RG7nXQdRHKt0LKTNYrrwVHjnBOvSQ/e+8NH052E3hiNCzsjsbGH+6qlmcly+yNtJZecQrXPqTfl0qPaI63ik6p7qMIgXiB4HE5UTyZo5uxv3OyUkmmPzRpZkPEj+3/VzovjohiHW9vdCeJaDl7sGsOqnVMhkAznkqGOnGUsn1Po=; 25:0DdRNd/7mYihhfRn76hhcT9e1hpa3hzl4QVBbuHu3vyQWCYGPi7eVo4FHh2JPwT1fjeWIxl0SmtuMA+PllQWYMRXgXjBOxoYDi9Mu96zZCO3Sq74LtQmVmNNYMfI9I62bQjuX+b636QfAuUEbvER3OBLaT2ZqEy7OAB1M6IyidfXyLXlOwdxjNfi0W48n+xKUieTw9xuDEMl9D9ajHQP269igOi2CeDWnW0628HzOK06yP4H/u2QOnpIMu6d8P17VIch5CLT62jvySJqZRPXj1UXHUhhKzkzuBN7FY60hdqD54QibonnOPo1MaIopvp1UYeAMqeVkApfBRVrlLTR7rWYjSMsZd+9jx+b6HVznNn1gZlSu/4xv9+N5pyzrd4pMUJwBmdoten0g64isdbBnO7Fi6mRxUdZ9mh7S1/wrec/a8HIROcyyx8VDgiO6rct X-MS-Office365-Filtering-Correlation-Id: a363e3aa-1a6d-459c-9c7e-08d40a7449ba X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2185; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 31:GwnrK0ylUVQXnlsIEssukOjePAqKQ7JTAEV3+EGloqza94wrKqfWFW1bZVpGZ0yyItY7SVNO5NAdEt5rRlNqi0tgmXX6PvJ7ynnUfJ2JwD3DTFtyEE0lMztbRPMidWkCqZpgZH2A1J9RT0Gls4Dz7d4+cXSpXa7tTRoAvXJzw7BjcytD/izbOC1jju7xqCJDkuR+lGGYMpoO9fGy+Pf0nOzx1CIHMRymlWFNZbTIMD8WR3c+kXQcHmQPQfMNdkwsOvJhrj2G/TnoYfp2TGOn6Q==; 20:pQMYh0iBdsshbjhFcXvDHhzvj1xIsHS+YfGIQATXIy9KBrlk7QdJCRios0Hf5ZNpl8zT1JKvFGxt5OP9fBit8KHa40Tn9qcS6J8RLMoq0fY75514VYdBoxwipim6C0grdVkIKb2hpwLYajMdImx/JiHQ+JND2tT0iWLEFd9avJBhktPR7MXWWoNxbWU0OJPR7tiDe0+F1JnztHzZcH4OLY0m1fwFuykTBqOuGiAjyHVp5TZ2GwqfohLsXYWYTs908BduHaBdsKydGiD4KF9CY7AFaVfuJ5rMuqGoEdnPVwUk4SNwf2lzjHYsROwgwOwujCoqZ79aBCI+TJ/IfGm1lySntxjVWQtkLNxrWchFQNeozo7e16+SgoZmrSRGQbW2f3MWsaYRi47S8/AJa4zNerDS9/63zIv4+0QkV4iMounNlsH+3ctP7oPKJNinW486ZhW73Os0sUEj09WngV43NsvJV54XFxyZEEXpladb+Yzs9yYCZ7qGOpT7LNfGOC90d5zDWW3f7icysMUro1a0rAR4NJK5F0z+FEw+Wir7RNzg+rVy14m75slkupfDAEm9lR0QIdyCVupEp1ESbNq3E5mn2rnIc0siwBBFUWvDNSQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2185; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2185; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 4:bgkVNAESPtWMzdvRzrzOBhbSPYxg950rUWyAHqnwi82n+ycqQRTM++UHESL6eztWGnp36m2h/KKU0GlTvUHiTKJSBWJsOdAgDZXlVs0d2Z2hVHQ8bLzT6TTaN7joea+4Q9nQlkwsRAz7IWwPSlNmgOwLeFgCfPgZSIX9AlLb+NS7sgyZC+m5838e89ZOy1qfCfzZFr+5C7V6myejHEzHHDKpCaj6QuGDHkmv++IFPPxS8X2mWdiglvU72YjEF7WUQrccc4bDAsq0JdROAhRoPhIXOB0gEi8bdt8zLPbEU/4hv2cVOXMy+LxgLPokTqryaXRttUF1Rp6HfUnyUKtWIR+Toc/j8SPtP4YdwJez9XgH7CdlRTwyqUWC5d+tvKalpVG/V6PIM2LOSAxOafDHXB83NcD5X51vEcL/9E8uqQc= X-Forefront-PRVS: 012349AD1C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(377454003)(189002)(24454002)(83506001)(229853002)(68736007)(305945005)(50466002)(77096005)(65826007)(31696002)(230700001)(2950100002)(189998001)(5660300001)(5001770100001)(4001350100001)(97736004)(81166006)(47776003)(76176999)(54356999)(50986999)(65956001)(66066001)(33646002)(65806001)(2501003)(64126003)(105586002)(2906002)(92566002)(7846002)(31686004)(101416001)(106356001)(23676002)(8676002)(36756003)(81156014)(586003)(6116002)(107886002)(42186005)(86362001)(3846002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2185; H:[172.29.35.92]; 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: =?utf-8?B?MTtDWTFQUjA1TUIyMTg1OzIzOm1kczZjYTFqQ0d2Q2hhdlZBWWRzMGIzaWxh?= =?utf-8?B?UlpIRFA2N0xJY2tOQnFvbDFIaERGTnhNdnZrKzhhSUtRSHk2SmdLclQydHhW?= =?utf-8?B?elNtS2pGMll6clVVVHVmLyt0dDVRaEt2Vkl4UlkrbFIyQUFjZ09NNCtzMCtL?= =?utf-8?B?eWFwaEcwcUsrNWpydnUwYWJpWW01RWV0dFh5Wnh4d0NKNURBTkxGRnZXQ1Ri?= =?utf-8?B?K0FuQm9GQW1OSVE0ZFhVZ0dJNHB4eSswbzROemw1Y0hYODVEQkpPcXZvMkZI?= =?utf-8?B?UTR6ZkxTTTZRVFRKUEZPWUYzUkNnb1AyaGJIZFJPWUNpcFdhM3djV3BkZ1JJ?= =?utf-8?B?UkhVNHcyamMwUWJoRjl2b2RBaFArZEkwQ0MwbGlYcENncUUyM2V6VVp6Tklo?= =?utf-8?B?LzMxejkyZ1BUWlJuWVZqdTJqOEE0RlVqMytvbVJRa0kzOUM1MEtUeW15ZlpX?= =?utf-8?B?dSt5SUVwRUtETWR0NmE3azNXMTFnUHdMSUx3MGZiZ0J3dHhjOGVBUWdwMldJ?= =?utf-8?B?dWtoVVY5VU1TQWRsZ0tBK0k2RmR2KzIxbFg0NjBzN3JkMUlCY3dtN2JlS28z?= =?utf-8?B?VlFpOU9uNyttRS9jR3lCa1RzN0JBcENRQm9qbjZKSDRnZmdUVFc4YzQzamRV?= =?utf-8?B?R0VLMmNXVU1JeEZ5ZlN3dWZ0Z0tSTXN3eEhoS000eEVaa3ByZTBoa0R0ZUth?= =?utf-8?B?SWk0V3luSHBTL3FYYmY5UzEzaG1RT0tpS05QZlNJMVlaUExUZWowMVlLZTVD?= =?utf-8?B?bE5FemVQMnJJRCtNTU5nS3NsSWx5K3U5QVFZSVllSEtSVjhDQ2RlaTVVSjU2?= =?utf-8?B?YTdYUytDOXF4ZnhDVHVTSDN2WUZLd0E3UlFqRkNwY1NNZUljQUhpVThEZktu?= =?utf-8?B?K3RwVGJ3Q01BOVc1aVJQMVBodFluWUdzZ2I2NWJ2cXNTN0N1T1o5QVJLNytr?= =?utf-8?B?REdrc3NTa0lncXAwTnVOVnU1SkEycGl0SGx1Z2JBZWVMZ2lwQnRqc1lLUXJi?= =?utf-8?B?UlQ0bG5nZ3I5VmtLSkcwakZTdUd2bTVoTnIybEE1NjRRU0xBeG5pcUZpL21D?= =?utf-8?B?K2ZscmhiYS9kOEU0K2ZBUllraGJaS0Ria3FXQStiSng2YllQT2ROblJMRllK?= =?utf-8?B?Z2hWK3J3QVAxWk1vR1R5dThob2VHQzF4YXlERW1mZXoxRmFxelVRODk5NnlD?= =?utf-8?B?SXdOaHRZeVBrUDRGSVppMWkwMWZJSkpNc09PbjBESGdpZlRXSXMyZHBheFlI?= =?utf-8?B?d3QzbHNmMjJzUG4xc3YxMFpEdURUMVFtakdTdWRHQ1JFNm51U3daTjh6aWhp?= =?utf-8?B?aFdqMDd2RFl3K2dyM0l1RHBvOHdCV1FYVDdmM1NEVTY2eFBHV01YRFhlbTdG?= =?utf-8?B?bDJEKzNUL3E2SzFaQzJHYkFmOGp5Tm80RzRPSklaVFp5SmFyTXNYbUs3am40?= =?utf-8?B?TklFRHBWaldvUFUyb3A5Mm83M1k2QVJSTWR2eVY1aC9wakdqK3BKTno2eU5Z?= =?utf-8?B?Um93bE9QWmpUeCtDTE9EZG1mWngzY05JRlZsL2lXNEtkb3BoSG5Ka2VuWFZ5?= =?utf-8?B?VmlFSjJQMmtvWVNHcGVwd0FBdHhSUGRJODB1ZHp5cmVZWk9DVDZQSDUxOXVW?= =?utf-8?B?UkZ1KzBVTVdjR1VUZll2UzBMM2pjQThsdFZERENvejU0dDFtZS9LcDZjd2hL?= =?utf-8?Q?TLM23JE9WdeT+yoWZo=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 6:IQUw6qQlVEreXZDmjSzwspDh8eS4kIt9GjN/bmHMH8TfGn2hsnpIi6h+CPYpuy89Il2a6bYBPQAmJKl1xVadU4oB2osGeIvS11jFebHPmF0YuuqCNmBgcwQv133pur0JCUGWURWF5iQejKhfw8Zd38tnIxBUEULUM4KPK83xazXL4okkin5WGPjrEvQ5SLrdQVUYMfYerutfgXM7HMprNtKxHR2KmJszyWrtkmNapvATy2EiLOg/weZe6vvnKwsFHQlvoQ9KyjjGgZR29icc8PeiSd1FjWH90ZKP9YoU9mIjsuJ8vaY9/keEzqKFXbvIQCadmlAjbJAD8UIBCJfq4bRAvu4ruBCygxOM0ux9nFY=; 5:iwZPEaCGIJZa7Knh0+r4Qgo/GA4UpmcL5XVRIUIwIa62bYLTSbeJY5agSBx+Tw1N7AsLc+krhImKFER8PKjpR1OouNIKIpWee0n89BmMJEGzet0Jm0YEZdKbgE8o1fj9yUJsUbH67+R9HEng9Qswuw==; 24:5bR9n4vzGiHx/E0pjMEseqq6flOZTfPFtD+sHzpTh4RGdDEtgH74s5WxjfzkWRxY5LKzDrm9MZq5b320BA7WEbPgPnCI5VF0QoRy1R8k9g4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 7:L19BO/lbJLLdSe1K5SkpvpE/2Ua6dI2y6QFkYdaAaIwtYBKqTFqWkKt4+JED5PvcJfm7F+rRyhfEaFnU6m0BwILA03yVlGaB1TYUHV4I+0l2X92y2pUmzPo5CTeNfskKLxEQA5B2Zb3NJp2T46HxiheYjkuV7DgMWT4T9zJymQoHAfF8zeWuc+jU8kpu+fWcviOpolbChMkAk3wqgKRqwWOMrX7Ut9Hc9HtqP8PVpwyteiALlFlBFZn8JoA7nGQynj2iVAH+hxBV3CStFIQWWNs4SjhTODCE4QZ9EIfK1CmBtCQmG8/m2JqNdFWo/jhnxrnOfcq1Rv38oaAEAlkilGIVrPnDbTupc9PJKooTUXs= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2016 20:49:52.7736 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2185 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 11 Nov 2016 20:49:56 -0000 On 11/11/2016 12:04 PM, jmh.direct wrote: > Actually, I had presumed that the particular load balancing you > describe was not expected to work. I can't imagine why this would not be expected to work. However, it's nice to have one WG chair say "that is not expected to work" and another say "it's obvious how that works". ;-) > One of my concerns with the proposed BGP encoding is that it can > represent many things that will not work. This seems to make it fragile. I guess I have a very different perspective. As long as the protocol supports the SFC/NSH architecture, it's good if it also allows for generalizations of the architecture and for additional features. That doesn't make it fragile, that makes it robust. "Fragile" is when every new feature requires a redesign of the protocol. Another way to make a protocol fragile is to overload too many functions on any one field. For example, imagine a protocol that had one eight-bit field that was used (a) as part of an address, (b) as a TTL, and (c) as a "I'm done with this packet" flag. And suppose this field could also be increased in value (say, by a "reclassifier") as a packet traverses the network. Now, that would be a fragile protocol ;-) From nobody Fri Nov 11 13:14:03 2016 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 5001E12950F for ; Fri, 11 Nov 2016 13:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 3d45gfnEwfs6 for ; Fri, 11 Nov 2016 13:14:01 -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 1D9A71294E7 for ; Fri, 11 Nov 2016 13:14:01 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Fri, 11 Nov 2016 16:13:59 -0500 From: Dave Dolson To: Eric C Rosen , "Jim Guichard (jguichar)" , Ron Parker , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] Re: decrementing service function path index Thread-Index: AQHSPFmypPrGVzWAGU+0+I5rqpGxmKDUSARw Date: Fri, 11 Nov 2016 21:13:59 +0000 Message-ID: References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.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.142.11] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 11 Nov 2016 21:14:02 -0000 SSB0aGluayB0aGVyZSBpcyBzb21lIGxheWVyaW5nIGNvbmZ1c2lvbiBoZXJlLg0KQXMgSSBzZWUg aXQsIG9uY2UgeW91IHB1dCBOU0ggaW5zaWRlIGFub3RoZXIgdHJhbnNwb3J0IChlLmcuLCB0byBk ZWxpdmVyIGl0IGZyb20gYW4gU0ZGIHRvIGFuIFNGKSwgdGhlIGludGVybWVkaWF0ZSBub2RlcyBh cmVuJ3QgZG9pbmcgTlNIIGFueW1vcmUuDQpTbyBpdCBtaWdodCBtYWtlIHNlbnNlIHRvIGRyYXcg ZGlhZ3JhbXMgb2YgbG9naWNhbCBjb25uZWN0aXZpdHkuDQpFcmljLCBJIHRoaW5rIGluIHlvdXIg ZXhhbXBsZXMgYWxsIG9mIHRoZSBTRkZzIGFyZSAiY29ubmVjdGVkIiB0byBhbGwgb2YgdGhlIFNG cyBhdCB0aGUgbG9naWNhbCBsZXZlbC4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogRXJpYyBDIFJvc2VuIFttYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0XSANClNlbnQ6IFNh dHVyZGF5LCBOb3ZlbWJlciAxMiwgMjAxNiA1OjI1IEFNDQpUbzogSmltIEd1aWNoYXJkIChqZ3Vp Y2hhcik7IFJvbiBQYXJrZXI7IERhdmUgRG9sc29uOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyAnSm9l bCBNLiBIYWxwZXJuJzsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gUmU6IGRlY3Jl bWVudGluZyBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggaW5kZXgNCg0KSmltPiBXZWxsIHVubGVzcyBJ IGFtIG1pc3Npbmcgc29tZXRoaW5nIFNGRjIgaW4gdGhpcyBleGFtcGxlIHdpbGwgbmV2ZXINCnNl ZSB0aGUgTlNIIGFzIFNGRjEgd2lsbCB0dW5uZWwgdGhlIHBhY2tldCBkaXJlY3RseSB0byBTRjEt MiB1c2luZyB3aGF0ZXZlciB0cmFuc3BvcnQgaXMgaW4gcGxheS4NCg0KVGhhdCBpcyBleGFjdGx5 IG15IHBvaW50OyBmb3IgdGhpcyBzb3J0IG9mIGxvYWQgYmFsYW5jaW5nIHRvIHdvcmsgd2l0aCBO U0ggYXMgaXQgaXMsIG9uZSBuZWVkcyB0byBoYXZlIGEgdHJhbnNwb3J0IHR1bm5lbCBmcm9tIGVh Y2ggU0ZGIHRvIGVhY2ggcmVtb3RlIFNGSSB0aGF0IHRoZSBTRkYgbWF5IHNlbGVjdCBhcyB0aGUg bmV4dCBob3AgaW4gYSBzZXJ2aWNlIHBhdGguICANClRoaXMgbWVhbnMgdGhhdCBmb3IgZXZlcnkg dHlwZSBvZiB0cmFuc3BvcnQgdGhhdCBtaWdodCBiZSAiaW4gcGxheSIsIHlvdSBoYXZlIHRvIGZp Z3VyZSBvdXQgd2hhdCB0byBwdXQgaW4gdGhlIHRyYW5zcG9ydCBoZWFkZXIgaW4gb3JkZXIgdG8g aWRlbnRpZnkgYSBwYXJ0aWN1bGFyIFNGSS4NCg0KVGhlIGZhY3QgdGhhdCB0aGUgdHJhbnNwb3J0 IHR1bm5lbHMgY29ubmVjdCBTRkZzIHRvIFNGSXMgcmF0aGVyIHRoYW4gY29ubmVjdGluZyBTRkZz IHRvIGVhY2ggb3RoZXIgaXMgc29tZXRoaW5nIHRoYXQgSSBkb24ndCB0aGluayBpcyBhcHBhcmVu dCBmcm9tIHRoZSBkb2N1bWVudHMgb3IgZnJvbSBzb21lIG9mIHRoZSByZWNlbnQgdGhyZWFkcyBv biB0aGUgbWFpbGluZyBsaXN0Lg0KDQooTHVja2lseSwgZHJhZnQtbWFja2llLWJlc3MtbnNoLWJn cC1jb250cm9sLXBsYW5lIGhhbmRsZXMgdGhpcyB3ZWxsLCBiZWNhdXNlIGl0IHByb3ZpZGVzIGVu Y2Fwc3VsYXRpb24gaW5mb3JtYXRpb24gb24gYSBwZXItU0ZJIGJhc2lzLikNCg0KUm9uPiAgRG8g eW91IHRoaW5rIHRoYXQgYW4gU0ZGIGNvdWxkL3Nob3VsZCBkaXNjZXJuIHRoaXMgYnkgZXhhbWlu aW5nDQp0aGUgc291cmNlIElQIG9mIHRoZSBwYWNrZXQgaXQgcmVjZWl2ZXMsIG9yIGRvIHlvdSB0 aGluayB3ZSBuZWVkIHNvbWUgc29ydCBvZiAic291cmNlIGlkIiBpbiB0aGUgTlNIIGJhc2UgaGVh ZGVyLCBpdHNlbGYNCg0KSWYgd2Ugd2FudGVkIHRvIHJlcXVpcmUgdGhhdCB0cmFuc3BvcnQgdHVu bmVscyBvbmx5IGdvIGJldHdlZW4gU0ZGcywgSSB0aGluayBpdCB3b3VsZCBiZSBzdWZmaWNpZW50 IGp1c3QgdG8gaGF2ZSBhIGZsYWcgaW4gdGhlIE5TSCB0aGF0IG1lYW5zICJ0aGUgbG9hZCBiYWxh bmNpbmcgZGVjaXNpb24gaGFzIGFscmVhZHkgYmVlbiBtYWRlIi4gIEkgZG9uJ3QgdGhpbmsgYSBz b3VyY2UgaWQgaXMgbmVlZGVkLg0KDQpCdXQgSSdtIG5vdCBwcm9wb3NpbmcgY2hhbmdlcyB0byBO U0gsIGp1c3QgZXhwbG9yaW5nIHRoZSByYW1pZmljYXRpb25zIG9mIHNvbWUgb2YgdGhlIGV4aXN0 aW5nIGRlc2lnbiBkZWNpc2lvbnMuDQoNCg0K From nobody Fri Nov 11 13:18:52 2016 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 1273C129CD8 for ; Fri, 11 Nov 2016 13:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_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 d3Pu5fvNwTWZ for ; Fri, 11 Nov 2016 13:18:49 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A981129687 for ; Fri, 11 Nov 2016 13:18:49 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0319.002; Fri, 11 Nov 2016 13:18:48 -0800 From: Ron Parker To: Eric C Rosen , "Jim Guichard (jguichar)" , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] Re: decrementing service function path index Thread-Index: AQHSPFmy9O3AP3iWnECkAY/hR57vZ6DUSCWg Date: Fri, 11 Nov 2016 21:18:48 +0000 Message-ID: References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 11 Nov 2016 21:18:51 -0000 RXJpYywgeW91IHJhaXNlIGFuIGV4Y2VsbGVudCBwb2ludCBhYm91dCB0cmFuc3BvcnQgdHVubmVs cy4gICAgIEhlcmUgaXMgbXkgYXBwYXJlbnRseSBpbmNvbXBsZXRlIG9yIGluY29ycmVjdCBtZW50 YWwgbW9kZWw6DQoNCiogU0ZGJ3MgaGF2ZSBkaXJlY3Qgb3IgdHVubmVsZWQgY29ubmVjdGl2aXR5 IHRvIHRoZSBTRkkncyB0aGF0IHRoZXkgImZyb250LWVuZCINCiogU0ZGJ3MgaGF2ZSBkaXJlY3Qg b3IgdHVubmVsZWQgY29ubmVjdGl2aXR5IHRvIG90aGVyIFNGRidzDQoqIFNGSSdzIE1BWSBoYXZl IGRpcmVjdCBvciB0dW5uZWxlZCBjb25uZWN0aXZpdHkgdG8gbXVsdGlwbGUgU0ZGJ3MNCiAgICog aW4gdGhpcyBjYXNlLCBpbiBteSBtZW50YWwgbW9kZWwsIGVhY2ggb2YgdGhvc2UgU0ZGJ3Mgc2lt dWx0YW5lb3VzbHkgImZyb250LWVuZHMiIHRoZSBzaGFyZWQgU0ZJcw0KKiBXaGVuIGFuIFNGRiBu ZWVkcyB0byBmb3J3YXJkIHRvIGFuIFNGSSB0aGF0IGl0IGRvZXNuJ3QgZnJvbnQtZW5kLCBpdCBw cm9ncmVzc2VzIHRoZSBwYWNrZXQgdG8gdGhlIFNGRiB0aGF0IGRvZXMgZnJvbnQtZW5kIHRoYXQg U0ZJDQoNCkkgdGhpbmsgdGhlIGJpZ2dlc3QgZGlzY3JlcGFuY3kgdG8gcmVhbGl0eSBpcyBhcHBh cmVudGx5IHRoZSBsYXN0IGJ1bGxldC4gICBJbiBteSBtb2RlbCwgU0ZGIHRvIFNGSSBhc3NvY2lh dGlvbnMgYXJlIGV4cGxpY2l0IChpLmUuLCBjb25maWd1cmVkIG9yIGNvbW11bmljYXRlZCB2aWEg Yy1wbGFuZSkuICAgSSB3b3VsZCBiZSBvYmxpZ2VkIGlmIHlvdSBjb3VsZCBlbnVtZXJhdGUgaG93 IGZhciBvZmYgSSBhbSBzbyBJIGNhbiBjb25zaWRlciB0aGUgaW1wbGljYXRpb25zIGFuZCBjb25z ZXF1ZW5jZXMuDQoNClRoYW5rcy4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEVyaWMgQyBSb3NlbiBbbWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5ldF0gDQpT ZW50OiBGcmlkYXksIE5vdmVtYmVyIDExLCAyMDE2IDM6MjUgUE0NClRvOiBKaW0gR3VpY2hhcmQg KGpndWljaGFyKSA8amd1aWNoYXJAY2lzY28uY29tPjsgUm9uIFBhcmtlciA8Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbT47IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbT47 IGFkcmlhbkBvbGRkb2cuY28udWs7ICdKb2VsIE0uIEhhbHBlcm4nIDxqbWhAam9lbGhhbHBlcm4u Y29tPjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gUmU6IGRlY3JlbWVudGluZyBz ZXJ2aWNlIGZ1bmN0aW9uIHBhdGggaW5kZXgNCg0KSmltPiBXZWxsIHVubGVzcyBJIGFtIG1pc3Np bmcgc29tZXRoaW5nIFNGRjIgaW4gdGhpcyBleGFtcGxlIHdpbGwgbmV2ZXINCnNlZSB0aGUgTlNI IGFzIFNGRjEgd2lsbCB0dW5uZWwgdGhlIHBhY2tldCBkaXJlY3RseSB0byBTRjEtMiB1c2luZyB3 aGF0ZXZlciB0cmFuc3BvcnQgaXMgaW4gcGxheS4NCg0KVGhhdCBpcyBleGFjdGx5IG15IHBvaW50 OyBmb3IgdGhpcyBzb3J0IG9mIGxvYWQgYmFsYW5jaW5nIHRvIHdvcmsgd2l0aCBOU0ggYXMgaXQg aXMsIG9uZSBuZWVkcyB0byBoYXZlIGEgdHJhbnNwb3J0IHR1bm5lbCBmcm9tIGVhY2ggU0ZGIHRv IGVhY2ggcmVtb3RlIFNGSSB0aGF0IHRoZSBTRkYgbWF5IHNlbGVjdCBhcyB0aGUgbmV4dCBob3Ag aW4gYSBzZXJ2aWNlIHBhdGguICANClRoaXMgbWVhbnMgdGhhdCBmb3IgZXZlcnkgdHlwZSBvZiB0 cmFuc3BvcnQgdGhhdCBtaWdodCBiZSAiaW4gcGxheSIsIHlvdSBoYXZlIHRvIGZpZ3VyZSBvdXQg d2hhdCB0byBwdXQgaW4gdGhlIHRyYW5zcG9ydCBoZWFkZXIgaW4gb3JkZXIgdG8gaWRlbnRpZnkg YSBwYXJ0aWN1bGFyIFNGSS4NCg0KVGhlIGZhY3QgdGhhdCB0aGUgdHJhbnNwb3J0IHR1bm5lbHMg Y29ubmVjdCBTRkZzIHRvIFNGSXMgcmF0aGVyIHRoYW4gY29ubmVjdGluZyBTRkZzIHRvIGVhY2gg b3RoZXIgaXMgc29tZXRoaW5nIHRoYXQgSSBkb24ndCB0aGluayBpcyBhcHBhcmVudCBmcm9tIHRo ZSBkb2N1bWVudHMgb3IgZnJvbSBzb21lIG9mIHRoZSByZWNlbnQgdGhyZWFkcyBvbiB0aGUgbWFp bGluZyBsaXN0Lg0KDQooTHVja2lseSwgZHJhZnQtbWFja2llLWJlc3MtbnNoLWJncC1jb250cm9s LXBsYW5lIGhhbmRsZXMgdGhpcyB3ZWxsLCBiZWNhdXNlIGl0IHByb3ZpZGVzIGVuY2Fwc3VsYXRp b24gaW5mb3JtYXRpb24gb24gYSBwZXItU0ZJIGJhc2lzLikNCg0KUm9uPiAgRG8geW91IHRoaW5r IHRoYXQgYW4gU0ZGIGNvdWxkL3Nob3VsZCBkaXNjZXJuIHRoaXMgYnkgZXhhbWluaW5nDQp0aGUg c291cmNlIElQIG9mIHRoZSBwYWNrZXQgaXQgcmVjZWl2ZXMsIG9yIGRvIHlvdSB0aGluayB3ZSBu ZWVkIHNvbWUgc29ydCBvZiAic291cmNlIGlkIiBpbiB0aGUgTlNIIGJhc2UgaGVhZGVyLCBpdHNl bGYNCg0KSWYgd2Ugd2FudGVkIHRvIHJlcXVpcmUgdGhhdCB0cmFuc3BvcnQgdHVubmVscyBvbmx5 IGdvIGJldHdlZW4gU0ZGcywgSSB0aGluayBpdCB3b3VsZCBiZSBzdWZmaWNpZW50IGp1c3QgdG8g aGF2ZSBhIGZsYWcgaW4gdGhlIE5TSCB0aGF0IG1lYW5zICJ0aGUgbG9hZCBiYWxhbmNpbmcgZGVj aXNpb24gaGFzIGFscmVhZHkgYmVlbiBtYWRlIi4gIEkgZG9uJ3QgdGhpbmsgYSBzb3VyY2UgaWQg aXMgbmVlZGVkLg0KDQpCdXQgSSdtIG5vdCBwcm9wb3NpbmcgY2hhbmdlcyB0byBOU0gsIGp1c3Qg ZXhwbG9yaW5nIHRoZSByYW1pZmljYXRpb25zIG9mIHNvbWUgb2YgdGhlIGV4aXN0aW5nIGRlc2ln biBkZWNpc2lvbnMuDQoNCg0K From nobody Sat Nov 12 03:22:41 2016 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 416A6129A68 for ; Sat, 12 Nov 2016 03:22:40 -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 sn2BkwtoWy2x for ; Sat, 12 Nov 2016 03:22:39 -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 59815129535 for ; Sat, 12 Nov 2016 03:22:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 3EA74263357; Sat, 12 Nov 2016 03:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478949759; bh=/HLCNpw25QFyJIBjdGAzUCMCMtYBABsd2qn2yUawjuE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QLs28moKOGqmgi5qnin0SAwVh4qI38vM3Xx9LFxDZmRhOXpwWXvm1UJliCt/j4PQr ZPs/DzicqHw/GVFAGkFmBbY6qF9B6HEji5KSJRtONsNF0WQCMGg688aMpale+hYS2B VWGeFownJyBNNowEFdIdwb8EjjZluJJFyTl0A0AI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-93c0.meeting.ietf.org (dhcp-93c0.meeting.ietf.org [31.133.147.192]) (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 00C5A24B45F; Sat, 12 Nov 2016 03:22:37 -0800 (PST) To: Eric C Rosen , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" References: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> From: "Joel M. Halpern" Message-ID: <294a889e-7686-2d2e-3b62-70ab38a41c96@joelhalpern.com> Date: Sat, 12 Nov 2016 06:22:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 12 Nov 2016 11:22:40 -0000 There are at least two forms of confusion I can see here. 1) I was speaking about what I had observed as a participant. I am sorry if it appeared I was speaking as chair. The discussions in the WG occured before I was chair, and I did not attempt to review the archives as would be needed to make a chair assertion. 2) "this" actually covers a range of behaviors. As a participant, and as an author on the SFC architecture, I understood the request for delegation to the data plane to cover a number of different cases. However, I at least did not understand it to cover the case I see Eric asking for. Let me describe what I understood, and what I think is being requested. It is clearly up to the WG if there is actual support for changing what we have3. First, structurally, the SFF form an overlay connected by transport mechanisms. Whether those are tunnels or not depends upon the particular transport. Many of the solutions use tunnels. Also, structurally, the mechanism for connecting service function instances to SFF is out of scope of the work, except that it has to preserve the NSH header. (The SFC Proxy is for the case where the actual SF does not understand / preserve the NSH header.) Given that, I believe we are discussing a situation where we have SFF-A and SFF-B. SFF-A has access to SF instance of two different functions, SF_1 and SF-2. SFF-B also has access to SF instance of two different functions, one of them the same functionality SF-2, and one some other SF-3. Whether the two SF-2s are actually the same instance, different instances, or two different front end load balancers for the same cluster is, for this discussion, immaterial. One of the cases we were specifically asked to allow is that when an SFP needs to get to an instance of SF-2, it should be allowed than an earlier SFF could pick between SFF-A and SFF-B. Another case that we I understood to be requested was when SF-2 needed to be reached after SF-1, that SFF-A was free to decide whether to use its local SF-2 instance, or to pass the packet to SFF-B to deliver to his instance. As a side-effect of this, on a different SFP, one could have the situation where SF-2 needed to be reached after SF-3, and the packet went first to SFF-B and then SFF-B could decide whether to hand the packet to the local SF-2 or hand it to SFF-A to delvier to its SF-2. What I heard Eric asking for was for the delegation to allow for a packet which needed to be delviered to SF-2 to be delivered by the preceding SFF to either SFF-A or SFF-B, and then for the SFF it got delivered to to decide whether to delvier it to a local SF-2 or to the other SFF. I do not believe this case was ever suggested to the WG. The logic described in teh SFC archtiecture and the NSH draft will not allow that. In particular, the NSH document is very clear that the SFF can make its forwarding decision based solely on the SFP-ID and SFP Index. As such, if the path and index allows A to hand the packet to B and allows B to hand the packet to A, we would have a major problem. There has been significant discussion on the email list, particularly in the context of who modifies the SFP-Index, about the desire to have the NSH processing be independent of the incoming interface. We also discussed this in the context of possible loops between SFF if there were situations in which SFF forwarded to each other without handing the packet to an SF. As a participant trying to understand the logic, I thought we were clear that even when SFF considered additional (e.g. metadata) information, it did not consider the incoming port. One of the problems we discussed with using incoming port to distingusih things is that depending upon what kinds of transport are used, there is not always port information. There are sometimes separate interfaces. There are sometimes separate source addresses, and sometimes there is simply no information provided by the transport as to who sent the packet to the SFF. Yes, we could as a working group declare that there must always be distinct sender information. That would be a new requirement on the transports, and would complicate cases such as using MPLS as a transport that some members have indicated they consider important. Yours, Joel On 11/11/16 3:49 PM, Eric C Rosen wrote: > On 11/11/2016 12:04 PM, jmh.direct wrote: >> Actually, I had presumed that the particular load balancing you >> describe was not expected to work. > > I can't imagine why this would not be expected to work. > > However, it's nice to have one WG chair say "that is not expected to > work" and another say "it's obvious how that works". ;-) > >> One of my concerns with the proposed BGP encoding is that it can >> represent many things that will not work. This seems to make it fragile. > > I guess I have a very different perspective. As long as the protocol > supports the SFC/NSH architecture, it's good if it also allows for > generalizations of the architecture and for additional features. That > doesn't make it fragile, that makes it robust. "Fragile" is when every > new feature requires a redesign of the protocol. > > Another way to make a protocol fragile is to overload too many functions > on any one field. For example, imagine a protocol that had one > eight-bit field that was used (a) as part of an address, (b) as a TTL, > and (c) as a "I'm done with this packet" flag. And suppose this field > could also be increased in value (say, by a "reclassifier") as a packet > traverses the network. Now, that would be a fragile protocol ;-) > > > > > > > > From nobody Sat Nov 12 04:47:36 2016 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 71506129ACE for ; Sat, 12 Nov 2016 04:47:35 -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 aPN-dBJLECsM for ; Sat, 12 Nov 2016 04:47:33 -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 618A9129453 for ; Sat, 12 Nov 2016 04:47:33 -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; Sat, 12 Nov 2016 04:47:32 -0800 From: Ron Parker To: "Joel M. Halpern" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSPNcWSO7vo8W49EmeO6cH8sfa8qDVTCjr Date: Sat, 12 Nov 2016 12:47:31 +0000 Message-ID: References: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> , <294a889e-7686-2d2e-3b62-70ab38a41c96@joelhalpern.com> In-Reply-To: <294a889e-7686-2d2e-3b62-70ab38a41c96@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" , "sfc@ietf.org" , Dave Dolson , Eric C Rosen Subject: Re: [sfc] decrementing service function path index 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, 12 Nov 2016 12:47:35 -0000 I think that the view that CP communicates the forwarding table (I believe = this view to be broadly held) is too limiting. If, instead, it communicate= d forwarding policy/rules, the actual forwarding table would be constructed= locally, accounting for any local load balancing decisions. For SFPs tha= t support some or all of their SFs to be load balanced in this manner, the = SI as interpreted by CP now means a class of SFs and not a specific SF (in = positions of the SFP where the load balancing is allowed in this manner).=20 =20 Ron > On Nov 12, 2016, at 6:22 AM, Joel M. Halpern wrote: >=20 > There are at least two forms of confusion I can see here. >=20 > 1) I was speaking about what I had observed as a participant. I am sorry= if it appeared I was speaking as chair. The discussions in the WG occured= before I was chair, and I did not attempt to review the archives as would = be needed to make a chair assertion. >=20 > 2) "this" actually covers a range of behaviors. >=20 > As a participant, and as an author on the SFC architecture, I understood = the request for delegation to the data plane to cover a number of different= cases. However, I at least did not understand it to cover the case I see = Eric asking for. >=20 > Let me describe what I understood, and what I think is being requested. I= t is clearly up to the WG if there is actual support for changing what we h= ave3. >=20 > First, structurally, the SFF form an overlay connected by transport mecha= nisms. Whether those are tunnels or not depends upon the particular transp= ort. Many of the solutions use tunnels. > Also, structurally, the mechanism for connecting service function instanc= es to SFF is out of scope of the work, except that it has to preserve the N= SH header. (The SFC Proxy is for the case where the actual SF does not und= erstand / preserve the NSH header.) >=20 > Given that, I believe we are discussing a situation where we have SFF-A a= nd SFF-B. SFF-A has access to SF instance of two different functions, SF_1 = and SF-2. SFF-B also has access to SF instance of two different functions,= one of them the same functionality SF-2, and one some other SF-3. Whether= the two SF-2s are actually the same instance, different instances, or two = different front end load balancers for the same cluster is, for this discus= sion, immaterial. >=20 > One of the cases we were specifically asked to allow is that when an SFP = needs to get to an instance of SF-2, it should be allowed than an earlier S= FF could pick between SFF-A and SFF-B. >=20 > Another case that we I understood to be requested was when SF-2 needed to= be reached after SF-1, that SFF-A was free to decide whether to use its lo= cal SF-2 instance, or to pass the packet to SFF-B to deliver to his instanc= e. > As a side-effect of this, on a different SFP, one could have the situatio= n where SF-2 needed to be reached after SF-3, and the packet went first to = SFF-B and then SFF-B could decide whether to hand the packet to the local S= F-2 or hand it to SFF-A to delvier to its SF-2. >=20 > What I heard Eric asking for was for the delegation to allow for a packet= which needed to be delviered to SF-2 to be delivered by the preceding SFF = to either SFF-A or SFF-B, and then for the SFF it got delivered to to decid= e whether to delvier it to a local SF-2 or to the other SFF. >=20 > I do not believe this case was ever suggested to the WG. The logic descr= ibed in teh SFC archtiecture and the NSH draft will not allow that. In par= ticular, the NSH document is very clear that the SFF can make its forwardin= g decision based solely on the SFP-ID and SFP Index. As such, if the path = and index allows A to hand the packet to B and allows B to hand the packet = to A, we would have a major problem. > There has been significant discussion on the email list, particularly in = the context of who modifies the SFP-Index, about the desire to have the NSH= processing be independent of the incoming interface. We also discussed th= is in the context of possible loops between SFF if there were situations in= which SFF forwarded to each other without handing the packet to an SF. As= a participant trying to understand the logic, I thought we were clear that= even when SFF considered additional (e.g. metadata) information, it did no= t consider the incoming port. >=20 > One of the problems we discussed with using incoming port to distingusih = things is that depending upon what kinds of transport are used, there is no= t always port information. There are sometimes separate interfaces. There = are sometimes separate source addresses, and sometimes there is simply no i= nformation provided by the transport as to who sent the packet to the SFF. = Yes, we could as a working group declare that there must always be distinc= t sender information. That would be a new requirement on the transports, a= nd would complicate cases such as using MPLS as a transport that some membe= rs have indicated they consider important. >=20 > Yours, > Joel >=20 >> On 11/11/16 3:49 PM, Eric C Rosen wrote: >>> On 11/11/2016 12:04 PM, jmh.direct wrote: >>> Actually, I had presumed that the particular load balancing you >>> describe was not expected to work. >>=20 >> I can't imagine why this would not be expected to work. >>=20 >> However, it's nice to have one WG chair say "that is not expected to >> work" and another say "it's obvious how that works". ;-) >>=20 >>> One of my concerns with the proposed BGP encoding is that it can >>> represent many things that will not work. This seems to make it fragile= . >>=20 >> I guess I have a very different perspective. As long as the protocol >> supports the SFC/NSH architecture, it's good if it also allows for >> generalizations of the architecture and for additional features. That >> doesn't make it fragile, that makes it robust. "Fragile" is when every >> new feature requires a redesign of the protocol. >>=20 >> Another way to make a protocol fragile is to overload too many functions >> on any one field. For example, imagine a protocol that had one >> eight-bit field that was used (a) as part of an address, (b) as a TTL, >> and (c) as a "I'm done with this packet" flag. And suppose this field >> could also be increased in value (say, by a "reclassifier") as a packet >> traverses the network. Now, that would be a fragile protocol ;-) >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Nov 12 14:08:33 2016 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 CE3911294B4 for ; Sat, 12 Nov 2016 14:08:25 -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 BkJpcDxYeiXF for ; Sat, 12 Nov 2016 14:08:23 -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 89E66126CD8 for ; Sat, 12 Nov 2016 14:08:23 -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 uACM8FFa023572; Sat, 12 Nov 2016 22:08:15 GMT Received: from 950129200 ([58.120.104.2]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id uACM8AS7023511 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 12 Nov 2016 22:08:13 GMT From: "Adrian Farrel" To: "'Ron Parker'" , "'Eric C Rosen'" , "'Jim Guichard \(jguichar\)'" , "'Dave Dolson'" , "'Joel M. Halpern'" , References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> In-Reply-To: Date: Sat, 12 Nov 2016 22:08:07 -0000 Message-ID: <0dea01d23d31$42821980$c7864c80$@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: AQIgrbss3hc6CKL2djyaMboulKyfnQG7Sgr8AXzjmREBJLKr8wNKeon+AeVOae4Bj9QfJAIRFMC1AoOscBQCIVFnCQMBLfNyALtFTFqfjI0OUA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22696.003 X-TM-AS-Result: No--12.550-10.0-31-10 X-imss-scan-details: No--12.550-10.0-31-10 X-TMASE-MatchedRID: gzVbiXtWD9v/L1OmfjpS5pmug812qIbz78+iNzIXmPOTRKwJ9IvW+YCu qghmtWfXJkkHKpjR6XAQqXYq+jFJOaPsv4iPeV3NnhHKNOYbLL6lY+G3TvhajZp7oByyIr/NwCt RPmnYINJNYvDaO9t+nFxBgG7mg/Dlrc1P3+sGT5yVUcz8XpiS9IEcpMn6x9cZdHKVzba1Q/3LsV tV5uAXoAXyh7zbeS+DnigNcqoKjgvCvGwqhr+p7eXEBW3Y8Wp+XccelkX/ubCCsBeCv8CM/bppS wuYPeB7LiQKZUkLSuwxK06rCzlCCG8Fyh0Rv2sVq9e4GPoN3vGn4oqkEDHdRuQydRUvl3QT++3g Q26tbbi7lSWLlh/2ux4oyGx/NBqwCCk23kSAVswcAs17rCuNsedJKF0CJUbKxQ9jBEEzSQd/tRh i0zpKILAIxfKk6xgcN9YSxuW+d6zbs/05ilnemlPjo7D4SFg44+ZcrqvCDkF94c+e7fWIcL6+Zj PnEZJY585VzGMOFzABi3kqJOK62QtuKBGekqUpI/NGWt0UYPA1xyctdW/dMrHHZPpkSeJkfx2Zh /W0m6LgWRUyln3BdGY7eqLvyw0k Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 12 Nov 2016 22:08:26 -0000 Ron, I find myself agreeing with most of your "incomplete or incorrect" = model. But I wonder.... If an SFI is connected (by tunnels or otherwise) to more than one SFF = (i.e., the SFI is front-ended by more than one SFF), how does it decide = through which connection to return a packet that it has processed? The = decision could be as simple as to assume bidirectional tunnels and send = each packet back through the same tunnel on which it was received = maintaining a little per packet state in the SF, or could be as complex = as making a forwarding decision based on some knowledge of the SFP. It = could require inspection of the NSH or could be the product of load = balancing. Now, before the howling grows to severe :-) this suggests to me that = connecting an SFI to multiple SFFs might be unwise. Adrian > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: 11 November 2016 21:19 > To: Eric C Rosen; Jim Guichard (jguichar); Dave Dolson; = adrian@olddog.co.uk; 'Joel > M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] Re: decrementing service function path index >=20 > Eric, you raise an excellent point about transport tunnels. Here = is my apparently > incomplete or incorrect mental model: >=20 > * SFF's have direct or tunneled connectivity to the SFI's that they = "front-end" > * SFF's have direct or tunneled connectivity to other SFF's > * SFI's MAY have direct or tunneled connectivity to multiple SFF's > * in this case, in my mental model, each of those SFF's = simultaneously "front- > ends" the shared SFIs > * When an SFF needs to forward to an SFI that it doesn't front-end, it = progresses > the packet to the SFF that does front-end that SFI >=20 > I think the biggest discrepancy to reality is apparently the last = bullet. In my > model, SFF to SFI associations are explicit (i.e., configured or = communicated via c- > plane). I would be obliged if you could enumerate how far off I am = so I can > consider the implications and consequences. >=20 > Thanks. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Friday, November 11, 2016 3:25 PM > To: Jim Guichard (jguichar) ; Ron Parker > ; Dave Dolson ; > adrian@olddog.co.uk; 'Joel M. Halpern' ; = sfc@ietf.org > Subject: Re: [sfc] Re: decrementing service function path index >=20 > Jim> Well unless I am missing something SFF2 in this example will = never > see the NSH as SFF1 will tunnel the packet directly to SF1-2 using = whatever > transport is in play. >=20 > That is exactly my point; for this sort of load balancing to work with = NSH as it is, > one needs to have a transport tunnel from each SFF to each remote SFI = that the > SFF may select as the next hop in a service path. > This means that for every type of transport that might be "in play", = you have to > figure out what to put in the transport header in order to identify a = particular SFI. >=20 > The fact that the transport tunnels connect SFFs to SFIs rather than = connecting > SFFs to each other is something that I don't think is apparent from = the documents > or from some of the recent threads on the mailing list. >=20 > (Luckily, draft-mackie-bess-nsh-bgp-control-plane handles this well, = because it > provides encapsulation information on a per-SFI basis.) >=20 > Ron> Do you think that an SFF could/should discern this by examining > the source IP of the packet it receives, or do you think we need some = sort of > "source id" in the NSH base header, itself >=20 > If we wanted to require that transport tunnels only go between SFFs, I = think it > would be sufficient just to have a flag in the NSH that means "the = load balancing > decision has already been made". I don't think a source id is needed. >=20 > But I'm not proposing changes to NSH, just exploring the ramifications = of some of > the existing design decisions. >=20 From nobody Sat Nov 12 14:32:59 2016 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 049191294D0; Sat, 12 Nov 2016 14:32:56 -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_40=-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 tP7mRftpgQSC; Sat, 12 Nov 2016 14:32:55 -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 CAD0B129405; Sat, 12 Nov 2016 14:32:54 -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 uACMWqEI028295; Sat, 12 Nov 2016 22:32:52 GMT Received: from 950129200 ([58.120.104.2]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uACMWm96028274 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 12 Nov 2016 22:32:51 GMT From: "Adrian Farrel" To: Date: Sat, 12 Nov 2016 22:32:46 -0000 Message-ID: <0df601d23d34$b30aaa20$191ffe60$@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: AdI9NK6K0S6WFMknRGCGjbkKiKc7hg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22696.003 X-TM-AS-Result: No--5.117-10.0-31-10 X-imss-scan-details: No--5.117-10.0-31-10 X-TMASE-MatchedRID: 7ZzK4U4L8LQ9d1nHWxkekPHkpkyUphL9UcH09qBGmHRIRRbSf2xcTJxc qyimK04xpNkGX2Ew1qV8RJrzb34CraBW2ZrFVYNRma6DzXaohvMS12tj9Zvd8ypnHGSoRylAGlQ k6C/T3fExZkVI8xKeC1+24nCsUSFNExAtD/T72EbdB/CxWTRRu25FeHtsUoHuzvXPZh2qWVbOuM 1+QiEmiz1vOT2WcdYjVjf6+C1dk76+68HqACCvKA== Archived-At: Cc: bess@ietf.org Subject: [sfc] BGP/SFC encoding of things that will not work 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, 12 Nov 2016 22:32:56 -0000 Joel said... > One of my concerns with the proposed BGP encoding is that it can = represent > many things that will not work. This seems to make it fragile. Joel, if I may, can I call you out on that generalisation? I don't find anything in your statement that I can discuss or debate. = Perhaps you could help with an example of what thing you might encode = that "will not work". Thanks, Adrian PS I have cross-posted this mail to SFC and BESS as requested by the AD From nobody Sat Nov 12 16:23:27 2016 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 94F4812949A for ; Sat, 12 Nov 2016 16:23:26 -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 AbNCNaYi9GWK for ; Sat, 12 Nov 2016 16:23:24 -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 9AB71129549 for ; Sat, 12 Nov 2016 16:23:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7367B24B45F; Sat, 12 Nov 2016 16:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1478996604; bh=Ldpnlde4Z5oTc4uc6b/q4HgA1oKrW2m9ojv1HO5hcPI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=mOVVShaF+HbIgY34Q367D5jIXhfVrFw0QvwtCeeuvLgRH/kUcxYHqgT26XJ+1oVIf xg5IcUlKJDD3yY3VgWZqOKhgxl0cjuYLCeLw+SoCdxmMqW6VvMEwBSKubkEb63X7UM ZzL5GE8v01ky8DvO5mXD2rSk+QUa9u0EwjxOdp74= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-93c0.meeting.ietf.org (dhcp-93c0.meeting.ietf.org [31.133.147.192]) (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 1818224069B; Sat, 12 Nov 2016 16:23:22 -0800 (PST) To: Ron Parker References: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> <294a889e-7686-2d2e-3b62-70ab38a41c96@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <9acd3d65-4bc0-9409-412d-6743b01bd280@joelhalpern.com> Date: Sat, 12 Nov 2016 19:23:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "adrian@olddog.co.uk" , "sfc@ietf.org" , Dave Dolson , Eric C Rosen Subject: Re: [sfc] decrementing service function path index 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, 13 Nov 2016 00:23:26 -0000 Since we are not defining the control protocol, we do not need to decide whether control provides policy or SF information. As I understand it from working on the drafts, we have agreed that even if control provides SF identification, it is allowed to provide a list of choices. Which is why the three different load balancing cases I cited are, as far as I can tell, supported by the current definitions. Yours, Joel On 11/12/16 7:47 AM, Ron Parker wrote: > I think that the view that CP communicates the forwarding table (I believe this view to be broadly held) is too limiting. If, instead, it communicated forwarding policy/rules, the actual forwarding table would be constructed locally, accounting for any local load balancing decisions. For SFPs that support some or all of their SFs to be load balanced in this manner, the SI as interpreted by CP now means a class of SFs and not a specific SF (in positions of the SFP where the load balancing is allowed in this manner). > > Ron > >> On Nov 12, 2016, at 6:22 AM, Joel M. Halpern wrote: >> >> There are at least two forms of confusion I can see here. >> >> 1) I was speaking about what I had observed as a participant. I am sorry if it appeared I was speaking as chair. The discussions in the WG occured before I was chair, and I did not attempt to review the archives as would be needed to make a chair assertion. >> >> 2) "this" actually covers a range of behaviors. >> >> As a participant, and as an author on the SFC architecture, I understood the request for delegation to the data plane to cover a number of different cases. However, I at least did not understand it to cover the case I see Eric asking for. >> >> Let me describe what I understood, and what I think is being requested. It is clearly up to the WG if there is actual support for changing what we have3. >> >> First, structurally, the SFF form an overlay connected by transport mechanisms. Whether those are tunnels or not depends upon the particular transport. Many of the solutions use tunnels. >> Also, structurally, the mechanism for connecting service function instances to SFF is out of scope of the work, except that it has to preserve the NSH header. (The SFC Proxy is for the case where the actual SF does not understand / preserve the NSH header.) >> >> Given that, I believe we are discussing a situation where we have SFF-A and SFF-B. SFF-A has access to SF instance of two different functions, SF_1 and SF-2. SFF-B also has access to SF instance of two different functions, one of them the same functionality SF-2, and one some other SF-3. Whether the two SF-2s are actually the same instance, different instances, or two different front end load balancers for the same cluster is, for this discussion, immaterial. >> >> One of the cases we were specifically asked to allow is that when an SFP needs to get to an instance of SF-2, it should be allowed than an earlier SFF could pick between SFF-A and SFF-B. >> >> Another case that we I understood to be requested was when SF-2 needed to be reached after SF-1, that SFF-A was free to decide whether to use its local SF-2 instance, or to pass the packet to SFF-B to deliver to his instance. >> As a side-effect of this, on a different SFP, one could have the situation where SF-2 needed to be reached after SF-3, and the packet went first to SFF-B and then SFF-B could decide whether to hand the packet to the local SF-2 or hand it to SFF-A to delvier to its SF-2. >> >> What I heard Eric asking for was for the delegation to allow for a packet which needed to be delviered to SF-2 to be delivered by the preceding SFF to either SFF-A or SFF-B, and then for the SFF it got delivered to to decide whether to delvier it to a local SF-2 or to the other SFF. >> >> I do not believe this case was ever suggested to the WG. The logic described in teh SFC archtiecture and the NSH draft will not allow that. In particular, the NSH document is very clear that the SFF can make its forwarding decision based solely on the SFP-ID and SFP Index. As such, if the path and index allows A to hand the packet to B and allows B to hand the packet to A, we would have a major problem. >> There has been significant discussion on the email list, particularly in the context of who modifies the SFP-Index, about the desire to have the NSH processing be independent of the incoming interface. We also discussed this in the context of possible loops between SFF if there were situations in which SFF forwarded to each other without handing the packet to an SF. As a participant trying to understand the logic, I thought we were clear that even when SFF considered additional (e.g. metadata) information, it did not consider the incoming port. >> >> One of the problems we discussed with using incoming port to distingusih things is that depending upon what kinds of transport are used, there is not always port information. There are sometimes separate interfaces. There are sometimes separate source addresses, and sometimes there is simply no information provided by the transport as to who sent the packet to the SFF. Yes, we could as a working group declare that there must always be distinct sender information. That would be a new requirement on the transports, and would complicate cases such as using MPLS as a transport that some members have indicated they consider important. >> >> Yours, >> Joel >> >>> On 11/11/16 3:49 PM, Eric C Rosen wrote: >>>> On 11/11/2016 12:04 PM, jmh.direct wrote: >>>> Actually, I had presumed that the particular load balancing you >>>> describe was not expected to work. >>> >>> I can't imagine why this would not be expected to work. >>> >>> However, it's nice to have one WG chair say "that is not expected to >>> work" and another say "it's obvious how that works". ;-) >>> >>>> One of my concerns with the proposed BGP encoding is that it can >>>> represent many things that will not work. This seems to make it fragile. >>> >>> I guess I have a very different perspective. As long as the protocol >>> supports the SFC/NSH architecture, it's good if it also allows for >>> generalizations of the architecture and for additional features. That >>> doesn't make it fragile, that makes it robust. "Fragile" is when every >>> new feature requires a redesign of the protocol. >>> >>> Another way to make a protocol fragile is to overload too many functions >>> on any one field. For example, imagine a protocol that had one >>> eight-bit field that was used (a) as part of an address, (b) as a TTL, >>> and (c) as a "I'm done with this packet" flag. And suppose this field >>> could also be increased in value (say, by a "reclassifier") as a packet >>> traverses the network. Now, that would be a fragile protocol ;-) >>> >>> >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Nov 12 18:47:30 2016 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 8D6F212950E for ; Sat, 12 Nov 2016 18:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 SbpbaYqDXG3O for ; Sat, 12 Nov 2016 18:47:26 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A2A12940A for ; Sat, 12 Nov 2016 18:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5066; q=dns/txt; s=iport; t=1479005246; x=1480214846; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ye4ky41CliMui7GIFe/PArgaGagk8M6h+3916GHs1H8=; b=d4Cyx3VRSpjZ01unQU47Lhmn9alEW0M3Tq7argoF0lltGsEEsMXbE51u REe89ArHuCTKofaojXfLKJsTHZBil7O2zMHJeJYr62CCwCHWc5F+l54oP C5knY2/4nfvmzm1mI0QO+CitExXP8Aka2CThWRATg7XVdLB6R36YT0V41 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQAf0ydY/5ldJa1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMmCwEBAQEBH1iBAAeNN5cJlGCCBx0LgjWDRgKCDD8UAQIBAQE?= =?us-ascii?q?BAQEBYiiEYQEBAQQBAQE3NBcEAgEIEQQBAR8JBycLFAkIAgQBEgiIWQ6xRotCA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBFwWLFoQgLzGFKQWaQQGJSYcMkCeNRIQJAR4?= =?us-ascii?q?3gQMchRpyhnyBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,482,1473120000"; d="scan'208";a="347802425" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2016 02:47:25 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uAD2lPq3014935 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 13 Nov 2016 02:47:25 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 12 Nov 2016 20:47:24 -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; Sat, 12 Nov 2016 20:47:25 -0600 From: "Surendra Kumar (smkumar)" To: "adrian@olddog.co.uk" , "'Ron Parker'" , "'Eric C Rosen'" , "Jim Guichard (jguichar)" , "'Dave Dolson'" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSPFm5obKOLlhBikWOxkebyzPtc6DUrkMAgAGgHYD//9iz4A== Date: Sun, 13 Nov 2016 02:47:25 +0000 Message-ID: References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> <0dea01d23d31$42821980$c7864c80$@olddog.co.uk> In-Reply-To: <0dea01d23d31$42821980$c7864c80$@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.24.8.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 13 Nov 2016 02:47:28 -0000 Isn't that programmed by the control plane as part of laying out the SFP ? IOW, for a given SFP, there is one (and only one) anchor SFF for each SFI, = to keep the implementation simpler. Otherwise, I tend to agree with the ass= essment on complexities: asymmetric forwarding and problematic to state-ful= l SFFs, etc. Surendra.=20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Saturday, November 12, 2016 2:08 PM To: 'Ron Parker' ; 'Eric C Rosen' ; Jim Guichard (jguichar) ; 'Dave Dolson' <= ddolson@sandvine.com>; 'Joel M. Halpern' ; sfc@ietf.or= g Subject: Re: [sfc] decrementing service function path index Ron, I find myself agreeing with most of your "incomplete or incorrect" mod= el. But I wonder.... If an SFI is connected (by tunnels or otherwise) to more than one SFF (i.e.= , the SFI is front-ended by more than one SFF), how does it decide through = which connection to return a packet that it has processed? The decision cou= ld be as simple as to assume bidirectional tunnels and send each packet bac= k through the same tunnel on which it was received maintaining a little per= packet state in the SF, or could be as complex as making a forwarding deci= sion based on some knowledge of the SFP. It could require inspection of the= NSH or could be the product of load balancing. Now, before the howling grows to severe :-) this suggests to me that conne= cting an SFI to multiple SFFs might be unwise. Adrian > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: 11 November 2016 21:19 > To: Eric C Rosen; Jim Guichard (jguichar); Dave Dolson;=20 > adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] Re: decrementing service function path index >=20 > Eric, you raise an excellent point about transport tunnels. Here is m= y apparently > incomplete or incorrect mental model: >=20 > * SFF's have direct or tunneled connectivity to the SFI's that they "fron= t-end" > * SFF's have direct or tunneled connectivity to other SFF's > * SFI's MAY have direct or tunneled connectivity to multiple SFF's > * in this case, in my mental model, each of those SFF's=20 > simultaneously "front- ends" the shared SFIs > * When an SFF needs to forward to an SFI that it doesn't front-end, it=20 > progresses the packet to the SFF that does front-end that SFI >=20 > I think the biggest discrepancy to reality is apparently the last bullet.= In my > model, SFF to SFI associations are explicit (i.e., configured or communic= ated via c- > plane). I would be obliged if you could enumerate how far off I am so I= can > consider the implications and consequences. >=20 > Thanks. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Friday, November 11, 2016 3:25 PM > To: Jim Guichard (jguichar) ; Ron Parker=20 > ; Dave Dolson ;=20 > adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > sfc@ietf.org > Subject: Re: [sfc] Re: decrementing service function path index >=20 > Jim> Well unless I am missing something SFF2 in this example will=20 > Jim> never > see the NSH as SFF1 will tunnel the packet directly to SF1-2 using=20 > whatever transport is in play. >=20 > That is exactly my point; for this sort of load balancing to work with=20 > NSH as it is, one needs to have a transport tunnel from each SFF to=20 > each remote SFI that the SFF may select as the next hop in a service path= . > This means that for every type of transport that might be "in play",=20 > you have to figure out what to put in the transport header in order to id= entify a particular SFI. >=20 > The fact that the transport tunnels connect SFFs to SFIs rather than=20 > connecting SFFs to each other is something that I don't think is=20 > apparent from the documents or from some of the recent threads on the mai= ling list. >=20 > (Luckily, draft-mackie-bess-nsh-bgp-control-plane handles this well,=20 > because it provides encapsulation information on a per-SFI basis.) >=20 > Ron> Do you think that an SFF could/should discern this by examining > the source IP of the packet it receives, or do you think we need some=20 > sort of "source id" in the NSH base header, itself >=20 > If we wanted to require that transport tunnels only go between SFFs, I=20 > think it would be sufficient just to have a flag in the NSH that means=20 > "the load balancing decision has already been made". I don't think a sou= rce id is needed. >=20 > But I'm not proposing changes to NSH, just exploring the ramifications=20 > of some of the existing design decisions. >=20 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Nov 12 18:57:32 2016 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 9F6A812946F for ; Sat, 12 Nov 2016 18:57:30 -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 eQs4aER1x_Xs for ; Sat, 12 Nov 2016 18:57:28 -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 6D3511295EF for ; Sat, 12 Nov 2016 18:57:28 -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 uAD2vL2Y032304; Sun, 13 Nov 2016 02:57:21 GMT Received: from 950129200 (dhcp-8717.meeting.ietf.org [31.133.135.23]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAD2vFeE032280 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 13 Nov 2016 02:57:18 GMT From: "Adrian Farrel" To: "'Surendra Kumar \(smkumar\)'" , "'Ron Parker'" , "'Eric C Rosen'" , "'Jim Guichard \(jguichar\)'" , "'Dave Dolson'" , "'Joel M. Halpern'" , References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> <0dea01d23d31$42821980$c7864c80$@olddog.co.uk> In-Reply-To: Date: Sun, 13 Nov 2016 02:57:15 -0000 Message-ID: <0ea801d23d59$a6ff5260$f4fdf720$@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: AQIgrbss3hc6CKL2djyaMboulKyfnQG7Sgr8AXzjmREBJLKr8wNKeon+AeVOae4Bj9QfJAIRFMC1AoOscBQCIVFnCQMBLfNyALtFTFoCljrZFQBxG0CRn3SkbkA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22696.004 X-TM-AS-Result: No--26.215-10.0-31-10 X-imss-scan-details: No--26.215-10.0-31-10 X-TMASE-MatchedRID: nI1cAR4k0HZCl9DEsHnSbVVN8laWo90Mt3aeg7g/usAutoY2UtFqGFdV hcU0C7v4vowMh0QPYODwx43j/HRRr2yYPUbeObe2SEQN/D/3cG74uJ1REX4MHQCGaccd4ae9AiS +/fhiPFaFqhjQIAAvft/mwzNqfNY5b3gilrWi3Ghff2PxVyknEb4kZYg1dp8sy+N+FbWCyaFKJA /HeCVx7+HT3LWl/fX9PpGyHSnX9XgfLCnwVCuCFZpWgCLYjjT9oAVkVRxtvpEXzqHaBURjrD5Wt phTUNF+yD7iRZkG1t5yKzLF6OyLjkDAEmiOG36B5cQFbdjxan5dxx6WRf+5sIKwF4K/wIz9umlL C5g94HsuJAplSQtK7DErTqsLOUIIbwXKHRG/axWr17gY+g3e8afiiqQQMd1G5DJ1FS+XdBMQ2iW GCBc44SEFwAW8/k7ufclpT8AuTw3PQ3bSPt1JA01Wvi92YKnOGWAN/II9wcTQcN485+Hvhr1qj7 fHwtzGzLaR/NpnmKS68ojoRbcOaSaJdRfH0U3lnbUZkYTzXIb2nQ8y51KMpRHfiujuTbed82+ZJ oKeNOW36h2hK5rvdpGTpe1iiCJqtD9qpBlNF8ov7bm8B5Akl/oA9r2LThYYKrauXd3MZDUD/dHy T/Xh7Q== Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 13 Nov 2016 02:57:30 -0000 That makes it simpler, but is it simple enough? If an SFI is front-ended by different SFFs on different SFPs, does the SFI have to understand the SPI and "route" back to the correct SFF? I thought that was function we were trying to keep out of the SF. Adrian > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: 13 November 2016 02:47 > To: adrian@olddog.co.uk; 'Ron Parker'; 'Eric C Rosen'; Jim Guichard (jguichar); > 'Dave Dolson'; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index > > > Isn't that programmed by the control plane as part of laying out the SFP ? > IOW, for a given SFP, there is one (and only one) anchor SFF for each SFI, to keep > the implementation simpler. Otherwise, I tend to agree with the assessment on > complexities: asymmetric forwarding and problematic to state-full SFFs, etc. > > Surendra. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Saturday, November 12, 2016 2:08 PM > To: 'Ron Parker' ; 'Eric C Rosen' > ; Jim Guichard (jguichar) ; 'Dave > Dolson' ; 'Joel M. Halpern' ; > sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index > > Ron, I find myself agreeing with most of your "incomplete or incorrect" model. > > But I wonder.... > > If an SFI is connected (by tunnels or otherwise) to more than one SFF (i.e., the SFI > is front-ended by more than one SFF), how does it decide through which > connection to return a packet that it has processed? The decision could be as > simple as to assume bidirectional tunnels and send each packet back through the > same tunnel on which it was received maintaining a little per packet state in the > SF, or could be as complex as making a forwarding decision based on some > knowledge of the SFP. It could require inspection of the NSH or could be the > product of load balancing. > > Now, before the howling grows to severe :-) this suggests to me that connecting > an SFI to multiple SFFs might be unwise. > > Adrian > > > -----Original Message----- > > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > Sent: 11 November 2016 21:19 > > To: Eric C Rosen; Jim Guichard (jguichar); Dave Dolson; > > adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] Re: decrementing service function path index > > > > Eric, you raise an excellent point about transport tunnels. Here is my > apparently > > incomplete or incorrect mental model: > > > > * SFF's have direct or tunneled connectivity to the SFI's that they "front-end" > > * SFF's have direct or tunneled connectivity to other SFF's > > * SFI's MAY have direct or tunneled connectivity to multiple SFF's > > * in this case, in my mental model, each of those SFF's > > simultaneously "front- ends" the shared SFIs > > * When an SFF needs to forward to an SFI that it doesn't front-end, it > > progresses the packet to the SFF that does front-end that SFI > > > > I think the biggest discrepancy to reality is apparently the last bullet. In my > > model, SFF to SFI associations are explicit (i.e., configured or communicated via > c- > > plane). I would be obliged if you could enumerate how far off I am so I can > > consider the implications and consequences. > > > > Thanks. > > > > Ron > > > > > > -----Original Message----- > > From: Eric C Rosen [mailto:erosen@juniper.net] > > Sent: Friday, November 11, 2016 3:25 PM > > To: Jim Guichard (jguichar) ; Ron Parker > > ; Dave Dolson > ; > > adrian@olddog.co.uk; 'Joel M. Halpern' ; > > sfc@ietf.org > > Subject: Re: [sfc] Re: decrementing service function path index > > > > Jim> Well unless I am missing something SFF2 in this example will > > Jim> never > > see the NSH as SFF1 will tunnel the packet directly to SF1-2 using > > whatever transport is in play. > > > > That is exactly my point; for this sort of load balancing to work with > > NSH as it is, one needs to have a transport tunnel from each SFF to > > each remote SFI that the SFF may select as the next hop in a service path. > > This means that for every type of transport that might be "in play", > > you have to figure out what to put in the transport header in order to identify a > particular SFI. > > > > The fact that the transport tunnels connect SFFs to SFIs rather than > > connecting SFFs to each other is something that I don't think is > > apparent from the documents or from some of the recent threads on the > mailing list. > > > > (Luckily, draft-mackie-bess-nsh-bgp-control-plane handles this well, > > because it provides encapsulation information on a per-SFI basis.) > > > > Ron> Do you think that an SFF could/should discern this by examining > > the source IP of the packet it receives, or do you think we need some > > sort of "source id" in the NSH base header, itself > > > > If we wanted to require that transport tunnels only go between SFFs, I > > think it would be sufficient just to have a flag in the NSH that means > > "the load balancing decision has already been made". I don't think a source id is > needed. > > > > But I'm not proposing changes to NSH, just exploring the ramifications > > of some of the existing design decisions. > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Nov 12 20:12:01 2016 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 E90FA129638 for ; Sat, 12 Nov 2016 20:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 WGOQdEYHVsJZ for ; Sat, 12 Nov 2016 20:11:56 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9EA129664 for ; Sat, 12 Nov 2016 20:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7141; q=dns/txt; s=iport; t=1479010313; x=1480219913; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gDFalXxip3rVpUbQjkc5/B1CWNefV27CkCPkd3/RngM=; b=C9yQuJFiiyd7dK9YSa4cXln3iHpo/XGFGUauZFBXxJq6hXjSlMnr9BP+ bZ8KHo8GhMagQzeb1ehrpvDxisptlQjiLoa6ocSTaQFDBU1SEmJUgo8Zr X77V/3zC5b2rIdEjehxZdFO428PbLL4UOuWwTYV0mRsrgFpisTWFGBQXW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgBv5ydY/5NdJa1SChoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYMxAQEBAQEfWIEAB403lwmUYIIHHQuCNYNGAoIMPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRhAQEBBAEBASQTNBcEAgEIEQQBAR8JBycLFAkIAgQBEgiIWQ6wfD2LQwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARcFixaEIC8xhSkFlFmFaAGJSYcMkCeNRIQJAR4?= =?us-ascii?q?3gQMchRpyhnyBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,482,1473120000"; d="scan'208";a="170563814" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2016 04:11:52 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uAD4BqaT009227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 13 Nov 2016 04:11:52 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 12 Nov 2016 22:11:51 -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; Sat, 12 Nov 2016 22:11:52 -0600 From: "Surendra Kumar (smkumar)" To: "adrian@olddog.co.uk" , "'Ron Parker'" , "'Eric C Rosen'" , "Jim Guichard (jguichar)" , "'Dave Dolson'" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSPFm5obKOLlhBikWOxkebyzPtc6DUrkMAgAGgHYD//9iz4IAAeBWA//+o2QA= Date: Sun, 13 Nov 2016 04:11:51 +0000 Message-ID: <6562cad548c4438c8a5e7af43419364d@XCH-RCD-020.cisco.com> References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> <0dea01d23d31$42821980$c7864c80$@olddog.co.uk> <0ea801d23d59$a6ff5260$f4fdf720$@olddog.co.uk> In-Reply-To: <0ea801d23d59$a6ff5260$f4fdf720$@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.24.8.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 13 Nov 2016 04:12:00 -0000 Ah, I was speaking of CP choosing SFFs for an . Obviously, yes, CP and SF touch points are a problem as has been discussed = many times. Add this to the list of those problems, in programming the SF. There are two approaches to forwarding: 1. CF -> SF1 -> SF2 -> SF3: with only SF managed 2. CF -> SFFx(SF1) -> SFFy(SF2) -> SFFz (SF3) : with only SFF managed #1 is the "dumb" forwarders, over the top approach - inefficiencies are obv= ious. What is mandated is something in between, which is unnecessary and adds abs= olutely no value. Surendra. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Saturday, November 12, 2016 6:57 PM To: Surendra Kumar (smkumar) ; 'Ron Parker' ; 'Eric C Rosen' ; Jim Guichard (j= guichar) ; 'Dave Dolson' ; 'Joel = M. Halpern' ; sfc@ietf.org Subject: Re: [sfc] decrementing service function path index That makes it simpler, but is it simple enough? If an SFI is front-ended by different SFFs on different SFPs, does the SFI = have to understand the SPI and "route" back to the correct SFF? I thought that was function we were trying to keep out of the SF. Adrian > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: 13 November 2016 02:47 > To: adrian@olddog.co.uk; 'Ron Parker'; 'Eric C Rosen'; Jim Guichard (jguichar); > 'Dave Dolson'; 'Joel M. Halpern'; sfc@ietf.org > Subject: RE: [sfc] decrementing service function path index >=20 >=20 > Isn't that programmed by the control plane as part of laying out the SFP = ? > IOW, for a given SFP, there is one (and only one) anchor SFF for each=20 > SFI, to keep > the implementation simpler. Otherwise, I tend to agree with the=20 > assessment on > complexities: asymmetric forwarding and problematic to state-full SFFs, e= tc. >=20 > Surendra. >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Saturday, November 12, 2016 2:08 PM > To: 'Ron Parker' ; 'Eric C Rosen' > ; Jim Guichard (jguichar) ;=20 > 'Dave Dolson' ; 'Joel M. Halpern'=20 > ; sfc@ietf.org > Subject: Re: [sfc] decrementing service function path index >=20 > Ron, I find myself agreeing with most of your "incomplete or incorrect" m= odel. >=20 > But I wonder.... >=20 > If an SFI is connected (by tunnels or otherwise) to more than one SFF=20 > (i.e., the SFI > is front-ended by more than one SFF), how does it decide through which=20 > connection to return a packet that it has processed? The decision=20 > could be as simple as to assume bidirectional tunnels and send each=20 > packet back through the > same tunnel on which it was received maintaining a little per packet=20 > state in the > SF, or could be as complex as making a forwarding decision based on=20 > some knowledge of the SFP. It could require inspection of the NSH or=20 > could be the product of load balancing. >=20 > Now, before the howling grows to severe :-) this suggests to me that connecting > an SFI to multiple SFFs might be unwise. >=20 > Adrian >=20 > > -----Original Message----- > > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > Sent: 11 November 2016 21:19 > > To: Eric C Rosen; Jim Guichard (jguichar); Dave Dolson;=20 > > adrian@olddog.co.uk; 'Joel M. Halpern'; sfc@ietf.org > > Subject: RE: [sfc] Re: decrementing service function path index > > > > Eric, you raise an excellent point about transport tunnels. Here is= my > apparently > > incomplete or incorrect mental model: > > > > * SFF's have direct or tunneled connectivity to the SFI's that they "front-end" > > * SFF's have direct or tunneled connectivity to other SFF's > > * SFI's MAY have direct or tunneled connectivity to multiple SFF's > > * in this case, in my mental model, each of those SFF's=20 > > simultaneously "front- ends" the shared SFIs > > * When an SFF needs to forward to an SFI that it doesn't front-end,=20 > > it progresses the packet to the SFF that does front-end that SFI > > > > I think the biggest discrepancy to reality is apparently the last bulle= t. In my > > model, SFF to SFI associations are explicit (i.e., configured or communicated via > c- > > plane). I would be obliged if you could enumerate how far off I am so= I can > > consider the implications and consequences. > > > > Thanks. > > > > Ron > > > > > > -----Original Message----- > > From: Eric C Rosen [mailto:erosen@juniper.net] > > Sent: Friday, November 11, 2016 3:25 PM > > To: Jim Guichard (jguichar) ; Ron Parker=20 > > ; Dave Dolson > ; > > adrian@olddog.co.uk; 'Joel M. Halpern' ;=20 > > sfc@ietf.org > > Subject: Re: [sfc] Re: decrementing service function path index > > > > Jim> Well unless I am missing something SFF2 in this example will=20 > > Jim> never > > see the NSH as SFF1 will tunnel the packet directly to SF1-2 using=20 > > whatever transport is in play. > > > > That is exactly my point; for this sort of load balancing to work=20 > > with NSH as it is, one needs to have a transport tunnel from each=20 > > SFF to each remote SFI that the SFF may select as the next hop in a ser= vice path. > > This means that for every type of transport that might be "in play",=20 > > you have to figure out what to put in the transport header in order=20 > > to identify a > particular SFI. > > > > The fact that the transport tunnels connect SFFs to SFIs rather than=20 > > connecting SFFs to each other is something that I don't think is=20 > > apparent from the documents or from some of the recent threads on=20 > > the > mailing list. > > > > (Luckily, draft-mackie-bess-nsh-bgp-control-plane handles this well,=20 > > because it provides encapsulation information on a per-SFI basis.) > > > > Ron> Do you think that an SFF could/should discern this by=20 > > Ron> examining > > the source IP of the packet it receives, or do you think we need=20 > > some sort of "source id" in the NSH base header, itself > > > > If we wanted to require that transport tunnels only go between SFFs,=20 > > I think it would be sufficient just to have a flag in the NSH that=20 > > means "the load balancing decision has already been made". I don't=20 > > think a source id is > needed. > > > > But I'm not proposing changes to NSH, just exploring the=20 > > ramifications of some of the existing design decisions. > > >=20 >=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 Sun Nov 13 01:48:37 2016 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 F28281294FE; Sun, 13 Nov 2016 01:48:35 -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 QFw9nKCAXPKu; Sun, 13 Nov 2016 01:48:35 -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 1D7341294AD; Sun, 13 Nov 2016 01:48:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0E14B240DBB; Sun, 13 Nov 2016 01:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479030515; bh=50IisZJnyKAcsJrEqVo3fn40+xVqwOhOVWt13MTl9Uk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=j5tPIZ3TrOTTMUnWG8DOuYYJ2U3JKTsTMBKu6njVr6kBzTtWmpeeJu3N7bo53KTzC Kozuau8/1X9Zg+kcXrxOBt9VwUScsd/XzV0PGW41x1iE3wRWRjm+Tj/mvFEeyAZY7t LjqPFXQJnqMaVMNZIX65CgrVoEF0iwv+QN8CxS2s= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-93c0.meeting.ietf.org (dhcp-93c0.meeting.ietf.org [31.133.147.192]) (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 3EF44240144; Sun, 13 Nov 2016 01:48:34 -0800 (PST) To: adrian@olddog.co.uk, sfc@ietf.org References: <0df601d23d34$b30aaa20$191ffe60$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Sun, 13 Nov 2016 04:48:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0df601d23d34$b30aaa20$191ffe60$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: bess@ietf.org Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work 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, 13 Nov 2016 09:48:36 -0000 Fair enough. In this case, what I was refering to is the combination of two preorpties of the encoding of paths. On teh one hand, it is extraordinarily flexible in being able to represent a broad range of delegated choices (as well as allowing the controller to advertise very specific things. At the same time, it has no explanations for which ways of using those tools will or will not work, are intended to work, or should not be used. One example is the quesiton i raised on the list is an SFP with two SFF each of which has two different SF types, A and B. That seems like a natural thing to do, given the coding. It is extremely unlikely to produce a desirable result in reality. There is significant value in a flexible represent. There is also significant danger if the users can not figure out what will and will not work. Or if they can not tell if the necessary external properties can be met. Yours, Joel On 11/12/16 5:32 PM, Adrian Farrel wrote: > Joel said... > >> One of my concerns with the proposed BGP encoding is that it can represent >> many things that will not work. This seems to make it fragile. > > Joel, if I may, can I call you out on that generalisation? > > I don't find anything in your statement that I can discuss or debate. Perhaps you could help with an example of what thing you might encode that "will not work". > > Thanks, > Adrian > > PS I have cross-posted this mail to SFC and BESS as requested by the AD > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > From nobody Sun Nov 13 04:56:41 2016 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 EF7E8128B38 for ; Sun, 13 Nov 2016 04:56:39 -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 VaDqN5LqKAsD for ; Sun, 13 Nov 2016 04:56:38 -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 D9190127A90 for ; Sun, 13 Nov 2016 04:56:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CB9BA240DBB for ; Sun, 13 Nov 2016 04:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479041798; bh=Lv0Vpq3wKCSWy1Ik1KXi4MSMks6T54k4nyVvmcZmeTQ=; h=To:From:Subject:Date:From; b=LUGtplBMR+nYn16UmSRTQRjGeFF64ZGYxxfHIAkt3ZeJWVW5VqHGbkJ/yfTjBI1x9 HiFad70wOohS58V9fuZFETgKCyF8OrgvU74ztQ6aeRw+t5cO9jSN1r7jlg4kNGB0aV hjuhHDo0pz2QpzlILXhvTRs2cl7rC7qJhQ3WWcqU= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-93c0.meeting.ietf.org (dhcp-93c0.meeting.ietf.org [31.133.147.192]) (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 5458D240DB7 for ; Sun, 13 Nov 2016 04:56:38 -0800 (PST) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Sun, 13 Nov 2016 07:56:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] RTG OOAM DT status 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, 13 Nov 2016 12:56:40 -0000 The OAM design team is presenting their current status to the NVO3 and RTGWG sessions. Due to lack of time, they will not be presenting to SFC. The NVO3 slides can be found at https://datatracker.ietf.org/meeting/97/session/nvo3 Please do look at the slides, and if you have questions either ask on the list or go to one of the sessions where they will be presenting. Thank you, Joel From nobody Sun Nov 13 07:15:45 2016 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 E4EB5129675; Sun, 13 Nov 2016 07:15: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 0Hn5VXVPa2ve; Sun, 13 Nov 2016 07:15:41 -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 7557912955B; Sun, 13 Nov 2016 07:15:41 -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 uADFFdEi020157; Sun, 13 Nov 2016 15:15:39 GMT Received: from 950129200 ([58.120.104.2]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uADFFZHP020143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 13 Nov 2016 15:15:37 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: <0df601d23d34$b30aaa20$191ffe60$@olddog.co.uk> In-Reply-To: Date: Sun, 13 Nov 2016 15:15:34 -0000 Message-ID: <100b01d23dc0$ca9cbb10$5fd63130$@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: AQIERaviNwI8ZmZzRZpO6OqYuyC+7gIGeYDfoGKt+sA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22698.000 X-TM-AS-Result: No--25.985-10.0-31-10 X-imss-scan-details: No--25.985-10.0-31-10 X-TMASE-MatchedRID: TmlY9+XBoTnYfPOPCpnfAirlEE4jXe2UZdKh+/+x0Y6tj24Xqh0yXKF6 09GrmC7th41p4lzSNF/hVzYQMdzSdcwdQieqpnTaDwE3qnU/QTMQtuqs6BbPJwDqzaYhcjeQQ3V KD88yS8rSWpwKkD4fnQFjnZyRyQbkwrxsKoa/qe1ZluvuHEedhD8V4lh/3DF1fKvJLWOzfdDCX0 YsfK3COugdMXcgdbway0R2TzRAIA1m8SPGyjDNlbSw7varainhQvKiQ/1oohHadW4iYSMjUXAWu ORm0TIa7rYjKjSGs+18GgLoi0uCEhipbBBoU1Dtq32frrMnhEhk5GAa7kpXtw2G3vz8l/IEzhaO PCcV6YsyyOWBZC/udDeT288mssTUuJqllQ6sW7QD2WXLXdz+AVHB9PagRph0RJWmeOMHa+Svl7i J0qRezz+MHIPcs+ZxemcXt3vLEIsmH44HB04abVEp96PnqFJskk5xcxBziMER34ro7k23nfNvmS aCnjTlt+odoSua73aRk6XtYogiarQ/aqQZTRfKVnRXm1iHN1bEQdG7H66TyOk/y0w7JiZo Archived-At: Cc: bess@ietf.org Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work 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, 13 Nov 2016 15:15:44 -0000 I agree that there are risks associated with allowing configuration of options. Indeed, control of traffic paths from intelligence outside the network is a danger. However, we allow that and some operators even use it. True, those with fat fingers or buggy software may inadvertently send data down the wrong path, create loops, or black-hole traffic. But if we were to suggest that it should not be possible for control of paths to be applied from outside the network, then we might find ourselves in trouble. Similarly, however, we also consider the application of choice from within the network to be useful. Consider, for example, the loose hop in a traffic engineered path. It is clear that a choice exists, but we don't specify how a node that expands a loose hop works out what path to use: it's a policy choice how the loose hop is expanded. Now, in the specific case, suppose I conceive three different load balancers. They all do load balancing, but they do it differently. Let's assign them different service function types so we can distinguish them. Now let's assume that we really don't want to use one of them in our service function path, but that we are happy to see any instance of a function of either of the other types on the path. See what we can do with our proposal? But I suspect your concern is slightly more complex. I think you may be worried about how additional information to inform a choice might be passed to an SFF. I think that, just as in the traffic routing case, there are many ways to answer the question. But the simplest case is choosing between an allowed set of SFIs using the local policy for balancing SF load. Hope this helps, Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 13 November 2016 09:49 > To: adrian@olddog.co.uk; sfc@ietf.org > Cc: bess@ietf.org > Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work > > Fair enough. > > In this case, what I was refering to is the combination of two > preorpties of the encoding of paths. > On teh one hand, it is extraordinarily flexible in being able to > represent a broad range of delegated choices (as well as allowing the > controller to advertise very specific things. > At the same time, it has no explanations for which ways of using those > tools will or will not work, are intended to work, or should not be used. > One example is the quesiton i raised on the list is an SFP with two SFF > each of which has two different SF types, A and B. That seems like a > natural thing to do, given the coding. It is extremely unlikely to > produce a desirable result in reality. > > There is significant value in a flexible represent. There is also > significant danger if the users can not figure out what will and will > not work. Or if they can not tell if the necessary external properties > can be met. > > Yours, > Joel > > On 11/12/16 5:32 PM, Adrian Farrel wrote: > > Joel said... > > > >> One of my concerns with the proposed BGP encoding is that it can represent > >> many things that will not work. This seems to make it fragile. > > > > Joel, if I may, can I call you out on that generalisation? > > > > I don't find anything in your statement that I can discuss or debate. Perhaps you > could help with an example of what thing you might encode that "will not work". > > > > Thanks, > > Adrian > > > > PS I have cross-posted this mail to SFC and BESS as requested by the AD > > > > _______________________________________________ > > BESS mailing list > > BESS@ietf.org > > https://www.ietf.org/mailman/listinfo/bess > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Nov 13 08:00:26 2016 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 E023912956A; Sun, 13 Nov 2016 08:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 yS902POp7KYc; Sun, 13 Nov 2016 08:00:19 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311D312954F; Sun, 13 Nov 2016 08:00:19 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0319.002; Sun, 13 Nov 2016 08:00:18 -0800 From: Ron Parker To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] [bess] BGP/SFC encoding of things that will not work Thread-Index: AQHSPZMcR4zL80381UuYqwJuxIlM/qDXjIUA//+DpdA= Date: Sun, 13 Nov 2016 16:00:17 +0000 Message-ID: References: <0df601d23d34$b30aaa20$191ffe60$@olddog.co.uk> <100b01d23dc0$ca9cbb10$5fd63130$@olddog.co.uk> In-Reply-To: <100b01d23dc0$ca9cbb10$5fd63130$@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "bess@ietf.org" Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work 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, 13 Nov 2016 16:00:21 -0000 This was the very reason we introduced the concept of RSP. Perhaps the va= lue wasn't recognized so well at the time because we were wrestling with ot= her issues. But, IMO, RSP was always about the ability to have "loose hop= s" as Adrian describes. And, as Adrian describes, the option to build and= deploy a network that runs somewhat autonomously (like dynamic IP routing)= as well as still allowing for a network that is more strictly controlled f= rom an external entity, like the way we often describe SDN. Both are vali= d, but the former requires this "loose hop" "late binding" type of instance= selection capability. At one point, it was suggested by someone on the thread that the actual res= ulting RSP could be stamped into a type 2 TLV. Such an encoding would lik= ely require not just a sequence of SFI's, but a sequence of {SFF, SFI} to h= andle the multi-homed SFI case. It could be very useful for troubleshoot= ing and service assurance, too. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, November 13, 2016 10:16 AM To: 'Joel M. Halpern' ; sfc@ietf.org Cc: bess@ietf.org Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work I agree that there are risks associated with allowing configuration of opti= ons.=20 Indeed, control of traffic paths from intelligence outside the network is a= danger. However, we allow that and some operators even use it. True, those= with fat fingers or buggy software may inadvertently send data down the wr= ong path, create loops, or black-hole traffic. But if we were to suggest th= at it should not be possible for control of paths to be applied from outsid= e the network, then we might find ourselves in trouble. Similarly, however, we also consider the application of choice from within = the network to be useful. Consider, for example, the loose hop in a traffic= engineered path. It is clear that a choice exists, but we don't specify ho= w a node that expands a loose hop works out what path to use: it's a policy= choice how the loose hop is expanded. Now, in the specific case, suppose I conceive three different load balancer= s. They all do load balancing, but they do it differently. Let's assign them d= ifferent service function types so we can distinguish them. Now let's assum= e that we really don't want to use one of them in our service function path= , but that we are happy to see any instance of a function of either of the = other types on the path. See what we can do with our proposal? But I suspect your concern is slightly more complex. I think you may be wor= ried about how additional information to inform a choice might be passed to= an SFF. I think that, just as in the traffic routing case, there are many = ways to answer the question. But the simplest case is choosing between an a= llowed set of SFIs using the local policy for balancing SF load.=20 Hope this helps, Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 13 November 2016 09:49 > To: adrian@olddog.co.uk; sfc@ietf.org > Cc: bess@ietf.org > Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not=20 > work >=20 > Fair enough. >=20 > In this case, what I was refering to is the combination of two=20 > preorpties of the encoding of paths. > On teh one hand, it is extraordinarily flexible in being able to=20 > represent a broad range of delegated choices (as well as allowing the=20 > controller to advertise very specific things. > At the same time, it has no explanations for which ways of using those=20 > tools will or will not work, are intended to work, or should not be used. > One example is the quesiton i raised on the list is an SFP with two=20 > SFF each of which has two different SF types, A and B. That seems=20 > like a natural thing to do, given the coding. It is extremely=20 > unlikely to produce a desirable result in reality. >=20 > There is significant value in a flexible represent. There is also=20 > significant danger if the users can not figure out what will and will=20 > not work. Or if they can not tell if the necessary external=20 > properties can be met. >=20 > Yours, > Joel >=20 > On 11/12/16 5:32 PM, Adrian Farrel wrote: > > Joel said... > > > >> One of my concerns with the proposed BGP encoding is that it can=20 > >> represent many things that will not work. This seems to make it fragi= le. > > > > Joel, if I may, can I call you out on that generalisation? > > > > I don't find anything in your statement that I can discuss or debate. Perhaps you > could help with an example of what thing you might encode that "will=20 > not work". > > > > Thanks, > > Adrian > > > > PS I have cross-posted this mail to SFC and BESS as requested by the=20 > > AD > > > > _______________________________________________ > > BESS mailing list > > BESS@ietf.org > > https://www.ietf.org/mailman/listinfo/bess > > >=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 Sun Nov 13 13:23:02 2016 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 6980612964F for ; Sun, 13 Nov 2016 13:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Ui_o40lMsICU for ; Sun, 13 Nov 2016 13:22:58 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 62D85129653 for ; Sun, 13 Nov 2016 13:22:57 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id n6so37673554qtd.1 for ; Sun, 13 Nov 2016 13:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xkv+h0MrU/gCsGDuAxvL0/St03n0a6+AsCsjEAf8qSQ=; b=ZN+FIiilvOQroV6hE8XAFFYxQlnp73++EFCT4CNmIPu8MvRhI6xvelpxFbd3lBk6Ei BOA+xKT8GCpF39hFMUfyO/+6PHcAbuXW5EoWGWwa5MlfIIFoZKkVeLypB5JgpDmUyvYR 4iv27We7y0H41gwN9kPqlM6Mb4TC0yISAT8MTS8sJCkwwJWVfm1dp5IHIQDYTTNkmRlr 6dNGW9waRRBGRZe8fkigL2OYhJT2h4FsLCeZLnBq6luqmKn/VLH3A14BYzxWiZ2gZTeJ +PX+6SiWDHUB6OUJ1Rxt4SnDhv8NhGzV9voNN+7pok6z6GiEOyO9Tmk7v7uiuJT8V7yN oIpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xkv+h0MrU/gCsGDuAxvL0/St03n0a6+AsCsjEAf8qSQ=; b=XCJwr05uDA5Uh8i3xr+SSajiZN+MKjBJKHVOy3sLJycWQGlHeFV5vLkhtH1mUqoTCP xWpyOZlGqw6rnB+qc3BnsD/joazrOoCv0zKO5EFd6hQ0GW8j1iJiPdnYkVIXDoXhB5gR I7nXquCf4P+pocTa40GHZMnn2HN0kDM6kfVvuHNVZBDTnx+7yNwbHSpfJ5CYTS24yM3P CFJ/QHUFeZ+xxru/N/AAkRW0huep5eTAcmem2mFGbksK0uACVukioZbTkuYEQGWr7I3l uin1716LqAbB8dCCABu25L9UtfCNJx/ndB0Mz5yVMYFBxkN+JUK+rVbwjVFQuLSt/MCi cB1w== X-Gm-Message-State: ABUngveZEEDmK4WVXYpffClErqlt14JlVhKGojrq0i0rYcGyVcF1YhiUZkJ1p25uzdUZpbGVF3hbex7bXn5I3A== X-Received: by 10.200.44.196 with SMTP id 4mr5220423qtx.262.1479072176596; Sun, 13 Nov 2016 13:22:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.34.228 with HTTP; Sun, 13 Nov 2016 13:22:55 -0800 (PST) Received: by 10.200.34.228 with HTTP; Sun, 13 Nov 2016 13:22:55 -0800 (PST) In-Reply-To: References: From: Alia Atlas Date: Sun, 13 Nov 2016 16:22:55 -0500 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11357024aeee370541355313 Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] RTG OOAM DT status 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, 13 Nov 2016 21:23:01 -0000 --001a11357024aeee370541355313 Content-Type: text/plain; charset=UTF-8 I would like to clarify that the OOAM design team was closed during IETF 96. These drafts are work that was done & individuals continue to work on them. The work is relevant for multiple working groups. We try to avoid spending agenda time in multuple WGs repeatedly. Regards Alia On Nov 13, 2016 9:56 PM, "Joel M. Halpern" wrote: > The OAM design team is presenting their current status to the NVO3 and > RTGWG sessions. > Due to lack of time, they will not be presenting to SFC. > The NVO3 slides can be found at https://datatracker.ietf.org/m > eeting/97/session/nvo3 > > Please do look at the slides, and if you have questions either ask on the > list or go to one of the sessions where they will be presenting. > > Thank you, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a11357024aeee370541355313 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would like to clarify that the OOAM design team was closed= during IETF 96.
These drafts are work that was done & individuals continue to work on t= hem.
The work is relevant for multiple working groups.=C2=A0 We try to avoid spe= nding agenda time in multuple WGs repeatedly.

Regards
Alia


On Nov 13, 2016 9= :56 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:
The OAM design team is presenting their current status t= o the NVO3 and RTGWG sessions.
Due to lack of time, they will not be presenting to SFC.
The NVO3 slides can be found at https://datatrac= ker.ietf.org/meeting/97/session/nvo3

Please do look at the slides, and if you have questions either ask on the l= ist or go to one of the sessions where they will be presenting.

Thank you,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--001a11357024aeee370541355313-- From nobody Sun Nov 13 14:10:43 2016 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 E5FE11294A7; Sun, 13 Nov 2016 14:10:41 -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 QTtBJq5p5aYg; Sun, 13 Nov 2016 14:10:40 -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 602691293D6; Sun, 13 Nov 2016 14:10:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5274C240DB1; Sun, 13 Nov 2016 14:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479075040; bh=RXHvonKB6pxTq90TrxLw3UgeYY3nWXVEWvXyiz/QRng=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=j/dzdLLKztC0DENlFXGzol01i0w0AK+XPlM5FOm9q1GrWAeDExReZA1tQhxCmgZ8s uKBkvqhJUrncNZN5ZSc53ypBNXCm7wl1tl83qtENJ6ignHVOlqDU7HeG2X4gGkZIQW zjxSEvr9p3dZtb7lFn4G7mknx2CrXg7PhxgYkT80= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-93c0.meeting.ietf.org (dhcp-93c0.meeting.ietf.org [31.133.147.192]) (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 65DB4240144; Sun, 13 Nov 2016 14:10:39 -0800 (PST) To: adrian@olddog.co.uk, sfc@ietf.org References: <0df601d23d34$b30aaa20$191ffe60$@olddog.co.uk> <100b01d23dc0$ca9cbb10$5fd63130$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Sun, 13 Nov 2016 17:10:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <100b01d23dc0$ca9cbb10$5fd63130$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: bess@ietf.org Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work 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, 13 Nov 2016 22:10:42 -0000 In regard to this particular aspect of the proposal, my concern would be significantly alleviated if the text said that different service3 function types could be used in a choice only when they were interchangeable / equivalent for the purposes of the service function path. While there still would be ways to misuse it (that is true of most of our solutions), at least the develoepr and user would understand when it was expected to work. Yours, Joel On 11/13/16 10:15 AM, Adrian Farrel wrote: > I agree that there are risks associated with allowing configuration of options. > > Indeed, control of traffic paths from intelligence outside the network is a > danger. However, we allow that and some operators even use it. True, those with > fat fingers or buggy software may inadvertently send data down the wrong path, > create loops, or black-hole traffic. But if we were to suggest that it should > not be possible for control of paths to be applied from outside the network, > then we might find ourselves in trouble. > > Similarly, however, we also consider the application of choice from within the > network to be useful. Consider, for example, the loose hop in a traffic > engineered path. It is clear that a choice exists, but we don't specify how a > node that expands a loose hop works out what path to use: it's a policy choice > how the loose hop is expanded. > > Now, in the specific case, suppose I conceive three different load balancers. > They all do load balancing, but they do it differently. Let's assign them > different service function types so we can distinguish them. Now let's assume > that we really don't want to use one of them in our service function path, but > that we are happy to see any instance of a function of either of the other types > on the path. See what we can do with our proposal? > > But I suspect your concern is slightly more complex. I think you may be worried > about how additional information to inform a choice might be passed to an SFF. I > think that, just as in the traffic routing case, there are many ways to answer > the question. But the simplest case is choosing between an allowed set of SFIs > using the local policy for balancing SF load. > > Hope this helps, > Adrian > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: 13 November 2016 09:49 >> To: adrian@olddog.co.uk; sfc@ietf.org >> Cc: bess@ietf.org >> Subject: Re: [sfc] [bess] BGP/SFC encoding of things that will not work >> >> Fair enough. >> >> In this case, what I was refering to is the combination of two >> preorpties of the encoding of paths. >> On teh one hand, it is extraordinarily flexible in being able to >> represent a broad range of delegated choices (as well as allowing the >> controller to advertise very specific things. >> At the same time, it has no explanations for which ways of using those >> tools will or will not work, are intended to work, or should not be used. >> One example is the quesiton i raised on the list is an SFP with two SFF >> each of which has two different SF types, A and B. That seems like a >> natural thing to do, given the coding. It is extremely unlikely to >> produce a desirable result in reality. >> >> There is significant value in a flexible represent. There is also >> significant danger if the users can not figure out what will and will >> not work. Or if they can not tell if the necessary external properties >> can be met. >> >> Yours, >> Joel >> >> On 11/12/16 5:32 PM, Adrian Farrel wrote: >>> Joel said... >>> >>>> One of my concerns with the proposed BGP encoding is that it can represent >>>> many things that will not work. This seems to make it fragile. >>> >>> Joel, if I may, can I call you out on that generalisation? >>> >>> I don't find anything in your statement that I can discuss or debate. > Perhaps you >> could help with an example of what thing you might encode that "will not > work". >>> >>> Thanks, >>> Adrian >>> >>> PS I have cross-posted this mail to SFC and BESS as requested by the AD >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Sun Nov 13 20:27:21 2016 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 0C0CB129487; Sun, 13 Nov 2016 20:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.696 X-Spam-Level: X-Spam-Status: No, score=-105.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 GKZGMp3Zndo6; Sun, 13 Nov 2016 20:27:16 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 40E111295DD; Sun, 13 Nov 2016 20:27:16 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 58EB23D298175; Mon, 14 Nov 2016 12:27:12 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id uAE4RDNE020028; Mon, 14 Nov 2016 12:27:13 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) Message-Id: <201611140427.uAE4RDNE020028@mse01.zte.com.cn> Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uAB9NQB3038975; Fri, 11 Nov 2016 17:23:26 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <2df5c8d8-ae75-85ac-7940-cd4264a960e8@joelhalpern.com> References: <3C851841-3FC8-430B-93BE-E96C63B8EC55@cisco.com> <9C8B3B99-1938-4B49-844F-C65F53A48725@cisco.com> <2df5c8d8-ae75-85ac-7940-cd4264a960e8@joelhalpern.com> To: "Joel M. Halpern" , "Jim Guichard (jguichar)" MIME-Version: 1.0 X-KeepSent: 42A00DAD:542EC9BE-48258068:003343E1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: wang.cui1@zte.com.cn Date: Fri, 11 Nov 2016 17:23:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-11-11 17:23:26, Serialize complete at 2016-11-11 17:23:26 Content-Type: multipart/alternative; boundary="=_alternative 0033982848258068_=" X-MAIL: mse01.zte.com.cn uAE4RDNE020028 X-MSS: AUDITRELEASE@mse01.zte.com.cn Archived-At: Cc: sfc , "sfc@ietf.org" Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 14 Nov 2016 04:27:19 -0000 This is a multipart message in MIME format. --=_alternative 0033982848258068_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBKb2VsICYgSmltLA0KDQogIFRoYW5rcyBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLg0KICBZ ZXMsIHlvdSBhcmUgcmlnaHQuIGkgbWlzc2VkIHNvbWUgb3RoZXIgY2FzZXMuIEFsbCB0aGVzZSBj YXNlcyBhcmUgDQpzaWRlLWJ5LXNpZGUuIA0KU28gYm90aCB0aGUgZ2VuZXJhbCBhbmQgdGhlIHNw ZWNpZmljIHJlcHJlc2VudGF0aW9uIHNob3VsZCBiZSBhbGxvd2VkLg0KDQogICBIb3dldmVyLCBh cyB0aGVyZSBhcmUgc2xpZ2h0bHkgZGlmZmVyZW50IHVuZGVyc3RhbmRpbmcgYWJvdXQgJ3RoZSAN Cm1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEnLA0KYXJlIHRoZXJlIGFueSBwb3NzaWJsZSB0 byBjbGFyaWZ5IGl0IGluIHRoZSBwcm9wb3NlZCB0ZXh0Pw0KDQpCUnMsDQpMaW5kYSBXYW5nDQoN Cg0KDQoNCiJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiANCreivP7Iyzog ICJzZmMiIDxzZmMtYm91bmNlc0BpZXRmLm9yZz4NCjIwMTYvMTEvMTAgMjM6NDINCg0KytW8/sjL DQoiSmltIEd1aWNoYXJkIChqZ3VpY2hhcikiIDxqZ3VpY2hhckBjaXNjby5jb20+LCAid2FuZy5j dWkxQHp0ZS5jb20uY24iIA0KPHdhbmcuY3VpMUB6dGUuY29tLmNuPiwgDQqzrcvNDQoic2ZjQGll dGYub3JnIiA8c2ZjQGlldGYub3JnPg0K1vfM4g0KUmU6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRm Lm9yZy90cmFjL3NmYy90aWNrZXQvMjENCg0KDQoNCg0KDQoNCihUaGlzIGlzIHRoZSBjYXNlIHdo ZXJlIGV2ZW4gdGhlIGNoYWlycyBtZWFudCBzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdzLCANCnNv IHRoYW5rcyBmb3IgbWFraW5nIHN1cmUgd2UgYXJlIGNsZWFyLikNCg0KUGVyc29uYWxseSwgSSB0 aGluayB0aGF0IHRoZSBtYXBwaW5nIGJldHdlZW4gdmFsdWUgYW5kIG1lYW5pbmcgaXMgZ29pbmcg DQp0byBiZSBoYW5kbGVkIHZpYSBpbmRpcmVjdGlvbi4gIEkgZG8gbm90IHRoaW5rIHRoYXQgdGhl IGNvbnRyb2wgc3lzdGVtIA0Kd2lsbCBldmVyIHNheSB0aGF0IHZhbHVlIDEwMSBtZWFucyAiY29r ZSIuICBSYXRoZXIsIEkgdGhpbmsgdGhhdCB0aGUgDQpjb250cm9sIHN5c3RlbSB3aWxsIHByb3Zp ZGUgZW5vdWdoIGluZm9ybWF0aW9uIHRoYXQgdGhlIFNGIGNhbiBkZXRlcm1pbmUgDQpob3cgdG8g aW50ZXJwcmV0IDEwMS4gIFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgd2hhdCB0aGUgU0YgbmVlZHMg dG8ga25vdyANCmlzIG5vdCAiY29rZSIsIGJ1dCByYXRoZXIgd2hhdCBkYXRhIHNldCBpdCBjYW4g dXNlIHRoZSBnaXZlbiB2YWx1ZSBhcyBhIA0Ka2V5IGludG8sIGFuZCB3aGF0IG1lY2hhbmlzbSAo cHJlLXByb3Zpc2lvbmVkIGRhdGEgc2V0IDMsIHJhZGl1cywgDQpkaWFtZXRlciwgTERBUCwgLi4u KSBpdCBjYW4gdXNlIHRvIGdldCB0aGUgaW5mb3JtYXRpb24gaXQgbmVlZHMgdG8gZG8gDQppdHMg am9iIHVzaW5nIHRoYXQga2V5Lg0KDQpXaGlsZSBmb3Igc29tZSBTRiwgYmVpbmcgdG9sZCAidXNl IERDIGFsbG9jYXRpb24iIHdpbGwgYmUgc3VmZmljaWVudCwgSSANCmV4cGVjdCBpbiBtYW55IGNh c2VzIHRoYXQgd2hhdCB0aGUgU0YgbmVlZHMgdG8gYmUgdG9sZCBpcyB0aGF0IGJ5dGVzIDcgLSAN CjkgYXJlIHRoZSBpbmRleCBpdCBuZWVkcyB0byB1c2UgYXMgdGhlIGtleSBmb3IgZ2V0dGluZyB0 aGUgc3Vic2NyaWJlcnMgDQpjb250ZW50IGZpbHRlcmluZyBwb2xpY3kuICBTbyB3ZSBoYXZlIHRv IGFsbG93IGJvdGggdGhlIGdlbmVyYWwgYW5kIHRoZSANCnNwZWNpZmljIHJlcHJlc2VudGF0aW9u Lg0KDQpZb3VycywNCkpvZWwNCg0KT24gMTEvMTAvMTYgODoxNSBBTSwgSmltIEd1aWNoYXJkIChq Z3VpY2hhcikgd3JvdGU6DQo+IEhpIExpbmRhLA0KPg0KPiBCeSB0aGlzIHdlIG1lYW4gaG93IHRo ZSBTRiBpcyB0byBpbnRlcnByZXQgdGhlIGRhdGEgY2FycmllZCB3aXRoaW4gdGhlDQo+IG1ldGFk YXRhLiBGb3IgZXhhbXBsZSwgdGhlIGFsbG9jYXRpb24gc2NoZW1hIG1pZ2h0IHNheSChsHRlbmFu dC1pZA0KPiBjYXJyaWVkIGF0IG9mZnNldCA8YmxhaD6hraGxIGJ1dCB0aGVuIHRoZSBTRiBuZWVk cyB0byB1bmRlcnN0YW5kIHdoYXQgDQp0aGUNCj4gZXh0cmFjdGVkIHZhbHVlIGZyb20gdGhlIG1l dGFkYXRhIGNvcnJlc3BvbmRzIHRvIGluIHRlcm1zIG9mIHdoaWNoDQo+IHRlbmFudCBlLmcuIHZh bHVlIDEwMSBtaWdodCBtZWFuIKGwY29rZaGxLiChsGNva2WhsSBpbiB0aGlzIGV4YW1wbGUgaXMg DQpub3QNCj4gY2FycmllZCB3aXRoaW4gdGhlIG1ldGFkYXRhIHNvIHRoZSBTRiBuZWVkcyB0byBt YXAgdGhlIHZhbHVlIGZyb20gdGhlDQo+IG1ldGFkYXRhIHRvIGEgbWVhbmluZ2Z1bCB0ZW5hbnQg aWRlbnRpZmljYXRpb24uDQo+DQo+IEhvcGUgdGhpcyBjbGFyaWZpZXMgLi4NCj4NCj4gSmltDQo+ DQo+IEZyb206ICJ3YW5nLmN1aTFAenRlLmNvbS5jbiA8bWFpbHRvOndhbmcuY3VpMUB6dGUuY29t LmNuPiINCj4gPHdhbmcuY3VpMUB6dGUuY29tLmNuIDxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20u Y24+Pg0KPiBEYXRlOiBXZWRuZXNkYXksIE5vdmVtYmVyIDksIDIwMTYgYXQgOTo0NSBQTQ0KPiBU bzogSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb20gPG1haWx0bzpqZ3VpY2hhckBjaXNj by5jb20+Pg0KPiBDYzogInNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNA aWV0Zi5vcmcNCj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+Piwgc2ZjIDxzZmMtYm91bmNlc0BpZXRm Lm9yZw0KPiA8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4NCj4gU3ViamVjdDogUmU6IFtz ZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCj4NCj4gRGVhciBK aW0gJiBKb2VsLA0KPg0KPiAgICBUaGUgdGV4dCBzYWlkOiAndGhlIGRhdGEgc2VtYW50aWNzIGlu Y2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWENCj4gYW5kIHRoZSBtZWFuaW5nIG9mIHRo ZSBpbmNsdWRlZCBkYXRhLicNCj4gICAgSSBhZ3JlZSB3aXRoICd0aGUgYWxsb2NhdGlvbiBzY2hl bWEnIGNhbiBoZWxwIHRoZSBTRkMtYXdhcmUgU0YgdG8NCj4ga25vdyBob3cgdG8gaW50ZXJwcmV0 IHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4gSG93ZXZlciwNCj4gICAgQ291bGQgeW91IGNs YXJpZnkgd2hhdCBpcyAndGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEnIGFuZCBob3cN Cj4gdG8gZGVzY3JpYmUnIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhJz8NCj4NCj4g ICAgVGhhbmtzIHZlcnkgbXVjaCA6KQ0KPg0KPiBCUnMNCj4gTGluZGEgV2FuZw0KPg0KPg0KPg0K Pg0KPg0KPg0KPiAqIkppbSBHdWljaGFyZCAoamd1aWNoYXIpIiA8amd1aWNoYXJAY2lzY28uY29t IDwNCm1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PioNCj4gt6K8/sjLOiAgInNmYyIgPHNmYy1i b3VuY2VzQGlldGYub3JnIDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPg0KPiAyMDE2 LzExLzA5IDAyOjAxDQo+DQo+IA0KPiDK1bz+yMsNCj4gICAgICAgICAgICAgICAgInNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmcgPA0KbWFpbHRvOnNmY0Bp ZXRmLm9yZz4+LA0KPiCzrcvNDQo+IA0KPiDW98ziDQo+ICAgICAgICAgICAgICAgIFtzZmNdIGh0 dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCj4NCj4NCj4gDQo+DQo+DQo+ DQo+DQo+DQo+IERlYXIgU0ZDIFdHOg0KPg0KPiBBZnRlciBtdWNoIGRpc2N1c3Npb24gb24gdGhl IGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0ICMyMSB0aGUNCj4gZm9sbG93aW5nIHRleHQgaGFz IGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5IG1ldGFkYXRhIHNlbWFudGljcyBhbmQNCj4g c28gZm9ydGguIFBsZWFzZSByZXZpZXcgYW5kIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgc28g dGhhdCB0aGUgY2hhaXJzDQo+IGNhbiBkZXRlcm1pbmUgY29uc2Vuc3VzIGFuZCB1cGRhdGUgdGhl IHRpY2tldCBhY2NvcmRpbmdseS4NCj4NCj4gVGhhbmsgeW91IQ0KPg0KPiBKaW0gJiBKb2VsDQo+ DQo+ICMjIyMjIyMjIyMNCj4NCj4gKk5FVyBmb3Igc2VjdGlvbiAzLjQqOg0KPiBUaGlzIHNwZWNp ZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBw bGFjZWQNCj4gaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVy LCBhbmQgZG9lcyBub3QgZGVzY3JpYmUNCj4gdGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nIG9mIHRo ZSBpbmNsdWRlZCBtZXRhZGF0YS4NCj4NCj4gQW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0 aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8NCj4gcHJvY2VzcyB0aGUgZGF0YSBw bGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiAgVGhlIGRhdGENCj4gc2VtYW50 aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9m IHRoZQ0KPiBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEg c2VtYW50aWNzIGlzIG91dHNpZGUNCj4gdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4N Cj4NCj4gVXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlmIHRoZSBTRkMt YXdhcmUgU0YgaXMNCj4gY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBtZXRhZGF0YSBi dXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlDQo+IGRhdGEgc2VtYW50aWNzIGZvciB0aGUgbWFu ZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlDQo+IHBhY2tldCBh bmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCj4NCj4gW2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxvY10g cHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGENCj4gbWVhbmluZyB3aXRoIHRo ZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCj4NCj4gKk5F VyBmb3IgZW5kIG9mIHNlY3Rpb24gMy41LjEqOg0KPiBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBu b3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlDQo+IG1hbmRhdG9yeS10 by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVz ZQ0KPiBjb25zaWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRo ZSBjb250cm9sIHBsYW5lIGNhbg0KPiBpbnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRh dGEgc3RydWN0dXJlIG9mIFRMVnMgdG9nZXRoZXIgd2l0aA0KPiB0aGVpciBzY29waW5nIChTZWUg U2VjdGlvbiAzLjMuMyBvZiBbSS1ELmlldGYtc2ZjLWNvbnRyb2wtcGxhbmVdKS4NCj4NCj4gVXBv biByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhDQo+ IG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUg U0ZDLWF3YXJlIFNGDQo+IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVTVCBsb2cg dGhpcyBlcnJvci4NCj4NCj4gSWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBh cmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLCB0aGUNCj4gY29udHJvbCBwbGFuZSBNQVkgaW5z dHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3aXRoIHRoZSBvcmRlciB0byBjb25zdW1lDQo+IHRoZXNl IFRMVnMuICBJZiBubyBpbnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNG IE1VU1QNCj4gcHJvY2VzcyB0aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5IGFwcGVhciBpbiB0 aGUgTlNIIHBhY2tldC4NCj4NCj4gSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRM ViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0DQo+IHRoZSBkZWZpbml0aW9uIG9m IHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUDQo+ IE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMNCj4gZXJyb3IuX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcg bGlzdA0KPiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4g c2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz ZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQoNCg0K --=_alternative 0033982848258068_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkRlYXIgSm9lbCAmYW1wOyBKaW0sPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgVGhhbmtzIGZvciB5 b3VyIGNsYXJpZmljYXRpb24uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJp Ij4mbmJzcDsgWWVzLCB5b3UgYXJlIHJpZ2h0LiBpIG1pc3NlZCBzb21lDQpvdGhlciBjYXNlcy4g QWxsIHRoZXNlIGNhc2VzIGFyZSBzaWRlLWJ5LXNpZGUuIDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iQ2FsaWJyaSI+U28gYm90aCB0aGUgZ2VuZXJhbCBhbmQgdGhlIHNwZWNpZmljIHJl cHJlc2VudGF0aW9uDQpzaG91bGQgYmUgYWxsb3dlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtIb3dldmVyLCBhcyB0aGVyZSBhcmUg c2xpZ2h0bHkNCmRpZmZlcmVudCB1bmRlcnN0YW5kaW5nIGFib3V0ICd0aGUgbWVhbmluZyBvZiB0 aGUgaW5jbHVkZWQgZGF0YScsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJp Ij5hcmUgdGhlcmUgYW55IHBvc3NpYmxlIHRvIGNsYXJpZnkgaXQgaW4NCnRoZSBwcm9wb3NlZCB0 ZXh0PzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+QlJzLDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+TGluZGEgV2FuZzwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVv dDtKb2VsIE0uIEhhbHBlcm4mcXVvdDsNCiZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OzwvYj4g PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNw OyZxdW90O3NmYyZxdW90OyAmbHQ7c2ZjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYvMTEvMTAgMjM6NDI8L2ZvbnQ+DQo8 dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Smlt IEd1aWNoYXJkIChqZ3VpY2hhcikmcXVvdDsNCiZsdDtqZ3VpY2hhckBjaXNjby5jb20mZ3Q7LCAm cXVvdDt3YW5nLmN1aTFAenRlLmNvbS5jbiZxdW90OyAmbHQ7d2FuZy5jdWkxQHp0ZS5jb20uY24m Z3Q7LA0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtzZmNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Nm Y0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbc2ZjXSBodHRwczovL3RyYWMu aWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4oVGhpcyBpcyB0aGUgY2FzZSB3aGVyZSBldmVu IHRoZSBjaGFpcnMgbWVhbnQgc2xpZ2h0bHkNCmRpZmZlcmVudCB0aGluZ3MsIDxicj4NCnNvIHRo YW5rcyBmb3IgbWFraW5nIHN1cmUgd2UgYXJlIGNsZWFyLik8YnI+DQo8YnI+DQpQZXJzb25hbGx5 LCBJIHRoaW5rIHRoYXQgdGhlIG1hcHBpbmcgYmV0d2VlbiB2YWx1ZSBhbmQgbWVhbmluZyBpcyBn b2luZw0KPGJyPg0KdG8gYmUgaGFuZGxlZCB2aWEgaW5kaXJlY3Rpb24uICZuYnNwO0kgZG8gbm90 IHRoaW5rIHRoYXQgdGhlIGNvbnRyb2wgc3lzdGVtDQo8YnI+DQp3aWxsIGV2ZXIgc2F5IHRoYXQg dmFsdWUgMTAxIG1lYW5zICZxdW90O2Nva2UmcXVvdDsuICZuYnNwO1JhdGhlciwgSSB0aGluaw0K dGhhdCB0aGUgPGJyPg0KY29udHJvbCBzeXN0ZW0gd2lsbCBwcm92aWRlIGVub3VnaCBpbmZvcm1h dGlvbiB0aGF0IHRoZSBTRiBjYW4gZGV0ZXJtaW5lDQo8YnI+DQpob3cgdG8gaW50ZXJwcmV0IDEw MS4gJm5ic3A7VGhlIGRpZmZlcmVuY2UgaXMgdGhhdCB3aGF0IHRoZSBTRiBuZWVkcyB0bw0Ka25v dyA8YnI+DQppcyBub3QgJnF1b3Q7Y29rZSZxdW90OywgYnV0IHJhdGhlciB3aGF0IGRhdGEgc2V0 IGl0IGNhbiB1c2UgdGhlIGdpdmVuDQp2YWx1ZSBhcyBhIDxicj4NCmtleSBpbnRvLCBhbmQgd2hh dCBtZWNoYW5pc20gKHByZS1wcm92aXNpb25lZCBkYXRhIHNldCAzLCByYWRpdXMsIDxicj4NCmRp YW1ldGVyLCBMREFQLCAuLi4pIGl0IGNhbiB1c2UgdG8gZ2V0IHRoZSBpbmZvcm1hdGlvbiBpdCBu ZWVkcyB0byBkbyA8YnI+DQppdHMgam9iIHVzaW5nIHRoYXQga2V5Ljxicj4NCjxicj4NCldoaWxl IGZvciBzb21lIFNGLCBiZWluZyB0b2xkICZxdW90O3VzZSBEQyBhbGxvY2F0aW9uJnF1b3Q7IHdp bGwgYmUgc3VmZmljaWVudCwNCkkgPGJyPg0KZXhwZWN0IGluIG1hbnkgY2FzZXMgdGhhdCB3aGF0 IHRoZSBTRiBuZWVkcyB0byBiZSB0b2xkIGlzIHRoYXQgYnl0ZXMgNw0KLSA8YnI+DQo5IGFyZSB0 aGUgaW5kZXggaXQgbmVlZHMgdG8gdXNlIGFzIHRoZSBrZXkgZm9yIGdldHRpbmcgdGhlIHN1YnNj cmliZXJzDQo8YnI+DQpjb250ZW50IGZpbHRlcmluZyBwb2xpY3kuICZuYnNwO1NvIHdlIGhhdmUg dG8gYWxsb3cgYm90aCB0aGUgZ2VuZXJhbCBhbmQNCnRoZSA8YnI+DQpzcGVjaWZpYyByZXByZXNl bnRhdGlvbi48YnI+DQo8YnI+DQpZb3Vycyw8YnI+DQpKb2VsPGJyPg0KPGJyPg0KT24gMTEvMTAv MTYgODoxNSBBTSwgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgd3JvdGU6PGJyPg0KJmd0OyBIaSBM aW5kYSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBCeSB0aGlzIHdlIG1lYW4gaG93IHRoZSBTRiBpcyB0 byBpbnRlcnByZXQgdGhlIGRhdGEgY2FycmllZCB3aXRoaW4NCnRoZTxicj4NCiZndDsgbWV0YWRh dGEuIEZvciBleGFtcGxlLCB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgbWlnaHQgc2F5IKGwdGVuYW50 LWlkPGJyPg0KJmd0OyBjYXJyaWVkIGF0IG9mZnNldCAmbHQ7YmxhaCZndDuhraGxIGJ1dCB0aGVu IHRoZSBTRiBuZWVkcyB0byB1bmRlcnN0YW5kDQp3aGF0IHRoZTxicj4NCiZndDsgZXh0cmFjdGVk IHZhbHVlIGZyb20gdGhlIG1ldGFkYXRhIGNvcnJlc3BvbmRzIHRvIGluIHRlcm1zIG9mIHdoaWNo PGJyPg0KJmd0OyB0ZW5hbnQgZS5nLiB2YWx1ZSAxMDEgbWlnaHQgbWVhbiChsGNva2WhsS4gobBj b2tlobEgaW4gdGhpcyBleGFtcGxlDQppcyBub3Q8YnI+DQomZ3Q7IGNhcnJpZWQgd2l0aGluIHRo ZSBtZXRhZGF0YSBzbyB0aGUgU0YgbmVlZHMgdG8gbWFwIHRoZSB2YWx1ZSBmcm9tDQp0aGU8YnI+ DQomZ3Q7IG1ldGFkYXRhIHRvIGEgbWVhbmluZ2Z1bCB0ZW5hbnQgaWRlbnRpZmljYXRpb24uPGJy Pg0KJmd0Ozxicj4NCiZndDsgSG9wZSB0aGlzIGNsYXJpZmllcyAuLjxicj4NCiZndDs8YnI+DQom Z3Q7IEppbTxicj4NCiZndDs8YnI+DQomZ3Q7IEZyb206ICZxdW90O3dhbmcuY3VpMUB6dGUuY29t LmNuICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj48 dHQ+PGZvbnQgc2l6ZT0yPm1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbjwvZm9udD48L3R0Pjwv YT48dHQ+PGZvbnQgc2l6ZT0yPiZndDsmcXVvdDs8YnI+DQomZ3Q7ICZsdDt3YW5nLmN1aTFAenRl LmNvbS5jbiAmbHQ7PC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20u Y24+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY248L2ZvbnQ+PC90 dD48L2E+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7Jmd0Ozxicj4NCiZndDsgRGF0ZTogV2VkbmVzZGF5 LCBOb3ZlbWJlciA5LCAyMDE2IGF0IDk6NDUgUE08YnI+DQomZ3Q7IFRvOiBKaW0gR3VpY2hhcmQg Jmx0O2pndWljaGFyQGNpc2NvLmNvbSAmbHQ7PC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86amd1 aWNoYXJAY2lzY28uY29tPjx0dD48Zm9udCBzaXplPTI+bWFpbHRvOmpndWljaGFyQGNpc2NvLmNv bTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDsmZ3Q7PGJyPg0KJmd0OyBDYzog JnF1b3Q7c2ZjQGlldGYub3JnICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpzZmNAaWV0 Zi5vcmc+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86c2ZjQGlldGYub3JnPC9mb250PjwvdHQ+PC9h Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyZxdW90Ow0KJmx0O3NmY0BpZXRmLm9yZzxicj4NCiZndDsg Jmx0OzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOnNmY0BpZXRmLm9yZz48dHQ+PGZvbnQgc2l6 ZT0yPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7Jmd0OywNCnNmYyAmbHQ7c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZsdDs8L2Zv bnQ+PC90dD48YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPjx0dD48Zm9udCBz aXplPTI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSA8L2ZvbnQ+PC90 dD48YSBocmVmPWh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjE+PHR0Pjxm b250IHNpemU9Mj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxPC9mb250 PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0Ozxicj4NCiZndDsgRGVhciBKaW0g JmFtcDsgSm9lbCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhlIHRleHQgc2Fp ZDogJ3RoZSBkYXRhIHNlbWFudGljcyBpbmNsdWRlIGJvdGggdGhlIGFsbG9jYXRpb24NCnNjaGVt YTxicj4NCiZndDsgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLic8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDtJIGFncmVlIHdpdGggJ3RoZSBhbGxvY2F0aW9uIHNjaGVtYScgY2Fu IGhlbHAgdGhlIFNGQy1hd2FyZQ0KU0YgdG88YnI+DQomZ3Q7IGtub3cgaG93IHRvIGludGVycHJl dCB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuIEhvd2V2ZXIsPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7Q291bGQgeW91IGNsYXJpZnkgd2hhdCBpcyAndGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1 ZGVkDQpkYXRhJyBhbmQgaG93PGJyPg0KJmd0OyB0byBkZXNjcmliZScgdGhlIG1lYW5pbmcgb2Yg dGhlIGluY2x1ZGVkIGRhdGEnPzxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGFu a3MgdmVyeSBtdWNoIDopPGJyPg0KJmd0Ozxicj4NCiZndDsgQlJzPGJyPg0KJmd0OyBMaW5kYSBX YW5nPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyAqJnF1b3Q7SmltIEd1aWNoYXJkIChqZ3VpY2hhcikmcXVvdDsgJmx0 O2pndWljaGFyQGNpc2NvLmNvbSAmbHQ7PC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86amd1aWNo YXJAY2lzY28uY29tPjx0dD48Zm9udCBzaXplPTI+bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbTwv Zm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDsmZ3Q7Kjxicj4NCiZndDsgt6K8/sjL OiAmbmJzcDsmcXVvdDtzZmMmcXVvdDsgJmx0O3NmYy1ib3VuY2VzQGlldGYub3JnICZsdDs8L2Zv bnQ+PC90dD48YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPjx0dD48Zm9udCBz aXplPTI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAyMDE2LzExLzA5IDAyOjAxPGJy Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IMrVvP7Iyzxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm cXVvdDtzZmNAaWV0Zi5vcmcNCiZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpzZmNAaWV0 Zi5vcmc+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86c2ZjQGlldGYub3JnPC9mb250PjwvdHQ+PC9h Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyZxdW90Ow0KJmx0O3NmY0BpZXRmLm9yZyAmbHQ7PC9mb250 PjwvdHQ+PGEgaHJlZj1tYWlsdG86c2ZjQGlldGYub3JnPjx0dD48Zm9udCBzaXplPTI+bWFpbHRv OnNmY0BpZXRmLm9yZzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDsmZ3Q7LDxi cj4NCiZndDsgs63LzTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7W3NmY10NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv c2ZjL3RpY2tldC8yMT48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L3NmYy90aWNrZXQvMjE8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgRGVhciBTRkMgV0c6PGJyPg0KJmd0Ozxicj4N CiZndDsgQWZ0ZXIgbXVjaCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IHdpdGggcmVnYXJkIHRvIHRp Y2tldCAjMjEgdGhlPGJyPg0KJmd0OyBmb2xsb3dpbmcgdGV4dCBoYXMgYmVlbiBwcm9wb3NlZCB0 byBoZWxwIGNsYXJpZnkgbWV0YWRhdGEgc2VtYW50aWNzDQphbmQ8YnI+DQomZ3Q7IHNvIGZvcnRo LiBQbGVhc2UgcmV2aWV3IGFuZCBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIHNvIHRoYXQgdGhl DQpjaGFpcnM8YnI+DQomZ3Q7IGNhbiBkZXRlcm1pbmUgY29uc2Vuc3VzIGFuZCB1cGRhdGUgdGhl IHRpY2tldCBhY2NvcmRpbmdseS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFuayB5b3UhPGJyPg0K Jmd0Ozxicj4NCiZndDsgSmltICZhbXA7IEpvZWw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAjIyMjIyMj IyMjPGJyPg0KJmd0Ozxicj4NCiZndDsgKk5FVyBmb3Igc2VjdGlvbiAzLjQqOjxicj4NCiZndDsg VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhl IGNvbnRlbnQNCnBsYWNlZDxicj4NCiZndDsgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxk IG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3JpYmU8YnI+DQomZ3Q7IHRoZSBz dHJ1Y3R1cmUgb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0YWRhdGEuPGJyPg0KJmd0Ozxi cj4NCiZndDsgQW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3Mg Zmlyc3QgaW4gb3JkZXIgdG88YnI+DQomZ3Q7IHByb2Nlc3MgdGhlIGRhdGEgcGxhY2VkIGluIHRo ZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4gJm5ic3A7VGhlDQpkYXRhPGJyPg0KJmd0OyBzZW1h bnRpY3MgaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcg b2YgdGhlPGJyPg0KJmd0OyBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMg dGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGU8YnI+DQomZ3Q7IHRoZSBzY29wZSBvZiB0aGlz IHNwZWNpZmljYXRpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgVXBvbiByZWNlaXZpbmcgYW4gTlNI IE1ELXR5cGUgMSBwYWNrZXQsIGlmIHRoZSBTRkMtYXdhcmUgU0YgaXM8YnI+DQomZ3Q7IGNvbmZp Z3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0IGhhcyBub3QgeWV0IHJlY2Vp dmVkDQp0aGU8YnI+DQomZ3Q7IGRhdGEgc2VtYW50aWNzIGZvciB0aGUgbWFuZGF0b3J5IGNvbnRl eHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MNCnRoZTxicj4NCiZndDsgcGFja2V0IGFuZCBN VVNUIGxvZyB0aGlzIGVycm9yLjxicj4NCiZndDs8YnI+DQomZ3Q7IFtkY2FsbG9jXSBhbmQgW2Jy b2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhPGJyPg0KJmd0 OyBtZWFuaW5nIHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0 IGZpZWxkLjxicj4NCiZndDs8YnI+DQomZ3Q7ICpORVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4x Kjo8YnI+DQomZ3Q7IFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0 aW9uIGFib3V0IFRMVnMgdGhhdCBhcmU8YnI+DQomZ3Q7IG1hbmRhdG9yeS10by1pbXBsZW1lbnQg b3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICZuYnNwO1RoZXNlPGJyPg0K Jmd0OyBjb25zaWRlcmF0aW9ucyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gJm5ic3A7SG93ZXZl ciwgdGhlIGNvbnRyb2wNCnBsYW5lIGNhbjxicj4NCiZndDsgaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNG cyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGg8YnI+DQomZ3Q7 IHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0Zi1zZmMtY29udHJv bC1wbGFuZV0pLjxicj4NCiZndDs8YnI+DQomZ3Q7IFVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0 aGF0IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYTxicj4NCiZndDsgbWFuZGF0b3J5LXRvLXBy b2Nlc3MgVExWIGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUNClNGPGJy Pg0KJmd0OyBNVVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJy b3IuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgbXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3Mg VExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2ZW4gU0ZQLA0KdGhlPGJyPg0KJmd0OyBjb250cm9s IHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNv bnN1bWU8YnI+DQomZ3Q7IHRoZXNlIFRMVnMuICZuYnNwO0lmIG5vIGluc3RydWN0aW9ucyBhcmUg cHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUgU0YNCk1VU1Q8YnI+DQomZ3Q7IHByb2Nlc3MgdGhlc2Ug VExWcyBpbiB0aGUgb3JkZXIgdGhleSBhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuPGJyPg0KJmd0 Ozxicj4NCiZndDsgSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5j bHVkZWQgaW4gYW4gTlNIIHBhY2tldCwNCmJ1dDxicj4NCiZndDsgdGhlIGRlZmluaXRpb24gb2Yg dGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0LCB0aGUgU0ZDLWF3YXJlIFNGDQpNVVNUPGJy Pg0KJmd0OyBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzPGJyPg0KJmd0 OyBlcnJvci5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsgc2ZjQGlldGYub3JnICZsdDs8L2Zv bnQ+PC90dD48YSBocmVmPW1haWx0bzpzZmNAaWV0Zi5vcmc+PHR0Pjxmb250IHNpemU9Mj5tYWls dG86c2ZjQGlldGYub3JnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Jmd0Ozxicj4N CiZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsg c2ZjQGlldGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp emU9Mj48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJyPg0Kc2ZjQGlldGYub3Jn PGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250 PjwvdHQ+DQo8YnI+DQo= --=_alternative 0033982848258068_=-- From nobody Sun Nov 13 21:07:26 2016 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 9163F129622 for ; Sun, 13 Nov 2016 21:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 FqKrj4YMyG9K for ; Sun, 13 Nov 2016 21:07:24 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47211294C7 for ; Sun, 13 Nov 2016 21:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59; q=dns/txt; s=iport; t=1479100044; x=1480309644; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=V79rak9zKtST9oLop4pJtM175mrtrsmD/pndkJPclw8=; b=J7BcU1WuYSu2fOnGjbfa8NU2pX9+MF+GgvIV+pL2m0soyefmgi0+HcgA 0qlFmdq3RZhMAttQCdmNAjeC4XPp/4FjS0yZUTSkVVWN4IU1ez472dv4a i40+CDaEcZtvKdgb7/LQCYpoV6zis29AtYQw+MEbEFpG4T3WQRggPLVGR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeBwBpRSlY/5BdJa1dHAEBBAEBCgEBg?= =?us-ascii?q?zEBAQEBAR+BBLwChhkBAYIWQxABAgEBAQEBAQFiHQuFAQoVdgImAkMcDQgBAYh?= =?us-ascii?q?dnwWPfIIpi0EBAQEHAgEkgQmFM4F9CIohgl0Fj1yKZZBdgVkBiCWGIZFONSCBA?= =?us-ascii?q?4VUIId2AQEB?= X-IronPort-AV: E=Sophos;i="5.31,488,1473120000"; d="scan'208";a="169930075" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2016 05:07:24 +0000 Received: from [10.24.100.175] ([10.24.100.175]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uAE57NXB031110 for ; Mon, 14 Nov 2016 05:07:23 GMT To: "sfc@ietf.org" From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> Date: Mon, 14 Nov 2016 00:07:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] OAM work 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, 14 Nov 2016 05:07:25 -0000 I would also like to help out on the SFC OAM work. Joe From nobody Sun Nov 13 21:10:37 2016 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 3A4721295FF for ; Sun, 13 Nov 2016 21:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 Kfv7GlCZtX8j for ; Sun, 13 Nov 2016 21:10:35 -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 E1357129543 for ; Sun, 13 Nov 2016 21:10:34 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Mon, 14 Nov 2016 00:10:33 -0500 From: Dave Dolson To: Joe Clarke , "sfc@ietf.org" Thread-Topic: [sfc] OAM work Thread-Index: AQHSPjUA1MvZBcD0r0aUHqUdvS5ldqDX71fw Date: Mon, 14 Nov 2016 05:10:33 +0000 Message-ID: References: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> In-Reply-To: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] 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] OAM work 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, 14 Nov 2016 05:10:36 -0000 I would like to help as well. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joe Clarke Sent: Monday, November 14, 2016 2:07 PM To: sfc@ietf.org Subject: [sfc] OAM work I would also like to help out on the SFC OAM work. Joe _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Nov 13 21:13:49 2016 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 92D2C1295FF for ; Sun, 13 Nov 2016 21:13:48 -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 BwM2-0l4yKOO for ; Sun, 13 Nov 2016 21:13:47 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 D5E29129543 for ; Sun, 13 Nov 2016 21:13:46 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id c20so61583367itb.0 for ; Sun, 13 Nov 2016 21:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c6o2K3LWx889qTXI1XiTH1vbU0/IvasyoGkwOLIG6pQ=; b=tku6Ao6/pmIKlTKaduVs88DkUTpzrWt15w6YrPDL/FRQGy4+lhT0GK71XyVssNt9fV k1vi0qbtNBTcIoLZ/pAcxvIDWJI0NeyIn5QjgAtRjHNeDKLY8q0CODgi83X0mak0t4ba cmnmqMV69l5ROBsOxBqaFw69f94fYx7yIhOPgWt1Aqw1cHXO/S8Sj7idq1sG6eux9oR4 0ItBbSLjnLyRqrI9G7lujTM7XbMzBzAyY53WSj7iyqcVztSawOU4SfDbDFde2CXs7PFN IB2MwnqAl8bd1lVVB8FjitREdBgPY9MLKeYRnKub6dxWMkTJ/xiRx3zldG1rO4Ex1sit Rv9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c6o2K3LWx889qTXI1XiTH1vbU0/IvasyoGkwOLIG6pQ=; b=e5x0z3vQOF/KBCPvJMYlCI63qOJCwNkME/8YIc4/bGFwZSEB/BLmAPGRHHmIV2knVT oFEwXhbf0r3HyNVhm23O+/yDx9JIZLQezxz+rLEIfqE66n39dTwFciaAidaITH8qm3fW l5dhCzbK1uIlPcy3G4fFqNTb5iZx+/cR3Y3tTXhltKcWwafvCis06Vu6hjNJIEI/vmbp 4vwzX64hz1KTk+FDJCYy5XOMErv+wNpuamWXo/V9gbkQ2/jGkryMesDXrfzGZWegyEpm 17L13wHxD4xyHu4kPj5aq6uovxSSgQZNqkCpH+m83uiAHhGB3BApMZkEx78ha8vTMO5F pXDw== X-Gm-Message-State: ABUngvfRg2KJ65fry9MBr32avhhRIA7FkUds8RgJE+KiVuRyBfaGtQyAiBYdpIXojAtrmOLynbFjRvStx1BIuw== X-Received: by 10.157.4.109 with SMTP id 100mr5588340otc.205.1479100426258; Sun, 13 Nov 2016 21:13:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.63.169 with HTTP; Sun, 13 Nov 2016 21:13:45 -0800 (PST) In-Reply-To: References: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> From: Greg Mirsky Date: Sun, 13 Nov 2016 21:13:45 -0800 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a113dc02e7e8d9905413be7a2 Archived-At: Cc: Joe Clarke , "sfc@ietf.org" Subject: Re: [sfc] OAM work 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, 14 Nov 2016 05:13:48 -0000 --001a113dc02e7e8d9905413be7a2 Content-Type: text/plain; charset=UTF-8 Dear All, as I've indicated at the meeting, please consider me as volunteer for this work. Regards, Greg On Sun, Nov 13, 2016 at 9:10 PM, Dave Dolson wrote: > I would like to help as well. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joe Clarke > Sent: Monday, November 14, 2016 2:07 PM > To: sfc@ietf.org > Subject: [sfc] OAM work > > I would also like to help out on the SFC OAM work. > > Joe > > _______________________________________________ > 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 > --001a113dc02e7e8d9905413be7a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
as I've indicated at the meeting, please= consider me as volunteer for this work.

Regards, = Greg

O= n Sun, Nov 13, 2016 at 9:10 PM, Dave Dolson <ddolson@sandvine.com= > wrote:
I would like to help a= s well.

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Joe Clarke
Sent: Monday, November 14, 2016 2:07 PM
To: sfc@ietf.org
Subject: [sfc] OAM work

I would also like to help out on the SFC OAM work.

Joe

_______________________________________________
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

--001a113dc02e7e8d9905413be7a2-- From nobody Sun Nov 13 21:51:41 2016 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 67125129690 for ; Sun, 13 Nov 2016 21:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 U53dR0lS5NfH for ; Sun, 13 Nov 2016 21:51: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 C7745129634 for ; Sun, 13 Nov 2016 21:51:35 -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 DAH88366; Mon, 14 Nov 2016 05:51:32 +0000 (GMT) Received: from SZXEMI401-HUB.china.huawei.com (10.82.75.33) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Nov 2016 05:48:40 +0000 Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.216]) by SZXEMI401-HUB.china.huawei.com ([10.82.75.33]) with mapi id 14.03.0235.001; Mon, 14 Nov 2016 13:48:05 +0800 From: Gaurav agrawal To: "gregimirsky@gmail.com" , "ddolson@sandvine.com" Thread-Topic: [sfc] OAM work Thread-Index: AQHSPjUOup4MI7mlM0WCR9EEoh2Ep6DXaFOAgAAA5YCAAI+zqg== Date: Mon, 14 Nov 2016 05:48:04 +0000 Message-ID: References: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> , 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_etPan582950142e7ec9d5684alocalhost_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.582950E5.002A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.216, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f848136bc266a6ff2101aaf53d5557fe Archived-At: Cc: "jclarke@cisco.com" , "sfc@ietf.org" Subject: Re: [sfc] OAM work 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, 14 Nov 2016 05:51:38 -0000 --_000_etPan582950142e7ec9d5684alocalhost_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am interested in SFC OAM and would like to contribute too. Regards, Gaurav. From:Greg Mirsky To:Dave Dolson, Cc:Joe Clarke,sfc@ietf.org, Date:2016-11-14 14:14:08 Subject:Re: [sfc] OAM work Dear All, as I've indicated at the meeting, please consider me as volunteer for this = work. Regards, Greg On Sun, Nov 13, 2016 at 9:10 PM, Dave Dolson > wrote: I would like to help as well. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Beh= alf Of Joe Clarke Sent: Monday, November 14, 2016 2:07 PM To: sfc@ietf.org Subject: [sfc] OAM work I would also like to help out on the SFC OAM work. Joe _______________________________________________ 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_etPan582950142e7ec9d5684alocalhost_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

I am interested in SFC OAM and would like to contribute too.

Regards,
Gaurav.
From:Greg Mirsky
To:Dave Dolson,
Cc:Joe Clarke,sfc@ietf.org,
Date:2016-11-14 14:14:08
Subject:Re: [sfc] OAM work

Dear All,
as I've indicated at the meeting, please consider me as volunteer for = this work.

Regards, Greg

On Sun, Nov 13, 2016 at 9:10 PM, Dave Dolson <ddolson@sandv= ine.com> wrote:
I would like to help as well.

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Joe Clarke
Sent: Monday, November 14, 2016 2:07 PM
To: sfc@ietf.org
Subject: [sfc] OAM work

I would also like to help out on the SFC OAM work.

Joe

_______________________________________________
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_etPan582950142e7ec9d5684alocalhost_-- From nobody Mon Nov 14 00:03:32 2016 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 B9CAA1297AA for ; Mon, 14 Nov 2016 00:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 8KE1DKMvwHiv for ; Mon, 14 Nov 2016 00:03:29 -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 845BE129537 for ; Mon, 14 Nov 2016 00:03:28 -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 CVC80535; Mon, 14 Nov 2016 08:03:26 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Nov 2016 08:02:28 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.116]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Mon, 14 Nov 2016 16:02:19 +0800 From: Mach Chen To: Gaurav agrawal , "gregimirsky@gmail.com" , "ddolson@sandvine.com" Thread-Topic: [sfc] OAM work Thread-Index: AQHSPjUOzxaIDCTio0GM850ETGOAx6DXaFOAgAAA5YCAAAmXAIAAq4TQ Date: Mon, 14 Nov 2016 08:02:19 +0000 Message-ID: References: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.121.94] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FD726F4SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.58296FCE.0061, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.116, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 769615f00d267338d2a873a261632a50 Archived-At: Cc: "jclarke@cisco.com" , "sfc@ietf.org" Subject: [sfc] =?gb2312?b?tPC4tDogIE9BTSB3b3Jr?= 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, 14 Nov 2016 08:03:31 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FD726F4SZXEMA510MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Q291bnQgbWUgaW4gYXMgd2VsbCENCg0KVGhhbmtzLA0KTWFjaA0KDQq3orz+yMs6IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEdhdXJhdiBhZ3Jhd2FsDQq3osvNyrG85Dog MjAxNsTqMTHUwjE0yNUgMTM6NDgNCsrVvP7IyzogZ3JlZ2ltaXJza3lAZ21haWwuY29tOyBkZG9s c29uQHNhbmR2aW5lLmNvbQ0Ks63LzTogamNsYXJrZUBjaXNjby5jb207IHNmY0BpZXRmLm9yZw0K 1vfM4jogUmU6IFtzZmNdIE9BTSB3b3JrDQoNCkhpLA0KDQpJIGFtIGludGVyZXN0ZWQgaW4gU0ZD IE9BTSBhbmQgd291bGQgbGlrZSB0byBjb250cmlidXRlIHRvby4NCg0KUmVnYXJkcywNCkdhdXJh di4NCkZyb206R3JlZyBNaXJza3kNClRvOkRhdmUgRG9sc29uLA0KQ2M6Sm9lIENsYXJrZSxzZmNA aWV0Zi5vcmcsDQpEYXRlOjIwMTYtMTEtMTQgMTQ6MTQ6MDgNClN1YmplY3Q6UmU6IFtzZmNdIE9B TSB3b3JrDQoNCkRlYXIgQWxsLA0KYXMgSSd2ZSBpbmRpY2F0ZWQgYXQgdGhlIG1lZXRpbmcsIHBs ZWFzZSBjb25zaWRlciBtZSBhcyB2b2x1bnRlZXIgZm9yIHRoaXMgd29yay4NCg0KUmVnYXJkcywg R3JlZw0KDQpPbiBTdW4sIE5vdiAxMywgMjAxNiBhdCA5OjEwIFBNLCBEYXZlIERvbHNvbiA8ZGRv bHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4gd3JvdGU6DQpJ IHdvdWxkIGxpa2UgdG8gaGVscCBhcyB3ZWxsLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEpvZSBDbGFya2UNClNlbnQ6IE1vbmRheSwgTm92 ZW1iZXIgMTQsIDIwMTYgMjowNyBQTQ0KVG86IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPg0KU3ViamVjdDogW3NmY10gT0FNIHdvcmsNCg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8gaGVs cCBvdXQgb24gdGhlIFNGQyBPQU0gd29yay4NCg0KSm9lDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FD726F4SZXEMA510MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Count me i= n as well!

 = ;

Thanks,

Mach<= /o:p>

 = ;

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounc= es@ietf.org] =B4=FA=B1=ED = Gaurav agrawal
=B7=A2=CB=CD= =CA=B1=BC=E4: 2016=C4=EA11=D4=C2= 14=C8=D5 13:48
=CA=D5=BC=FE=C8=CB: gregimirsky@gmail.com; ddolson@sandvine.com
=B3=AD=CB=CD: jclarke@cisco.com; sfc@ietf.org
=D6=F7=CC=E2: Re: [sfc] OAM work

 

Hi,

I am interested in SFC OAM and would like to contribute too.

Regards,
Gaurav.

From:Greg Mirsky

To:Dave Dolson,

Cc:Joe Clarke,sfc@ietf.org,

Date:2016-11-14 14:14:08=

Subject:Re: [sfc] OAM work

 

Dear All,

as I've indicated at the meetin= g, please consider me as volunteer for this work.

 

Regards, Greg=

 

On Sun, Nov 13, 2016 at 9:10 PM= , Dave Dolson <ddolson@sandvine.com> wrote:

I would like to help as well.


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Joe Clarke
Sent: Monday, November 14, 2016 2:07 PM
To: sfc@ietf.org
Subject: [sfc] OAM work

I would also like to help out on the SFC OAM work.

Joe

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FD726F4SZXEMA510MBXchi_-- From nobody Mon Nov 14 06:03:06 2016 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 BAEEB12948A for ; Mon, 14 Nov 2016 06:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 i00X5odtEhS0 for ; Mon, 14 Nov 2016 06:03:03 -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 40DBC12940C for ; Mon, 14 Nov 2016 06:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=584; q=dns/txt; s=iport; t=1479132183; x=1480341783; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TOxdLkZf+kK8eItnKWrgQvstbHrtyeLFy0nhhApoZ3Y=; b=FImZPPBhlAUzYotNhfZ0g8f0fdI6C1f1NEFSnlCxKO23YUY7WK7eGHlK Lx64K44IlOAEjcswnCdpVfRn7qFaQIctrZxnTwFayjtA9LgvrX/fOiq5B 19MYYeX9ul8juNzJJEOepMsCo6Ckt6I9QshFrowck6JytDZoSWSRWKoEN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AQDWwilY/49dJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzEBAQEBAR9YgQAHjTeraYIHHQuFewIagX0/FAECAQEBAQEBAWIohGI?= =?us-ascii?q?BAQQBAQEgETobAgEIGgImAgICJQsVEAIEARKIYQ6vD4Ipi0gBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEXBYEJhTOBfYJdhEiDBC2CMAWaQQGQXIFZARWEdok7kU0BHje?= =?us-ascii?q?BAxyFGnKGcIEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,638,1473120000"; d="scan'208";a="347471659" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2016 14:03:02 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uAEE31gl002328 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Nov 2016 14:03:02 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Nov 2016 09:03:01 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1210.000; Mon, 14 Nov 2016 09:03:01 -0500 From: "Shobhan AyyadevaraSesha (sayyadev)" To: "Joe Clarke (jclarke)" , "sfc@ietf.org" Thread-Topic: [sfc] OAM work Thread-Index: AQHSPjUCsUWLXwVmO0CjmoPTJrNtlKDYUOqA Date: Mon, 14 Nov 2016 14:03:00 +0000 Message-ID: References: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> In-Reply-To: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.77.229] Content-Type: text/plain; charset="utf-8" Content-ID: <7A530407F2587144A91532DA936265B0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OAM work 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, 14 Nov 2016 14:03:05 -0000 SSBhbSBhbHNvIGludGVyZXN0ZWQsIHBsZWFzZSBjb25zaWRlciBtZSBhcyB3ZWxsLg0KVGhhbmtz DQpTaG9iaGFuDQoNCg0KDQpPbiAxMS8xMy8xNiwgOTowNyBQTSwgInNmYyBvbiBiZWhhbGYgb2Yg Sm9lIENsYXJrZSAoamNsYXJrZSkiIDxzZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg amNsYXJrZUBjaXNjby5jb20+IHdyb3RlOg0KDQogICAgSSB3b3VsZCBhbHNvIGxpa2UgdG8gaGVs cCBvdXQgb24gdGhlIFNGQyBPQU0gd29yay4NCiAgICANCiAgICBKb2UNCiAgICANCiAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHNmYyBtYWls aW5nIGxpc3QNCiAgICBzZmNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KICAgIA0KDQo= From nobody Mon Nov 14 11:55:01 2016 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 DA57012947E for ; Mon, 14 Nov 2016 11:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=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 rmLq_4uD2Wyp for ; Mon, 14 Nov 2016 11:54:57 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0129.outbound.protection.outlook.com [104.47.32.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF956129454 for ; Mon, 14 Nov 2016 11:54:57 -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=6UDzs1SFNrFR3lqnRyCH+UJxznEJSCUtlV+0KUC638w=; b=FVSS+eCjLS4tS5obABxPZIFYy2sK2Lda7KONEP43DvpA96j/C39z+nc6a4Jhmqq8dBOTIIp4lKPhH/RpSFFFqOre/2n+7vSpSr7BO+HnxEZWqWQlTI+kdzvCzCdvH0mp+MTgF+OChvraiOM/hJ6on+IPGudrOLOb/MQeo74bHZI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.32.171] (66.129.241.14) by SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Mon, 14 Nov 2016 19:54:53 +0000 From: Eric C Rosen To: Dave Dolson , "Jim Guichard (jguichar)" , Ron Parker , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> Message-ID: <86a5e8e1-f543-8e93-3cd8-d4deaf43a1e6@juniper.net> Date: Mon, 14 Nov 2016 14:54:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: VI1PR1001CA0018.EURPRD10.PROD.OUTLOOK.COM (10.167.204.28) To SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 2:FFx1OOv5tJk9C8rSDu1q6CK5HZmF3w2ul9JyRen7eTnaRcsuniDH1lpjt+/Zf6XSravvr/5NTSUeuigKsFD/E7v1irTmNcXNi/kzlsCB+9BZz0KUR3oZlYg4oYPdnuwPI9vIrzJmH1scJ0uESmShPGAF+XqXsFsKHBDeDzPPtQc=; 3:uj9TlxgZxPSnOirVkY5mIxDabu9cPnoZk2jmC/17AC5c8yg11GuOGnvLI0tAY3q21Kj291GQsuIXgDc3IvKhJbDHzS6MHO/UaPpDvb5JCxIloFKT2dlk0a3DQkW5lQhaeBgwG+lAq1ozVDKePZMAixLGxTlrVl4VQfBq0fQSJuk=; 25:2DJiglNPKj80aPJ8/Q9NfDePrf/bpg6pwVkM/ZnmFJa+IT/sidFYO3I2aX3D+m/bK2YG81AWOIPFFmdVla8jD6OgFlGFQ49YdOUogndPwXftKkIV2of1HXntGScJpKBzbFtxHe2xlp/tIMwgcqQoOl1+rYX8y0qtq41yXyQX3dVH1IoTfd2KWyGyeSqbdv9Z9kUZ5XmHfoVplMkuh7NSAeaA92NTlEZcLY+BDssAaRjxzsLa3nLDX5js/dbWRhRGfCxmSdwdArjx3SKIBDNdkMybLfFxX6kJ+oqNFro3jdI1BKHySJsww4ZqLz7WY4frxQn7sMNphsa4kmtlEaU7H7QRA6UV1jj3znpI/1T5KgRAnY5obHfLTeToaVAn9jBIydvTEI9B4AHRKA+BrVOF8GOEWckPRw+YsB2D+ThhDkhCGnuBc+CA4ClEaye1Uef+ X-MS-Office365-Filtering-Correlation-Id: ff44b4e3-bef8-4e8a-4cf8-08d40cc81b89 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 31:O6fP5g2o7XQyLrwvg+2BXXdEh8e+zujA7L+v8cBlSxVG2cGv2+dZI6cf6kFmqzvB8rhomlXfGD21WgSqs4fz+I7gjBJPK7h0BhR6cczVwot8rQkpO75jtXuaNrzPjySVY4wgoiqusLJwFzLpFuNXA2yB2LmZjDrTYo4ZwxMaPMM684q7CDEXMOM7efFRCK4sFkS38epjf7OGH2FHM0kbVEMJqouTW8Tj30nqca4I4XfcACA+m5nWkL3iBkb/Dc2nAsiRYJGrT1/4j7ktleAujg==; 20:OC+kMmULNq9Ft63s2SpaUqNp/C551DRb4Hij/8eFUiGEyB8lyw5eGk26EjkTwKYuhUjEcdZee+A/PQHuBZ61r2cYAmpEfchNKFEVnTRnTmLMSfnVFUkgyGIDiOg1GSD6Kef60MtP61l62V3Yld3q2NPsCBEIhvWpykvHtMdcK8g3wznzyq4y0cI7mgjvLDG+tT6NWA1mUkOm4XwjqCwY5Ng3ksfprzCuRO+6lLXT+gA0rxns4g/x7mCMiZ9byV/cUfrbFvdEA3nB90ZdqUqpe2grfKorxkCGHtb4U+H2ifIN02jHLIPzaRHfN18hMoA1WygO17feRSw9Xx62FfMXtWCwM56Ew/jCMTEQpvkud2SQKNXzDJoZzcpjy/YHOyEkJNFVJEJkHtnYuz2iQVm2mBN2cN6opPnbEUufkO/EQ9oVYJeNYDzmk3cezVFHZ+xE8b7/1pP6EOX2aPRSsJuqD36WGDi2TUsbgnyUv+kyjRwVC9iZW/tAuToruVWZrCU+qTnJ0U9EkO6K/9dKaYkc+VlVRHDaHuo3ubjXqlR8UqxND3UOQ6aN/Ks9lERJM+o23oFKPAT+hmi80lZ7DyGZibpvTXJHVVZ6UFozxqM2pmw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061324); SRVR:SN1PR05MB2189; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 4:0+x1KneYsqUbQp0dlqpRp3wtxlzZV7PuQpJBAyd8dTUmlkrpq2ABpcLtJ4lP8LjCV/X01AFsmoOcm4zMPpeHh59s/0a8+dDf8BXMD71NwdNVmsUO0/5OJ6vlQrpPHOcDY+o9S3oiJsSlKam4/IKOqqDZTzGGG8Q/EGn4qJ1/MuOMQsTo2FXS1wP4r42vEl59Orr5Qpo94Hu75qrjPmjjaWvPs9eMgQ5EkScW1F6PmVL5IkyeveAsj+kwEkeo/kZwDFjJHEn7kFZ0wi+29Q9MqAAVS6cL068mX1eQ3azjyEve3m7Iln0T1pzswSlkMRsevBIBhBd8RN5QUTB9MXTQ/xdtBNdw9jU+0/aG4kVfaua6WjrH/xX6Pc530ckSAcgNdd9lsKJUSZGGfEKKqvIQf0sWHaxUWNz9jelFEvqNBtF8KDePWKs4ruQxr/g8rU8T67nYY4FzObSSjAXoFOuuQ+4zRP75OvDkFMtwSdom5Zw= X-Forefront-PRVS: 0126A32F74 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(24454002)(377454003)(93886004)(105586002)(68736007)(106356001)(33646002)(50466002)(64126003)(305945005)(101416001)(7736002)(54356999)(76176999)(50986999)(8676002)(36756003)(42186005)(7846002)(230700001)(31686004)(65806001)(77096005)(66066001)(2501003)(47776003)(65956001)(81156014)(2906002)(6116002)(3846002)(81166006)(92566002)(97736004)(5001770100001)(86362001)(4001350100001)(229853002)(65826007)(23676002)(5660300001)(31696002)(83506001)(107886002)(189998001)(2950100002)(6666003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2189; H:[172.29.32.171]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1TUIyMTg5OzIzOkw1blRXUm5sKzB6K1A3SVc1WkxUaFJXb21S?= =?utf-8?B?M1VFc3ZwMlBaODc1d3dlRU1QMjFrTk1EcC9FSHMrZXluTHpDM2dnUU8yOEMx?= =?utf-8?B?UjlieUp3d2t4NyttVldqQmF2K3ZJZVkwZHhBZTFxL2xWaTUrU0JXb2RJTTJv?= =?utf-8?B?aW5HL0ZMVHdwOUsrZks5UFhtOUQyNWM1UElGbW1nWWlrRHkrTzc5OGpIQ2tn?= =?utf-8?B?VjVpY3BVeHF5ZW1Uc3pFZE1WS2x5bmNwbDJkMllRcXVPbDJiTXdlb3hrWTNw?= =?utf-8?B?K01SSERmWDBPMkZ3RTNxRDRBNzdmWExaZWZiVndDeCtBSUtVa08vaGt0aDhW?= =?utf-8?B?ek1paTNMeHRIZFQ1TlBaTUZsQjg4bUtNWlRpWFZoMjBxZW1PdUxLOHZ4ci9q?= =?utf-8?B?cEZtdU8xVGxGOW1sU0RQSUY5bVJpanpkVXRGN1dscU5YZFJRejJGRW9HRC9F?= =?utf-8?B?dXdmY2F3bm5mZHhqT2s2SzlybGZKYmQ3dHVsVTBiYlZnbExxZ0tSSmx1RHlQ?= =?utf-8?B?RW1RN2NobWJzYXhQTWZvdVVWaklFTzZ4SGJsWjNOaURGRW9HYkV5RnJHSnIx?= =?utf-8?B?VGc1R0JhcGdSTWt0dUM2V2dFL28zUVVJN1dMTVlMODQ5TlhsREdHT1I2dHFC?= =?utf-8?B?b3o2STNYVUZDQTdZbUFGK1J6TGdBZFZhQTNDekc1U2h0czZldW5tT1JYM1VY?= =?utf-8?B?d215OUkrVFdXdDVUZ0ltUCtmQ01yYmtKdTcwNUt2dzJlOXlWT3I0ZHBIblJF?= =?utf-8?B?ZUdYWkp5MWVNTWxmRVMxM1RFVWx0VmhVd283OE82N2dBb2NQZUhiczJYbDJo?= =?utf-8?B?ckFKYWw5QmxleEk3WXlJcnFvYVFqU25sbkZlN0tEbHNHNDVpZE92SElRRGpY?= =?utf-8?B?NDVCemdZdmZGYW03RDNsZlRSS3pTd3pTVjJFc3E4T1ViZGRhUnlFQUliNWs4?= =?utf-8?B?Y3M4ZkY3YldWT1IyUUE2WnBKTE1adjJPQXNScUFyTnZ0azU4R1A3anBSbW5K?= =?utf-8?B?Y09ITEZhV1hET3R3STNvaUJnZE9BQWt2YzZ4amhCeHJma292U2owbU1Fa1lD?= =?utf-8?B?b0cxZG5QanFzWG1kNHgzbmd5QnhVanJOUFZRWE5JOUtHNkY3Y1NveVROd1Rm?= =?utf-8?B?emJ3aUIyc3NqZ3U2NEpIUVY4NFJra1QwMzRvNUR5TFM3dWxsaG5zemFiVm5v?= =?utf-8?B?cHlqd0ZtSXJKYnVhTXVuWHFEbTNsZjhCd3REY1hQczE1emYzWTVMOFZuMWJm?= =?utf-8?B?OTAyOTB2bHdFbVpneDFoaWlrRms1QjVzQnkyV0N3NXY0d2FvSDdzK3l2QlY2?= =?utf-8?B?SktjN0c0N2R6TjBHNWRDVDBLMDF2dHBOOFVGeXJVeXYzYW1rVWNRK2thZWNO?= =?utf-8?B?dlY1UU1yUkZaYU5YeU1RZ1lScXFhcDRuaDgxSWxZU1hjdmZqRzhKMUpsK0Jx?= =?utf-8?B?Z1Z2V3FSOFdoZmQyNll6WXRqZEF1VnFFb2xCMHNCMFMrbHFOS1R5MnZ2dm11?= =?utf-8?B?dURGZHhmVXU3cG9UNVVVcEdOQnZ2SVdtMG1USDlSN3lNb1dMWHpsekM4NDQ4?= =?utf-8?B?ZnVienhJUzZYTkwwYVpPbUYvUzFmUWEwTTVscXMrSHptdnVMc2Q2a0ZybVhh?= =?utf-8?B?VzQ0T2FoSFp1VnhFc0pPc2Q5RllZcWp4MWk1WkN2b2tPMEc5NWtuZC9CREdI?= =?utf-8?Q?R4y04QX2vox6P4kldhJyiijr1c1hgyQjD9FSUgi?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 6:1YXIABZbUM7WZE+J3+RWnszFyFcuzhkAzV9jD+0vAJl/myCknNgKVogHQBgHh5k66ri04h1cNfoQqo42sTWjRNfX8/Mx1/LaSRl6sIM0NRuQSF6AUwHxcYHVjMHMPoDtzSRY1JFjKc/vOerr0uUVa48D2a6WoQI77NXz2AR3x9d/pUg/7Y1jfPFFdBR/BNdT71lCm2T34YYgW8h8N5zaaXdJ54y/OPd6qZN4ao5u7bNFfb8rH0UsRwaXP/Ds0Hgk5K8ed+7jniNHYFrIqx8IG81zXTYMv4sD0yBxgq/wFeJHOD9i+LIUPxIGzmCyu6c1Qq7pOJ0DSZKnpxUKYmCLMQnoMiOno6p3qp7DRkDfY5A7RcPmmiVh7R+WmQeURrY4; 5:76CglT0i6r1oQWv1ZGBUK0oXHqnJuI9vvWhIy9ouWHsd/QUD6rIl22qfNgikLc+YKRJdMlJmoPiCj9O1d+WjSt4EUfmKRYYmQAw3OKh4H9YSESbAPCyKAZfkb6tswRgwTMLKELjzP9m7GTrsepvgXw==; 24:ZnV5N7Cus+HorNEd3ZhFaBdDkdln3tYWnw/JlIfllEQ9b14qx/2gtSFkneAE+bR4B5i5UE9gdMNENTR93IxOOXvPhQJKf777FsFdwAq97+s= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 7:Pqanm0rfA8n6k9nInRbAUpNs2iBVnwyZipJOUnBsqQ6i7RQRLZT2osspDXngZGZ3jLqrCXRPBjTmDEm8/SrlQ0Xh0ksXT6W/qFSTy+6UPHOWeGFuVNeKezf5v0XNy+JTYu5hyuQw9UmRNZ51vKQXiN2Ei4eb6El4D5i/3cV16L4pU5damz9KjQAGJj1Zxa/vzIuK0MKhIOGejHdm0pnPcxzfy0kB8l87aIiD0FMrLXq705gwmxpFQHdLPA3+y7RxwHwwSJp/MPLsQ0pzttSgO5nVGehZg5NQdcWNBVhH+OaLxMBUF+HkZwi4aELOzWcpxXap/KXy1KY1gho88jKtJv0216xjo7JPkEUr2kombBU= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 19:54:53.3115 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2189 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 14 Nov 2016 19:55:00 -0000 On 11/11/2016 4:13 PM, Dave Dolson wrote: > I think there is some layering confusion here. > As I see it, once you put NSH inside another transport (e.g., to deliver it from an SFF to an SF), the intermediate nodes aren't doing NSH anymore. > So it might make sense to draw diagrams of logical connectivity. > Eric, I think in your examples all of the SFFs are "connected" to all of the SFs at the logical level. Suppose SFF1 connects directly to SF1-1 and SF2-1, whereas SFF2 connects directly to SF1-2 and SF2-2. And suppose that an SPI/SI of 17/255 means "SF1", while an SPI/SI of 17/254 means "SF2". I was thinking that: - each SFI knows the SFF to which it is directly connected; - there is a unidirectional transport connection from an SFF to those SFIs to which it is not locally connected. Then the processing might be something like the following: SFF1 sees an NSH packet whose SPI/SI is 17/255. SFF1 selects SF1-1 and delivers the packet to it. SF1-1 processes the packet (based on its NSH), decrements the SI, and delivers the packet with an SPI/SI of 17/254 to SFF1. SFF1 processes the packet (based on its NSH), and selects SF2-2. SFF1 sends the packet to SF2-2 over a unidirectional transport connection. SF2-2 processes the packet (based on its NSH), decrements the SI, and delivers the packet with SPI/253 to SFF2. SFF2 recognizes (based on the NSH) that the packet is at the end of its service path. Note that when SF2-2 is done with the packet, it does not send it to SFF1, it sends it to SFF2. The "direct" connection and the "remote" connection are not treated the same. The "direct" connection could of course be implemented as a transport session. But in this model, SF1-2 and SF2-2 do not know about SFF1, they only know about SFF2. So I think it would be a bit misleading to say that the direct connection and the remote connection are both logical connections. The remote connection is really unidirectional (SFF-->SFI) and the SFI doesn't know who sent the packet. The local connection is bidirectional (SFF<-->SFI). It might have made more sense to say that SFF1 should send an SPI/254 packet through a transport connection to SFF2, and that SFF2 should dispatch the packet to an SF2 instance without first sending it to another SFF. But this would require one of the following two solutions: - either a flag in the NSH that means "already seen by an SFF", or - the SFF would have to know that packets received on certain transport connections are from an SFF. Both of these solutions are simple enough, but both appear to have been ruled out by the WG for some reason. From nobody Mon Nov 14 12:03:53 2016 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 7C32012947E for ; Mon, 14 Nov 2016 12:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, 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=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 kyzZCFg4_10e for ; Mon, 14 Nov 2016 12:03:51 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0115.outbound.protection.outlook.com [104.47.32.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFA1129455 for ; Mon, 14 Nov 2016 12:03:50 -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=4oiWrW7H1YlYLftzSyATJIcPQj7QK+nao3k1r1CPyNg=; b=cFTpA8yXOKmgQT0HU59NTlbqvS1Q5keukrMfuyIndVoT3C5OG2rA9IkFVxq1IDiIY5hF3uBVnxZPq/JzS9E5eKn+NQV3jf2rJA+HhVVEuCUhloBFq3XcSAtkMuIYqqrtuLDJn9A2OhHUO32QlIymWR8/4qGEzGasH/1jl2Kgl0I= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.32.171] (66.129.241.14) by BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Mon, 14 Nov 2016 20:03:46 +0000 To: Ron Parker , "Jim Guichard (jguichar)" , Dave Dolson , "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> From: Eric C Rosen Message-ID: <91c9b192-e92f-d7be-3be2-2031e1c6cc3a@juniper.net> Date: Mon, 14 Nov 2016 15:03:43 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY1PR14CA0084.namprd14.prod.outlook.com (10.164.65.180) To BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138) X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 2:9zPcal6hwtr6RluZ1jIqcmkMs1A/b0k9nLSuwwEuIBkj1s/s0qs4YukXw2ib8+d4QkTEGaPdo/GZdfUZlzDFJVaE0c7L8tG7t9Vymem/SUPM3bS134onI7G+vMfLX0V1AYFhbEG4iLwk08A592j7Shc7XRoHlivH2XpcjzTj++g=; 3:6vhmP63thIRUvKERZq9W0cfqPc2qBWK3Yij/4u7+nJRNifcq2IKkQ9RP0OSjlgnNVLlIl7V33AJf0uKgkQUqsZ0lmGJKDuhphDzhB84JJHaMG64HV2hYNwd5j6h3lcrbsavrBwbZ3hTk+vmHSei09Pwy/o2fjb0NrvAOz1cYURE= X-MS-Office365-Filtering-Correlation-Id: ada9347c-2b19-45b0-143e-08d40cc958d1 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BL2PR05MB2178; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 25:FMrXUuAKghcHnCGohcrtPsZFcQ4w0K7zFZ24KZ0c+BE6HI9ejT2khtcgkCZQCsOenmRbTRUXmVBXBOIQRgznLil2+ZRsm04nHFzuCSzG5aCHJgwQNuxvj7Kt8dHmCGBAMkIus9zCidgNgMRX+2tMH52JZjp7M+ficAfN0CdVdkZ8CSMXrylyYHdZBKLZAiMiE2pYtxSsHrJ1uRiw4LBPKyOFYnaxVaaW/Khs9+x4xaDi17tsDu/8mQ+MqV5x3/CtmAdi0lO4GiR0IsUajpmyui/lBLEqLbAqUs5fQJRnuQ5ZubrJUDHej8xnxVy5V29+Gj8wCBmInovxkYI39/8ubr2T4EFRaacgObkI9ijxJfGhdrUNdL/wIyotxWgo0ANYWOdYAGmqnJPGLR7xP7fCKU8egM5TfVfsnUZ1UIS6iM/55JzlMiRhSBhDp70YQbEPFUlgfyOCK0tNML2ugfvUa91ikfQ/IkLCB9mwKeBIUgeI52Tho3ki4qYUAHmahWRjiVcJkWzUW/l+FBJK/CmYphXP5PSr8Q6uOzc0GcFYBfAxAMLab1J8mOvtcgYeCpwNcMTKrI7XYsaROGjr1NKKBEkQsWCP7BKulovmZOUaqq4Gw8GsgL3RCo5o67ZEGj6Yfq15TxVDAQUAJkfVO7cJv1ePDbEwFF9YxBtm50cgZz30haJKP2UHvwBQIpyH0b3OLBHOV4WFj1Ygj1nCUsbBAunHq03IyRRonls4pmdw6/E= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 31:cFpB0pGpwGI9Z/OFo9d3intUaNUK4fS840W9CDN/1FijsUDVp9JVYfDE4oz/FaG9zryJGTWGEJ4JjYJCyqVghiBLR67zPHUdWJ7kWdUhbbnJ6xEoTpn8UB4E+D1IPA+Y6/Ddr2MtpsUEPwMYJK4KM2tc7UWnDn/QoAnUMNsZCZaa+9tt9Gjnu4LnKMyheWjQcmRKZuxQkbBFVUiwJzeRatWLo0X+fzX7G9PeeFBpDlyBaX3N2XnDBs3JyezlD0bFGZ54NITQNxN/nEZ3Jdxa2g==; 20:5uNC8AFlgv884HDGJYfivRHTWnZMtQLNgn1W3wjFupFbwAkvY+TxKQT0OQM9eXoS6zPjDVesCduQnqufnw2LPXNcUhQb9AVOspPnYnHLuSaYg5jR3XAA5Vd5m8XqQGg42AzvyCUJQuMbwlufKbrxYRvvwtKJWIuQIYUlWz5+TDaQWZbXi8hu7BhIq8ghaR+0tuRIIMPV39iNFRjPnidlxK1qBJ8BxXoCoqqhu0wx+CmOQvL7OG48BaCnGoYUsbuU0bNEKnwudAxr2NXaWc1Tw2CFmIVRts2L9pNsNKpk0Zo8EFt3qutO7939FzOt4TSn7tZ6HCBRDGb6Ti7rmL2ruVgfqMudwu7we0TZPaK2ezqqWGT4+ONmA2CD9Cwg3Z+amTaeJTEvddEBeq5dp0tl3T4zU9MWCubmed7ItrYWvutAc8UucnKBZPDwMdzmcBJ7PFJ0wVfal7Qpo5hzjS3LIlhBjBM6qcpTxohB959tfDa0hdMADLwc1YtvTc2th5kNVukBmYcNkOIsXS8iBsctB/exbdSLYQfh8Pyvja4bl9S3y6RpFLsaJrqLeMtrAEhpgrjPUgPB9pQzF6+H6zbplEA/xazNrAVy6uJqoXoCaWs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6061324); SRVR:BL2PR05MB2178; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2178; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 4:qVksYnr39Khc5MCqx2yWKSqw/2T/l9Mqm9H3mYJW2I2Z8bMoBh7Tdr9KeLFQWHtmgK/EV1tDFe9JJyqpAaK0u23onqC9p6rQeF4RVxsdcdVmKO8SxVELh9wMMOtj/Bs5PN/cFIFhmpeUyoALzgaMsqiCojMOTU1Bd20FwgGcfGealpy16HFhPOkNMivc1kTUSgIn0o5rih9vALy2wWEMrt3qq+mujCG6gjtd1f5ieTsir3nD+StXip+Ad3Tg3u8Ga3hCg039uUZbi3LYjYpgFLRkohj98FWFhaMvNkLR38FisDf5SnkjYNeDnNNQ1ZKZY4hKiQnUEe/f7WK9r4LxfsT9cPhptcpvMOOoyl4wYj29jZptldwfPjKwZmtz92qG0fKdwHl6x67dh6C6uDkSHC+SQWww2g6Z9TVcnaj8DtmFiSyWJO5+gY/W3N1aE38O X-Forefront-PRVS: 0126A32F74 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(24454002)(189002)(377454003)(6666003)(83506001)(6116002)(2950100002)(3846002)(86362001)(77096005)(68736007)(5001770100001)(54356999)(8676002)(65826007)(305945005)(230700001)(7736002)(81166006)(7846002)(5660300001)(2501003)(2906002)(229853002)(97736004)(50466002)(76176999)(47776003)(23676002)(65956001)(65806001)(101416001)(81156014)(66066001)(50986999)(4001350100001)(107886002)(189998001)(33646002)(106356001)(105586002)(31686004)(42186005)(31696002)(36756003)(92566002)(93886004)(64126003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2178; H:[172.29.32.171]; 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: =?utf-8?B?MTtCTDJQUjA1TUIyMTc4OzIzOndETlg0MFoxcm9UNG92SHN3Y05IOGlFVHkw?= =?utf-8?B?cUIyNGV3VG16U0N4U0p0V2NtTGpndHE4YzVGdk16RThtMEFSME16eGxWM2t1?= =?utf-8?B?V3hMTmVzZWxsRFZ6ZVVpVDNjaCtkdi91Qkc1OS9tcGdZSnB4SThpMmxmWGxp?= =?utf-8?B?MXZUNjI1YWpHZW1mZTk1K09paDB3ZTVBYUd2TXYrRnN5dmd6Nk5Ua29wT2V6?= =?utf-8?B?WWd5MGdlSk9MZ09VRE90aklmV0dlaG9adzBVU1QzUEt6alhDbEM5aHl6TWho?= =?utf-8?B?eTRPNi82K3FQOTVuTDRQU0dNRVdhNW03V1RJdm4yMUl5NHY4OGUwNGkra3Vv?= =?utf-8?B?WEZOOTZtSkFoeXJJQjJVS2syK0h3VVBoZ0xoZ1FQbDBQckZra25tUTcvOXd2?= =?utf-8?B?QUdHL1BBdkViaERBN05ydDFiNmRoTC9CdWJxRFZSSW9PMmpxRnNiV1RSZ1Nj?= =?utf-8?B?NXhHd2RFcXpLVTRLTmZPWEp2ZDVwckM2V0d2eFNCcmNGTUpiZnV4S2ZDQXlP?= =?utf-8?B?ZnhSdndVU2NmdDdnOHNHY0tBK1pWaG1HdmpjdHlvd3JQUDErN2d2aGtmb3RE?= =?utf-8?B?S2dNL09oaHZEK053Yjd6YVBBVlQ5cFFUTzBmdERxNmdzTXRhcDY3ZzNTSFZW?= =?utf-8?B?SWRqUDhzT3pEY01UYi85bjRTeG4rUXZqTWd4bVNuVVloMlorNmZSaFRFQitz?= =?utf-8?B?NVBYZW9TR0xmU3JoRFRpYXhQNEpZK0Qwc2xQUzl5RFRkeEZFblpCSFMxcXZn?= =?utf-8?B?RVorLzVFTWFoTHZIR3cyMUdYVmtaTWtqZ3NFRG5sOE5rdmhXTlNiZUk4TEtW?= =?utf-8?B?S0RCNlFGZVAyYUY3RzFIbi9UTFRqZ2FuVWdsMklqQ3F4bk9SNTBlYXFnR3ZH?= =?utf-8?B?VHc1WnFJZUF1TnJhWFlpZ2FNVWVhMmJDcVpEU2FoaTJJUkJNZTBWazJTMmt4?= =?utf-8?B?T3dXYXp6M01pS2czRGhIcnFmbk5OZ21KaUtoMzhRUmFRL2M1UzhMdG9Wa3I5?= =?utf-8?B?MFpZOEIrUGpPSFF3R2R0UGcrUUtPYjNwdEYvb0RGOHp1bmlSdnF5bmtjMk4y?= =?utf-8?B?V0ZpZ01aR3d2cWUzaFF6ZFNwL3poRFhVY1NuUWMxQlgxVnVmbTNKY0dZVCtE?= =?utf-8?B?MGFGMTZ0QTAzRVIvVU9uaTdOVjJSRnFJN1JaWlN1bE8yZHNISWZ6bzhScmNa?= =?utf-8?B?MndDMkpXZHNweWYzMkkyc0cvK1lCczBUTi8zZnNiSktURGNidWV5U2p0eDZv?= =?utf-8?B?c21ib2xKeFgvOWkzQmNzcHh1Z3pvOUhtVFhkMVVvb0RoRWE2dzcyTUJ6V1hS?= =?utf-8?B?R3krelNPNEEvTGlGdEFwSkRYRGsvdUdpNkVSdG93SC9KbkhDMUU1ZHB3K1NR?= =?utf-8?B?dUFkME84bGxYb2kvWGg0b09hbi9mbkMrZ0pSVk9Da1lZTVhBVzNrTzJuaGMz?= =?utf-8?B?UHlOalhJVk5PcnVYZlNMcWNqb0hLZFRyY0haWmhGMFFtajlWaXUrQkQ4dXBT?= =?utf-8?B?NTh0S0J6RmxSR0hkdnVMa2pDaUV0czNGRUFhV2dyYVRxR3ZQSWs4czMwNFlU?= =?utf-8?B?dWpFTWpjdzBqTG5FS1pncExweWFpQSs4aHp3Rk5IUHdCQ0VzeDJkTU91SWNT?= =?utf-8?B?b0Y1WE9uRmVyNGh5M2JSRzl2NXpwS2JsV0gxTnZsWjRRL2dCQ3ovZ1RZbnM3?= =?utf-8?Q?lf6HEvS1U3SXBW9erABVD/ayuLd2qrT4DZUTLlG?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 6:28fDHl3q04E/AN09DAdQxxDJSCNvEn71IsaHJMtQgxL5sc4nuy+eUHsrSah2DO7EVr8SiMs45XKIlryn1tw54aZQQhz/BsIxLUgJt6pkABvQCySQy3hpotB3hcUMOPXhBQf3VW4/FbBuJ9HxE4EjP2UYcl3FP5UM9LkJLj39JCA/8mqYG83UWPfz7k1fRhwskOdhHUIXRc9GE4YDB6kr3uX1TSTSTU7QTMb5Uh1v8YDD2G6NdOgG6RgkEQHzoHEV2rzhTrDniBDcfrWSIN6dIVMgDVNxV3k/2oxkqnMaIAOjQS1YRqZF9OBbyIq8i/4P18G5JpfQQyz5D2Md52pwwXCxumXkSY29SyRmWKlp45dZptJEbk7eheVp+hNCmbbH; 5:+SkoEt7m2Jx55GMCar8IEPcH3faDlcMMFfQlXAiRupbHGHowf7VvFBe5jckTb0fQNb4ZVLevQXvnGo+PozWHNQJMKMiYkZsNpDsLzXLZAn03K8A5t0N1t8FqPgP4hqfX7bY9mSJTAZDGDdpZd1kh2g==; 24:wvAXRyabdTMwwaivG4mjxMosaCd4XWH/ErpfI4kBiyvCTvL5gfmtsvkJWp9XLpZGllbvVcUfmERPjHD028UU2+aGjUsyNmfEv7FJR/GY0xA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 7:N4CmO4V43S7f1pPyRmy+8Ouzwm8NsGxYF3RROnBxhyE2BMif86JRtwftEM1ZQnjnaD8rlAQKrW0y1zINoR5THqbG0KchhlXZGIIN6eczYEgEsTm9OzMnUDnn97//8SsNo3e7KjY5/Hh5WYAZlhmHW74dTw/nn3IXCLmL0hpAkQmCwKzBr/NECTA3m+Y0nR6k1Ee1JGfvAII/fYwQez92ZI11nAbE1WHtqrkVWd/atlMWSFet7uQyQYOV3PIGgtnzhq5tcn7jPByA1S7zYRz3SX6jYecanHRp1qrWLq8x9j8P1jk94No6iVMwHAYtzRRKf8nN1i4lUyIMMZbokhlW4TLhFrxXKY5qAe3/Px7e9Zg= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 20:03:46.8136 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2178 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 14 Nov 2016 20:03:52 -0000 On 11/11/2016 4:18 PM, Ron Parker wrote: > Here is my apparently incomplete or incorrect mental model: > > * SFF's have direct or tunneled connectivity to the SFI's that they "front-end" > * SFF's have direct or tunneled connectivity to other SFF's > * SFI's MAY have direct or tunneled connectivity to multiple SFF's > * in this case, in my mental model, each of those SFF's simultaneously "front-ends" the shared SFIs > * When an SFF needs to forward to an SFI that it doesn't front-end, it progresses the packet to the SFF that does front-end that SFI I think this is a very sensible model. It requires that an SFI know which SFF front-ends it, and it requires that that an SFF can tell whether a packet it is processing just came from another SFF or from an SFI. But what we are being told is that the WG has already rejected that model ;-( On 11/12/2016 5:08 PM, Adrian Farrel wrote: > If an SFI is connected (by tunnels or otherwise) to more than one SFF (i.e., the SFI is front-ended by more than one SFF), how does it decide through which connection to return a packet that it has processed? The decision could be as simple as to assume bidirectional tunnels and send each packet back through the same tunnel on which it was received maintaining a little per packet state in the SF, or could be as complex as making a forwarding decision based on some knowledge of the SFP. Or the SFI could know which SFF is it's "front end", and that SFF may or may not be the one from which the packet was received. From nobody Mon Nov 14 12:27:14 2016 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 ED8851299EA for ; Mon, 14 Nov 2016 12:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=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 rCeICldC32Q7 for ; Mon, 14 Nov 2016 12:27:12 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0099.outbound.protection.outlook.com [104.47.42.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372111299E9 for ; Mon, 14 Nov 2016 12:27:12 -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=n32gp9jMIi+s0yAC/L7IbRFJLqtp3nhwRhxtzY6/fKM=; b=AdEyI25Ekyc/2MUijmhTAbkJH+mVRwKzMLbR0G8FOafoYIzS3rX1RKy3QgPPAzyOgHnG8gqza63D4Al8kN5hh7urRQ3xd8D6TsoMejd9v9lXtcSZAEj6xxCFB//DLZYG7nbRx9604zlMFhmbeZL8REykDkjqdBs9Tgvyf0G3vHs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.32.171] (66.129.241.14) by SN1PR05MB2191.namprd05.prod.outlook.com (10.169.124.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Mon, 14 Nov 2016 20:27:09 +0000 To: "Joel M. Halpern" , Dave Dolson , "adrian@olddog.co.uk" , "sfc@ietf.org" References: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> <294a889e-7686-2d2e-3b62-70ab38a41c96@joelhalpern.com> From: Eric C Rosen Message-ID: <55101011-eaf5-aa39-1746-17c66465244e@juniper.net> Date: Mon, 14 Nov 2016 15:26:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <294a889e-7686-2d2e-3b62-70ab38a41c96@joelhalpern.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: DB5PR03CA0019.eurprd03.prod.outlook.com (10.162.150.29) To SN1PR05MB2191.namprd05.prod.outlook.com (10.169.124.139) X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 2:7L8SaQm9keW54HzrhoAn4IQ8cXdM54IzI4ZnHnSlgHh675Ln/kO/wkEDEoFhNeBPWpHLgt3L0Pf55eBMeVN9+jyD1+Dqmcfz9unKdp/RxvO10x123hpw+qx/6DgFPaUX9JC1wkO6hRGw/jhp9rsvt/Ui4shMT7Buk7Gl/qijHaM=; 3:PvCsEXsnN6WIniHyWf4AQ/6SgK6lQ2ewEeGOJAhCgAMiwvi/J0frl1okJRvD0V9G/mO2xLzlGTFC5C0HK1WLDZ5DAJ85Mc/dFAegUWV1dKzEBz2jjRZ5VWLzg14BrljvCxQyIAZEA4AtrgKmAy2U550ay3mYBRz0oLYp2ryQ0OE= X-MS-Office365-Filtering-Correlation-Id: 127e7c21-5bfc-49ed-2fa1-08d40ccc9cb9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR05MB2191; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 25:WDDYDVm2FwULiZfe3my35PZYVV25cqmJuRcJyUnydCQgH6zGdCi87RktWDpMTbNPVg5dllh0mKjMeivUnSeuTyn3agDsA/YXpCu6/aClWjGWryLIE3As6nadwbQrANIv+du355jqlIJNVRrTz+CjL0M9ca5ULqjz2ie4uazSF60gP4uEfMCNDmS1NyCo+WGQRnxMMC/GUZfagUWmg+qWIaHC1IxjnFlOfb/PsecCW2RzHZVsrSptd1tLh+AHdO0M89mW2G9jfnJiLVDSCu71xV8eDSsOAUc3q9bVpQLkb3V49e8jF+fgdwqkjCw/7TC/jRhm/7FQR0K9a/PjeSD+ahvgzcVFWxhaRbYn2joBVLAKH0zx9t/+Doq5P0bHIMSk66ZSJ2ojH/oLxpcdsMsFsKRLcNbqmZPuvUQyD+krMQGmQz6UPTfcbxR4y25gWZMDs8X21acu1zIqtRLOOdyQ9B5JaxGW+eIqM+a9A936C7ZxdX2aFKT6D9nhXUSNaogwElFq4T6dDJ37nGBGLUvV2UYCfCtWedYyjxTUeVDzE+CtCMCi4YXKX4cFbgbuVILK/QA/0HtBLJZqCOo60qBUopbuPjIbSgc0BFdMGc/LKt1VgXG7dM19+OAHhOJUYlhLYQdxL/0PFVXVlQ6U21GUT5RuYpgE+V9hoHEMXx6UvMXiyz2dtgPdROfs0K1tEV11mx0S6KyeIloCX24Kij+RSRkKIqmWOJc21JoH4gLvd7Y= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 31:b6MR2nnvtenaGVjLnM5yWdJE5MjqIcpbp7tn0jP7aROSJlqgZ0dcQVU9hRPEoWRiynAmGtr8gWD8aatctczbPx1BMf27+uKNbikE8q5MUCQLwP0DwN/ZUyQ39nPx1CTeaIqoHByUzvJBY5Wp25aE8fXRc+9YVocY3yRzmo2frKqXt+y9twlYeroc4Oj1qo7cV2wKkuVwC2NY3pSq4+Q8XFgh/x3NmpDZSDqUsSsMYfUJsnB155NBIHpBuUjvVdHK; 20:NCVekJQuqnODnewMzi2sHFbfk+rk3l6Cp17orpxd/OErkQ0v1ntBXYRHl0A7ChgYiutB2Svk3EEXjkN5MJ/wmOnS+g6t7N4e4UROnAwI94MMl1aLZTVK/mWMycsfK4kbP++HSe34cDCtMBnlDS1kXaM1Iu44CeqK7x+See3WLsadmS7SCQMgvuN4vemF2qcmegYbw3dmuVuQd9zDGkZTbmJBPeZfZDkzZB6iSbBAKkrbSrYKjXIcOx3W4pCb94FgCKgG/xv0SEc5ragxYyBRa41qi0rtPzqq33xXfuxS86EAmjVxgSR/wiF/xAkxBu7xAZRvHl2Fdv8wcqnNVMyKQIoLsDyJhpKklgT/rCFbarU/+9PiKoi612to6d7odZmOgTu2TMP1fumyywjkLNFFXExGbT4w0SAuiEVRRfIPTtjjmRWpebcx2LlCgwXUtTJBTXhJdOossGfKvo58Gn5GBDWJOm3kbd60YNL1uMampZURIEKxi7ZZiprW4gp5VbG497f0Apq7SQ0YRHQgqQ973OEj6si5wtlvHTehOUzI1w3u7gkRkpJQF0uPOPIO0AjgZIhck6wNpUI/snw13boiuyWWxf8dz3q/mGSBafHcFao= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6061324); SRVR:SN1PR05MB2191; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2191; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 4:tyTqH9NJGOBgzGT+cJwOBquVtqnthavjfroFoRSaf1E4qNpo+1HyRsvzYqwBgIBNCz36bOeFzDbh7/SE22aKzqWAJP2iy5rvG3cbRvxwlZhiAyfHQP7nhPnumWwqh0FxI24rv7JMEHkqcMtFdspZhzhFRMmIw5a9zYqOVH0KcAwEbgfm+7hcBtlfJVJIEgNvmBC9SPUZ+WiAaQO3acx6d9J/qlWod8lq72OxDSssko53deDejEtIOxZ7JgqyBNmFf0sTTb4RiONh/O0CScdfqW/ftV+4HgLShiGRoT0DPbYNYPuKl/TiUc/NamHPupzNPgm5Dogk28pcMSFXeDyw9tIKxnzdhCzV9srtfpNPK5Bw+nYsbbSTbyhA7YC4GgCHFUjFWb6afhNu91sjo6EKJS7En6oErqOwgHdCamKQ6iGcxsBmnvnUFfKKj+lJWvbk X-Forefront-PRVS: 0126A32F74 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(377454003)(189002)(24454002)(199003)(2906002)(7736002)(305945005)(97736004)(5001770100001)(4001350100001)(5660300001)(101416001)(65806001)(36756003)(65956001)(81156014)(2501003)(230700001)(23676002)(64126003)(81166006)(31686004)(229853002)(42186005)(92566002)(68736007)(7846002)(76176999)(54356999)(8676002)(50986999)(3846002)(6116002)(6666003)(31696002)(66066001)(77096005)(106356001)(86362001)(2950100002)(33646002)(50466002)(107886002)(47776003)(2201001)(189998001)(65826007)(83506001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2191; H:[172.29.32.171]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1TUIyMTkxOzIzOlViQVZwOUZPek5pNTdIS25NVTVxVzUvZ3J5?= =?utf-8?B?amNybi9qWWNNaVZ5Rjdiak9TMlZEMzJxcTkwbE9JYXV1djRPQ2pjd21RNzBH?= =?utf-8?B?ZXg4elRYUlZISzcxVWlxYVU5ZkZMYkhNNWFtK3VEbDMxYkwzRnVpQVpKdDVM?= =?utf-8?B?RFNQOEZoSjg3VStqSXByMTRPZHJHWEFBRk5mY0NjVysyUTR6a2YrWjlUTkFq?= =?utf-8?B?Q1JZSlA3OUlvcVZQU3RCOWxKMmpYUHNSUGVRU0hNd0xwZFJwaVRDQnJBTDR1?= =?utf-8?B?Q01YdUpzTGZ0RjBRZmdjdkQrY0xURk1YUXlKSVBwaUx0bHhEUndzK2ZjbG9L?= =?utf-8?B?cGpFM1RHMjU5Mks5bmExcUtveXJPd0dJMHA1VFdacDYwTGJ1SVlDQnkvR2FJ?= =?utf-8?B?NkpIdm5oamRQNnhDcmZMbThCaGhwTmIvZnVMTGFybklERm9qVW12SWtvemda?= =?utf-8?B?NjFJSFpmaEFndWZiWm40U3JGczhkRktIYnBLUUVjbm16d01vOGozanVXWFgx?= =?utf-8?B?Z1U3MmxuYVlJT2JRWVUvWWlsWCtKbGNyd2ZNMTBCQUdzbHVsOERJVFNXM2l5?= =?utf-8?B?THMvWEZ1SVYxc2lRdVhlQ3RFZHB5bHpOY21BbUQxVHFWQWpjRVNBVWhpSHpM?= =?utf-8?B?YTNxa0ErdjQ3djBYWllQYWh1WFVvQklaYXZJREtZVWtSUThqb1VXdm0yMHQ4?= =?utf-8?B?Q0lIZ1RxaVVoNDFjdnlaWUhJa0xXbG93akpvdjhldm1xd1FHQ1dFQkJnWkwv?= =?utf-8?B?UTh6UE9ZWkN6d3lXak9pWGwxd1lYQXp3YmtwZzByZlVxWkVzL0MySHF2YkZs?= =?utf-8?B?YkdNYndML0NTOGtPWFc2ZUtrRXNWc0JFWDNFMWEvNzBGbWNYeDNKamVyUzgr?= =?utf-8?B?NEk1YjR3MjM2ZUVIdUlMWmVUU01ZcjFQMGt0bzFMM2tOT1hsWUc0Qnc0dUVT?= =?utf-8?B?QWcrTE9NT0ZhWFVoTzZ3R1hiNkRVc2hwclhha3dvWVFYR2lGTjFnNTdhZ1ox?= =?utf-8?B?a1kyaytwTkM0YWY4NXgwWEsydWNIY3U5T0gzOGh0NGltUVppMnVDdGVwK292?= =?utf-8?B?Q0xnU0h5YmtaSEVGOWpObE5KQjBibm5Mc2czcHdMTlVHa1ZxdmtLRjlnNTd4?= =?utf-8?B?SnMxWk1FNFk5dmc0dG5kWU9zMVhpejRxQjYyTmJpVmpHN2xwK1lGQzBRdTZa?= =?utf-8?B?ZE16M3BoME5QZytHQ3hMbkQvREFMYWdUZ1pmM3piZGlTN3h6akZBNnFVdk9Q?= =?utf-8?B?bitrbmc5OTZFdnVZcFVIWmZTai9mdE53VnFmMy9zSVJ5NitRRFdVaFczdUdJ?= =?utf-8?B?ZU9QeG1lcDVLb2pHMXZ0ODNRZmx3V3NRd0lTVklaRjRXc016eGJFNnQ4Wklj?= =?utf-8?B?eTlTbWRwQm5lTU1TSDRPRmRCVFEwekw3bTg3TGI0Y29EWkc5SGw2bm5iUktm?= =?utf-8?B?SlBTVGl2QXBDVTFJTEN3amdKWUZlTG5zd3Q4bWF6Z01OazJvdDVoVGY3aXc5?= =?utf-8?B?aGVZdm9iT2txRmZLaDFBK0pReEh0SytCczJlMnNQY2tCTjVUSkxqWUNvdm4x?= =?utf-8?B?UWhrajRRbUdObmJOYVVIVVlGTkFSYTQwMUMyNFZFZUFhbFZtek1OWWkybmRv?= =?utf-8?B?S3M4K2VyZjdWZ1lMSTRNMUR0M1dnV2x3dEp6Z3VrMzgyZ2hiak1KSTZVSHFZ?= =?utf-8?Q?gKnI7Cfc7gQ+G40cFBfvMmsPPJJcox2j+0i+E6u?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 6:dlrj1I0H9JnsYQEcafDNLZRpZkuo6PnjmS2ixay1NetW3r0cgSM9TPl5awmQbvDQ9+TUhtozsoX8AWaKj28iuGkgQ4WfexdsgYjpRKmSOH2uawh4bjNYXdnVTnK3uTrlthnMO/3w6CoOjEaJlggRFObD9ujLniCORgsB6o8nTK5hHUjht3I/+h6FHWyPQ6fFI3qvIXFWtg6+pGxRmWzyO1S6gBMNDRKZ0OhHMH8HCq7bd7iedtJXTEl6EbYax5TYWW8rFbnbxvXdQhNlEysqcfP6xKT+125S0JRDKfLJ6CNyJs56XZ9vSMCEmnBsspZOTDvE31w5iAg6CyW2/DJraoHSoP9CrPwSxvjgBKpCjxpMtzGf0iKtqKrg0GHXJfKB; 5:HEfWafQm6I0ZjE22sT8UQeSFgWeDHUMLkPwcmVUtCX9ZEDYNAZcuhrsS94XIioLliDhxUki3cv0B+aYeVb35Ygb3JDp5g68zSNaF06dlklJrLarjLywazI5wlH+MxPZOb/bp816PphoimNNb8gNNQdTXukPJE5vzG8kL4IuTsUY=; 24:OgfTEFZ1GytSI1TAHMrRnN1iE5p5quFGZ2ZOlPUDp/7lyD1hQPKzOktTLO8ZAU+bPgy3nkDOb1gDWyL3zl1GzBBHM5k3N/NoHbCVwK2D8dE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 7:eXJqYcWgpzotDnhJerTAPX+t7zlKP8Qq5AS1KY6Y+ZYNAtfcoheCx+xEEIKQn6G5pa7QbHMBU64Na/9/SYmocwwxXV1m821wYkDDjgyTw8iPL4boaLX1MF/nkPRvsYPmcH+0lKckKBjKtRCdAatrwea31g0Evcge+Kv3P0c0ogPfWGsWlXHVvdFnSzPT1nUBk/KWim1BWYxye+/6Fr2FkdIFmroPbRhBFt1NfYaD6hYfWK/bMgj91avQiLYerGA8u4FJRWQG2tIJVtncDKGS/izrQ/c9ErZKrCP2F068aBdQTEqTwO7uiz4p+wlMBBowQx8WxE9UrzI5Ct6DSamptf5MShqpAw085XLKASON+Gs= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 20:27:09.1482 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2191 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 14 Nov 2016 20:27:14 -0000 On 11/12/2016 6:22 AM, Joel M. Halpern wrote: > One of the problems we discussed with using incoming port to > distingusih things is that depending upon what kinds of transport are > used, there is not always port information. There are sometimes > separate interfaces. There are sometimes separate source addresses, > and sometimes there is simply no information provided by the transport > as to who sent the packet to the SFF. Yes, we could as a working group > declare that there must always be distinct sender information. That > would be a new requirement on the transports, and would complicate > cases such as using MPLS as a transport that some members have > indicated they consider important. You don't need to know the incoming interface or the source address of the previous hop. The only information that the transport needs to provide is an identifier of the transport connection. (Or in the case of MPLS, an incoming MPLS label.) All an SFF would need to know is that a particular packet arrived on a transport connection originating at another SFF. In the case of MPLS this is particularly easy, as an SFF could advertise two labels: one that is only to be pushed on a packet by another SFF, and one that is only to be pushed on a packet by an SFI. I don't really understand the difference between the load balancing use case I raised and the ones Joel has described. If SFF1 sends a packet to SFF2, then SFF1 has to be responsible for making the load balancing decision, and SFF2 has to know that the load balancing decision has already been made. From nobody Mon Nov 14 13:06:42 2016 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 4D0521294A2 for ; Mon, 14 Nov 2016 13:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 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=-1.497] 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 1Trl4U9VqjWd for ; Mon, 14 Nov 2016 13:06:39 -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 006E512946B for ; Mon, 14 Nov 2016 13:06:38 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0319.002; Mon, 14 Nov 2016 16:06:37 -0500 From: Dave Dolson To: Eric C Rosen , "Joel M. Halpern" , "adrian@olddog.co.uk" , "sfc@ietf.org" Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSPD2ZgDa3IiYdtkCDma+QNmaeP6DUlaAAgADz3ACAA7y/AP//s1RA Date: Mon, 14 Nov 2016 21:06:37 +0000 Message-ID: References: <1ypecpkt1ytfupauiypd0v09.1478883842516@email.android.com> <294a889e-7686-2d2e-3b62-70ab38a41c96@joelhalpern.com> <55101011-eaf5-aa39-1746-17c66465244e@juniper.net> In-Reply-To: <55101011-eaf5-aa39-1746-17c66465244e@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] decrementing service function path index 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, 14 Nov 2016 21:06:40 -0000 RXJpYywNCkFzIEkgdW5kZXJzdGFuZCB5b3VyIHNvbHV0aW9uLCBpdCByZXF1aXJlcyBleGFtaW5p bmcgbXVsdGlwbGUgcHJvdG9jb2wgbGF5ZXJzIHRvIG1ha2UgYSBuZXh0LWhvcCBkZWNpc2lvbi4g DQpXaGVuIHRoZSBTRiBkZWNyZW1lbnRzIHRoZSBpbmRleCwgb25seSB0aGUgTlNIIGxheWVyIG5l ZWRzIHRvIGJlIGV4YW1pbmVkIHRvIHJvdXRlIHBhY2tldHMgdG8gdGhlIG5leHQgU0YsIGF0IGxl YXN0IGluIHNpbXBsZSBkZXBsb3ltZW50cy4NCg0KSW4gbW9yZSBjb21wbGV4IGRlcGxveW1lbnRz LCBsb3dlciBsYXllcnMgbWF5IGluZGljYXRlIGEgZG9tYWluIGFuZCBoaWdoZXIgbGF5ZXJzIG1p Z2h0IGJlIHVzZWQgZm9yIGxvYWQtYmFsYW5jaW5nIHNlbGVjdGlvbi4NCg0KQnV0IGZyb20gd2hh dCB5b3UgYXJlIHNheWluZywgSSByZWNvbW1lbmQga2VlcGluZyB0aGUgU0ZzIGF0IGEgc2luZ2xl IE5TSC1ob3AgYXdheSBmcm9tIHRoZSBsb2FkLWJhbGFuY2VyLiBEb24ndCBsZXQgYW4gaW50ZXJt ZWRpYXRlIFNGRiBzZWNvbmQtZ3Vlc3MgdGhlIG9yaWdpbmFsIGRlY2lzaW9uLg0KDQotRGF2ZQ0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmljIEMgUm9zZW4gW21haWx0 bzplcm9zZW5AanVuaXBlci5uZXRdIA0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTUsIDIwMTYg NToyNyBBTQ0KVG86IEpvZWwgTS4gSGFscGVybjsgRGF2ZSBEb2xzb247IGFkcmlhbkBvbGRkb2cu Y28udWs7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIGRlY3JlbWVudGluZyBzZXJ2 aWNlIGZ1bmN0aW9uIHBhdGggaW5kZXgNCg0KT24gMTEvMTIvMjAxNiA2OjIyIEFNLCBKb2VsIE0u IEhhbHBlcm4gd3JvdGU6DQo+IE9uZSBvZiB0aGUgcHJvYmxlbXMgd2UgZGlzY3Vzc2VkIHdpdGgg dXNpbmcgaW5jb21pbmcgcG9ydCB0byANCj4gZGlzdGluZ3VzaWggdGhpbmdzIGlzIHRoYXQgZGVw ZW5kaW5nIHVwb24gd2hhdCBraW5kcyBvZiB0cmFuc3BvcnQgYXJlIA0KPiB1c2VkLCB0aGVyZSBp cyBub3QgYWx3YXlzIHBvcnQgaW5mb3JtYXRpb24uICBUaGVyZSBhcmUgc29tZXRpbWVzIA0KPiBz ZXBhcmF0ZSBpbnRlcmZhY2VzLiBUaGVyZSBhcmUgc29tZXRpbWVzIHNlcGFyYXRlIHNvdXJjZSBh ZGRyZXNzZXMsIA0KPiBhbmQgc29tZXRpbWVzIHRoZXJlIGlzIHNpbXBseSBubyBpbmZvcm1hdGlv biBwcm92aWRlZCBieSB0aGUgdHJhbnNwb3J0IA0KPiBhcyB0byB3aG8gc2VudCB0aGUgcGFja2V0 IHRvIHRoZSBTRkYuIFllcywgd2UgY291bGQgYXMgYSB3b3JraW5nIGdyb3VwIA0KPiBkZWNsYXJl IHRoYXQgdGhlcmUgbXVzdCBhbHdheXMgYmUgZGlzdGluY3Qgc2VuZGVyIGluZm9ybWF0aW9uLiAg VGhhdCANCj4gd291bGQgYmUgYSBuZXcgcmVxdWlyZW1lbnQgb24gdGhlIHRyYW5zcG9ydHMsIGFu ZCB3b3VsZCBjb21wbGljYXRlIA0KPiBjYXNlcyBzdWNoIGFzIHVzaW5nIE1QTFMgYXMgYSB0cmFu c3BvcnQgdGhhdCBzb21lIG1lbWJlcnMgaGF2ZSANCj4gaW5kaWNhdGVkIHRoZXkgY29uc2lkZXIg aW1wb3J0YW50Lg0KDQpZb3UgZG9uJ3QgbmVlZCB0byBrbm93IHRoZSBpbmNvbWluZyBpbnRlcmZh Y2Ugb3IgdGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBwcmV2aW91cyBob3AuICBUaGUgb25seSBp bmZvcm1hdGlvbiB0aGF0IHRoZSB0cmFuc3BvcnQgbmVlZHMgdG8gcHJvdmlkZSBpcyBhbiBpZGVu dGlmaWVyIG9mIHRoZSB0cmFuc3BvcnQgY29ubmVjdGlvbi4gIChPciBpbiB0aGUgY2FzZSBvZiBN UExTLCBhbiBpbmNvbWluZyBNUExTIGxhYmVsLikNCg0KQWxsIGFuIFNGRiB3b3VsZCBuZWVkIHRv IGtub3cgaXMgdGhhdCBhIHBhcnRpY3VsYXIgcGFja2V0IGFycml2ZWQgb24gYSB0cmFuc3BvcnQg Y29ubmVjdGlvbiBvcmlnaW5hdGluZyBhdCBhbm90aGVyIFNGRi4gIEluIHRoZSBjYXNlIG9mIE1Q TFMgdGhpcyBpcyBwYXJ0aWN1bGFybHkgZWFzeSwgYXMgYW4gU0ZGIGNvdWxkIGFkdmVydGlzZSB0 d28gbGFiZWxzOiBvbmUgdGhhdCBpcyBvbmx5IHRvIGJlIHB1c2hlZCBvbiBhIHBhY2tldCBieSBh bm90aGVyIFNGRiwgYW5kIG9uZSB0aGF0IGlzIG9ubHkgdG8gYmUgcHVzaGVkIG9uIGEgcGFja2V0 IGJ5IGFuIFNGSS4NCg0KSSBkb24ndCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIHRoZSBsb2FkIGJhbGFuY2luZyB1c2UgY2FzZSBJIHJhaXNlZCBhbmQgdGhlIG9uZXMg Sm9lbCBoYXMgZGVzY3JpYmVkLiAgSWYgU0ZGMSBzZW5kcyBhIHBhY2tldCB0byBTRkYyLCB0aGVu IFNGRjEgaGFzIHRvIGJlIHJlc3BvbnNpYmxlIGZvciBtYWtpbmcgdGhlIGxvYWQgYmFsYW5jaW5n IGRlY2lzaW9uLCBhbmQgU0ZGMiBoYXMgdG8ga25vdyB0aGF0IHRoZSBsb2FkIGJhbGFuY2luZyBk ZWNpc2lvbiBoYXMgYWxyZWFkeSBiZWVuIG1hZGUuDQoNCg0KDQoNCg0K From nobody Mon Nov 14 13:07:02 2016 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 4505B1294A2 for ; Mon, 14 Nov 2016 13:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=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 oNkRT8XeTwoL for ; Mon, 14 Nov 2016 13:06:58 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0133.outbound.protection.outlook.com [104.47.42.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5508412946B for ; Mon, 14 Nov 2016 13:06:58 -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=WQO1cqDjyir3oDhsp4rf4pn35XJfGrPUEiRHCazNlKU=; b=WUbMTSyycbp9J4qNJ7lfTwIXRTPjg6WitsgFiLllHfgON0qVf/k/ySXkHrAWfaBDfWegn6zBPFRY44XDtsMteXCy9LfoM5MUHa7gobrkddJXX2QR/Ns7KgTpDbVwh9UQdjVS6lZaofhR1+yWRUB8dxb7YEUEN4tKwUs6SVJZMQE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.32.171] (66.129.241.14) by SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Mon, 14 Nov 2016 21:06:43 +0000 To: Lucy yong , Loa Andersson , "adrian@olddog.co.uk" , 'Dave Dolson' , "sfc@ietf.org" References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <71fee848-be00-9137-286f-4908125e62a5@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D572EC726@dfweml501-mbb> From: Eric C Rosen Message-ID: <37aa2696-34fc-54d5-f607-10d747ac87fa@juniper.net> Date: Mon, 14 Nov 2016 16:06:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572EC726@dfweml501-mbb> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: MWHPR01CA0024.prod.exchangelabs.com (10.168.201.162) To SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 2:CWR/t7UPeR9eAeyHrbbiKqrpMOp2cArlSdACbaukPJQVF77sRVIqTyaDESHPLsug52AJv83otzSAR2S3NHdDdmIevVebOvnTfCHoFovMhgJEA/kEtefaM8QiPV6a0kW+SWvXAw5RS7+DYdgbmbQo4enK8zYAawkEB/ZEhPKQt6U=; 3:l69PLUW/r7fgVQG9CXrnyXLuGwvPecDAxK1sguoYKpK2NdUgJsviBFVJgD4HTzXnXCNnedRG16lw5PRjr6Fhb98wQxYED6tcWFXq8fAKMA5xBhi4FpGz10ghl0xuSzo8C91udKk67qZcRAdzHYyeKaCfvrU5S08kTF/dMi7808c=; 25:/K9Li02lgTLF6jHwsuBGZAvd5RwRW8Q9bvNJTbfN29ylt7wDbh3XTOI/xMNTrJi3UhdQ/YY5jf9mmQ+aOvhelTILUIbqes3a9HFbF88ikdaE5eplNC+RvkrBMLF3ZiV0PwjZyzqxwiuXOK6ahvwplOQzF5HiK5Ex4qsS61wKP+kCxpxynKLaLWC9kKfEf0c6VjBJVdOjl/ysXHjuj6vahyt1SreqDasBie/Zng4oC3iMrQnia+Y5m5lmIGlezbmYksBGud5HpEAyHnPuLTVT+i73Qkt47EtLP1/gBfrtG/DfmEuySsBM/fZVE9O4iQ1MSNk8mgUqXOALqBnqRLv+u6W1/QZlXHDWO0RdvwFaIMiRf5a8Iid5TIU00H4S14pasKiu0y7O1g7KC0hz+zyIpik8ks4HI9+bcb62i027fkk= X-MS-Office365-Filtering-Correlation-Id: dfaf91fe-4a78-4e78-4588-08d40cd223b9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 31:vQjC3jqyhnhb1mSNF/xuirWHklCCxyDDM6lq5oqm+rlKaHvAeEHuj/qk1RP+ft4+oYw0y5OZKsfoHh68lUwdAjOX7fEICmf8pJVEXTdnAhi7dV4IIQpsv3s8DTXiiDi1KMEI1SpzPXoOxgmgifmh3A10Za2Xc57YwDxIOQ1ovtVFv7DBnUBxHMl1R+jj65cmB4wrFYd32N8EJfyuR/hDppozf5QBqBXmGYNLiV2AlFlNKpAHoFsmn+iRj40cN0OS; 20:knGthYBvF0DgwqxcauhG+6ZyuOm8tpcRqRivh178IV2kVJPQNvsHtpezJlNTZwPXACRnvTZLuav1eAvRPJaNvsJ2O471+SfzVrdOIpy7w/kbjii4vuUYduIfOVrLi0p9DCvq1ylKAoPSMb5+L8zYgIVmYVPLhsuMeOfYgRAgzaUyQVtQ9ibpYIvyZcV0DNFQv0vIOfsMYtJYcAZU79f8g7JjbRrta6VTMEos4/sv9LchnDawrxMzNXFcWLNvGUorTBvnHmbr3HDw+oR+HwARWN7oy73ETWeTrd+rOKmq+wW51S9Fh11//N2wmJJFPtH0SHc0slD3yTL8jdmhlpTzssP0xxqX7EzUJsNclHgp3xj/fRJkMTTdGhFOr8QbnQyigFXuuGJo1zNUhd8Ew4ZngpVGUfkkCJ+iJWF1tH7PHtWlOJWqVbbdE4mAtTlqyAYLmLlV++fSbyGfGCSJ34Fnf2Sva6ctC5kS3KYSiLVNB+qyQVFkVMmS2QazpypuYytM0s01Hald1LXoW6JxFqy+1IN9MiZYEVBu4R4sjYQSF184y3la6q9S1NhFCUQW4l9xk/aYq+n6BwBF1Zzw9EXVLeg1v3dvZu5fzTzx+4b9iB4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(131327999870524); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061324); SRVR:SN1PR05MB2189; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 4:TbEkprkcPVioRoG60zD3Eo+AiFAEP+tgy9TN/3huzEfv1zb4Iu4dhLZFCo54L87X/d4ynO8whuRuXaZoCuzsMA0kiTtOwYrJ4OeMKb39cMzGGlcBcfOzfninUAIOCrtozOjWv0jt/sp6TUD6KJMsp9FQ5mXnKAM2pp9zyX3hjGO1ma3DRd3Ikmx1AIg2wONQrfJRCUI779kJ5y+V4MgZTyUUmwXQhJt15afwN/bw9OsqoUlXdAqIvbuhZMmMJS7bzu3G9b8wuWDblc6SxPBPwRU4kEmMHHDwIaVSZGHD6g30OHyTXPacjgTPPZM2OKYx7/IWQ2Qz+HBRsGZGlWVErqhjd5IQ02RqCVQJmzgYZoL36W8i/LlHxDlzvT7ESkjz2TrhcLi97ahEYFuPsRZIHtKma9cvwFoCqc7pnwVPdDt0r1SmIHPbTHiirlSkpp5SZR2Db1T2VDol1s0jZNBxILhFwVX/rfPloIb2/QNm1XY= X-Forefront-PRVS: 0126A32F74 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(377454003)(24454002)(189002)(199003)(92566002)(81156014)(2906002)(81166006)(3846002)(6116002)(107886002)(5660300001)(83506001)(31696002)(6666003)(189998001)(2950100002)(5001770100001)(4001350100001)(86362001)(97736004)(229853002)(23746002)(65826007)(101416001)(7736002)(305945005)(8676002)(50986999)(76176999)(54356999)(93886004)(50466002)(105586002)(64126003)(106356001)(68736007)(33646002)(65806001)(77096005)(47776003)(65956001)(5890100001)(66066001)(2501003)(7846002)(36756003)(42186005)(230700001)(31686004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2189; H:[172.29.32.171]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR05MB2189; 23:qvMts+NEGZ77tnsGwZK6+UpB0B5ZnVXEyI57D?= =?Windows-1252?Q?s3ShAx5j12GufELFl0zQO9mgD4AO5WBRqDM4XwatuZwqE3PQtXhgtuA1?= =?Windows-1252?Q?c1/yTxDac0qrWfY62Zty7BAKyBaHmqe+MUmTe/00xHKqGaQd9jWlWFjf?= =?Windows-1252?Q?AyyzQszjetMeDXDdd7dT6oPJpnJvAInMly6gzHmmip32aIUnSoJOcs2b?= =?Windows-1252?Q?GSHlw56HtKG7R6y0xG6BY1ejPGLPATh+8nm8zK/oP/FYD64lKnMx6xoq?= =?Windows-1252?Q?oR4aB+tPIStiSoWObCQ5WVRzPHOmjv7ureDF6smvMW53cCOH9RjebVD6?= =?Windows-1252?Q?9xrAfSyWbPZYrALaGBr2yMGGaEfv9H+eLRKVKV/Mg+6mS0af9MJjqZct?= =?Windows-1252?Q?oq/sxcDlQx0gup/QbO8wu+tgVYvay0of60VHAt/TfndVi18N1TWijsL6?= =?Windows-1252?Q?l1EZc3w0cEk5TOdhWjjEKcY4FFjoBLjdXyDLxlXOp9KupbjWeziBsEb7?= =?Windows-1252?Q?N4TOkfYZwiFAZ+1gnMbg84XX2ccOCjGQXBRj/cCy0+LLtI25FxGzyWIv?= =?Windows-1252?Q?T1K/ny2bLClEZ2S3EPbOhmmYjDO+smqbYTPDHRL71+t4O3SaN/ik3g05?= =?Windows-1252?Q?zwZCJ6kb6/r+xnMVFKqZK086CHh3C0Gx8zkRtSrz7JqryIIi54v6E92a?= =?Windows-1252?Q?kb9xfX6Kp9VzAG3dFZR2u8V0L640airuNcD4Cetg2jWGzi/8rU0tgAfM?= =?Windows-1252?Q?fcI6sNr/yomWJxZVGoUFifNAirRg7zSCYiNaubxmN9NufEaqgaQNep0r?= =?Windows-1252?Q?WtiIApq0+LrjVfFfWd6K+DZZjcM4Drr/J6pFwt8ftOts08Pw6Ex4T2Yw?= =?Windows-1252?Q?QGrGrYoDEkhKLocd9h0yt9W+fl1kjPA+0ALNE1dvudmSbyBec76RqsmA?= =?Windows-1252?Q?8LXchCpWNt3RWhR4XcYoijr+SlejWWMjmMCedEIT8gSXJhvyLgSIoINZ?= =?Windows-1252?Q?YZNwwOuw5WLFkoF98ZHyvLT5m3Hm1d3uQ/qk7lkT+Sd9ZrVeiqAh9r8D?= =?Windows-1252?Q?i/z8IKeqrJIIXZX1IL+uB/ifGHx/Yu6AVajt0rpRRQ9g1ECkwQb5f9Jm?= =?Windows-1252?Q?hZMPlwDf4DLKtAPs3G+mSIn8ZzXk8LL57ebEjxNB6ejs9GjovRQBBBY5?= =?Windows-1252?Q?a8iw48tjRFTogSvnofksdxBrg+DhoH8pmwvMJxpNyx/2y8wGEiZVlltp?= =?Windows-1252?Q?ppjihKlzIHKAdpsVS6ag9/HC8gi9m2dt4tgCyCD4FH1tjkf0yAgalRig?= =?Windows-1252?Q?KRmkxqzZfSRcKLMCJFLjQPh1tL+0z1hkR7QJURUUtyDjTGzCv6ULY79C?= =?Windows-1252?Q?UOPY12PzSrnBEx/617j4VnjGBCewIEisVz/tjlbUJLSOhnx7VRC8oc?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 6:ZWwQzcnieS3IGLBZeD96rRGOb6h1I9C7Tcq83pRipzzTx0/VQvQw476MNdMZYZVHEWEU9VYNFQf34LYegZ045KAYiY0i9jtNhnCyDTC59sPfVzkYploEUbVlaw1dBxXDpFBnSZAYk3RKtB1XIkgIa8E9yd4e8A3Oo17FCWcZFHf04OxZAZKduvEamcdlwEqBBlgJHbspwzWO5CktneD+UUmyJITtuBe0UZcOHpPwocOr5qZT53zG2hDKxAgv8dRkcP5HUNGd8h/A2LqNAyIhol71ZHWH7ZvcArFHXkhr5PA9QtL+Hgy9bLvAG0uSzYZjvhE+QeWGVYWjew7ENjy7HfFlSIxHtkCLEbbTHzk1SETemFTpGjiNte84MzQO4kJb; 5:HJh5B1ECSFduVRG8/f4ocuGZ6Ho36CdjMXZyCq5U88SOGgpPiMfP7zwATtaIqXqUe0/0tEKuCI+alf4uWDBwPngdbihMNt48Giyse8h5cUHrQpIB0jdLCeksBfPvxQq51DbYYnxn17AfFwBsgZJvb8GJ2zjBz8/9D/Ku7az5b5c=; 24:dL5WWz7e4EVNKjmmQl84dGMw0KlXBct4TwQ65XtSVMW9m6ay4R4Unu5T+gF67llteUl2cff6EjFG2W/uyvxsMGd1l9UblenI3JfqgtL9WrA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 7:DcCRn34rdHx19T5ce1N77tTBgA5KsrwzJ5YU3CqWGHfn8/MNCH4fhabv8hxc6jpzkKW4gQXXycs0sB/3z7Tqpqfz3d74DuuzG/YW/57KOC7Jl85vkwPDHHMFqjD1XBGUqd1j6mWTt5kQeFIHKPw7InbD0gpVM5qxL6IpkvmC7Y7xsHYpywuNESv4FcV/qIFhmYQ6EM3DWmnUFY5g1evbSPrzFybRzvsDg39ZqsB1V2of7DYVfymqwf0K2SihpNrvGmFpdSh+LaOXJMZnUg7plYdsQs5aokqwIza6NBEFXDxyq+4XK1cPFFM+2dzmC5ZGaIDYOLdbVABG4f2yy4NEjWFvW+1MvQtdsATzw5whAhU= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 21:06:43.5902 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2189 Archived-At: Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 14 Nov 2016 21:07:00 -0000 On 11/10/2016 8:41 PM, Lucy yong wrote: > Hi Eric, > > "You want to be able to add/remove SFIs from an SPI without changing the addresses of all the SFIs." > > Long time ago, we argued that using SPI/SI to indicate SI's location on a SFC path has the nature where adding/removing a SI to an SFC results the change of some SIs locations (those after the SI), thus SFFs have to be updated accordingly. We thought that is bad design. I would tend to agree that that is not a good design. > The counter argument then was that, adding/removing a SI to an existing SFC is considered as a new SFC that will be given a new SPI, configuring SFFs for a new SPC is a normal operation. I don't find this to be credible. Management of the SPI name space is an issue for the operators, it's not up to the WG to decide that the SPI value must change whenever an SF is added or removed. > Not sure what convergence concern you have. Suppose SPI 17 has two elements: SF1, SF2, SF3. And suppose that the respective SPI/SI values for these three SFs are17/255, 17/254, and 17/253 respectively. Now suppose we want to remove SF2, so that SPI 17 now has two elements: SF1, SF3. We have to change SF3's SPI/SI to 17/254. During the convergence period, some nodes will think that 17/254 means "SF2" (old value), and some will think that it means "SF3" (new value). Further, some nodes will think that 17/253 means "SF3", and some will think that 17/253 is an invalid value. So consider an NSH packet, with SPI/SI 17/254, at SFF1. If SFF1 knows only the old value of SPI 17, it will send the packet to SF2. SFF1 will get the packet back with an SPI/SI of 17/253. To SFF1, this means "next hop is SF3". Let's suppose SFF1 forwards the packet to SFF2, because it knows that there is an instance of SF3 attached to SFF2. However, SFF2 knows the new value of SPI 17, and hence thinks that 17/253 is invalid. So SFF2 drops the packet. A packet has now been lost during the convergence period. This packet loss would not have happened if we had not changed the SPI/SI of SF3 from 17/253 to 17/254. In that case, SFF2 would have known that 17/253 means SF3. Also, 17/253 would still be the last hop of SPI 17, so there'd be no confusion about when the chain was finished. > Do you want that, if an SFF can't reach an SF temporarily due to a failure, allow the SFF to resets SI and forward to next SI? > > That's an interesting question. I'm not sure what the desired behavior is in that case. From nobody Mon Nov 14 20:51:28 2016 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 760701296B4; Mon, 14 Nov 2016 20:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.697 X-Spam-Level: X-Spam-Status: No, score=-105.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 LXga9ZrGGjiV; Mon, 14 Nov 2016 20:51:19 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D22371295A0; Mon, 14 Nov 2016 20:51:18 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 1828432D15E38; Tue, 15 Nov 2016 12:51:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uAF4p884013238; Tue, 15 Nov 2016 12:51:08 +0800 (GMT-8) (envelope-from ao.ting@zte.com.cn) In-Reply-To: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> References: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> To: Joe Clarke MIME-Version: 1.0 X-KeepSent: E0C8E185:E9352F17-4825806C:001A69BB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: ao.ting@zte.com.cn Date: Tue, 15 Nov 2016 12:50:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-11-15 12:50:52, Serialize complete at 2016-11-15 12:50:52 Content-Type: multipart/alternative; boundary="=_alternative 001AA81C4825806C_=" X-MAIL: mse01.zte.com.cn uAF4p884013238 Archived-At: Cc: sfc , "sfc@ietf.org" Subject: Re: [sfc] OAM work 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, 15 Nov 2016 04:51:27 -0000 This is a multipart message in MIME format. --=_alternative 001AA81C4825806C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrA0KDQpJJ2QgbGlrZSB0byBjb250cmlidXRlIFNGQyBPQU0gYXMgd2VsbC4NClRoYW5rcy4N Cg0KVGluZw0KDQoNCg0KDQq3orz+yMs6ICAgICAgICAgSm9lIENsYXJrZSA8amNsYXJrZUBjaXNj by5jb20+DQrK1bz+yMs6ICAgICAgICAgInNmY0BpZXRmLm9yZyIgPHNmY0BpZXRmLm9yZz4sIA0K yNXG2jogICAyMDE2LzExLzE0IDEzOjA3DQrW98ziOiAgIFtzZmNdIE9BTSB3b3JrDQq3orz+yMs6 ICJzZmMiIDxzZmMtYm91bmNlc0BpZXRmLm9yZz4NCg0KDQoNCkkgd291bGQgYWxzbyBsaWtlIHRv IGhlbHAgb3V0IG9uIHRoZSBTRkMgT0FNIHdvcmsuDQoNCkpvZQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoNCg== --=_alternative 001AA81C4825806C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6w8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknZCBsaWtlIHRvIGNvbnRyaWJ1dGUgU0ZDIE9B TSBhcyB3ZWxsLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhh bmtzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGlu Zzxicj4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9 IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Kb2UgQ2xhcmtlDQom bHQ7amNsYXJrZUBjaXNjby5jb20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0j NWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyA8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3NmY0BpZXRm Lm9yZyZxdW90Ow0KJmx0O3NmY0BpZXRmLm9yZyZndDssIDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj7I1cbaOiAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7IDwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNi8x MS8xNA0KMTM6MDc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0i c2Fucy1zZXJpZiI+1vfM4jogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W3NmY10gT0FNIHdvcms8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mcXVvdDtzZmMmcXVvdDsNCiZsdDtzZmMtYm91bmNlc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8 YnI+DQo8aHIgbm9zaGFkZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgd291 bGQgYWxzbyBsaWtlIHRvIGhlbHAgb3V0IG9uIHRoZSBTRkMgT0FNIHdvcmsuPGJyPg0KPGJyPg0K Sm9lPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJyPg0Kc2ZjQGlldGYub3JnPGJyPg0KPC9mb250 PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYz48 dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+ DQo= --=_alternative 001AA81C4825806C_=-- From nobody Mon Nov 14 22:44:13 2016 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 9E55B129A25 for ; Mon, 14 Nov 2016 22:44:12 -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 5JWuN-_ASi9s for ; Mon, 14 Nov 2016 22:44:10 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 11EE51295DD for ; Mon, 14 Nov 2016 22:44:10 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id f82so147225672wmf.1 for ; Mon, 14 Nov 2016 22:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0GA3YML7xNyKxlnwRitU4mWUVxCevjwRqK36aOD25zU=; b=nXpQwYZPcKrRxeU4cKYofi4Ep9MCTbxDCeJT6BlR9V2JhPXjn0kI/CEN4oAOgNgXWN OgMIfb2DP9PT7vWGTcchYIqWOGW2hBnwFKzxw30llzoNLWVvmZmJzQeRvrRuqkTyiJym OGDcq1bJjiWNgbyFInVZbx3zjlYWblWMiSU534ii3YOCwEM2xWFIIDu1eFyXrAsrS0Xw NI5QC9tJ4WW1edCrlS+TAfiOJxT/W8qutN7yXNRlVGT+5dvVkYVBjeeSlE7lUI2NFsXk bP+JcJ6Tumb3Th9NDgle278+DLkMXeRysLr9RQi/baQpwZudS7NOybf7LTUi1cpQnDsa Gs6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0GA3YML7xNyKxlnwRitU4mWUVxCevjwRqK36aOD25zU=; b=QiJxw9zEmCMqu3ERYAx1hRAvn6i7yvByQF5DcoCZN4gvTcWE4DLyFqwaxkfKExvFSI gOYyEdh64rceJRLqwkGTsM3oqiC0PpBgGo3cw3QKeW4Hqf8YDKZZSVtILojh8ZIsUKmh mpkB28xUWnRKeb0JAffCm8SIJ58K2fcEx5iQIf6vAi090WHQkZKUuxGlVwJELyNHaNtm 5mSi8riYb6BneUeHzBsu6xhyTDG4eu0sQNDVmcFKhhudi1gx12qxD39+y0CdBMqfd3YP +igzbIahNIA2CIhPjcWEpl4Vf/QpD77290ogUGma/lqGywfLBbzirWg9Zeo39NPEBiOt e13A== X-Gm-Message-State: ABUngveOzE1NkPm2XheJfL8FVDd8bBrPXthkjNajYqDmCm29kM1Te0gGEGKPNLhP4FOqtn/ulw8AgQpz9+mPFA== X-Received: by 10.194.201.227 with SMTP id kd3mr28003393wjc.74.1479192248529; Mon, 14 Nov 2016 22:44:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.146.141 with HTTP; Mon, 14 Nov 2016 22:44:08 -0800 (PST) In-Reply-To: References: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> From: Mohan Kumar Date: Tue, 15 Nov 2016 12:14:08 +0530 Message-ID: To: sfc@ietf.org Content-Type: multipart/alternative; boundary=047d7bae42428747dd05415148dd Archived-At: Cc: aldrin.ietf@gmail.com, cpignata@cisco.com, anoop@alumni.duke.edu, ramkri123@gmail.com, nobo.akiya.dev@gmail.com Subject: Re: [sfc] OAM work 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, 15 Nov 2016 06:44:12 -0000 --047d7bae42428747dd05415148dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I would like to contribute SFC OAM work . Please include me Thanks., Mohankumar.N On Tue, Nov 15, 2016 at 10:20 AM, wrote: > Hi=EF=BC=8C > > I'd like to contribute SFC OAM as well. > Thanks. > > Ting > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Joe Clarke > =E6=94=B6=E4=BB=B6=E4=BA=BA: "sfc@ietf.org" , > =E6=97=A5=E6=9C=9F: 2016/11/14 13:07 > =E4=B8=BB=E9=A2=98: [sfc] OAM work > =E5=8F=91=E4=BB=B6=E4=BA=BA: "sfc" > ------------------------------ > > > > I would also like to help out on the SFC OAM work. > > Joe > > _______________________________________________ > 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 > > --047d7bae42428747dd05415148dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I would like to contribute SFC=C2=A0OAM=C2=A0work . Please include me=C2=A0

Thanks.,
Mohankumar.N
<= /div>

On Tue, Nov = 15, 2016 at 10:20 AM, <ao.ting@zte.com.cn> wrote:
Hi=EF=BC=8C<= /font>

I'd like to contribute SFC OAM= as well.
Thanks.

Ting



=E5=8F=91=E4=BB= =B6=E4=BA=BA: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Joe Clarke <jclarke@cisco.co= m>
=E6=94=B6=E4=BB= =B6=E4=BA=BA: =C2=A0 =C2=A0 =C2=A0 =C2=A0 "sfc@ietf.org" <sfc@ietf.org>,=
=E6=97=A5=E6=9C= =9F: =C2=A0 =C2=A0 =C2=A0 =C2=A0 2016/11/14 13:07
=E4=B8=BB=E9=A2= =98: =C2=A0 =C2=A0 =C2=A0 =C2=A0[sfc] OAM work
=E5=8F=91=E4=BB= =B6=E4=BA=BA: =C2=A0 =C2=A0 =C2=A0 =C2=A0"sfc" <sfc-bounces@i= etf.org>



I would also like to help out on the SFC OAM work.=

Joe

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

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


--047d7bae42428747dd05415148dd-- From nobody Mon Nov 14 22:57:05 2016 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 637781295DD for ; Mon, 14 Nov 2016 22:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 l_mKXUeWJ7mT for ; Mon, 14 Nov 2016 22:57:01 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178A312956B for ; Mon, 14 Nov 2016 22:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=580; q=dns/txt; s=iport; t=1479193021; x=1480402621; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NZnmDUUreICRqYdl8nK32jUHeg0QKTqbjJc+fCFNNUE=; b=DfQZMIFveqtoGxFydcBTvtxtAoyUZEOf+ZjhiB5lysw3YHZSM0oBouY3 ZHx2WRHzmLKDWMgm1055c9nbMCzTjoockVGf7Lk26zFLIFOwQ8lepYBdC j6TML36PpHlACC2ADD6jto1LiDl+5cCZPDDAi0IduPc+FLv4XFM1dNjlR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAQA1sSpY/4sNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzQBAQEBAR9YgQAHjTerbYIHHQuFewIaghE/FAECAQEBAQEBAWIohGI?= =?us-ascii?q?BAQQBAQEgETobAgEIGgImAgICJQsVEAIEARKIZw6vbIIpi1oBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEXBYEJhTOBfYJdhEgXgm0tgjAFmkEBkGCBWQGOSJFQAR43gQQ?= =?us-ascii?q?chRxyhjKBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,641,1473120000"; d="scan'208";a="348380671" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2016 06:57:00 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uAF6v075026169 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 15 Nov 2016 06:57:00 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Nov 2016 01:56:59 -0500 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1210.000; Tue, 15 Nov 2016 01:56:59 -0500 From: "Zafar Ali (zali)" To: "Joe Clarke (jclarke)" , "sfc@ietf.org" Thread-Topic: [sfc] OAM work Thread-Index: AQHSPjUC2Eg3a+5ZkE6ci0H3B26sr6DZnoAA Date: Tue, 15 Nov 2016 06:56:59 +0000 Message-ID: References: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> In-Reply-To: <922826e4-d227-9897-a86f-e5b739ed6a78@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.130.246] Content-Type: text/plain; charset="utf-8" Content-ID: <929E8402F6189148829B616B0F89AF66@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] OAM work 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, 15 Nov 2016 06:57:02 -0000 KzEsIEkgd291bGQgYWxzbyBsaWtlIHRvIGNvbnRyaWJ1dGU7IGl0IGJlIGdyZWF0IGlmIHlvdSBj YW4gYWRkIG1lIHRvby4gDQoNClRoYW5rcw0KDQotIFoNCg0KDQoNCg0KDQpPbiAxMS8xNC8xNiwg MTI6MDcgQU0sICJzZmMgb24gYmVoYWxmIG9mIEpvZSBDbGFya2UgKGpjbGFya2UpIiA8c2ZjLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpjbGFya2VAY2lzY28uY29tPiB3cm90ZToNCg0K Pkkgd291bGQgYWxzbyBsaWtlIHRvIGhlbHAgb3V0IG9uIHRoZSBTRkMgT0FNIHdvcmsuDQo+DQo+ Sm9lDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Tue Nov 15 00:48:07 2016 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 90615129A52 for ; Tue, 15 Nov 2016 00:48:04 -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 8Asjeu26Sqzu for ; Tue, 15 Nov 2016 00:47:59 -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 5CAF3129A4F for ; Tue, 15 Nov 2016 00:47:59 -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 uAF8lvpr006422 for ; Tue, 15 Nov 2016 08:47:57 GMT Received: from 950129200 (dhcp-8717.meeting.ietf.org [31.133.135.23]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uAF8lqkL006402 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 15 Nov 2016 08:47:56 GMT From: "Adrian Farrel" To: Date: Tue, 15 Nov 2016 08:47:50 -0000 Message-ID: <040101d23f1c$f5d532f0$e17f98d0$@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: AdI/HNlfSFGht+O5QcGLyEOTwfRp0w== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22700.004 X-TM-AS-Result: No--22.982-10.0-31-10 X-imss-scan-details: No--22.982-10.0-31-10 X-TMASE-MatchedRID: J6o5iPn8/JUHEgQPy2A4oWA/V00XWjDtQxhbwXgdp1x9Q5/gynnG1mvR pLKeUdVVszdn5AsZVydsoOObVorcjToOKuJSTzbft1AhvyEKdj63dp6DuD+6wCT6mvI5Y4IS9Db qJlkr43futiMqNIaz7SFyczyoJ0Rq4MG9jJywnBVa14NJcKtRNIyzstdwoG+PnvbaEOoeixMONn COtDoJBZ6Ss6O2bihGHDnwvr6B+jQYB2fOueQzjzl/1fD/GopdyJ1gFgOMhOn6APa9i04WGCq2r l3dzGQ1A/3R8k/14e0= Archived-At: Subject: [sfc] Heads up - other OAM work 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, 15 Nov 2016 08:48:06 -0000 Hi, Sitting in RTGWG and OPSAWG today I heard preso's about "in-situ OAM" (draft-brockners-*.txt) This work seems to be aware of its potential applicability to SFC (well, specifically to NSH). In view of the comment in SFC yesterday that the WG's OAM is not abandoned and the tsunami of volunteers to help with SFC OAM, there is probably some correlation to be done. Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Zafar Ali (zali) > Sent: 15 November 2016 06:57 > To: Joe Clarke (jclarke); sfc@ietf.org > Subject: Re: [sfc] OAM work > > +1, I would also like to contribute; it be great if you can add me too. > > Thanks > > - Z > > > > > > On 11/14/16, 12:07 AM, "sfc on behalf of Joe Clarke (jclarke)" bounces@ietf.org on behalf of jclarke@cisco.com> wrote: > > >I would also like to help out on the SFC OAM work. > > > >Joe > > > >_______________________________________________ > >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 Nov 15 18:37:05 2016 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 24F7B129566; Tue, 15 Nov 2016 18:37:03 -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 azbo_Zx2DpmD; Tue, 15 Nov 2016 18:37:01 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 5471E129458; Tue, 15 Nov 2016 18:37:01 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id o1so33165307ito.1; Tue, 15 Nov 2016 18:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=j/M6OxQyla+z2OhTfvvlFRXmqj1BupUq0FpOSRyTcms=; b=gL52XFRRJjR1ObQdq+ls6C6y7n7RmF98Lg03mJWVvgrWkA5WuLGMHs2ece9IIc4SsV jufRF7ttU3KV9GRSaTT5xgf3BmbyUuWJRo1SJRuVnyTurQTRxGsRZNHrv+blqeeSIdci AUznuyQ95Y6W9yPcrnh64xhZpCsaUdgOpuHjmFn7oSdYj8FXljOhdaAxZMhz9SAwXs2J 9WW93LEqq/n0HfMLUiNRhDsWRci1bUGmM8gBodNR6XTTdzyO2onshrSzcZ0w1lsZKK2K QSWxXGzYJi8UjD2atI2mik0wpHIWIJ0mh9grdQ57VTJhGReY/i4wTI10RWMxjRp0MtId Dpww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=j/M6OxQyla+z2OhTfvvlFRXmqj1BupUq0FpOSRyTcms=; b=A7hzB3+j6reR9nq4GXcVAKVysEYUBJ69MsX2VVNp+rWUglX6rMXQgWW2hZwq8Inree owpe133o2uB91vJBJaR1VVLS3yxCutCue7Oj2mxT3tIHVWESENfF1d/BAyzMfb7Tlpcq k+9qicZjsCdDP+76/13pUBchf3GUE63fpTr0g1/s3XP7x9yGSG5NhpyG+7jMV9jWJjuA shl+snevK22qJBENP2+2tSdtNE+UEQW131F9t3ROnBLpQA5GQmvlutjIdt3pXZNqZOQ8 XOq0hqCFTsBe99NHW5LnnJXjXUwByZm38L0rvIQrnThe3BkDOpjlLjCcZdb81CRulV5S UdPw== X-Gm-Message-State: ABUngvdZCqa6rRWdKZEKQbu29DsmfN+td/pSWaN07yPPESIZtoEyKUaqkqQazufu+vgxBcuMdndi4pgEUgAiUg== X-Received: by 10.36.47.132 with SMTP id j126mr6006464itj.108.1479263820420; Tue, 15 Nov 2016 18:37:00 -0800 (PST) MIME-Version: 1.0 From: Sangwon Hyun Date: Wed, 16 Nov 2016 02:36:49 +0000 Message-ID: To: sfc@ietf.org Content-Type: multipart/alternative; boundary=001a1143d7408b9b11054161f270 Archived-At: Cc: i2nsf@ietf.org Subject: [sfc] Request to review draft-hyun-i2nsf-nsf-triggered-steering-01 from I2NSF WG 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, 16 Nov 2016 02:37:03 -0000 --001a1143d7408b9b11054161f270 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi SFC WG, This is Sangwon from I2NSF WG. The link below is an Internet Draft of I2NSF WG. In I2NSF WG meeting last Monday, I2NSF WG chairs Linda and Adrian asked me to request SFC WG to review this draft. Title: NSF-triggered Traffic Steering in I2NSF Framework Link: https://tools.ietf.org/html/draft-hyun-i2nsf-nsf-triggered-steering-0= 1 This draft describes an architecture of I2NSF framework to provide traffic forwarding between NSFs (Network Security Functions) to realize I2NSF=E2=80= =99s information model based on ECA (Event-Condition-Action) security policy rule. This draft focuses on the traffic steering for only security services rather than general service function chaining. In I2NSF framework, an NSF triggers an advanced security inspection (e.g., DPI and DDoS attack mitigation) with a different type of NSF according to an ECA policy rule; for instance, a firewall triggers further inspection of the suspicious traffic with a DPI based on its own security inspection result. Thus, our NSF-triggered traffic forwarding is based on the result of the predecessor NSF to dynamically select the next NSF without the predefined forwarding path. Thus, an NSF dynamically determines the next NSF to trigger rather than following a pre-determined SFP. Realizing this requires the traffic forwarding from the triggering NSF to the triggered NSF. For this forwarding, we added an additional component named NSF Forwarder (NSFF in Figure 1: NSF-triggered Traffic Steering Architecture), which takes charge of such traffic forwarding with the result of the predecessor NSF. In addition, we also added another component named NSF Operation Manager (in Figure 1), which maintains the forwarding information of NSF instances running in the system. Periodically or on demand, NSFF requests the forwarding information of the triggered NSF to NSF Operation Manager. If you could review and give us some comments of the draft, it will be really helpful for us. Best regards, Sangwon --001a1143d7408b9b11054161f270 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi SFC WG,


This is Sangwon from I2NSF WG. The l= ink below is an Internet Draft of I2NSF WG. In I2NSF WG meeting last Monday= , I2NSF WG chairs Linda and Adrian asked me to request SFC WG to review thi= s draft.


Title: NSF-triggered Traffic Steering in I2= NSF Framework
Link: https://tools.ietf.org/html/draft-hyun-i2ns= f-nsf-triggered-steering-01


This draft describes an a= rchitecture of I2NSF framework to provide traffic forwarding between NSFs (= Network Security Functions) to realize I2NSF=E2=80=99s information model ba= sed on ECA (Event-Condition-Action) security policy rule. This draft focuse= s on the traffic steering for only security services rather than general se= rvice function chaining.

In I2NSF framework, an NSF triggers an adva= nced security inspection (e.g., DPI and DDoS attack mitigation) with a diff= erent type of NSF according to an ECA policy rule; for instance, a firewall= triggers further inspection of the suspicious traffic with a DPI based on = its own security inspection result. Thus, our NSF-triggered traffic forward= ing is based on the result of the predecessor NSF to dynamically select the= next NSF without the predefined forwarding path.

Thus, an NSF dynam= ically determines the next NSF to trigger rather than following a pre-deter= mined SFP. Realizing this requires the traffic forwarding from the triggeri= ng NSF to the triggered NSF. For this forwarding, we added an additional co= mponent named NSF Forwarder (NSFF in Figure 1: NSF-triggered Traffic Steeri= ng Architecture), which takes charge of such traffic forwarding with the re= sult of the predecessor NSF. In addition, we also added another component n= amed NSF Operation Manager (in Figure 1), which maintains the forwarding in= formation of NSF instances running in the system. Periodically or on demand= , NSFF requests the forwarding information of the triggered NSF to NSF Oper= ation Manager.

If you could review and give us some comments of the= draft, it will be really helpful for us.

Best reg= ards,
Sangwon
--001a1143d7408b9b11054161f270-- From nobody Wed Nov 16 02:52:03 2016 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 E11D212969A for ; Wed, 16 Nov 2016 02:52:00 -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 zSJu9y2g_YIh for ; Wed, 16 Nov 2016 02:51:59 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 71342129688 for ; Wed, 16 Nov 2016 02:51:59 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id t79so63908249wmt.0 for ; Wed, 16 Nov 2016 02:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=OvqTqcTP4QeW9bpf0UT9pTI8WLads2sFUKrfIJwWrZc=; b=xLdApr9vyKDH1U4HlyRMczEuS1Cb17UGQ1TLnfY/0cIY0sp/G1A8xOQ935Tdb5Gp2Z uIUm7L5hpwEY+5970/dLei7eya0b2k4C4Fy+20J2BiNinI7keknEWTk8sZeJ3uApTYjH PSlVgRxkujI1X5ULhyC8jCgB0YtbHPmuYeGmKto24TEa4E9/sYzsQuEs75hqpJ/+zvS3 ng6ykgNpTEIbX2WnRw0Ctn+n4ElVhF5/mrKHz8iVeNFVxejaWxPeBEOk8rRGGP6aBVvk IyHlp696kpArRVxa3tCTS9luI9d1jDk37XR13slyAH3fyQ5HEhiXnMlefmSGj+qGvK9m dcAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=OvqTqcTP4QeW9bpf0UT9pTI8WLads2sFUKrfIJwWrZc=; b=E0TpBHzH4h1xZ1GfJRSiKBVkIoQ6B+OD+CrV7DH9owR+QcVVKs5qYk07+epyj62+cQ 3NEF5bRLEZj/mcXX8eQiJGgfNV9mV1BdQi/Pz2MtuBPhWFr69yRVlZ/+IKF85o9z5l0X rGUSDIPd+8s9sskzY4cPf/6G23cz84Edzk++wwISBu/hwPVcgDQctTazGdk3PcD1Bv/L drINyNj4dBEC/ei9NE3gtkEVEzQFn4oKD7Z69eD+w4W5m8D4Cgbn1WaxdKwKL/4O0EhT zLgLPbjQQPAHUEHN3dGo+QeK/QY6GqD4rCA/y03fE483i9do/aOycU/EBtylNXZRCt4O qMHQ== X-Gm-Message-State: ABUngvd5tBlWJytJU1QRpCJ4sGmlldRjX8sJkN3HYC6sV9d5v/lxQh4qE4vdQniddU1oJc53xyunUsSI+l0vzg== X-Received: by 10.194.186.177 with SMTP id fl17mr1380568wjc.143.1479293517927; Wed, 16 Nov 2016 02:51:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.129.72 with HTTP; Wed, 16 Nov 2016 02:51:57 -0800 (PST) From: Nobin Mathew Date: Wed, 16 Nov 2016 16:21:57 +0530 Message-ID: To: ddolson@sandvine.com, homma.shunsuke@lab.ntt.co.jp, diego.r.lopez@telefonica.com, mohamed.boucadair@orange.com, max.ldp@alibaba-inc.com Content-Type: multipart/alternative; boundary=047d7bb04c4ca7a044054168dc23 Archived-At: Cc: sfc@ietf.org Subject: [sfc] One question regarding IBN from draft-ietf-sfc-hierarchical-01 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, 16 Nov 2016 10:52:01 -0000 --047d7bb04c4ca7a044054168dc23 Content-Type: text/plain; charset=UTF-8 Hi Authors, Internal Boundary Node (IBN) As mentioned in the previous section, a network element termed "Internal Boundary Node" (IBN) is responsible for bridging packets between SFC-enabled domains. It behaves as an SF to the higher level (Section 2.1), and looks like a classifier and end-of-chain to the lower level (Section 2.2). Above is the IBN definition copied from the draft, My understanding here is an IBN is a normal forwarding device which do a classification/switching (Ex; OVS). 1) So this drafts suggests the switch to do the NSH manipulation also ? ====draft copy===== 3.3. Decrementing Service Index Because the IBN acts as an SFC-aware SF to the higher-level domain, it must decrement the Service Index in the NSH headers of the higher- level path. This operation should be undertaken when the packet is first received by the IBN, before applying any of the strategies of Section 3.1, immediately prior to classification. ====draft copy===== 2) This means that, all the switch implementation should support the NSH [here SI index decrement] manipulation, now may be not supported by switches ? 3) Why its mentioned that IBN is SFC-aware SF, even though its doing a classification for the upper domain? Please correct me if my understanding is wrong. Regards Nobin --047d7bb04c4ca7a044054168dc23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Authors,
Internal Boundary Node =
(IBN)

   As mentioned in the previous section, a network element termed
   "Internal Boundary Node" (IBN) is responsible for bridging pac=
kets
   between SFC-enabled domains.  It behaves as an SF to the higher level
   (Section 2.1), and looks like a classifier and end-of-chain to the
   lower level (Section 2.2).

Above is the IBN definition=
 copied from the draft,
My understanding here is an IBN is a normal forw=
arding device which do a classification/switching (Ex; OVS).

<= pre>1) So this drafts suggests the switch to do the NSH manipulation also ?= 
=3D=3D=3D=3Ddraft copy=3D=3D=3D=3D=3D 
3.3.  D=
ecrementing Service Index

   Because the IBN acts as an SFC-aware SF to the higher-level domain,
   it must decrement the Service Index in the NSH headers of the higher-
   level path.  This operation should be undertaken when the packet is
   first received by the IBN, before applying any of the strategies of
   Section 3.1, immediately prior to classification.
=3D=3D=
=3D=3Ddraft copy=3D=3D=3D=3D=3D
2) This means that, all the switch= implementation should support the NSH [here SI index decrement] manipulati= on, now may be not supported by switches ?
3) Why its mention= ed=C2=A0 that IBN is SFC-aware SF, even though its doing a classification f= or the upper domain?

Please correct me if my unders= tanding is wrong.

Regards
Nobin

--047d7bb04c4ca7a044054168dc23-- From nobody Wed Nov 16 04:36:13 2016 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 CA2171296DD for ; Wed, 16 Nov 2016 04:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 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, RP_MATCHES_RCVD=-1.497] 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 D1RSJpuOV4SB for ; Wed, 16 Nov 2016 04:36:09 -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 9472F1296D3 for ; Wed, 16 Nov 2016 04:36:09 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 07:36:07 -0500 From: Dave Dolson To: Nobin Mathew , "homma.shunsuke@lab.ntt.co.jp" , "diego.r.lopez@telefonica.com" , "mohamed.boucadair@orange.com" , "max.ldp@alibaba-inc.com" Thread-Topic: One question regarding IBN from draft-ietf-sfc-hierarchical-01 Thread-Index: AQHSP/d0FWt7R7/FlkqYXueriMQZVKDbiHZQ Date: Wed, 16 Nov 2016 12:36:06 +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.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98311699B7wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] One question regarding IBN from draft-ietf-sfc-hierarchical-01 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, 16 Nov 2016 12:36:12 -0000 --_000_E8355113905631478EFF04F5AA706E98311699B7wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm9iaW4sDQpUaGFua3MgZm9yIHJlYWRpbmcgdGhlIGRyYWZ0IGFuZCBhc2tpbmcgcXVlc3Rpb25z IQ0KUGxlYXNlIHNlZSBpbmxpbmUgW0REXS4NCg0KRnJvbTogTm9iaW4gTWF0aGV3IFttYWlsdG86 bm9iaW5tQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTYsIDIwMTYgNzo1 MiBQTQ0KVG86IERhdmUgRG9sc29uOyBob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwOyBkaWVn by5yLmxvcGV6QHRlbGVmb25pY2EuY29tOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBt YXgubGRwQGFsaWJhYmEtaW5jLmNvbQ0KQ2M6IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogT25lIHF1 ZXN0aW9uIHJlZ2FyZGluZyBJQk4gZnJvbSBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDEN Cg0KSGkgQXV0aG9ycywNCg0KSW50ZXJuYWwgQm91bmRhcnkgTm9kZSAoSUJOKQ0KDQoNCg0KICAg QXMgbWVudGlvbmVkIGluIHRoZSBwcmV2aW91cyBzZWN0aW9uLCBhIG5ldHdvcmsgZWxlbWVudCB0 ZXJtZWQNCg0KICAgIkludGVybmFsIEJvdW5kYXJ5IE5vZGUiIChJQk4pIGlzIHJlc3BvbnNpYmxl IGZvciBicmlkZ2luZyBwYWNrZXRzDQoNCiAgIGJldHdlZW4gU0ZDLWVuYWJsZWQgZG9tYWlucy4g IEl0IGJlaGF2ZXMgYXMgYW4gU0YgdG8gdGhlIGhpZ2hlciBsZXZlbA0KDQogICAoU2VjdGlvbiAy LjEpLCBhbmQgbG9va3MgbGlrZSBhIGNsYXNzaWZpZXIgYW5kIGVuZC1vZi1jaGFpbiB0byB0aGUN Cg0KICAgbG93ZXIgbGV2ZWwgKFNlY3Rpb24gMi4yKS4NCg0KQWJvdmUgaXMgdGhlIElCTiBkZWZp bml0aW9uIGNvcGllZCBmcm9tIHRoZSBkcmFmdCwNCk15IHVuZGVyc3RhbmRpbmcgaGVyZSBpcyBh biBJQk4gaXMgYSBub3JtYWwgZm9yd2FyZGluZyBkZXZpY2Ugd2hpY2ggZG8gYSBjbGFzc2lmaWNh dGlvbi9zd2l0Y2hpbmcgKEV4OyBPVlMpLg0KDQpbRERdIEkgZG9u4oCZdCB0aGluayB0aGlzIGlz IGEgY29ycmVjdCBpbnRlcnByZXRhdGlvbiB0byBzYXkg4oCcbm9ybWFsIGZvcndhcmRpbmcgZGV2 aWNl4oCdLiBUaGUgSUJOIGlzIGFuIE5TSCBlbmQtcG9pbnQsIG1lYW5pbmcgaXQgcmVjZWl2ZXMg TlNIIHBhY2tldHMgb3ZlciBzb21lIHRyYW5zcG9ydCBzdWNoIGFzIEV0aGVybmV0IG9yIFZYTEFO LUdQRS4gWW91IG1pZ2h0IGJlIGFibGUgdG8gZ2V0IE9WUyB0byBhY3QgdGhpcyB3YXkuDQoNCjEp IFNvIHRoaXMgZHJhZnRzIHN1Z2dlc3RzIHRoZSBzd2l0Y2ggdG8gZG8gdGhlIE5TSCBtYW5pcHVs YXRpb24gYWxzbyA/DQoNCltERF0g4oCcU3dpdGNo4oCdPyBUaGUgZHJhZnQgZG9lcyBub3QgdXNl IHRoZSB0ZXJtIOKAnHN3aXRjaOKAnSBhdCBhbGwuDQoNCg0KDQo9PT09ZHJhZnQgY29weT09PT09 DQoNCjMuMy4gIERlY3JlbWVudGluZyBTZXJ2aWNlIEluZGV4DQoNCg0KDQogICBCZWNhdXNlIHRo ZSBJQk4gYWN0cyBhcyBhbiBTRkMtYXdhcmUgU0YgdG8gdGhlIGhpZ2hlci1sZXZlbCBkb21haW4s DQoNCiAgIGl0IG11c3QgZGVjcmVtZW50IHRoZSBTZXJ2aWNlIEluZGV4IGluIHRoZSBOU0ggaGVh ZGVycyBvZiB0aGUgaGlnaGVyLQ0KDQogICBsZXZlbCBwYXRoLiAgVGhpcyBvcGVyYXRpb24gc2hv dWxkIGJlIHVuZGVydGFrZW4gd2hlbiB0aGUgcGFja2V0IGlzDQoNCiAgIGZpcnN0IHJlY2VpdmVk IGJ5IHRoZSBJQk4sIGJlZm9yZSBhcHBseWluZyBhbnkgb2YgdGhlIHN0cmF0ZWdpZXMgb2YNCg0K ICAgU2VjdGlvbiAzLjEsIGltbWVkaWF0ZWx5IHByaW9yIHRvIGNsYXNzaWZpY2F0aW9uLg0KDQo9 PT09ZHJhZnQgY29weT09PT09DQoNCltERF0gQmVjYXVzZSB0aGUgSUJOICppcyogYW4gU0YsIHll cyBpdCBkZWNyZW1lbnRzIHRoZSBTSS4NCg0KDQoyKSBUaGlzIG1lYW5zIHRoYXQsIGFsbCB0aGUg c3dpdGNoIGltcGxlbWVudGF0aW9uIHNob3VsZCBzdXBwb3J0IHRoZSBOU0ggW2hlcmUgU0kgaW5k ZXggZGVjcmVtZW50XSBtYW5pcHVsYXRpb24sIG5vdyBtYXkgYmUgbm90IHN1cHBvcnRlZCBieSBz d2l0Y2hlcyA/DQpbRERdIE5laXRoZXIgU0ZGIG5vciBTRiBub3IgQ2xhc3NpZmllciBhcmUg4oCc c3dpdGNoZXPigJ0gYXMgcGVvcGxlIG5vcm1hbGx5IHVuZGVyc3RhbmQgdGhlIHRlcm0uDQoNCjMp IFdoeSBpdHMgbWVudGlvbmVkICB0aGF0IElCTiBpcyBTRkMtYXdhcmUgU0YsIGV2ZW4gdGhvdWdo IGl0cyBkb2luZyBhIGNsYXNzaWZpY2F0aW9uIGZvciB0aGUgdXBwZXIgZG9tYWluPw0KW0REXSBJ IGhvcGUgeW91IGNhbiB1bmRlcnN0YW5kIHRoZSBJQk4gYXMgYSBraW5kIG9mIGFkYXB0ZXIgYmV0 d2VlbiB0d28gZG9tYWlucy4gSW4gdGhlIHVwcGVyIGRvbWFpbiBpdCBwbGF5cyB0aGUgcm9sZSBv ZiBhIFNlcnZpY2UgRnVuY3Rpb24sIGJ1dCBpbiB0aGUgbG93ZXIgZG9tYWluIGl0IHBsYXlzIHRo ZSByb2xlcyBvZiBjbGFzc2lmaWVyIGFuZCBTRkYuIEl0IGlzIGRvaW5nIGNsYXNzaWZpY2F0aW9u IGZvciB0aGUgbG93ZXIgZG9tYWluLCBub3QgdGhlIHVwcGVyIGRvbWFpbi4NCg0KUGxlYXNlIGNv cnJlY3QgbWUgaWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZy4NClJlZ2FyZHMNCk5vYmluDQoN Cg== --_000_E8355113905631478EFF04F5AA706E98311699B7wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob2Jpbiw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciByZWFkaW5nIHRoZSBkcmFmdCBhbmQg YXNraW5nIHF1ZXN0aW9ucyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHNl ZSBpbmxpbmUgW0REXS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IE5vYmluIE1hdGhldyBbbWFpbHRvOm5vYmlubUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAxNiA3OjUyIFBNPGJyPg0KPGI+VG86PC9iPiBE YXZlIERvbHNvbjsgaG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcDsgZGllZ28uci5sb3BlekB0 ZWxlZm9uaWNhLmNvbTsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgbWF4LmxkcEBhbGli YWJhLWluYy5jb208YnI+DQo8Yj5DYzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBPbmUgcXVlc3Rpb24gcmVnYXJkaW5nIElCTiBmcm9tIGRyYWZ0LWlldGYtc2ZjLWhpZXJh cmNoaWNhbC0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIEF1dGhvcnMsPG86cD48L286cD48L3A+DQo8cHJlPkludGVybmFsIEJv dW5kYXJ5IE5vZGUgKElCTik8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQXMgbWVudGlvbmVkIGluIHRoZSBwcmV2aW91cyBz ZWN0aW9uLCBhIG5ldHdvcmsgZWxlbWVudCB0ZXJtZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgJnF1b3Q7SW50ZXJuYWwgQm91bmRhcnkgTm9kZSZxdW90OyAoSUJOKSBpcyBy ZXNwb25zaWJsZSBmb3IgYnJpZGdpbmcgcGFja2V0czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBiZXR3ZWVuIFNGQy1lbmFibGVkIGRvbWFpbnMuJm5ic3A7IEl0IGJlaGF2ZXMg YXMgYW4gU0YgdG8gdGhlIGhpZ2hlciBsZXZlbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyAoU2VjdGlvbiAyLjEpLCBhbmQgbG9va3MgbGlrZSBhIGNsYXNzaWZpZXIgYW5kIGVu ZC1vZi1jaGFpbiB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPiZuYnNwOyZuYnNwOyBsb3dlciBsZXZlbCAoU2VjdGlvbiAyLjIpLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QWJvdmUgaXMg dGhlIElCTiBkZWZpbml0aW9uIGNvcGllZCBmcm9tIHRoZSBkcmFmdCw8YnI+TXkgdW5kZXJzdGFu ZGluZyBoZXJlIGlzIGFuIElCTiBpcyBhIG5vcm1hbCBmb3J3YXJkaW5nIGRldmljZSB3aGljaCBk byBhIGNsYXNzaWZpY2F0aW9uL3N3aXRjaGluZyAoRXg7IE9WUykuPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+W0REXSBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBhIGNvcnJl Y3QgaW50ZXJwcmV0YXRpb24gdG8gc2F5IOKAnG5vcm1hbCBmb3J3YXJkaW5nIGRldmljZeKAnS4g VGhlIElCTiBpcyBhbiBOU0ggZW5kLXBvaW50LCBtZWFuaW5nIGl0IHJlY2VpdmVzIE5TSCBwYWNr ZXRzIG92ZXIgc29tZSB0cmFuc3BvcnQgc3VjaCBhcyBFdGhlcm5ldCBvciBWWExBTi1HUEUuIFlv dSBtaWdodCBiZSBhYmxlIHRvIGdldCBPVlMgdG8gYWN0IHRoaXMgd2F5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT4xKSBTbyB0aGlzIGRyYWZ0cyBzdWdnZXN0cyB0aGUgc3dpdGNoIHRv IGRvIHRoZSBOU0ggbWFuaXB1bGF0aW9uIGFsc28gPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bRERdIOKAnFN3aXRjaOKAnT8gVGhlIGRyYWZ0IGRv ZXMgbm90IHVzZSB0aGUgdGVybSDigJxzd2l0Y2jigJ0gYXQgYWxsLjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPj09PT1kcmFmdCBjb3B5PT09PT0gPG86cD48L286cD48L3By ZT4NCjxwcmU+My4zLiZuYnNwOyBEZWNyZW1lbnRpbmcgU2VydmljZSBJbmRleDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBC ZWNhdXNlIHRoZSBJQk4gYWN0cyBhcyBhbiBTRkMtYXdhcmUgU0YgdG8gdGhlIGhpZ2hlci1sZXZl bCBkb21haW4sPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGl0IG11c3QgZGVj cmVtZW50IHRoZSBTZXJ2aWNlIEluZGV4IGluIHRoZSBOU0ggaGVhZGVycyBvZiB0aGUgaGlnaGVy LTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBsZXZlbCBwYXRoLiZuYnNwOyBU aGlzIG9wZXJhdGlvbiBzaG91bGQgYmUgdW5kZXJ0YWtlbiB3aGVuIHRoZSBwYWNrZXQgaXM8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZmlyc3QgcmVjZWl2ZWQgYnkgdGhlIElC TiwgYmVmb3JlIGFwcGx5aW5nIGFueSBvZiB0aGUgc3RyYXRlZ2llcyBvZjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBTZWN0aW9uIDMuMSwgaW1tZWRpYXRlbHkgcHJpb3IgdG8g Y2xhc3NpZmljYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+PT09PWRyYWZ0IGNvcHk9PT09 PTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5bRERdIEJlY2F1c2UgdGhlIElCTiAqPGI+aXM8L2I+KiBhbiBTRiwgeWVzIGl0 IGRlY3JlbWVudHMgdGhlIFNJLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSBUaGlzIG1lYW5zIHRoYXQsIGFsbCB0 aGUgc3dpdGNoIGltcGxlbWVudGF0aW9uIHNob3VsZCBzdXBwb3J0IHRoZSBOU0ggW2hlcmUgU0kg aW5kZXggZGVjcmVtZW50XSBtYW5pcHVsYXRpb24sIG5vdyBtYXkgYmUgbm90IHN1cHBvcnRlZCBi eSBzd2l0Y2hlcyA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0REXSBOZWl0aGVyIFNGRiBub3Ig U0Ygbm9yIENsYXNzaWZpZXIgYXJlIOKAnHN3aXRjaGVz4oCdIGFzIHBlb3BsZSBub3JtYWxseSB1 bmRlcnN0YW5kIHRoZSB0ZXJtLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgV2h5IGl0cyBtZW50aW9uZWQm bmJzcDsgdGhhdCBJQk4gaXMgU0ZDLWF3YXJlIFNGLCBldmVuIHRob3VnaCBpdHMgZG9pbmcgYSBj bGFzc2lmaWNhdGlvbiBmb3IgdGhlIHVwcGVyIGRvbWFpbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5bRERdIEkgaG9wZSB5b3UgY2FuIHVuZGVyc3RhbmQgdGhlIElCTiBhcyBhIGtpbmQgb2YgYWRh cHRlciBiZXR3ZWVuIHR3byBkb21haW5zLiBJbiB0aGUgdXBwZXIgZG9tYWluIGl0IHBsYXlzIHRo ZSByb2xlIG9mIGEgU2VydmljZSBGdW5jdGlvbiwgYnV0IGluIHRoZSBsb3dlcg0KIGRvbWFpbiBp dCBwbGF5cyB0aGUgcm9sZXMgb2YgY2xhc3NpZmllciBhbmQgU0ZGLiBJdCBpcyBkb2luZyBjbGFz c2lmaWNhdGlvbiBmb3IgdGhlIGxvd2VyIGRvbWFpbiwgbm90IHRoZSB1cHBlciBkb21haW4uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+UGxlYXNlIGNvcnJlY3QgbWUgaWYgbXkgdW5kZXJzdGFu ZGluZyBpcyB3cm9uZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O b2JpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E8355113905631478EFF04F5AA706E98311699B7wtlexchp2sandvi_-- From nobody Wed Nov 16 06:16:54 2016 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 CAE701297DE for ; Wed, 16 Nov 2016 06:16:51 -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 FtIV9iMlaiuu for ; Wed, 16 Nov 2016 06:16:46 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 84C6412983F for ; Wed, 16 Nov 2016 06:16:39 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id t79so75650007wmt.0 for ; Wed, 16 Nov 2016 06:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IioXN0phDHg9C5FFcCS6RfrIDbkeLBBfbVtCLBjJriw=; b=dUiHx2omU3dHFHZi7c4yUnHCVj7Gutq59tDqx17VIIm13x0MJ87UKhr1JZH7LWRXqZ 0egvzdXS6XwUtYCHOmThAtsBDHBTz1Dr49Dlhr2nqqIxYAnfFa5K0YRTbb8NnBODlVAD TDPBvSeH1jTgoYuj4fp09PCHRVDm8WVKzt9UuzQcuHJhWItKgOuj6NSMZG9ybPWMmvj+ WEDvjztFzjAX0zY1BJjZqQ5KPUR6nj7LR/jb9i46UMJxPANMiugTZYxc0t62RRCsbMeU 0LxLn6oWeTe+OvPKjz+ETRcilYZtRaNb4Xw62r8T+XsJJSamTZdA1gAEmS/cliEVF7zi YZrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IioXN0phDHg9C5FFcCS6RfrIDbkeLBBfbVtCLBjJriw=; b=PgJZAfvk5LhNFku1OEtg2qfgA+c8lcF39jjzzzxIJfKzaiZhfWRvO3GuKLXK2bw8Di q1GDaCIo0fkToBYG0GzxUsR57Jyo23Ar8NV406nVvZkO2MB40/XidiVHjU5ixpA2eMJ8 CXNjIZi08MrPfyNwaqqAuC1z9c96gYjEJDatfsNKhE3XT/yQ6GMcawNt6+mVG5usC/Lo Id9Vpx2qLBKgijcvHuW7nRyI9E5a0ENHD6NBL2J0rXO0VuMRpknd9v4UIwjAn2emW6AB vYgJ0y9McySBLaXGl96RxL17G6bs8198ezPZhR/sKZ51C+CEaPiu4IOxkHTpDj7T0IAn mhvA== X-Gm-Message-State: ABUngveKPHULC/4Iz0KBNQqCfxhJH0xTSOa5HZyVfqjxS7CQySK8bK0bCM5eaYUNLEeHKr71xKEAnKyR1uoK8w== X-Received: by 10.194.186.177 with SMTP id fl17mr2020660wjc.143.1479305798004; Wed, 16 Nov 2016 06:16:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.129.72 with HTTP; Wed, 16 Nov 2016 06:16:37 -0800 (PST) In-Reply-To: References: From: Nobin Mathew Date: Wed, 16 Nov 2016 19:46:37 +0530 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=047d7bb04c4c9ab58505416bb8ef Archived-At: Cc: "max.ldp@alibaba-inc.com" , "mohamed.boucadair@orange.com" , "homma.shunsuke@lab.ntt.co.jp" , "sfc@ietf.org" , "diego.r.lopez@telefonica.com" Subject: Re: [sfc] One question regarding IBN from draft-ietf-sfc-hierarchical-01 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, 16 Nov 2016 14:16:52 -0000 --047d7bb04c4c9ab58505416bb8ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dave, Thank you for your reply. So IBN is special purpose device, it could be a linux PC or an OVS , right? Do you think the open implementation of OVS needs to support the SI index decrementing [the IBN functionality] ? Regards Nobin On Wed, Nov 16, 2016 at 6:06 PM, Dave Dolson wrote: > Nobin, > > Thanks for reading the draft and asking questions! > > Please see inline [DD]. > > > > *From:* Nobin Mathew [mailto:nobinm@gmail.com] > *Sent:* Wednesday, November 16, 2016 7:52 PM > *To:* Dave Dolson; homma.shunsuke@lab.ntt.co.jp; > diego.r.lopez@telefonica.com; mohamed.boucadair@orange.com; > max.ldp@alibaba-inc.com > *Cc:* sfc@ietf.org > *Subject:* One question regarding IBN from draft-ietf-sfc-hierarchical-01 > > > > Hi Authors, > > Internal Boundary Node (IBN) > > > > As mentioned in the previous section, a network element termed > > "Internal Boundary Node" (IBN) is responsible for bridging packets > > between SFC-enabled domains. It behaves as an SF to the higher level > > (Section 2.1), and looks like a classifier and end-of-chain to the > > lower level (Section 2.2). > > Above is the IBN definition copied from the draft, > My understanding here is an IBN is a normal forwarding device which do a = classification/switching (Ex; OVS). > > [DD] I don=E2=80=99t think this is a correct interpretation to say =E2=80= =9Cnormal forwarding device=E2=80=9D. The IBN is an NSH end-point, meaning = it receives NSH packets over some transport such as Ethernet or VXLAN-GPE. = You might be able to get OVS to act this way. > > 1) So this drafts suggests the switch to do the NSH manipulation also ? > > [DD] =E2=80=9CSwitch=E2=80=9D? The draft does not use the term =E2=80=9Cs= witch=E2=80=9D at all. > > > > =3D=3D=3D=3Ddraft copy=3D=3D=3D=3D=3D > > 3.3. Decrementing Service Index > > > > Because the IBN acts as an SFC-aware SF to the higher-level domain, > > it must decrement the Service Index in the NSH headers of the higher- > > level path. This operation should be undertaken when the packet is > > first received by the IBN, before applying any of the strategies of > > Section 3.1, immediately prior to classification. > > =3D=3D=3D=3Ddraft copy=3D=3D=3D=3D=3D > > [DD] Because the IBN **is** an SF, yes it decrements the SI. > > > > 2) This means that, all the switch implementation should support the NSH > [here SI index decrement] manipulation, now may be not supported by > switches ? > > [DD] Neither SFF nor SF nor Classifier are =E2=80=9Cswitches=E2=80=9D as = people normally > understand the term. > > > > 3) Why its mentioned that IBN is SFC-aware SF, even though its doing a > classification for the upper domain? > > [DD] I hope you can understand the IBN as a kind of adapter between two > domains. In the upper domain it plays the role of a Service Function, but > in the lower domain it plays the roles of classifier and SFF. It is doing > classification for the lower domain, not the upper domain. > > > > Please correct me if my understanding is wrong. > > Regards > > Nobin > > > --047d7bb04c4c9ab58505416bb8ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,
Thank you for y= our reply.
So IBN is special purpose device, it could be a linux P= C or an OVS , right?
Do you think the open implementation of OVS n= eeds to support the SI index decrementing [the IBN functionality] ?
Regards
Nobin

On Wed, Nov 16, 2016 at 6:06 PM, Dave Dolson <ddolson@= sandvine.com> wrote:

Nobin,

Thanks for reading the dr= aft and asking questions!

Please see inline [DD].

=C2=A0

From: Nobin Ma= thew [mailto:nobinm@g= mail.com]
Sent: Wednesday, November 16, 2016 7:52 PM
To: Dave Dolson; homma.shunsuke@lab.ntt.co.jp; diego.r.lopez@telefonica.com; <= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank">mohamed.bo= ucadair@orange.com; max.ldp@alibaba-inc.com
Cc: sfc@ietf.org
Subject: One question regarding IBN from draft-ietf-sfc-hierarchical= -01

=C2=A0

Hi Authors,

Internal Boundary Node (IBN)
=C2=A0
=C2=A0=C2=A0 As mentioned in the previous section, a network element t=
ermed
=C2=A0=C2=A0 "Internal Boundary Node" (IBN) is responsible f=
or bridging packets
=C2=A0=C2=A0 between SFC-enabled domains.=C2=A0 It behaves as an SF to=
 the higher level
=C2=A0=C2=A0 (Section 2.1), and looks like a classifier and end-of-cha=
in to the
=C2=A0=C2=A0 lower level (Section 2.2).=

Above is the IBN definition copied from=
 the draft,
My understanding here is an IBN is a normal forwarding devic=
e which do a classification/switching (Ex; OVS).
[DD] =
I don=E2=80=99t think this is a correct interpretation to say =E2=80=9Cnorm=
al forwarding device=E2=80=9D. The IBN is an NSH end-point, meaning it rece=
ives NSH packets over some transport such as Ethernet or VXLAN-GPE. You mig=
ht be able to get OVS to act this way.
1) So this drafts suggests the switch to do the NSH manipulation also =
?
[DD] =E2=80=9CSwitch=E2=80=9D? Th=
e draft does not use the term =E2=80=9Cswitch=E2=80=9D at all.
=C2=A0
=3D=3D=3D=3Ddraft copy=3D=3D=3D=3D=3D 
3.3.=C2=A0 Decrementing Service Index
=C2=A0
=C2=A0=C2=A0 Because the IBN acts as an SFC-aware SF to the higher-lev=
el domain,
=C2=A0=C2=A0 it must decrement the Service Index in the NSH headers of=
 the higher-
=C2=A0=C2=A0 level path.=C2=A0 This operation should be undertaken whe=
n the packet is
=C2=A0=C2=A0 first received by the IBN, before applying any of the str=
ategies of
=C2=A0=C2=A0 Section 3.1, immediately prior to classification.<=
u>
=3D=3D=3D=3Ddraft copy=3D=3D=3D=3D=3D
[DD] Because the IBN *is* an =
SF, yes it decrements the SI.
=C2=A0

2) This means that, all the switch implementation sh= ould support the NSH [here SI index decrement] manipulation, now may be not= supported by switches ?

[DD] Neither SFF n= or SF nor Classifier are =E2=80=9Cswitches=E2=80=9D as people normally unde= rstand the term.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

3) Why its mentioned=C2=A0 that IBN is SFC-aware SF,= even though its doing a classification for the upper domain?=

[DD] I hope you ca= n understand the IBN as a kind of adapter between two domains. In the upper= domain it plays the role of a Service Function, but in the lower domain it plays the roles of classifier and SFF. It is doing classificatio= n for the lower domain, not the upper domain.

=C2=A0

Please correct me if = my understanding is wrong.

Regards

Nobin

=C2=A0


--047d7bb04c4c9ab58505416bb8ef-- From nobody Wed Nov 16 23:01:17 2016 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 68C161293D9 for ; Wed, 16 Nov 2016 23:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 WEe8rqObbQh6 for ; Wed, 16 Nov 2016 23:01: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 E400B1279EB for ; Wed, 16 Nov 2016 23:01:12 -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 DAR78006; Thu, 17 Nov 2016 07:01:10 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Nov 2016 07:01:09 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.151]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 17 Nov 2016 15:01:00 +0800 From: Qin Wu To: "sfc@ietf.org" Thread-Topic: PCEP Extensions for Service Function Chaining (SFC) Thread-Index: AdJAgO1RsNEN2eVCSXOP4RRw2Kyxmw== Date: Thu, 17 Nov 2016 07:01:01 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.115.111] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8548B777nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.582D55B6.0081, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6ea40d9069f15d3d386770c9fa8a823d Archived-At: Subject: [sfc] PCEP Extensions for Service Function Chaining (SFC) 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, 17 Nov 2016 07:01:15 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8548B777nkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGZvbGtzOg0KQ2hhaXIgcmVtaW5kIHVzIHJlY2VudGx5IHRvIGFubm91bmNlIHRvIHRoaXMg bGlzdCB0aGF0IFBDRSBXRyBpcyB3b3JraW5nIG9uIFBDRSBFeHRlbnNpb24gZm9yIFNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW5pbmcuIEhlcmUgaXMgdGhlIHJlbGV2YW50IGRyYWZ0Og0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LXBjZS10cmFmZmljLXN0ZWVyaW5nLXNmYy0wOQ0K UGxlYXNlIHRha2UgYSBsb29rIGF0IGl0IGFuZCB5b3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9u cyBhcmUgd2VsY29tZS4NCg0KLVFpbg0K --_000_B8F9A780D330094D99AF023C5877DABA8548B777nkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, folks:

Chair remind us recently to ann= ounce to this list that PCE WG is working on PCE Extension for Service Func= tion Chaining. Here is the relevant draft:

https://tools.ietf.org/html/d= raft-wu-pce-traffic-steering-sfc-09

Please take a look at it and yo= ur comments and suggestions are welcome.

 

-Qin

--_000_B8F9A780D330094D99AF023C5877DABA8548B777nkgeml513mbxchi_-- From nobody Wed Nov 16 23:43:24 2016 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 00ABD1295CE for ; Wed, 16 Nov 2016 23:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 luPpyntSf_Fq for ; Wed, 16 Nov 2016 23:43: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 E8DF41294C7 for ; Wed, 16 Nov 2016 23:43:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVI85975; Thu, 17 Nov 2016 07:43:18 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Nov 2016 07:42:40 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 17 Nov 2016 15:42:33 +0800 From: Xuxiaohu To: Qin Wu , "sfc@ietf.org" Thread-Topic: PCEP Extensions for Service Function Chaining (SFC) Thread-Index: AdJAgO1RsNEN2eVCSXOP4RRw2KyxmwAJEQTr Date: Thu, 17 Nov 2016 07:42:32 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.116.5] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.582D5F97.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 813528e65c4bf5cdf88a37088dfb3aac Archived-At: Subject: [sfc] =?gb2312?b?tPC4tDogUENFUCBFeHRlbnNpb25zIGZvciBTZXJ2aWNlIEZ1?= =?gb2312?b?bmN0aW9uIENoYWluaW5nIChTRkMp?= 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, 17 Nov 2016 07:43:24 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653NKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpJdCdzIGdyZWF0IHRvIGtub3cgdGhhdCB0aGUgUENFIFdHIGlzIG5vdyB3b3Jr aW5nIG9uIFBDRSBFeHRlbnNpb25zIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nLg0KDQoN Cg0KVGhlIGZvbGxvd2luZyBpcyBhIGRyYWZ0IGFib3V0IFBDRVAgZXh0ZW5zaW9ucyBmb3IgdGhl IE1QTFMgc291cmNlIHJvdXRpbmcgYmFzZWQgU0ZDIChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXh1LW1wbHMtc2VydmljZS1jaGFpbmluZy0wMCk6DQoNCg0KDQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtcGNlLXNyLXNmYy0wMw0KDQoNCg0KQW55IHN1 Z2dlc3Rpb25zIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZSBhcyB3ZWxsLg0KDQoNCg0KQmVzdCBy ZWdhcmRzLA0KDQpYaWFvaHUNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQq3orz+yMs6IHNmYyBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUWluIFd1IFtiaWxsLnd1 QGh1YXdlaS5jb21dDQq3osvNyrG85DogMjAxNsTqMTHUwjE3yNUgMTU6MDENCsrVvP7Iyzogc2Zj QGlldGYub3JnDQrW98ziOiBbc2ZjXSBQQ0VQIEV4dGVuc2lvbnMgZm9yIFNlcnZpY2UgRnVuY3Rp b24gQ2hhaW5pbmcgKFNGQykNCg0KSGksIGZvbGtzOg0KQ2hhaXIgcmVtaW5kIHVzIHJlY2VudGx5 IHRvIGFubm91bmNlIHRvIHRoaXMgbGlzdCB0aGF0IFBDRSBXRyBpcyB3b3JraW5nIG9uIFBDRSBF eHRlbnNpb24gZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcuIEhlcmUgaXMgdGhlIHJlbGV2 YW50IGRyYWZ0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LXBjZS10cmFm ZmljLXN0ZWVyaW5nLXNmYy0wOQ0KUGxlYXNlIHRha2UgYSBsb29rIGF0IGl0IGFuZCB5b3VyIGNv bW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KLVFpbg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653NKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 

It's great to know that the PCE WG is now working on PCE Extensions= for Service Function Chaining.

 

The following is a draft about PCEP extensions for the MP= LS source routing based SFC (see h= ttps://tools.ietf.org/html/draft-xu-mpls-service-chaining-00):

 

https://t= ools.ietf.org/html/draft-xu-pce-sr-sfc-03

 

Any suggestions and comments are welcome as well.

 

Best regards,

Xiaohu

 

=B7=A2=BC=FE=C8=CB: sfc [sfc-bounces@ietf.= org] =B4=FA=B1=ED Qin Wu [bill.wu@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA11=D4=C217=C8=D5 15:01
=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] PCEP Extensions for Service Function Chaining (S= FC)

Hi, folks:

Chair remind us recently to ann= ounce to this list that PCE WG is working on PCE Extension for Service Func= tion Chaining. Here is the relevant draft:

https://too= ls.ietf.org/html/draft-wu-pce-traffic-steering-sfc-09

Please take a look at it and yo= ur comments and suggestions are welcome.

 

-Qin

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653NKGEML515MBXchi_-- From nobody Thu Nov 17 00:46:03 2016 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 3AC7E1297EE for ; Thu, 17 Nov 2016 00:46:02 -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 lDrSRLhjU3es for ; Thu, 17 Nov 2016 00:46:01 -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 A1D3F1297BC for ; Thu, 17 Nov 2016 00:45:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8AE90240EFB; Thu, 17 Nov 2016 00:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479372358; bh=RzoaE+IowrjTb3gt0BO5Lh0Eo0avt4cO6FresH4WiQM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kccn3pgBUeMpXM0KhdCFeGS5ltDx4SO1HCwf12VXwrOckVPJ/0MmXGixCO6FMTlEX KQFtmIAar+K+ZnngpX9irJN2iSO7vxJ7zT+E69/Tx05Lh7/mj+BmEn2qn5nDzL/WB/ 9VnbhCBRAVpFGhCsHTzxiUweIvLploo5GkBGSIMQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-93c0.meeting.ietf.org (dhcp-93c0.meeting.ietf.org [31.133.147.192]) (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 A3A67240D9F; Thu, 17 Nov 2016 00:45:57 -0800 (PST) To: Xuxiaohu , Qin Wu , "sfc@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653@NKGEML515-MBX.china.huawei.com> From: "Joel M. Halpern" Message-ID: <6ac5a6ca-62a0-5b74-0f0f-cfcf0937a443@joelhalpern.com> Date: Thu, 17 Nov 2016 03:46:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBQQ0VQIEV4dGVuc2lvbnMgZm9yIFNlcnZpY2Ug?= =?utf-8?q?Function_Chaining_=28SFC=29?= 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, 17 Nov 2016 08:46:02 -0000 Xu, it is unclear in this draft whether your intention is to carry NSH to support interoperation with other transports and carriage of metadata. Can you please clarify? Thank you, Joel On 11/17/16 2:42 AM, Xuxiaohu wrote: > Hi, > > > > It's great to know that the PCE WG is now working on PCE Extensions for > Service Function Chaining. > > > > The following is a draft about PCEP extensions for the MPLS > source routing based SFC (see > https://tools.ietf.org/html/draft-xu-mpls-service-chaining-00): > > > > https://tools.ietf.org/html/draft-xu-pce-sr-sfc-03 > > > > Any suggestions and comments are welcome as well. > > > > Best regards, > > Xiaohu > > > > ------------------------------------------------------------------------ > *鍙戜欢浜:* sfc [sfc-bounces@ietf.org] 浠ｈ〃 Qin Wu [bill.wu@huawei.com] > *鍙戦佹椂闂:* 2016骞11鏈17鏃 15:01 > *鏀朵欢浜:* sfc@ietf.org > *涓婚:* [sfc] PCEP Extensions for Service Function Chaining (SFC) > > Hi, folks: > > Chair remind us recently to announce to this list that PCE WG is working > on PCE Extension for Service Function Chaining. Here is the relevant draft: > > https://tools.ietf.org/html/draft-wu-pce-traffic-steering-sfc-09 > > Please take a look at it and your comments and suggestions are welcome. > > > > -Qin > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Nov 17 01:07:06 2016 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 27969129629 for ; Thu, 17 Nov 2016 01:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 J65p9cyajMwA for ; Thu, 17 Nov 2016 01:07:03 -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 01B241294E4 for ; Thu, 17 Nov 2016 01:07:02 -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 DAR99038; Thu, 17 Nov 2016 09:07:00 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Nov 2016 09:06:59 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 17 Nov 2016 17:06:47 +0800 From: Xuxiaohu To: "Joel M. Halpern" , Qin Wu , "sfc@ietf.org" Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogUENFUCBFeHRlbnNpb25zIGZvciBTZXJ2aWNlIEZ1bmN0?= =?gb2312?Q?ion_Chaining_(SFC)?= Thread-Index: AdJAgO1RsNEN2eVCSXOP4RRw2KyxmwAJEQTr//+Nk4CAAIrJzA== Date: Thu, 17 Nov 2016 09:06:47 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37717@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653@NKGEML515-MBX.china.huawei.com>, <6ac5a6ca-62a0-5b74-0f0f-cfcf0937a443@joelhalpern.com> In-Reply-To: <6ac5a6ca-62a0-5b74-0f0f-cfcf0937a443@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.121.109] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.582D7335.000D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5a2dd4999167be34641f3b8a954e2b17 Archived-At: Subject: [sfc] =?gb2312?b?tPC4tDogILTwuLQ6IFBDRVAgRXh0ZW5zaW9ucyBmb3IgU2Vy?= =?gb2312?b?dmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKQ==?= 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, 17 Nov 2016 09:07:05 -0000 SGkgSm9lbCwNCg0KVGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IGp1c3QgZGVzY3Jp YmVzIG5lY2Nlc3NhcnkgUENFUCBleHRlbnNpb25zIHRvIHJlYWxpemUgdGhlIE1QTFMgc291cmNl IHJvdXRpbmcgYmFzZWQgU0ZDIGFwcHJvYWNoIGFzIGRlc2NyaWJlZCBpbiAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LW1wbHMtc2VydmljZS1jaGFpbmluZy0wMCkuIEl0IGRv ZXNuJ3QgdG91Y2ggdGhlIE5TSC1iYXNlZCBTRkMgYXBwcm9hY2guIEkgdGhpbmsgaXQncyBRaW4n cyBkcmFmdCB0aGF0IGNvdmVycyB0aGUgTlNILWJhc2VkIFNGQyBhcHByb2FjaC4NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCreivP7IyzogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29tXQ0Kt6LLzcqx vOQ6IDIwMTbE6jEx1MIxN8jVIDE2OjQ2DQrK1bz+yMs6IFh1eGlhb2h1OyBRaW4gV3U7IHNmY0Bp ZXRmLm9yZw0K1vfM4jogUmU6IFtzZmNdILTwuLQ6IFBDRVAgRXh0ZW5zaW9ucyBmb3IgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKQ0KDQpYdSwgaXQgaXMgdW5jbGVhciBpbiB0aGlzIGRy YWZ0IHdoZXRoZXIgeW91ciBpbnRlbnRpb24gaXMgdG8gY2FycnkgTlNIDQp0byBzdXBwb3J0IGlu dGVyb3BlcmF0aW9uIHdpdGggb3RoZXIgdHJhbnNwb3J0cyBhbmQgY2FycmlhZ2Ugb2YgbWV0YWRh dGEuDQoNCkNhbiB5b3UgcGxlYXNlIGNsYXJpZnk/DQoNClRoYW5rIHlvdSwNCkpvZWwNCg0KT24g MTEvMTcvMTYgMjo0MiBBTSwgWHV4aWFvaHUgd3JvdGU6DQo+IEhpLA0KPg0KPg0KPg0KPiBJdCdz IGdyZWF0IHRvIGtub3cgdGhhdCB0aGUgUENFIFdHIGlzIG5vdyB3b3JraW5nIG9uIFBDRSBFeHRl bnNpb25zIGZvcg0KPiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nLg0KPg0KPg0KPg0KPiBUaGUg Zm9sbG93aW5nIGlzIGEgZHJhZnQgYWJvdXQgUENFUCBleHRlbnNpb25zIGZvciB0aGUgTVBMUw0K PiBzb3VyY2Ugcm91dGluZyBiYXNlZCBTRkMgKHNlZQ0KPiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQteHUtbXBscy1zZXJ2aWNlLWNoYWluaW5nLTAwKToNCj4NCj4NCj4NCj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXBjZS1zci1zZmMtMDMNCj4NCj4NCj4N Cj4gQW55IHN1Z2dlc3Rpb25zIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZSBhcyB3ZWxsLg0KPg0K Pg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+DQo+IFhpYW9odQ0KPg0KPg0KPg0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gKreivP7IyzoqIHNmYyBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUWluIFd1 IFtiaWxsLnd1QGh1YXdlaS5jb21dDQo+ICq3osvNyrG85DoqIDIwMTbE6jEx1MIxN8jVIDE1OjAx DQo+ICrK1bz+yMs6KiBzZmNAaWV0Zi5vcmcNCj4gKtb3zOI6KiBbc2ZjXSBQQ0VQIEV4dGVuc2lv bnMgZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykNCj4NCj4gSGksIGZvbGtzOg0K Pg0KPiBDaGFpciByZW1pbmQgdXMgcmVjZW50bHkgdG8gYW5ub3VuY2UgdG8gdGhpcyBsaXN0IHRo YXQgUENFIFdHIGlzIHdvcmtpbmcNCj4gb24gUENFIEV4dGVuc2lvbiBmb3IgU2VydmljZSBGdW5j dGlvbiBDaGFpbmluZy4gSGVyZSBpcyB0aGUgcmVsZXZhbnQgZHJhZnQ6DQo+DQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1wY2UtdHJhZmZpYy1zdGVlcmluZy1zZmMtMDkN Cj4NCj4gUGxlYXNlIHRha2UgYSBsb29rIGF0IGl0IGFuZCB5b3VyIGNvbW1lbnRzIGFuZCBzdWdn ZXN0aW9ucyBhcmUgd2VsY29tZS4NCj4NCj4NCj4NCj4gLVFpbg0KPg0KPg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBs aXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPg== From nobody Thu Nov 17 05:47:12 2016 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 651591298CC for ; Thu, 17 Nov 2016 05:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 9VRVvfi6qFYc for ; Thu, 17 Nov 2016 05:47:09 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A651298CA for ; Thu, 17 Nov 2016 05:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1745; q=dns/txt; s=iport; t=1479390428; x=1480600028; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TS/KUF9bEWRXfyF3Pg3S9MddkQj1K71F0O+XCQQErNs=; b=lSI4XhqVGtUdCnFHjCpQm0788J9lAR/8elllVwVou44TU+HH8M1DEtzS u9Ci8kajeVkserAbudJ6hIRH3xcX51m5gj8ycTiEHQSdK4NV9Xui5YaBw LkS9JZaW2ZuEpnRh4L2NLsgsw0Sqs85ZJ4u1a400RKpKl+wMwrFgCDhNF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAwB3tC1Y/5hdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR+BWAekRpZrhiECgg1DEAECAQEBAQEBAWIohGgBAQEDATo?= =?us-ascii?q?/BQsCAQgYHgULMiUBAQQOBYhkCLA3i14BAQEBAQEBAQEBAQEBAQEBAQEBAR2GP?= =?us-ascii?q?IF9CIJVhEmDMYIwAQSaQwGQbJAmjVCECgE1IIELg3aBRXKGbYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,506,1473120000"; d="scan'208";a="170183264" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2016 13:46:57 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAHDkvB2007198 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Nov 2016 13:46:57 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 07:46:57 -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, 17 Nov 2016 07:46:56 -0600 From: "Paul Quinn (paulq)" To: Eric C Rosen Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI4FZoby3s/XPxYbUq35Andp+fNvQAORE0AANk5y4AADtlJgAC/lDGAAIeEloA= Date: Thu, 17 Nov 2016 13:46:56 +0000 Message-ID: References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <71fee848-be00-9137-286f-4908125e62a5@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D572EC726@dfweml501-mbb> <37aa2696-34fc-54d5-f607-10d747ac87fa@juniper.net> In-Reply-To: <37aa2696-34fc-54d5-f607-10d747ac87fa@juniper.net> 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.235] Content-Type: text/plain; charset="us-ascii" Content-ID: <469926A7D2A82749ABB1E1FCD21EFA56@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 17 Nov 2016 13:47:10 -0000 Eric, > On Nov 14, 2016, at 4:06 PM, Eric C Rosen wrote: >=20 >=20 >> Not sure what convergence concern you have. > Suppose SPI 17 has two elements: SF1, SF2, SF3. And suppose that the res= pective SPI/SI values for these three SFs are17/255, 17/254, and 17/253 res= pectively. >=20 > Now suppose we want to remove SF2, so that SPI 17 now has two elements: S= F1, SF3. We have to change SF3's SPI/SI to 17/254. >=20 > During the convergence period, some nodes will think that 17/254 means "S= F2" (old value), and some will think that it means "SF3" (new value). Furt= her, some nodes will think that 17/253 means "SF3", and some will think tha= t 17/253 is an invalid value. >=20 > So consider an NSH packet, with SPI/SI 17/254, at SFF1. If SFF1 knows on= ly the old value of SPI 17, it will send the packet to SF2. SFF1 will get t= he packet back with an SPI/SI of 17/253. To SFF1, this means "next hop is = SF3". Let's suppose SFF1 forwards the packet to SFF2, because it knows tha= t there is an instance of SF3 attached to SFF2. However, SFF2 knows the ne= w value of SPI 17, and hence thinks that 17/253 is invalid. So SFF2 drops = the packet. A packet has now been lost during the convergence period. >=20 > This packet loss would not have happened if we had not changed the SPI/SI= of SF3 from 17/253 to 17/254. In that case, SFF2 would have known that 17= /253 means SF3. Also, 17/253 would still be the last hop of SPI 17, so the= re'd be no confusion about when the chain was finished. This convergence issue isn't really germance to NSH. You need to have a co= rrect view of the state of the network, for a given plane, when moving pack= ets. = From nobody Thu Nov 17 05:47:42 2016 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 63BE41298CC for ; Thu, 17 Nov 2016 05:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 nmgY1qsLHenz for ; Thu, 17 Nov 2016 05:47:39 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF58012975C for ; Thu, 17 Nov 2016 05:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4107; q=dns/txt; s=iport; t=1479390458; x=1480600058; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AMg+85yFpLTG29AxFAyx27dVBZIB8te/aUuL5IFYlCY=; b=Frc32cZzLg0OoVuZe3P46ru6rMEwiXNmSnF0UNqy04Rq1pmu54NA/7Ty nPmbEbObFMafFoZFYdqM7pBr7vjtzIRPCPgMLx+WIvYmRUppuZqx2DkPG J4rJhJ73y8RUF6SVYlb1fV+KdRLTcIqX6rcs+IlPaFS3P23XATbxpGIUC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQCytC1Y/4kNJK1UChoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYM3AQEBAQEfgVgHjTiXDpRkggeCa4M2AoINPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?oAQEBAwE6PwULAgEIEgYeBQsyFw4BAQQOBYhkCLA3i14BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GPIF9CIJVhBkIKIMxgjAFmkMBkGyQJo1QhAoBHjeBC4N2gUVyhT2?= =?us-ascii?q?BMIEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,506,1473120000"; d="scan'208";a="349675653" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Nov 2016 13:47:24 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uAHDlOth026183 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Nov 2016 13:47:24 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 07:47:23 -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, 17 Nov 2016 07:47:23 -0600 From: "Paul Quinn (paulq)" To: Eric C Rosen Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI4FZoby3s/XPxYbUq35Andp+fNvQAORE0AANk5y4ABVfXwgA== Date: Thu, 17 Nov 2016 13:47:23 +0000 Message-ID: <0E6EF9D3-533C-4218-B008-C4F9CA358429@cisco.com> References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <71fee848-be00-9137-286f-4908125e62a5@pi.nu> 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.235] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" , "sfc@ietf.org" , Dave Dolson , Loa Andersson Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 17 Nov 2016 13:47:40 -0000 > On Nov 10, 2016, at 1:35 PM, Eric C Rosen wrote: >=20 > On 11/6/2016 5:56 AM, Loa Andersson wrote: >> I can't think of a case where it is harmful to decrement by another >> value than 1. >>=20 >> OTOH hand have shown that it is useful?=20 >=20 > I think there is a real issue here, but I don't think it has been capture= d well in this discussion. >=20 > IMHO the real issue is whether the successive elements (SFIs) in a servic= e path (as identified by a specific SPI) are required to have successive in= tegers as their SIs. >=20 > I don't think this has much to do with the behavior of the SF. I unders= tand that the SF needs a way to mark the NSH to indicate "I'm done with thi= s packet". Apparently the only way for the SF to do this is to decrement = the SI by something. And we'd like the SF to be able to indicate "I'm done= " without knowing anything about the SPI. This implies that the decrement = needs to be a fixed value. And if it's going to be a fixed value, it might = as well be 1. >=20 > It wouldn't make sense to have an option to configure an SF to "decrement= by 5", say, because if we don't want to require the successive elements of= the SPI to have successive integers as their respective SIs, we also don't= want to require that they have successive multiples of 5 as their SIs. If= we wanted the SF to do anything other than decrement by 1, we'd really nee= d to pass it enough information about the SPI to enable it to identify the = next hop. That seems undesirable. >=20 > So suppose the SPI has two elements, one with SI=3D3 and one with SI=3D5.= If an SF gets a packet with SI=3D5 in the NSH, it processes the packet, s= ets the SI to 4, and sends the packet to the SFF. >=20 > Initially I thought that the SFF could interpret "SI=3D4" as meaning "the= next hop after SI=3D5". The SFF knows the SPI, can see that the next hop = after 5 is 3, and thus could change the SI in the NSH to 3, and then forwar= d the packet. However, I've been told that the SFF isn't supposed to do s= tuff like this, because only a classifier can modify the SPI/SI at this poi= nt. So instead we'd have to say that the SFF has a co-resident classifier= that modifies the SI as described. Of course, if you deploy SFFs that do= n't have the co-resident classifier then you wouldn't be able to deploy SPI= s with non-successive integers as the SIs. Well, if you want to deploy an = optional feature, you need to deploy software that supports that feature. >=20 > I've only seen one really interesting argument against creating SPIs with= non-successive SIs, the argument that says that that would make it more di= fficult to figure out the "reverse" of an SPI. This will require some furt= her thought. >=20 > Now to Loa's question (or my reinterpretation of it) of whether there is = an advantage to having non-successive SIs in an SPI, I'd say yes. If you t= hink that SPIs may get modified (by insertion or deletion of elements) dyna= mically, and that such modifications need to be distributed dynamically, it= seems like a good idea to be able to make these modifications without chan= ging the SIs of the elements that were present before the modification. A= fter all, one can think of an SPI/SI as an address of an SFI. You want to = be able to add/remove SFIs from an SPI without changing the addresses of al= l the SFIs. This will get you much more consistent/predictable behavior du= ring the convergence period where not everyone knows about the change yet. = (Imagine if you couldn't add or remove a system from the network without c= hanging the addresses of all the other systems.) >=20 > Of course, someone will say that the WG has already determined that the S= PIs never need to be modified dynamically. But that's really > a deployment decision, not a decision that should be forced by the archit= ecture or the protocol design. >=20 >=20 On the contrary: dynamically updating SPI is supported and the need for tha= t functionality is clear.= From nobody Thu Nov 17 05:47:46 2016 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 D54361298CE for ; Thu, 17 Nov 2016 05:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 8KdNbLayshkT for ; Thu, 17 Nov 2016 05:47:44 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21AE1298D2 for ; Thu, 17 Nov 2016 05:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3236; q=dns/txt; s=iport; t=1479390463; x=1480600063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nuDZ6YYX1+Uw1Qtu7d/AX2k9ePOPKlzbIlaxhsS5aig=; b=ipL53mfJ07qlCpHRRbn2mIv7etsOBeYvkbWpWWiW8PY7QNf4gM6BYFMz 6xN46zOx9mVJcX4hhiDMNOdV27zxFrxb1kUl3y4kDqmQK/+sgPQacZFZe zWiOsT+QqNs5lwr3x1uwkKoRrmEcmg8nGN5gnYaKBRhj6CQTZylSXuMAv o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAwDJtC1Y/51dJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgykOAQEBAQEfgVgHpEaUZIIHhiECgg1BEgECAQEBAQEBAWIohGgBAQE?= =?us-ascii?q?DATo/BQsCAQgYHgULMiUBAQQOBYhkCLA3i14BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2GPIF9gl2ESYMxgjABBI5hi2IBkGyQJo1QhAoBJQUrgQuDdoFFcoU9KoEGgQw?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.31,506,1473120000"; d="scan'208";a="348766134" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2016 13:47:20 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uAHDlKDh030424 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Nov 2016 13:47:20 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; Thu, 17 Nov 2016 07:47:20 -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, 17 Nov 2016 07:47:19 -0600 From: "Paul Quinn (paulq)" To: Eric C Rosen Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI4FZoby3s/XPxYbUq35Andp+fNvQAORE0AANk5y4AADtlJgAC/lDGAAIeIBAA= Date: Thu, 17 Nov 2016 13:47:19 +0000 Message-ID: <1EFFEB68-B740-45E7-A42F-D0368671254D@cisco.com> References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <71fee848-be00-9137-286f-4908125e62a5@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D572EC726@dfweml501-mbb> <37aa2696-34fc-54d5-f607-10d747ac87fa@juniper.net> In-Reply-To: <37aa2696-34fc-54d5-f607-10d747ac87fa@juniper.net> 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.235] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 17 Nov 2016 13:47:46 -0000 Eric, > On Nov 14, 2016, at 4:06 PM, Eric C Rosen wrote: >=20 > On 11/10/2016 8:41 PM, Lucy yong wrote: >> Hi Eric, >>=20 >> "You want to be able to add/remove SFIs from an SPI without changing the= addresses of all the SFIs." >>=20 >> Long time ago, we argued that using SPI/SI to indicate SI's location on = a SFC path has the nature where adding/removing a SI to an SFC results the = change of some SIs locations (those after the SI), thus SFFs have to be upd= ated accordingly. We thought that is bad design. >=20 > I would tend to agree that that is not a good design. >=20 >> The counter argument then was that, adding/removing a SI to an existing = SFC is considered as a new SFC that will be given a new SPI, configuring SF= Fs for a new SPC is a normal operation. >=20 > I don't find this to be credible. Management of the SPI name space is a= n issue for the operators, it's not up to the WG to decide that the SPI val= ue must change whenever an SF is added or removed. >=20 >> Not sure what convergence concern you have. > Suppose SPI 17 has two elements: SF1, SF2, SF3. And suppose that the res= pective SPI/SI values for these three SFs are17/255, 17/254, and 17/253 res= pectively. >=20 > Now suppose we want to remove SF2, so that SPI 17 now has two elements: S= F1, SF3. We have to change SF3's SPI/SI to 17/254. >=20 > During the convergence period, some nodes will think that 17/254 means "S= F2" (old value), and some will think that it means "SF3" (new value). Furt= her, some nodes will think that 17/253 means "SF3", and some will think tha= t 17/253 is an invalid value. >=20 > So consider an NSH packet, with SPI/SI 17/254, at SFF1. If SFF1 knows on= ly the old value of SPI 17, it will send the packet to SF2. SFF1 will get t= he packet back with an SPI/SI of 17/253. To SFF1, this means "next hop is = SF3". Let's suppose SFF1 forwards the packet to SFF2, because it knows tha= t there is an instance of SF3 attached to SFF2. However, SFF2 knows the ne= w value of SPI 17, and hence thinks that 17/253 is invalid. So SFF2 drops = the packet. A packet has now been lost during the convergence period. >=20 > This packet loss would not have happened if we had not changed the SPI/SI= of SF3 from 17/253 to 17/254. In that case, SFF2 would have known that 17= /253 means SF3. Also, 17/253 would still be the last hop of SPI 17, so the= re'd be no confusion about when the chain was finished. >=20 This convergence issue isn't germance to NSH. Devices need to have a consi= stent view of the state of the network, for a given plane, when moving pack= ets. You are implying some things about the control plane, that might not = be true, if for, example a "pull" model is used. >=20 >> Do you want that, if an SFF can't reach an SF temporarily due to a failu= re, allow the SFF to resets SI and forward to next SI? >>=20 >>=20 > That's an interesting question. I'm not sure what the desired behavior i= s in that case. In general it comes down to simple policy. For the most part services, par= ticularly, when security services are involved, the default is to stop send= ing packets down the chain.= From nobody Thu Nov 17 05:48:26 2016 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 8DD961298CC for ; Thu, 17 Nov 2016 05:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 LRFeSeoVnpOq for ; Thu, 17 Nov 2016 05:48:23 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352A11297CD for ; Thu, 17 Nov 2016 05:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3777; q=dns/txt; s=iport; t=1479390503; x=1480600103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4a3xL37gzgfsaG1/VMzYCMidxF3DM5kgxjpmSuBp0X4=; b=hKQaWwKOzkkIMOKkqe68vvxCBwLX0iVGdBDALG0wdA0tEsvJFCFiwUuJ +2IrfWuZZlZwbYm3W+49rYOYbxlALtb8Jjek2Y0J2ndD/qEeJAiYdNBhN nInW7dD8wyM6MLHUO2oiWu/V+yb8wPt8Cjq3X2KoCAwmoQCYKs+tXD5g8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAwDJtC1Y/40NJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR+BWAekRpZrhiECgg1CEQECAQEBAQEBAWIohGgBAQEDASc?= =?us-ascii?q?TPwULAgEIGB4QMiUCBA4FG4hJCK96PYteAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?IY8gX2CXYQaL4MxgjABBJpDAZBskCaNUIQKATQhgQuFO3KGbYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,506,1473120000"; d="scan'208";a="175340535" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Nov 2016 13:48:00 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uAHDm0Bk017382 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Nov 2016 13:48:00 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 07:47:59 -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, 17 Nov 2016 07:47:59 -0600 From: "Paul Quinn (paulq)" To: Eric C Rosen Thread-Topic: [sfc] decrementing service function path index Thread-Index: AQHSPFm55o/4frEPxEagpDf+RcXX8qDUrOuAgASg1ICABFCOAA== Date: Thu, 17 Nov 2016 13:47:59 +0000 Message-ID: <1910AAC8-2A27-4EDA-8C6B-8CF90F1BB41F@cisco.com> References: <025f01d2346a$24f947a0$6eebd6e0$@olddog.co.uk> <026701d23470$6cef2880$46cd7980$@olddog.co.uk> <028701d2347a$850d1fd0$8f275f70$@olddog.co.uk> <299eef07-1535-071a-3a8e-2a9b47ce243f@juniper.net> <6238FC57-EFF7-423F-AABB-0E433A9AA20C@cisco.com> <86a5e8e1-f543-8e93-3cd8-d4deaf43a1e6@juniper.net> In-Reply-To: <86a5e8e1-f543-8e93-3cd8-d4deaf43a1e6@juniper.net> 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.235] Content-Type: text/plain; charset="us-ascii" Content-ID: <55BE333B9B51524DA2F483CE04E62956@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] decrementing service function path index 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, 17 Nov 2016 13:48:25 -0000 > On Nov 14, 2016, at 2:54 PM, Eric C Rosen wrote: >=20 > On 11/11/2016 4:13 PM, Dave Dolson wrote: >> I think there is some layering confusion here. >> As I see it, once you put NSH inside another transport (e.g., to deliver= it from an SFF to an SF), the intermediate nodes aren't doing NSH anymore. >> So it might make sense to draw diagrams of logical connectivity. >> Eric, I think in your examples all of the SFFs are "connected" to all of= the SFs at the logical level. >=20 > Suppose SFF1 connects directly to SF1-1 and SF2-1, whereas SFF2 connects = directly to SF1-2 and SF2-2. And suppose that an SPI/SI of 17/255 means "S= F1", while an SPI/SI of 17/254 means "SF2". >=20 > I was thinking that: >=20 > - each SFI knows the SFF to which it is directly connected; >=20 SFIs don't need to know that: they simply return the packet from whence it = came. > - there is a unidirectional transport connection from an SFF to those SFI= s to which it is not locally connected. >=20 > Then the processing might be something like the following: >=20 > SFF1 sees an NSH packet whose SPI/SI is 17/255. >=20 > SFF1 selects SF1-1 and delivers the packet to it. >=20 > SF1-1 processes the packet (based on its NSH), decrements the SI, and del= ivers the packet with an SPI/SI of 17/254 to SFF1. >=20 > SFF1 processes the packet (based on its NSH), and selects SF2-2. SFF1 sen= ds the packet to SF2-2 over a unidirectional transport connection. >=20 > SF2-2 processes the packet (based on its NSH), decrements the SI, and del= ivers the packet with SPI/253 to SFF2. You appear to be thinking of SFF as a PE-like device. That is decidedly no= t what SFFs are. They are simply logical front-ends for service functions.= As I mentioned above, the SFI, SF2-2 in this case, simply returns the pac= ket to SFF1. Nothing more complex than that. If you need multiple instances of SFF1 (let's say for redundancy), then it'= s an implementation decision how to ensure SPI/SI tables are consistent bet= ween them. >=20 > SFF2 recognizes (based on the NSH) that the packet is at the end of its s= ervice path. >=20 > Note that when SF2-2 is done with the packet, it does not send it to SFF1= , it sends it to SFF2. The "direct" connection and the "remote" connectio= n are not treated the same. The "direct" connection could of course be imp= lemented as a transport session. But in this model, SF1-2 and SF2-2 do not = know about SFF1, they only know about SFF2. So I think it would be a bit m= isleading to say that the direct connection and the remote connection are b= oth logical connections. The remote connection is really unidirectional (S= FF-->SFI) and the SFI doesn't know who sent the packet. The local connecti= on is bidirectional (SFF<-->SFI). >=20 "remote" and "direct" are distinctions without a difference. SFF1 is "resp= onsible" for the services that are connected to it, that's it.=20 > It might have made more sense to say that SFF1 should send an SPI/254 pac= ket through a transport connection to SFF2, and that SFF2 should dispatch t= he packet to an SF2 instance without first sending it to another SFF. But = this would require one of the following two solutions: >=20 > - either a flag in the NSH that means "already seen by an SFF", or >=20 > - the SFF would have to know that packets received on certain transport c= onnections are from an SFF. >=20 > Both of these solutions are simple enough, but both appear to have been r= uled out by the WG for some reason. >=20 >=20 Because, frankly, they aren't needed. The current (implemented) model work= s, is simple to understand and provides the requisite behavior for chaining= . From nobody Thu Nov 17 08:15:49 2016 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 41B1612948A for ; Thu, 17 Nov 2016 08:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=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 QG3hn3mGqd14 for ; Thu, 17 Nov 2016 08:15:45 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0128.outbound.protection.outlook.com [104.47.38.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D2912940C for ; Thu, 17 Nov 2016 08:15:45 -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=bzCgz/QQLlsMwnGfGWMq2PLEKnghIUou0e6NhEoB3fg=; b=eaXiYdTbRkQEx0Cvlaq6C1e/jaFWoGh3RKn9Ahq04jbIDYTRFItKY395mHM4hfbDoZFDIcsjm5N4q7gFgtLLj1C0JUyMAHs5fECo4CqTOZXL2xQ9O7v5sBdEd3ozQcVKI/B1vB/G9TIZtyS2YDN3y/a3XqwAzgksyIKveu8nmvc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.36.9] (66.129.241.11) by BY2PR05MB2181.namprd05.prod.outlook.com (10.166.112.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Thu, 17 Nov 2016 16:15:43 +0000 To: "Paul Quinn (paulq)" References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <71fee848-be00-9137-286f-4908125e62a5@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D572EC726@dfweml501-mbb> <37aa2696-34fc-54d5-f607-10d747ac87fa@juniper.net> <1EFFEB68-B740-45E7-A42F-D0368671254D@cisco.com> From: Eric C Rosen Message-ID: Date: Thu, 17 Nov 2016 11:15:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1EFFEB68-B740-45E7-A42F-D0368671254D@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BY2PR08CA0015.namprd08.prod.outlook.com (10.163.62.153) To BY2PR05MB2181.namprd05.prod.outlook.com (10.166.112.9) X-MS-Office365-Filtering-Correlation-Id: c7d0f182-ca5a-4e49-be30-08d40f04fb4d X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR05MB2181; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 3:qAZU8+1SRKNVjZ6dT+pnCeJaFuDIKUmMFEFSzOUrhkQQeIOg86OF8B8224lDS05eq8+5ZX0M/97eTD6DADOTjbpOJimSI1xfKlqCDFdkMHY8YbnwDjQPeYWwN9YLfO2xn4Tyf1sF8OiMqh0Rwxt3RqXvEbWP3lk6HFFUDpOF0p8wY1/uDkkGvliirDi3S464tSzufujgS+xefE59AAIFYaVPVbGk0jM9o42HDYNNikX0MO3TmB66/MaSY8x/21GP6BuujVXJLu2xoBEzb7a3BQ== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 25:Ii6zqwiHhA7hd2i/L+Un7SjZmyZdoGTHHTPCDnygmEKs99atcVcX0vuqTcHGHNv62RU8bIdH+KoxoIOmiwMqzLK2poFypiMDDpJjmBbLAr5ckiCLIeA7JK7pOFS+vHFcVX7QjCh/F+l1o3h+4dSNF0/tq1ydSq+wSu053v4oIiXkAuA0Iuk0LVX9MFvABoNVkhoCY0LwTDVjsdEsTa2cfjcQBqvLHZ6QkRIQWjW0rOIYbhvcptC0mTIwgp/5WlQ8yGsp2+zgaztXEmYBGQkEL9dl6nLcyYo5BhER4s4yo77Ab13V8WlNJb2YUr+Z2PV9gxIuEwgo+sjH0x5b2EBRKKN+gZ+ndxpD9j5V2cBk1utf2UblPlH9coZrA3lcyOcWAJmH43Hq6lUrV8L0VmEHT2YCSEGf61hwAWIezdosOgv+9+eUMsU0ZY03AxK63nd6Nvpe/O0PWYRu2m5hDbJFKrmxl38+V+dEu474+fW2+elfAkLoKP90tMLtrSziWz3Ft5NDUfof3FURWf7/S/3WnllpaloWzVD9Dw17ahxzJnmMt1uc0CtJzbIJz6KYSHpnepYuCkMt3uXTp6JpnxraZJedIfZ1D3mZATrLsTGwYswhJCnxCJYiJYE5+6vk1zInIXmISJcYKmIfh4hnybPKoalWCdO4l3hpJzQPOAZ5IRAjJoY8e5hvVobdgGFwSJBqznSjsKcryDtB67D0MzFoOrj8v4eWQ9SfnvtMv14sFNchs1CGadJ4fyYXcfSHWkHA7EDbocdYb5LW5kpCWIgHJyZOOJ2GXYdR/hns9LetL1c= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 31:qQk/BJO15spZuk5AsR6ZPv5fugzqa+GywPb3BwW4m72+EEiKHc5mElexChmsJfE3FLbuvEhofqaKEHY4YCAuAoNeGngZN0VFEf779qvgBF34la+xJ69kMqu6Rvtggoe1sCfdRHam7mH0+0Ar1QGZQHn58lyZ/8Ust6OFDe616/DPAigrlOwDUJ0BOJ1Ptvk/W3V2nXcHhMgb9SEvyM5gG+wT8ZEj01IWtJ4kaXG8HB7Y98GRt7qmNsBT7arBV8I4Ym7kwe6/wqTz+W5OK1Nik26tIXMM6XvgVdn0T2OMu2c=; 20:YFWmWTxjMmGqXU6EzKiF7NLLoRNCk5HiWkgt/94H0p+IakjGyhS2DnpPn5Rt2X/cywQFdFheD7ykboXXk7WX92XtR0R1ZVXHsvBxlKB3OzSH+CiSEibLW7y+l8Ey7ZRhbE+TRBxoVTktfvo8YVKf5yhzOp16DLg/+EP9r2GfgEMsYciz1AtRH/IASQxqcmBp5esB0CSXjkj6weYCVQZW8Or/R4DTgj9nkAPriDRkmSh4kXEjiweAkXpFJfhfkSPSkOoYUSvpjEr35j9SS6df2iDArfln1woNfWgQa74huB1iS1m7uUwJ1yKb01Ueh5kjrvd8SDFFLhq2xcCTQZZUaz2jCyHG0GihuTbo5d1ks9cXo+vbujXvpBjyHIrEzw0srpP8rWLlz/9GWCx66QN/CGTs8ZoFKijz3Nsz7+mW0E+4uM7FbNUMlHY1kGi7txsF0YgEqB56f+P1IdzcrRjGUL+AbgmjrUOup8AfZ9mPnV45JOGSCTAR7rCIlHSLMcBLpy6bx7QBBpRupKU842MHSAy0Avi8EL1Kl8240hClJ3pUv2kc4AWmIiPTW0IOCVNY6PzcDaLDcc2RH4mXTTyEXS+/EttIFqtDHTUeOsbIGoY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040281)(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041223)(6061324)(6072148); SRVR:BY2PR05MB2181; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2181; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 4:E3qvXOPB42e3rrMndtJ1ojx3emcgGVbZlNkzXBBe0Y2o3VLKWDDNHr8nj2egMz/aNA/wqVZtZjd8AEfuByZ1cqIZBsWcPyCsGnGnl6/vK1Z/DQvbEkxacv8+yER3PZjO/D187Cc9qcBdZKp3dK2P3+TAf4U9I/dQOt1Qol6aSRHIP8AvpOeai/bMuCe6dmocasZF+5CTbGNpVwu9okjnLZMGtAg6r6Glc774thjSyAtxw+6yQIokwp0qI/vna1OrN5hFEBFg+6Ri7KqM1+PqAhd+wdBOUMS7oOExZAEnGAOFa373IzcoeiJjqso6ipdkg3mJCQzL732sRaweYjjAB5dVIo/bJYnfqEXNjbvHpVtyAXlccCljTgtQbCo7SbExE7Wj6MmRtZrXItKjD1vFg5zYCGScmaLl7PygtD13Tcwe4e9O+936b9VaEKt3M8AzaM5HUc5oTuQ4L6UhjdunLrsHpLf6UPkXqtsKXD6BcPKTjHRsGiMjUxpri3RzTivZ5Ac5w4/e32jJxirvOEnjNvnqSx/LUQkCNSPbJyqUuxc= X-Forefront-PRVS: 01294F875B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(189002)(65956001)(66066001)(47776003)(65806001)(101416001)(3846002)(6116002)(36756003)(50466002)(230700001)(54356999)(50986999)(76176999)(189998001)(4001350100001)(97736004)(106356001)(2906002)(105586002)(93886004)(68736007)(33646002)(8676002)(81156014)(81166006)(77096005)(42186005)(31686004)(92566002)(4326007)(23746002)(83506001)(110136003)(64126003)(86362001)(229853002)(65826007)(6666003)(305945005)(2950100002)(5660300001)(7736002)(6916009)(7846002)(31696002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2181; H:[172.29.36.9]; 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: =?Windows-1252?Q?1; BY2PR05MB2181; 23:jLtttXxH5HIzd9cS4bZurq4gp9Z4qFAIzPWpi?= =?Windows-1252?Q?o3MjeoeQGe6ZprnoO7nz2JTEObIOqZ21LlrvvjqjPZX6QyoihkWWHJ6k?= =?Windows-1252?Q?dcwsEne6KI2WI+rJjJQPpqPTnys+V7YgTSYMNbYda6mT7b571DjSQmPg?= =?Windows-1252?Q?Z3rAZRTkR60/+Rr4vxElYGQaOWKbVQdSobOqM/LU4JnWkg5e44TZsAPx?= =?Windows-1252?Q?BOhA2Lt3bRztQnPInFyiJ1Z3zdy1MkhAMw5DEnsFM86I7RvmsOwIz6B8?= =?Windows-1252?Q?e2eyIPbEcrAuH8I5ySgBnY74PFn0Y8eWGVzomSheQML06/3sbYR+P6iS?= =?Windows-1252?Q?kztFTNnZTZYwJQiI/6lfmWaqdA6MQfQtz4o4X9A9HpgA6eEjiLTgrqSe?= =?Windows-1252?Q?ZxCCCtUD3+WYIaLT6KHN/qkcj533dfbM+/xc1T95rFXChjPMRF+xBIhy?= =?Windows-1252?Q?9+nazNd0gGCcTy0wX4CVcSFhyFcgyF03larGs7mi9pWwzGjlj8Ax+frl?= =?Windows-1252?Q?PiHSBt6te37hyDUTqabmQqN6N/AUIiUXA7yRGFIe2KzKxe0CGWIORT7c?= =?Windows-1252?Q?rMzbM2AliDWhr9jYgSMb3XRVRIrBVg/TRWl1+wHUPipJkKfOHWfGKf3K?= =?Windows-1252?Q?JFZw0KXyq9Qydb9YCmh5umaNWZDF+pCVJj57qXtYfD5nkaD/voCyUXDk?= =?Windows-1252?Q?cgMamZ8gDhJ62ILvUGRSF+Qc8ou2jgmkqMuLCFkM0cX7OzRIi+GHEpTw?= =?Windows-1252?Q?nMM9Q1DBY4V6Nu59OZcX2icN/bjpipqddmuBI5O8qbjXbKA0q6E8Kim5?= =?Windows-1252?Q?5ApetiG0xUk/T7KUu9kyVaNvZr967o2xrCrsV8EWuYG93IubOLMREI3U?= =?Windows-1252?Q?ZfASs33uSHXz/4kRRbr6YQ90DZh0ssXfy9rM2CbF0Wy84V/bbTb+bmZQ?= =?Windows-1252?Q?krElw8R38dlgn9x/VWEkmfKCZyuTJj3PVC+jfS0bAETxvlg7Pm2sjcVu?= =?Windows-1252?Q?vWh/w56g+CpipVn8CFh91v3QI3l2OivnzUFSW1KNBxsJrHFGIi/Bc3ud?= =?Windows-1252?Q?cA3Ai7fMUT8jtrSZD4pQ2UWChpKQobkMbk9uWwA031EyTEwToR3CnHFS?= =?Windows-1252?Q?iG2c4TlsB20Pjpdy5x4UTleWw6py/LdzTtRSlPvbxbUnyyd/EAK+EkkZ?= =?Windows-1252?Q?TaFR0MT9RJjX5pBT7CvffslqQ+dXAmU09ETfNoqrH/k3bsL2aKYYrpDs?= =?Windows-1252?Q?HAroEHTEWgXJfzXZzyDG9mOiNXpFz/Z1HSpxozbNIeB43OmlEI1svoSh?= =?Windows-1252?Q?P8OslcW9Ajy3mj5XZ+wQVYyWA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 6:HVNKLoO8Y1y9yJAc3AiMfAPZcIHaNFZjr0f2Dc50qAtBf3ev5Hi5QIjOAPUgnEe9wujBYtEv6TOUOAW8UCovuLsQkNvE/1wgvXL40fTGjfRvLb/Aq3xW8IDpIfd9pps2I6Lsvobpu7jyThPJboR8Pl1Zg3j9Z5K7xwAwImkvfV4OyLvh/aO8xw8OioBKgqNR0kEHxrtOPApZGwkCqD0rTboFFyV7EqIQXNaNABVOc5Toz6nhWsX154znMIpTzja0uIqUhr9OEkSOgWnJy6EFRlZjACR4ir5KlQoEeF4fm05oZcDJNjmLC1nY2t/9yegTqJocUmfswvme7l1SOlhUCd0dPCyL9Fbzktj6da0cdL4L1lCuCfJLSGpeD5TnjxoDwbt/F6k6vwyFJfak/0COqJ9FSiMSgs3qt4Gk1o/z+YCX8UU4dNkf0nYQa3Ca2q46rTrQ2Ld9+XG5Z0y3CjwsoQAtJ52InW1s3mAAvh7IKLe3RMYWuZmpYs4JPSyWnWfY; 5:3gzeW0WyPLvFJwxkwR/cZxC0sI0iEaPAgfyOOlu/VDSIIaGwNyx+quIXcwz1WCtr6UrsmT67nTg6lWNGS3SJLhOLacjhKSUEiDv9vo+LrcysKBhFyvuo3rAna8UoF5yTeIyIoK5ZjsbkU61GY04Ewg==; 24:D3sh5WFL/WjMMu2JcCdzOqjSrEeVlCJNdRXTzRMySOyKLrUDeN3/lVz+ul6e42JWwFNbTWBtbNpSEiIf8wRbItP5DYCO7i6yde50LL6tuqI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 7:lW73uj1+gHraUv3J8eAJqZlyuhPSL8jUx5d53hf3lG0fvxKm8r1Kk/1JzJhq3F7vMk4QvazTSGsIX2eTNUUd29VEjcMzTlLWpCeiIteMIils0Fek8Abp4P6ZvpEvf/LQRmrNGe8HKB55rQ+9gUNDLX72goylOxwZLgcjz0Pk0vUqCYgBfWUTuX1MiYqRPLaTaodc4ZhqtO3p1jEmxUItJXZGhjXk6aR2RSOjMXwu6AehlK0PAVKGgehtt1i7ZSnAklst4FI7lDUXUc6+vwnFgMcq9IqMuznOlwNImcTf/bo9BMqiDdTXC5mtp0oRC5JAIqhNQF8OwtuTQY8ZYewA7mu6aZXw96wAGKqJsqGKbSg1DE1bl4w4QkSrnbXWGk0CBkmfPz84TVNwKcZCYqbDeneX0uvnXMLvL17O1EM0N+FE6N5Y5JGHL/kRt1ZWgXXECmSr3HpVOUjYwhuQq8OXJQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2016 16:15:43.0319 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2181 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 17 Nov 2016 16:15:47 -0000 Paul> This convergence issue isn't germane to NSH. I don't see how such a statement could possibly be true. The behavior of the routing system during the convergence period after a change always has to be understood. Paul> Devices need to have a consistent view of the state of the network, for a given plane, when moving packets. Routing in general would be a lot simpler if convergence were instantaneous. In reality, devices do not always have a consistent view of the state of the network. Paul> You are implying some things about the control plane, that might not be true, if for, example a "pull" model is used. It is true that I was assuming a particular control plane model, but I don't think a "pull" model eliminates the convergence issues. Lucy> Do you want that, if an SFF can't reach an SF temporarily due to a failure, allow the SFF to resets SI and forward to next SI? Eric> That's an interesting question. I'm not sure what the desired behavior is in that case. Paul> In general it comes down to simple policy. For the most part services, particularly, when security services are involved, the default is to stop sending packets down the chain. Can the policy be different for different SF types? If so, is the SFF expected to know the type of the next hop SF, so that it can determine the proper policy to apply when the next hop is unreachable? Eric> Of course, someone will say that the WG has already determined that the SPIs never need to be modified dynamically. But that's really a deployment decision, not a decision that should be forced by the architecture or the protocol design. Paul> On the contrary: dynamically updating SPI is supported and the need for that functionality is clear. Glad to hear it. But some of the long-time WG participants have suggested that if you modify a service path dynamically, you have to change the SPI value that you use to denote that path in the NSH. Eric> each SFI knows the SFF to which it is directly connected Paul> SFIs don't need to know that: they simply return the packet from whence it came. It's pretty hard to return a packet from whence it came if you don't know from whence it came. Perhaps you are saying that each SFI has a co-resident SFF, so it always knows how to return the packet to it. But that's not any different than what I said, except for the fact that you'll have the looping problem I described. Paul> You appear to be thinking of SFF as a PE-like device. That is decidedly not what SFFs are. They are simply logical front-ends for service functions. I was just thinking of an SFF as an abstract entity of some sort that looks up an SPI/SI value, and determines from that lookup what the next SFI hop is, and how to get the packet there. Paul> As I mentioned above, the SFI, SF2-2 in this case, simply returns the packet to SFF1. Nothing more complex than that. That wouldn't make much sense in my example, even assuming that SF2-2 knew how to return the packet to SFF1, because SFF1 and SF2-2 are not co-resident, and you wouldn't want to send the packet across the network just to figure out where its next hop is. Paul> "remote" and "direct" are distinctions without a difference. I don't see how that could possibly be the case. Are you saying that SFC load-balancing decisions are not allowed to take factors like latency or load into account? Paul> The current (implemented) model works, is simple to understand and provides the requisite behavior for chaining. What a convincing argument! From nobody Fri Nov 18 10:39:37 2016 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 DF1D8129626 for ; Fri, 18 Nov 2016 10:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 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=-1.497, 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 ulyQIhTcjbsS for ; Fri, 18 Nov 2016 10:39:33 -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 468C9129406 for ; Fri, 18 Nov 2016 10:39:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=620; q=dns/txt; s=iport; t=1479494373; x=1480703973; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zD/XAAuX7c9puA8vFxo4dPJtrDzRvSxm0WOgMLecCuI=; b=eCQHJDS8jGF3k4vE2/cRaSP+/lsysLqV/o6kmhwWijYETKeAyoheMYn5 3PWrvGr782yTeitEfVvkX+x6H5bJ5URzv5PU5AgJ5CSIs790wqM/piL2K jMFfcvVwWVBqf8MmxRKYerDbTa9uVCX5aDfPM8XIvvyKdbY/b4O5cNPGk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQCQSi9Y/51dJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR+BWAeNOJcPlGaCB4YhAoIMPxQBAgEBAQEBAQFiKIRoAQE?= =?us-ascii?q?BAwE6PwULAgEIGB4FCzIlAgQOBYhkCK4xi0kBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEchjyBfYJdhCUkgzGCMAEEmksBkHGBWo5NjVuECgEeN4ELg0UcGIFFcoYHgTC?= =?us-ascii?q?BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,659,1473120000"; d="scan'208";a="176581172" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2016 18:39:32 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uAIIdWdn022066 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 18:39:32 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 18 Nov 2016 12:39:31 -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; Fri, 18 Nov 2016 12:39:31 -0600 From: "Paul Quinn (paulq)" To: Eric C Rosen Thread-Topic: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] Thread-Index: AdI4FZoby3s/XPxYbUq35Andp+fNvQAORE0AANk5y4AADtlJgAC/lDGAAIeIBAAABS0pgAA3UcSA Date: Fri, 18 Nov 2016 18:39:31 +0000 Message-ID: <10E8EE3C-27C5-464B-BC33-156E6BC4837B@cisco.com> References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <71fee848-be00-9137-286f-4908125e62a5@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D572EC726@dfweml501-mbb> <37aa2696-34fc-54d5-f607-10d747ac87fa@juniper.net> <1EFFEB68-B740-45E7-A42F-D0368671254D@cisco.com> 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.235] Content-Type: text/plain; charset="us-ascii" Content-ID: <7A83261100301545819447F4465783EE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 18 Nov 2016 18:39:35 -0000 > On Nov 17, 2016, at 11:15 AM, Eric C Rosen wrote: >=20 >=20 > Paul> This convergence issue isn't germane to NSH. >=20 > I don't see how such a statement could possibly be true. The behavior of= the routing system during the convergence period after a change always has= to be understood. >=20 Eric, you are correct, rather, I should have said: unique to NSH, nor does = NSH introduce any unique requirements. In fact, given the limited scope of= NSH forwarding (i.e. not global routing), NSH lookup merely results in map= ping to the network topology, where routing occurs.= From nobody Mon Nov 21 10:22:39 2016 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 84BFC129B3A for ; Mon, 21 Nov 2016 10:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=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 nLb7L4w2Swza for ; Mon, 21 Nov 2016 10:22:36 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0113.outbound.protection.outlook.com [104.47.37.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E5A129B35 for ; Mon, 21 Nov 2016 10:22:36 -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=Suai0WxZobrzBZZ1CQusgurwXmvc5QP57hqG5m0Rkk0=; b=RfIgdgx6mYyLzhBHHp0/p5yHEY+MsLu+c057ez0+VgY394xnZb36DOTt5T4CohIrWToJMEt2oIvwO16cMnZC1RI1DWuaK3QPP/RoyHiIn242C3BVr9sdFgEyiq+2e6+6qgNSH2n3/PV2+w/NeRKCmrjclBkmpQUvpMjHdaInl8A= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.33.13] (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.747.5; Mon, 21 Nov 2016 18:22:33 +0000 To: "Paul Quinn (paulq)" References: <016e01d23815$ad464d20$07d2e760$@olddog.co.uk> <71fee848-be00-9137-286f-4908125e62a5@pi.nu> <2691CE0099834E4A9C5044EEC662BB9D572EC726@dfweml501-mbb> <37aa2696-34fc-54d5-f607-10d747ac87fa@juniper.net> <1EFFEB68-B740-45E7-A42F-D0368671254D@cisco.com> <10E8EE3C-27C5-464B-BC33-156E6BC4837B@cisco.com> From: Eric C Rosen Message-ID: <115e3e41-7523-e3db-1d12-821956b5050e@juniper.net> Date: Mon, 21 Nov 2016 13:22:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <10E8EE3C-27C5-464B-BC33-156E6BC4837B@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BY2PR03CA041.namprd03.prod.outlook.com (10.141.249.14) To BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) X-MS-Office365-Filtering-Correlation-Id: 17f6dbc9-ad4b-41db-6fbf-08d4123b5d6f X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:h+GhpuIu4uOb4pCugT2k67vI8tjH/wwgaAxwtkyz9YPXz7lRfj4UujtH5I3kyuhuiuoOV4Na+yUA5KzbiG3Xn33mjl7MeUn1PHq2LvACbTrkvpZWSjegkmzCzbsMeCMpordjfV2WTTV1uU4zTXtwXddJNSdDfmOEmljbnvRYnbmNGKe+y8R+BtLZlzdwk4/zly7I+8kUlNERwTQC/Uk1y4D/m3lsovCAxoE89VFAzw29kJDqKbZNsGxM00b4yleMqCGdEWhL78ZPA/ZFBaT3VQ==; 25:jCvrswmvvKAEuvlAV5dS1igr8NIyFRydsUwZaBDAeAOz924afQXpE1wsuW8gvo3YHSlVIqWw46yHH7P3d/3dfMAfE6uhlOK6Jc4zNmy1A+s6baZav9qX767K/WfheSvyueJU6nSe0/MAKSLBAvRQ7bBtmRsrdaMs/nnd3CFNi2tLgWrm57ecjdidJm6fQBCKnvIgNeliwD0tPht2M26PBw7Ao+DsTHTJcGU0/q58u0ZT/jNd7OYBR3eNr23Sj1FaYSA30bRJxiiqBIrgkmSdJEC+s9A3ma2WrLniFyFO1CKC8+CdxrpUTYK9r2aPXrovnKvMhcm6nZMiOqCwx5pnjkA8wwg361CmR8JetOrWrkC+ZjPPJ4XfsQgCuQ0Az+1IbwAZls5cj4Z3VsN2kCbtPvxgpoT3zeSro13uo1iEQlaBNCwePMp93znTLywpfmlKLwhc8MAe6oTEb9DhYWHcnQ== X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:gbvaQe6sa4tQUHSj+mg438PM6P3EDidQ7cv8df0+RfhttKuueYVtX+GERY+ZmRSinx8Ci09LJVk6QbS3j/QiSBTj5SzCqmu+s657pX6VJCex5kCWhdnUM51l8yw3apEA+yB58BpH0WJQwBdaPXVRucbBWIQqWE0Yy2Xhm3XSPn8ZRHmGKK4Na1HY9Xz+UnIRcQigKuVooKCBW/DQuBNLG3zeeY7xW3vAUMNBiNZtW63FneAMKcAeCzEaEIP0pzVvCwTloRCju0zwuIxRI0QIwE3NeSBjgmHLLp17nwCkFf0=; 20:HHqDy/dqdjosQsUrhp8DLY0P2yk7prfWipuFhlFL9nrQEiKkuFrgUHOjA6WgcKAp/wMulGzdVe5zaXKQkaC+GUeJY8r+IfM4YP7ea6U2H6ZZDM6x1ZmMomBmjj0mKGNZvCLeqowXw1mUuRLWshusVPa69IvE+S0DbPUMbvUxAnG5OoXub59OVCkarwRTjHzjVzf+GStTWP+eTGpg5mt1BbYucsYxraPeBMQadwK/ViyAcWbv7Y5rLFgQNF+iAmlFKaEY5qqrQrWz9SVp81bXiif6dYoEpGOoxMoWEvUclJMx/aqVkp6f2XzwE0LizAcToHVUHKynECKT4FleoZMQqIdCFjBPqYT5pr7cACvmOpRaZyTCgpeN5+wruHJViRr6k4qIQhldgk5GzaJJ/hvrazKWyjG62PbqdlC5xMp0OnbcqhiG5d4TTe9X5UGnbVYw2IxGNxqy9e1qtVPKW8MbfKAqLY4meo/NCEDuOERt1m+T/8ydLWHs0O0t/BWsA3G/58fZO/1G+gB3/q4h2vgme+agyFK/qn7lnvc3Z5tpOZOUuQrdBQppzTuBntVSlCsZMo0hcpDomnbWBzXlutgj764L1AMRcLwzpKnOhIEy55I= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(6061324)(6072148)(6042181); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:n17kRrraw4VDLgjrJ32Qj3B3P44K6VPWK/NM1BJbRQE5j9fL7FTnJjXtLRpXPZ6w2iuEHUCHgef7Sfvl4LH1kedvARGCq3ohGWsMEl3hGBTw6k8DNCoE8tN1xIinIZT0OiQxiWVUHiD2L7s1ABVgNl/A7QGdZ71msF1P7QAkspLcPgV5AHu9mkFD6Ljb8EG43yEvzooB0m817thSqPnjdpk8yBNeuRbfLRFOVj/IhtSqq6e/hYCXtn21zNWgrhJEM7XFNVP69jBL+ZCCoa5xZQMnF4RChTYEDR0YN/gU4bu2E+4BOOMp2GScasTUF7sckQmsV0QfDTpOpRPBjUyLJCKjrPUMfG5GoZrFTSwsR8fiiWv6n5eHv/LUbMMjikdZ8mtjZtJxoZL9doWrL6uhqluR13QE493+R8EzgeVqSLIVz5BkTYObZY0nevzaMiH62T2S3bYrl+/3w0CBGrmc9ajTtgI2Sheu08WzznG/eJg7nX3D9EqtD/esLEBKD0VLCPDyt8byd3WtdHg4IvG3SzWHoEJFPTjWJt4DBd262XI= X-Forefront-PRVS: 01334458E5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(24454002)(377454003)(189002)(6116002)(83506001)(68736007)(92566002)(66066001)(65806001)(65956001)(47776003)(101416001)(230700001)(189998001)(3846002)(7846002)(105586002)(50466002)(50986999)(7736002)(106356001)(33646002)(54356999)(76176999)(305945005)(2950100002)(6916009)(6666003)(65826007)(81166006)(110136003)(5660300001)(23746002)(4326007)(64126003)(81156014)(31696002)(2906002)(77096005)(31686004)(229853002)(4001350100001)(86362001)(38730400001)(93886004)(97736004)(36756003)(8676002)(42186005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.33.13]; 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: =?Windows-1252?Q?1; BL2PR05MB2180; 23:QR0grji6ynlpObjSNCN6OtBkb9m7dOSlQuHPt?= =?Windows-1252?Q?qDGJLTRQIopOLoqAcpOjS6pcdBSxv+IiuLq2e5uhVHPrkMaqgK4m20Op?= =?Windows-1252?Q?b/aOjZdWv2GHzaJnJfLwj3aKpAASFmXyT2s3OLmXOp+T0Lma0wqEW+iH?= =?Windows-1252?Q?fDNiduAquIEvhYQfisoSQodNKegEfVspsy5qHhn9ffLyrmb662yBy6nm?= =?Windows-1252?Q?Iau/i9jL78FvyBLkDL/DGcTi0GrQB3yLBhNy4S1FsmZykoOQJt5huMQ5?= =?Windows-1252?Q?5zKy+TuTZHGpItQ4HFgGdYYNU5xqTMAclSRwNzQWFLEbdVZzAFDElOIo?= =?Windows-1252?Q?qMNVpAPPtxLZ9t2R2cMkoLTpiB8Ku71eLkJ25PIQ4b0QgS/xEqGpZi3D?= =?Windows-1252?Q?sveNm6Nr2cEAOkjzIu37MD8crnCJv8zjpp1y2la/o+XPWnhCHHoTLyw9?= =?Windows-1252?Q?WDhiOvf5iNPFOtbsJFnrr32Hy/iyncVvOmQjq3SMdWe/ShM6Nx4QATdJ?= =?Windows-1252?Q?hoqcQpwaKNy2E8tP7TkeckW1u5h0ePLxeqjkf2e4nUUt1dU7Ai4GO7XA?= =?Windows-1252?Q?oE58wNWnzEMmlE++5NFbF+Q+rW6Hq8SHcZk8XtTbbIMtrnflMwUWaebu?= =?Windows-1252?Q?TjzRdgCQTueShmwgig7F/cYTTlly0o96cuHuc3AyG/I95BxzYAAtN7hK?= =?Windows-1252?Q?JsuoqMbb4WBFRaxm+CGu/GAMzULSXrIEAlSLQS1hDufSc3xqqor95fny?= =?Windows-1252?Q?vufEDZaXoOPdWEtmyjp2en7LCMGi1IzuY+QG81EPmQ2clNUQWjW7tV8r?= =?Windows-1252?Q?5C/Shu8VpU3Te0SRUguJoR12+gbuu97CYcgKuwAlO7tUznLrL2SIMv4C?= =?Windows-1252?Q?rtKR1rxl6lWEH5tiOOG39rSDucWQXYhopQzwdU0oCo3MM+hg7T1j2ixC?= =?Windows-1252?Q?uwooQU7VHSlcRjaGqraYIvROH6rGsIuvWVeBE8cXMcDJScz6PW20AHs9?= =?Windows-1252?Q?sPfkJODbDThY232NvF/FYvabbFFBPy2Kb+i5Xxt6noDxydIFOVy738Rd?= =?Windows-1252?Q?cC7XPdXwlAteXmRAol5vTWPQHxO6Nni352fDDQv0GQEcwXKi1UFKQZ20?= =?Windows-1252?Q?slPIMa4rcrW+kb7zUEgC2ULs5pCJfWu6DxB3q9xTod9G9o0EYfE6uzxZ?= =?Windows-1252?Q?KuiZvECl7aYEzK+0Qppldn7x3o/hzw1aXb27acOPvPdVvJg8b669Nqvn?= =?Windows-1252?Q?bRBac83KCXXMES+x26WKrekgTu7k2nfLta29nh02q5J4gBs0RPUo+fH0?= =?Windows-1252?Q?5Zc++9Qsg2KfmQEtAhv0g4jza/oCN4ylqPQf51OiAlEbLeHROej4Hsu0?= =?Windows-1252?Q?E4wI0dC9wgis2IzzC90RcIy2FnWkNr8uw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:NVl/1WBJnxz/8sO6OPlVGOrASzkXzLYcbzBXWJDbDESQR6hCK4R6XJ5PZMN99eMEY6gCMm8yDIWIm4G0T/ZcnUQrbK3tbp3mVTn6RKTKj+aGDqgimD7dRcvTQXpwnnFs/fV/FHgx/eRSuGPmZyN2aoKSvT/9CiAWjkq76u/yz6noCS+rUzH9/QDvZX6MMBCzPOsIoJdgweZdB9DwGlmLny2QrS8IYp4a7mITX4f7UMhYN/XEOxPtL/ymml8ynKohCqqCcx+8nDvfeYW8cC80MH6ICYjzqlfmjCX98yOuwLIUMRMzWGFzWdXcAvtBF3JhfAlQHp5JTfrDiIaQLM83u0ZCiNr+XjR1qYQt06v4iVUjnfkkyr+MLJzcyIBNaROxdVcNcxecdGv8IpTob0OgHlfdy5/xI36HZZciZas7zx42ulOIJMSDubS33nbgqTpCOShijHDjvARZPy52SzJvnmPqYujK0e4aTPra2Q4Fcot3uHmmgtHmuv+c+IrkmRTo; 5:puXsJRj7lgJHNk53Eb41VviXl0tYzCnTQ3mXsFyRNWqJIJQJz4QdP0vwGeweGgNrsqe1Eh0fwvWFnYkklIwUqeB+qF9EBjOR6YXodEmxxoWWckcMeRwV/EFBjhjeL9dY55XX1x5uE5+0dTHOt42XjMUFQHowDzWFf+abcTPgtrg=; 24:a1nHTbIjnnneZ0s1D+6oZWttC/0vsFaRIuW03qAS5GtRLXJcm5S3AO4MhOuBiSXaehzhx4SOjp6Oha7e/gDM9HK8qedEF8WSdFUk/TqjdNA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:NRwZBVnolOGGMXT3SKGM6owFpMIpAehwNL55vG04EMxoGST3fnly1oDX2k8J/jDFouY9IXXFY7yKEg4ed5/ON8aXZvusg313Rn0NSrHXlOztlH908TrjmLk9BhZS+5wYpDXZCxEtlVKlAY9P4+DkpsQREXm7OEJhRh48RApxAxQgU0mW3cjvU1fuVCa0TNuY+2qP7g9MOmoHtVXVL3RbqtAgkmi84O49CrUbwduf4NxMs5uSrfVibPqjzj95LWPmlYpn88maE7n8vigZa6TD4b2cYfNNPdz3lseo5xaX7MMpWr9lqrKR6RAHbXze6ogFObM1dkeL/SaWwjYMOs+XNsy4geuz/YWL9fUgmVQXasT5Jhy6qtu1WF5bqLsoXGgUkBW9B208UHSFrbmGpJARBR2nVABHQ6ZycICx097141DxTmCYK9p9ZA37M1iQGdsVX62IHT+6hHpqqlay5e0WYw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Nov 2016 18:22:33.6029 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] OK. Enough with the looping (spiralling :-) [Was: decrementing service function path index] 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, 21 Nov 2016 18:22:38 -0000 On 11/18/2016 1:39 PM, Paul Quinn (paulq) wrote: > given the limited scope of NSH forwarding (i.e. not global routing), NSH lookup merely results in mapping to the network topology, where routing occurs. Each SFF looks up a single SPI/SI value to determine the next service hop, i.e., the next SFI, to which a given packet needs to be sent. If the SFI denoted by a particular SPI/SI value changes while the packet is in flight, the SFFs may make conflicting decisions. If it takes time for all the SFFs to see that the SPI/SI value's denotation has changed, then there is an NSH-specific convergence issue. This can be avoided if the SFI(s) denoted by a particular SPI/SI value do not change while a packet is in flight. If we want to allow the path denoted by a particular SPI value to change (via the addition or deletion of SFIs), but we don't want SFI(s) denoted by a particular SPI/SI to change, then the SIs in a given path cannot be required to be sequential integers. From nobody Tue Nov 22 01:41:29 2016 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 38753129C8D for ; Tue, 22 Nov 2016 01:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 PpXew2bPCpQn for ; Tue, 22 Nov 2016 01:41:22 -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 C52B8129C74 for ; Tue, 22 Nov 2016 01:41:13 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id CA75A1201B7; Tue, 22 Nov 2016 10:41:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id A5E42180061; Tue, 22 Nov 2016 10:41:11 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Tue, 22 Nov 2016 10:41:11 +0100 From: To: Lucy yong , Dave Dolson , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 Thread-Index: AQHSO1V5dhBvoux3dU2uL7kFD+H1LqDSvAUAgAAWlICAAAOeAIAAAqSAgAACoYD//5cW4IASX7kA Date: Tue, 22 Nov 2016 09:41:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DB75CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8CBEC11C-EF7C-4EEB-8123-8C0CE4B0BF25@cisco.com> <787AE7BB302AE849A7480A190F8B933009DAF5CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009DAF632@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D572EC4DD@dfweml501-mbb> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572EC4DD@dfweml501-mbb> 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_787AE7BB302AE849A7480A190F8B933009DB75CCOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21 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, 22 Nov 2016 09:41:26 -0000 --_000_787AE7BB302AE849A7480A190F8B933009DB75CCOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTHVjeSwNCg0KV29ya3MgZm9yIG1lLiBUaGFua3MuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IEx1Y3kgeW9uZyBbbWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tXQ0KRW52b3nDqSA6IGpldWRp IDEwIG5vdmVtYnJlIDIwMTYgMTg6MDkNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsg RGF2ZSBEb2xzb247IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNCk9iamV0 IDogUkU6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjENCg0K SW4gZmF2b3Igb2YgTWVk4oCZcyB0ZXh0LiAgSG93IGFib3V0IDogTVVTVCBsb2cgYXQgbGVhc3Qg b25jZSBwZXIgdGhlIFNQSSBmb3Igd2hpY2ggYSBtYW5kYXRvcnkgbWV0YWRhdGEgaXMgbWlzc2lu Zy4NCg0KTHVjeQ0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgOToy MSBBTQ0KVG86IERhdmUgRG9sc29uOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gaHR0cHM6Ly90cmFj LmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMQ0KDQpSZS0sDQoNCkkgd291bGQgc2F5OiDigJxN VVNUIGxvZyBhdCBsZWFzdCBvbmNlIHBlciBTRlAgZm9yIHdoaWNoIGEgbWFuZGF0b3J5IG1ldGFk YXRhIGlzIG1pc3NpbmfigJ0uDQoNCkJldHRlcj8NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgRGF2ZSBEb2xzb24N CkVudm95w6kgOiBqZXVkaSAxMCBub3ZlbWJyZSAyMDE2IDE2OjExDQrDgCA6IEJPVUNBREFJUiBN b2hhbWVkIElNVC9PTE47IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL3NmYy90aWNrZXQvMjENCg0KU28geW91IHdvdWxkIHNheSwg4oCcTVVTVCBsb2cgYXQg bGVhc3Qgb25jZSBwZXIgdHlwZSBvZiBtaXNzaW5nIG1hbmRhdG9yeSBtZXRhZGF0YeKAnSA/DQoN Cg0KDQpGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21d DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTYgMTA6MDIgQU0NClRvOiBEYXZlIERv bHNvbjsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KU3ViamVjdDogUkU6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3Nm Yy90aWNrZXQvMjENCg0KSGkgRGF2ZSwNCg0KVGhlIGltcGxlbWVudGF0aW9uIG11c3QgZGVmaW5p dGVseSBsb2cgdGhlIGVycm9yOiB0aGF0IGlzLCB0aGVyZSBpcyBhIG1pc3NpbmcgbWFuZGF0b3J5 IG1ldGFkYXRhIGZvciBhIGNoYWluLiBJdCBkb2VzIG5vdCBuZWVkIHRvIGFkZCBhbiBlbnRyeSBw ZXIgcGFja2V0IGFzIHdhcyByaWdodGZ1bGx5IG1lbnRpb25lZCBieSBSb24uDQoNCkhvdyB0byBw cm90ZWN0IGFuIGltcGxlbWVudGF0aW9uIGZyb20gbWlzY29uZmlndXJhdGlvbiBpcyBub3Qgc3Bl Y2lmaWMgdG8gdGhlIGxvZ2dpbmcgZmVhdHVyZSwgYnV0IGl0IGlzIGEgZ2VuZXRpYyBjb25jZXJu IElNSE8uDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSBEZSBsYSBwYXJ0IGRlIERhdmUgRG9sc29uDQpFbnZvecOpIDogamV1ZGkgMTAgbm92 ZW1icmUgMjAxNiAxNTo0OQ0Kw4AgOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbc2ZjXSBodHRwczovL3RyYWMu aWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxDQoNCkppbSwNCkkgYWdyZWUgd2l0aCB0aGlzIHdv cmRpbmcuDQpUaGlzIGFsbG93cyB0aGUgaW1wbGVtZW50ZXIgdG8gY2hvb3NlIGFuIGFwcHJvYWNo IHRoYXQgZG9lcyBub3Qgb3ZlcndoZWxtIHRoZSBkZXZpY2Ugd2hlbiB0aGUgc3lzdGVtIGlzIGNv bmZpZ3VyZWQgaW1wcm9wZXJseS4NCg0KSWYgaXQgd2VyZSDigJxNVVNU4oCdLCBJIHdvdWxkIGV4 cGVjdCBtb3JlIGRldGFpbHMgYWJvdXQgd2hhdCBleGFjdGx5IHNob3VsZCBiZSBsb2dnZWQuIE90 aGVyd2lzZSwgaG93IGNvdWxkIG9uZSB0ZXN0IGNvbXBsaWFuY2U/DQoNCi1EYXZlDQoNCg0KRnJv bTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDE2IDg6Mjgg QU0NClRvOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb c2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxDQoNCkRlYXIgU0ZD IFdHOg0KDQpBcG9sb2dpZXMsIGl0IHdhcyBwb2ludGVkIG91dCB0byBtZSB0aGF0IEkgbWlzc2Vk IGFkZGluZyB0aGUgdGV4dCBhdCBhIHRoaXJkIGxvY2F0aW9uLiBDb3JyZWN0IHRleHQgYXMgZm9s bG93czoNCg0KTkVXIGZvciBzZWN0aW9uIDMuNDoNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5v dCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0aGUgbWFu ZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5vdCBkZXNj cmliZSB0aGUgc3RydWN0dXJlIG9yIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIG1ldGFkYXRhLg0K DQpBbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNlbWFudGljcyBmaXJzdCBp biBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRl eHQgZmllbGQuICBUaGUgZGF0YSBzZW1hbnRpY3MgaW5jbHVkZSBib3RoIHRoZSBhbGxvY2F0aW9u IHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMt YXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRpY3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpVcG9uIHJlY2VpdmluZyBhbiBOU0ggTUQtdHlwZSAxIHBh Y2tldCwgaWYgdGhlIFNGQy1hd2FyZSBTRiBpcyBjb25maWd1cmVkIGZvciBtYW5kYXRvcnkgdXNl IG9mIG1ldGFkYXRhIGJ1dCBoYXMgbm90IHlldCByZWNlaXZlZCB0aGUgZGF0YSBzZW1hbnRpY3Mg Zm9yIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0aGUg cGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGlt aXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHByb3Zp ZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0YSBj b252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuDQoNCk5FVyBmb3IgZW5kIG9m IHNlY3Rpb24gMy41LjE6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNz dW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhv c2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3MuICBUaGVzZSBjb25zaWRlcmF0aW9ucyBh cmUgZGVwbG95bWVudC1zcGVjaWZpYy4gIEhvd2V2ZXIsIHRoZSBjb250cm9sIHBsYW5lIGNhbiBp bnN0cnVjdCBTRkMtYXdhcmUgU0ZzIHdpdGggdGhlIGRhdGEgc3RydWN0dXJlIG9mIFRMVnMgdG9n ZXRoZXIgd2l0aCB0aGVpciBzY29waW5nIChTZWUgU2VjdGlvbiAzLjMuMyBvZiBbSS1ELmlldGYt c2ZjLWNvbnRyb2wtcGxhbmVdKS4NCg0KVXBvbiByZWNlaXB0IG9mIGEgcGFja2V0IHRoYXQgYmVs b25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMViBpcyBtaXNz aW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MgdGhl IHBhY2tldCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxp bWl0aW5nIHRvIGFueSBsb2dnaW5nLg0KDQpJZiBtdWx0aXBsZSBtYW5kYXRvcnktdG8tcHJvY2Vz cyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBjb250cm9sIHBsYW5lIE1B WSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVyIHRvIGNvbnN1bWUgdGhl c2UgVExWcy4gIElmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUg U0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVyIHRoZXlhcHBlYXIgaW4gdGhl IE5TSCBwYWNrZXQuDQoNCklmIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJl IGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IFRM ViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2Vz cyB0aGUgcGFja2V0LCBpdCBTSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJh dGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmcuDQoNCkZyb206IHNmYyA8c2ZjLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEppbSBHdWlj aGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KRGF0 ZTogVGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDE2IGF0IDg6MjIgQU0NClRvOiAic2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFtzZmNdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90 aWNrZXQvMjENCg0KRGVhciBTRkMgV0c6DQoNCkdpdmVuIHRoZSByZWNlbnQgZGlzY3Vzc2lvbiBv biB0aGUgbWFpbGluZyBsaXN0LCB1cGRhdGVkIHRleHQgKHdpdGggY2hhbmdlcyBpbiBSRUQpIGFz IGZvbGxvd3M6DQoNCk5FVyBmb3Igc2VjdGlvbiAzLjQ6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9l cyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhl IG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3Qg ZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0 YS4NCg0KQW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmly c3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBj b250ZXh0IGZpZWxkLiAgVGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2Nh dGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4g U0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KVXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUg MSBwYWNrZXQsIGlmIHRoZSBTRkMtYXdhcmUgU0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5 IHVzZSBvZiBtZXRhZGF0YSBidXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50 aWNzIGZvciB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3Mg dGhlIHBhY2tldCwgaXQgU0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRl IGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nLg0KDQpbZGNhbGxvY10gYW5kIFticm9hZGFsbG9jXSBw cm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5nIHdpdGggdGhlIGRh dGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLg0KDQpORVcgZm9yIGVu ZCBvZiBzZWN0aW9uIDMuNS4xOg0KVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55 IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9y IHRob3NlIHRoYXQgYXJlIG1hbmRhdG9yeS10by1wcm9jZXNzLiAgVGhlc2UgY29uc2lkZXJhdGlv bnMgYXJlIGRlcGxveW1lbnQtc3BlY2lmaWMuICBIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBj YW4gaW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZz IHRvZ2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5p ZXRmLXNmYy1jb250cm9sLXBsYW5lXSkuDQoNClVwb24gcmVjZWlwdCBvZiBhIHBhY2tldCB0aGF0 IGJlbG9uZyB0byBhIGdpdmVuIFNGUCwgaWYgYSBtYW5kYXRvcnktdG8tcHJvY2VzcyBUTFYgaXMg bWlzc2luZyBpbiB0aGF0IHBhY2tldCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNz IHRoZSBwYWNrZXQgYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuDQoNCklmIG11bHRpcGxlIG1hbmRh dG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJlcXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNv bnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRoZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIg dG8gY29uc3VtZSB0aGVzZSBUTFZzLiAgSWYgbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwg dGhlIFNGQy1hd2FyZSBTRiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhl eWFwcGVhciBpbiB0aGUgTlNIIHBhY2tldC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRo ZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQgaW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0 aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBN VVNUIE5PVCBwcm9jZXNzIHRoZSBwYWNrZXQsIGl0IFNIT1VMRCBsb2cgdGhpcyBlcnJvciwgYW5k IE1VU1QgYXBwbHkgcmF0ZSBsaW1pdGluZyB0byBhbnkgbG9nZ2luZy4NCg0KRnJvbTogc2ZjIDxz ZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhh bGYgb2YgSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBOb3ZlbWJlciA4LCAyMDE2IGF0IDE6MDEgUE0NClRv OiAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NmY10gaHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvc2ZjL3RpY2tldC8yMQ0KDQpEZWFyIFNGQyBXRzoNCg0KQWZ0ZXIgbXVjaCBkaXNjdXNzaW9u IG9uIHRoZSBsaXN0IHdpdGggcmVnYXJkIHRvIHRpY2tldCAjMjEgdGhlIGZvbGxvd2luZyB0ZXh0 IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGhlbHAgY2xhcmlmeSBtZXRhZGF0YSBzZW1hbnRpY3MgYW5k IHNvIGZvcnRoLiBQbGVhc2UgcmV2aWV3IGFuZCBpbmRpY2F0ZSBzdXBwb3J0IChvciBub3QpIHNv IHRoYXQgdGhlIGNoYWlycyBjYW4gZGV0ZXJtaW5lIGNvbnNlbnN1cyBhbmQgdXBkYXRlIHRoZSB0 aWNrZXQgYWNjb3JkaW5nbHkuDQoNClRoYW5rIHlvdSENCg0KSmltICYgSm9lbA0KDQojIyMjIyMj IyMjDQoNCk5FVyBmb3Igc2VjdGlvbiAzLjQ6DQpUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg bWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY29udGVudCBwbGFjZWQgaW4gdGhlIG1hbmRh dG9yeSBjb250ZXh0IGZpZWxkIG9mIHRoZSBOU0ggaGVhZGVyLCBhbmQgZG9lcyBub3QgZGVzY3Jp YmUgdGhlIHN0cnVjdHVyZSBvciBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4NCg0K QW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUgZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4g b3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0 IGZpZWxkLiAgVGhlIGRhdGEgc2VtYW50aWNzIGluY2x1ZGUgYm90aCB0aGUgYWxsb2NhdGlvbiBz Y2hlbWEgYW5kIHRoZSBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3 YXJlIFNGIGdldHMgdGhlIGRhdGEgc2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMgc3BlY2lmaWNhdGlvbi4NCg0KVXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNr ZXQsIGlmIHRoZSBTRkMtYXdhcmUgU0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBv ZiBtZXRhZGF0YSBidXQgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIGZv ciB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBh Y2tldCBhbmQgTVVTVCBsb2cgdGhpcyBlcnJvci4NCg0KW2RjYWxsb2NdIGFuZCBbYnJvYWRhbGxv Y10gcHJvdmlkZSBzYW1wbGUgZXhhbXBsZXMgdG8gYXNzb2NpYXRlIGEgbWVhbmluZyB3aXRoIHRo ZSBkYXRhIGNvbnZleWVkIGluIHRoZSBtYW5kYXRvcnkgY29udGV4dCBmaWVsZC4NCg0KTkVXIGZv ciBlbmQgb2Ygc2VjdGlvbiAzLjUuMToNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYWtl IGFueSBhc3N1bXB0aW9uIGFib3V0IFRMVnMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWltcGxlbWVu dCBvciB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnktdG8tcHJvY2Vzcy4gIFRoZXNlIGNvbnNpZGVy YXRpb25zIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljLiAgSG93ZXZlciwgdGhlIGNvbnRyb2wgcGxh bmUgY2FuIGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2Yg VExWcyB0b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJ LUQuaWV0Zi1zZmMtY29udHJvbC1wbGFuZV0pLg0KDQpVcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQg dGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExW IGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJv Y2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0KDQpJZiBtdWx0aXBsZSBt YW5kYXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRo ZSBjb250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9y ZGVyIHRvIGNvbnN1bWUgdGhlc2UgVExWcy4gIElmIG5vIGluc3RydWN0aW9ucyBhcmUgcHJvdmlk ZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4gdGhlIG9yZGVy IHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuDQoNCklmIG11bHRpcGxlIGluc3RhbmNlcyBv ZiB0aGUgc2FtZSBUTFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0aGUgZGVm aW5pdGlvbiBvZiB0aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMtYXdhcmUg U0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0IGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLg0K --_000_787AE7BB302AE849A7480A190F8B933009DB75CCOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0 ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBi dWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRl eHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAu QmFsbG9vblRleHQsIGxpLkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxs b29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHls ZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFu LkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiM5OTMzNjY7DQoJZm9udC1zdHlsZTppdGFs aWM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdo dDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+SGkgTHVjeSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldvcmtzIGZvciBt ZS4gVGhhbmtzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1l ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTHVjeSB5b25nIFttYWlsdG86bHVjeS55b25n QGh1YXdlaS5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMTAgbm92ZW1i cmUgMjAxNiAxODowOTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1U L09MTjsgRGF2ZSBEb2xzb247IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmc8 YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJFOiBbc2ZjXSBodHRwczovL3RyYWMuaWV0Zi5vcmcv dHJhYy9zZmMvdGlja2V0LzIxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojOTkzMzY2Ij5JbiBmYXZvciBvZiBNZWTigJlzIHRleHQuICZuYnNwO0hvdyBhYm91dCA6DQo8 L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TVVTVCBsb2cgYXQg bGVhc3Qgb25jZSBwZXINCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj50 aGUgU1BJPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+IGZvciB3aGlj aCBhIG1hbmRhdG9yeSBtZXRhZGF0YSBpcyBtaXNzaW5nLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkx1Y3k8L3NwYW4+PGk+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2Ij48bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2k+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDE2IDk6MjEg QU08YnI+DQo8Yj5Ubzo8L2I+IERhdmUgRG9sc29uOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NmY10gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv c2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMTwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UmUt LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHdv dWxkIHNheTog4oCcTVVTVCBsb2cgYXQgbGVhc3Qgb25jZSBwZXIgU0ZQIGZvciB3aGljaCBhIG1h bmRhdG9yeSBtZXRhZGF0YSBpcyBtaXNzaW5n4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5CZXR0ZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si Pk1lZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5E ZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFs8YSBo cmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBEYXZlIERvbHNvbjxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPiBqZXVkaSAxMCBub3ZlbWJyZSAyMDE2IDE2OjExPGJyPg0KPGI+w4AmbmJz cDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKaW0gR3VpY2hhcmQgKGpndWljaGFy KTsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3NmY10gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYu b3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3Rp Y2tldC8yMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNvIHlvdSB3b3VsZCBzYXksIOKAnE1VU1QgbG9nIGF0IGxlYXN0IG9uY2UgcGVyIHR5cGUgb2Yg bWlzc2luZyBtYW5kYXRvcnkgbWV0YWRhdGHigJ0gPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+IFs8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAx MCwgMjAxNiAxMDowMiBBTTxicj4NCjxiPlRvOjwvYj4gRGF2ZSBEb2xzb247IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc2ZjXSA8YSBocmVmPSJodHRwczovL3RyYWMu aWV0Zi5vcmcvdHJhYy9zZmMvdGlja2V0LzIxIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9z ZmMvdGlja2V0LzIxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhp IERhdmUsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgaW1wbGVt ZW50YXRpb24gbXVzdCBkZWZpbml0ZWx5IGxvZyB0aGUgZXJyb3I6IHRoYXQgaXMsIHRoZXJlIGlz IGEgbWlzc2luZyBtYW5kYXRvcnkgbWV0YWRhdGEgZm9yIGEgY2hhaW4uIEl0IGRvZXMgbm90IG5l ZWQgdG8gYWRkIGFuIGVudHJ5IHBlciBwYWNrZXQNCiBhcyB3YXMgcmlnaHRmdWxseSBtZW50aW9u ZWQgYnkgUm9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+SG93IHRvIHByb3RlY3QgYW4gaW1wbGVtZW50YXRpb24gZnJvbSBtaXNjb25maWd1cmF0 aW9uIGlzIG5vdCBzcGVjaWZpYyB0byB0aGUgbG9nZ2luZyBmZWF0dXJlLCBidXQgaXQgaXMgYSBn ZW5ldGljIGNvbmNlcm4gSU1ITy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5E ZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgPC9iPjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+cGFydCBkZTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBEYXZlIERvbHNvbjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSAxMCBu b3ZlbWJyZSAyMDE2IDE1OjQ5PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKTsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxi cj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtzZmNdIDxhIGhyZWY9Imh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjEiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3Nm Yy90aWNrZXQvMjE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5KaW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFn cmVlIHdpdGggdGhpcyB3b3JkaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhpcyBhbGxvd3MgdGhlIGltcGxlbWVudGVyIHRvIGNob29zZSBhbiBhcHByb2Fj aCB0aGF0IGRvZXMgbm90IG92ZXJ3aGVsbSB0aGUgZGV2aWNlIHdoZW4gdGhlIHN5c3RlbSBpcyBj b25maWd1cmVkIGltcHJvcGVybHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SWYgaXQgd2VyZSDigJxNVVNU4oCdLCBJIHdvdWxkIGV4cGVjdCBtb3JlIGRldGFpbHMgYWJv dXQgd2hhdCBleGFjdGx5IHNob3VsZCBiZSBsb2dnZWQuIE90aGVyd2lzZSwgaG93IGNvdWxkIG9u ZSB0ZXN0IGNvbXBsaWFuY2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1E YXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBz ZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmltIEd1aWNoYXJkIChqZ3Vp Y2hhcik8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDE2IDg6Mjgg QU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIDxhIGhyZWY9Imh0dHBzOi8v dHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjEiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90 cmFjL3NmYy90aWNrZXQvMjE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgU0ZD IFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkFwb2xvZ2llcywgaXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQgSSBtaXNz ZWQgYWRkaW5nIHRoZSB0ZXh0IGF0IGEgdGhpcmQgbG9jYXRpb24uIENvcnJlY3QgdGV4dCBhcyBm b2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+TkVX IGZvciBzZWN0aW9uIDMuNDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90 IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIGNvbnRlbnQgcGxhY2VkIGluIHRoZSBtYW5k YXRvcnkgY29udGV4dCBmaWVsZCBvZiB0aGUgTlNIIGhlYWRlciwgYW5kIGRvZXMgbm90IGRlc2Ny aWJlIHRoZSBzdHJ1Y3R1cmUNCiBvciBtZWFuaW5nIG9mIHRoZSBpbmNsdWRlZCBtZXRhZGF0YS4g Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj5BbiBTRkMtYXdhcmUgU0YgTVVTVCByZWNlaXZlIHRoZSBkYXRhIHNl bWFudGljcyBmaXJzdCBpbiBvcmRlciB0byBwcm9jZXNzIHRoZSBkYXRhIHBsYWNlZCBpbiB0aGUg bWFuZGF0b3J5IGNvbnRleHQgZmllbGQuJm5ic3A7Jm5ic3A7VGhlIGRhdGEgc2VtYW50aWNzIGlu Y2x1ZGUgYm90aA0KIHRoZSBhbGxvY2F0aW9uIHNjaGVtYSBhbmQgdGhlIG1lYW5pbmcgb2YgdGhl IGluY2x1ZGVkIGRhdGEuIEhvdyBhbiBTRkMtYXdhcmUgU0YgZ2V0cyB0aGUgZGF0YSBzZW1hbnRp Y3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0 YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+ VXBvbiByZWNlaXZpbmcgYW4gTlNIIE1ELXR5cGUgMSBwYWNrZXQsIGlmIHRoZSBTRkMtYXdhcmUg U0YgaXMgY29uZmlndXJlZCBmb3IgbWFuZGF0b3J5IHVzZSBvZiBtZXRhZGF0YSBidXQgaGFzIG5v dCB5ZXQgcmVjZWl2ZWQgdGhlIGRhdGEgc2VtYW50aWNzIGZvcg0KIHRoZSBtYW5kYXRvcnkgY29u dGV4dCBmaWVsZCwgaXQgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFja2V0PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0 YW5kYXJkO2NvbG9yOnJlZCI+LCBpdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOnJlZCI+U0hPVUxEDQogbG9nIHRoaXMg ZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmc8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13 ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPltkY2FsbG9jXSBhbmQgW2Jy b2FkYWxsb2NdIHByb3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcg d2l0aCB0aGUgZGF0YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13 ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2Nv bG9yOmJsYWNrIj5ORVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xPC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1z dGFuZGFyZDtjb2xvcjpibGFjayI+OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5UaGlz IHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRo YXQgYXJlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5 LXRvLXByb2Nlc3MuJm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMNCiBhcmUgZGVwbG95 bWVudC1zcGVjaWZpYy4mbmJzcDsmbmJzcDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4g aW5zdHJ1Y3QgU0ZDLWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRv Z2V0aGVyIHdpdGggdGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRm LXNmYy1jb250cm9sLXBsYW5lXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5VcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQg dGhhdCBiZWxvbmcgdG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExW IGlzIG1pc3NpbmcgaW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJv Y2VzcyB0aGUgcGFja2V0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOnJlZCI+LA0KIGl0PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRh cmQ7Y29sb3I6cmVkIj5TSE9VTEQgbG9nIHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUg bGltaXRpbmcgdG8gYW55IGxvZ2dpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2si Pi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7 Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIFRMVnMgYXJlIHJl cXVpcmVkIGZvciBhIGdpdmVuIFNGUCwgdGhlIGNvbnRyb2wgcGxhbmUgTUFZIGluc3RydWN0IHRo ZSBTRkMtYXdhcmUgU0Ygd2l0aCB0aGUgb3JkZXIgdG8gY29uc3VtZSB0aGVzZSBUTFZzLiZuYnNw OyZuYnNwO0lmDQogbm8gaW5zdHJ1Y3Rpb25zIGFyZSBwcm92aWRlZCwgdGhlIFNGQy1hd2FyZSBT RiBNVVNUIHByb2Nlc3MgdGhlc2UgVExWcyBpbiB0aGUgb3JkZXIgdGhleWFwcGVhciBpbiB0aGUg TlNIIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7Y29sb3I6YmxhY2siPklmIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBU TFYgYXJlIGluY2x1ZGVkIGluIGFuIE5TSCBwYWNrZXQsIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0 aGF0IFRMViBkb2VzIG5vdCBhbGxvdyBmb3IgaXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1Qg cHJvY2Vzcw0KIHRoZSBwYWNrZXQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6cmVkIj4sIGl0 Jm5ic3A7U0hPVUxEIGxvZyB0aGlzIGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5n IHRvIGFueSBsb2dnaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5zZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgSmltIEd1 aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBj aXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMTAs IDIwMTYgYXQgODoyMiBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtzZmNdIDxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjEi Pmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NmYy90aWNrZXQvMjE8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+RGVhciBTRkMgV0c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R2l2ZW4gdGhlIHJlY2VudCBkaXNjdXNz aW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHVwZGF0ZWQgdGV4dCAod2l0aCBjaGFuZ2VzIGluIFJF RCkgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJs YWNrIj46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPlRoaXMgc3BlY2lmaWNhdGlvbiBk b2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0 aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5v dCBkZXNjcmliZSB0aGUgc3RydWN0dXJlDQogb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0 YWRhdGEuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtp dC1zdGFuZGFyZDtjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUg ZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQg aW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNlbWFu dGljcyBpbmNsdWRlIGJvdGgNCiB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5n IG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEg c2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdl YmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6 YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZD LWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0 IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3INCiB0aGUgbWFuZGF0 b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdl YmtpdC1zdGFuZGFyZDtjb2xvcjpyZWQiPiwgaXQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6 YmxhY2siPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOnJlZCI+U0hPVUxEIGxvZyB0aGlz IGVycm9yLCBhbmQgTVVTVCBhcHBseSByYXRlIGxpbWl0aW5nIHRvIGFueSBsb2dnaW5nPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5bZGNhbGxvY10gYW5kIFti cm9hZGFsbG9jXSBwcm92aWRlIHNhbXBsZSBleGFtcGxlcyB0byBhc3NvY2lhdGUgYSBtZWFuaW5n IHdpdGggdGhlIGRhdGEgY29udmV5ZWQgaW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTot d2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjayI+TkVXIGZvciBlbmQgb2Ygc2VjdGlvbiAzLjUuMTwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+VGhp cyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgVExWcyB0 aGF0IGFyZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IG9yIHRob3NlIHRoYXQgYXJlIG1hbmRhdG9y eS10by1wcm9jZXNzLiZuYnNwOyZuYnNwO1RoZXNlIGNvbnNpZGVyYXRpb25zDQogYXJlIGRlcGxv eW1lbnQtc3BlY2lmaWMuJm5ic3A7Jm5ic3A7SG93ZXZlciwgdGhlIGNvbnRyb2wgcGxhbmUgY2Fu IGluc3RydWN0IFNGQy1hd2FyZSBTRnMgd2l0aCB0aGUgZGF0YSBzdHJ1Y3R1cmUgb2YgVExWcyB0 b2dldGhlciB3aXRoIHRoZWlyIHNjb3BpbmcgKFNlZSBTZWN0aW9uIDMuMy4zIG9mIFtJLUQuaWV0 Zi1zZmMtY29udHJvbC1wbGFuZV0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+VXBvbiByZWNlaXB0IG9mIGEgcGFja2V0 IHRoYXQgYmVsb25nIHRvIGEgZ2l2ZW4gU0ZQLCBpZiBhIG1hbmRhdG9yeS10by1wcm9jZXNzIFRM ViBpcyBtaXNzaW5nIGluIHRoYXQgcGFja2V0LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHBy b2Nlc3MgdGhlIHBhY2tldA0KIGFuZCBNVVNUIGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5k YXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+SWYg bXVsdGlwbGUgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWcyBhcmUgcmVxdWlyZWQgZm9yIGEgZ2l2 ZW4gU0ZQLCB0aGUgY29udHJvbCBwbGFuZSBNQVkgaW5zdHJ1Y3QgdGhlIFNGQy1hd2FyZSBTRiB3 aXRoIHRoZSBvcmRlciB0byBjb25zdW1lIHRoZXNlIFRMVnMuJm5ic3A7Jm5ic3A7SWYNCiBubyBp bnN0cnVjdGlvbnMgYXJlIHByb3ZpZGVkLCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgcHJvY2VzcyB0 aGVzZSBUTFZzIGluIHRoZSBvcmRlciB0aGV5YXBwZWFyIGluIHRoZSBOU0ggcGFja2V0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Vi a2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpi bGFjayI+SWYgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFRMViBhcmUgaW5jbHVkZWQg aW4gYW4gTlNIIHBhY2tldCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgVExWIGRvZXMgbm90 IGFsbG93IGZvciBpdCwgdGhlIFNGQy1hd2FyZSBTRiBNVVNUIE5PVCBwcm9jZXNzDQogdGhlIHBh Y2tldDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpyZWQiPiwgaXQmbmJzcDtTSE9VTEQgbG9n IHRoaXMgZXJyb3IsIGFuZCBNVVNUIGFwcGx5IHJhdGUgbGltaXRpbmcgdG8gYW55IGxvZ2dpbmc8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPnNmYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91 bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgJmx0OzxhIGhy ZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE5vdmVtYmVyIDgsIDIwMTYgYXQgMTowMSBQTTxi cj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W3NmY10gPGEgaHJlZj0iaHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvc2ZjL3RpY2tldC8yMSI+aHR0cHM6Ly90cmFjLmlldGYub3Jn L3RyYWMvc2ZjL3RpY2tldC8yMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtp dC1zdGFuZGFyZDtjb2xvcjpibGFjayI+RGVhciBTRkMgV0c6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5BZnRlciBtdWNo IGRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2l0aCByZWdhcmQgdG8gdGlja2V0ICMyMSB0aGUgZm9s bG93aW5nIHRleHQgaGFzIGJlZW4gcHJvcG9zZWQgdG8gaGVscCBjbGFyaWZ5IG1ldGFkYXRhIHNl bWFudGljcyBhbmQgc28gZm9ydGguIFBsZWFzZQ0KIHJldmlldyBhbmQgaW5kaWNhdGUgc3VwcG9y dCAob3Igbm90KSBzbyB0aGF0IHRoZSBjaGFpcnMgY2FuIGRldGVybWluZSBjb25zZW5zdXMgYW5k IHVwZGF0ZSB0aGUgdGlja2V0IGFjY29yZGluZ2x5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+VGhhbmsgeW91 ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjayI+SmltICZhbXA7IEpvZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPiMjIyMjIyMjIyM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1z dGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPk5FVyBmb3Igc2VjdGlvbiAzLjQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJs YWNrIj46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPlRoaXMgc3BlY2lmaWNhdGlvbiBk b2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSBjb250ZW50IHBsYWNlZCBpbiB0 aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQgb2YgdGhlIE5TSCBoZWFkZXIsIGFuZCBkb2VzIG5v dCBkZXNjcmliZSB0aGUgc3RydWN0dXJlDQogb3IgbWVhbmluZyBvZiB0aGUgaW5jbHVkZWQgbWV0 YWRhdGEuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtp dC1zdGFuZGFyZDtjb2xvcjpibGFjayI+QW4gU0ZDLWF3YXJlIFNGIE1VU1QgcmVjZWl2ZSB0aGUg ZGF0YSBzZW1hbnRpY3MgZmlyc3QgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgZGF0YSBwbGFjZWQg aW4gdGhlIG1hbmRhdG9yeSBjb250ZXh0IGZpZWxkLiZuYnNwOyZuYnNwO1RoZSBkYXRhIHNlbWFu dGljcyBpbmNsdWRlIGJvdGgNCiB0aGUgYWxsb2NhdGlvbiBzY2hlbWEgYW5kIHRoZSBtZWFuaW5n IG9mIHRoZSBpbmNsdWRlZCBkYXRhLiBIb3cgYW4gU0ZDLWF3YXJlIFNGIGdldHMgdGhlIGRhdGEg c2VtYW50aWNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdl YmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6 YmxhY2siPlVwb24gcmVjZWl2aW5nIGFuIE5TSCBNRC10eXBlIDEgcGFja2V0LCBpZiB0aGUgU0ZD LWF3YXJlIFNGIGlzIGNvbmZpZ3VyZWQgZm9yIG1hbmRhdG9yeSB1c2Ugb2YgbWV0YWRhdGEgYnV0 IGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZSBkYXRhIHNlbWFudGljcyBmb3INCiB0aGUgbWFuZGF0 b3J5IGNvbnRleHQgZmllbGQsIGl0IE1VU1QgTk9UIHByb2Nlc3MgdGhlIHBhY2tldCBhbmQgTVVT VCBsb2cgdGhpcyBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13 ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPltkY2FsbG9jXSBhbmQgW2Jyb2FkYWxsb2NdIHBy b3ZpZGUgc2FtcGxlIGV4YW1wbGVzIHRvIGFzc29jaWF0ZSBhIG1lYW5pbmcgd2l0aCB0aGUgZGF0 YSBjb252ZXllZCBpbiB0aGUgbWFuZGF0b3J5IGNvbnRleHQgZmllbGQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRh cmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5O RVcgZm9yIGVuZCBvZiBzZWN0aW9uIDMuNS4xPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xv cjpibGFjayI+OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRp b24gZG9lcyBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCBUTFZzIHRoYXQgYXJlIG1hbmRh dG9yeS10by1pbXBsZW1lbnQgb3IgdGhvc2UgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLXByb2Nlc3Mu Jm5ic3A7Jm5ic3A7VGhlc2UgY29uc2lkZXJhdGlvbnMNCiBhcmUgZGVwbG95bWVudC1zcGVjaWZp Yy4mbmJzcDsmbmJzcDtIb3dldmVyLCB0aGUgY29udHJvbCBwbGFuZSBjYW4gaW5zdHJ1Y3QgU0ZD LWF3YXJlIFNGcyB3aXRoIHRoZSBkYXRhIHN0cnVjdHVyZSBvZiBUTFZzIHRvZ2V0aGVyIHdpdGgg dGhlaXIgc2NvcGluZyAoU2VlIFNlY3Rpb24gMy4zLjMgb2YgW0ktRC5pZXRmLXNmYy1jb250cm9s LXBsYW5lXSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0 YW5kYXJkO2NvbG9yOmJsYWNrIj5VcG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmcg dG8gYSBnaXZlbiBTRlAsIGlmIGEgbWFuZGF0b3J5LXRvLXByb2Nlc3MgVExWIGlzIG1pc3Npbmcg aW4gdGhhdCBwYWNrZXQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBOT1QgcHJvY2VzcyB0aGUgcGFj a2V0DQogYW5kIE1VU1QgbG9nIHRoaXMgZXJyb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5JZiBtdWx0aXBsZSBtYW5k YXRvcnktdG8tcHJvY2VzcyBUTFZzIGFyZSByZXF1aXJlZCBmb3IgYSBnaXZlbiBTRlAsIHRoZSBj b250cm9sIHBsYW5lIE1BWSBpbnN0cnVjdCB0aGUgU0ZDLWF3YXJlIFNGIHdpdGggdGhlIG9yZGVy IHRvIGNvbnN1bWUgdGhlc2UgVExWcy4mbmJzcDsmbmJzcDtJZg0KIG5vIGluc3RydWN0aW9ucyBh cmUgcHJvdmlkZWQsIHRoZSBTRkMtYXdhcmUgU0YgTVVTVCBwcm9jZXNzIHRoZXNlIFRMVnMgaW4g dGhlIG9yZGVyIHRoZXlhcHBlYXIgaW4gdGhlIE5TSCBwYWNrZXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJsYWNrIj5JZiBtdWx0 aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgVExWIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggcGFj a2V0LCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBUTFYgZG9lcyBub3QgYWxsb3cgZm9yIGl0 LCB0aGUgU0ZDLWF3YXJlIFNGIE1VU1QgTk9UIHByb2Nlc3MNCiB0aGUgcGFja2V0IGFuZCBNVVNU IGxvZyB0aGlzIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933009DB75CCOPEXCLILMA3corp_-- From nobody Tue Nov 22 12:38:09 2016 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 9AA5C129795 for ; Tue, 22 Nov 2016 12:37:57 -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 zEwmwgxWkNE9 for ; Tue, 22 Nov 2016 12:37:56 -0800 (PST) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (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 E782D1296FA for ; Tue, 22 Nov 2016 12:37:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id D0BA636F616 for ; Tue, 22 Nov 2016 12:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479847072; bh=LDOP/fGSYqbx78lZ90J8Fc2EhrwqfK9Iq7RVuC4Ela8=; h=Subject:References:To:From:Date:In-Reply-To:From; b=ZAAEBUC1MSVBiQaEJuhD4cHEk17tZP7WekJCOEburFuQh6slvHjldzifpAQ9r4mel oiP/rS96tz0C40Rg94eVVbQfGhSFjuwlTIjleCeXA8jSB3JrskdozFMpMsPDAXFBiw E/Fpysonk6U5o31QZ2ShCUihrK/1Phlu9S0UchFU= X-Virus-Scanned: Debian amavisd-new at maila1.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 maila1.tigertech.net (Postfix) with ESMTPSA id 77AF836F62F for ; Tue, 22 Nov 2016 12:37:52 -0800 (PST) References: <147983988739.30322.12665666314505231970.idtracker@ietfa.amsl.com> To: "sfc@ietf.org" From: Joel Halpern X-Forwarded-Message-Id: <147983988739.30322.12665666314505231970.idtracker@ietfa.amsl.com> Message-ID: <00756d26-1e72-7b2d-4d8b-230a5bbda621@joelhalpern.com> Date: Tue, 22 Nov 2016 15:38:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147983988739.30322.12665666314505231970.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Fwd: NomCom 2016-2017: LastCall for Feedback 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, 22 Nov 2016 20:37:57 -0000 Please, do give them your comments. Yours, Joel -------- Forwarded Message -------- Subject: NomCom 2016-2017: LastCall for Feedback Date: Tue, 22 Nov 2016 10:38:07 -0800 From: NomCom Chair 2016 Reply-To: ietf@ietf.org To: IETF Announcement List CC: ietf@ietf.org Just a reminder that feedback for the current Nominees for IETF and IAB leadership is due by 23:59 UTC on Thursday, November 24, 2016. You can view the list of nominees and enter feedback via the datatracker: https://datatracker.ietf.org/nomcom/2016/feedback/ or you can provide your input by sending email to: nomcom-2016 @ ietf.org You can also send general feedback about Areas, the IESG, The IAB, and the IAOC to the same email address. The NomCom is particularly interested in your feedback on the IAOC and the current nominees given the discussion of IASA 2.0 as outlined in plenary at IETF 97. We would also like to encourage feedback on all of the nominees. Please take a few moments to comment on the full range of nominees in areas where you are active. We have good responses for some but not all of our pool and would appreciate additional input. Lucy Lynch NomCom Chair 2016-2017 llynch @ civil-tongue.net From nobody Wed Nov 23 04:49:27 2016 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 73BAB129D4A for ; Wed, 23 Nov 2016 04:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 AKefSkja54Eb for ; Wed, 23 Nov 2016 04:49:23 -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 30CDE129D6E for ; Wed, 23 Nov 2016 04:49:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBG08332; Wed, 23 Nov 2016 12:49:18 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Nov 2016 12:47:53 +0000 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Wed, 23 Nov 2016 18:17:41 +0530 From: Phaneendra manda To: "sfc@ietf.org" Thread-Topic: [sfc] Review comments for draft-agv-sfc-packet-loss-measurement-01 Thread-Index: AdJFh8dU9j7De4XRQn2cOmj7omWbvA== Date: Wed, 23 Nov 2016 12:47:41 +0000 Message-ID: <6A6AEA8F97B29F4585E1A9F4BE8838747E3A9B30@blreml501-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.148.192] Content-Type: multipart/alternative; boundary="_000_6A6AEA8F97B29F4585E1A9F4BE8838747E3A9B30blreml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58359051.0099, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6130d9d31534d5a076a79d77d143c09b Archived-At: Cc: Aruna kumar padhi Subject: [sfc] Review comments for draft-agv-sfc-packet-loss-measurement-01 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, 23 Nov 2016 12:49:26 -0000 --_000_6A6AEA8F97B29F4585E1A9F4BE8838747E3A9B30blreml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, Please find the below review comments for draft-agv-sfc-packet-loss-measure= ment-01 1. In Section 1.3 This document defines the implementation mechanism for the packet loss measurement as per performance measurement architecture [SFC-PM- arch]. This document defines a new NSH message format for carrying packet loss measurement related control information. It also defines operations to be carried out for packet loss measurement. communication mechanism between measurement controller, measurement collector and MA is out of scope of this document. Can be This document defines the implementation mechanism for the packet loss measurement as per performance measurement architecture [SFC-PM- arch]. This document defines a new NSH message format for carrying packet loss measurement related control information. It also defines operations to be carried out for packet loss measurement. Communication mechanism between measurement controller, measurement collector and MA is out of scope of this document. 2. In section 2.1 The length is only 5 bits in Performance Measurement Context Header TLV. In= the TLV, it includes the list of MA Identifiers. So the max MA Identifiers= that can be in the list is 31 (4 byte used for Measurement Window Index an= d Reserved). This list can include max of 31 MA Identifiers for both SFF an= d SF. Where there is no limit for SF's can be max of 31 in a Service Functi= on Chain. I think the length field need to be revised. 3. In section 2.2 Reserved: Reserved 16 bits for future purpose. - Is repeated twice. 4. In section 2.3, The method of encoding the PMF id is done using the flow id defined i= n [I-D.ietf-sfc-nsh]. - But I could not find any flow id de= fined in ietf-sfc-nsh draft. 5. In section 3.5 I think it should collect the stats at outgoing port only when packet loss = measurement is initiated. 6. In section 3.7 I think this can include one more scenario, packet loss when a Service func= tion is Down. 7. I think this draft considers only static Service Function Path. I sugges= t this draft can also include the below scenarios - Dynamic SFP as mentioned in RFC 7665 section 5.2 - Bidirectional SFC - Reclassification and branching as mentioned in RFC 7665 section 4.8 Thanks & Regards, Phaneendra Manda. --_000_6A6AEA8F97B29F4585E1A9F4BE8838747E3A9B30blreml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

Please find the bel= ow review comments for draft-agv= -sfc-packet-loss-measurement-01

 

1.      In Section = 1.3

   This=
 document defines the implementation mechanism for the packet

  = ; loss measurement as per performance measurement architecture [SFC-PM-

  = ; arch]. This document defines a new NSH message format for carrying

  = ; packet loss measurement related control information. It also defines=

  = ; operations to be carried out for packet loss measurement.

  = ; communication mechanism between measureme= nt controller, measurement

  = ; collector and MA is out of scope of this document.

 =

  = ; Can be

 = 

   This=
 document defines the implementation mechanism for the packet
   loss=
 measurement as per performance measurement architecture [SFC-PM-
   arch=
]. This document defines a new NSH message format for carrying
   pack=
et loss measurement related control information. It also defines=

   oper=
ations to be carried out for packet loss measurement.

   Communication mechanism between measurement c=
ontroller, measurement


   coll=
ector and MA is out of scope of this document.


 =



 =




2.
In section 2.1



The =
length is only 5 bits in Performance Measurement Context Header TLV. In the=
 TLV, it includes the list of MA Identifiers. So the
 max MA Identifiers that can be in the list is 31 (4 byte used for Measurem=
ent Window Index and Reserved). This list can include max of 31 MA Identifi=
ers for both SFF and SF. Where there is no limit for SF’s can be max =
of 31 in a Service Function Chain. I think
 the length field need to be revised.


 



3.
In section 2.2


 Reserved: Reserved 16 bits for future purpose.   – Is re=
peated twice.


 


4. In section 2.3, 


   =
;   The method of encoding the PMF id is done using the flow=
 id defined in [I-D.ietf-sfc-nsh]. – But I could not find any flow i=
d defined in ietf-sfc-nsh draft.  


 


5. In section 3.5=



I think it should collect the stats at outgoing port only when packet los=
s measurement is initiated.


 


6. In section 3.7=



I think this can include one more scenario, packet loss when a Service fu=
nction is Down.


 


7. I think this draft =
considers only static Service Function Path. I suggest this draft can also =
include the below scenarios


- Dynamic SFP as menti=
oned in RFC 7665 section 5.2


- Bidirectional SFC


- Reclassification and=
 branching as mentioned in RFC 7665 section 4.8


 


 


Thanks =
& Regards,


Phaneen=
dra Manda.


=
 
--_000_6A6AEA8F97B29F4585E1A9F4BE8838747E3A9B30blreml501mbx_-- From phaneendra.manda@huawei.com Tue Nov 22 01:46:00 2016 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 E644D129CAF for ; Tue, 22 Nov 2016 01:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.164, 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=-1.497, 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 R0B5OqqNYliP for ; Tue, 22 Nov 2016 01:45:57 -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 60402129C9F for ; Tue, 22 Nov 2016 01:45:54 -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 DBD11207; Tue, 22 Nov 2016 09:45:51 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Nov 2016 09:44:50 +0000 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Tue, 22 Nov 2016 15:14:38 +0530 From: Phaneendra manda To: "sfc@ietf.org" Thread-Topic: [sfc] Review comments for : Performance Measurement Architecture for SFC Thread-Index: AdJEpQpj92A8+idKSra49KzWKaNe9A== Date: Tue, 22 Nov 2016 09:44:37 +0000 Message-ID: <6A6AEA8F97B29F4585E1A9F4BE8838747E3A8A57@blreml501-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.148.192] Content-Type: multipart/alternative; boundary="_000_6A6AEA8F97B29F4585E1A9F4BE8838747E3A8A57blreml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.583413D0.004D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2b092cab863e623eea061dae098b1015 Archived-At: X-Mailman-Approved-At: Wed, 23 Nov 2016 05:01:35 -0800 Cc: Aruna kumar padhi Subject: [sfc] Review comments for : Performance Measurement Architecture for SFC 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, 23 Nov 2016 07:19:31 -0000 --_000_6A6AEA8F97B29F4585E1A9F4BE8838747E3A8A57blreml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please find the below review comments for draft-agv-sfc-performance-measure= ment-architecture-02 1. In section 2 Measurement Controller: An entity that controls and coordinates a set of measurement functions. The measurement controller is responsible for programming the performance measurement instance at measurement classifier and updating the same to measurement collector, additionally it can inject probe packets in SFP for measurement. can be Measurement Controller: An entity that controls and coordinates a set of measurement functions. The measurement controller is responsible for programming the performance measurement instance(PMI) at measurement classifier and updating the same to measurement collector, additionally it can inject probe packets in SFP for measurement. While going through document there is no abbreviation mapped for PMI. Ma= rking this would improve the readability 2. In section 3 Active measurement : Measurement controller induce probe packets with encoded performance measurement data or programs PMI at measurement classifier which will in turn induce probe packets with encoded performance measurement data. measurement controller updates the PMI to measurement collector. Participating measurement agents based on received encoded information carry out measurements and reports the collected data to measurement collector. measurement collector co-relates received data and provides measurement results. can be Active measurement : Measurement controller induce probe packets with encoded performance measurement data or programs PMI at measurement classifier which will in turn induce probe packets with encoded performance measurement data. Measurement controller updates the PMI to measurement collector. Participating measurement agents based on received encoded information carry out measurements and reports the collected data to measurement collector. measurement collector co-relates received data and provides measurement results. 3. In section 4.1 "PMF identifier" - PMF is used without providing any abbreviation. 4. In section 4.3.3 MA identifier has two parts 1) Node identifier - 24 bit a) For SFF: MUST be unique number assigned by controller b) For SF: All zero. Context identifier itself identifies SF node. I think here it should be Service Index. Context identifier referred now= here in the draft. 5. In section 4.3.3 - At MA : Presence of self service index triggers the PM collection & reporting can be - At MA : Presence of self MA identifier triggers the PM collection & reporting Because of below reasons - A service function does not know its service index - As mentioned in section 5, point 1, it is mentioned Measurement contr= oller programs the MA identifier to MA. So the MA knows the MA identifier n= ot the service index. 6. In section 2 In the description of Measurement Classifier : It can also generate pro= be packet. Need to be updated in description (In section 6 it is mentioned = Measurement classifier may generate probe packet based on the instruction b= y measurement controller. 7. In Section 4.3.3 A service function can be part of multiple service function chains, In t= his case the Measurement Agent will have 2 MA ID's configured. As per the = draft in section 4.3.3, there is no consideration for Service Path Index(SP= I) while MA Identifier construction. So MA Identifier may have conflict. 8. In Section 4.3.3 There is no clarity on Measurement Agent Identifier with PM type value on= how it is encoded. Like few bits are used for MA Identifier and few bits = are used for PM type. It is just mentioned MA Identifier with PM type. I th= ink more details can be provided here. Thanks & Regards Phaneendra Manda. --_000_6A6AEA8F97B29F4585E1A9F4BE8838747E3A8A57blreml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Please find the below review comments for draft-agv-sfc-performance-measurement-archi= tecture-02

1. In section 2

   Measurement Controller: An entity that controls and coordinat= es a set
   of measurement functions. The measurement controller is respon= sible
   for programming the performance m= easurement instance at measurement
   classifier and updating the same to measurement collector,
   additionally it can inject probe packets in SFP for measuremen= t.
 

    can be

  

     Measurement Controller: An entity that contr= ols and coordinates a set
   of measurement functions. The measurement controller is respon= sible
   for programming the performance m= easurement instance(PMI) at measurement
   classifier and updating the same to measurement collector,
   additionally it can inject probe packets in SFP for measuremen= t.

   While going through document there is no abbreviation mapped = for PMI. Marking this would improve the readability

 

 

2. In section 3

   Active measurement : Measurement controller induce probe pack= ets
      with encoded performance measurement data or= programs PMI at
      measurement classifier which will in turn in= duce probe packets
      with encoded performance measurement = data. measurement contr= oller
      updates the PMI to measurement collector. Pa= rticipating
      measurement agents based on received encoded= information carry out
      measurements and reports the collected data = to measurement
      collector. measurement collector co-relates = received data and
      provides measurement results.
 

   can be

 

  Active measurement : Measurement controller induce probe packe= ts
      with encoded performance measurement data or= programs PMI at
      measurement classifier which will in turn in= duce probe packets
      with encoded performance measurement = data. Measurement contr= oller
      updates the PMI to measurement collector. Pa= rticipating
      measurement agents based on received encoded= information carry out
      measurements and reports the collected data = to measurement
      collector. measurement collector co-relates = received data and
      provides measurement results.

 

 

3. In section 4.1

    "PMF identifier" - PMF is used without provid= ing any abbreviation.

 

4. In section 4.3.3

    MA identifier has two parts
   1) Node identifier - 24 bit
      a) For SFF: MUST be unique number assigned b= y controller
      b) For SF: All zero. Context identifier itself identifies SF node.

   I think here it should be Service Index. Context identifier r= eferred nowhere in the draft.

 

5. In section 4.3.3

 

  - At MA         : Pres= ence of self service index tr= iggers the
            &nb= sp;            =    PM collection & reporting

  can be

 

  - At MA         : Presence = of self MA identifier tr= iggers the
            &nb= sp;            =    PM collection & reporting

 

Because of below reasons

   -  A service function does not know its service index

   -  As mentioned in section 5, point 1, it is mentioned M= easurement controller programs the MA identifier to MA. So the MA knows the MA identifier not the service index.

 

6. In section 2

   In the description of Measurement Classifier :  It can a= lso generate probe packet. Need to be updated in description (In section 6 it is mentioned Measurement classifier may generate probe packet based o= n the instruction by measurement controller.

 

7. In Section 4.3.3

   A service function can be part of multiple service funct= ion chains, In this case the Measurement Agent will have 2 MA ID’s co= nfigured.  As per the draft in section 4.3.3, there is no consideration for Ser= vice Path Index(SPI) while MA Identifier construction. So MA Identifier may= have conflict.

 

8. In Section 4.3.3

  There is no clarity on Measurement Agent = Identifier with PM type value on how it is encoded.  Like few bits are= used for MA Identifier and few bits are used for PM type. It is just mentioned MA Identifier with PM type. I think more details can = be provided here.

 

 

Thanks & Regards

Phaneendra Manda.

--_000_6A6AEA8F97B29F4585E1A9F4BE8838747E3A8A57blreml501mbx_-- From nobody Thu Nov 24 04:34:49 2016 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 6AF91129960 for ; Thu, 24 Nov 2016 04:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DRUGS_MUSCLE=0.164, 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=-1.497, 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 QfpyzOj5nD6W for ; Thu, 24 Nov 2016 04:34:45 -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 1E2221294C8 for ; Thu, 24 Nov 2016 04:34:43 -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 CVW62810; Thu, 24 Nov 2016 12:34:40 +0000 (GMT) Received: from SZXEMI404-HUB.china.huawei.com (10.82.75.40) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Nov 2016 12:34:39 +0000 Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.216]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Thu, 24 Nov 2016 20:34:29 +0800 From: Gaurav agrawal To: Phaneendra manda , "sfc@ietf.org" Thread-Topic: [sfc] Review comments for : Performance Measurement Architecture for SFC Thread-Index: AdJEpQpj92A8+idKSra49KzWKaNe9ABaxE6Q Date: Thu, 24 Nov 2016 12:34:29 +0000 Message-ID: <2F2059F256F9B24F82EAC5EE47F446C6E774F768@szxemi502-mbx.china.huawei.com> References: <6A6AEA8F97B29F4585E1A9F4BE8838747E3A8A57@blreml501-mbx> In-Reply-To: <6A6AEA8F97B29F4585E1A9F4BE8838747E3A8A57@blreml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.250.69] Content-Type: multipart/related; boundary="_004_2F2059F256F9B24F82EAC5EE47F446C6E774F768szxemi502mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5836DE62.0072, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.216, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1d8962f98b17ccba53eeeccce436bd63 Archived-At: Cc: Aruna kumar padhi Subject: Re: [sfc] Review comments for : Performance Measurement Architecture for SFC 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, 24 Nov 2016 12:34:48 -0000 --_004_2F2059F256F9B24F82EAC5EE47F446C6E774F768szxemi502mbxchi_ Content-Type: multipart/alternative; boundary="_000_2F2059F256F9B24F82EAC5EE47F446C6E774F768szxemi502mbxchi_" --_000_2F2059F256F9B24F82EAC5EE47F446C6E774F768szxemi502mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUGhhbmVlbmRyYSwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgc3VnZ2VzdGlvbnMu IFBsZWFzZSBmaW5kIG15IGluLWxpbmUgY29tbWVudHMuDQoNClRoYW5rcyBhbmQgUmVnYXJkcywN CkdhdXJhdg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFBoYW5lZW5kcmEgbWFuZGENClNlbnQ6IDIwMTbE6jEx1MIyMsjVIDE1OjE1DQpUbzog c2ZjQGlldGYub3JnDQpDYzogQXJ1bmEga3VtYXIgcGFkaGkNClN1YmplY3Q6IFtzZmNdIFJldmll dyBjb21tZW50cyBmb3IgOiBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBBcmNoaXRlY3R1cmUgZm9y IFNGQw0KDQpIaSwNClBsZWFzZSBmaW5kIHRoZSBiZWxvdyByZXZpZXcgY29tbWVudHMgZm9yIGRy YWZ0LWFndi1zZmMtcGVyZm9ybWFuY2UtbWVhc3VyZW1lbnQtYXJjaGl0ZWN0dXJlLTAyDQoxLiBJ biBzZWN0aW9uIDINCiAgIE1lYXN1cmVtZW50IENvbnRyb2xsZXI6IEFuIGVudGl0eSB0aGF0IGNv bnRyb2xzIGFuZCBjb29yZGluYXRlcyBhIHNldA0KICAgb2YgbWVhc3VyZW1lbnQgZnVuY3Rpb25z LiBUaGUgbWVhc3VyZW1lbnQgY29udHJvbGxlciBpcyByZXNwb25zaWJsZQ0KICAgZm9yIHByb2dy YW1taW5nIHRoZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBpbnN0YW5jZSBhdCBtZWFzdXJlbWVu dA0KICAgY2xhc3NpZmllciBhbmQgdXBkYXRpbmcgdGhlIHNhbWUgdG8gbWVhc3VyZW1lbnQgY29s bGVjdG9yLA0KICAgYWRkaXRpb25hbGx5IGl0IGNhbiBpbmplY3QgcHJvYmUgcGFja2V0cyBpbiBT RlAgZm9yIG1lYXN1cmVtZW50Lg0KDQogICAgY2FuIGJlDQoNCiAgICAgTWVhc3VyZW1lbnQgQ29u dHJvbGxlcjogQW4gZW50aXR5IHRoYXQgY29udHJvbHMgYW5kIGNvb3JkaW5hdGVzIGEgc2V0DQog ICBvZiBtZWFzdXJlbWVudCBmdW5jdGlvbnMuIFRoZSBtZWFzdXJlbWVudCBjb250cm9sbGVyIGlz IHJlc3BvbnNpYmxlDQogICBmb3IgcHJvZ3JhbW1pbmcgdGhlIHBlcmZvcm1hbmNlIG1lYXN1cmVt ZW50IGluc3RhbmNlKFBNSSkgYXQgbWVhc3VyZW1lbnQNCiAgIGNsYXNzaWZpZXIgYW5kIHVwZGF0 aW5nIHRoZSBzYW1lIHRvIG1lYXN1cmVtZW50IGNvbGxlY3RvciwNCiAgIGFkZGl0aW9uYWxseSBp dCBjYW4gaW5qZWN0IHByb2JlIHBhY2tldHMgaW4gU0ZQIGZvciBtZWFzdXJlbWVudC4NCiAgIFdo aWxlIGdvaW5nIHRocm91Z2ggZG9jdW1lbnQgdGhlcmUgaXMgbm8gYWJicmV2aWF0aW9uIG1hcHBl ZCBmb3IgUE1JLiBNYXJraW5nIHRoaXMgd291bGQgaW1wcm92ZSB0aGUgcmVhZGFiaWxpdHkNCg0K W0dhdXJhdl0gQWdyZWUgYW5kIHRleHQgd2lsbCBiZSB1cGRhdGVkIGFjY29yZGluZ2x5Lg0KDQoy LiBJbiBzZWN0aW9uIDMNCiAgIEFjdGl2ZSBtZWFzdXJlbWVudCA6IE1lYXN1cmVtZW50IGNvbnRy b2xsZXIgaW5kdWNlIHByb2JlIHBhY2tldHMNCiAgICAgIHdpdGggZW5jb2RlZCBwZXJmb3JtYW5j ZSBtZWFzdXJlbWVudCBkYXRhIG9yIHByb2dyYW1zIFBNSSBhdA0KICAgICAgbWVhc3VyZW1lbnQg Y2xhc3NpZmllciB3aGljaCB3aWxsIGluIHR1cm4gaW5kdWNlIHByb2JlIHBhY2tldHMNCiAgICAg IHdpdGggZW5jb2RlZCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBkYXRhLiBtZWFzdXJlbWVudCBj b250cm9sbGVyDQogICAgICB1cGRhdGVzIHRoZSBQTUkgdG8gbWVhc3VyZW1lbnQgY29sbGVjdG9y LiBQYXJ0aWNpcGF0aW5nDQogICAgICBtZWFzdXJlbWVudCBhZ2VudHMgYmFzZWQgb24gcmVjZWl2 ZWQgZW5jb2RlZCBpbmZvcm1hdGlvbiBjYXJyeSBvdXQNCiAgICAgIG1lYXN1cmVtZW50cyBhbmQg cmVwb3J0cyB0aGUgY29sbGVjdGVkIGRhdGEgdG8gbWVhc3VyZW1lbnQNCiAgICAgIGNvbGxlY3Rv ci4gbWVhc3VyZW1lbnQgY29sbGVjdG9yIGNvLXJlbGF0ZXMgcmVjZWl2ZWQgZGF0YSBhbmQNCiAg ICAgIHByb3ZpZGVzIG1lYXN1cmVtZW50IHJlc3VsdHMuDQoNCiAgIGNhbiBiZQ0KDQogIEFjdGl2 ZSBtZWFzdXJlbWVudCA6IE1lYXN1cmVtZW50IGNvbnRyb2xsZXIgaW5kdWNlIHByb2JlIHBhY2tl dHMNCiAgICAgIHdpdGggZW5jb2RlZCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBkYXRhIG9yIHBy b2dyYW1zIFBNSSBhdA0KICAgICAgbWVhc3VyZW1lbnQgY2xhc3NpZmllciB3aGljaCB3aWxsIGlu IHR1cm4gaW5kdWNlIHByb2JlIHBhY2tldHMNCiAgICAgIHdpdGggZW5jb2RlZCBwZXJmb3JtYW5j ZSBtZWFzdXJlbWVudCBkYXRhLiBNZWFzdXJlbWVudCBjb250cm9sbGVyDQogICAgICB1cGRhdGVz IHRoZSBQTUkgdG8gbWVhc3VyZW1lbnQgY29sbGVjdG9yLiBQYXJ0aWNpcGF0aW5nDQogICAgICBt ZWFzdXJlbWVudCBhZ2VudHMgYmFzZWQgb24gcmVjZWl2ZWQgZW5jb2RlZCBpbmZvcm1hdGlvbiBj YXJyeSBvdXQNCiAgICAgIG1lYXN1cmVtZW50cyBhbmQgcmVwb3J0cyB0aGUgY29sbGVjdGVkIGRh dGEgdG8gbWVhc3VyZW1lbnQNCiAgICAgIGNvbGxlY3Rvci4gbWVhc3VyZW1lbnQgY29sbGVjdG9y IGNvLXJlbGF0ZXMgcmVjZWl2ZWQgZGF0YSBhbmQNCiAgICAgIHByb3ZpZGVzIG1lYXN1cmVtZW50 IHJlc3VsdHMuDQoNCltHYXVyYXZdIEFncmVlIGFuZCB0ZXh0IHdpbGwgYmUgdXBkYXRlZCBhY2Nv cmRpbmdseS4NCg0KMy4gSW4gc2VjdGlvbiA0LjENCiJQTUYgaWRlbnRpZmllciIgLSBQTUYgaXMg dXNlZCB3aXRob3V0IHByb3ZpZGluZyBhbnkgYWJicmV2aWF0aW9uLg0KDQpbR2F1cmF2XSBBZ3Jl ZSBhbmQgd2lsbCBiZSBhZGRlZCBpbiBhYmJyZXZpYXRpb24uIFdlIGFsc28gd2FudCB0byBhZGQg dGV4dCB0aGF0IGl0oa9zIG9ubHkgcmVxdWlyZWQNCmluIGRlcGxveW1lbnRzIGV4cGVjdGluZyB0 byBtb25pdG9yIGZpbmUgZ3JhaW5lZCBmbG93cyB3aXRoaW4gYSBjb2Fyc2UtZ3JhaW5lZCBmbG93 cy4NCg0KNC4gSW4gc2VjdGlvbiA0LjMuMw0KICAgIE1BIGlkZW50aWZpZXIgaGFzIHR3byBwYXJ0 cw0KICAgMSkgTm9kZSBpZGVudGlmaWVyIC0gMjQgYml0DQogICAgICBhKSBGb3IgU0ZGOiBNVVNU IGJlIHVuaXF1ZSBudW1iZXIgYXNzaWduZWQgYnkgY29udHJvbGxlcg0KICAgICAgYikgRm9yIFNG OiBBbGwgemVyby4gQ29udGV4dCBpZGVudGlmaWVyIGl0c2VsZiBpZGVudGlmaWVzIFNGIG5vZGUu DQogICBJIHRoaW5rIGhlcmUgaXQgc2hvdWxkIGJlIFNlcnZpY2UgSW5kZXguIENvbnRleHQgaWRl bnRpZmllciByZWZlcnJlZCBub3doZXJlIGluIHRoZSBkcmFmdC4NCg0KW0dhdXJhdl0gWWVzLCBp dCBzaG91bGQgYmUgU2VydmljZSBJbmRleC4gQWxzbyB3ZSBwbGFuIHRvIHByb3ZpZGUgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCB0aGlzOg0KDQoxKSAgICAgIEZvciBTRiwgTm9kZSBpZGVudGlmaWVy IG5lZWRuoa90IGJlIGV4cGxpY2l0bHkgY29uZmlndXJlZCAoaXShr3MgYWxsIDApLCBhcyBTSSBp cyBzdWZmaWNpZW50IGVub3VnaCB0byB1bmlxdWVseSBpZGVudGlmeSBTRi4NCg0KMikgICAgICBG b3IgU0ZGLCBOb2RlIGlkZW50aWZpZXIgbmVlZHMgdG8gYmUgcHJvZ3JhbW1lZC4NCg0KMykgICAg ICBNQSBpZGVudGlmaWVyIGlzIGNvbWJpbmF0aW9uIG9mIE5vZGUgSWRlbnRpZmllciArIFNJIChT SSB2YWx1ZSBpcyBvYnRhaW5lZCBmcm9tIHBhY2tldCBpdHNlbGYpDQoNCjQpICAgICAgTUEgaWRl bnRpZmllciBpcyBOT1QgcmVxdWlyZWQgaW4gY2FzZSBvZiBFMkUgb3IgSG9wIGJ5IGhvcCBtZWFz dXJlbWVudCBhcyBQTSB0eXBlIGl0c2VsZiBpbmRpY2F0ZXMNCg0Kd2hldGhlciBTRi9TRkYgbmVl ZHMgdG8gcGFydGljaXBhdGUgaW4gbWVhc3VyZW1lbnQuDQpXaWxsIHVwZGF0ZSB0ZXh0IHRvIGNs YXJpZnkgdGhpcyBpbiBkcmFmdC4NCg0KNS4gSW4gc2VjdGlvbiA0LjMuMw0KDQogIC0gQXQgTUEg ICAgICAgICA6IFByZXNlbmNlIG9mIHNlbGYgc2VydmljZSBpbmRleCB0cmlnZ2VycyB0aGUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBQTSBjb2xsZWN0aW9uICYgcmVwb3J0aW5nDQogIGNh biBiZQ0KDQogIC0gQXQgTUEgICAgICAgICA6IFByZXNlbmNlIG9mIHNlbGYgTUEgaWRlbnRpZmll ciB0cmlnZ2VycyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQTSBjb2xsZWN0aW9u ICYgcmVwb3J0aW5nDQoNCkJlY2F1c2Ugb2YgYmVsb3cgcmVhc29ucw0KICAgLSAgQSBzZXJ2aWNl IGZ1bmN0aW9uIGRvZXMgbm90IGtub3cgaXRzIHNlcnZpY2UgaW5kZXgNCiAgIC0gIEFzIG1lbnRp b25lZCBpbiBzZWN0aW9uIDUsIHBvaW50IDEsIGl0IGlzIG1lbnRpb25lZCBNZWFzdXJlbWVudCBj b250cm9sbGVyIHByb2dyYW1zIHRoZSBNQSBpZGVudGlmaWVyIHRvIE1BLiBTbyB0aGUgTUEga25v d3MgdGhlIE1BIGlkZW50aWZpZXIgbm90IHRoZSBzZXJ2aWNlIGluZGV4Lg0KDQpbR2F1cmF2XSBJ ZGVhIGlzIHRvIGlkZW50aWZ5IHRoZSBTRiBvciBTRkYgaW4gYSBjaGFpbiAoTm90ZTogVGhpcyBp cyBub3QgcmVxdWlyZWQgZm9yIEUyRSBvciBob3AgYnkgaG9wIG1lYXN1cmVtZW50LCBvbmx5IHJl cXVpcmVkIGluIGNhc2UgbWVhc3VyZW1lbnQgaXMgc3BlY2lmaWMgdG8gYSBzZXQgb2YgU0YvU0ZG KS4NCg0KTGV0IG1lIGVsYWJvcmF0ZSBob3cgZHJhZnQgcGxhbiB0byBoYW5kbGUgaXQuDQpJZGVu dGlmeSBTRkY6IFNpbmNlIFNQSStTSSBhbG9uZSBpcyBub3Qgc3VmZmljaWVudCB0byBpZGVudGlm eSBTRkYsIGRyYWZ0IGludHJvZHVjZSBhIG5ldyBlbnRpdHkgY2FsbGVkIG5vZGUgaWRlbnRpZmll ciB0byBiZSBjb25maWd1cmVkIGJ5IENvbnRyb2xsZXIgaW4gU0ZGLiBNQSBpZGVudGlmaWVyIGZv ciBTRkYgaXMgdGhlbiB0aGUgY29tYmluYXRpb24gb2YgobBOb2RlIElkZW50aWZpZXIgKHByb2dy YW1tZWQgYnkgQ29udHJvbGxlcikgKyBTSSAodGhpcyB2YWx1ZSBpcyBvYnRhaW5lZCBmcm9tIFNG QyBzZXJ2aWNlIGhlYWRlciBpbiB0aGUgcGFja2V0KaGxLiBOb3cgdG8gaWRlbnRpZnkgd2hldGhl ciBpdCBuZWVkcyB0byBjYXJyeSBvdXQgdGhlIG1lYXN1cmVtZW50LCBTRkYgY2hlY2tzIGl0cyBN QSBpZGVudGlmaWVyIHByZXNlbmNlIGluIHRoZSBwYWNrZXQgbWV0YWRhdGEuDQpJZGVudGlmeSBT RjogRm9yIHRoaXMgbm9kZSBpZGVudGlmaWVyIGlzIG5vdCByZXF1aXJlZC4gTUEgaWRlbnRpZmll ciBvZiBTRiBpcyChsE5vZGUgaWRlbnRpZmllciAoYWxsIHplcm8pICsgU0kgKFNJIHZhbHVlIGlu IHBhY2tldCmhsS4gU0YgY2hlY2tzIGl0cyBNQSBpZGVudGlmaWVyIHByZXNlbmNlIGluIHBhY2tl dCBtZXRhZGF0YQ0KDQpEcmFmdCB3aWxsIGFkZCBhZGRpdGlvbmFsIHRleHQgdG8gY2xhcmlmeSB0 aGlzLg0KDQo2LiBJbiBzZWN0aW9uIDINCiAgIEluIHRoZSBkZXNjcmlwdGlvbiBvZiBNZWFzdXJl bWVudCBDbGFzc2lmaWVyIDogIEl0IGNhbiBhbHNvIGdlbmVyYXRlIHByb2JlIHBhY2tldC4gTmVl ZCB0byBiZSB1cGRhdGVkIGluIGRlc2NyaXB0aW9uIChJbiBzZWN0aW9uIDYgaXQgaXMgbWVudGlv bmVkIE1lYXN1cmVtZW50IGNsYXNzaWZpZXIgbWF5IGdlbmVyYXRlIHByb2JlIHBhY2tldCBiYXNl ZCBvbiB0aGUgaW5zdHJ1Y3Rpb24gYnkgbWVhc3VyZW1lbnQgY29udHJvbGxlci4NCg0KW0dhdXJh dl0gQWdyZWUsIGRlc2NyaXB0aW9uIHdpbGwgYmUgdXBkYXRlZCBhY2NvcmRpbmdseS4NCg0KNy4g SW4gU2VjdGlvbiA0LjMuMw0KICAgQSBzZXJ2aWNlIGZ1bmN0aW9uIGNhbiBiZSBwYXJ0IG9mIG11 bHRpcGxlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5zLCBJbiB0aGlzIGNhc2UgdGhlIE1lYXN1cmVt ZW50IEFnZW50IHdpbGwgaGF2ZSAyIE1BIElEoa9zIGNvbmZpZ3VyZWQuICBBcyBwZXIgdGhlIGRy YWZ0IGluIHNlY3Rpb24gNC4zLjMsIHRoZXJlIGlzIG5vIGNvbnNpZGVyYXRpb24gZm9yIFNlcnZp Y2UgUGF0aCBJbmRleChTUEkpIHdoaWxlIE1BIElkZW50aWZpZXIgY29uc3RydWN0aW9uLiBTbyBN QSBJZGVudGlmaWVyIG1heSBoYXZlIGNvbmZsaWN0Lg0KDQpbR2F1cmF2XSBZZXMgZm9yIHR3byBk aWZmZXJlbnQgY2hhaW5zIE1BIGlkZW50aWZpZXIgY29tcHV0ZWQgbWF5IGJlIHNhbWUsIGJ1dCB0 aGF0IGlzIGZpbmUgYXMgdGhpcyBNQSBpZGVudGlmaWVyIGlzIGp1c3QgdXNlZCB0byBjaGVjayBp ZiB0aGUgZ2l2ZW4gU0ZGIG5lZWRzIHRvIGNhcnJ5IG91dCBhbnkgbWVhc3VyZW1lbnQgYnkgY2hl Y2tpbmcgaXRzIHByZXNlbmNlIGluIFNGQyBwYWNrZXQgbWV0YWRhdGEuIFBsZWFzZSBsb29rIGF0 IGJlbG93IGV4YW1wbGUgZm9yIG1vcmUgZGV0YWlscy4NCkluIGJlbG93IGV4YW1wbGUgaXShr3Mg ZXhwZWN0ZWQgdG8gY2FycnkgbWVhc3VyZW1lbnQgYXQgU0ZGMSBQb3J0IFAxLCBQMiwgUDMsIFA0 IGFuZCBpdHMgYWxzbyBleHBlY3RlZCB0byBjYXJyeSBvdXQgbWVhc3VyZW1lbnQgYXQgU0YzLiBT byBiZWxvdyBwaWN0dXJlIGRlcGljdHMgdGhlIGJlaGF2aW9yLg0KDQpbY2lkOmltYWdlMDAxLnBu Z0AwMUQyNDY3RC4zMUQ4RTUwMF0NCg0KOC4gSW4gU2VjdGlvbiA0LjMuMw0KICBUaGVyZSBpcyBu byBjbGFyaXR5IG9uIE1lYXN1cmVtZW50IEFnZW50IElkZW50aWZpZXIgd2l0aCBQTSB0eXBlIHZh bHVlIG9uIGhvdyBpdCBpcyBlbmNvZGVkLiAgTGlrZSBmZXcgYml0cyBhcmUgdXNlZCBmb3IgTUEg SWRlbnRpZmllciBhbmQgZmV3IGJpdHMgYXJlIHVzZWQgZm9yIFBNIHR5cGUuIEl0IGlzIGp1c3Qg bWVudGlvbmVkIE1BIElkZW50aWZpZXIgd2l0aCBQTSB0eXBlLiBJIHRoaW5rIG1vcmUgZGV0YWls cyBjYW4gYmUgcHJvdmlkZWQgaGVyZS4NCg0KW0dhdXJhdl0gQWdyZWUgYW5kIHRleHQgd2lsbCBi ZSBhZGRlZCBmb3IgdGhlIHNhbWUuDQoNClRoYW5rcyAmIFJlZ2FyZHMNClBoYW5lZW5kcmEgTWFu ZGEuDQo= --_000_2F2059F256F9B24F82EAC5EE47F446C6E774F768szxemi502mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Phaneendra,

 

Thanks for your review= and suggestions. Please find my in-line comments.

 

Thanks and Regards,

Gaurav

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Phaneendra manda
Sent: 2016=C4=EA11=D4=C222=C8=D5 15:15
To: sfc@ietf.org
Cc: Aruna kumar padhi
Subject: [sfc] Review comments for : Performance Measurement Archite= cture for SFC

 

Hi,

Please find the below review comments for draft-agv-sfc-performance-measurement-archi= tecture-02

1. In section 2

   Measurement Controller: An entity that controls and coordinat= es a set
   of measurement functions. The measurement controller is respon= sible
   for programming the performance m= easurement instance at measurement
   classifier and updating the same to measurement collector,
   additionally it can inject probe packets in SFP for measuremen= t.
 

    can be

  

<= span style=3D"font-size:12.0pt;font-family:"Arial","sans-ser= if";color:black">     Measurement Controller:= An entity that controls and coordinates a set
   of measurement functions. The measurement controller is respon= sible
   for programming the performance m= easurement instance(PMI) at measurement
   classifier and updating the same to measurement collector,
   additionally it can inject probe packets in SFP for measuremen= t.

   While going through document there is no abbreviation mapped = for PMI. Marking this would improve the readability

 

[Gaurav] Agree and text= will be updated accordingly.

 

2. In section 3

   Active measurement : Measurement controller induce probe pack= ets
      with encoded performance measurement data or= programs PMI at
      measurement classifier which will in turn in= duce probe packets
      with encoded performance measurement = data. measurement contr= oller
      updates the PMI to measurement collector. Pa= rticipating
      measurement agents based on received encoded= information carry out
      measurements and reports the collected data = to measurement
      collector. measurement collector co-relates = received data and
      provides measurement results.
 

   can be

 

  Active measurement : Measurement controller induce probe packe= ts
      with encoded performance measurement data or= programs PMI at
      measurement classifier which will in turn in= duce probe packets
      with encoded performance measurement = data. Measurement contr= oller
      updates the PMI to measurement collector. Pa= rticipating
      measurement agents based on received encoded= information carry out
      measurements and reports the collected data = to measurement
      collector. measurement collector co-relates = received data and
      provides measurement results.

 

[Gaurav] Agree and text= will be updated accordingly.

 

3. In section 4.1

"PMF identifier" - PMF is used without provid= ing any abbreviation.

 

[Gaurav] Agree and will= be added in abbreviation. We also want to add text that it=A1=AFs only req= uired

in deployments expecting to monitor fine grained flows within a coa= rse-grained flows.

 

4. In section 4.3.3

<= span style=3D"font-size:12.0pt;font-family:"Arial","sans-ser= if";color:black">    MA identifier has two parts
   1) Node identifier - 24 bit
      a) For SFF: MUST be unique number assigned b= y controller
      b) For SF: All zero. Context identifier itself identifies SF node.

   I think here it should be Service Index. Context identifier r= eferred nowhere in the draft.

 

[Gaurav] Yes, it should= be Service Index. Also we plan to provide more information about this:

1) &nbs= p;    For SF, Node i= dentifier needn=A1=AFt be explicitly configured (it=A1=AFs all 0), as SI is= sufficient enough to uniquely identify SF.

2) &nbs= p;    For SFF, Node = identifier needs to be programmed.

3) &nbs= p;    MA identifier = is combination of Node Identifier + SI (SI value is obtained from packe= t itself)

4) &nbs= p;    MA identifier = is NOT required in case of E2E or Hop by hop measurement as PM type itself = indicates

whether SF/SFF needs to participate in measurement.

Will update text to clarify this in draft.

 

5. In section 4.3.3

 

<= span style=3D"font-size:12.0pt;font-family:"Arial","sans-ser= if";color:black">  - At MA     &nbs= p;   : Presence of self service index tr= iggers the
            &nb= sp;            =    PM collection & reporting

  can be

 

  - At MA         : Presence = of self MA identifier tr= iggers the
            &nb= sp;            =    PM collection & reporting

 

Because of below reasons

   -  A service function does not know its service index

   -  As mentioned in section 5, point 1, it is mentioned M= easurement controller programs the MA identifier to MA. So the MA knows the MA identifier not the service index.

 

[Gaurav] Idea is to ide= ntify the SF or SFF in a chain (Note: This is not required for E2E or hop b= y hop measurement, only required in case measurement is specific to a set of SF/SFF).

 

Let me elaborate how draft plan to handle it.

Identify SFF: Since SPI+SI alone is not sufficient to identify = SFF, draft introduce a new entity called node identifier to be configured b= y Controller in SFF. MA identifier for SFF is then the combination of =A1=B0Node Identifier (programmed by Controller= ) + SI (this value is obtained from SFC service header in the packet)= =A1=B1. Now to identify whether it needs to carry out the measurement, SFF = checks its MA identifier presence in the packet metadata.

Identify SF: For this node identifier is not required. MA identifie= r of SF is =A1=B0Node identifier (all zero) + SI (SI value in packet)= =A1=B1. SF checks its MA identifier presence in packet metadata

 

Draft will add additional text to clarify this.

 

6. In section 2

   In the description of Measurement Classifier :  It can a= lso generate probe packet. Need to be updated in description (In section 6 it is mentioned Measurement classifier may generate probe packet based o= n the instruction by measurement controller.

 

[Gaurav] Agree, descrip= tion will be updated accordingly.

 

7. In Section 4.3.3

   A service function can be part of multiple service funct= ion chains, In this case the Measurement Agent will have 2 MA ID=A1=AFs con= figured.  As per the draft in section 4.3.3, there is no consideration for Ser= vice Path Index(SPI) while MA Identifier construction. So MA Identifier may= have conflict.

 

[Gaurav] Yes for two different chains MA id= entifier computed may be same, but that is fine as this MA identifier is ju= st used to check if the given SFF needs to carry out any measurement by che= cking its presence in SFC packet metadata. Please look at below example for more details.

In below example it=A1=AFs expected to carry measurement at SFF1 Po= rt P1, P2, P3, P4 and its also expected to carry out measurement at SF3. So= below picture depicts the behavior.

 

<= /o:p>

 

8. In Section 4.3.3

  There is no clarity on Measurement Agent = Identifier with PM type value on how it is encoded.  Like few bits are= used for MA Identifier and few bits are used for PM type. It is just mentioned MA Identifier with PM type. I think more details can = be provided here.

 

[Gaurav] Agree and text= will be added for the same.

 

Thanks & Regards

Phaneendra Manda.

--_000_2F2059F256F9B24F82EAC5EE47F446C6E774F768szxemi502mbxchi_-- --_004_2F2059F256F9B24F82EAC5EE47F446C6E774F768szxemi502mbxchi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=63100; creation-date="Thu, 24 Nov 2016 12:34:28 GMT"; modification-date="Thu, 24 Nov 2016 12:34:28 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA0UAAAENCAYAAADAE86dAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAPX8SURBVHhe 7d0HmDVVkTfwRldRMaEiSFAXRTGiYkZFBXPEnDFhdhWziAlRMIFZMaMIBoyYMGACM2sWMYJhXV0T rrrm/s7v7Fez/fZ7Q9+ZO/NOqHqe+0y4HU7/u/ucCv+q2qot0qQkAolAIpAIJAKJQCKQCCQCqwCB 7373u80pp5zS/O1vf2u22mqrVTCi1TmEf/zjH82FLnSh5sY3vnFzkYtcZHUOcg2Naqs0itbQ3cqh JgKJwGYI/OlPf2p+9atfNenfmfxwUCy23377Zuutt86nKBFIBBKBVY3A4x//+OZnP/tZc5Ob3KQa RimbIxDG4jve8Y7mgAMOaO585zsnTEtEII2iJQKYuycCicCWQ+DHP/5xY/E8xznO0VzwghdseM1S NkfgbGc7W/Ob3/ymGkRHHHFE9SymJAKJQCKwWhGg5F//+tdv7nOf+6zWIa6acT360Y9uLnOZyzQP e9jDVs2Y1upA0ihaq3dulY77D3/4Q/Mf//Efzd///vcMeU+4R6IaQt3bbbdd4rSEZ/kLX/hC88xn PrN56Utf2uy4444ZLRqDJaPo+9//fvOYxzymecUrXtFc+tKXXgLquWsikAgkAsuLwEMe8pBmzz33 rBGQlMkIPPKRj2yueMUrNg9+8IMTqiUikEbREgHM3f8Pgb/85S/Nk5/85OaHP/xhc9GLXjQV1DEP h5D3n//85+b3v/9986xnPau50pWulI/RIhH48pe/3DznOc+piv4OO+ywyKNsjN0YRY997GNrpOhS l7rUxrjovMpEIBFYkwikUTT8tqVRNByraVumUTQNofx+MALyOu573/s2D3/4w5u99torjaIJyDEg H/SgBzX3u9/9mtvd7naDMc4NN0WAUfTsZz+7Rop23nnnhGcCAt/5zneaJzzhCc2RRx6ZRlE+KYlA IrCqEUijaPjtSaNoOFbTtkyjaBpC+f1gBH7961/X8C1+6/Wud73B+23EDf/61782+++/f3Ove92r udWtbrURIZjLNadRNBzGNIqGY5VbJgKJwJZFYFaj6Ac/+EGjYh3q/i677NJc+cpXbtCGQ7797W9X Fkv3f/GdfTANrn71qy98/9///d/N1772teYXv/hFdSJd5SpX2bKATDh7GkXzuzX/98TM75h5pA2O gAkmZTICqulktbQt85SgLio6cNZZZ202gH/+85+V1uj73/72tyM/DNq+/O53v2tUwUtJBBKBRCAR WDkEvvKVrzQMKM7FW97yls1tb3vb5mY3u1l1On7mM59ZGMjrXve65va3v31zm9vcpm7b/WBroBZb lxXrOe6442olNx/H3m+//WoRg+9973srd2F5pi2CQBpFWwT2PGkikAisNAIiJS972cuaO97xjrWq 0Q1veMOaA9ddOP/zP/+zucc97lF7Pvjedje4wQ3qx+8+73rXu+rQLaCf/OQn62J53etet9l3332b F7zgBc0ZZ5yx0peW50sEEoFEYMMhIPrziEc8ojnqqKPqte+99971oxLpMcccU+np//7v/76AC4NH pVLz+D777LPwwWy55jWv2ZzznOes0aYXvvCFzec+97nmuc99bvORj3ykFjF45Stf2Tz1qU9N59c6 f8rSKFrnN3g1X55Q9pve9KbmcY97XP287W1vq6HqEBPY61//+lpyedSHZycU1P51vuENb2gOPvjg 5uc///lqhiDHtkIIqFJ397vfvUEz+OAHP9icdtppzVe/+tXm8MMPr97DV7/61XUknjmLKNrE17/+ 9cai+81vfrN+vvWtb9VPRJg8r7e4xS2a973vfc0d7nCHZvfdd2+e9KQnVQrpT37ykxW6sjxNIpAI JAIbE4GPfexjzWc/+9nmXOc6V9UVOKniw5GFUkfHIP/yL/9Sf17ykpdsjj766OaEE05o3vOe9zTv fve7mw9/+MPN85///FoJVrsCxWj8Xznwq171qrVSrP232WabZHis90dN89aURGAeCJRCC23xwref +MQnJh6u0I/a5z3vee0lLnGJtrxfm3wKb7d9+9vfXvcvNLy2TGybbdPdp4S3NznXT3/607ZUI2vP c57z1P1KaH0elzb3Y5TS5e1d73rX9v3vf//cj72RDvilL32pLUZNW4yQsZf9P//zP21pAFifh+IR bIvB055++un12XjUox5V/7/tttvWvz3DpVx1/d+//du/1eOeeeaZ9VMiQG2JNrWFVteWQhntscce 2xaqRluKPNRzF9pdu+uuu9Z9n/a0p62621AMwbZQR9pShW7VjS0HlAgkAolAF4HiXGqLs2oiKObj a1/72nXOLdS5thhGbYns1DnO3F2cWG2hvNVjFMdr3a70amsvf/nLt8XYaffYY4+25B7VNeS//uu/ NjuXeb84vtqzn/3sbYlI1Xl/NYqxvepVr1qNQ1tzY8pI0Xq3elfh9b32ta+tvWV++ctfVs89D43S 1PjAvPc87V/84hebMhE1F7jABeoVCF+/6EUvqvQnlcZ8ePnvf//71+/lcxx66KFNMTSaYnDVv5UF D+/QKoQhh7RCCHiOdtttt3q2yP1RqU7i7DOe8YzmJS95SVMMoPqsdPPhRIWOP/74RrdwUaFiBNV8 I9QMFAyRp/e+972VvkE0kpWv5HxZHnyFbm6eJhFIBDYsApe97GWbt7zlLZUVgrZMH7jpTW/aXOc6 16lzu2IJ0ZOtaOcVJ5VfMQDkIgUjwO/m7r7IMVWw4eIXv3jVTYozbcNivVEuPI2ijXKnV9F1Slb8 4x//WBXHAw88sFLnTGrvfOc7q1FDYUVhMokJZxMGzq1vfeuFD9oS4+nmN7/5grJLccULLt7/+j8T WkoiwICxQCqBXryBNV9INSGGNgMat9z3/rYwxjP38Y9/fOH5VMr6oIMOatAySWwT6GpY7Dn2s0Sl mrvd7W4JfCKQCCQCicAyIqAgjjnbfIsWbc5+61vfWmlvjCUFFArzZJM5m4FTGBqNyqWf//znm1NO OaVSoOkYfUG143x1nJNPPrnmFNFdUtYvAmkUrd97u2qvjNEiKvSjH/2o/jSBycU48cQTaySIQfSA Bzygeu3DsDnppJOqx8ck9a//+q/1dxNheH/wgBlFok477bTTqr32HNiWQWC77barESEcdFFJxrTF UUUiSbd6HVlcGVDxTOm1ZRFkDCnI4BmVO9SXQtmsxRbw0vHPHb/Q8bbMheZZE4FEIBHYIAjIGeIs LRS6Rt4ohxfHKtaI4jdylM3xJEpxF2p9bRmy5557Nte61rXqdqJBiiyQQpmruUZvfOMbF/SPQrmr 38knlXeasn4RSKNo/d7bVXtlJZeoenNEhoS/P/3pTzcodXr2mOB8Rznt9hM4//nPXyculKfCA66/ M4xCgZVoWXjClbpUckjqtfe9+asWkBzYsiLgGUG3VE2O11CBDhEfnkXPHW+jSKW/JdKGMNgPOeSQ ajCVPLXmsMMOqxXmuqJaHeodGp1nV8UjvS5SEoFEIBFIBJYXAXqAObnk6FZHKtocJxeHFkeq+fye 97xnHURQo9HnbD9O9Ft8ylOeUivXiTapQkdHYRgpz00XSVm/CKRRtH7v7aq9spIc35SkwOpxka+h shduL8VV2eSHPvShVWll4IRho8ymiUn5ZB+/iwqNasSWxtCqvfVbZGCeB9FDVAlRHDQ6JVdVGIrq hSJJF77whTfxAoZxPW7QKhtaJFUpQq9QFpZhro9RehO3yK3OkyYCicAGQoChwnElR5mBZI5Hc5Pf aU6mU3C2hsgbjajPOJgcxzE5uZ74xCfWvkf2obOMYgpsILg3xKVupTTEPK6U9c3CphBIbvO3pGS9 PFJJnQfCy3cMj4DIDA+Il/985ztfDSUrQxkh5SFnd//l+Ug855UfJ2hGJizPCkqTkLfzm8h4Z9CR 5GcwepRL5oW3vZD2EDER8t5TdHmL5IqsNsFL5tm6973vXZvIpSwOAbxwkRz3XC7aOPGsMYREhpSC D4kiDEq+S9L1DIr0yD169KMf3Rx55JEjD2lec16LMRH9FLlU4INH0kLsGVxNwuEgN8o1yalKSQQS gURgtSLA4YTidsABBwwaojlbGwXzr3zly1zmMs25z33uhX31H0K3o+eY46cZR+ZyxRU4x9CiUfRX qyhYRc+hf6UsDYFFG0UePEowL/83vvGNagDxjlKw5YH4MIzSY7q0G7RSe/OgMIAYsBGhEYVhIJkQ Lne5y1VPOuNlnAw1iiiUcjR46j0vJi7n8rx4rhhUeMByhyStS56UDP+hD31o4vljXBpoUnKFziVR otutNkmjaD53ZKhR5GyeNRWKok+R5x0XHa+cUUNQ6eS1qYyoK7ru56PEgqn/hSpG3h1Gl4/3x5xn X93QV5OkUbSa7kaOJRFIBCYhMKtRtJHRTKNofnd/ZqOI8cMap2xSMHbZZZdmxx13rPSUi13sYtX6 VrKWoiuhjbI7p2DU/K46j7QJAhQ594ii51P6sFQDBT3oZz/7Wa2o5Xf3WYKivJ5RvNqhRpGTiyYy dlCPNF9zfmFrRhCFsvR7qQYSKh2qHEPp5S9/+aAS2xIkdaLm2dHQTd7SapM0iuZzR2YxiuZzxrV7 lDSK1u69y5EnAhsNgTSKht/xNIqGYzVty8FGEWW5NMWqlcEID6vogTBlN0Q57YT5/dpDwL0Xmta3 hQHDiLrSla5UK8ed97znXbigWYyi2ElE0X6MIsZ0l67nf4wn52dgD01wVEVMlRgefMcU+VptkkbR fO5IGkXDcUyjaDhWuWUikAhsWQTSKBqOfxpFw7GatuWgQgvocXI/cDI1xlKmlkKM3pQG0TSI1/73 DBL0IvdcDoVIjtwLNCOc26WISKLcHz0C+vlLjC+GEMN7qEFkLCrRbb/99pXutxoNoqXglfsmAolA IpAIJAKJwP8246aX+vzqV79agIRDFcOFI8jPEMyX0047rTJgCIesffVOjI+/0ahnFQ5ebUawaiaJ nGllvyeJUuLyn7rNxGcdT26/OAQmGkUoVHq/qBB2jWtco5ayRZ+alFeyuGHkXmsFAUaGZ0AhBNHC 448/vj4j8oS6PV7WyvXkOBOBRCARSAQSgURg7SGgrYc+Qz4KMmCIEHmdj3nMY6quQm8lDCV6S/d/ KobaVylvRR2udrWr1Z8qz8l7Vil3iKieK7IlP1WlXM5j7Rq6whDS6y5KhivkwwDrCmMsGoprRK/w lP5LKSuHwFijCL1HCUJWtrwOie7pdV+5G7MWziTPR9iW10VhBM+MqFLmkK2Fu7dxxsi587SnPa0W Tbj73e/efPKTn1y4eJ5E//OdHDfCY6i3hf/ZVh6l5qz+3m+//WpFRGVaVQ6Us6bYwlD5/ve/v9A8 VnXFn/zkJ5vtajFVTU+DWf0yRh0frVRPJFUZH/7wh+fCOfQG5HaJQCKwbhBArRft8Xnf+95XHbQE y0RutP93oz7xd/zPPBr7R+VdxaXkzR9++OG1Qby0kRDOX3O2Cqb2JaeffnptGKs6LmNI2W4lvQ88 8MCFbaQfqDaLXfPABz6wVjZVqEfj+lgD0P4ZYj70bXnR2o/c6U53ar7yla+sm3u22i9kpFFECXjN a15TczIoAwoopCQCoxBAU1OC24Sit5CwL/raJOF9sS2lrqvwmRTe//73N69+9asXPDQmIdXC/E/+ CKGoxv6O8eY3v7k57rjjKpXPMWYRnhr7K+agetgoEe7WUFb1u5gI+9uZWE2K+t6YAFNWDwK8hp4h z5b7+KIXvWjhPnpe/c934bVTee7YY4+t/2PEeKZERP3tHisRf8IJJ9Tn10KHUvyKV7yiRksniefW AqcQiEXbAnmXu9ylOfXUUxd28z5YiC2IRJTeIvuBD3xgYRtGE68or6cmhPL87njHO1YnVjokVs9z lyNJBBKB5UUgHPVRNZdz1pzu/1Fyu0vLj9/jJx2XaKegfYdqyj4KiXGCMX6sFwwswmEm0nOFK1yh zv/kU5/6VDWMbnSjG9UAAkeWlgeMKXnYxBzP6SYX2/fmblElUSC9lYi1ho4hXYBhxHiSskD/CIfd 8qKZR4fAZkaRRVYvDw+Nvh3TarknjImAZ4XXXNEFk4hS2JOEgePZso8QNyOcCH37W619zyARfYr/ MdQpfRpwxv6Owdtyj3vco1aoo0BSWqcJDxPFk6ddtIsiahIyuYXgCFNgbWOy23///asSq8N1V048 8cSq7BqTY4gmGEMqqNPuwsp9z/sXwkBi1BCUT9FNEnNd9OyK/8l7i5w29/btb397NZp0O9ePSKQU LeJjH/vYwjncf9t6bizSxDONZiFqZfHTx8iCaHGNZ4URZJH1rOnnpbeSZ5LB410g/s8jyptosTQO 7864yNPKoZxnSgQSgURg5RG4wAUuUB1F8oU4qMioxu7jRmbOV11XxVofbTzM03SZL37xiwsOWfsz wOg8DCrzNmcZiTUicqHlO0WUqbsNvYLEmhT6yic+8Ymaj+Q4YazFNpxijpey/AhsYhS5wUok83pb lLOIwvLfgPVyBi8xBfGSl7xk9bhMkq7nhlIXIW+TWHwXeWsmmK7Hx98RiRLBZIwwVBg1ynhTNnF7 hdJDeNYpm6JJkWCJi0yR5SEy6fHMiBg94xnPWIgY8cCjJokUiCRRTI0XR1k0gUiGfNCDHlQ9Qt4d k5dwuP8pUJKyuhDg4dttt91qlIYxPtTpE0YLnrf+Qyh3DHGGzn3ve98aebK4oeoRxo6oEgeA8zBs /M97okAN0c6AoEh4Li16FkYSfZP8tEjyNKJ0iGbGQnvxi1+8bqtQiQUd1ZlBlZIIJAKJwEZCgL7A KamlBxYJ46hbGXcaFtFXs7sdg8Qx6MPmXmLtMF/7G8VaEEFrmq44Fj3FTwWpSHebMIpiTVGcwf9E hBRWiF539ott7K+JbMryI7CJUSRsiOJhkZ/m7V/+oeUZ1hoCJhAUItGVmAxGXUN4cEw6SmabxFDO KKjxnYkhJP7X/6nQA2OHUcXgoSxKTGQEHX300QtJlyI7DCdK7Mknn1yTMMNwu/GNb1w7X++7777V IBPOlmdCKKgiShRhYW9V92zLAIrS9MLsrpWyLcFSwqZmt4wm58po0ep6ij0zT3ziE+t9Rptzz2fJ lfQ8dMUzG32wPFNR6YjRhMohosSwESFiQDOKYlGMn2ifPISqJ3WpdM5jG+PzveeS8RWRyni2PM+O y3gPiunqQj1HkwgkAonA8iHAGUWfOOigg+ocyRkVkfWhZ+3qHDH3MlKsEShthPG188471zk98qfD +Ir9u8cJPXqSPm1/+wRjwXn6x7LNLOvU0GvO7TZHYMEoYvFawCl2rOHFCJrIRz/60aqQ8lg6Zlco zBRNCmzkgvDO26efh2FfntfgWy5mPN19KBRoL+Hh735HeRXenPUlWuqY1tv+FEaTB8WToTIuRyeu m4HxhCc8oSYReh4odrO8+JTBrlzkIhepXnzCWAk+L486Wh06k2eb1yW87RGmdiwTF69NVHtBUyIR mTJBUoJ5/sOoim1MnDGeiHJ5pqZhsN6egbVwPZJieRTRzfC4p+XAda9plJHbNXLid42IeS6dy7PR fQ76xxh1zPhf97v+/0Z9F+cfdR9sn0b6WnhCc4yJQCIwKwL0D5XjUJY5vER0hgo9oL8OyH1WkEE/ Ts7OUcJYkVNKIqfUscz3mFbyjAiHamzT1Tn8T94QI0iuEuqefWObKMltvdp2222HXk5utwQEFowi iilPJZ76rOJhePnLX16TfT2QrHUUJkqo6kwhHtrHP/7xNZeEMoy+hLaEC2pfycwhPKO2O+KII2Yd zsjtnfuwww6ridFdA0ykAQWLItz3FMzlxBvoIIwCE4uqWahA0wxaxoN7fKtb3ao58sgjqzcdN3io TFLyGOhREtNE6dlCmVNyU/5F8HO7oey4/2EcR3nPUQpqNw+qP97Y3jkmKalDrzO3mx8C5gGGrfnH 86rKW995M+lsXW9ebBfzyQ1ucIOxRWnQNNHmnDMM/4h8XvGKV6x9uiyIjCkSz6JtPUOoorvvvntd GC2eJBZOC7NtLMKT5m80PNeeLID5PU95pEQgEdhyCMRaa/4LAwLlXaEDtDcyxLGE8i63WD4z6jtn lupx5mE6Cmo+QXF71KMeVdlUHKvmcGwTugwjipMN20pBBvM1lglRBtwcjo0l0k/XwRCg71g3CIaJ +Z9jVn6q/Gx6qXOY17MVzso8Z1uVB6Z1KhUxLNroR7N46+2rOofyhWgpFmyLM8VSREhyPIWX4SOs qSa8B1g0KSxz2+L4y+1g4Xs4UE0os6xwEZ55iIdVJEFCvgiVnBERBIn08kUyh2ppKJuEGMMUTlW0 3EOlKfti8nG/JTMynFDRlDnWG8DEYuJQ0Y7CyjBxv0wgEtNf/OIX16owojD2kcfTFQn0yiWbFBlB ztEXVcYcw09NiY1HVGmvvfaqdDl0PnzhW9ziFjWp3UTp+WAI8fwYr9yjpz/96fU7oXrPqXwmExgj 27lNrJ6zUZOZZ56BHkbh0pDfuHujiz372c+uzwpawyhxTz1botRyz8xL5OCDD677hqC7ie6Yh3jm 3G9lUz0Hop+eZxRM1DhzmKnTs2p+cw7HNZcQzxbeOYPFomdOlacpgioq6vkyb1p4Peuea8+OxtiH HnpoHZuCIop48CQ6rvwl74Pn03euyb76X6hmZEz2l2PUjwg5NkcBJxAqKSMsDfaVe2/cD/OAhtLW PcpQNJl2v9Iht3L3Is+0NhCgS9AB6Y7jJOZQ7xJ2Uhgh1m1ztapxDApGhvmOwxYzCV3eT7oKxkBf vKtXucpV6hrO0R/OMPTmq1/96nVz5bcVYxDZ4fyn03LEmmsZUY5tHSHefzmm1il0ewYcI8n87Rzh 4MJw0acIs8lxpRfI1VYFepJ+SofhXKOPpCwNgWoUSfINBU+T1lnFjaU8eGC61DsRJMpkJMSHUcRj 6eZ3hSIiRGkcHjTWsrF4qEKJmXVco7anTFOuKQascJ5XOTBROWQe59iox2AUeSlNBiYBVbEofZFY Hrh0jSI0NB5yytwLXvCC6kn33AwxiiiL7l143J2fQskQUQXOBGSydDzKpDGZZPw0RopoGPOMOHlD vDueEWNmuBmrydW1UJJNiM7D+GLgK+hAYfV7PNPGxUCyj31HSRpF83lLhhhFsGZY25YxHEU4GAkM nChu8MpXvrIa9ZwlnDsWUYaIfTwbo6i3rsLzyyFkXglHjzmM4YLn7ngWLAu1bdDpRCw5BCx0zuv5 ITyInn3PmvnPnOp/FnPPnn1FtizyFs6IaqKtmtMUXOjTSh2X0u25NQbHQjVNo2g+z+CQo5hzYp6C u3vkIxeCwYyic/nLX74a9gzWlERgoyNgLjYHch6OE04pxY8YLZhJ5rUQRgg9kk7KgUQUQjJvygP1 PzqgTwQCwpnke/Ntn7LGyNJ2gy4rQhSRfcf2Hd2BjkFvHUXLlvdpDuZEoyfYti/GYE0ydrS7cc6+ 7n7WFXnNaRTN4a1hFBWLuS1UtrYkCftzZikhw7ZEXNriIW9LmeO2KKptMXLaYg1vcqyimLZFuWiL 8dOWhWGT74pR1ZYHu/WTFK9sW7xqbfHszjyeaTsUb21blJW2eIDbQn2Ztnl+PxCBQr9sCw2yLTla baGO1WeqKKCb7V1eXNHJtigCbVFM6/fFMG+LIlr/71MmxPr/MtG05WWv/yvekvq/EpWpf5dJpy1G TFuUiXqsokzU/xcPT33+QkqEsH5v2zIh1X+XssxtmZDqtiU6WY9t31L+e+G5LdXj2mIctcWob4sX qC3RobYol/Uai9Jaj+OdKVGE+uwWr1VbaKQLxy3h77HIFcW2LR6itkyiA9HNzUYhUCKLbYkYtoX+ MBagUrWnLRUD25Iv2RZDZZPtyoLalsWpLYtYWwzZ+l0xkOsxy6JX50bPcono1W08e8XLWL8rxlJb okRtoR63RcHd5LjFIG5LhKjOiSWHbeE7z0Qps13nHvuWKM9m4zb3lahSWyIIbaFdtCWK3xaqRuta i5exLTz3er3ereJFbAsleZPnfRwQhfpRn93FzvP5BC4dAeteUYzaYqDW+1CUurYYuO1RRx3VFgdS W4zrugZ6BlISgY2MQDGG2sLC2MgQDL72Es1qixN38Pa54XgEaqQIZQ3dg1e/289jFpuLx4uVzPvJ oxoVkdBEIoTI+ylsKdEdxSloRaxukSLeWVQUURtUFc2tupEiHjZe0kkeTh5RnPkIR466BtEr4Uhe CLkmURp3luvNbTdHICJFujXzfIv6CSOjZHbFc8Y7jtrmmUEfITi6PB3yyfCC9WgR4UFf4jEXtRHq ln+GVuRe87yUR7h6enjfPV885l0Pjr40qHZC1qiY6G32cT7FRUSreGM8qyI7PP8hnkt0J5EhzyVv FIpVlEO2nXLLtuFBMh6RI9uIDoyTjBTN5w0S/XnOc55To3qiJJPEPV9JmtKs5xPRROnwrHvWUEdQ Ouc1Zs+pnE5zLHppyupCQMldeQS8xHIXdtpppzqXdOea1TXiHE0isHwImKvQ5s2DkS8069migIL9 6Y6itXQFc/N6EGuDa1EsTKuQKDS1Hq5tS11DNYooFCZkvPRZF2DhS0qsXIswRBgtKHkMjuIBq8ox mgrjR+6FRR9dIOgEqEoUX/k9ONdklFEknIh/6Xyj8p6cF70Et5MyMUrkelDK8ftVJ2EEomDFebfU jVgP5w2jSChXHoX7zkBFVeuK+4d7S/FT2jKeGy+3++45QQdCu3RP3XfGkb99cHKFqrshb79TikeF o02G8i4Y6voo9amSkiLd/64x1L8fxiAc7vzjxDNv8o0eM5PuaRpF83niGa3ygtDcwriez5FX9iie T4Y+Hrm5FBVi3sIZxdmANqrwQ8rqRcAcxzgyH8pns25OcvSt3ivJkSUCi0OAc52TgMN9Vr2UPqCo DP2BjkrHszbTcbsUu2kjC8d9VJabtv2W+J7eRI9F+csiOku/A9Uoks+Bx8wTP6tIMqcESzTr509Q fimIEt3kWFAERRAiKW5SKdxRRhGlWzK0n6MWiDCKGDxRLaR7PXj497nPfarxJcEeV1/UwZhEj2Zp 9jUrThthe9UL8YBVFcTHVe3PC6saYcrmCEigZOTLWUlZHAL44aKLjAiL3ah8msUd+f/24rwxV/nJ eRR5IJMWaoupsZjzLM6jvJPREZ0TQPEOx8ZTZ9jjnM/zWpxfDyXGl/zPScb9UvHK/eeHAIeN1hSe NUVCRI9SEoFEYDoCKsFhhiguE8WbRMlnEXM9h2zm+c2C2trethpFwm7oFChlswpKHHqUqAtlGIXJ Yq++OzqRxV4CPU+XxR8lTlKc5GNRnXHigaZYz6v6nGQ6oUUJ0xLgI6IgGY+hxKBjKE0a06zYbLTt laCGsSgdKiQDlqiwRsFbjpA1RTW6Rw85vm0prN0Snit9nyioolfKzYumiZKmLA4B3j/dyzlg5i2e k6j4w0mjlKq5wxyHImoeG2W4mEMspJwCqoxxFPjZpYA4tqgQ2qXtzT+8fIyoeRpDXUw8+6jC+oNF lH7emOXx5o8ALzX6LqqoUsDuX0oikAiMRkB5bYVu6J/ROsOWGAWzOGhRWM3hHFWc5ykbA4FqFOFu orAtxigCE9qQHBGGDouccmzxVZtdOUPhf0JRQKuiaKAGTCoxGLQBOUXyPpYivG3GQRlFrYvuxHFM /1NeUf1526VhtDi0KXO8MiJw7q2qMBQxdKAoYby4I4/ey7EpDO4XTz5P+yTDyPYUUc+rZ4BSu6Uq cMGKosxgTK/9PJ+K+R1LtEaJeHxtFYNK4Y3q2EHV6+fJdc/qmTKfmO+0OhhH6+PFNFcyiDJKPb/7 tl6PhG3x6U9/uj57aRit17uc17VUBETEo0Q25zqh+0nlmFTJrnteziltN+gI9OOcn5d6V9bO/nMx iuJyLfA4oBSH7bfffjOPJEWQYkE5FbGZ5K2UsE65FtHBlVyK4Kai2chjGqegSOijUBtXcreXgvb/ 7SsBnszinZn1zCY9eWIKd7i/04TCiirJaE/a2jS0Nu735irGj+bS8tdCOI84acLR00dIBFBvLnOh 8vCjaBeewaABiyKNyoPbuMjnlU9CQN4ZhyLKaL/VQSKXCCQC/4cA5pLelPLzzMcKitEThog8e025 pZakPjgEsfWzzVyNovUDS17JPBDgaWEAo4gtl1AShLZx7dE0hxg6OPqKgEg4n1RcYbnGnMddGwgw hvRIYxgFDUP1QcbSqOdGZMizLhqpR9G44i1yG0VUbTutYt7aQCpHuZIIlLL/Na8W7T0Tq1cS+TzX WkEA+0dUFY1OPzpVPRX7kmsuT4jzChvJe4QRYH4XHfITk0RVXP3cVH40n6esHgQ4FbFs9JDCSPK7 eVAKkP8tNaqXRtHqudfrbiSUPkYR42i5pPScqqW0efa9EHI90CC9KONEQQhKq/y2cc1Vl2u8edy1 gwBqpkIyItYWVvQlTVo9O31hQHneRZs97+MMInx3HcsVe0ErTUkEZkUg8tWUKuYQyvywWRHM7dcz AgwgjdsxVLoRfe1iFJqRTmE+N0dToBXCoVQr1COyxJiSSoJVhJKfsvoQkJ/LuPVh1GKWYYTJ1S39 KGuBN6wvjLVZJY2iWRHL7QcjsBJGEa/pIx7xiE3GpCfR4YcfPpF2KZ9DnyLRovS2Dr6lG2ZDXkPP EE+i59jiyQBH0SzNpzfBAc3CNmgWcon6XdC7G6PUKZ/qmR3VVmAWgC0IFvRRYtHoF2wYty3jj/Ni HjQRY2IYjqssagGLanyzXGtuuykCChiZ+xjpmV+UT0ci8L8IyGlHeZOry/EklYORw7ElCsQQ4kwQ MTJPm6fMe+ZiqR/YJvoYKq6QsjYQsOZY71AkGbulmXqNAlrTUIwVa5ul19vZi1fzGSxrD4hmpksR i6t+LvI8/N7nylukNYlVmc75Zq09P25sQHFcFag85P0FGafU9xLwfIRH9cmhnIxTFHh+KUT9njZL wWej7cvr4h7f8IY3XLZLp6iqCsZbKikSvcmExksw6d7xAqmYaHw8CymJQCBg8RQN4pFHv1CUQzGP q171qps1ejYJK6bgWRMhmpQfZF7USDjonotB3Bwnp0ljY7x3xUwYcJ7naLyN7sFLahs0EiW43/zm N9cKZuY0C0RQDBh0Gg1//etfr5Grpc7JKqTpA8fDCq8upo95zGNqPox1Jh0Ri7n7/7eP++2eWUtV Q1zqfVvaaHLvRGDLI2BulM9pHmMUoSnL3WQYmXMwSnxHUTZPh0FEdxBlMOebs7IB6pa/l7OMgFFr fbYGK1plPtQGiAEcVEgG784777ywRk46/tlmOfmkbS32+q7c8pa3rHkdEtoOOOCAugiGWLyVFJVc LNw1D2HQedjxP30oxRSBKH/La8l7u++++za3utWtmlvf+tb1p07hiiuMEgaTl4onLmX1IuAZUjBB qFv/Ac+eSjH+9gJMEgnwV77ylasXifc6JRGAAEPI4ujZEtXpV6rsomQRZnxw8FiMJ1E27ceAkft2 xStecVFgc+xIsFdZyUKgAA0Pp2ffQs5LSnCuzbs+3gORhN12260qASKjjBYUUuI60QJPOeWURY2p v5N+UbjdmsSah+MceuDJz1JNdFIkbS6D2AAHcf8peO5bt+zwBrj0vMREYDMEzGNaXJjn6AGveMUr agl78yJnjHlnXK6J90e5bnP90Op0eQtWPwJXucpVqg0ipcLa95rXvKYaytNat8zFKEJFkseBk0k5 UN1LcjKvpIfyfe97X0WQN0uISxRmHp4t9Cc9hliIwp76DIkQUFQAQHhN8Uh5CrwocgSMj8EzqlpZ VI/6wAc+sPrv+gYfIYXwQQ96UL2XGgjr9yOBfWiZbcaxCVHEKCUREDURGfL8MIwmFeHQwwJ1iTcK dW5SewHIes5Eisw5iy35r+0BJ5D5S+RHwQdRoDe84Q01cVjPI+K9wK1moDCgbMdjKsIkn0nESKER QrnmNZ1X5Ea0ijHJUQUf7xaj7d3vfncdN6fUPGh6+bQ21Si29qGLpCQCGxUBSi59zxxI/zM3MnDo pPKGx7GB4BXVaLGYKM85N62/pwgzQhsDAROsIusQO2SczMUoUgFM+PHggw+uXbedXKUPD6q/o7Ei Q4hCsFiloH8RvAMS5S26d7nLXSoX1O8UFQaQB57nF72OceZ7ESL0FT8ZcV3hPVVGGsUueKbr7xFZ P1dE8UOZC7nuda9b7x1ayRARZaKk6q81r8jlkPPmNqsPAe8++huPEsNoUtRHsQS8dTQM+wwxKHCc zUdLaS+g75soiwiQ5zySgHnERAwe97jHVWAjl2iUR0zUCLU5+nfYfprnbNa7BUPUPbl9FBMl82OO nvVYuf14BKxfciOGzneJZSKwHhHQpPULX/hCjRKJptM/5RNNc1TBQpluzb8xTDKCvR6fjv+7Jgaz ip2chhzpbJZRMhejCKVDXgaaWjygUd0D7933ZKgHf+itQdGz+HYVGN5engEvBa4oZYcHQa6T8CrF gtWoX1JX8E4ZdRQKVA8vVLcD/dAx5XZbDoFLX/rSlROs5PZQMYFSENPbOhSx9beduYohxOs+zSAS dZZDdMlLXrL+7Brlk5ARHWd8LGXh5czRgNDcJUKK4mvOQl3maOo6ecx9DH2UOnxqz7jkfPQ5ZcDN j8sxJwcGsERd+Na3vlUjUSL6KfNFwOIuMoeRkZIIbEQEeP6xQ6LKGCf8kH6FsBJ1pys89KEPrdXK UtY/AtZrFEk0dgwKOZl9mYtRdM1rXrM+mJRStAz8zCc84QlVwdA0daWE5ccwEzLFmycUCAqBaMC3 v/3t+vIovPDABz6wVh8jKHbGTPyk8PCmTgq7rtQ15XmGI0BJUIITtWnoc8fTimb0qU99arNqXcPP nFuuVQQYROYMBoXoz6SozxlnnFGNEB5J9OBZIt5hFI0r1T0UP/mavFzmKQUSJJaa3OXRSSoNcR3m PXOh6BRFAV1UFSbUQFHVcRJUPNEdpW37HzRlY4DHpGNwWFE2GGVoyynzR4DzjiNw3g7H+Y80j5gI zBcB0XfUYes+qjM2EPbHEKEXmjcxjeivKRsHAc8Lh6K1GJWuX3Z9yUYRQ4SRgbeHviG5NhZpPHoe zZNPPrkiPi6PCL3Ow3n961+/Jo/2P3vvvXdNnptEE+CRFOGRNC+nKKpAoZbgszPWjAuVgzHEk4lf z8um9C6vAXod5cWxeHV9p+gC+l3K2kDg6le/elVwZ8kJEy0SKepSitbG1eYol4IAGpxoD/75tKiP Z4MhxICWKzOLQWSM5hKR5yFUu1HXZN5C+RX54e3aY4896pyooMGLXvSimreJGkBM+qJEIkIi9eZk OUV+mgvl+0wS87YcTR3hR31cvzl2nOPBua0FX/rSlyq/H1efEadSZMp8EbCmWtTnTYGc7yjzaInA fBHgzKLQmus4um92s5sNNojsa15UpdacmrLxEPDcSLmRXmNN7MqSjSIRIt7Ik046qR5XnofKXv5H icD1POyww+p345rMmdhFZRgqlIb+R9UQHrFR+1sQKASKPaCEvPGNb9ykS7z9GDVdmgtAKM4MOgs3 jyZqCcOMF1g+lH1QVSgfokwpawMByqpyjBq0DTVyVMviSVeFK5WLtXGflzpKNDgFEjhzRLUnRYVF mEWRlPrEPZ/VIDJWBtFSvPkiLqgijDf5RF1xLY7fneNEus1xnFLmNfQ1/RomVdOLY1Iy5ImK8ODo 9z/eKzz8UaX2jQNWijqY960DolgiXH7qFJ8yXwSyeet88cyjrW4EMHtEq+lo5jOOUJ8hwmlO31OV E1soZeMigMquYramvt1K1Es2iix2HjDNCHHbLdDoS6effnq15C3MEm4JpYDS2Vc8PdjCoLz7Fs3+ x/95SvulbHk0u6VeRZhEnYwBpYDwBu+///41IRrdw9+MHONjKapKJ4LEiypihCrC46rQAiUChWQp ydEb95Hbclcussg4R4kbImFIffGLX9xM4Ryyf26zthCg1JsPGMIcN+MajboqBhHjCS0zkjQXc7Uc P0upuGnRpwiIlnP+yKc094oWqbyISy/yTeRFmhtFp3jCJok5WSUeOZUh4X3Fux73EYXq46blgjEo cqNgjcg7MZeaWzEB5JcqFNFvLLsYTHOfRCAR2HgIKOBlXpM/bM5BCx4i9E4RIvOdOdM8Zx6iM6Ie j5qTGGC+pzf6YEVxSo0qzGQsjjOPok3G4jzj8gWNKXTcIdee24xGQPEFrVkEd0KWbBTxtIqoKLTA i0khpUAovap5p+IGEm5jsfbARNfzpd4oJWjRQiTLKZ6gUzHlAUfU38611157VcNGRIjRpBs9Oofx 8VziFeKi8qTi6OMaWsx5PL10vKwUgJS1gwCDSDjdPUd/HCLutWpi73nPe4ZsntusUQQ4Q+Q6igDr X+FZGSfoYeY0xVksolvaI8/w0WfBfIpDb5H3zCqBje4WhRaMEy2E02daVEt0CZ1OOfulikWc0vD8 5z+/Osm6witnnTC36h+SlOSlop37JwIbDwHOcb0FJctLdeDYmtYfLlCiL8olEsk273GEmyM5a+iF fmdwdZPvMZ1ExOm0tvFTPiaHlPms63SSomGt0I9uqcIo0k5B781+yxBj5AyjX6csHYEb3OAG1YmI XUS2KgtrixJicWUkLFYs0LyqEnlZ4ugeqBPdikisblEgnkM3dak14VE8VJVzHHSREGMRffLghtJj wVa2NrobsxDHCVqdqJf8AZGklMUhwMPOO84rv9LCayOKSDkcyht2z3kMnvvc51YKaMr6QkCURW6L RbCvtPevVI6ZbS1yykovJcrj2HoMyVXkqVyvEvTAacYjhxMv7VIxXa84znJdGuIylBWygGlKIrBe EUAfFok2H2+33XbV4R4U6GnXjDUigi0fEg1awRxGjIi7wlreHQ4dfd/M+eZpDvMPf/jD1WGE7SQi FRWJUYrpCnI60a/NeSL5xiZ3koG1VBENwnLinJP3wun/lre8pVKifUTjh5QdX+o4NsL+ngftKmqV VEZRSYptSzUhv6YkAnNDoHjk2zJpze14sx6oTHpt8fC3xfMzaNfi9WlLFLEtHppB2+dGaweBkjPY lpLWbTFO2qK8Txz4qaee2pbFsi2LaFs8dnO5SMcqC+hcjpUHSQQCgZK71RaGQ1uUtQQlEVi3CBTn d1uizG2J7tRrtEbTL0rEeeo1FwdXW9hAbWEU1W2L8dMWg6ctkffN9i1GR1vSJtqSZ1K/K473tjhv 2mLwbLZtUaDb4jxtC/ugfmeOLwZEW6JZU8c0dANjLdGpdt99921LQKEtwYv6vhen79BD5HYDECh1 CdqSA9sW+mO7ZPrcRrAi8xrXJgLC3aKWimgMEYU+UC/R7oTmU9YHAu6/pH8ev4c85CETIxSoXeho 6LX6V0yLeqwPhPIqEoFEIBFYnQigNmFvXP7yl6+efMUS5I3L9Z5GDxZt0ZsNBU5UiGARod9hNinM hRUg3xxlTbqEgktDCjdgIaEBL2c/SyXGVfDEhrIeodOJkA3tj7c67+jqG5X0H0Xb5I2lUbT67k+O aE4ImPzkuMk5Q90cInKRbCsZPGXtI6CyDJoBI8dCOEnQMw455JBKt4w8yLWPQF5BIpAIJAJrEwFp EfIlOaei5QCjSC6PvMpJYjsGhF6E6GYhjBmOL9Q7tDrUKbQ31Do5S84VVFQUX79zrKlyjMb2rne9 q1KrtXFB0Ue7Wk7R/1M6CoVd7vPQHKrlHNN6O7acVwYuA3zJRhEreUgloaHbLQfYJXpWL9bH7ykb AwGTm/wRE2i35OKkqzfRyoWjTE+r3LUxUFy7V6nKJA9joc39L1d4gkhmZTzhguNxr1bhzZJgK0+P kafxrGe1W7ggFAkLN8VgHuL4Eojx50XbcO/1++iKtgi8mUrdxocyIs+0K/5W5ILhScHQLDYlEUgE EoE+AqIkWgPol4bJQRTQUgyhm6/e34++qcG0+VKRnMhfp6tGs2NVPBUtUKxL8R3GjbwjPdjoioQO YV8tBhTi8jHHKchkblO0a1JuvHy/7nzY/93xrFGTKtbJRzX3YjooJ67QRMp8EdD2hzOczrdko+it b31rfTg8gCzZvmg2iLriYZi1348EM97bpQrFgFKkIt1QJYFioTBDVKRY6hhy/y2DAC+LBEUeoKEi zC7srkR3ytpEwMLBw8jI0XdskjAyJPCiTuhbsFrlV7/6VTVKeDU1oDa38lZG4m0YKRQClYsspvMo D4uCqhkrBYDxyGvKgDSndhtqM4q0YUBHUeWJI8LPMHoUYqBc2E8k1r6UHUUvxpWeXa33IseVCCQC y4sAGpviR+YeNLIQDhpz0gUveMGxAzDPcL6YK7uRFUaS4gj3ve99674MGowSOoJ51NpPX2XMEEYU XdA+enFaK/xUgEFlUsUYJgkavnnQWMx3/Y+5lNE3zlmvmAPHFweY3xWJMM7uvLu8d2FjHJ3xa32y di7ZKHJTLcDClKpudKNGrG1WuBKtyh+OMprGQa56GI8tPuhSxQOn8pPP0AaK8kpUHBna62apY8z9 lwcB4W8lFymUQ3OLNK+Uj2QCNImmrC0ELFrmDaWmhxhEL3rRi+pcM23bLY2CHmrmUZ5FDiblYhkp qCAWadWPYqGnCPjMIydKlU8RHd5UTirOAnO9fk8ql1IaKCreFUpIKVRRxyY/y/baIhCVQq0F+Pre RdvY3zXpRZeSCCQCiQAEGBLmBfPyVa5ylU1Aoc/R48bNbRwujClz0W677bbJvttss01zk5vcpFLq OZhUnKNr+sgx4kyzj2rMIXRarWf0s9HKQVXiacZQ7Kvdi3mQPmne7H9cp9Leo6rIMQr1dZNHxCFl 7CJF5nXtGbSXSJkPAmGU0heXbBTVgxQrq1THqAZE1/DhJfSgCfvhZY56iDW7sp+oUPch5AHlcdRn hpLT7TejHCJPqYdtHPVC6W0LsuNKxuNV6CenUZQpvs4vMhDiBVE63PcsfA905KT46W/jc+y+kSX8 xstgjCmrAwETGU+TSWaoKL9J6TvttNOG7pLbrQIEzAuMB7QEtLlJYvFkEIlcRKPRVXAJY4fAWDff Mj5i3vE376bFXKSLDHX8DL1WFFS4djHyTmnsqn2B85n3zLmUCc4w82rfm6nMvcRmhpHIkGNaI4xb /4+URCARSAR++tOf1nmZTqmtyigx742KrphPOOk5xEa1U7EfxhAHDx2P41uvI4n2nGIiBaJMcndI tHoZQqUPCvPQ/OVxd9p1mc9Fp+REM4SiUfbFLnax5g1veEPVpdH4fvCDH+QDM2cElmwUsaIlrsnD YETwEoacfPLJdREX8hOm7D7EOKG6nHsoWcKUUJY748SDyBvqJ4PFy0GBEenRXNWLwtCK5Ol+vgij 5K53vWs97n777Vf57wwdhpmxGidOvv3jOLZTA56wwFFPiHr1KDX6HEm0s52x6rNkHPin3c7CxsgT gU6YsjoQ8Ax6hjxbQ40cRpRn+oQTTsg8tNVxG6eOwr3yvjKIpnU5ZyBr6uzdxi1fC4LyITnYfGYe 5AkVieecUYmJB5PMO29S82rH7vYVMi9zNslb2nrrravHlUNM7w9Gzj777FPnQfNj0PrOd77zVU+r vD1zNvxFiBxbr5CURCAR2NgIcKygPSssMGtuJ8e5OYWDZZwxBV26KNoux7YiC+ZV50KhNrd2K88x mMxxpUz31BuDkSJq349sTd2xt4H5W5oHWrEoUj8qpQqftBX6LbxS5ovAko0iw2G8uFEaoloUCc6n Bc/CuPPOO29StpBnkfUrWQ1fEjee9Ssq86xnPasaLh5EiXX2R7O48Y1vXC34ePBti7InioSCETQn x8JBxRNVKcRDhVcvIsW6dmwhTIlrFm9RHwoSS5zljdZxxStesR6DeHkYQ45hjF5WHgb7MbwYb699 7WsX7goM5CIJd6asHgTQ4YSoh3aB9qwo48lAzqjf6rmP40biXdfA0kIyaUG0v/dXQi1u9lqIEMU1 i3QrUGDu5JxRVcmzaf4zb3L8TBIeTE4rDiaeyP7Hu4GON60cvdwhnlYGJecQ4Ri61KUuVedrc6fi D+6HNSAcXN2xaZCo8ShHlHMeeOCBWXBh9b9mOcJEYNkQ4GBHAWYQmA/oakOFfkYfpJ/JXx8iIt0c YiqOMmZUnu1XdjPHcuzQH6YJ5788I1GnpQjdg8Fjrh/XRJ6OKoiwVANsKeNcr/vOxShi5Fiwcccp kaJAqEcMGIoly7yba8RwwRdlyDB4GBuMG1Q41UAskhLfeCBRRoRB/fTAeVAs3hZciWcUAYt4UEYY KDyWjBmGFOvd4s3bKTTq5fHASQgWErW98wtDehkZczyg8WD7yQvrp3N68Blnxhn5Rt0kYd7Q6173 uptwUtfrw7OWrkuU0KTH6OXVHiImHl7sMPSH7JPbrDwC8ltUKaKMT/PoiSZ59x/2sIfVSPFaEV5N JWNRSyzUjDmRIgaHedE18XqSKCfbvzYRcgm7rnvcBxWPQTNKzOvmS/OuUrSRrGxb86z/M5bM+eZs pc0pE+Z6+UTWgHBecUKhNPPq2peROu68a+Ue5TgTgURg8QiYw0WQKfuTiiiMOgNmD12QM5remJII LBaBuRhFTs7gQI1goKDNMRhY+hbwfslu21igeRct9hJ5eRQtlBZI3EwPuP26+/IqMooYTxZduQAS 4FjWka9EaRB+VGIvRIIao83/GTwoVKJCFmHGDgof3nyUX7RfLN7BKcWTR11Bz9luu+2aG93oRgu0 m0klGRd7Y3K/+SPgHqMADa1o6Flh6DPwk7s7//sxjyNyUFDGRUvwrycJ45Yzg0KPNruWxNyleIR8 nD5n3XxkvpwW0UTDEDkXKRP97n/8X/ReA+O+iCrJ1RJtZYD1I2wcXbyuEpy7Yp6XZ6R8LmeV/aIg RGxnHeC1HecVXUv3KceaCCQCsyOAuSPaz7GlYuwQCZ3vmGOOqfnndMPs4TMEudxmEgJzM4os1Iwi nlrGg6iKcriaIvXLwqKYyfHghcfhjEUa9cWiSXllGMWHwcVIoRRY/FHucOrx0P1N0Q2+u3wCngLH xbdkQFnQLciMF4aa8syiUZQjPTdQOYyRAdStZ981jiQN80aIAvHMMqSiYkjXMytiJeIUxlQ+fqsH Ac8F77Wcs6ElgHm6UTFFGFJWFwI8iwwinsVp9AZULUn+aBkihmtNzKsocqIu5kjXLDLkekRszGFo dYQjKSoqdfOLPP/y5Dh0RHNGfRiWfQ675GXzLQOUc4BjyBwocsXAMU9TZHh3jUmTRd+jJ8rFtB7I I2L0cELZR++Q2Ebk/6lPfWqlX6ckAonAxkJAMS452IojmJ+GCH2P41sVTo4cTm703cUI3XVclVn6 HN1wSC/OWc/tuOOK4phT6ZHG5TNJpzTXz7u4zqzXsp62X7JRFBU3/PSgor0JgfJaMiBIcN3Dw2mB tMCLDCktKDeHAaX3hQeA4cKYogjI96EEnHnmmc2Tn/zkejz0N4YTo4a3gDcSPYMwttBKeEQt8PIL RK0YKcZhnDyaIgAoNI7DwEH7c16FEgjKnJdMbpPF36IvNOsFdF0UC0oWz4ReRvFSyXVC21M9JWX1 IYCuQ1EcGi2iSIpemrjlpaVseQTcPwUGlFWlWI+KbHRHySDyEU3y3q5V4QlVGtvc5Pk1FymyoMoe J1RQfs3Dyseai8dR6WbBgNEiv5MS4vycSpwEnFlozxZ3hpQxqOxk/lcinINJ4nPkeInWm+PNqeZr USVzsr4gDKhuIYdZxpfbJgKJwNpEQIoFCjB9TPnqoWIuER2S+iA9YppTrH9cawjHuMgUJxm90e/y LbuReLnjqMbWj3mJuZvuKv+S7mneRE0O0bcIForV0CV9OLCU5+4ab9IA6KbWNMcRaZtHX7p5Xeda Pc7ZSxW2Z6CwMUJGlTCcdmEsaPk6HirH8LF4epBUgPLw2oYX0TZKChI/3Uy0CgaLBDk3mAFkIWcw MT4stowVyqwHw8IvAmTR5y3lXUCPY7TIO7IvrymFQIRJDpBoEENMUhoFyngpuqxvxxddcixjMB5F I2zjRXNu23iAfUSHXA/DjFfUufxP/omfIlMWfFEz/9vIQpmi6Lhvq0U8jxQx0SKTzZBkToVClA92 393XlC2LAPqW+8dJ4j2fJBaziCZxgGwp0T4ATSwKEyxmHBxAqGicRZxJlAEUYnOQXMYQxohtREX9 f6nGhjlXpCiqNPkZH/M1g8k5zMM8vZxcxsZY8+50xdjMi5xgCt2Yv83dSx3jYvBcD/ugLVKiGJ7z 6Em1HjDJa1gbCFDwOUTMH3S/oWkIHNvKbptT5UCaS2YReiGnmvxH844UDPqoqLYouPSO0P04uTlx rPtL1WMYYhzpnOv026AJKlzD6WoeN4diJTEUMaFEzzFVRNn1T6IT03GlgHBAnXHGGVVvp5uItrk2 2+RcMMsT8b/sCjpFbRJcblRbLOS2AOrXlERgbgiUSact1Jm5HW9eBypGa1s8023xCg0+ZFGs20Lv bItna/A+ueF8ESgUgTpPFYOgLRHdqQcvFNq2LJptyR2cuu1yb1AKCbSl78RynyaPv8EQKJTGtjj1 2qIMbbArz8td6wgUNk1bKsW1hco+06WU1hptSb1oS+S8tSbMKoV11BZDoy1Om812LVXo6rELLa9+ V/Ld22I4taV9zKyn2Wz74jBvi8Oovq/dcZecqLao8G3JF637lNzXtvRJaovhM/ac1pPigNpkmxJt a4uh1ZYWCEse60Y7QImwtYVh1pZS5+2S6XOz2WO5dSKw5RHggdGLAP2ovPyDBsTzLgo4lHY36KC5 0WAEolyr/EA5KqK548Q9VSUNnUA0aShPffBgcsNEIBFIBBKBRSMgem8txdDB4plFUOZES+QuLibC jA2EJYLRoyiY9ItIA0HHRqFbDkYIJpG8dJU2u+M2HtEyESGCUYDBohIynPRP0kamKyLx2CuYA2jk UkbgGIXAZsEzt90UgTSK8onYkAjgMKso2J9sxoERPbNMmCarlJVDACXAwoAuoZ/EtD4QFh65iBY4 tNuURCARSAQSgdWBgD6OKGPSGlDCZhF5jBxjDIzF5kui0Mv5RkGW8yh9QqsCBWDkQ6rmaZt5C0qb 9JJuyXA5VVpKKDxjPJx/CtsEbU/uvbEao6a2kTOEFk0nkf+E9qdCrrQSukkWXVjanUujaGn45d5r FAGRBl4W5eCHTiK8S6rWmThTVgYBiwB+tQIoJf1xarlWXjjlXW07Ld9oZa5gPmeRN6LSkkV0VCUk hqPFkedTpc1Zxf5Do6bjjm1cvJYW+VkTfpejutOsGOT2iUAisLwIiM6Yo+UbzpqjY17H7jjggAPq 2o25MavEHMfwUXhHHg7nmWbYIjSKLcg3mlY9WN4PI0XFT01j+x//V5Rm0pzK8FE8QesPRXTkVDFy tLExDrlM8rLlD8lDco5+FVzGkcp7jEX7yHNXuCFl8Qgs2SiKcoHThuAB7vfXiH147C36Ch8MFclw XrBJi69zSkSb1ul91Dnt060I0t/Gd87POh8nvnP+Scfp70s50GuJgjNKUfjlL39Zy+LCy8fvKvN1 X2Ln629jrOPKTg7FfL1tp1gGBdLkNEQU8mAYUfwokSnLiwBKg0Rc1R0Lp3tqyVWePosIet16K++M RiGZXmEDPd36ogeTpGMfCaNDxRzDE6kk9lDnwCSjiDFqgTenD5HCf2+0YuA5TkkEEoH1iwCHoj5r imTNWhxBIQKUaEVcFEFYrC5Dryu5ndUQIihr6NWMNFEZ6ztDhQE2STSBV6jBx3rT/xx00EG1ofio OdWci8mgZ54Kc+ZfESSiAEPJs6rHhRNKnArHinyJAtmPoPx1nV/oeLYRPSt5MamfLOE1WrJRpJqG EtcsVOVh+8K7adGzjdLYffFwC6NSYpRrHSq4k/JCUGrGCataZY5Ze8x42JREHFVW28N4yCGHVC9H 9GViwTPSQhh3KDzyUGyjNLiHnPEyTrw8Hvi73/3u1cNt3CozdV9OL7QXFlYqOPlc7nKXq5X0hE9D jK+7jaiIKnyZD7Mp+p4flQUp0kM81SYeWHsGMlo09E1d3HbmBVQ5ZUf97Fcx6x418o1ESTz7FpP1 JuYUzg7zhKarnsEQDpQwlMxD45xPozA566yzaiTuC1/4wqLpKHFcHs9olD20+hGHBG+t+5ySCCQC 6xMB8zk9Sa4MfXDo/AANjhO6mLWX4u9Yi3XgoN1Z89HmVLDrOjc5sTmkRV+6FLdRd4RxxtHMMU33 6n/oeo7fp/j5v0p75j2RHbQ5hlCI69KHUyW6rtHDKESXY7QRTjLVm0sRoYV9HVOQgKG1WGrh+nz6 ZruqJRtF+hGhIKFM8PZ1F2SeAU1Ufafst/BkXyikasFT2oUAhSWHCE8kJSES5EbtQ5GgPAz1KlCu 1K5XfpaB0g+hemCFRV0P44Xhw+CR7+A6Q97ylrfUCYDhFE3JfC/cOi6c6iFXYlHpct4UiqDzM4Lg QigwIk8iHLwMPkK9to9S5/AXJYKnc/Ou+DAip+ViDMF9PW3DyOFZ98x1jcpJ1yi0zWgVGk9ZHgQs TqgDFkM/JxlE3icRIkr9kHyj5Rnx8h81EnP11NBTzSIZYjE0L2h5YDHvJx9b6CkVSnRbhE899dS6 K4XAAgxn74D9w4Hkb9Ej/5PUqzdRPzpqfkJn8T3vq3eI0tNVeND9zFHOLdJlDizVo+r5KQjuLzGX 4dQz8Myzkojx/C3wqCPWiK6Y45Q3d7yURCARWN0ImAO87yhrHCdDBduHAaNFiggKWaxBZN8o0KAd AEe1tjH0KR9tZESAjDWoffQpa0xfh2RcYY6M+4hARfQnrjWYD3RI86nG27e4xS1qnyTGngiP8dEt 5TT5GePClNDLTUSLmEu1mDHvmgcdh7HpOIIMiylAMfSerPftlmwUWQDdSDdGAl03GmKxtlC6gfiS /RvlgaPQ6B3EkPCg6UEyRKKmfXcBtmgzanR9t9CzrONFGHJMY2HMSMJnvfe9GY4pciPqpaqVSI6H 1YMYTb9cEyOR4oz6Q2F40pOeVA0eSf0UFMJA9PJF9IaBx/tgDHqP2J4iQ6kwJsIogqEeIc7tw4AT imZMESFWE4kxOoaX3za2NbGkbIqAiBzP0NCCC54JXhw0Rs3jUuaLgOdXtMezzsiZ9MxaHDkE3Af7 XOYyl6mDsYh5bySs4mPLR7LYUaxFlt1rkb5Z6LrzvcrZjxbOFJFnlAqNT+NaOU0YjkEZ7DpeROol 6ZqTzBG8jxbPUsq5zsnmOREev5svGTUMFPM5XFVqZPzwajKgwulFSUBBQRMRnTI3cr4wVhzDXG5/ i7U53Zjx+HlP999//zoPMuCiT5hxoImYFzmC8OTdH04I94/BxADrin2G9jaZHfHcIxFIBOaBgMg2 Sq9Kc5McXKPOddRRR1UqrmanQ3oKDhmveUZeEyd+9AbSW5POxHntZ+iqehjR4TiZlyrWNHOtucy8 SsxhDCCGYpyTTkIfprvRTfTPxMTipDKvEjiaS1XgM7fqYwRfBqTfUxaPwJKNItEVCxPDhoe3S9FC l3MTWbSjwqXoLjyerF8PH+NJ5GgUDW/aJfKUspAZFB4eH8efxWJGRQtDxnj7HgneU17a/ott4XYu UTM0EIYZD0JXvASUtAh3Uk7w72OhpwS8+MUv3iSUii7H4xANH0XeKCXCtrwN8HKM8Lw6nxcvImRe Gp2OlWtcDKbTMF8P35toTYKM2i4ladK1mSA1+RqV27EeMNlS12D+8DzzqDFyJk3uFHUOCYo3Pvel LnWphWF7570jnALmFtEEzgxVixgHjAg/vU9rTWAieuNaOD88s+ZcXk60EPNDzHmUCdQ48wjjET3Z vGE+9jsHlsWWsWIhFv3kmRR1Ng+6Fwwo3lT3RCPcyKEU+adAWIjhKaeJ44WDzJrgY8EXmRJJF+3x vbnTvoxUc5tFnUiepgD5Hk3G4o5m4v9yCNBUImJue/fbeB03JRFIBFYnAhxRcms4OmalNTNaOLHk KJrb5imME01O6YmiNuYvelI41uJcxmz8GCVLFfMsp3c0FNcyIj70QE7xkJ122ql52MMeVmlyGD8c 732jkBOL4VT6HNVAgLWOcZeyNASWbBQ5PQXlspe9bF1YQ8mncFA8LKgWvz71wqJpUZXXEUo/JUbI cZak2+BOWuxRaKLbvVArryOv6VDDiEKAYmbhH5Vj4ngUjf7D6QVzvTymjBJRhP45GY68qzzYpDQI a0466aTqgR0lPKkUGonVFBPCw03Z43mJHAA0P7jpbE4YbT6wR0EhFEfRJedL2RyB0iit3lPG7Cih VHaLdTCY0XrcI4ZwytIRoNyjM3ifRST61IPuGaITOieD5NiuQRTbWcxEfEVgOQm808pzc5xQtv2M vhBLH/3KHcG85Np+9rOf1WdPFAV25hPPZTdKxBHC2Od4kiPJ2BC5QZHzHeMktu86gODkuOYdhpHC Iowi3syYby3WonrXv/71F+Y6kSpeTWM033MycYq5r2gzjB7jDnYB1GKejfWB8sNoszY4P4MqHEnm 2ZREIBFYGwhwEHNu0AHNO7MI5ziDQYSoNCSdZddVu+1QPXTVXsAGGdhcjCILqgVLFQ+VolApKOYW a4qJhbQfdeHptNiit/AiCFFSVkR8WOaiH6IpqBbCjT74k/28JOe1wLOWeUvxM1n7IleRcObcFleW OJ6mz6TqIuPyftA9RkWQbM/oMRbK9ShKRxwzwp+OpUY/70FfcP4pBI7HkxqJeJQFRh+vAPoLA9TE QTl3fRQLETe0O+FXONqGgUTJpODMUglvg7wDC9VdeKJHlfn0TPMoaRoXyY/C7kLbJu+UpSHgnRbt 8d74Oc0gkofCOSBSNG7BpMCjrYqUMgYYEjyCqKgcCCgL86JjLO3qZ9ubAwqFztwR8wBHDhz6BRYY GCLWItnovqJC5lgYc7iYmxmYDJ7unMVjigonusSDai5RrMW5Y2GHJ/y6BRIYnpxG5kj4w1vkXkTb 75xd5l7zcTAHIm8z5jgRIds7Fo+q87vfzrvUkuGzIZ1bJwKJwGIRsI6iqNEJOWRnEfOzfG2OHNGc lERgJRGYi1FkwBRytCILrAiFD+5meA77F8Ugsqjy8oqeiK74WPApSYwWXkTRF8aVj9/HlTjsLthx LsePRVwEJ47j56x9NByTIkAB6SvODA3RBtfieinM/eNb5CknDJtxIhrByEELYcAxgLpGk5CqHAuf UGL8LoxqIoEBJQjFBr0rlD6GmL8Zj9l4dDT6FESK8qhoEYWQMscgQisSzubx9j+YRp7YSr646+Vc sKOwMzBFiCIPcNT1eT9sIxnfffCuTRI0MJFWVC3vJ4PAvVQxUy7MOCN4NWIbkRTzq9wghgMqhvwf PTbQJiKaGduabxg4jAlznnlB93SRY88vB4p5xDxt/hBBMpdxYjGwRKI4VRhTotTml8jD4sQSUeK0 0ReDA8ZYGDXmbeeMcbhfnAcvfelLqyFHInE5miSa753D9TGYzLGoMyJG7rXj+S4MI+OUmJwVNVfj 05pj2sgIeP85ERWkoq9xbnAocuSinPt4t0fpYHRBdGcFrNDaUxKBlUZgyUZRLFIWLAYDKhxPpIWS 0kjJiYU0tlWQAQWMgmMhDqrXhz/84frC4JFHVSHboXn4eKkiVyeOZfFGHcGtROmwuDKuRKosxBZm hhFvo2S/OJaQ7iTxMvc9k/KClMFGWUNJYbxZyEW9RKZ4ZikYvBsoH5KcjYXi7LooZFEBzrh8Fxx9 kTGUHmNUOAGOFn6TRBgyCleImKGh+L+InOthLCqmwPihuKPTwZbCaYySyuVD2XfWRMelPJCUq265 yaUca5Z93TfPHMUqqG/Tfrp3jF7PI1zdD8qcD3x55lXDcm9gTJH3bHoOUBlTZkfA8ylZn/FiEZ3U RTwq0qGpyocZSn2Tf+O9M5+IvMprEVWl0KOWiSZxRHgXV7MwGiXUhqODkcchoolhNKl1fYyeiEab 90ThUVAYgOZVPHXKiLnAdgws87Xf5eeI3KO8MCblC7k/5li5Qea2qHrnnnEOoExHrhIjy1hE+hg9 0dZAlEjlJDmm5iY5Qoww7yn6tHdJ7gGaHceP6JD5V4EI3maOMmsJwy7ukwgVg48xlpIIJAKrBwHv b1S45FDhhDJvW4/pQpxU1sy+c9kaLa+ajmKuWg5xDnqkMSoC1tfx/M2xY00wt0zqQzlqfOaoxTSV 7R/LPIsZFQV1hmDBGDU/ztKSYchxN9o2W5WHoMX3trhaMGcV+wh1MkBY9zyBES6N/4l4KCSAhmFx 8ztKkoiIhbYvHlZeAt5IC/MokXxn8RaRkoTmQbaAM7goB6hzhHHGgxnlHIdcn6IJuPIW3X6vIudj cERukJeIMq1SFoOJyHWgbEVxA9uI1Fj0Y1wMFdeIXoLW5hO5FDy64RVlPOl3hM7id9dMyUBTcVzK PAOP0kJxokygErpuE5F9YCx6BcuVqkDnvPKl0CEpWKOMzHH3gjJnfxjMSpuJfRlFJomhPF50Rt5z RrVoHgO478kKr7rny6Tp+TaBizJ5xqMC4JBnbKNvE0n+aF/elUl9ISxMCi+4p96TUZTTSXiKElPc KePodCGORxlnHHlXGBrez2kRqMXcO3OkPB2l8RcjFlvGuucSNc37wTAQVTG3cEBEnw0GS/9ZtFAz 5m2PXtx/LzgBGP+OZR7x7JuHRaCiUpJ3mZOLcRZiDkJldP8YNN4h+9on8o9UpPM/99p2HDX+9u4Y h/fUsR3LOmQ/1+tY5iv320Jv/P5mwNnfcV2n825U4YXnSDPfZ2+SjfoUrJ7rph/Rt+g61kcObw5j Di9lrrGJzEGcJtbR7jPLWWVOM9d355hR+mHof6PySSehwWjgKDN30KtEobutSuilWAQc9OYVedhD dSYReIYMQzDy5Bd7ZzjRpYM4lrzZIRIV9eh/K+n8HjK21b4NXROThI6wZKOIAUHBV/nCYuyh4223 sEqu85P30cPlb4ul7ykek6hkvIoWQg2qRuXooE0IwTIsYlH0olFw0D5UC/HyebgoOrP06GHwoI3w UAKpL6IHokAUOwoGpbj/EovyiBYxjIyPUdJdvJ3Dw8vTypgU5Yp8lW5/JL/zdKPIhCIDT7hTjBhv YYx1x2lyEcEyDrxe55mlYdpSH2JKC6PIWBlts/QWsG14xilKs+QS2FZ0Krzqs+zrOUPJgTlFPWhA sIiyxe6R59ezR4k2wVJMKNuzJpMuFeO1ur8FiXHj3WGoTzKIGDSivCYtEY1Ji+UkPCj8nkkRplGG Mu8lr5z7q0CAe6l4zLxkqUbRvMaRx1lfCKRRtL7u51q+GmwUc7VoPP2LfsQ44gi3ttJxODg4u/v6 mOfYusq5jPY7SThrFmsUcbbQxUKvol86VginFYOIcRR9K6MHZGxDL7WW9Kne8lXRiQUGMEq6PeM4 pZyTXjOujQBdhWPLcel3jEiOcs7+EMdwLMfuMivovgqFcfJhL2G2dNfVaOcyip4eeaUcYBu1xUHX KKJwtkV5bQsVwq8picDcECgvdFuS4ed2vJU4UJkM2xLJbIvXZ5PTFS99W6J1baE4tsWTtcn3JXJX 9ymRh5UY4po+R3EStGXBaEuif1sm+InXUgyZtlC66qdM6ity3YV225ZKlm2hb7Sl0EBbjN+5nLd4 8driRZzLsfIgiUAgUKhAbaEZtsVBlqAkAlsMgeLkbQvrpS3On03GUBgUbWHctMWIaM3nJYrUFhp6 WwyItjig6rYlj7euCcXRPWj81uiSU9kW42jQ9t2NSpS6Lc64tjhq22IMtcWZ2RZDpG5SjIM6jsJ+ aosTui1R67Y4wBd2Lw7m1jxeHNFticTU7YohWL8vTvy2RK3bYry0JZLfFkd561zFAdgWB2BbHNtt MQjruIvzrS2O303GXpz5baE0t8Vx3pbIUFuMxLZQpdtiZNbtijHXlr6WbYlu1eOUiFvFsDCG6veF CdGWqFtbHH5tYQZhf9VzFOZLW1hSbYl2tSUgUcdcqHmbnLsYXfWYhdI4M57rZQfPp+e0OMXbJecU rWXPRo59eRHgael3gl7eMy796Cg+ohFytSJRHDWTF4iHCtdZ/ks3yikS51ozt2gy/vL8eA7hxTs3 ySslwok6AFf7TCrAsPS7/n9HEL0yNlEp+TkS/Z1fZLgbwZ3nOfNYiUAikAisVQRQ+dHQUF/7leZE ieREK7SA6iqNwfop2oIu5yM1wP/lea6ERA81DCJru7mdYH9g9qDViZp02S0iLZgvaPOK3KBaiS6g y8n1xoBS5ZTYX/4x1oFcd/RWuZRoeRgnKirLaQrBZpKGYlz2C4aTvyM/1BokaiQHU+RIhAvm/k9g J6dTdEikThVmxczgSgfDyJCzjj0kZQNdOQTTaa22qFiO5yWNouVANY+5phG43e1uV/M/KPHEZC5R 3CQ0qrM1WiTetMILs9AE1zRIMw4enihzipBMM4jkzjCIFBXAL59UonvGYQze3D21wFvA0VMtYsaE WhGFYwYfLDdMBBKBRGAdIkBxRw1G+1KopV9YiTOLQUAxj6IFUicYFVICFGuRk8jh1O9luZxwGY+1 SP52VLD0U/61dAZzfImCLFCtGS5yuaUroMwzgIwfRVCPTAYJY4QwlFwzI1HhCIVk0NmsY6jbcipR DQljK4pLyLln+DCeUOfoElE0QbEcxiOHIgq4tVHRCCkatmMkWacYc/JnGXyK3ihygcpnfOh2tkUV l0MagipunbVNStOsqFHkIRsl/j9riWwvkAd7khLqO8cd1Yh1yM2f9pLyFEyTIdv0jzFpgojrdl0+ wQcdh20ce9q1TLuOjfS9KJAoAV4vXEWOpvGco+dLNJrcSHhNu1aeNJO9iVpBkEnCIOIJU0zARL2l i1d4DiwqxmJBlLPIUNJzZyXL28PQosy4HBV9tUBaaBlvUeClj7OFXVEdnsuhIrezWzRm1H7GxGBc THlseQS8r6OEsqSACSNa8na3J1Js73lRJYoXVxEaOYzThKLhPvKyGrdk8L6hS0E58MAD6/PqQ9Hh baUEhdhPDoGCPLbRW87vcmxTEoGNgID3xLxD8R83VzMyKPUU9hC6i/VVJEMhATnnDKWI2iw3dtHa wLpu3mKcOLcCBa4jWAGRh62Al23MMQwQ672Kvww9leJCDzNukTNiDfMdZyDGgTk82BHRiFp+Ohww VLp98+SzdntiyiPCVnF+czL8HL9rhJrX6LxxflEjc6u1S468aq/2YRxt1NyhIc/Vko0iyoHFQHJZ 1/qMk0tYk7xmURmlMHr4vFDCf6pnDBVlqb1srN5xQglgcSuhPYtYIC1y+oD0xcOvpKPEelY774By t12jzoPJo+w71yXyoKjCNCWKcgELypdxU766Co5zGJeohDCqj8gFzwVq1yhxTthn6drhT4DJiRdI qFkFrCEicZRniKKU0aL/Q0xpVsmzKAUWwEnVAHnQorqcn5JSV4tY0FUDssCgT1C+vZ/e61HK+rzH bY5RRhsdpW9EMNzNSYrOmHMssn1RAAclUGlyydDT5qLYn/Gg0WuU4h51XRZ7x6Q4DBVj5vmkWIiw 9sXC7zteVO+hcXsnuwaduRHdhFJlnIVzXzFA1RknjCjrlXlUYQ1rA4XN/2L9YmDyfqvo5tx6l8HU h2IUoiiL8VHo4nvbO0dKIrDeEVBdjrLNETCuiXZgQAnvzv3eLe+JSsSiLuZ7eo3IBmfFEOfGUvAN JzKHl3WHIw6VTsEwEmt4bEfXsx6F4eZ9NxepTmy8jJOIhAXlzVygrYCIVDQOdz4SWDDCGFnm0O7c Ym4zBgaMMaDtK1CkYjM92dojqjWqETbDh9Bfjc/cTD83j9MXGU8rWXRrKfdpS+y7ZKOIoSME6qFm IHUVQtath583zo3k+esLo0ZVEjkEbtxQBcMDrNKGqlLjxCInz2OWRYpx4UHWaLBv5Hk4eS4pFx5I ZRcZSR5Y1xBiouBlZMSoCCJsykNrAR0nFnUvDDwYe15CeS0oPK6TUGQoHl4Uill8GEVdL0ycg8FJ iYO9ksMpwxFQWU6lHBP/UHGvKZ+TDPWhx1oP2/G8mZA9p9NK4uNfow3oQ2aRiYl9teHA+8ZhYRGl kJsjKOzmQA6gaRHbxV6PhUy0Fz6U+WgJ4HjmTHOF0rHhLeyfh7JhbDEXMOaGSHgiu17M2C8iVmG8 hvdz2nH1KBJ1MSaKQN/DzItrnjWncS4xSlwzZcO4Y43xO0+rudc2UU6fAygUDNdsnOH5tQ8jjILg 3WZ8ob9QNqxTtmcUOYcImUpOSu0y7h0/Kn2a251DfoA10Dvv45k3H6ckAusZAUYLx4HnnzEzi3Am 0GnQ7UTiiXddw3r6ijnOO0mhn3djdO919C90XpXozCvmb4ZKtEwxB9guGDbRIsY89PrXv74ag36G A8a+qHhKjFsPfO9vrBPzjLXN9bo+ogpeVNmlGzLMOM9Fxa1/5iUScywqHF0X48L2kRckKhQ6sKgX PdraJHqnVQwdhg7O2Y7SZ54zF3Z1Yk42kXY6dcqc6HMeCIoCj1nXs27x07OHl9jD0rdOPRQMBSVw 0T4shm7gEIkFuB8GRG+wSLnxUb531II+6hwWTA+cY9qnz4/1wHmAlJhmwOFu6tpsUuBxdD2oerbB IfWdPBSLPy+vRdXDT7xwvA1hKFpMcW0t6BZskwJPqoc7XiSeCGND2XBcH4mKjLR+2UgvtQhdeI23 RBPVIfdxtW7D8GTkuGddD86k8cYkREFbLuV4teLVH5dJvVQerD2qTOCTxMLH88VrxhMXnrbVfK3e Qwue+UK+mTkQvcG7u5wUSgq3xcu8GkJpZxzc+MY3rnNW/9njEBFJMkfzzIpe+3voc92/D66PQUiB ELGPcq9De4IxdMzfng8Oo34BC3M4ChqFxZzoedCPRD86ydAMaHOhuU3jbq0TvK+UKaWAeVTDMeF3 46RMEO80hYVDiyLm43uGGVxhx/kUJXuxBszN8DWOWMMoIz4ixJ4FxpNWELbJfkGr+c3NsS0VAQo9 vUO7Eor8LCJ6QtdTWGBUdEm+DGYLHYcOw1Fhrhoa2Z42FnodhzOnJ32Nk4vTjg4nShQOGmu56ws9 M3J1OK4ZhIwL6xZjR1EDYm4uFUvrvEBv0EqFAShXB2vJ/61zDJAwzuxnXnaNjBr4mMuULXd+RqN5 lT7I+U7HFlVipNHv7BPGjLVIxFsggN5orJxL5ktRLT3ozNeMz66ejgXg+3Sc//+nR0m9pZTkVsau PFhtMWba8mC1ZcFZqNJXLOa2LGS1/K5tlA/tSvG+teWBqaWOSXkR2qJotOWGTa30V7x4tfxheUjq tsolKl+o9GExEOqxirFQSxQWA2bq8Wyg5GFZsGuZRWUVnaMryi4qXdgvO6mkoetQKrIs6G1ZwNtC ydhk3+JVaIuR1hYaTP1/8ZQsjNPfSisWQ2mTfRxLicYSdar/V7KyKABtMZzqccqEUUs3KifYlWJc 1nuq/KJS63AqxucgDOa5UfF41HuwVkWZUfexTICDL8EzXaJ7bVGQBu+z3jYsUYu2KJ1tcQpMvbTi FGiLt7GWIS1Rjqnbr+YNSsSmzmVKbyvDqsxqWdjrkP3f+7hY8S55j8vi2t75zndeOFZxwlT8ihew 4m2eVQa3K85dIhxtcVLVfxejpi3GRFucQFOHUxwv9bwl96du6/z2dX/LAtwWI7aWsTXPluj61OPZ IMqre0dKlGmzUuXmNsdTcrYrxXNcx1IoqnWuVbLWu9aVUnGpblOUtvpvJXWV3p20BpTIUVui820x suo+1oCinNWyvUrgFmOrLcZPnUNjjoZl4f23xXCr5XutOUreWguU718pyZLcK4V0ngcC5jPlnosx UEtYzyLFmGgLvbctRtHg3eg8Japc5wjvtjWiGCNtMcbqHDCrKFOtBHdX19Iaohhdm7SIcJ2265fO dj5joG+OaylBl4sy37anj9m+K7YZVUa/23rC733dznG6/3Oe7t/Gq/R59944V/e4xtO9ftvaZyOX 9Z97SW4hRrQCXjvcScKTJ4mW95KlPCrRX/KZKBGePGHl8rrFMaZZ/b4Pzx2rWSiTJ1S0iTeAtVwe xIl5DN1zoM2x+lEjRo2XxS3S06eJ8A6isKC08KLwTvajYvYRaYrIkEiS8KtzEhSULmWIh5KVL8oW zbt4CHBNXR9PTVA+XHOEmXkghG+NRYRJngtJ7+WQp2nTbXieha15toeWFueBuvCFL1zpPBsxt0ju C9qDSELwp8chz8PFE2gOQKcaGtGd/U6uzB48ca5b5JanERbeQd4/88I8eNwiKyIm6CciNN5zkSLR a5Re9LluxMZ5RcBFXMxr9jMXeLb93zwtKoIexsPo43j9wjdR7SgqLYmGoxiL9uCpxzwbkXrHEVHq 0vziLkR59XHvlPGMmrfjuszNIvKjSqTHNlG1SQTdmEdFK53DGmQulVckeZqYo1ER5QKYW0X65SBZ Y0TvCU8rr7K8Tnlc8plQRd1zEfw4/8o8eXmWRGBlEKB70IHQvGZhn6BrWRe8U5G3M2TEotoYOSK7 9EnvlsII1tbFFAswP4j6dHUtxzF3do8nWmO7UdFvc6F5eNz56XLddAa6X7+Cqm1G6WTd1hN+7zc2 d5zu/5yn+7fxmpe698a5usc1nu7129Y+qSP+7xO55JwiB7FAuTnoDkJxQp0MA5QD1AQPUb8CHHoD pR6NDM/d4opu5m8UMjzJCNNabCRrW5Siska8UG4wg8Ri5cVhWEmILt7UapBRRCx+DC3HcCwfC/84 GafMxkPjeF2Jv50rXqJx28QxvISoHEKsfbHgSl6EJV47JZvYx/+FaPHo5RcJRaORUFAsxAypj3zk I5VDar9I/tuICvqQSXfaNpIg3Vdh6yHi/ivCMUuRhiHHXQvboAh4l1EjhPcnifwbxj5nCjrB0HyU tYADHreiAIwjzw8DWc+IeSw6DALOJ8YGejJHCWeLakWevf68Yy7AaZezyOFjzvGhWPjOPOhYaI7+ bxvGbLfKGswpAP7nPWDEdu+XexiUY9fsGMq8Ot4kB9c4uh0KDdpI3+gxv/k/g85ciFLXF/tYixiB kwRVRB6B+4J20lXUXL+CKagx3mXXwTjSiwT9xPrGgLKvalD2db16kljvUKutfymJwHpCgL7G0cGB FTrJkOuTFsFR691FAZtVzJt0O86NoKRxAs9ilM16ztx+4yIwF6MIfBZr3lGGDA42pdDDLFIxSiGX 7CpJ2faMHcq8j+OI8PA0Mox46eK7QhVbUPLjllFYHUMUp2+NyykyBooChS0qClnYogfNLLdeY0fX 0/dwMuQoKiJi8iJEF/qRJvvwPo4ygrpjgB08HIuh55whOKv4tqJgkvhY91E+GtdesjWPp3wDxqGq LjisxISCO5vJdLPc8abeB/eWYjnU++s98OxRhjeKUBCVTeZRt4BNEtFOBpEIA+74PIyF1YgzDx0D gYOCg2YeZfE9g9552PHaio5f4xrXqPz8fnSH8o7TLrKkCI5t48OposqlOYZyYU70nfmWYWse6wqn lkiYuYezpttqQGTF965PMrFjxGfaszDqvpkjXV+/MI+cHe+WOZHhJIqusEnX4cYYwbMf1wjSWuBd tqaYQxkw8pC6IpqmmSGjM8Q5RO/NB/CilDGUGE9dYaAa22qqnLga340c09pCgBOFs9p7wSkyVLxv 9C5RbcWnlsIGEO3gvAmjbNY2LkPHnNttbATmZhRZrBkDFn+UEYssDxrvQN+IUHqaB5GyYAGixPsw hiSsivKgNHgJfG97CzHPJsOiKzyDPJUWNpVBQumnENjX9wwnL6YEOQudj5drVpFUS0GOuvb252U1 ZteOqsFLzIvoHCJlRLSGsWP/K13pSiNPKwImGZg3RlEGxkxUZokdFHMQjXOdIRQF1wp3DSd56eFO qaEc8KoSnh1/p3dl1rveVGoSz/LQBHrPLWVYsuW8EkRnH/XK7eFdZhAxyHnVJwmDSKVKz7EI0VIW yZW7wqWdyfwTNNbFHimiJowR1A7PF+oX40Zk3HsdvXbC+GKoisibSzzDnCLmST/9LRIiwVakmYEh KuLDiAp6RZyXAkLRF1UxF0sEFrHmbOEAo/wYG4NNlMx5HGvSdXOWGXO/l5v3R8TFPOeZ4mX2U7TL 2MPgMOcZCwqy9UKRDkaO6FxEiry3ojkosMQ8bH51bI40RiGWAloOA9KYRISwDyhxCme4TucnzgFr 8ylsYKgkuDFS1qwx/tc3Khd733O/RGBLI8DRwFErgqoowCyCyWIOmjW6NOkcdBrz0zycTLNcS267 MRBYslEUBo9FEx0Cx1qUx2LFE0lUESG8bRZPXkTKEE+bBa77Ee1BEeMlVCXIw2+R9PF7UC5CAXB+ VA4GFgoHzyQvoVyFKKlt0cW7dIzgV07io1rs7NNv6EcZMTHg31u08WMpgbZT7jA83pQChhBKhQoi Fmn72CYq4lk8GU/RC4kXhrLoJ2+7a+ABpmRQHglFhjJEyVG2WyRIOBrOSnfbFo2OB5nCBGdYEt+r 9Nc3KjfGY760q6TYoepQHodGi3i6PW+zlPRe2ii3zN4or54zCmSUMx03EnNCNEH1jA+tVrZlrmy+ Zx363Iw7K0WAoh/GirlB1TVVk/xOzG2eU44Zwpkkl4YBOkooOPI5VXob12TasURHgiPP4cIAtr1q e36iSopUzUKpMR7GhajQqDnJvMYA4yxj8PjJIHnwgx+8cCkMJFRo0Rlj4YTQ20gUMoztMIpE0QnH mrn/jDPOqLkKHFEMH4aNZ5mihYqoKaWomHk0yvXKiTCXEw4rBhX85BE5PycYinZ0tp/vE5RHSwRW HgFsHY4Pep2qZbNIVJoTXZrWx2iW49LPOC8Ws35g9dC5GHmc5n3Dio5KVxMt50zpp2sYJxoxx4q5 cCjjyHHkm5rTRuVCxvVbH5U5N6fNIsaBRTSqcbQcMNdDN+bwcv19ejQdHRNLQII+aRyTetPF2KRw 0DHpspxT8r66a4k1iD5sjfIMhU6LZh1i3jRnmm997yM3W1XXLRINVBFjKdXninetLWAsVAJRUago PK1qSYXaUAtuFBpRWx6IVmUu1ZLKTVmoZjSqeohtCpWjVgwaV+GjeKdr5aHieV44hOpPqg6Vhaot ymhbjLO29Edpy42bqUhJiTa15UVunaMvKnSo3uT6yiTRloW1LTd+s+38z1hso1KLfbpS+iHVqk0q yZHyArbF+1rHrppRfMrC36oAFVVQVEVRncn4YFoSnjerWtc9T4litUVRaIvCMBMG89h4rVef62Kg 2pTnreRgDIbGu1GUuM0qyAw+wCrfUPUyz6mqjNOkTNZtWUhqNcSNKGVR2qzK2iw4FMdLWxa3TSr0 qZjUr3JUjIBa7YioKDStop9tbWfOHSUqE/XPazvzYLeikvP2KyVNu744Rr/qZne/qNw06dhxHBiN mq+NLaoAFqp1XZf87H78T4WmfrUp+MJ5ksCoX11q2rXP6/usPjcvJPM4fQS8TyrcqjbXnWeGIFUU 6qr7zFJpbshxbaPqHL2IDjWreM8L/a9WqCwO5rZEsTY5RHG+1KqTql8WZk2tXtmXYiS2xaFTP8V4 GDQE51W5WHXlSVX7imOxLfmSLV12qNBvi8FRr6m/Fpvb6S2FodQW51VbDLlaoVlV6KjybI6lo6qw CVd6aWE+tcUwqTr7KKGXqzZqn8JUqPv4WYzfWnE45lv3vwQt2uLkbws7q+oLzqGSaEhJ/WiLA7lW SDW+2MazN+uaMhSz/nbd6nMiN0syihY7iNxv/SOwnowiileJ0FWDfpyh3r+jhZ5TjaJC1Vl3N1uJ eZOc0vLTxKRnsrPPqBKn0/ZfD98v1ShaDxjkNcwfgTSK5o9pHvF/ESjRlOp4LYybmSDRyqJ4+Zet DchSjCIOHoo8w4jy3TdqOLKV+2ZEjDKKOOG1JOCoVqLfsfqG1SiwOGAYDEr49xV9+EYAwZqqvcuQ tjScOFo/cKQzYrSRUcK8K9oXaBGj7UAIB7n/hcHKgHUdHPMhJfJUjZRCLV74H8ePgIHxMxZLjntb ckg3WdO1JGCcRUDBM1QiP61nYpxo81ByRQfpEjM9iDNsPPeS3LOE+XLbRGAtIoAaKXdDPplchCEi r0AemVyIcfSkIcdZTduUeaYmqQuTy50QEp8kKAryNeSYoI8uhvKwmq4/x5IIJAKJwHpHQCEsDbjR ohUOGSrSGdD05Vd3qa5D91+J7VDktESxNssTjrxf1Dp0MLnXKLTWur5Y96RLqDTpYxtpHouREumq hWlQz9ByFcNBYxtaeMi40cuK87nmWqJo94uauYcogt0CX9IspIJEbrp0F8XKUNZC0B3RtdGOo4Ix irC0ADn06NzyN1GQu2s6nUfaQNCtUff8bazyy6R29It92UZ6CywVrpECMooGuBiMF7PPknOKFnPS 3CcRWIsIKOihmMXQ8tyuUR4YfrAE77UuJi18ZHkZJuLuJDrq2iw4cjVM2KP6xKx1PHL8iUAikAis NwTk1Milk9ensNRQsT4osCWPT85ov8fO0OMs93YMBzmH8ms4OBkOhMNTUQm54PId+wYG5V1/Njk/ 8izlFZb0jIWiLUPH7dyq8cnF4TRkeOr7JI9eISKFeYb0YFINlMORcccYhX/XQPE340I+U7egEaOL AcW4YSBq68Ao6m5jDLaLlg+urUTQqsHLoPS9XFA9OkNgKY9MGxmVkjmCXY/nSaENef5yleRhyl8K kV+vyJr8TtspfKOQj3MtNRd36D3pbpdG0WJQy302JAK8K5IVJXSb+IeICYTnSXnulXzB9QHiyZEM bqES3bHQKd0+KdHTNZlITdZdsUBIPOVJk0zO2zRJbCcJXuKmRSRlaQgoDOCeeO5GeTDdH4s2r58+ Z6NETyJltxUtGCq2tc+k6KikXc+axW1WMaZxDgOLuep4GqNyRPQL3ziXhdf+GmEreDA0QZmXtlDP akGFUeNWIMW7w7Pp4/2BgxLg40SVLQpASiKwVhEwz5jnObIYDbOIQiXmHwp+FJSaZf+V3NZcIqGf k9OYiZ8MHcWxfN+fZ12fqsK+MyeZHxg31tpQ8h1DpWNrruIGUWipa6wwKEScrJGMBO1TFClQ4ZKx xSBS8l/RLfOO46mM2Z//+gbQYvDrXuMoFkf3f1ghnJujIocMLAaiCCGD2DWKMDHcXB+DSGSK0aQ4 mWI4dBGitUwU1lHJlnEa/TgXG4VbDBYL+6DdLaXQgqSxUQmufTqfZNpIAO5/Vxa/tryMg44T+0p+ tc+kRCznLAv2xEIEo2iHeKf2m3RsCWzOPykB0Xe2mSUJV8JzeSEqZ3NU8rOx4XXGp3g26lhHJVT7 v2NtKVlPOUWBofuOR1sMjMGw4iGXUHsrt4bg9Cp+ITlR8iNuc6m+0pbw9GbJo56BUk648oYdo0zM rfdlmshhKS95WyacylEuYe22hMPbYqRVvrd8p1GiIAgudekftPC1Zwu32HiLAjnt1LXICV52FBGZ usMG2GCpOUWl5HNbFpxWIm4pzb8ZYvjhpRpmW7x3bakGuNn35qJSwro+E+7NpGTf7s4l0lf3UdBl nBSFoG7j+Z1FisFTefbyFvqisAl+vWfWxzNcKJib8Pdx8RWcKdUh6/c+pSLnxBw+a4JnudBAFo4t 8bh4KRfmcusZrCQIl0W9fory1Jb+SGN576UyZT1eqYI6CwRL3jZzipYMYR7g/yNgjigVzGrxqHGF V8aBJcHf+jRrUavFgL/UnCL5NOZRoihYqcJZ9a0SIapFCYhiAOaTKLQAG/NrqfBZ55uYF/yuMIJC B4oLFIdhnYOtt+brUmG5Ho8OaK4rld3q34pXKNQgd6cr5jzFGEqrhZrTY95xvGKojSz6EPuWCEtb jKm2OIg2OZ48aOt5tyiFscjhMe/K8VXQrPRsq+t2iP8rnAAnuUvjhI5c2si0xaiphRfkXofIvaaD 9vUVRZdKFKotTtO6KR1VzlVX5FgVA7XqHCshc80pKhWoaqhLGG9UF2/WoHCaUqks477w9AWvUunH ocISVwJ4kmdOw1bb6O8zRFjn0WhRDwxebjzPbllAJSr1pGDt2oZHxVh4DEJckzLFclBso4w2fMZ5 cGM/XgWls+2DY8p70MWMp4A3QTlu2/goqyusyfMZoscGb41j+MBXGDNl6QjwaiiXLvITXNtpR8VP ViqZl4TwTPMC+SlqI4IUjYq9S+G5wgXG2eV5ESHgBfd8Crd3n7dR5+epITw0vO0+erWI3vgpNN0v R+r9RXfD+Y3Sz8LrSiLz6BuLUP0kkT/F0+h9dy0p80HA/dZiADdbLzPPS8gvfvGLRg6A51F501Fl TPG5bWcu0NvM9kMk+O3xPI3aJ3qfDeXCG4cy19YF81bwz+PY3gk0TfOYeRRdUySIR9bPEO+Q5w3X 3TZ6NhmnY4+KKtkvePDy26wLPkq/KretH1FZgBu5BegociJEqLzrKDbWExTavhgX6oeIWf9ahmCc 2yQCWxoBa4F3wPPPsz/pfe+PVTlo7xx9SZuStSBBjbNGmTfNi/QzeUIkvg8c6IHmLdFic41cGx+/ 04HNz+Ym2MV6i1ESpaejhDh8CVq9FgoiRiGidCh05h99L/WZi2OJams2PavQEc3LXXaAaJdrphuK BLlncoREukPoAOYz5bnlBI0S9x2NHotA5Me1d9cA87jrF13qzsfGIpIY+cgiYXTlbplwcyrso63P rNe9lO2r5hQ3ajEHUofcIi2UGH0e4jgWbg+R73Axo5lp9zx6vzAGgOQ4Q5V3Dyglbtzi5xxuvEV3 VK35/rVaBN1giV7q8VNEPQwUUA93vCgmDtfjYfMiWSTth4YRIpRK+dSoVRhQGFooldE3Dmv4eHi8 PPo3WajRYYQko8eGF48iTTFl9OhfVDz6tWFrvDAe0DBAGVBq11vQHWeaUbaY+78R92GUMhrivgzB QK1+xg7DJgwOfakop2g/FC6hYs+svikmFJMOyhvj2HNJgWM0C91PayQbYW/heBQ+hpnnxsKlv41w fJcCyLmAFif8TSi6DCLGvHfcT4bdJLFAeD/0Y9DDIWV+CMTibPEwB3R7SOB9W0xx4fH4+zQIc6Te Qox5Bq55yRw2pAdEHKt7THMMAwIt0nMZc9rQIhoMHc4yfYf0pesb54w/VEHOJE6fEqGpzi3NYL1D 5n5j52SQ+Ov/nm89m4zJguqZJcZqXqW0Ee+ARdgCXipQ1Y+5ljGD3uFarBfG5D2XcOw7vcr83m9+ bTzmeu/ZUtfS+T0teaREYDYErDPeGzkd0Rx5yBHQSek1KGfew9Uu9CtrbOiN8mJdL6NHTo3rIL63 nXnXOolCS4+zrpkHzDc+fjcnKyRkjlUowZziOz8ZG8R56W++t7brHcfpElRFxplz0A9sZx5Huzdf OY6G0pOcTuZDc1afGo/m7hrNtdZ+/ZXohHQAOixRUMG1KXDAwa5nkLwfDuDuPWX8MRrpJa5DoSXr CccUh6lriAIUdHpzJb2HgeUnvZRujRJIr46ebwIL1g7zdBzDsY3VPist1SjCYVysYeRiPDgWZB61 rrUneYpX0kPjHP2b6gZSoljFDCLbWLCGiIatpHtM10C5Y2BY2MLCHZK05kaLyjCGWL1+igB56MMo 8nJQArwYHgJGhwfJw2UbHn8fi6sH0XeOY9HkmcSVjIayHn6ezaiyATdd5Z2TscXoYUhZ1CnJxMsC aw91GDyMLnzMaJwo2lXCuXWichzfy4OhJMS5h+A7r20W+1zN6/zLcRycWgmochmGKJbGYHIzyXlO 4pntK5EULxxc/FwOBRMhT5J7GDlCFGLG8LSqb+Oum6HtOTDRhnEWnm4TdeT/eNYokhwPnnVjmyQM Nu+uZ9EklzJfBOI9KrSH+n5H9Nv/zTeeSQ4az1T/nRMZdN8tOBZ+P803Ma8NGWk8q55N+1sgeTZF oIL3PdQosuCaGxk0DO++eMZ5M11nVzSSFbGMuczCG+tAbMfI8sxGhN3xKW7hGDNXhzc49rFOUV4o hOZXzjvzM1xdq7mcccZ50R2vcYqsMtiiYWs/OXsItrlNIrAlETAP0GvoKhTkocKRTKn37mjQuhaE sUHxVwjAPEk39I7TUTnzItLrfafIyyOmg6kQR+8aJwwc+hvn1CiJ89rGeekAoijWWOcw7xgHHK2f sxapMEcZr5yorjBs6Nh0QXMTY49j1XnDAWpNMBZOUQaiuY/OyMhjPIUwEukOMae6BtuJbNHzzZu+ 96EXWQ8Yi4IEGrOah83PUVAhCjv4jpPWfcGEcFz6rYIL/TVgRZ4xfD212WflgwfPryhsbbmBlceO 94jjHKIGfAGtHhs/u/udbfBQ8bBx0oma6+rDawA7TQr1ovLYC72hbor7iR+K41ke7Mo1lyulCRfO 5DTBh9RAqt/kVAMyY8IXLZ7JmqNRlL9NDqfJFE6meu+4m7ik5aZuso1mtI4fteHll5QHpI5xnOCb FsV4oZY+3jqeqfyEYm3XPJTisV2oce843T4wmrxqmIkLWzwh0yCY+/dyinBs16PIycHJ1QdgqHhW PaN6HJRJsDYolhunuaRcMbkinl/PTj//Tk4HzrP8B/0EpjU1K16n+n6493jScph8/O15judcXoZn PHoUeC6NDQ8Zt3xSf4G4bj0Q5EXJfUoZjcBSc4q8S+4nzr57VRbpmivpudGjwvzr+XHvimNlYRC2 kbcmj6hEWCq33VypcaH5I56jeAYdzzbBDfesOq9eW3LLPCvOHX00cO1jLtaTwvEcA0fcz0m5SyXC VTn68hi64ll3zv6apC+I/5vX5On5vRjxm+zrWfT/ofOOOb0oKrUnS8ydepEVRa82JZfLpVmjd9K7 F2sVHjz+fzQjdl+c13y8kpI5RSuJ9vo7l9w988As61igoAGnPnyz5EzPA8Gl5BQt5vyz9NabZdvF jGW17LPernOznCLUNZbdYqtjifjwPPP8ifgQ1iYPpQiSCh99ioRteBtZuEJqhJXMUleBYqiE112e D/4lfjnqBW8gTnp5iAb1RuH17JcuNAbHdxxeEWULWbLd0oW2ESZkBcf3LOU+J9c+jh8UQl5dFCje yVHiWLwwwpdCjcR1oRfCB91KWBKvnndepIuEt9Z1s/pRnkSRUE3GeTGGYj3LdrwSxrDaqtB4xlE2 0dZ4uEUVfdBgxtEs3X+eeZ5p94Woxy9ELlo0tAeRZ91+zgsfESARJB/f8Y7g94oS9j3gOMi88qhH 3jHh8CHvq2fRs4FuhT4pZO0YPOaeRd4xHF9eeO8Pj2GULEUJGscnjmcBdrjUxo7ulLK8CLg3okXu pQif++qZRIkz5/QjFagNnhfzBa9fzNOon+aRiLrwhAadDG3MfNgVz6P5xjMoSqkcKzFfo5yYJ81x 6LxB+XA8tJxxMi6yxDsoitmPIllD/J/3k3d1FMfePrysnudJYs1y/byRvJ0odDEe6xF+PZqq6/E+ ynFyTJF8OKAsm4t5Pq1zPkQkC410CGV7eZ+UPHoiMBkB87/n2vsugjGLRKU5rAXvwHqWoRHwrv61 nvFY79dZ6XMWF0r/YidyCzHDAGfdQo2q4SdDQaKUBbO/WFNM0cfQJChmQnqlIkfNAaK02bd4qeti hW6BX+gF7CYYG7vF2rnkLlncGBEWZedFa3Buyjlqj8UOzcEnkt7j4Q0uvm374rtY9H3X3yaS6CgF QdXrbxN/R1jUT1z5UYs3Rcei655QfiOkS6mxUPtQ6inkfrp+HP+u4elFLpWYakiU4UTxFR4fWhxg qS+1Z4mCstomTEatZ0qoVri5eNErHbJ4fetzxjAIcQ3ws53vbWf7yB8rlVFq2Bj9ZohQ5iiQYcAy dChcDAo/o3w22hxh9MQ76dmiCCojSikV2nbucRLPm/F7TuRwoEn4m/OCUIgZeuhGMMErRh0l3kPG uHyVcUKp9N4x7oIfPASH3GbxCHgm3D8GK1oCLjxaprmkbyRzdLlHHDBRsMOzZh7wt+fMMTxb5hv/ 9738w74zwxznf84lp6cr3infe9/RUOTrOJbPtF5Wo5Bg4HnG++dBY8GRN78zyhS7Qd3oijWDIyhy A0Yd33zJuGFYUgo9v11HF6MHv38U3dg7iDYnT9Nx0E2tO2h0REI0GsyookOLv+u5ZyIwXwTkhHAk m0dm7SFHdzOvcGJLL0hJBNYTAtUoki/A2Bjae2UUABRyC5ZFindS1R4LCI7qKN44Zd4+Flo8dVEQ +TVyKqKhFqOA0UQxo3hS4kZ5x23nvH0eZnA1Q8lzDOfw6V+rfArn7i+yOJgSeHnMKR6iA/1t5F9Y /OFokmGQ9cdpHwpFl6PZx9E+PLoqJFnwKcndmvA8r5TiLu/X7zyrPJu8nwxS2HeNH99LtpfTNKnP xjwfbAoHpWxaLso8zznkWIxFzwtF0TPnmfARteRpZ4SGQiPqKFqn8IWonmgRLz3jnPcd9u4Jw2JI 1Mb43P/IuZFEyBFQymZWAyQKOMR1MI558BgeXZE35ryTqtGEE2JUhDaORXH07nm/XBujMJRJxR04 DlzvKBEhghljDv86ZXkRiDnUc8a4ZtRTanDDGeocJ5E8HPfePCAipBeG50zlQkavn55zv+NyU/IZ Q55DRWMYM+HMiPOKhnLgMCDM77Z1bM9BFFsw/5i3FBBR9dA25qtxwnB3Pf31AS8ez9wawXhxHX46 j3fEmsFJZc5m7Mu55MxgkJg7rUOhrFH+7B+FKTgkPOciO+YmRpTrMO+aQ8OZwPEEI1Ef+6vWaJ5n BHG2yVmKdcu6VOh39TIpipRG72dKIrAaEfC+SXY3X1jbZslfER21LyYOp2tKIrDeEKhGkQncizK0 8tsoECxuFE2LooXVIia6YwHvJ6NbyFCIeNcom6IYPpRTf1PIRD5473i5GUY+Fq6o5hFjsBAXrnc9 lwWaoutlR3lS+MH3FGGFByxeca5+pRRGDe+jZFqGhWNQCikMqCUUZp5V18jj7vi28b0FkmeT0kCZ oFi6xmj0xUCwaDOqYrG0+FLOo1oICoxkOAu/RdviS7mxqIfCTRkxFgu//zs/2heDVmUR3YVR5OyP FsIQs41rRuugPKFvrYQwPI1/MZ7i5R4f7Bm57hmvtHtK2eLhphhFtMj9kqTIc247xjE6DWpoUDw9 R4p78C4PEZTGUBT7xnV/fx5v+FF+JXJK9HSfPXsSIycZRd4dz8Ok0qoUaQUjPBPeLdcnCdJ+FEYe eY6FvqBOMIg8r2kQDbnrS9+G4tK9n54Lz7BnQKEa4l7bJiqkmUvQJFGYR4ln11zFIB5n1IvEO2ZQ SET1ze8KgEiiZTB4j2wzpKBNdxzG630YpZQxLoybY4ITwU/nY7DFWERujSeSdBl73mXGWHRa966I 6Eb1OVFe87Jxi+hwOjAwYaHikfkY40F0nUNBgRxRYnMCQ88cCl/vDYdBUBKd1zk5n8wb/Sp1S38C 8giJwHwQ8L7QB1D3Z6G304u8h9avtVBpbhRadC7OFnMj5/soRg99jaOEjkrP6gtdTaSds2lo8Sp6 mEptDMpJjkp0Y7rbrKwtTn6OGdHrvpjbY/7i6OEQGnVddG9MEg5aLK4hjbDNr6Lq5mUOZHNrVxT0 sV7QXRjgGAn0qb6jt7sPTOE0FNv5vBWdo0TilgTSsijUxO9ZREGDcriFxk8lulH/9okiCAoT+Lso UvXQEmuLl29sgp6CBSUiUxNcx4kGmo5ZPHl1E00lNZvSVEtzLs2kJJjbplCNBl2S4gXFaKkNLjXq k2wusVgD1hCJvBKbNeKKbSTqFsV4YRvJ6oVOVPe3jfGUhbYtiufCNpKMnSsSgiW1G6viC5p3uX77 KkSh2aZmapKmi3e3LQpRWxTWuo3jum+R7Gg7idbGKDHYMcrCXZOGNdJaCdGsyzjjfq/EOYeeQ1Mw mEoW74viBEWxWSiGMeqYEs7hWSbN+rVEcgVCuona08ZS+g/URO4h+Dh+WcRqorwGcSUys0kDy3Hn kuReHASbNUXrbw+PMknVZnKS5hV4sN+4pr9loajJtRJ0U4YjsNRCCwobuC8xP7tPxYlUi7tE42Zz gLknGuEpRuD+ThKFNhR00WhvlPi+REQ2WxcUa3Auc5IkVb8r5DCLaJJalLOJ81Jx8tTr9nOcGItt Rl2Hc/hOs2tSHEStBsX+VxxKCx//g2W3aSWMiyOtjtF1ThL3xTGj2eMsOCxl2yy0sBT0Nt6+xbFa C4Qo2jSLWIeKQl2Lqgxt/DzL8WfZdimFFsyH9CvFwYqDsXWsrpgnNKGlB9CfoqBMdxtFbRS0oa8p 0DVEnLc4zeu5zUnjRLNUxbzGNVcftZ+5UaEjY3J/u2JupovRAzWsphcq5lQok7XAEzHnWZ9cL92m GL1VZy0Bjs3w6R6bHqO4Gn20OFTrvgqBlSj7QqEe2xiXgmH0F2Ow3bgm13RHjXNhYP1aKekWWtjK SdlIKDnRgGkS5aFvlaEXoBHgpaKOOQ5vnAiRHB4/eSWUN+XZ40VDc+CJFvUYJyI2vHa8hKM8kDx9 okjyg4Kihd7gPCgSvHv249HHc59EW4sxiGywdNGhWN5Ry901dAW9yvl5GngGlXeM8oaxHSvXNsbi O/kaXf6tfVnYvJJySySrs6p5QbueBBE80SVezUikFs0QrfKdXA4e/n65c+flDRFFgjOqyUp5L3kc RAr1tunS/+Zu0S/igLxd6I28IKKLEUnhmREZRI0RVRzVhJH3yHeoA10etkghT7Tv+s/BqCG6b3Lc UBl564Y0fPSa8vjMQnWYBo9nUGRIIQ6Rp1FRoe4xvLfGK4LkmRPpima2qBTd65DrIooZz7LxizqI eHlnNpq4312a1Ua7/rze5UFAThgvsLVkaPPc5RlJHnW1IyCKINpp3ZMnO4sooW/+wu6ZVsRkluMu Zlv5rmjbIhPTeuf1j2/9pwuJ3GB/YDaJcoSIUIgkYQDRxazt3TWdfgs/kXprsdxCzAmpEZOEPokS TB+iu3XXces6PYS+KhKNZUSHimI2446L0izqRwdH2XVt2ETOE2L8ka9Pb3FNqP+eA9cqGo9d5HmA hUiSiDfdWgEvOEcp8mg5Q0+gu4jAYyrQfTCk6FCi9dZ+56BLmZe0lsEsicbXwY7qFyyT8uFYxoYR ZuyRX72Y52SWfWDp2mv6QNcSKxfSFnpQW4yLlTLQ8jzrDIFihNWoQwm/rsor47Ep1Je2GIjVw8Fz 4qN0vGjPKM86z1gJa7eFilQ9Kl1vsovk3XDNQyOS9uGB4pHqe3ZWCjTRT94i5eSnecGV3+SRLlSL 6h2DH89QYCeyqqxreNXgVRwFbZk8FzCGdZmsq2d+I8pSI0UbEbO85ukIZKRoOka5RVvL42PPTGLf jMPJWm5+125kNchSIkVwEDUpjugW26g46hciNyLuJfWgtnPBzBBR6Ud+MaGKsVKjypg3JRDQKk0+ TUTvsYswpLptEJT0LxT0qn+I3hVaYo2qjIpQ9c8hqlWc5bWcumiQtjdaA3SlUPFq1KcbETMW0Rqs E1ICB7WNTLcdDR1HCxDtHCIyqN2ASJeIuGiX8fbHWZz7tQ1OtJ4pRnRbAgL1+ROlN75RkTIsB20P 6FHwMJ6I7k/Ddh7fb1aSOywqVqNoAksvJRFYDAIiczwe4/IYFnPMee+DTysKKJLHs+LDO8Qj0veC ybOTdM0zwuOBF9vP05EXIRrHszGEh+t6eIFEWxS/CIlu1/O+3v7xlFuWPyFyie8bTVxtJ6LTFX/z KMnPE0EWDRL14O2KgioqePnbdiSugwcuEtJ5vmwT+S/LfY15/EQgEUgEEoGmtoyQl4oRMK3JarTS CNywJ0Qj7DdrVGa1Yo+pIRoiH1b0LNZgERoFWUQ45Gv2KyaLhNCN5VNh72BGiZaIikSrjiHXTD+K yIQ8IOwpH+woTCUR3yFRX7nA1lx5kcYaVZBjDNZuER/VQbstPuL89B9YuH4FZ7pMIjpO5PSLQBFj hI3CXfCj83SjWaJv1nl5Q9hPWCJ0Ddck/ziq/cKMPhEizwuriN4gSiQyZ99ZSqEPwX3oNrXQQghQ hAYVPOgqa0MPltttbAQowCqZoZZ1Fe3VhIqJQvjWBIL6xaDxGTUJecEVrTBRCqsK77pGL7QQfleE 5B1H0vpQkeCtMAgjQ/UvFDYT2HIK6qcQt+IkhR++Wc8tvStM1CZTWDEILYy2RZEzWZkUGUeu1+Ih 7C6MrliDSRatzqQfBVxcIzqpZ2LIZL+c15/HTgQSgURgIyGgfQOFHhVqGkVaUSY0Ig4veiB6phQF 69t6Ego8Gj1D0VpH6LzWNSkJFPW+g9DaDhMViOkGPqjgDCuFZwgjgH6AzuZnFD7oKvjWQJRXhRzQ 16UaoAIyHIzHttIerJuO4aOYU78YDqMl9KxRFZ6NJ6p79g0M12aN9tM2fo4yQuhKcWyFbhjXo+jv Uj8YznBV6IYtwUHM0KE7SWGhVygSxvGsmAMdynkdU3ELFT7pE3SMKBq0JZ65TYwiA8D7o9SWBKl6 Y1MSgSEIeHE9M6pByTlZzeKFDW/JuHGaMHhhVNHDGZYPJ/rFkDE5qMLTFZMZnrH8Orltk4TnxbHx s+Gm6p0Jg0EyJL9osdiKeokQKVk8yiByXHlGJjULod5F8gFVw+EVs7CaxBg9Ji6TqcWDx8k1ad5q MlORBvfagsorZEKMXK2V6pO1WIxW6374/PIlGbWjKsV5Xi3ADNO+wR7XJFKnalLXSzfteikKvHij qhrFvp4rZbF5WodK9AryDojSjnpnLJSqwKnyJJ+t37fIuaISpOPgrw9pUO3ZpdCoBmXcjP4upp5x EW/HVF7ch8MCdt6PrnCYPPvZz67fdUt6D8Uht0sElhMBUQzPOoV7SC6QuSPK/HMIqk43a/7Rcl7P vI7tfY++a+Y465Kfoi/W8v4cyzhQMU1Exbwg191HHr7/qRpn3rAN/UA0yU9VlEmwS8LwYHRaR7u5 7vJotIWhAzBO4R/6hlzcWVvmOJfoDudlN0/dOEWOOEYZaIwcjs5RVfFEB6c1cPd8mf/gKa86KkTL M/I3PUCwhX7gg5Hj+uRCaTtj/uSkphMxEkWWYOP/moWvuIzj46mOptpIsY7nQdnLY6xTBOSbeEZw WlVpWu2iohReK15sPzeoO3b84qI8Vr6uj6pz8Slh7lqVqi9RyU1u3iSRsxfVE8sLv1CtEYbLJd5n /OBizC1Uhhl1LpV1umPC71WZC1aFale/UzVR1Rl5RfKE5BQV42eBX1wWhso9VpVP9ZlSArTFxVYx UZXFSbgv1/Vv6eMuNaeoLBBtWdxqjlYx0je5HO8gLrf7UhbUinVf8MjdL/dPhSN5cEPEPbQP3vk4 kddiG5zzIVJaJyxUOPLsqNKJv46nH1K8tzWHz3e2wYv3zJUiOAvbyHGQE4D7H8cpZbInVnXEbS+0 zlolCcffx76F8rGQTyjHTnXKojAsfG8cePgxx8Fc9UjPufMbn1wF98kcs1KSOUUrhfTaO481TgVe 79JQKd76hcpq3mmVWuV5REXLocdZzu2WmlPkXVUdmFibVESj63q/VXolco7kC6m+Saxj3vMS1agV j0MXoBuoQGd+KNS6mgdDP/B9iR4tVGlV6S1yihzPHFgMkU3mKvnYco7MR+ZC1ZtVLHa84riZOK+U AkhtcfRudq/tr0pxKQixcEtUjnUOVYqJv60d1u0Q47VeuPfjpBiDNQ/bvD9K95M7JG8pcpfiOK5H lWWVbOkUzq3ynTHBqES/6ty700471TyjlZBuTtEmhRb6J1cST6KUUtUWk5REoIuAidKLRRHol7bc qEgpyECRHFfiuIuLZETKWRgh3rPlEKWbJWSOUpa752OsKM8d4zExKZZQmszWzSRt+h8DyGRFkSxR pboAdMu0UrhHFWspnrO6yK502eLlwHTWY0qohddipUQq6n1hpCqQ0S1/XSJzbfHEVaPBNrHYdc9V 6BlVgbeAeeZGbTNqbCVKVI+pFcE4oTDYpuSWTb0864hr8Ewp+64MvAXbghjtCbw7ErsZRcps24YT wiKttQCDhMCEEaRkuG2UsWX4M/rGFQviFCie4JoI7Dn1ocxQUEq+YD2uxR6WFmzPdfGg1uToQgVZ MOhLBLktXuX6Hvi/MZfGtlWh7CogUwFZ4gaMotJLaaKjY4mnyN3nhIBnxHPpE8/ecvxk1HOCmRNK JeCqTA85j+e476wr1dLqM04XHHKMpW4Dm2klv5diFJk3JfF7v4lzMUTMX4yiaG1iDilNpKujBC6K BShlPs6hV/pKtte97nXHFi0y7ynQoCy158AxzeOKKihuRs/2YYgZXxhjQx+9uG+Mp65YaxmAWrdY q+kmro3TJ0peG4v5lmHCuDIPK/FtnegWgiqUvzpG641r8FzQD8ybjGkOz7gORRVgxWhyTbbxvTkb lv6OFiCeGb/HR5EmhpFnOIpSDMVhsduNLMk9LkQljIX7iO5QbnrlB04Lp614uCtPuKII4IkKNaPh CK8K8Qq/rjcR0kXHQWsj0xL/hMhRfNAPitJXw9MaF4/aT9hamFwYHV0NNQ2XG1UhSlYuFU8UQXQf DdlQ+yRACpH3E0jLRFJzi+T94AUrKkHi3iqO4HeFJiTdogoU79oCFzl4y0L/So4qU6r4gtwljT1D lKVHt5NQ2i9zv9RrXe37o1WgIuJNT3uORl0L+hYamXuJRofCoTErwWdHBdOAGD8b9qiPIfLUtA2Q GOv8GpKi4aHaoVZMEtRJ9xHFDV2EyBt0PeYAuXCeM+VeHdvfk8SzgZ5tvFo2hKBrSlZ2Hu9QqcZU qZcKgYT4HUXXuFEzUFRQNZR7DfE7rIxPDpz31/kkI3vP0DZQ9bo5EnjwKL+ShlFBvvvd71b6KIqp c6AUyZlzzhBjlF/g3fAu2yboNSgz0SZiuZ9L1BStAuSNZL7ecqO9+OOjlnovlWL2vphzl0s8Byhd aMzmaXP7pIahxmHtsk28f+Z7Y0Uns475bl7r0qTrNg6UWJRrbUhGyVJKcju2eadEIer7ai42l8p1 Md+ggRF0NTqv+cb5zINoX+aUUSL/x9xrjTUP90WOkPOiMGq/Alv/k7OLIozSj6aMtouOjC4cNLQh zwmamuuJtbm7jxQA14eu5h6isiu37dkIMU/axtpsHqbrS4WwxsR6BSc0f7lV5sJiCFaavGPGsxHF Hmyn0bx8JPOTY8vH9lyh0qEGjrMj4GytLNG0mTAYgtO4bboluRf6FE07oIXQYsxIUt9d5Y7V1oNm 2jXk90tDwMtCifcseKlNXJTt9SryOIoXp77IlMe+MdG/bpOHBUlugXwIkyPDZ9x+FgDcXkqZnByL pUlz2nmG4m08XnbHx5Mm4xIyfccYsq0xRKKj67aPRZEyaoI1oalc59jENUu0tPgynFwLpdL1UG59 zzizcOBg+99GE4ur/mfyUxbjQKDoW5Qcp1Aca46XvDbKlQXcvYCrhYry5X8h0SVd/zjvqxwaxq+x UAQmSRhFDC/vuwRhvaosiuZ/H04DxrKFMHpajDsmY4jx71nqPgfGS8GXo1MoKHV9oWRIDg8ppW9r gq7FndFRSsNXY6zbHZ1Sx0nDMHnc4x5Xx8YY0rujayh2x+d4kT9EYXCNDEc95DiAKAEUQ3OB8/X7 valIxSBkKMF0nDK3HM88I9B7JVG7XxVzOc6Xx1wcAuZFayfllSynUeT45mJrtPl8yHoShpT82RLN rzm05n5OPY6sIcdYHDKb7mXMDAUGiXlulCzFKIK7d9q7EkUnrG3+p2hB9MQM3PyP088204pH2cea qzJbX+K8vu8fB77G49rN485Hb5jFeeY+2W9SMSPjM45J1+E4DJxRzjLfGZ+x0QnkYY3qIeraYTuq DxFsxu0TmBmn4xvnSs1pY/sUTQs9oS3oXI4mgWtYFrjKm0TPiU7r046R368NBNxr9xTfFD0Gl7Yo GfXeR47J2riSxY9S3X79CiZ1oB51dOFlOSQRih86gi2da4NmEdSkUWNGPZIX5JnoS6mOUztRR9+C EomooXr0JjQjPTJm4bYPxWytbIdShVsNl8VI5HPBsFQrrLlcaAeoXmhx8ozw4/WI6FLjPIPoCjjy aCfOj4qGQoHOiGqDHoYLj6rmo0O6nDoS9Dl5gygGupw7XvS28syiW9DzUCXQRByjRFvqz/66UBJp 67Yol10pRlHts6H3B5qGbTxvXUHR8H88edQPv6OtdAXNz//ROIaIXKnivKg0oxDvLp67ruuodbjv pSBDzRkaRXGVCwC/YtRVKo5xrtS7bDxDr3UIHrnN8iDgnS0Og+U5+ByPOmn+n+NpJh6qRBXqejFO lkKfW6lryPOsLQRmos+Ns/55hnnSRQ1UxWBZsgKjvjkrdxZLdx5ehjzG0hAoj/EmJRp5BngDVBUp ym0tsTytc/PSRrC69kb10cmbJ3oazag/ct6WvqdkdV3d7KPhwfERJehTddBDhP9FC7odwD0/sPAM bWRBiUBxKrz0/+2aPaMEfS4qx4nEiVCgXaI5iLygP6ruo8RrREVK48UaDeKdi6ilORqFzPzseKJO 6GTRj8L9wwpQuSgiRaIn6GUiJqI34fF2GSgXaJ+84crb8jY7H2+fyFA3esT7i2InaqU6Uwg6hyqG qjei/YjYoO0V59vCNs6J3iJyg9YDR+Vzux5l1bZEy7y3OrmPE9cPP2MPOkdsi9ZCunQ5f6Mgwkik bVy0TwROxSQ4wG85hYdZhEpk1zOQsnoR8E7SlbwjKZMRQC8rTb7rPDZKlhIpSuwTgVEIdCNFm5Xk HgqZECv6g4UrShSiMwTVSCgwP2sLA7QQyj9qFIokugw6iHusGddGMojiPWAoLoY6sN4MIngIiZfk 05G5C+Mw8jxtdIMIdt4d8yFH0lLE5I0CZ65FM0GNU9bVO8uJ0RUGKQMFDx7NSsnT+OCsa8bL4Dcu 9CtGmw9Dpk+NZuDguDt3v+Q3qqjvGb+aGyuz6jyOxbjpit4gxsrw6YpjyHnyrDAm5KLhq3dFHhTn jPwfhhsDsN8sGU2zJC+PNTy9z/KGKFzeUQoYOmhXGPgaD8st6gp6ChqqeRLNj4HLWOyK+8OYGkWh Wcp9H7Uvup57kQ2R541sHi8RSAQ2LAJrK8iVo00EVg4B5X9Vs0pq6HTMi2evYrURK8tNR+d/t0Bx U/oV3WpWQeUqi1SljhFlYP3tE3Q59C1/q3RHVCZTyQgdbZSgmqkuhQI9Tkpxh3pMFFqCZuaYaGuo tM5VEmrrNircTRO0vBLVqPQ0VStR7lTlUybXeENQwlQqLMUO6jn8VK4VjS3E9iob2d9xHK84c9oS rVkoX6u0LHxQYYnn1HFR5kpfo7YYbvX4JV+p0uTQh9BD0T6L069S4WCNOoyyGC0qVKVCI1QiHbXY MVRuUrHJMVdC3BPXPq1a10qMJc8xGQE0x6humFhNRqA4e9oS6R67UdLn8gmaNwJd+tzZSyTgGRvW IswLTwQmIIAiKowvcbufXD1uN8UKVP6RuClK0qWQ8qRL/EY3VRGs/0HpcR778JyP285+CjT49MV+ IgT9cy/3jXZe1WVEj2elGi732FbL8UVaFAJAd5q1OpkCFyVHp0Yn7Csyg/qmipKKRyInChSIgojw ivSKgogoodKNSlgVUVF1yHOGPjcqAVa1NlER9DgsAMcT9VKcAI3N76VUdq3EprrgtMIraJeO4RlV NELyuSRmzSVVKwpapmiQ30ueVD2XdwpFDM1OZIs4tyqGjoHuJ7LjXVUQIahvOsyj73mnSj5UpS8p hKJgEPxQZDUp90Gbsz8s4WFfkTZUOBEsBSZQ6IgkYFEw7zkanjGIPCkEocrUcicIO6/7qyCFe52y uhEoOZe1EAfGxSRBz9RkGf1TJLj0wakRWNUPozCAiKliJQqTqFaGrhkfdFlVu7w/IpueR0VQ+tt5 ZlUV9k6LChclsxY3EOUVNTaXe89QZqclxs8beZXHrCdR7bJ/fNFhuHifZ2UheO9VQkNl9L5iPnTX aIyH0047rdKRVdcsPX4W5psYhwi2uQBV17vXp9mOwsN8hwpsfhYRH1cpUoEYUXzU4CHRZvqEaL97 hgpsLrUmdPUVFGvPCvqx54OeYZtuo3gRbtesuA32gYi7eXDatblXKPMq7sKLTqIKbcx/sHTdxug5 9MFaMG44hHg3FA7CUnBMa+VKFnKznor6G/vEPkXztsbyeInAWkJglkiR/gCiADzM5YWuHmzJohLK I+m6TBA1KV5vgvLyVY9796OPAa++HgW80uO2s8+oBrG84TzwCh7oPbCSkpGiYWhrsnrwwQcPbp4a R1UwQbPSKPqhOIK+PCJz8XwpfqCQgn4PJPoATRqZviCKYzjeKBHVct7+8+Qcigs4t4/fx/UGGnd+ 0ZbueEdt57ptM6loSYyl27spjqV4iP2jz14xdGoRCNfkJ6+zj8INcOgnmsNX8YdJhRNch+tfyaat 5pVHPOIRGZkd9tpt8a2GRIr0vtKbqyi0mzTQLsp7LeChmA0x1/qf6Oy4j6IrCmDpKzdpu4gSa0Qs aqwojuJC1in9vPSVWcnn2vUtZ6TIHCGaq9GphtH66XTFGm39hK/IdBQO6m4jcuwe2UbvnSFijijO sBpZnlS4SQGc4uipc/s0UdBJsRz9hYy50IkX9I6IHpuTFbHRwNX1FodZvS5RcEV6iJ5DGAEKyegR VNoQtMVxVRtse4ZGifVC30Pn1gcJS8SzK+IPk3hmFLIpxnXtC6X3kWMbQ7fRt35EetdpoqsXVKFY 1zHad6UKfwxu3jrtpuT3icB6RmCIUeSlRbuxmFh8TGgmP80g/V28MQt0JrScUpu//t+kyngqHsD6 sY8Po8iEaEGynQll1HYmDIKOpJqYBnAMMfuYzKI62ErdnzSKhiHtvpSy5LV7+EpN+MNGllutFQQY cQyiEulaK0Pe8OOcZhSheVKIzd+UQk3AUVVRMTUF9X+KI+dAidy2JUJS/6eBpkbEqiT6oOjaj/Jf PO4L6xCapTUjtise+0pXpRhT0lWFRCst0YR6ryiqGmhaf2y7kjLUKFpMJU/OEQYCA4BBobpmV1S8 pLQzCij4fTq4d4/ByFi0r+36htUorDS616CacdtvSOpe+Z4wCqzjo4yx/nHRfxkP1t4QNN4SQa/3 ntAnXEeJEC1sw6HC4RqOVVVCGTeoybEmuf8crF3jxbPHqUTnMD4UZDTHMIAYV2jGqohGs2+VPOkj DLhR4nycyWjPcT854IzP875SBrnzaL6Ngr7oQgvzDpnm8RKBtYiAUH7x/NekcPQfdCNUJx8hduH6 suBUCpJweIS1DzrooBomltQdH5W3hJRVlQqKEJoEuk9/O0nmBM0BpQfNL+gVzpOVH1fn04R2pXIc upZnJCURmAUBNBf0luLt3oR+MssxctvVhwDaFkokQeFBV9UT64EPfGCl0qmQiOqlV2CXmmmdQHFC I1UR0U+NitHtUKmKIlqPaU1ANbONj32sG2hKaGToq2ii6Kkkeuh53mJcqwU1FC3UL2vrYgTWaHEo hq4ZtY2orGpeRsv1/ajiQWi61nwVLvUygw8a8BCJexHbKjajb59COO4FOqNiOUOot0Gfdp+79Fm9 EdEt9cQjKMLO26U1oztrnIqC6Dt6h+fK/0NvML/AAZUz7r/nUKEcfdEUnEG1RPcLGj+aZTH86vjj GqQTeN48i+hp6Huoc11Bb4Yrup5Gryh0ron+tNIFq+rYh9zM3CYRSARGI8AQwesnyi5HdTF5I15q XF7llBlDJoaYdEwQOL44vPExSdouukI7pknJ991t5Y5EA7ZQsvF0F1PqOe/ryiOgtL0y2fIA+hXO Vn40eca1ggAFTD6EnD1Kcjo+1sqdmz5OBg8FU3VFiiMFVX4bI4XDTd6G/1M6Kalx760NctsYQhxl PoxmYptQTq0fytfHNn6++c1vrttRZinJ8oc8WxRka5YcOzmihfI0/QJWcIswBOVCLkasrxR5hoi8 YSX2CceivCrYWNf7RhFczNmaM8vrZFDe//73bzS2lgM1VCj6DDqtDegB97nPfZp73/veVXfgPHXP xuUcxTk8A/LU+tsad3xnWw5VOchd48L9NpdwqDKubMN46eYox3Gdw3WTQo+rY9bCwT1QRdRzEyIv iFFJ74GhnDbrG+evPE85ofJbrX1ya+MZ5QTQYkHuk3vhO/sy+FZqjmOMwoixnUbR0Cc5t0sERiDA A1f4uHUi4GnSe4UHyuLFC2QCkQjP6+JFj5fcy2+hKhW86ocXRkJ5TBRxKhOXJEr9SGI7CZEhyvFa TJXIF2FKWRsIUGIY03rsFFrl2hh0jnKLIcD7K1lZkjTFYlyfpC02wDzxkhFQ3INnn4NLPzDOLx50 CrOiA+H97yqKPPrWHMVVGDA+nC4hEZ1gbNlOoQfblPySuk71hXIsaqSIgO+tYbMWM1gyEFMOwHEo 0hV91RZzPmt1yduthg1jiCiC4FrdB2tpP7KjgAXHJ+NBdMjHvXCfGEsEU4Tx6m8/GRV9YXC4r4qz YJFgjTA2Cn2rFkBgELkPtonjiOr0Wy7E+LrPQ/we3zHs+tfRfTZsH8bfKAOkuy9cPBsMmL64bgY8 I8m1MLwYOSJKmBGFVlejQMGGUXyBMdYVRlBpUl771TGq9Jnz+0oIA9tzZV5No2glEM9zrFsETBpe Jp411biElPVq4ZVTOUtFLi+6SZgnIiaZO97xjrW6kGpYKrcwilQWI92JiLdQv5fYjnFkkgkZEmpf t+Cv8QvzbDCOKEErNfmvccg25PAjUiDSXJKm0yBah08Bh5l5Xk9A3mrKMEVTVUeKqMpejCMVKEVz QpH1HeVctIKzzIfBE+tIbEdRtZ0KZbahcDOOuoIWhq6tsbIeZsZT8plWHdockRRoFdK8E4sReFPg OS9hy8Dyk3PR/zkhusJIMk/bDr3LWu3DISqSghEi+hLNskVyRURgSGKdDsMDHV5Ep1uF1H1npGF/ iLAwMhzDh1HBIRICA4YuXUG0J8QYRIsYywQNjaLfvR7bM+xKYYNqgDkO4wUmIY7r2WGco2SOE8di sNFfPCslL2lhfmJg+pvO4jv95+CtOqf+auEEZjxF9JOO5HzwM+/Rp1ZCsHREv+CfRtFKIJ7nWLcI mBRMkiYPL7CFy0RgYRHZYQxpbszLx3gKg4cyLPTOgBJJKonTTUng3GRS8gfjCq88ttNU0mSWsj4Q EC3CT8dtZxz3+dbr4yrzKhaDAIWP4qARLmWt9F/ahK6ymGPmPqsTAZ51SiDnl0igqCAqEiOI0kgo xZTzrke/qxBPurJp21HsS9GGGrmWG0vRFRlYjUKht94q9xzYzDrOWIflbTEGRS5Q6RggJPAKrJU0 d39QDhmqSnr7MFyVNxdpQFtEEwtj1nacpSSM0+76z7jtNn8291PO5TjRBUQNHctHvhHDJYTxgDaJ 4qhEe4g8Vd9FuWsUQcp+l6aNIkgvifYC7rN8ni5jAR3QR47SuKi0dg6HHnpovQ/yqksvuQVav/Ew sjxT6IZdR6/xivQxxggKqEhnqbq7cB228U5o4r0SIkqIworRk0bRSiCe51i3CHhxeWNMqIwjCbKo dDxuaG9E0ialpuvVGpq8avJKWd8IoLvoJ8L7yZBmXFscUzYmAt55yhKFg+Il56CUvF3xfjEbE/0t c9UiCSIDlEPKKIeZpHbKbWksXBXiUu2s2WOPPWqOSBgDk9YH600UEZhErbadc+iPQ0RgKLnGwMmH 9rTaRK8zirXozizCOIFd4CJ3S2RGrp6oiaIHxPpsO/9jeHBMcGBR8PV2YpT5+F3ESHTONiI1ojS+ oxcwNkicVy6RqA1jgzOMAxVrhCFsf3k5zivaQ0F3nY7nPP1+UcYqqqXgg4+xccBypEZhBc8LGiSd xDzinBywdBLbEf3qjMczcPe7373ed8YiYwrlMoTxh9ImyuM6PSPanKIB0n04bx3fNu4LJzDnL5oc jHwvr4jzjyOYUUf0m4KLZ802roX+JJfN78stqIoMUpjVXKps3rrckOfx1yoCFicehGnNWyUcWrRs L1eI118uEO8b3nKp21+LIPA0CTPzQpmELHqjxEvKY8jTwosThRym4ciLxbMobG1iGtXcddoxFvu9 a3fdJrKogrfYY23E/dwrCyCKgeeEUoyr7llBqxjaPHgjYrcerpknlbJhvpFozPMssZnnuushXg/X uhGvQRK995rRM04ouHIpGEIUUn9TrlEmeeEpqJR0Cr3GwvJPKJSjcoOcg6JpDpHITmk3t4wSESjz jTkGnYsCzylDQUcX49EPr/5K3LtpzVuNQZSFIisfSMRjKI2cQSIvCK4UdngygOTrUNxjrY11lMEi IuLeYWuEkdPHgdNTpMP3fu8Lw1NExb1yXvM9o8b2qHTOLxLsHrjvcsimraMiG/QLBopcHdfGmOFg i6arjnHta1+7Ro/gal7xLHieGEMEBuiS9AbRIs8WfUWuU5eV4hlR+ElemvGap9DNPI8Mac8L3cUz w9j0vFnTjNH3rpMByvhn/IR+4vl0DxmDdAjROcYVVswk6t68nkXReM+7c3qOtlI7fF4Hz+OsfwT6 XNuVuGKT9KjEx+U8txeTYYPGIPdnSGKzycDEYVLxwptohMGjQovveeNcC4XHxDFKTFyl30T1CPLm DK0qhzNu8VXcAW93JctZKtP57Gc/u9IFVN5LmR0Bz5x7xhi2OPHAiUBaKCkB7ivvIYWJoWSByel7 c5yD8kJpsmBPq+Q0+51a/B7GxtA1B1CUKK6UCd7o0jOm3nvvu7nDHOLvadSnxY9m8p4xVs6dPm1r uc65Ho/rnRZtYcSIBA8V996z239+I4/ET9GDcRW6hm5nfY3KqI7VnVPiHEONjqHXNmm70uC6GjtH HXXUxMNxxKFeMQyjRcWQ88f71MXV9XcjMbaJaw9sps0jcLTfuHV31HmN13m6BRJs148KTbuuqFg7 qVpbFF2Ydh3OP2qb7vXBhC44bpyjnstxx+1e25BtpmExy/fmXoWqOKg5v0kaRbMg2NlWVRGevZWc LOL0rPSVXCjjReNRWWk6VyzMlIbu5LHI2zZ4N4onxRTWkiclNqaMRwBWPC3C/LxUK/l8rqf74nmP niMWFko95T7Kz8ZiY7uVKle6FvGFDey6FR9Xy3VEDxj3MvrHuOfRb8Y4eX+39DtkvjVWY1vJqPNq uU/zGgeHBuoR59gsRtG8zr/WjjPUKHJdn/rUp2pRCgUnrD0picBQBBh18T6KSoUxm0bRUAQ721ks eOXxJqdZ3Ys4/MRdnG+HHXbYpJLZvM/RP14YI9H4bbnP1z1+9BQQZnbtK+UZp6xIdFSGUwKlhS1l PALC94cffngtMSo3ZqXu03q8JxTQ8MB55k3WflLwfaIy0KjmgusRj8VeE8xWq+EYxq2f0ajZdYaH erHXvBz7zeq1Xo4xrPVjYhyIpqNFp0xGYBajyJHkwnDYMoyif19inAhMQ0AVRtQ5VMIuLTKNomnI 5fcbFgFGr15CQ+lzGxaocuHoDqgMkkUzB2IjPwl57YlAItBH4NWvfnWjMlgaRdOfjVmNIrko9mG8 y1XJ/MvpGG/0LUQYtVBRfEJ+WVey0MJGfzry+sciIEmVsj+t0AKqS3jwu5FDnnzfCdOiofh0/xfb xv54uvERDVhKFDJyAMbRO51zmgd4yDYBHoqXErK43RlVy5cqEUgEEoH/Q0CSufwFSeqjBNWT803/ INW65B9FHqs8Uc4mOa7+j2b57W9/u+bcKOwj19Aao6qXfmf+56MNhOqF1gD7zJpjKkVAJUyRa8nw XRGZMda3vvWtlabq+3HHR/1lDCpYoJLatOjtkEIL3bGItKr0BmNjltzfjb7mc5gIdBGQ963kvEp7 npvNRKGFlEQgEdgcgbKotKUUblsKHoyFx3cll6YtiXptacbZluosC9uWSbotBRXaUmWmLS9i/X+h mdX/lepzbam00paKNW2p2Fa3cYxSeagtjc7aYly0pcxlW6JVbaHUzHR7So+kevxC2dhsv9LzoC2N 4NpSEaYt1XTqePpSkvvbUjShblOq2bQlSbgtxtzEMRTjsWJVjKOZxpobJwKJQCKw3hEoRk2db8dJ qW7WFsNC0av6KVWBFzYtVUUX/l8Mkfr/UrBn4X/mZ/N6caIt/C+O42epUtaWRq11LRkixcHXlvSA Ov/bv5SN3mS30uemzvWFctSWCmNtMdTaUtinLb1lNjt8MXDaEr2pxymV3dpivE0dQjEO21Kieup2 /Q2Koda+8pWvbAuFuy05rjPvnzusbwToanQi71apLjj2YrNPURrRicASEBAh4sGTf6TCkJLb0UOC hyw8d7yERKM4/xO+japOeK08e47hWMpS8mToLcCzqCN0v9u0iFI3p6S84bWJG36sRnSOrwpeVxxf id93vetdtcSqv5UclR8XolwpD8rLXvay6nFTqlIlO54+50hJBBKBRCARmC8CojkqSoagg6HbkShy IbIf0Zhu4Qv/811E6EXr9XmxfhQHWG1KKaqjN4ziUCHWGO0inCv6GKEUmf9tiyVBuqWhrTkiUtYQ /W5EZ1DWVEsVuYo1QrNQyetaQ2gVQUS+pkWJloKqcSpfrgT1cccdVwswWG9TNjYCoqjy+RRVUDjL czuuPD2k0ija2M9LXv0SETDJd+likvd8iMUqFrHuz1jQ/K+7GOpTwJhBe1CO2curLHc0SIuhvuY1 r6klvfUk0BeAeOFLpKr58Ic/XI0t0q2YZ2JAddArQUIqjrvy2foHKCQRi6KxM8r0bEDnsAD6zjlR 5FISgUQgEUgElg8BvYLQ06IkddCopxkUYZDIk1D0RmNQ5Ybf85731MaUaGmxNhm9Of0pT3lKdaSF I0+VPP12nva0p9WCOX3haIuGqdpNWPuitQT6dDSddi6GEoNJr72VEhjpA2QtVeKe0eeacu1aqTuw es5Db+H49R6ccMIJtVms52JaznMaRavnHs48kuh34eZTnuXA4O2aDHxMbibX9S68V6IdFgK9cnR1 PuSQQ6pSj489LsIBP9Xl8LPnIfqLaM7GQHFPZk34FJnR0E1jV03kVNW55z3vWRcsjdLk+BDX5GUX YQpjxn22GBT6wMgGc4XyUKNRRPVCYnJglKkcp1mdY0X38ug1pKEbT6PnKvafB1Z5jEQgEUgEEoH/ QyDWqUJNq+0N3vjGN9Zo0awV1fpr/mUve9nm6le/ej0Rp1m01cAaeMADHlCZBRGleuxjH1vXGg62 UWKttF6QGC9DxDrCWNKagej7otEnx143ArZS93vnnXeu577f/e5XdSHMBx8OR45ETIuU9YWA51F+ 29e//vWmpBBUfZBzWfNYkdOSljDogrP63CCYVudGEjJ5+U1ywueSKUUhCr+4RgR4nEwE0bl4dV7F 0kclCqIjMqVdLwhYeEGE603I97rXvWqX5y7lQBj10EMPbUreTk0m5V3ri6gNAwe9YFzzVlEZC4jF C11BJRMLjWNe7nKXq81XGRu8VXe+850rdU5HaXQ4VAXb8LSZqHn10B268tSnPrWOU7jXImOyZ+C4 v/qH2JfxZTLgtePJ45nT2M6kYDIgjB1N7hiQPHgWRMczFvi9//3vrw0j99hjj7qIKK3NW8jzx0hz XF5FYxklFkoeGc/buK7fsR88eO6c133ycc8YYtGJu38Oixij3+J76UtfeukPTR4hEUgEEoEVQkDU R9GDcdXnODBF/9GXzbH3vve9axNfH+vXfvvtV1kHaHDWune+8501mk8o+ttvv32ljZ111lmVBXDA AQdscmVoZf4vYmTeHzfPxk50COOxvqGEMzAIJyKjjfC+3/rWt65jus1tblPXFrQ6Yw0xbytUZBs/ jXtaAaFZq88NuYXWDkabZtiaqDM0GYvWdUUZrJ3TInFDzpPbrCwC9DhOAD/dY3oFnU9BEikCDKJp BaX6I06jaGXv4VzP5mHwgpssvdAUYdEDL//nP//5piR2NgcffPC6r8QSRpFohwWCUm6CpnwzTixE fprAKeDoYahkJmovkok6JvruDZrVKGLQWNBue9vbNiVxtnrgGGOieIs1ihgiKABecF6+aQYHDCxm JoeuUWQhZBRZpMIoYqD5H/xgwZuIEmHfrlEkemUxYaCJwC3VKGK8Msr+8Ic/1EO5VxYmzfcsnBbw LnXDOKOyEqNI9AwFcNddd53r+5QHSwQSgURgORCYxSjiyDJ3H3bYYXXt4pTi+ebUQ3+bZhQdffTR mzn5UK3l2TBujjzyyKmK4jijSM6rPFQ5ssZSCjjUdclPhhmjiCEXwvnHSNrSRlGMh/LM0KMrYVxo Cs+pzJjMvm/L8eQv7zHlkTFs/dxtt92qToDZwmG8aFnf9SY2xtWpXFOS8WvFFpVqVGApk19bPP4b AgDVclRb23HHHdsyyW1yzYX21ZYXpn3kIx9Z/1+KH7TFC1cxKj2IalWcYrCMxGlI9blilLbFkKjH iXMUw7Qt0Yy2RF7aspBtcg7V6eJ/JVLUlghMWwyAuk1R/DcZh4pvxuq7EoVqXec0KZ7GioN9ysK6 sLnKQFFNKK63GBttMaZrBaFCi2gLPa9WFbJvMX7qviXnqC3RqbbQ6GpFonEyS/U51ZKcoyyWbeG7 t8UorR9VjkpUsy2G5EKVIueE5aMe9ah6/kIpaUsZzbZE4LLS3bSHIb9PBBKBVYHAtOpzqnYW6nWd F4szrY65FAloS6GdhYpyhRFQK4GSUkRg4f/WqcIcaIsiWP9XjKm2FFRoVYkrBQ9qxS1rQnGettac kMJOaIth0BY2QFucZZvgVChItWqd45VI0cJ3hcrdFqOo/r8YQPX/xclW/1aBrji6NjmONUXlO98X h9dm5xl1cxZbfW5V3OgcxJpHIHOKFm1ObvkdVRvj9REN4gGRMMnzryKMnzw3G0XKm1ijQH2usKiQ 8KkICBEmR1OTcNetqrMUnCLsHp4mnjwV21Q86VaNG3eO2F9kSh6UqBaqgzGKMMkBEkGJYg2OK3Ii 4hPRlu6xR9EAUCjxvInKQESeEMxQ8FDSeCKNnYigxU90Ol6YrgdwKXhF76SrXe1q9bpE6XzQD/1E n4gxomsYm/wqEThce15X+Ve8eymJQCKQCKx1BMzDkR8aawaKG7ZB5IBa4+XBku4653/WHt8TEf09 99xz4SOvBqPE/CrqFCLqj04nat+v0uZ4kXuESRBi/RT5QVM3J2vYrTqq3FP/H5X/FOOKn2v9XuX4 1zcCaRStwftLmWUMoWqZSNG2THiXuMQlapM3eSfKcm4kkVcjpH+3u92t0uSUsqbgWyAYKMG/ZliE sTjEYJmGocUDPY5EgiujBE1BPlFInMvP+F3hBAtaGDYMINV68MFRyBhH7ukRRxyxSZJg8fzV49// /vev19wVi2WMJxZZ3zNE5E3BxP7yoFA0GETOFQYX7CLfCA3v4Q9/eKW1PeYxj6k5P8st8GDEqpzH GEMD1fBPzpaxuI9KnVuIFbVISQQSgURgrSMgzwb1h/OqWx2LEWN9950cmKgoyjgxL/v4n/mb48rf 8il876Opaomy1/LU1sJuRVJrJqrRKEOGg8z8Ki+5n0+Liody7nwcVPJdg5I96j6UKFW9LuNKSQRW OwKZU7Ta71BnfPI6eM5V1zD5laaf1WMeotIGTq8KMuu9uEL3tvFkUeZdv8IBJn7GCiWeYs8A4Nnq iyIKFozI9+l/PySniEHDuHBvGBwiGSEqxKkgRNGX3yXpT3UeHjb/c24GrGp5EfXgMTR2C5qxS561 TVcsQCoEMe7kHHUX0cglYhgp7CABtis41K7L/qqx+L4fUWRMMUZw0C14DJFpz9MshRbcJ/eE4S76 ExE2xRycU28LXkz8dVX4GG5wUPSB0afQBO+nfK2IOq2h1ziHmggkAhsMgWk5ReZAxXbMvaIuXUOE E00hBnOdNY0xY7tovSD/klHFQWZdCaaAtcS2o0prg99aYJ2wXtqmO5daU6NKm/VlXAU547J+TJqH jTMKATHCpslyFFqYds78PhEIBNIoWgPPAmVQdTDV5i5+8YtXRTLoYN3hS+4XfWAwbSSJQgsa00kQ tagMkWlGEeVdiWuK+rSKOUPOt563YezpewTTaR5BxTDQO3k3LZIRHbKfJF5GkURJfS/0FvA/dMGo mKTsOsNS/4299tprPcOa15YIJALrAAEFE1SWMz+mTEbgmGOOqY47fZRSEoGVRiCNopVGfIbz8cLo v3Pqqac2QtCUQ1XIUjZFgCdNRMGio1T10FwqtDRRtWOPPbZ28e6LKn6leEKl36EY8LyNEl4y3jne vv42o74Lr1pESGKb2NexImI06nzRF2LcNpPGE8ezTeRhjXuehmxjX9upeqeaDyyn0exUk2PswFYV OTgwOhlI3Ua4ePByjOQyKZ0ewkhF4Rh33/L9SAQSgURgNSEg+kHJVzkzSz+PvzOo09pHcIClUbSa nuCNM5azP6PIxrnctXGljKF3vOMdlXpFWaQAmkyHKvtr4yrnN0pKtbKgfurvMLRZnOiGogVoiKPy U1AYUAciQTSMiP5P5w2DaMh3/e3j7/7PcecLY2iWc44a16TjxzmmbRPbieyIYKJzTqO0KeKgvxaq o+RckT2LoLLcXWGIlup3zcc+9rHaz0lkSZ6RnCj3Rp7TKFrk/J6sPFIikAgkAktHgKPIXBUNuIfM qxtxG/RoeUzWBY7glERgpRHISNFKIz7hfDzjav/LpTAhqMylQlfKdAQoy2h0cBtKdSvlRWvSPmNz XpXopo80t9BLSz6RykrdCNAoZPDRVTjS5wIHHkee4aWXx7yq4eUdSQQSgUQgEUgEEoFEII2iVfAM UPwoinJYovyyRpopicB6REAkVI4cg1/p2CEioqfUvLyj613veoPzxoYcO7dJBBKBRCARSAQSgUQg jaIt+AyoOFaaqTVyLITXRYZU2kpJBBKBRCARSAQSgUQgEUgEEoGVQyCNopXDeuFMaFuMIVW45GIo i4wKlAmYW+Bm5CkTgUQgEUgEEoFEIBFIBDY8AmkUreAjoKeN3AjGkCpbGowqKTw0B2YFh5qnSgQS gUQgEUgEEoFEIBFIBDYMAmkUrcCtZgydeOKJtfa+kpOMoRvc4Aa1mlZKIpAIJAKJQCKQCCQCiUAi kAhsWQTSKFpG/P/0pz/VcsKKKJzznOesJYj33nvv+ntKIpAIJAKJQCKQCCQCiUAikAisDgTSKFqG +yAypHgCY0g06KY3vWlzoxvdqJYTTkkEEoFEIBFIBBKBRCARSAQSgdWFQBpFc7wff/zjH2u+EGNI 0QS9WG54wxs25z73ued4ljxUIpAIJAKJQCKQCCQCiUAikAjME4E0iuaAJprcySef3Jxwwgn1aCJD ++yzTzYEnQO2eYhEIBFIBBKBRCARSAQSgURguRFIo2gJCP/1r39tPvOZz9RGlH//+98XIkPnPe95 l3DU3DURSAQSgUQgEUgEEoFEIBFIBFYSgTSKFoE2Y+izn/1sjQz9+c9/bvbdd98aHdpmm20WcbTc JRFIBBKBRCARSAQSgUQgEUgEtiQCaRQtAv1vfvObzfHHH99c6UpXqhXlznOe8yziKLlLIpAIJAKJ QCKQCCQCiUAikAisBgTWrFH0z3/+s1LW/Pzb3/62oliKFJ3tbGerDVid2zhShiGgUa0P/PRsUpAi JRFIBBKBRCARSAQSgUQgEdiSCKwZo+jnP/958+Mf/7g588wzm//6r/+qxsh///d/N3/5y1+a3/72 t80//vGPFVOwKfKUegZZ27Zb8v6tqXPDCsWQMbn11ls3cq/0bNp5552bi1/84s0lLnGJ5vznP/+a uqYcbCKQCCQCiUAikAgkAonA2kdgVRtFv/71r2uJ6+985zvV+GEI7bLLLs0OO+xQe/5c4AIXqNS1 bbfdtkYf0kBZ3Q8kY1LZcsbs//zP/zRnnXVWo3Lfj370o+Z3v/tdvaeMputc5zrNNa95zWxyu7pv Z44uEUgEEoFEIBFIBBKBdYPAqjSKfvjDH1Zj6LTTTmt23HHHZrfddmsue9nLNrvuums1flLWHwIa 3jJ+v//97zff+973agGLvfbaq7nWta7VXPjCF15/F5xXlAgkAolAIpAIJAKJQCKwahBYVUaRCMIH PvCB5gtf+EJz+ctfvrnRjW7UXPrSl141YOVAVgYB0SPFLDTBZRzd5CY3afbee++VOXmeJRFIBBKB RCARSAQSgURgwyGwaoyiU089tfnQhz5UowIqul3ykpfccDcjL3hTBORsfeUrX2lOPPHEmmt0hzvc oUYOUxKBRCARSAQSgUQgEUgEEoF5IrDFjSKK7/ve977mS1/6Uo0I3OAGN6hFDFISgUDg97//fY0g ih4xjPbcc88EJxFIBBKBRCARSAQSgUQgEZgbAlvUKGIQve1tb2tOP/305v73v3+tQJaSCIxDQMPc d77znc3d7na35hrXuEYClQgkAolAIpAIJAKJQCKQCMwFgS1mFKkU9/a3v70aRAcccEBzsYtdbC4X lAdZ3wgwjE444YTmTne6U0aM1vetzqtLBBKBRCARSAQSgURgxRDYYjw1iu0pp5zSPOABD0iDaMVu 99o/0XWve92ac/ba1762UaUwJRFIBBKBRCARSAQSgUQgEVgqAlvEKFJy+aMf/Wj19u+0005LvYbc f4MhIO/sKle5SvOWt7yl+etf/7rBrj4vNxFIBBKBRCARSAQSgURg3gisuFGkaec73vGO5gpXuEIt qpCSCCwGgbve9a61EawiHSmJQCKQCCQCiUAikAgkAonAUhA4+zOKLOUAs+6rypz+M495zGOac5/7 3LPuXrf/2c9+1nzuc5+r/Yz+/ve/1zLe3aauDC/NX7/85S833/jGN+rnW9/6VqMP0gUucIFm6623 Xjjvb3/72zqef/zjH81FL3rRRY2nu5MS0s4rAnbOc55z4Ss5VJ/4xCeaM888s36XTWiXBvW5znWu 5m9/+1uNOF7zmtdsznOe8yztgLl3IpAIJAKJQCKQCCQCicCGRWBFI0WoTp/61Keaa13rWs2FLnSh mUE/66yzmmc/+9nNne985+be9753c6973at+7nKXuzTvf//7F473y1/+slazU6XM97b18fc97nGP OoaQ0047rbn97W/fvOY1r5l5PKN2cO5HPepRzWMf+9iGcRbykpe8pLnnPe/ZfPvb357LefIgTX2O ttlmm+bjH/94wpEIJAKJQCKQCCQCiUAikAgsGoEVNYpEeL7zne801772tWcesIgQg+hVr3pVrVZ3 0kkn1cp1r3vd62rk5z73uU9t8km22mqrGkXYZ599aoSIIeLnMccc0/zlL39pDjrooObHP/7xwrai Nv/yL/8y85hG7XCzm92sOeSQQ2q+iyCccTvvk570pDrGhz3sYc05znGOuZxrox+EYa3Jr0hg5hZt 9Kchrz8RSAQSgUQgEUgEEoHFI7CiRtHXvva1WmluMcUV0M8YNwyYO97xjs0Vr3jF5jKXuUxznetc p3nZy17WPPnJT25QqkJsv+222za77757c9nLXrZue/3rX7/Zf//9G2WdTz755LqpRrHxWTyMm+4p OvWCF7yg5k495znPaV74whc2D3zgA5tDDz10XqfI4/x/BFDn/vSnPzWKd6QkAolAIpAIJAKJQCKQ CCQCi0FgxYwijVp/8pOfNNtvv31z/vOff+axiq489alPrcbNIx/5yObFL35xbfzKUNpuu+2axz/+ 8c3ee+9dj8sgCoOnfyJlnOUV7bDDDjOPYZYdHvKQh9SoEKPoqle9avP85z8/I0SzADhwWwa2aBza YkoikAgkAolAIpAIJAKJQCKwGARWzChSyODXv/51c77znW+TQgezDFoOyXHHHVer1n3/+99v3vve 9zaHHXZYwwD593//94VDoc+JGinE8OAHP7h+76Ni2Rvf+Mbm4Q9/eHO9611vEwOqOw5jVYDhV7/6 VR1z/+P/v/vd7xqG3iSxDbqeXCiKe8r8EbjgBS9Ysf39738//4PnEROBRCARSAQSgUQgEUgENgQC K2YUMSB+8Ytf1CgNo2VW+eIXv9h8+tOfrpXmNHx96Utf2rzhDW+o+UGOed/73rdWnAtBiWOMyCWS c/LNb36z0uREbuT3dCvD9cfy1a9+teYjMb5GfRhUt7vd7Zof/ehHYy/D+I4++uhKmUPtUnjhz3/+ 86yXndtPQYDxy4hNoygflUQgEUgEEoFEIBFIBBKBxSKwokaRyEm3HPYsg/7gBz/Y7LfffjUfKMSx Lne5y9X/M3xsE6Ly241udKNasvljH/tY/SnKpAKdaNUkQcdTkc5x73CHO4z83OpWtxpLA1RY4elP f3qNSD3lKU+phtg73/nO5pnPfGZV4FPmj0BQJud/5DxiIpAIJAKJQCKQCCQCicB6R2Crokz+bwLO MgsjRYQHhU2UZVb56U9/WktvizY98YlPbP71X/+1Vozzt0pvKG0vf/nLm6td7WrNGWec0ey5557N da973eaEE06YeCpG1l577dUceOCBzRFHHDHrsDbb/t3vfnetMsf4Mp6ISIkcyXuSFyW6tZho2ZIH t04PgCIpeqfsekoikAgkAolAIpAIJAKJQCIwKwIrFimadWD97Xfeeefmta99bSNCg5aGLieKIwqz yy67NK9//eurQRSimeeQBqkodXrdzKMktxwmZbiN68gjj9yEoqc4hEiRfkiq0q2QLbpU2HP/RCAR SAQSgUQgEUgEEoFEYN0jsGYiRd078V//9V81GvTHP/6xRowucYlLbHKjFDdAp0OTU457kvzhD3+o +UZKhfePM+vdV11P/6MrX/nKIyl6qHMKQsS4Mlo0K8Kjt89I0XxwzKMkAolAIpAIJAKJQCKwURFY k0bRRr1Zed1pFOUzkAgkAolAIpAIJAKJQCIwfwTWDH1u/peeR0wEEoFEIBFIBBKBRCARSAQSgUSg adIoyqcgEUgEEoFEIBFIBBKBRCARSAQ2NAJr0ij661//WnOK5A1prNqXv/3tb7W5689+9rO53lx9 hvQc+uEPf1ibsvZFhTz5SXojRX+k7373u43xhqiW193G79/+9rdrflRKIpAIJAKJQCKQCCQCiUAi kAisPAJryihi7Bx77LHNne985+aGN7xhLaV9i1vconnMYx7TfOUrX1lA7+c//3lz85vfvJbZnoco kKBi3B3veMdm7733rh9jeP/7379weM1D73//+zfXvOY167h8lAQ3PkZUiP5F17jGNep3sY1rUbku JRFIBBKBRCARSAQSgUQgEUgEVh6BNWMU/fOf/2xe+cpX1maoGrY+73nPq/2JHvKQh1SDQv+jL33p SxVB2/7mN79pVJabh7z5zW+u57nMZS5Tew+98IUvrI1bH/GIRzT6EpGzzjqr9kxiOL3pTW+qY9PE VX+iHXfcsW6jV5PqdNe//vWbN7zhDXUbx1Zq/IpXvOI8hprHSAQSgUQgEUgEEoFEIBFIBBKBGRFY M0bR3//+9+Zd73pXbXr6rGc9qzZyvc1tblOjM4wKkRf0NaL3kKap0Th1Rkw22xxVTtnn5z//+c1+ ++1Xz80oY3i97GUvq9v/7ne/q32R7nWvezW3ve1taz8lTWpvectbVgMqtkGT83+9jGIb21/0ohdd 6jBz/0QgEUgEEoFEIBFIBBKBRCARWAQCa8YoYuA8+tGPrgaGaNEHP/jB5vOf/3yjZ5HI0Rvf+MZq sJB5N0ZlEGkS223w+qtf/ar2NrrTne5Uz+lvOUdf//rXm0MOOaS5yU1u0jz+8Y9vfvSjHy3cFtEk 0Sv5UC9+8Ysrte6AAw5ovva1ry3i1uUuiUAikAgkAolAIpAIJAKJQCIwDwTWjFHkYm9/+9tXytnW W2/dvP71r6/GxxOf+MTmsMMOa+QRLVWGGlOKLTCS7nGPezQPetCD6mkZaIydk046qRZj2G677er/ HvCABzRf/epX6zYKKigAccopp9Qmrttuu21z5pln1m0+/OEPL3X4uX8ikAgkAolAIpAIJAKJQCKQ CCwCgTXTvPUnP/lJvbxddtml/kRpEyVS5Y2hpArdC17wgho1Ymhc61rXaq597Ws373nPexZgUa2O ISWig4bXF0bRBS94wWpk7bzzziPh/PSnP90cfvjhze6779487WlPq9uTz3zmMzVapAjDhS50ofo/ 47vBDW7QXPWqV62RLMbSaaedVscVx1c8Ap1OFOkDH/jAwvEWcS837C4iede73vWae9/73hsWg7zw RCARSAQSgUQgEUgEEoHFI7BmIkXyhtDNRFqIaBHD4mY3u1nzyEc+stLpjj766PrdKIOn+/9xESEF GuQFjdpfztBxxx3XfPSjH20e+tCHNkccccQmBsyFL3zh5lznOldzvvOdb+FuXOQiF2nOc57z1DHL ibINCl7kGNnwHOc4R80nEmX67//+78XfydwzEUgEEoFEIBFIBBKBRCARSAQWhcCaMYpUdfvTn/7U 7L///jUqo4rbf/zHf9RS3Kh0l7zkJWuZ7hAGjk9XVHhTWlsp7fe9732bfURqRHR22mmnTfZzLgUd RInkECnqgK4nehV9kvQbuuc971mr0yn44PPe9763jtm+jCPbM6iU5ZZrZPyf/exna7RLlCOq1C3q TuZOiUAikAgkAolAIpAIJAKJQCKwKATWjFF05StfuTnqqKOac5/73DUypB8QCtvd7373amy87nWv q72JCGNI+etRDVZnRSlKgSu9zWBSQOFSl7pUPbfPox71qHpI1eQYO29729sqdc9HNEkpb4YcufrV r9686EUvqjlGN7rRjSqtzv6iXY973ONqlColEUgEEoFEIBFIBBKBRCARSARWFoE1k1MUsMjBEVlR 5Q2lbY899miudrWrbUJbU/b6hBNOqMUO9tlnnyUhivaGmheFHPxNUPD8LoeJUROiUasCC4wpEaVd d911s/P/53/+Z40QGb9Grle60pWWNMaNvnPmFG30JyCvPxFIBBKBRCARSAQSgaUhsOaMoqVdbu69 HhFIo2g93tW8pkQgEUgEEoFEIBFIBFYOgTVDn1s5SPJMiUAikAgkAolAIpAIJAKJQCKwkRBIo2gj 3e281kQgEUgEEoFEIBFIBBKBRCAR2AyBNWMUySUaIvJ8+lXnhuw3j22cV55QltaeB5p5jEQgEUgE EoFEIBFIBBKBRGBlEFgzRtErX/nK5oEPfGDzhje8oTZJ7csXvvCFWv1Nfony2ENFwYRTTz21Fm5Y qmjWqgrdE57whFqIYYgo2a3UtxLeKYlAIpAIJAKJQCKQCCQCiUAisPIIrBmjSLU2Zbef97zn1Wpw XfnZz37WvOxlL2te8IIX1J5Fv/jFLwYjyRjRe+jYY48dvM+4DUWplNv+3ve+N7aBbH9f/ZJuf/vb N9/97neXfP48QCKQCCQCiUAikAgkAolAIpAIzI7AmjGKzna2szXbb799c53rXKf50Ic+1PzhD39Y uFrNXEWPlMbW62dUvx9Gx0c/+tFqsIT89a9/rY1czzjjjEYp7Y9//OPNb3/72/o1KpwIkoauX/rS l5o///nPI9FlgJ100knND37wg2brrbduLnCBC9ReSl1x/A9/+MPNJz7xiU0MNvtq8OqcX/ziF2sp 73/84x9117POOqv55Cc/Wfc7/fTTNzu3xq++01g2JRFIBBKBRCARSAQSgUQgEUgEFo/AmjGKGCkX utCFatPW73//+wsUOUYEo+jCF75w7feDttalrokEPf7xj2/ueMc7Nve6170qve3Zz352Nap+/etf 12aq5D3veU9z//vfv/n2t79dewjd5S53ae52t7s1BxxwQHPXu961ecQjHlENpxDjOe644+pxbatB 6/HHH98wtMIo+9GPftQ85jGPafbbb7/mfve7Xz3/Pe95z+bEE0+shznllFPqecmznvWs5qCDDmp+ +ctfNq95zWvqPhrTPuABD6iRLFGwriGIctc91uIfgdwzEUgEEoFEIBFIBBKBRCAR2NgIrBmjyG1S bOHa1752c9GLXnTBmGAgnXzyyc2tb33r5oIXvOAmRRbk6xx88MHNN77xjeYVr3hF85GPfKQaFxq7 Hnnkkc0OO+zQPO1pT2v+5V/+pRo2b3/725tddtmlOeqoo5pznOMczatf/epq6DzucY+r1L1DDjlk 4WkR9XnqU59ax/POd76zOfTQQxs5RSJW9iXOIwJ04IEHNu9617vqMWwj7wnl74Y3vGE1lIj9X/rS lzZnnnlm87a3va1GxBzX787x5Cc/uUG1C9l3330rBre5zW029hOcV58IJAKJQCKQCCQCiUAikAgs EYE1ZRShsF3iEpeo0SLUNlEikR3G0rWuda0apSFbbbVV/SkS8+53v7uR6yP6w0ixH2OJkfTzn/+8 Hgs171//9V/rMS5+8YvX/CSRGtQ5uUYodiQKPIhEMZzOda5z1eIOe++9dzVwRG623Xbb5i9/+Uvd XnTp+c9/fo1siSodc8wxDdqbiI+PyNeuu+5at2X4XOEKV6jjkRfF8GOkvelNb2q+/OUv12tQ2S7k Ihe5SHP961+/GnYpiUAikAgkAolAIpAIJAKJQCKweATWlFGEsiYKc+UrX7nmAYnCiNgwIBgzYYwE HKhov//976vhxLg4+uijmze+8Y3NNttsUw0QxhFDy3EZHYRh9ZKXvKQaO2hwDA/GznnOc55qPBFG EeNGhIlhFHL+85+/Oec5z7lglBnbQx7ykJoTdMUrXrEe56pXvWr9Pih2//M//1N3j7GLID32sY9t 3vrWtzY77rhjc9vb3nYhGjQqV2rxtz73TAQSgUQgEUgEEoFEIBFIBBIBCKwpo4gx8sc//rG56U1v 2lzucpdrHv3oR1dK3H3uc59qZIRhE7f2ete7XnO1q12tuclNblIjRYosoNI97GEPq/tc+tKXroaR /cIo+c///M+a37PTTjs1z33uc2s+kXwl20UEinEkh0ikSQTIuOyv4II8JYYRedWrXlVLfaPoPehB D6oGkfGLcIWBFYUVog+T6BbK3u1ud7ta2vsWt7jFQo4UIywlEUgEEoFEIBFIBBKBRCARSATmi8Ca MYo0REUfE9kR6bnsZS9bI0WiQXvttVdFheFCwsBBtTvssMNqno7KdKhpDCXGSgj6GeoaOt1973vf aqwwikSXRHducIMbNM95znMq1U10KCh0UYiBwaPAgwIODCDjC5qbIg277757NWxQ8+5xj3tUQ0o0 KkpwX+Ma16hV9Rhpij64FsdGu9tzzz0buUNKkDO0jCmMKBX4nBfFLiURSAQSgUQgEUgEEoFEIBFI BBaPwNmfUWTxuw/fUzRGoQCGBkNhVmEMiA7J31HyWk7Nec973ubOd75zc+Mb37hGimyz3Xbb1UiS 6A651KUuVQ2h853vfPVvhoQCCYwNojgDQwT1zTaMIN9d7GIXqxGkKHKgl5DzMcaU3Uabs50xMcL2 2Wefatg4HuOLQePcCiYw1i55yUvWHKNHPvKRNQ9o5513rnlMtrEt8bfcJMdlnDH+GFuKLIgyOTb8 RIx+85vf1KINxufYG1nkfKFP7rHHHhsZhrz2RCARSAQSgUQgEUgEEoFFIrBVoX61i9x3pt3kzigv jY6GGpaSCMwLAdX8GL73vve953XIPE4ikAgkAolAIpAIJAKJwAZCYM3Q5zbQPclLTQQSgUQgEUgE EoFEIBFIBBKBFUQgjaIVBDtPlQgkAolAIpAIJAKJQCKQCCQCqw+BNIpW3z3JESUCiUAikAgkAolA IpAIJAKJwAoisGaMIv2GNDydJPoNqfwWTVz72yq3rZGqCnFDRbW4H/7wh7VB7DhR9EA1uah+N/TY tlPNzv7jRN8ix1Z9b5yowKcXknLgQ0VpcCXKf/zjH9c+TV1RsELFvtNOO23ho/Ldj370o022VY3v O9/5zibbGOss+A4db26XCCQCiUAikAgkAolAIpAILBcCa8YoevGLX9zc/e53r+Wxf/rTn26Ch1oR ylZLuNcgVWnsvqjUpiS2Etivf/3rB+Opieutb33rWo57nDieqnFf+MIXBh/Xhl/5ylea/fbbrzZq 7QsDRB+mG93oRvXYt7nNbZrXvva1tc9RCCPo0EMPrX2YbHfLW96yed7znler0o0Txt2xxx5bq9qp 5Ge/Bz7wgc2XvvSlhV0YgrDSuNb3Pra93/3uV5vhEgagfk8KHMQ2xqn8eJQbnwmM3DgRSAQSgUQg EUgEEoFEIBHYQgisGaPoW9/6VqP0MoVeae+uiOQcffTRzTvf+c5qHEWfoO42733ve2v0Q9lrvX0m GTnd/URxGGHRH2jUfWIoRP+hIfdRJMs13P/+929OPvnkzSI1KvU985nPbDRyVcZbr6XLX/7ytQns hz/84XoKhiBD8S1veUut6Hf44YdX4+jII49s3vjGN44chn1e+tKXNgceeGAt8c3AfNKTnlRx0Vz2 y1/+ct3vt7/9bSNCxRBjZOmZpJHtYx/72OY85zlP3cY1/+QnP6nlx507tnHMXXbZZQgMuU0ikAgk AolAIpAIJAKJQCKwKhBYM0bRVltt1ey44441avKxj31sE8OHYYFeJkqhh48eP135xS9+0bz85S+v xsNxxx3XoNEdc8wxg26Apql6EnWPKUry0Y9+tB7LeaMHUv+8o06gp5E+SW9729vqtZD+fih+GtM+ 9KEPbf7t3/6t2X///ZuXvOQltUfRJz7xiWoQMVzgcNvb3rY56KCDao8kUSPRok9+8pMLVEMG4+te 97pKcxMlYnCJ8DBkNKvVYNbvX/3qV6thSeCjJ9KjHvWoelylrhlwjCR4hOFk3MqsO45tRJJgvO22 2w7CNjdKBBKBRCARSAQSgUQgEUgEVgMCa8YokveiaerVr371GqE49dRTK36MDEaAZqsaqYro9Fsv RfRIA1bNVxkjIjXyeWYVlDdGCkOA0SKiI4rFGGO4TRNj0yBWBCYayPZzej796U/XXB9GYIjjX+hC F2o+9KEP1XHL9/nmN7/ZXOISl9jklCJhn/vc5+qYyL//+79XWuFJJ51UDZqnPOUpDUpgV84666za ADaMNMfXuJahZFvjPOKII6ohFoK6B3tRphe96EU1SsXYc29SEoFEIBFIBBKBRCARSAQSgbWEwJox ihgcaGfoWuhZ6HBEsQBRFQ1hUbv6BpEcHDk7Iir2JaIvKHaMpaFyjnOco56fEcQgOP7445tvfOMb 9bioc4yxIZEiUadb3epWzU477bSQn9MfA7qecTOEugIDRodIFcNFlCoiN7GdvxkvYfCJnsFoXGNT BRRe85rXVJqePKMwpOzz7ne/u14jA0lkjRHoWgmDyb4w/PznP1+jUCeeeGLNT/JdSiKQCCQCiUAi kAgkAolAIrBWEFgzRhFAVTVjTOy5555V8RapEC0hV7va1UZWnWM8ffzjH6+fu93tbpXe9eQnP7ka Cq9+9aurgSGyouABo4CR8/jHP36zSnLnPve563ZyehznOte5TjXORH0YW4wRRsrBBx9cj+F4CkPE +EY9EOMiS87lu34EyTEYfmc/+9nr+UZtYx/GVBhL22yzTc2jCopfdxyoeAzE3XbbrVLqHI9RyZCS nyU36V3veleNxL3pTW9qPvOZz1TMiIIVDCWUO0anbU444YSaq4WOlxXo1soUkONMBBKBRCARSAQS gUQgEVhTRhGFXTSGUSRPiCIur+biF794pc8xkrrib9GOnXfeudLMlK5WmU1ezXWve90a6fjsZz9b ozwoZCIsCgiIIvUjTgwG0RBGRz8i1DVQ7B/HUKShP6Yhj5yqbwyZfgly5/fddttt11zhCleony6l zbGN/UpXulKz++67jz2VcTFo5EUpniAXiSFGXKfjX+QiF9kkN2jXXXethtbXvva1is1FL3rRivkO O+ywcJ7tt9++Of/5z1+3gXFKIpAIJAKJQCKQCCQCiUAisBYQWFNGEYMErUyOy5WvfOVK5xIBkt8j eoLmFYq9n/KGlMl+2cte1nzgAx+oeTU+H/nIR+rfN7vZzWpVtatc5Sr1/yInPuhkIiwhjIAwpG58 4xvXkt5ydRhmIlboeyIjDAIFERhrjoNOxoCbVfbYY48ahXrPe95T6XKMOdcp6sQo2nrrrWvEDAbO IX+IsWcsn/rUp2reVeQjMcoUTggjRS6Sogl+yo3aa6+9KtXOtUS5b9EwBRtE2Zzb/ir/MQaVPGc4 yekSDXvFK15R97WdXCgGl+PK/0pJBBKBRCARSAQSgUQgEUgE1gICa8YootSjulHy0cNEQvTy8Tcq F4mmrYwYURbREH100MH6goaGMnbGGWdsklvUp7Q5pw+jxz6iKgwmRRtEm9DHokz1uKax4x6EaAjb 309BBbk5Ii7oeQwXVeLQ9FDyCCOQceP6VYWzDSNF5TfX5XvCwLn2ta9dq9053wtf+MJq7Bj3ne98 50o7vNa1rlW38R2JinJKgDuuAgyMPVEl1EDCaHrCE55QaXUwth3aIWohY3VIftVaeEFyjIlAIpAI JAKJQCKQCCQC6x+BrYoB0a7EZTJqKNtyehRFmFVEKuSrULpFZDQIpfCLmFDUFULQ10cTUso+w0UR AEr/OCoZ2pyIkaiG5qSjxPeiNYyRiH4otCDaJDpypzvdqUZpRIcYSqq4DRVlsh1/n332qdGqvsh7 kscj+qJPEQPpvOc97yab6SdkG9XqUNxcB/pbiCiSiNPNb37zWtJbnpDcJ1E3kbXII/IYMLpUkSO+ 17cIvRC1ToPWy1zmMpuN0fFFpxxLFEv/o5UW1fUYZuOKSaz0ePJ8iUAikAgkAolAIpAIJAJrC4E1 YxStLVhztCuJQBpFK4l2nisRSAQSgUQgEUgEEoH1h8Caoc+tP+jzihKBRCARSAQSgUQgEUgEEoFE YDUgkEbRargLOYZEIBFIBBKBRCARSAQSgUQgEdhiCKwZo2iW1Kdx28p7mbVUtCII9pl0fgUMbCNH aVZx3Ci4MGrfIWOW/6MYxKxizKPObUwKS0SRCT9VpvO/SThEntKs48jtE4FEIBFIBBKBRCARSAQS gS2JwJoxipTJVv1MFbV+bx4AfuUrX2me//zn12ak+g/1RXEBhR6Uqz7++OMHY/6MZzyjVnf7+c9/ PnYfxQsk+ivyMIs4pgpymp/2Rb8h5a6VDVeE4UEPelAt8901vBhs8FDgQRlvRSwUVZjWOFUT2kc8 4hG1CIXKcs973vNqMYkQhSMUlnBeZb999D66y13uslnvpNjnzDPPbO53v/vVogspiUAikAgkAolA IpAIJAKJwFpCYM0YRQyCI444ojnkkENq1bmu6KPz0pe+tHnmM59Zf44yYPT5UTFO5ThlpDVYHSL6 +ajANsnQUNZb36JRxtq4cyi3rb8Sg8qYuiJ6c/jhh9f+Spq43vrWt24YHcp0q3IXwlBUNvt85ztf NYwYTA9/+MObt7zlLWMv7e1vf3tzn/vcp2J0q1vdqlaLs/1DHvKQWuKcGI/+The+8IVrpUBGobLm Ktup8tcXWDJY4TprJG7IPchtEoFEIBFIBBKBRCARSAQSgeVEYM0YRUpHKzWtJ5FS29FoFDgnn3xy bTCqtLX+PP0eOaIuL3rRi6qCL7KiFDbjYIgoR60Mdv+YDIivf/3r9RBRqlv/pGmCDnfkkUfWfkex n2asXWFkfehDH6q9iV772tfW/kHHHXdcc7GLXawadkTkS8RLM1lGjSjZO97xjto7yb76F4WBw6gT /RFZ8nv0LXrBC15QDS8/YfqqV72q7gPLi1zkInWczu3ny1/+8mr4nOtc59pkrMqS+/4b3/hGxeic 5zznNAjy+0QgEUgEEoFEIBFIBBKBRGBVIbBmjCL5KhR1RtHpp5/eiOAQ/2cUMTDQvOS89PNeULq+ //3v155Coh2oZgyKxeTh/PSnP22e+MQnVgNM757nPOc5jV5BjLF+49dRd1oUiOHw5Cc/uUZsSD8X ieEiMnTZy1524RAauu68887VKGLk6dOEJqh/UYjz60UkysPwIyJkqH0oes777Gc/u3n9619fG+CG iDSJCkWPpV/96lfVwDnrrLOqEWms/eicffVPOuiggyre+kfBwP1ISQQSgUQgEUgEEoFEIBFIBNYS AmvGKKJ4i7KIcjAQ5M6QH/zgBzWPBb3L//tKuX1EUvbdd9/6IQceeGBtdnrSSScNvleMCMdG3zvx xBObpz71qc2xxx7bXPziF68RI+PrR5NGHVzkCcVNPk832tXdlsHDIOlHXRg9DCHfMcREaRyvK/5m uPmeaKgqCoQCRzS17VLgGDZob/vvv3+l85FvfvOb9TzoiiJsIlCPfvSjqzEYtENjh4UxovDtsMMO tWgDwyglEUgEEoFEIBFIBBKBRCARWEsIrBmjiEEgX0U0Q7RIUQMRFhEj+T6iIaMqqX30ox9tfBgQ oiQUeUaCvJlXv/rVlWb2rW99q3n605/eKKrA2In/940NeUMMBMaDogKKINzrXveq42EMMBREYRzD 8Zwv8nRGPRTjKrmFYTHqewYNLMIAG3eM+B7l7uY3v/lCFKg7DteNogdXBg+DyvFgzNBRgOGEE06o +VKMo2OOOaYagnCOaxMpcq7IJXJPMlq0lqaAHGsikAgkAolAIpAIJAKJwJoxitwqyracFpXQRIgU KxAlQv1CLesXQ6Dgo8lR1FVXe/Ob31yV+ne/+93N+c9//ubTn/50jYr4Dr1M3o7P+9///oWcnHhE KP5ybVDX0Pi6su2229boi/OLIsWxnEvUZlZRIW+nnXba7Hpcv+9c72677dZc6lKX2qwa3B/+8Idm 9913r9+NE9EzdDj5SoxJVe4uetGL1s0ZXPKUGHtohq4VVqrUwV7lOvlYhx12WI2QqeiHkig3iYjC MRj7xSNmxSC3TwQSgUQgEUgEEoFEIBFIBFYKgTVlFDFyRGNQ5Sj+FHDK/b3vfe9K46Lsh2Lvp0pt qtYpQoAqx4Dy8X/GiwiPQgJ77bXXwnef+cxnakU4eTZdYfBc5zrXWSjpLfLE2GIoMc5ESi54wQs2 Rx11VDW2fJwb3W9WueY1r9nssssuNVfKeZ1HHhVaHTocCpyqdPKHTjnllGqo2UYxhS9+8Yu1lHbk Bzm3yE5ElFSdExX6/Oc/X8t8w1CECHaxDbqhnCkRIsf1nd8dh8HEAFWt7qY3vWk13i5zmcssGFW+ c+4hRSdmxSW3TwQSgUQgEUgEEoFEIBFIBJYDgTVjFDGG5LMwPhgsihAwPCj5N7jBDSo2ESmiyKPF MVAufelL14IGKtdtv/329eP3XXfdtfbqYQQpbCAnxgfdTG5SFE1wXpXenFeEBq1M0Yab3OQm1Th7 7nOfW8cVOU8MI8dwLNGXUSWs40aqBkeiUlz83xjvcIc7VKoe48R5FIlwfr2ICCPQ76q+yZVSXhud T4RG76M478c+9rH6f9ExY0SDkyv03ve+tzn44IPrd67FTxEjomiCohWodc7t8/jHP765xz3u0ey3 3341MvTKV76y4osuqDS48ZHHPe5xtTR6VNZbjoc2j5kIJAKJQCKQCCQCiUAikAjME4GzlzyaZ8zz gOOOJdrwvve9r0Y3RHlmFYYHQ4aRcJ7znKdSuij+t73tbatCLzLBgGEwMRDk5fzHf/xHc8973rMa RqPkEpe4RKWEibyMG5PzinwwPGzHGFN1jkHjnHoHofOJthhH0NCGXF9Egewn8hPCIBMtEvFhMLkW 1yTCIyoTcoUrXKFGr4jxiCLZJv7n/zBAc/M/URyRJTgyDJ3HuOEZtESUOXRAhpBt9F7acccda1SJ sWXbUaL4g+8YWLNgMASnadugOyp4YewpiUAikAgkAolAIpAIJAKJwKwIbFWiB+2sOy1me5EW+Sei G/oFpSQC80LgwQ9+cM2NQqNMSQQSgUQgEUgEEoFEIBFIBGZFYM3Q52a9sNw+EUgEEoFEIBFIBBKB RCARSAQSgSEIpFE0BKXcJhFIBBKBRCARSAQSgUQgEUgE1i0CaRSt21ubF5YIJAKJQCKQCCQCiUAi kAgkAkMQWDNGkUICQ5qC2k71uVGih4+y1UOOE/urPKei27hj2u5Pf/pTPW5UkxsCvG0UJ5jWzyfG POn88rWcv1/FbtI4pJL96le/qpXz+uI7BRaUG//FL35RP37/zW9+s1C2u7uP711LSiKQCCQCiUAi kAgkAolAIrAWEVgzRpFS0kpFv/SlL60Kel/0BNJzR9NRfYP6wvi4+93vXiu66UM0VJ785CfXimo/ +9nPxu6iJLVqcXr/DJHTTjuteeQjH9lc61rXaq52tavVMSud3a15odS48t8qyhmzUthve9vbamnw EAbNi1/84to7SAntm9/85s2rXvWqatCMk6gCeJe73KW56lWv2lz3utdtHvWoRzXf+ta3FnaBr5Lg qtupFhgVA5XdZiSGfOc736kV6WynH9Ohhx5aS6SnJAKJQCKQCCQCiUAikAgkAmsJgRU1iij90f9n VpA0D9W3R38cJZi7cuaZZ9ZeOa997WvrNqOiLx/4wAdqTx+9fo477rgaWRkilPzvfe97C41hR+3j fGeccUaNGE0T59XL5ytf+Uo1KB772MfW8T7sYQ9bMOZEfPT6UcKcMXTQQQfVEuSPecxjmo9+9KP1 FLBkIL7sZS+rfZqe/vSn19LgKqwfffTRI4chQgYjjVfh8KQnPanZf//9my996Uu1tDh8iPH86Ec/ qkbWIYccUsfyrGc9q5bl3nrrres2DE+VBH/6059WY+i+971v7Vn06Ec/OqNG0x6C/D4RSAQSgUQg EUgEEoFEYFUhsKJGkb4+i60Afrazna32yxE5OfHEEzehfWnAKjpyy1vesvb08ekKQ4TxcMc73rF5 05ve1Pz4xz9u3vKWtwy6EYwAvXycPwRN7uSTT65GC0NIbyTSP++oE5x66qmNCAvj5QlPeELzb//2 b9XQ04xVM1rygx/8oDaVZbyIFj384Q9vXv3qV9ceSR//+MfrNq73gx/8YHOb29ymNpC17Ute8pLm pje9ad0mDDQG4zHHHNN897vfrRTA6N0kouS4mrI+//nPr1Gu173udfXYIkWarzLYHvrQh1aDTWRL pC6Moh/+8Ie1/5NzOnf0R2JgTYpUDQJ9ERst9rlaxKlyl0QgEUgEEoFEIBFIBBKBdYbAihlFDAbR iSHRlFEYi3JQ1NHURDG++tWv1s3+9re/NZ/61Kdqw1A0L8pxX0H+yEc+UhV99C9UNJSxd73rXYtS 3r/97W/XCM897nGPalSIopx++um1keuQKNgnP/nJSoHbaaedFi5z++23r5Gg9773vdVwYaAw3DSX DdEY1XYMQrlAzomG129Mq7nrF77whQU6HCMFrZChpNktI4sR1BWUOo1dYUvkDsGbIWVb1yrCpDlu iKa5xx9/fD0/Q/PWt751xViUSrPblRS4wz8lEUgEEoFEIBFIBBKBRCARWAwCK2YUibRc5CIXqRGe SUUDxl0EQ0eERh4Og+I973lP3RS1jRGhIex5z3vezYoo/PnPf65RIREVeS9E1ANFjIExVCjdDDAR HkYZI4ERc6Mb3ahS5xgRQ4yioNl1lfjYjxHiGhlECiwwYvoiQuO7X/7yl9WoE2Hqir9FxhQ/IPvs s0/z4Q9/uEbJSN94gJ8olGgPOhxBVfR/uVeMKccSEWIEBu2QkWvc7uWFLnShahwZr9woRttKCSyM hcGckggkAolAIpAIJAKJQCKQCCwGgRUziiiuojm/+93vNikWMHTQFHC5NiIaV7/61WtODoVcgQA/ r3GNa4ysvnbCCSdUWpp8GVQ1VDDUMVGNo446qkauRFMe/OAH188BBxxQ82e6BQ2MEYVOBOZDH/pQ c5/73KfS1BRJkHfD2GJsKELwvOc9r+beOJZzdQsYOM65znWuSsUbRfcSDfJdUNRGbWMcsGSAwKRf Sc8+vg9jadttt2323HPPin1fUAAZOjvssEPFxn72hyVKnzwthh/jkREo4saA6oqxihIphIGiKF/r 4IMPnrkS39DnoL8d4xb2F7zgBRd7iNwvEUgEEoFEIBFIBBKBRGCDI7BiRhEFXjRBYj7DaDHCAKAA q5rmOGhzIhkiR/KN+iWx/Y0mJ+eHsfHlL3+5GlMocLvttlul4DGI0ML8rniAn6Ik/WiW/W3HWOpH Zxg6DAr7iPY4h+MwxEQyuiIniqHSNbpcl3333XffahCJhqHOdelqjoHmttdee1UD53KXu1yz++67 b1bUQGls1eDkH40Txtvb3/72mhPFCHzhC1+4kBflPl3+8pdv9thjj2aXXXap44E5aqLf4UVgJCrU LQPu/qJIuif9sS/mfg/Z5/vf/37FnrGckggkAolAIpAIJAKJQCKQCCwGgRUzigyOYi0ygwI2q4hg MB4YGYwHldZUOqOYq3xGMUZvI0FHU4jgs5/9bPPyl7+8bqd4gY+8HtEPpawVKRB5OuWUU2rxBNuj jaHikchRYsQwSPbee++aNyOnx1gUTWAo+B6FSyTFMRzPeRg4XRFVYlyooIdmxohRGQ8djsFEGCQX v/jFayEFhRGcx/EYc9e73vXq/gwWZbgZIPBkhBiL6xMZipwlmKAshsHImEGV++Y3v1mLKNz+9rev 98Q2YeAwlm5xi1tUjJzbd1HgQSlvwuhTeEFxBtfA0FIW3TWJpK0UnY2hy8js5l/N+mzl9olAIpAI JAKJQCKQCCQCGxuBFTWK5BRd5zrXaU466aSZ84oo7hRvOUIiMyIhIjEU9jA8QqlnPNmOcYMKpiiA aEf3Q2lHHWNIoIXFd2hp3UpzjI04L0NJTpGozs1udrN6XhS8qDrHALGvYzjeqGp0xi13h2HFyHIM JbdR0ByTiLYolc0QkrPEaGP4iQAxRIjj2wZ9zH4MoVvd6lY1ioW6F7lD8okYWXocGbeo0LHHHlvp cPKsRIUYVwpQHHHEEfXYCkkoSqFkt/ExxBiPj3jEI+r/iX2VCEexcx2MPZXs9DeCaxfD5XrF5Hah QTp/SiKQCCQCiUAikAgkAolAIrBYBLYqkZB2sTsvZj9GyOGHH14VbvSvofLud7+7FiBgHDBoRE1E NEQIKOoMEXQ6kRLGAsqc7+X9iFCNEkaMbRQKYHyMEudV1tp5I29F4QGRHlEc5xLlEVXRHHbXXXed eklocIoZyHVi7DEUGR7yhboimuOaKP6u44Y3vGGNinSFYSAihUaGUuc6upXtUAIZhwwxtEORHeN1 7T6iah4BBpOiDMqaE98pYOH822yzzUJ0rn9xIkaicLZ3bkbUkIITU0EasMGb3/zmahirANjHbsDu uUkikAgkAolAIpAIJAKJQCJQEVhxo4gCTklnaDCMRH1SEoFZEUADVNiBIRpVBWc9Rm6fCCQCiUAi kAgkAolAIpAIQGBF6XPVCiuRCRQrOS4oXSmJwKwIoEaiH6L8pUE0K3q5fSKQCCQCiUAikAgkAolA H4EVN4oMAP1Nwj5qlzLXKYnAUAREGhnT8rUY1ymJQCKQCCQCiUAikAgkAonAUhHYIkaRQfPyy3OR sxNlnpd6Mbn/+kdAHyS5ZXpArVSFu/WPal5hIpAIJAKJQCKQCCQCGxuBFc8p6sP9xS9+sTn++ONr BTWJ/imJwCgEFKR45zvf2SgsoTmuhrMpiUAikAgkAolAIpAIJAKJwDwQ2OJGkYv41re+VSlRevPo m6N0d0oiEAicdtppNaIoMnSPe9xjswp8iVQikAgkAolAIpAIJAKJQCKwFARWhVHkAvTbofj+7Gc/ q2Wdffrlp5dyobnv2kNAVEgjXEaRkuU3uclNRvZ+WntXliNOBBKBRCARSAQSgUQgEVhNCKwaoyhA +fKXv9yccMIJtW+OvKO99967NjNdiWagq+nGbNSxqEqoXPsnPvGJ2ntpl112aW53u9vVKGJKIpAI JAKJQCKQCCQCiUAisBwIrDqjyEX+85//rFXpPve5z9UGqRe72MVqY1J5JJRjzVbTSFqOx2Hlj8kI 0pxWhPAnP/lJo7nvH/7wh3q/RYd22223lR9UnjERSAQSgUQgEUgEEoFEYEMhsCqNou4d+P3vf998 85vfbL7xjW80Z511VrPNNtvUhq/6HaVhtLafVcaviOAf//jH5m9/+1uz0047NVe60pWay1/+8kmT W9u3NkefCCQCiUAikAgkAonAmkJg1RtFXTQ17Tz99NObX/ziF7X5K4Pp73//+5oCPAf7vwhsvfXW zfnPf/5q4F7iEpdodt1114QmEUgEEoFEIBFIBBKBRCAR2CII/D9Z0StczqaQhQAAAABJRU5ErkJg gg== --_004_2F2059F256F9B24F82EAC5EE47F446C6E774F768szxemi502mbxchi_-- From nobody Thu Nov 24 05:29:31 2016 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 908EB12951A for ; Thu, 24 Nov 2016 05:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 hQXZ_wI38BcU for ; Thu, 24 Nov 2016 05:29:27 -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 2F093129466 for ; Thu, 24 Nov 2016 05:29:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVW71317; Thu, 24 Nov 2016 13:29:23 +0000 (GMT) Received: from SZXEMI413-HUB.china.huawei.com (10.86.210.41) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Nov 2016 13:28:53 +0000 Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.216]) by SZXEMI413-HUB.china.huawei.com ([10.86.210.41]) with mapi id 14.03.0235.001; Thu, 24 Nov 2016 21:28:42 +0800 From: Gaurav agrawal To: Phaneendra manda , "sfc@ietf.org" Thread-Topic: [sfc] Review comments for draft-agv-sfc-packet-loss-measurement-01 Thread-Index: AdJFh8dU9j7De4XRQn2cOmj7omWbvAAx2C3w Date: Thu, 24 Nov 2016 13:28:41 +0000 Message-ID: <2F2059F256F9B24F82EAC5EE47F446C6E774F9E6@szxemi502-mbx.china.huawei.com> References: <6A6AEA8F97B29F4585E1A9F4BE8838747E3A9B30@blreml501-mbx> In-Reply-To: <6A6AEA8F97B29F4585E1A9F4BE8838747E3A9B30@blreml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.250.69] Content-Type: multipart/alternative; boundary="_000_2F2059F256F9B24F82EAC5EE47F446C6E774F9E6szxemi502mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0207.5836EB34.00FC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.216, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 065cbf7b58c872eb4a8dbffc49a865aa Archived-At: Cc: Aruna kumar padhi Subject: Re: [sfc] Review comments for draft-agv-sfc-packet-loss-measurement-01 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, 24 Nov 2016 13:29:29 -0000 --_000_2F2059F256F9B24F82EAC5EE47F446C6E774F9E6szxemi502mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUGhhbmVlbmRyYSwNCg0KVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrIGFuZCBzdWdnZXN0aW9u cyBhZ2FpbiBvbiB0aGlzIGRyYWZ0IGFzIHdlbGwgOikuDQoNClBsZWFzZSBmaW5kIGluLWxpbmUg Y29tbWVudHMuDQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCkdhdXJhdg0KDQpGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoYW5lZW5kcmEgbWFuZGEN ClNlbnQ6IDIwMTbE6jEx1MIyM8jVIDE4OjE4DQpUbzogc2ZjQGlldGYub3JnDQpDYzogQXJ1bmEg a3VtYXIgcGFkaGkNClN1YmplY3Q6IFtzZmNdIFJldmlldyBjb21tZW50cyBmb3IgZHJhZnQtYWd2 LXNmYy1wYWNrZXQtbG9zcy1tZWFzdXJlbWVudC0wMQ0KDQpIaSBBdXRob3JzLA0KDQpQbGVhc2Ug ZmluZCB0aGUgYmVsb3cgcmV2aWV3IGNvbW1lbnRzIGZvciBkcmFmdC1hZ3Ytc2ZjLXBhY2tldC1s b3NzLW1lYXN1cmVtZW50LTAxDQoNCg0KMS4gICAgICBJbiBTZWN0aW9uIDEuMw0KDQogICBUaGlz IGRvY3VtZW50IGRlZmluZXMgdGhlIGltcGxlbWVudGF0aW9uIG1lY2hhbmlzbSBmb3IgdGhlIHBh Y2tldA0KICAgbG9zcyBtZWFzdXJlbWVudCBhcyBwZXIgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQg YXJjaGl0ZWN0dXJlIFtTRkMtUE0tDQogICBhcmNoXS4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEg bmV3IE5TSCBtZXNzYWdlIGZvcm1hdCBmb3IgY2FycnlpbmcNCiAgIHBhY2tldCBsb3NzIG1lYXN1 cmVtZW50IHJlbGF0ZWQgY29udHJvbCBpbmZvcm1hdGlvbi4gSXQgYWxzbyBkZWZpbmVzDQogICBv cGVyYXRpb25zIHRvIGJlIGNhcnJpZWQgb3V0IGZvciBwYWNrZXQgbG9zcyBtZWFzdXJlbWVudC4N CiAgIGNvbW11bmljYXRpb24gbWVjaGFuaXNtIGJldHdlZW4gbWVhc3VyZW1lbnQgY29udHJvbGxl ciwgbWVhc3VyZW1lbnQNCiAgIGNvbGxlY3RvciBhbmQgTUEgaXMgb3V0IG9mIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQuDQoNCiAgIENhbiBiZQ0KDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0 aGUgaW1wbGVtZW50YXRpb24gbWVjaGFuaXNtIGZvciB0aGUgcGFja2V0DQoNCiAgIGxvc3MgbWVh c3VyZW1lbnQgYXMgcGVyIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IGFyY2hpdGVjdHVyZSBbU0ZD LVBNLQ0KDQogICBhcmNoXS4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IE5TSCBtZXNzYWdl IGZvcm1hdCBmb3IgY2FycnlpbmcNCg0KICAgcGFja2V0IGxvc3MgbWVhc3VyZW1lbnQgcmVsYXRl ZCBjb250cm9sIGluZm9ybWF0aW9uLiBJdCBhbHNvIGRlZmluZXMNCg0KICAgb3BlcmF0aW9ucyB0 byBiZSBjYXJyaWVkIG91dCBmb3IgcGFja2V0IGxvc3MgbWVhc3VyZW1lbnQuDQoNCiAgIENvbW11 bmljYXRpb24gbWVjaGFuaXNtIGJldHdlZW4gbWVhc3VyZW1lbnQgY29udHJvbGxlciwgbWVhc3Vy ZW1lbnQNCg0KICAgY29sbGVjdG9yIGFuZCBNQSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC4NCg0KDQoNCltHYXVyYXZdIEFncmVlLCB0ZXh0IHdpbGwgYmUgdXBkYXRlZCBhY2NvcmRp bmdseS4NCg0KDQoyLiBJbiBzZWN0aW9uIDIuMQ0KDQpUaGUgbGVuZ3RoIGlzIG9ubHkgNSBiaXRz IGluIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IENvbnRleHQgSGVhZGVyIFRMVi4gSW4gdGhlIFRM ViwgaXQgaW5jbHVkZXMgdGhlIGxpc3Qgb2YgTUEgSWRlbnRpZmllcnMuIFNvIHRoZSBtYXggTUEg SWRlbnRpZmllcnMgdGhhdCBjYW4gYmUgaW4gdGhlIGxpc3QgaXMgMzEgKDQgYnl0ZSB1c2VkIGZv ciBNZWFzdXJlbWVudCBXaW5kb3cgSW5kZXggYW5kIFJlc2VydmVkKS4gVGhpcyBsaXN0IGNhbiBp bmNsdWRlIG1heCBvZiAzMSBNQSBJZGVudGlmaWVycyBmb3IgYm90aCBTRkYgYW5kIFNGLiBXaGVy ZSB0aGVyZSBpcyBubyBsaW1pdCBmb3IgU0ahr3MgY2FuIGJlIG1heCBvZiAzMSBpbiBhIFNlcnZp Y2UgRnVuY3Rpb24gQ2hhaW4uIEkgdGhpbmsgdGhlIGxlbmd0aCBmaWVsZCBuZWVkIHRvIGJlIHJl dmlzZWQuDQoNCg0KDQpbR2F1cmF2XSBQZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBzcGVjaWZpYyB0 byBTRi9TRkYgaXMgZXhwZWN0ZWQgdG8gYmUgY2FycmllZCBvdXQgd2hlbiBhIHByb2JsZW0gaXMg aWRlbnRpZmllZCB1c2luZyB0aGUgRTJFIGFuZCB0aGVuIEhvcCBieSBob3AgbWVhc3VyZW1lbnQu IFNvLCB0byBjaGVjayBzcGVjaWZpYyBsaW1pdGVkIHNldHMgb2YgU0YvU0ZGIG1heCBsaW1pdCBv ZiAzMSBpcyBjb25zaWRlcmVkIGluIHRoZSBkcmFmdCwgdGV4dCB3aWxsIGJlIGFkZGVkIHRvIGNs YXJpZnkgdGhlIHNhbWUuDQoNCg0KDQozLiBJbiBzZWN0aW9uIDIuMg0KDQogUmVzZXJ2ZWQ6IFJl c2VydmVkIDE2IGJpdHMgZm9yIGZ1dHVyZSBwdXJwb3NlLiAgIKhDIElzIHJlcGVhdGVkIHR3aWNl Lg0KDQpbR2F1cmF2XSBBZ3JlZSwgdGV4dCB3aWxsIGJlIHVwZGF0ZWQgYWNjb3JkaW5nbHkuDQoN Cg0KDQo0LiBJbiBzZWN0aW9uIDIuMywNCg0KICAgICAgVGhlIG1ldGhvZCBvZiBlbmNvZGluZyB0 aGUgUE1GIGlkIGlzIGRvbmUgdXNpbmcgdGhlIGZsb3cgaWQgZGVmaW5lZCBpbiBbSS1ELmlldGYt c2ZjLW5zaDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWd2LXNmYy1wYWNrZXQt bG9zcy1tZWFzdXJlbWVudC0wMSNyZWYtSS1ELmlldGYtc2ZjLW5zaD5dLiCoQyBCdXQgSSBjb3Vs ZCBub3QgZmluZCBhbnkgZmxvdyBpZCBkZWZpbmVkIGluIGlldGYtc2ZjLW5zaCBkcmFmdC4NCg0K W0dhdXJhdl0gV2lsbCB1cGRhdGUgd2l0aCBjb3JyZWN0IHJlZmVyZW5jZS4NCg0KDQoNCjUuIElu IHNlY3Rpb24gMy41DQoNCkkgdGhpbmsgaXQgc2hvdWxkIGNvbGxlY3QgdGhlIHN0YXRzIGF0IG91 dGdvaW5nIHBvcnQgb25seSB3aGVuIHBhY2tldCBsb3NzIG1lYXN1cmVtZW50IGlzIGluaXRpYXRl ZC4NCg0KDQoNCltHYXVyYXZdIEFncmVlLCB0ZXh0IHdpbGwgYmUgdXBkYXRlZCB0byBtZW50aW9u IGFib3V0IGNhcnJ5aW5nIG91dCB0aGUgbWVhc3VyZW1lbnQgb25seSB3aGVuIHJlcXVpcmVkLg0K DQoNCg0KNi4gSW4gc2VjdGlvbiAzLjcNCg0KSSB0aGluayB0aGlzIGNhbiBpbmNsdWRlIG9uZSBt b3JlIHNjZW5hcmlvLCBwYWNrZXQgbG9zcyB3aGVuIGEgU2VydmljZSBmdW5jdGlvbiBpcyBEb3du Lg0KDQoNCg0KW0dhdXJhdl0gWWVzIHlvdSBhcmUgcmlnaHQgd2l0aCB0aGlzIG1lY2hhbmlzbSB3 ZSBjYW4gZmluZCBvdXQgaWYgYSBzcGVjaWZpYyBNQSBpcyBkb3duLCAgd2Ugd2lsbCBhZGQgYSB0 ZXh0IHRvIG1lbnRpb24gdGhlIHNhbWUuDQoNCg0KDQo3LiBJIHRoaW5rIHRoaXMgZHJhZnQgY29u c2lkZXJzIG9ubHkgc3RhdGljIFNlcnZpY2UgRnVuY3Rpb24gUGF0aC4gSSBzdWdnZXN0IHRoaXMg ZHJhZnQgY2FuIGFsc28gaW5jbHVkZSB0aGUgYmVsb3cgc2NlbmFyaW9zDQoNCi0gRHluYW1pYyBT RlAgYXMgbWVudGlvbmVkIGluIFJGQyA3NjY1IHNlY3Rpb24gNS4yDQoNCiAgICAgICAgICAgICAg ICAgICAgW0dhdXJhdl0gRnJhbmtseSBzcGVha2luZywgSSBhbSBub3QgY2xlYXIgYWJvdXQgdGhl IHNjZW5hcmlvIHNwZWNpZmllZCBpbiBzZWN0aW9uIDUuMiBvZiBSRkMgNzY2NSwgd2UgY2FuIGZ1 cnRoZXIgZXhwbG9yZSB0aGlzLg0KDQotIEJpZGlyZWN0aW9uYWwgU0ZDDQoNCiAgICAgICAgICAg ICAgICAgICAgW0dhdXJhdl0gQWN0dWFsbHkgZHJhZnQgYXBwcm9hY2ggY2FuIHZlcnkgd2VsbCBh Y2NvbW1vZGF0ZSB0aGlzLCBJIGNhbiBhZGQgYSB0ZXh0IHRvIGNsYXJpZnkgdGhpcy4NCg0KLSBS ZWNsYXNzaWZpY2F0aW9uIGFuZCBicmFuY2hpbmcgYXMgbWVudGlvbmVkIGluIFJGQyA3NjY1IHNl Y3Rpb24gNC44DQoNCiAgICBbR2F1cmF2XSBJdHMgYmFzaWNhbGx5IHByb2dyYW1taW5nIHJlLWNs YXNzaWZpZXIgdG8gdXBkYXRlIHJlcXVpcmVkIG1ldGFkYXRhLCBJIHdpbGwgYWRkIGEgc2VjdGlv biB0byBjb3ZlciB0aGlzLg0KDQoNCg0KDQoNCg0KVGhhbmtzICYgUmVnYXJkcywNClBoYW5lZW5k cmEgTWFuZGEuDQoNCg0K --_000_2F2059F256F9B24F82EAC5EE47F446C6E774F9E6szxemi502mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Phaneendra,

 

Thanks for your feedba= ck and suggestions again on this draft as well J.

 

Please find in-line co= mments.

 

Thanks and Regards,

Gaurav

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Phaneendra manda
Sent: 2016=C4=EA11=D4=C223=C8=D5 18:18
To: sfc@ietf.org
Cc: Aruna kumar padhi
Subject: [sfc] Review comments for draft-agv-sfc-packet-loss-measure= ment-01

 

Hi Authors,

 

Please find the bel= ow review comments for draft-agv= -sfc-packet-loss-measurement-01

 

1.      In Section = 1.3

   This=
 document defines the implementation mechanism for the packet

  = ; loss measurement as per performance measurement architecture [SFC-PM-

  = ; arch]. This document defines a new NSH message format for carrying

  = ; packet loss measurement related control information. It also defines=

  = ; operations to be carried out for packet loss measurement.

  = ; communication mechanism between measureme= nt controller, measurement

  = ; collector and MA is out of scope of this document.

 =

  = ; Can be

 = 

   This=
 document defines the implementation mechanism for the packet
   loss=
 measurement as per performance measurement architecture [SFC-PM-
   arch=
]. This document defines a new NSH message format for carrying
   pack=
et loss measurement related control information. It also defines=

   oper=
ations to be carried out for packet loss measurement.

   Communication mechanism between measurement c=
ontroller, measurement


   coll=
ector and MA is out of scope of this document.


 


[Gaurav] Agree, te=
xt will be updated accordingly.


 =




2.
In section 2.1



The =
length is only 5 bits in Performance Measurement Context Header TLV. In the=
 TLV, it includes the list of MA Identifiers. So the
 max MA Identifiers that can be in the list is 31 (4 byte used for Measurem=
ent Window Index and Reserved). This list can include max of 31 MA Identifi=
ers for both SFF and SF. Where there is no limit for SF=A1=AFs can be max o=
f 31 in a Service Function Chain. I think
 the length field need to be revised.


 

[Gaurav] Performan=
ce measurement specific to SF/SFF is expected to be carried out when a prob=
lem is identified using the E2E and then Hop by hop measurement. So, to che=
ck specific limited sets of SF/SFF max limit of 31 is considered in the dra=
ft, text will be added to clarify the same.


 



3.
In section 2.2


 Reserved: Reserved 16 bits for future purpose.   =A8C Is repea=
ted twice.


[Gaurav] Agree, te=
xt will be updated accordingly.


 


4. In section 2.3, 


   =
;   The method of encoding the PMF id is done using the flow=
 id defined in [I-D.ietf-sfc-nsh]. =A8C But I could not find any flow id d=
efined in ietf-sfc-nsh draft.  


[Gaurav] Will upda=
te with correct reference.


 


5. In section 3.5=



I think it should collect the stats at outgoing port only when packet los=
s measurement is initiated.


 


[Gaurav] Agree, te=
xt will be updated to mention about carrying out the measurement only when =
required.


 


6. In section 3.7=



I think this can include one more scenario, packet loss when a Service fu=
nction is Down.


 


[Gaurav] Yes you a=
re right with this mechanism we can find out if a specific MA is down, &nbs=
p;we will add a text to mention the same.


 


7. I think this draft =
considers only static Service Function Path. I suggest this draft can also =
include the below scenarios


- Dynamic SFP as menti=
oned in RFC 7665 section 5.2


            =
;        [Gaurav] Frankly speakin=
g, I am not clear about the scenario specified in section 5.2 of RFC 7665, =
we can further explore this.


- Bidirectional SFC


            =
;        [Gaurav] Actually draft =
approach can very well accommodate this, I can add a text to clarify this.<=
o:p>


- Reclassification and=
 branching as mentioned in RFC 7665 section 4.8


    [Gaurav] Its basically pro=
gramming re-classifier to update required metadata, I will add a section to=
 cover this.


 


 


 


Thanks =
& Regards,


Phaneen=
dra Manda.


=
 
--_000_2F2059F256F9B24F82EAC5EE47F446C6E774F9E6szxemi502mbxchi_-- From nobody Fri Nov 25 18:42:16 2016 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 A7020129446 for ; Fri, 25 Nov 2016 18:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 hppTocvXDoQM for ; Fri, 25 Nov 2016 18:42:12 -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 C6FE112941D for ; Fri, 25 Nov 2016 18:42:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWB08150; Sat, 26 Nov 2016 02:42:09 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 26 Nov 2016 02:42:08 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.151]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Sat, 26 Nov 2016 10:42:05 +0800 From: Qin Wu To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] RE: PCEP Extensions for Service Function Chaining (SFC) Thread-Index: AQHSR46shiKMA3VN+U6fgPz5x6XiJg== Date: Sat, 26 Nov 2016 02:42:05 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653@NKGEML515-MBX.china.huawei.com>, <6ac5a6ca-62a0-5b74-0f0f-cfcf0937a443@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37717@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37717@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5838F681.0152, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 43d7f8f6e933cfa0487eeb237327a9e7 Archived-At: Cc: BOUCADAIR Mohamed IMT/OLN Subject: Re: [sfc] PCEP Extensions for Service Function Chaining (SFC) 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, 26 Nov 2016 02:42:15 -0000 Sm9lbDoNClRoZSBpZGVhIGlzIHdoZW4gc3RhdGVmdWwgUENFIGNhbiBiZSB1c2VkIHRvIGNvbXB1 dGUgdHJhZmZpYy1lbmdpbmVlcmVkIFNGUHMsIFNGUCBJRCBjYW4gYWxzbyBiZSBwcmVkZXRlcm1p bmVkLiBUaGF0IGlzIHdoeSB3ZSBhZGQNClNGUCBpZGVudGlmaWVyIFRMViBhbmQgc2VuZCBpdCBi YWNrIHRvIGNsYXNzaWZpZXIuIFRoaXMgU0ZQIElkZW50aWZpZXIgcmVjZWl2ZWQgYnkgQ2xhc3Np ZmllciBjYW4gYmUgaW5zZXJ0ZWQgaW50byBOU0ggYW5kIHVzZWQgdG8gc2VsZWN0IHRoZSBwYXRo LCBpbnZva2UgU0YgaW5zdGFuY2UsIGlkZW50aWZ5IG5leHQgU0ZGLg0KVGhlcmUgbWF5IGhhdmUg b3RoZXIgY2FzZSB3aGVuIFBDRSBvbmx5IGNvbXB1dGUgdHJhZmZpYy1lbmdpbmVlcmVkIFNGUCwg ZW5jb2RlIGEgZnVsbCBzZXF1ZW5jZSBvZiBTRkYvU0YgaW4gdGhlIFBDRVAgbWVzc2FnZSwgQ2xh c3NpZmllciB0aGVuIGFsbG9jYXRlIGEgU0ZQIGlkZW50aWZpZXIsIGJ1dCBob3cNCmRvIHdlIHBy ZXZlbnQgb3RoZXIgY2xhc3NpZmllciBhc3NpZ24gdGhlIHNhbWUgU0ZQIElEIHRvIGFub3RoZXIg U2VydmljZSBGdW5jdGlvbiBQYXRoPyBBZGQgU0ZQIElEIGNvbmZsaWN0IGRldGVjdGlvbiBtZWNo YW5pc20gaXMgY29tcGxpY2F0ZWQuDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjL OiBYdXhpYW9odSANCreiy83KsbzkOiAyMDE2xOoxMdTCMTfI1SAxNzowNw0KytW8/sjLOiBKb2Vs IE0uIEhhbHBlcm47IFFpbiBXdTsgc2ZjQGlldGYub3JnDQrW98ziOiC08Li0OiBbc2ZjXSC08Li0 OiBQQ0VQIEV4dGVuc2lvbnMgZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykNCg0K SGkgSm9lbCwNCg0KVGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IGp1c3QgZGVzY3Jp YmVzIG5lY2Nlc3NhcnkgUENFUCBleHRlbnNpb25zIHRvIHJlYWxpemUgdGhlIE1QTFMgc291cmNl IHJvdXRpbmcgYmFzZWQgU0ZDIGFwcHJvYWNoIGFzIGRlc2NyaWJlZCBpbiAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LW1wbHMtc2VydmljZS1jaGFpbmluZy0wMCkuIEl0IGRv ZXNuJ3QgdG91Y2ggdGhlIE5TSC1iYXNlZCBTRkMgYXBwcm9hY2guIEkgdGhpbmsgaXQncyBRaW4n cyBkcmFmdCB0aGF0IGNvdmVycyB0aGUgTlNILWJhc2VkIFNGQyBhcHByb2FjaC4NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCreivP7IyzogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29tXQ0Kt6LLzcqx vOQ6IDIwMTbE6jEx1MIxN8jVIDE2OjQ2DQrK1bz+yMs6IFh1eGlhb2h1OyBRaW4gV3U7IHNmY0Bp ZXRmLm9yZw0K1vfM4jogUmU6IFtzZmNdILTwuLQ6IFBDRVAgRXh0ZW5zaW9ucyBmb3IgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKQ0KDQpYdSwgaXQgaXMgdW5jbGVhciBpbiB0aGlzIGRy YWZ0IHdoZXRoZXIgeW91ciBpbnRlbnRpb24gaXMgdG8gY2FycnkgTlNIIHRvIHN1cHBvcnQgaW50 ZXJvcGVyYXRpb24gd2l0aCBvdGhlciB0cmFuc3BvcnRzIGFuZCBjYXJyaWFnZSBvZiBtZXRhZGF0 YS4NCg0KQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeT8NCg0KVGhhbmsgeW91LA0KSm9lbA0KDQpPbiAx MS8xNy8xNiAyOjQyIEFNLCBYdXhpYW9odSB3cm90ZToNCj4gSGksDQo+DQo+DQo+DQo+IEl0J3Mg Z3JlYXQgdG8ga25vdyB0aGF0IHRoZSBQQ0UgV0cgaXMgbm93IHdvcmtpbmcgb24gUENFIEV4dGVu c2lvbnMgDQo+IGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nLg0KPg0KPg0KPg0KPiBUaGUg Zm9sbG93aW5nIGlzIGEgZHJhZnQgYWJvdXQgUENFUCBleHRlbnNpb25zIGZvciB0aGUgTVBMUyBz b3VyY2UgDQo+IHJvdXRpbmcgYmFzZWQgU0ZDIChzZWUNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXh1LW1wbHMtc2VydmljZS1jaGFpbmluZy0wMCk6DQo+DQo+DQo+DQo+IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1wY2Utc3Itc2ZjLTAzDQo+DQo+DQo+ DQo+IEFueSBzdWdnZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUgYXMgd2VsbC4NCj4N Cj4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0KPiBYaWFvaHUNCj4NCj4NCj4NCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtLQ0KPiAqt6K8/sjLOiogc2ZjIFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBR aW4gV3UgW2JpbGwud3VAaHVhd2VpLmNvbV0NCj4gKreiy83KsbzkOiogMjAxNsTqMTHUwjE3yNUg MTU6MDENCj4gKsrVvP7IyzoqIHNmY0BpZXRmLm9yZw0KPiAq1vfM4joqIFtzZmNdIFBDRVAgRXh0 ZW5zaW9ucyBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKQ0KPg0KPiBIaSwgZm9s a3M6DQo+DQo+IENoYWlyIHJlbWluZCB1cyByZWNlbnRseSB0byBhbm5vdW5jZSB0byB0aGlzIGxp c3QgdGhhdCBQQ0UgV0cgaXMgDQo+IHdvcmtpbmcgb24gUENFIEV4dGVuc2lvbiBmb3IgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbmluZy4gSGVyZSBpcyB0aGUgcmVsZXZhbnQgZHJhZnQ6DQo+DQo+IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1wY2UtdHJhZmZpYy1zdGVlcmluZy1z ZmMtMDkNCj4NCj4gUGxlYXNlIHRha2UgYSBsb29rIGF0IGl0IGFuZCB5b3VyIGNvbW1lbnRzIGFu ZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCj4NCj4NCj4NCj4gLVFpbg0KPg0KPg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFp bGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPg0K From nobody Fri Nov 25 18:50:57 2016 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 164CA1294AB for ; Fri, 25 Nov 2016 18:50:56 -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 zNlFSa13m1pI for ; Fri, 25 Nov 2016 18:50:54 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8CB1294A5 for ; Fri, 25 Nov 2016 18:50:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 63DD9269A8A; Fri, 25 Nov 2016 18:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1480128654; bh=Wqvgr2YgAD//zVB8GiKZODUACi3TnMHfsNp/F5iibk8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Gh4WzasKYk6SdAzf2G6k7u117LBuAm2KmIUJODKdXNfWqk3ITreeNggxTepD/G4Ai Q0fF42L8geYlbIZW0zKHP5R7L/TmaPxk4wuRbVRfx/kWvXw1CeAdqmNRDSxXNbZuV4 MWO09DT2/wSlVdQwuiV3CVt6CuhMccUldowcjtNo= 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 CE11F2402FF; Fri, 25 Nov 2016 18:50:53 -0800 (PST) To: Qin Wu , "sfc@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653@NKGEML515-MBX.china.huawei.com> <6ac5a6ca-62a0-5b74-0f0f-cfcf0937a443@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37717@NKGEML515-MBX.china.huawei.com> From: "Joel M. Halpern" Message-ID: <9e123ea1-65b6-6b86-41b2-cd17940a5ef9@joelhalpern.com> Date: Fri, 25 Nov 2016 21:51:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: BOUCADAIR Mohamed IMT/OLN Subject: Re: [sfc] PCEP Extensions for Service Function Chaining (SFC) 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, 26 Nov 2016 02:50:56 -0000 That sounds reasonable. I was looking for some of that in the draft so as to evaluate the (likely sound) details. Yours, Joel On 11/25/16 9:42 PM, Qin Wu wrote: > Joel: > The idea is when stateful PCE can be used to compute traffic-engineered SFPs, SFP ID can also be predetermined. That is why we add > SFP identifier TLV and send it back to classifier. This SFP Identifier received by Classifier can be inserted into NSH and used to select the path, invoke SF instance, identify next SFF. > There may have other case when PCE only compute traffic-engineered SFP, encode a full sequence of SFF/SF in the PCEP message, Classifier then allocate a SFP identifier, but how > do we prevent other classifier assign the same SFP ID to another Service Function Path? Add SFP ID conflict detection mechanism is complicated. > > -Qin > -----邮件原件----- > 发件人: Xuxiaohu > 发送时间: 2016年11月17日 17:07 > 收件人: Joel M. Halpern; Qin Wu; sfc@ietf.org > 主题: 答复: [sfc] 答复: PCEP Extensions for Service Function Chaining (SFC) > > Hi Joel, > > The current version of this draft just describes neccessary PCEP extensions to realize the MPLS source routing based SFC approach as described in (https://tools.ietf.org/html/draft-xu-mpls-service-chaining-00). It doesn't touch the NSH-based SFC approach. I think it's Qin's draft that covers the NSH-based SFC approach. > > Best regards, > Xiaohu > > ________________________________________ > 发件人: Joel M. Halpern [jmh@joelhalpern.com] > 发送时间: 2016年11月17日 16:46 > 收件人: Xuxiaohu; Qin Wu; sfc@ietf.org > 主题: Re: [sfc] 答复: PCEP Extensions for Service Function Chaining (SFC) > > Xu, it is unclear in this draft whether your intention is to carry NSH to support interoperation with other transports and carriage of metadata. > > Can you please clarify? > > Thank you, > Joel > > On 11/17/16 2:42 AM, Xuxiaohu wrote: >> Hi, >> >> >> >> It's great to know that the PCE WG is now working on PCE Extensions >> for Service Function Chaining. >> >> >> >> The following is a draft about PCEP extensions for the MPLS source >> routing based SFC (see >> https://tools.ietf.org/html/draft-xu-mpls-service-chaining-00): >> >> >> >> https://tools.ietf.org/html/draft-xu-pce-sr-sfc-03 >> >> >> >> Any suggestions and comments are welcome as well. >> >> >> >> Best regards, >> >> Xiaohu >> >> >> >> ---------------------------------------------------------------------- >> -- >> *发件人:* sfc [sfc-bounces@ietf.org] 代表 Qin Wu [bill.wu@huawei.com] >> *发送时间:* 2016年11月17日 15:01 >> *收件人:* sfc@ietf.org >> *主题:* [sfc] PCEP Extensions for Service Function Chaining (SFC) >> >> Hi, folks: >> >> Chair remind us recently to announce to this list that PCE WG is >> working on PCE Extension for Service Function Chaining. Here is the relevant draft: >> >> https://tools.ietf.org/html/draft-wu-pce-traffic-steering-sfc-09 >> >> Please take a look at it and your comments and suggestions are welcome. >> >> >> >> -Qin >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Sat Nov 26 02:21:09 2016 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 73CBC1295BD for ; Sat, 26 Nov 2016 02:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 uDGez2Zmk1JG for ; Sat, 26 Nov 2016 02:21: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 DFB1A1295BA for ; Sat, 26 Nov 2016 02:21:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBK68395; Sat, 26 Nov 2016 10:21:02 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 26 Nov 2016 10:21:02 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.151]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 26 Nov 2016 18:20:57 +0800 From: Qin Wu To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] RE: PCEP Extensions for Service Function Chaining (SFC) Thread-Index: AQHSR46shiKMA3VN+U6fgPz5x6XiJqDqCqsAgAEDZmA= Date: Sat, 26 Nov 2016 10:20:56 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37653@NKGEML515-MBX.china.huawei.com> <6ac5a6ca-62a0-5b74-0f0f-cfcf0937a443@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB37717@NKGEML515-MBX.china.huawei.com> <9e123ea1-65b6-6b86-41b2-cd17940a5ef9@joelhalpern.com> In-Reply-To: <9e123ea1-65b6-6b86-41b2-cd17940a5ef9@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5839620F.00AB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.151, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5496c0f73918acf20fccf3c0f813610d Archived-At: Cc: BOUCADAIR Mohamed IMT/OLN Subject: Re: [sfc] PCEP Extensions for Service Function Chaining (SFC) 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, 26 Nov 2016 10:21:08 -0000 VGhhbmtzIEpvZWwsIHdlIGNhbiBtYWtlIHRleHQgbW9yZSBjbGVhciBpbiB0aGUgbmV4dCB2ZXJz aW9uIGlmIGNvbmZ1c2lvbiBpcyBjYXVzZWQuDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0tLQ0K t6K8/sjLOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSANCrei y83KsbzkOiAyMDE2xOoxMdTCMjbI1SAxMDo1MQ0KytW8/sjLOiBRaW4gV3U7IHNmY0BpZXRmLm9y Zw0Ks63LzTogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0K1vfM4jogUmU6IFtzZmNdIFJFOiBQ Q0VQIEV4dGVuc2lvbnMgZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykNCg0KVGhh dCBzb3VuZHMgcmVhc29uYWJsZS4gIEkgd2FzIGxvb2tpbmcgZm9yIHNvbWUgb2YgdGhhdCBpbiB0 aGUgZHJhZnQgc28gYXMgdG8gZXZhbHVhdGUgdGhlIChsaWtlbHkgc291bmQpIGRldGFpbHMuDQoN CllvdXJzLA0KSm9lbA0KDQpPbiAxMS8yNS8xNiA5OjQyIFBNLCBRaW4gV3Ugd3JvdGU6DQo+IEpv ZWw6DQo+IFRoZSBpZGVhIGlzIHdoZW4gc3RhdGVmdWwgUENFIGNhbiBiZSB1c2VkIHRvIGNvbXB1 dGUgDQo+IHRyYWZmaWMtZW5naW5lZXJlZCBTRlBzLCBTRlAgSUQgY2FuIGFsc28gYmUgcHJlZGV0 ZXJtaW5lZC4gVGhhdCBpcyB3aHkgd2UgYWRkIFNGUCBpZGVudGlmaWVyIFRMViBhbmQgc2VuZCBp dCBiYWNrIHRvIGNsYXNzaWZpZXIuIFRoaXMgU0ZQIElkZW50aWZpZXIgcmVjZWl2ZWQgYnkgQ2xh c3NpZmllciBjYW4gYmUgaW5zZXJ0ZWQgaW50byBOU0ggYW5kIHVzZWQgdG8gc2VsZWN0IHRoZSBw YXRoLCBpbnZva2UgU0YgaW5zdGFuY2UsIGlkZW50aWZ5IG5leHQgU0ZGLg0KPiBUaGVyZSBtYXkg aGF2ZSBvdGhlciBjYXNlIHdoZW4gUENFIG9ubHkgY29tcHV0ZSB0cmFmZmljLWVuZ2luZWVyZWQg DQo+IFNGUCwgZW5jb2RlIGEgZnVsbCBzZXF1ZW5jZSBvZiBTRkYvU0YgaW4gdGhlIFBDRVAgbWVz c2FnZSwgQ2xhc3NpZmllciB0aGVuIGFsbG9jYXRlIGEgU0ZQIGlkZW50aWZpZXIsIGJ1dCBob3cg ZG8gd2UgcHJldmVudCBvdGhlciBjbGFzc2lmaWVyIGFzc2lnbiB0aGUgc2FtZSBTRlAgSUQgdG8g YW5vdGhlciBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGg/IEFkZCBTRlAgSUQgY29uZmxpY3QgZGV0ZWN0 aW9uIG1lY2hhbmlzbSBpcyBjb21wbGljYXRlZC4NCj4NCj4gLVFpbg0KPiAtLS0tLdPKvP7Urbz+ LS0tLS0NCj4gt6K8/sjLOiBYdXhpYW9odQ0KPiC3osvNyrG85DogMjAxNsTqMTHUwjE3yNUgMTc6 MDcNCj4gytW8/sjLOiBKb2VsIE0uIEhhbHBlcm47IFFpbiBXdTsgc2ZjQGlldGYub3JnDQo+INb3 zOI6ILTwuLQ6IFtzZmNdILTwuLQ6IFBDRVAgRXh0ZW5zaW9ucyBmb3IgU2VydmljZSBGdW5jdGlv biBDaGFpbmluZyAoU0ZDKQ0KPg0KPiBIaSBKb2VsLA0KPg0KPiBUaGUgY3VycmVudCB2ZXJzaW9u IG9mIHRoaXMgZHJhZnQganVzdCBkZXNjcmliZXMgbmVjY2Vzc2FyeSBQQ0VQIGV4dGVuc2lvbnMg dG8gcmVhbGl6ZSB0aGUgTVBMUyBzb3VyY2Ugcm91dGluZyBiYXNlZCBTRkMgYXBwcm9hY2ggYXMg ZGVzY3JpYmVkIGluIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtbXBscy1z ZXJ2aWNlLWNoYWluaW5nLTAwKS4gSXQgZG9lc24ndCB0b3VjaCB0aGUgTlNILWJhc2VkIFNGQyBh cHByb2FjaC4gSSB0aGluayBpdCdzIFFpbidzIGRyYWZ0IHRoYXQgY292ZXJzIHRoZSBOU0gtYmFz ZWQgU0ZDIGFwcHJvYWNoLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7IyzogSm9lbCBNLiBI YWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiC3osvNyrG85DogMjAxNsTqMTHUwjE3yNUg MTY6NDYNCj4gytW8/sjLOiBYdXhpYW9odTsgUWluIFd1OyBzZmNAaWV0Zi5vcmcNCj4g1vfM4jog UmU6IFtzZmNdILTwuLQ6IFBDRVAgRXh0ZW5zaW9ucyBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFp bmluZyAoU0ZDKQ0KPg0KPiBYdSwgaXQgaXMgdW5jbGVhciBpbiB0aGlzIGRyYWZ0IHdoZXRoZXIg eW91ciBpbnRlbnRpb24gaXMgdG8gY2FycnkgTlNIIHRvIHN1cHBvcnQgaW50ZXJvcGVyYXRpb24g d2l0aCBvdGhlciB0cmFuc3BvcnRzIGFuZCBjYXJyaWFnZSBvZiBtZXRhZGF0YS4NCj4NCj4gQ2Fu IHlvdSBwbGVhc2UgY2xhcmlmeT8NCj4NCj4gVGhhbmsgeW91LA0KPiBKb2VsDQo+DQo+IE9uIDEx LzE3LzE2IDI6NDIgQU0sIFh1eGlhb2h1IHdyb3RlOg0KPj4gSGksDQo+Pg0KPj4NCj4+DQo+PiBJ dCdzIGdyZWF0IHRvIGtub3cgdGhhdCB0aGUgUENFIFdHIGlzIG5vdyB3b3JraW5nIG9uIFBDRSBF eHRlbnNpb25zIA0KPj4gZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcuDQo+Pg0KPj4NCj4+ DQo+PiBUaGUgZm9sbG93aW5nIGlzIGEgZHJhZnQgYWJvdXQgUENFUCBleHRlbnNpb25zIGZvciB0 aGUgTVBMUyBzb3VyY2UgDQo+PiByb3V0aW5nIGJhc2VkIFNGQyAoc2VlDQo+PiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtbXBscy1zZXJ2aWNlLWNoYWluaW5nLTAwKToNCj4+ DQo+Pg0KPj4NCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1wY2Utc3It c2ZjLTAzDQo+Pg0KPj4NCj4+DQo+PiBBbnkgc3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSB3 ZWxjb21lIGFzIHdlbGwuDQo+Pg0KPj4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4gWGlh b2h1DQo+Pg0KPj4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+IC0tDQo+PiAqt6K8/sjL Oiogc2ZjIFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBRaW4gV3UgW2JpbGwud3VAaHVhd2Vp LmNvbV0NCj4+ICq3osvNyrG85DoqIDIwMTbE6jEx1MIxN8jVIDE1OjAxDQo+PiAqytW8/sjLOiog c2ZjQGlldGYub3JnDQo+PiAq1vfM4joqIFtzZmNdIFBDRVAgRXh0ZW5zaW9ucyBmb3IgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKQ0KPj4NCj4+IEhpLCBmb2xrczoNCj4+DQo+PiBDaGFp ciByZW1pbmQgdXMgcmVjZW50bHkgdG8gYW5ub3VuY2UgdG8gdGhpcyBsaXN0IHRoYXQgUENFIFdH IGlzIA0KPj4gd29ya2luZyBvbiBQQ0UgRXh0ZW5zaW9uIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nLiBIZXJlIGlzIHRoZSByZWxldmFudCBkcmFmdDoNCj4+DQo+PiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtd3UtcGNlLXRyYWZmaWMtc3RlZXJpbmctc2ZjLTA5DQo+Pg0K Pj4gUGxlYXNlIHRha2UgYSBsb29rIGF0IGl0IGFuZCB5b3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0 aW9ucyBhcmUgd2VsY29tZS4NCj4+DQo+Pg0KPj4NCj4+IC1RaW4NCj4+DQo+Pg0KPj4NCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFp bGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+Pg0K