From nobody Fri Jul 1 07:20: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 0080412D669; Fri, 1 Jul 2016 07:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 wegTUrV0F06y; Fri, 1 Jul 2016 07:20:38 -0700 (PDT) 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 97D1F12D666; Fri, 1 Jul 2016 07:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5951; q=dns/txt; s=iport; t=1467382838; x=1468592438; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BB/y3S/ey7INxFiOeNwQyf2ERjNmZGutL+DUe9XJV4c=; b=HASMRu+oXu9fqnLp4yVFKTrmfnyL3Hkj7ndM3O5uebl+fCu646AZ7r+T t+vjTFGept++7uWgl9QS9rOezn+be2mLXDhWM2ZK4xAgAKzh5qVB/26nn aLHi055uPUxi6wCh3TdTyjqEg0I9p4g6lJxzoNWKKUToxN/Ksl6BHCs5W I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgAKfHZX/5RdJa1dgz5WfAa5SoF7I?= =?us-ascii?q?oV2AoEvOBQBAQEBAQEBZSeETAEBBXkMBAIBCBEEAQEBJwcyFAkIAQEEAQ0FG4g?= =?us-ascii?q?VDgPEIAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFinWEIwEBhXYFjjmFCIVPAYYIi?= =?us-ascii?q?DuBaoRWgy57hEGGVokyAR42g3Buhz82fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,557,1459814400"; d="scan'208";a="291808574" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2016 14:20:23 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u61EKNWJ017518 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jul 2016 14:20:23 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 1 Jul 2016 09:20:23 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Fri, 1 Jul 2016 09:20:23 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Gregory Mirsky , Tal Mizrahi , "draft-ooamdt-rtgwg-oam-gap-analysis@tools.ietf.org" , "draft-ooamdt-rtgwg-ooam-requirement@tools.ietf.org" , "rtgwg@ietf.org" Thread-Topic: Comments about Overlay OAM Drafts Thread-Index: AdHPgQ8L7yui3SQ6S8i+8JhXelTIiwAPKBqAAAIJKnAAD6mBkADp5h2A Date: Fri, 1 Jul 2016 14:20:22 +0000 Message-ID: References: <7e12c3e474924b04b133da754e2f9cf8@IL-EXCH01.marvell.com> <48da4f66881d4accb182513b39744fc1@IL-EXCH01.marvell.com> <7347100B5761DC41A166AC17F22DF11221AB8DC9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221AB8DC9@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.20.14] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2D395EFF6D215548B7D4355C1395C3A5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "bier@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" Subject: Re: [sfc] Comments about Overlay OAM 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: Fri, 01 Jul 2016 14:20:41 -0000 Hi Tal, 6. Section 6 - certainly the OAM requirements have security implications. For example, OAM protocols may be subject to DoS attacks and to network recon. Some of these considerations are discussed in RFC 7276. The draft is listing the requirements and does not discuss about any solution or machinery. Accordingly, it does not introduce any security implications. I think the security consideration is applicable on the document that define the solutions. Does the below works: "This document list the OAM requirement for various Overlay network and does not raise any security considerations. Any document defining the solution for the above requirement must consider and include the relevant security mechanism=B2. Thanks, Nagendra On 6/26/16, 8:36 PM, "Gregory Mirsky" wrote: >Hi Tal, >many thanks for your thorough review of the documents by OOAM DT, greatly >appreciated. Please find my answers and notes in-line and tagged GIM>>. >We're preparing updates to both drafts and will reflect your comments in >the coming updates. > > Regards, > Greg > >-----Original Message----- >From: Tal Mizrahi [mailto:talmi@marvell.com] >Sent: Sunday, June 26, 2016 7:20 AM >To: Nagendra Kumar Nainar (naikumar); >draft-ooamdt-rtgwg-oam-gap-analysis@tools.ietf.org; >draft-ooamdt-rtgwg-ooam-requirement@tools.ietf.org; rtgwg@ietf.org >Cc: bier@ietf.org; sfc@ietf.org; nvo3@ietf.org >Subject: RE: Comments about Overlay OAM Drafts > >Dear Nagendra, > >>The comments seems to be missing in the mail. Can you please share the >>same?. > >Strange... The comments seem to be visible in the mail archive >(https://mailarchive.ietf.org/arch/msg/rtgwg/EPxJQcw9lOAIHV2HkRwNE6GVxAU). > >Nevertheless, here goes again: > > >Comments about draft-ooamdt-rtgwg-ooam-requirement: >https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-requirement-00 > >A general question about the draft: does the draft define requirements >for operators, requirements for vendors, or requirements for IETF working >groups? These are three significantly different scopes, and reading the >document I was not able to assess who the requirements are intended for. > >Other comments: >1. Section 3: The term 'UCMP' is defined in Section 3, but not used in >the document. >GIM>> Good catch, will clear >2. The following terms are used in the draft without having been defined: >- 'OAM session' >- 'node' >- 'centralized controller' >- 'FM' >GIM>> While Fault Management is straightforward >3. Section 4.1.1: 'Reverse Defect Indication (RDI)' =3D=3D> RDI usually >stands for Remote Defect Indication. >GIM>> Indeed, thank you. Will update. >4. Section 4.1.2: "Overlay OAM MAY support verification of the mapping >between its data plane state and client layer services" - please clarify >further. >GIM>> We intend to provide solutions in the new document. But one use >case discussed in draft-nordmark-nvo3-transcending-traceroute. >5. Section 4.2: the terms 'active' and 'passive' have not been defined in >the current draft (you may want to cite RFC 7799). >Specifically, this clarification is necessary since the term 'passive' >according to RFC 7799 is slightly different than the term 'passive' in >draft-ietf-ippm-alt-mark-00. >GIM>> Yes, and we are talking about measurement methods that can be used >"almost as passive" and explain the requirements toward the overlay to >achieve such behavior. >6. Section 6 - certainly the OAM requirements have security implications. >For example, OAM protocols may be subject to DoS attacks and to network >recon. Some of these considerations are discussed in RFC 7276. > > >Comments about draft-ooamdt-rtgwg-oam-gap-analysis: >https://tools.ietf.org/html/draft-ooamdt-rtgwg-oam-gap-analysis-01 > >1. I believe having an OAM gap analysis draft is a good idea. >GIM>> Thank you. >2. The current draft is still very preliminary, and some of the sections >are still empty.=20 >GIM>> we'll post update before the cut-off date to discuss it in Berlin. >3. Section 1: The introduction of the document goes way beyond the scope >of the title (Gap Analysis). The intro actually defines the baseline of >an Overlay OAM solution. Either this part should be removed from the >document, or the scope of the document should be redefined. >GIM>> I think it may justified as we list existing IETF OAM protocols. >Though we may move them out of the Introduction and into the new section. >4. Section 3.3: this section is unclear, and should probably be rephrased. >The section discusses both in-band telemetry and passive monitoring, and >it is not clear whether the two are related or not. >GIM>> We've discussed the telemetry and it could be collected using >active OAM, i.e. using injected OAM packets, or using passive-like >method. Interestingly to discussion in RFC 7799, telemetry collection may >use methods that could be characterized as hybrid methods as well. >5. Section 5: it looks like this text was copied from another draft, and >is not applicable to this document. >GIM>> Indeed, we've removed it in the working version. Contributions are >welcome and appreciated. > >Cheers, >Tal. > > > >>-----Original Message----- >>From: Nagendra Kumar Nainar (naikumar) [mailto:naikumar@cisco.com] >>Sent: Sunday, June 26, 2016 5:16 PM >>To: Tal Mizrahi; draft-ooamdt-rtgwg-oam-gap-analysis@tools.ietf.org; >>draft- ooamdt-rtgwg-ooam-requirement@tools.ietf.org; rtgwg@ietf.org >>Cc: bier@ietf.org; sfc@ietf.org; nvo3@ietf.org >>Subject: Re: Comments about Overlay OAM Drafts >> >>Hi Tal, >> >>The comments seems to be missing in the mail. Can you please share the >>same?. >> >>Thanks, >>Nagendra >> >>On 6/26/16, 4:12 AM, "Tal Mizrahi" wrote: >> >>>Dear OOAM Authors, >>> >>>I have read the two OOAM drafts, and I have some comments. Please see >>>below > From nobody Fri Jul 1 08:04: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 2200412D146; Fri, 1 Jul 2016 07:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgtai-gQlPNQ; Fri, 1 Jul 2016 07:55:49 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7114B12B061; Fri, 1 Jul 2016 07:55:49 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id v199so29912608wmv.0; Fri, 01 Jul 2016 07:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-transfer-encoding; bh=bNj4hwH8+sxoF0ient0FGt8ID7dQmgSWp7mDJqMSjY4=; b=sYUqST3VpErVdTOEu9xFo17tX60HEOlTcI3N95DvYvGJYv7bT3vfwp6bSIgodDd6lU 54tfVLjbV6xvZpUWw9SbxYEwemMPaxXpxPaLG3J1dr/DJ73usSQw6s+FUZNcOigBEl/5 YnI07yyGAjbq6wC9k2auO+K29W2Gmbe7WnAd9azR2KU3t6y8fhp9/HZ4HGyviBZbTbQ1 rwFEN1fZYh8/+d13H53J8RZWwqT04W0SlCOF8flXRaxC0twQ0sZ+AgEIk0ILLbvHfQvv HnnpjKaCoBL2AOtV/7anfqMXmNUpB+0/xSXUE+GVJLMyHrEca4GpNqLPvP6as9cMTHZy Fs1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-transfer-encoding; bh=bNj4hwH8+sxoF0ient0FGt8ID7dQmgSWp7mDJqMSjY4=; b=DS05DHZS3xhCCMK4N7MauRJcEVKakeSvyjnjlRxlxXidWNwPM+uATPXYSGX+7Oxjbz EDHxvfOFad/5PwM7nARoZoFvaFfkMOVXPcZmQaHflZM8GgMH2hcifIbi/3ExfvbEDoIz fnaSoivfV92QMFRSJjFdLuhR6LSeDKsEh2dAnlSS84W9aLdDgMT9j0cQ5iP0UuxJStIy dMyN0U2GQbVs7ltWNi+O0q9Afzz1mox2hbLZvUhmx2pUyCKF++L4id1bf+t+TQmolPVF XrAe5bGVER2G1NWGdJokiio/CtGH3onqRBhkZA16vmNu/wqT4DfkvcFm3R02O8jz6TLo rlAQ== X-Gm-Message-State: ALyK8tLV+SdMiUm8xKa4oiET9BAHgA/GV1M69QBhXSX4LDaWm9KCXODoZNs55p90Ggti/A== X-Received: by 10.194.43.131 with SMTP id w3mr4040750wjl.76.1467384947899; Fri, 01 Jul 2016 07:55:47 -0700 (PDT) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id t188sm6844451wma.8.2016.07.01.07.55.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jul 2016 07:55:47 -0700 (PDT) Message-ID: <57768471.4080707@gmail.com> Date: Fri, 01 Jul 2016 16:55:45 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gregory Mirsky , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" , "sfc@ietf.org" , "BIER (bier@ietf.org)" , "nvo3@ietf.org" References: <7347100B5761DC41A166AC17F22DF11221A217BD@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A217BD@eusaamb103.ericsson.se> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 01 Jul 2016 08:04:52 -0700 Cc: "Ignas Bagdonas \(ibagdona@gmail.com\)" , "Carlos Pignataro \(cpignata\) \(cpignata@cisco.com\)" , "Erik Nordmark \(nordmark@sonic.net\)" , "dekumar@cisco.com" , "Petr Lapukhov \(petr@fb.com\)" , "Nagendra Kumar \(naikumar\) \(naikumar@cisco.com\)" , "Alia Atlas \(akatlas@gmail.com\)" , "santosh.pallagatti@gmail.com" , "David Mozes \(davidm@mellanox.com\)" Subject: Re: [sfc] New documents published by Overlay OAM DT X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 14:55:51 -0000
Dear Greg,

You wrote:

the design team had published two documents:

·         Overlay OAM Requirements https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-requirement-00

·         OAM for Overlay Networks: Gap Analysis https://tools.ietf.org/html/draft-ooamdt-rtgwg-oam-gap-analysis-00


Both documents have subsections pro-active and on-demand for FM
but active and passive for PM.

Why is there no distinction made for active and passive FM,
and pro-active and on-demand for PM?

Best regards, Huub.


-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Fri Jul 1 08:10: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 5450212D14D for ; Fri, 1 Jul 2016 08:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 hSJX7L6TNrKa for ; Fri, 1 Jul 2016 08:10:35 -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 9888112D69C for ; Fri, 1 Jul 2016 08:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1555; q=dns/txt; s=iport; t=1467385835; x=1468595435; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=duBtsQaHE0942R5AddMb1XRnBZnI5MYL/BeeYncObhM=; b=KD/t1ge7erK0JrZRvTUR5Su91qcmHqKPhwq7WqKvtau+4a7DwwJzUDsn 0sCzHLWdw3C5rWgVEBY7lZLY2dYYSkFrSdY9mf+IImMvN4D8EdATyU1+j PnRsY6IJLvJMG3+RpXzeiBepe0VvHpFcOADD7pQB9vHz+AJ0FOjJ4gO38 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgBch3ZX/4ENJK1dgz5WfAa5SoF7J?= =?us-ascii?q?IV0AoEwOBQBAQEBAQEBZRwLhE0BBTo9AhACAQgSJBAyFwQBBgMCBA4FiDAOxCQ?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEcinWKGwWOAYsPAYYIiDuBak6ECIhqkAgBH?= =?us-ascii?q?jaDcG4Bh3R/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,557,1459814400"; d="scan'208";a="119072511" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2016 15:10:34 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u61FAYjQ017156 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jul 2016 15:10:34 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 1 Jul 2016 10:10:34 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Fri, 1 Jul 2016 10:10:34 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-ipfix-sfc-extension-03.txt Thread-Index: AQHR06p3L07URewiokiRtwOaB8EyY6ADvtmA Date: Fri, 1 Jul 2016 15:10:34 +0000 Message-ID: References: <20160701150801.24657.99381.idtracker@ietfa.amsl.com> In-Reply-To: <20160701150801.24657.99381.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.20.14] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Paul Quinn \(paulq\)" Subject: [sfc] FW: New Version Notification for draft-kumar-ipfix-sfc-extension-03.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: Fri, 01 Jul 2016 15:10:37 -0000 Hi All, Below is the new version with just a version bump. We welcome any comments/discussions on the same. Regards, Nagendra On 7/1/16, 11:08 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-kumar-ipfix-sfc-extension-03.txt >has been successfully submitted by Nagendra Kumar and posted to the >IETF repository. > >Name: draft-kumar-ipfix-sfc-extension >Revision: 03 >Title: IPFIX Information Element extension for SFC >Document date: 2016-07-01 >Group: Individual Submission >Pages: 14 >URL: =20 >https://www.ietf.org/internet-drafts/draft-kumar-ipfix-sfc-extension-03.tx >t >Status: =20 >https://datatracker.ietf.org/doc/draft-kumar-ipfix-sfc-extension/ >Htmlized: =20 >https://tools.ietf.org/html/draft-kumar-ipfix-sfc-extension-03 >Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-ipfix-sfc-extension-03 > >Abstract: > Service Function Chaining (SFC) is an architecture that enables any > operator to apply selective set of services by steering the traffic > through an ordered set of service functions without any topology > dependency. > > This document defines the required Information Elements to represent > the details about service flows over any Service Function Path. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Sun Jul 3 05:04: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 F036F12B018 for ; Sun, 3 Jul 2016 05:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 n2ooFP6zHFrp for ; Sun, 3 Jul 2016 05:04:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7055512B009 for ; Sun, 3 Jul 2016 05:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1866; q=dns/txt; s=iport; t=1467547444; x=1468757044; h=from:to:subject:date:message-id:mime-version; bh=13z1C0Oqe9tjBz6gxLeN0pEOVOnBPQGmkwCb7EJE/Wk=; b=bCnG5vqgH62bIGLoaowqc/2ZAyHIyA3tNSIdX6FLOKbKgsKgWXemDCbu e1nciSnWgOlMtYlWyqldEQI0/e0+3u4Vn9QC9xGM6lEVANdQjQ6LaP0SE Fpj4TYl6Om27mMhKhMT1OoPWbkTJiSx5B7yTaHotrUceCUis7WyPTvG1/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAgBN/nhX/4MNJK1cgnBOgVi0L4UBg?= =?us-ascii?q?XmGNoEEOBQBAQEBAQEBZRwLhEMQIwZiAQIJAT4CBDAnBIhDojePYo9RAQEBAQE?= =?us-ascii?q?FAQEBAQEihiiBeIoWK4IvBZNZhToBjkaBaoRWiGqQCQEeNoNwiUJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,569,1459814400"; d="scan'208,217";a="121851141" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jul 2016 12:04:03 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u63C43kv020400 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 3 Jul 2016 12:04:03 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; Sun, 3 Jul 2016 07:04:02 -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; Sun, 3 Jul 2016 07:04:02 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: SFC meeting Berlin Thread-Index: AQHR1SL99Ue452SxPkWJZtVgYi20Tg== Importance: high X-Priority: 1 Date: Sun, 3 Jul 2016 12:04:02 +0000 Message-ID: <1887AD82-ADDE-4E24-BBE7-194587238E10@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.183] Content-Type: multipart/alternative; boundary="_000_1887AD82ADDE4E24BBE7194587238E10ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] SFC meeting Berlin X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 03 Jul 2016 12:04:06 -0000 --_000_1887AD82ADDE4E24BBE7194587238E10ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRzoNCg0KV2UgaGF2ZSByZWNlaXZlZCBvbmx5IGEgc21hbGwgbnVtYmVyIG9mIGFnZW5k YSByZXF1ZXN0cyBmb3IgQmVybGluLCBhbmQgdGhlIG92ZXJhbGwgYWdlbmRhIGF0IHRoaXMgcG9p bnQgd291bGQgYmUgcmF0aGVyIGxpZ2h0Lg0KDQpJZiBhbnlvbmUgaXMgcGxhbm5pbmcgb24gcmVx dWVzdGluZyBhZ2VuZGEgdGltZSwgcGxlYXNlIGRvIHNvIG5vdywgc28gdGhhdCB3ZSBjYW4gZGV0 ZXJtaW5lIHdoZXRoZXIgYSBtZWV0aW5nIGlzIGp1c3RpZmllZC4NCg0KVGhhbmtzIQ0KDQpKaW0s IFRob21hcywgYW5kIE1hcnRpbg0K --_000_1887AD82ADDE4E24BBE7194587238E10ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIFdHOjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgaGF2ZSByZWNlaXZlZCBvbmx5IGEgc21h bGwgbnVtYmVyIG9mIGFnZW5kYSByZXF1ZXN0cyBmb3IgQmVybGluLCBhbmQgdGhlIG92ZXJhbGwg YWdlbmRhIGF0IHRoaXMgcG9pbnQgd291bGQgYmUgcmF0aGVyIGxpZ2h0LiZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgYW55b25lIGlzIHBsYW5uaW5nIG9uIHJlcXVlc3Rp bmcgYWdlbmRhIHRpbWUsIHBsZWFzZSBkbyBzbyBub3csIHNvIHRoYXQgd2UgY2FuIGRldGVybWlu ZSB3aGV0aGVyIGEgbWVldGluZyBpcyBqdXN0aWZpZWQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5UaGFua3MhPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5KaW0sIFRob21h cywgYW5kIE1hcnRpbjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVS RSI+PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1887AD82ADDE4E24BBE7194587238E10ciscocom_-- From nobody Sun Jul 3 05:04: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 8B8C312D127 for ; Sun, 3 Jul 2016 05:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 iN8h5Qlmlzrs for ; Sun, 3 Jul 2016 05:04:14 -0700 (PDT) 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 6826812D11E for ; Sun, 3 Jul 2016 05:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1866; q=dns/txt; s=iport; t=1467547454; x=1468757054; h=from:to:subject:date:message-id:mime-version; bh=+Hel1gqiQRV5XfpKaOwzKeVbEAglJitG5kOD7POxmIU=; b=JhfUfek9v4u+o1KDeTrE4D4aInwACvS05RGi6Ce7COjyJC39occAP4Pb 7MCBZjakIHNNUftk40yWZ+/PydPNvEm/V6j63H5raENGIFSNDFhTrhZ51 djpK48kAHH487oJc1NW2HA0/lbYxg7mwO5Kq+svsh5jKqxyWQnf9oxAAM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAgAP/nhX/5NdJa1cgnBOgVi0L4UBg?= =?us-ascii?q?XmGNoEEOBQBAQEBAQEBZRwLhEMQIwZiAQIJAT4CBDAnBIhDojePYo9RAQEBAQE?= =?us-ascii?q?FAQEBAQEihiiBeIoWK4IvBZNZhToBjkaBaoRWiGqQCQEeNoNwiUJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,569,1459814400"; d="scan'208,217";a="292237782" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2016 12:04:13 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u63C4DrX029310 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 3 Jul 2016 12:04:13 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; Sun, 3 Jul 2016 07:04:13 -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; Sun, 3 Jul 2016 07:04:12 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: SFC meeting Berlin Thread-Index: AQHR1SMD4swk6AvmDEuzOdnQ1/E/ZQ== Importance: high X-Priority: 1 Date: Sun, 3 Jul 2016 12:04:12 +0000 Message-ID: <1887AD82-ADDE-4E24-BBE7-194587238E10@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.183] Content-Type: multipart/alternative; boundary="_000_1887AD82ADDE4E24BBE7194587238E10ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] SFC meeting Berlin X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 03 Jul 2016 12:04:15 -0000 --_000_1887AD82ADDE4E24BBE7194587238E10ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRzoNCg0KV2UgaGF2ZSByZWNlaXZlZCBvbmx5IGEgc21hbGwgbnVtYmVyIG9mIGFnZW5k YSByZXF1ZXN0cyBmb3IgQmVybGluLCBhbmQgdGhlIG92ZXJhbGwgYWdlbmRhIGF0IHRoaXMgcG9p bnQgd291bGQgYmUgcmF0aGVyIGxpZ2h0Lg0KDQpJZiBhbnlvbmUgaXMgcGxhbm5pbmcgb24gcmVx dWVzdGluZyBhZ2VuZGEgdGltZSwgcGxlYXNlIGRvIHNvIG5vdywgc28gdGhhdCB3ZSBjYW4gZGV0 ZXJtaW5lIHdoZXRoZXIgYSBtZWV0aW5nIGlzIGp1c3RpZmllZC4NCg0KVGhhbmtzIQ0KDQpKaW0s IFRob21hcywgYW5kIE1hcnRpbg0K --_000_1887AD82ADDE4E24BBE7194587238E10ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIFdHOjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgaGF2ZSByZWNlaXZlZCBvbmx5IGEgc21h bGwgbnVtYmVyIG9mIGFnZW5kYSByZXF1ZXN0cyBmb3IgQmVybGluLCBhbmQgdGhlIG92ZXJhbGwg YWdlbmRhIGF0IHRoaXMgcG9pbnQgd291bGQgYmUgcmF0aGVyIGxpZ2h0LiZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgYW55b25lIGlzIHBsYW5uaW5nIG9uIHJlcXVlc3Rp bmcgYWdlbmRhIHRpbWUsIHBsZWFzZSBkbyBzbyBub3csIHNvIHRoYXQgd2UgY2FuIGRldGVybWlu ZSB3aGV0aGVyIGEgbWVldGluZyBpcyBqdXN0aWZpZWQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5UaGFua3MhPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5KaW0sIFRob21h cywgYW5kIE1hcnRpbjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVS RSI+PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1887AD82ADDE4E24BBE7194587238E10ciscocom_-- From nobody Sun Jul 3 12:06: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 CA4BC12B05B for ; Sun, 3 Jul 2016 12:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 BrehICPQ44Ud for ; Sun, 3 Jul 2016 12:06:03 -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 53C9512B036 for ; Sun, 3 Jul 2016 12:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2257; q=dns/txt; s=iport; t=1467572763; x=1468782363; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=uboeWULO279d0Q2BLMzuwWi6ITeCdo2hNDQazhPKAx4=; b=QptFA4wfTUJoSlyEvqrx9KuowQRVxsSKYOMmeXqMjNkYMcC3BeQntL62 Zcp5IsXic/Wrv/rU0VuNSOIIF9lAZFVETCbEw8ZWI2njHacZ4bXSlw8ZV VXe+e4n3NfY5TSL+E/6PYtiCbpbnpOxg6sLLiuwhMWmIh3yA3sanh2OR4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJBQD3YHlX/5FdJa1bgnBOgVK0NYUBg?= =?us-ascii?q?XmGGAKBJToSAQEBAQEBAWUnhEwBAQWBCQIBCAQBDAMBAgolDyMdCAIEARKIMMF?= =?us-ascii?q?2AQEBAQEBAQECAQEBAQEBAQEBHoYohE2EYIU7BYZSCYx+hToBjkaBaoRWiGqQC?= =?us-ascii?q?QElAi2DcG6INAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,570,1459814400"; d="scan'208,217";a="125360727" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2016 19:06:02 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u63J62J4008229 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 3 Jul 2016 19:06:02 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 3 Jul 2016 14:06: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; Sun, 3 Jul 2016 14:06:01 -0500 From: "Benoit Claise (bclaise)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] SFC meeting Berlin Thread-Index: AQHR1V3w5zlZ2tWGKEm7j3UbEIesGQ== Date: Sun, 3 Jul 2016 19:06:00 +0000 Message-ID: <4hhqh71ldm67l002vss8oro6.1467568574188@email.android.com> References: <1887AD82-ADDE-4E24-BBE7-194587238E10@cisco.com> In-Reply-To: <1887AD82-ADDE-4E24-BBE7-194587238E10@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_4hhqh71ldm67l002vss8oro61467568574188emailandroidcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] SFC meeting Berlin X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 03 Jul 2016 19:06:05 -0000 --_000_4hhqh71ldm67l002vss8oro61467568574188emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sent from my Samsung Galaxy smartphone. -------- Original message -------- From: "Jim Guichard (jguichar)" Date: 03/07/2016 14:04 (GMT+01:00) To: sfc@ietf.org Subject: [sfc] SFC meeting Berlin Dear WG: We have received only a small number of agenda requests for Berlin, and the= overall agenda at this point would be rather light. If anyone is planning on requesting agenda time, please do so now, so that = we can determine whether a meeting is justified. Thanks! Jim, Thomas, and Martin --_000_4hhqh71ldm67l002vss8oro61467568574188emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable




Sent from my Samsu= ng Galaxy smartphone.


-------- Original message --------
From: "Jim Guichard (jguichar)" <jguichar@cisco.com> <= /div>
Date: 03/07/2016 14:04 (GMT+01:00)
To: sfc@ietf.org
Subject: [sfc] SFC meeting Berlin

Dear WG:

We have received only a small number of agenda requests for Berlin, an= d the overall agenda at this point would be rather light. 

If anyone is planning on requesting agenda time, please do so now, so = that we can determine whether a meeting is justified.

Thanks!

Jim, Thomas, and Martin
--_000_4hhqh71ldm67l002vss8oro61467568574188emailandroidcom_-- From nobody Sun Jul 3 23:28: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 7BAAE12D511 for ; Sun, 3 Jul 2016 23:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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.426, 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 8dg_A-mQ2Rcv for ; Sun, 3 Jul 2016 23:28:40 -0700 (PDT) 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 7CB0812B05C for ; Sun, 3 Jul 2016 23:28:39 -0700 (PDT) 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 CNC66325; Mon, 04 Jul 2016 06:28:36 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 4 Jul 2016 07:28:05 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 4 Jul 2016 14:27:54 +0800 From: Xuxiaohu To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC meeting Berlin Thread-Index: AQHR1SL99Ue452SxPkWJZtVgYi20TqAHSgEA Date: Mon, 4 Jul 2016 06:27:54 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D568612@NKGEML515-MBX.china.huawei.com> References: <1887AD82-ADDE-4E24-BBE7-194587238E10@cisco.com> In-Reply-To: <1887AD82-ADDE-4E24-BBE7-194587238E10@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D568612NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.577A0215.00C8, 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: 29e27886a5fac8e716275b240f17e5da Archived-At: Subject: Re: [sfc] SFC meeting Berlin X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Jul 2016 06:28:42 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D568612NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgY28tY2hhaXJzLA0KDQpJIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCAxNSBtaW5zIGZvciBwcmVz ZW50aW5nIHRoZSBmb2xsb3dpbmcgZHJhZnQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQteHUtc2ZjLXVzaW5nLW1wbHMtc3ByaW5nLTA2DQoNCkJlc3QgcmVnYXJkcywNClhpYW9o dQ0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpTZW50OiBTdW5kYXksIEp1bHkgMDMsIDIwMTYgODow NCBQTQ0KVG86IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogW3NmY10gU0ZDIG1lZXRpbmcgQmVybGlu DQpJbXBvcnRhbmNlOiBIaWdoDQoNCkRlYXIgV0c6DQoNCldlIGhhdmUgcmVjZWl2ZWQgb25seSBh IHNtYWxsIG51bWJlciBvZiBhZ2VuZGEgcmVxdWVzdHMgZm9yIEJlcmxpbiwgYW5kIHRoZSBvdmVy YWxsIGFnZW5kYSBhdCB0aGlzIHBvaW50IHdvdWxkIGJlIHJhdGhlciBsaWdodC4NCg0KSWYgYW55 b25lIGlzIHBsYW5uaW5nIG9uIHJlcXVlc3RpbmcgYWdlbmRhIHRpbWUsIHBsZWFzZSBkbyBzbyBu b3csIHNvIHRoYXQgd2UgY2FuIGRldGVybWluZSB3aGV0aGVyIGEgbWVldGluZyBpcyBqdXN0aWZp ZWQuDQoNClRoYW5rcyENCg0KSmltLCBUaG9tYXMsIGFuZCBNYXJ0aW4NCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D568612NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIGNvLWNoYWlycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgMTUgbWlucyBmb3IgcHJlc2VudGluZyB0aGUg Zm9sbG93aW5nIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQteHUtc2ZjLXVzaW5nLW1wbHMtc3ByaW5nLTA2Ij5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQteHUtc2ZjLXVzaW5nLW1wbHMtc3ByaW5nLTA2PC9hPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5YaWFvaHU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkppbSBHdWljaGFyZCAoamd1aWNoYXIpPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwg SnVseSAwMywgMjAxNiA4OjA0IFBNPGJyPg0KPGI+VG86PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW3NmY10gU0ZDIG1lZXRpbmcgQmVybGluPGJyPg0KPGI+SW1wb3J0YW5j ZTo8L2I+IEhpZ2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldlIGhhdmUgcmVj ZWl2ZWQgb25seSBhIHNtYWxsIG51bWJlciBvZiBhZ2VuZGEgcmVxdWVzdHMgZm9yIEJlcmxpbiwg YW5kIHRoZSBvdmVyYWxsIGFnZW5kYSBhdCB0aGlzIHBvaW50IHdvdWxkIGJlIHJhdGhlciBsaWdo dC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5JZiBhbnlvbmUgaXMgcGxhbm5pbmcgb24gcmVxdWVzdGluZyBhZ2VuZGEg dGltZSwgcGxlYXNlIGRvIHNvIG5vdywgc28gdGhhdCB3ZSBjYW4gZGV0ZXJtaW5lIHdoZXRoZXIg YSBtZWV0aW5nIGlzIGp1c3RpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SmltLCBUaG9tYXMsIGFu ZCBNYXJ0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D568612NKGEML515MBXchi_-- From nobody Mon Jul 4 03:27: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 9D59F12B05A; Mon, 4 Jul 2016 03:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 kfYBqPw7f_wa; Mon, 4 Jul 2016 03:27:14 -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 CF70312B022; Mon, 4 Jul 2016 03:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13599; q=dns/txt; s=iport; t=1467628033; x=1468837633; h=from:to:cc:subject:date:message-id:mime-version; bh=XJh5tQUYR6h8eA1ZZrU6wemTNrFL8yFQbc/K9lNMNqg=; b=JdQ6DSFgDhcBs3VcAEvxZY3olgTnm3eXivq/dcNwTaHDHcPkCyAY4c7c 6fUSFdzAAgGKaGVO7/EYfdwEG8ZFYyee/sFdsVtDSoyek1LXoKInHfYZl 2D7hVqLpnqiwBz+cmqk23eb/OIRSL/SHDYY7IxQHp7LJ/oKRugqMDMsGE A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgCQOXpX/40NJK1cgnBOVnwGtCyCc?= =?us-ascii?q?oIPgXkihXaBNTgUAQEBAQEBAWUnhEwBAQUtTBIBCBEDAQIoORQJCgQBDQWIMA6?= =?us-ascii?q?6AQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiiETYRghTsFjjyFHYU6AYYIiD6PK?= =?us-ascii?q?pAJAR42g3BuiA1/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,574,1459814400"; d="scan'208,217";a="291838987" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jul 2016 10:27:12 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u64ARCxB013340 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jul 2016 10:27:12 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 4 Jul 2016 05:27:12 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 4 Jul 2016 05:27:11 -0500 From: "Saumya Dikshit (sadikshi)" To: Gregory Mirsky , "BIER (bier@ietf.org)" , "sfc@ietf.org" , "nvo3@ietf.org" , "rtg-ooam-dt@ietf.org" , "rtgwg@ietf.org" Thread-Topic: [nvo3] Comments to OOAM Requirements draft from Ron Bonica Thread-Index: AQHR1d6gu0FhL91PBUWmOM4v6y61oQ== Date: Mon, 4 Jul 2016 10:27:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.12.196] Content-Type: multipart/alternative; boundary="_000_D3A0227568F4Dsadikshiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rbonica@juniper.net" Subject: Re: [sfc] [nvo3] Comments to OOAM Requirements draft from Ron Bonica X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Jul 2016 10:27:17 -0000 --_000_D3A0227568F4Dsadikshiciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, I have following queries on Overlay OAM Requirements: >>>>> REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic, i.e. in-band with the monitored traffic, i.e. follow exactly the same path as data plane traffic, in forward direction, i.e. from ingress toward egress end point(s) of the OAM test session. "Exactly same path", should be made explicit if it's referring to the under= lay transport path. "OAM packets SHOULD be fate sharing with data traffic" will not apply to "R= EQ#3: centralized controller". I think "SHOULD" should be treated as a "MUST" if the reference is within t= he document :) >>>>> REQ#11: Overlay OAM MUST support fault localization of Loss of Continuity check. Does the "localization" maps to overlay node/link context ? Can we have a "= MAY" requirement for mapping it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement to narrow down to underlay for a speedier fault management. REQ#22 - REQ#25 refer to "per-segment". A "segment" maps to a NVO-tunnel? Shouldn't there be on a per-VNI basis a= s well. >>>>> REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such OAM methods MAY combine in-band monitoring or measurement in forward direction and out-of-band notification in the reverse direction, i.e. from egress to ingress end point of the OAM test session. In case of optical deployments like, fiber management (both request and res= ponse) can be out-of-band, hence may need a mention here. Thanks Saumya From: nvo3 > on behalf = of Gregory Mirsky > Date: Tuesday, April 5, 2016 at 1:39 AM To: "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: [nvo3] Comments to OOAM Requirements draft from Ron Bonica Dear All, Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> = tag. The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Net= works: Gap Analysis. Regards, Greg --_000_D3A0227568F4Dsadikshiciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <54A12C80EC4A9D47BC12A6E7B1505CFF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Greg,

I have following queries on  Overlay OAM Requirements:

>>>>> REQ#6:  Overlay OAM pac=
kets SHOULD be fate sharing with data traffic,
            i.e. in-band with the monitored traffic, i.e. follow exactly
            the same path as data plane traffic, in forward direction,
            i.e. from ingress toward egress end point(s) of the OAM test
            session.

“Exactly same path”, should be made explicit if it’s refe= rring to the underlay transport path.

"OAM packets SHOULD be fate sharing wit= h data traffic&= #8221; will not apply to "REQ#3:  centralized controller&#= 8221;.
I think “SHOULD” should be treated as= a “MUST” if the reference is within the document :)


>>>>> REQ#11: Overlay OAM MUS=
T support fault localization of Loss of
            Continuity check.
Does the “localization” maps to overlay node/link context ? Can= we have a “MAY” requirement for mapping
it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement
to narrow down to underlay for a speedier fault management.

REQ#22 — REQ#25 refer to “per-segment”. 
A “segment” maps to a NVO-tunnel?  Shouldn’t there b= e on a  per-VNI basis as well.

>>>>> REQ#7:  Overlay OAM MUS=
T support bi-directional OAM methods.  Such
            OAM methods MAY combine in-band monitoring or measurement in
            forward direction and out-of-band notification in the
            reverse direction, i.e. from egress to ingress end point of
            the OAM test session.

In case of optical deployments like, fiber management (both request an= d response) can be out-of-band, hence may
need a mention here. 


Thanks
Saumya

From: nvo3 <nvo3-bounces@ietf.org> on behalf of Gregory Mir= sky <gregory.mirsky@erics= son.com>
Date: Tuesday, April 5, 2016 at 1:3= 9 AM
To: "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org<= /a>" <sfc@ietf.org>, "<= a href=3D"mailto:nvo3@ietf.org">nvo3@ietf.org" <nvo3@ietf.org>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: [nvo3] Comments to OOAM Re= quirements draft from Ron Bonica

Dear All,

Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> tag= . The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Networks: Gap Analysis.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_D3A0227568F4Dsadikshiciscocom_-- From nobody Mon Jul 4 04:09:47 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 205A112B05E; Mon, 4 Jul 2016 04:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 rbBiHeFbXflR; Mon, 4 Jul 2016 04:09:28 -0700 (PDT) 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 AC08812B03C; Mon, 4 Jul 2016 04:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16124; q=dns/txt; s=iport; t=1467630568; x=1468840168; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ukg/UQo52rFxmySbAJQbCKWM6GjYUyKOPAcumwkv1c8=; b=QngqqmXJh7EPTTEtPVMn70ZBZptFrZhA3PstJtQGnTwIqnBfCgqPrwbn bTkNnEuc0kn9kI5LsM+Fi2hGyThg3zJG+dONAdsKI4HB6RN1XbYkbV3m4 aA0XDhlHobLAdcEN5Z8B7279498kOwSyqxv8KC6YTGESXyPF1rf75ICWt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAgD1QnpX/5FdJa1cgnBOVnwGtC2Cc?= =?us-ascii?q?oIPgXkihXYCgTQ4FAEBAQEBAQFlJ4RMAQEFLUwQAgEIEQMBAigHMhQJCAIEAQ0?= =?us-ascii?q?FiDAOuX8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYp1hE4ShTsFjjyFHYU6AYYIi?= =?us-ascii?q?D6BaoRWiGqQCQEeNoNwbogNfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,574,1459814400"; d="scan'208,217";a="293219403" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2016 11:09:26 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u64B9QEn020413 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jul 2016 11:09:26 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 4 Jul 2016 06:09:25 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Mon, 4 Jul 2016 06:09:26 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Saumya Dikshit (sadikshi)" , Gregory Mirsky , "BIER (bier@ietf.org)" , "sfc@ietf.org" , "nvo3@ietf.org" , "rtg-ooam-dt@ietf.org" , "rtgwg@ietf.org" Thread-Topic: [Bier] [nvo3] Comments to OOAM Requirements draft from Ron Bonica Thread-Index: AQHR1eSG9uAc9pVYcEa4KqSDjjMrVg== Date: Mon, 4 Jul 2016 11:09:26 +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/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.20.11] Content-Type: multipart/alternative; boundary="_000_D39FBA4116A342naikumarciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rbonica@juniper.net" Subject: Re: [sfc] [Bier] [nvo3] Comments to OOAM Requirements draft from Ron Bonica X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Jul 2016 11:09:31 -0000 --_000_D39FBA4116A342naikumarciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Saumya, Please see inline.. Hi Greg, I have following queries on Overlay OAM Requirements: >>>>> REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic, i.e. in-band with the monitored traffic, i.e. follow exactly the same path as data plane traffic, in forward direction, i.e. from ingress toward egress end point(s) of the OAM test session. "Exactly same path", should be made explicit if it's referring to the under= lay transport path. Yes, that is the intention. We will clarify it. "OAM packets SHOULD be fate sharing with data traffic" will not apply to "R= EQ#3: centralized controller". I think "SHOULD" should be treated as a "MUST" if the reference is within t= he document :) >>>>> REQ#11: Overlay OAM MUST support fault localization of Loss of Continuity check. Does the "localization" maps to overlay node/link context ? Can we have a "= MAY" requirement for mapping it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement to narrow down to underlay for a speedier fault management. MAY statement sounds reasonable. REQ#22 - REQ#25 refer to "per-segment". A "segment" maps to a NVO-tunnel? Yes, a segment referes to NVO tunnel between NVEs. Multiple such= segments may comprise an end-to-end tunnel. Shouldn't there be on a per-VNI basis as well. I think the granularity should definitely at per-VNI level. >>>>> REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such OAM methods MAY combine in-band monitoring or measurement in forward direction and out-of-band notification in the reverse direction, i.e. from egress to ingress end point of the OAM test session. In case of optical deployments like, fiber management (both request and res= ponse) can be out-of-band, hence may need a mention here. I see. We will check this. Thanks for your comments. Regards, Nagendra Thanks Saumya From: nvo3 > on behalf = of Gregory Mirsky > Date: Tuesday, April 5, 2016 at 1:39 AM To: "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: [nvo3] Comments to OOAM Requirements draft from Ron Bonica Dear All, Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> = tag. The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Net= works: Gap Analysis. Regards, Greg --_000_D39FBA4116A342naikumarciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
HI Saumya,

Please see inline..

Hi Greg,

I have following queries on  Overlay OAM Requirements:

>>>>> REQ#6:  Overlay OAM pac=
kets SHOULD be fate sharing with data traffic,
            i.e. in-band with the monitored traffic, i.e. follow exactly
            the same path as data plane traffic, in forward direction,
            i.e. from ingress toward egress end point(s) of the OAM test
            session.

“Exactly same path”, should be made explicit if it’s refe= rring to the underlay transport path.

<Nagendra> Yes, that is the intention. We will clarify it.

"OAM packets SHOULD be fate sharing wit= h data traffic&= #8221; will not apply to "REQ#3:  centralized controller&#= 8221;.
I think “SHOULD” should be treated as= a “MUST” if the reference is within the document :)
 


>>>>> REQ#11: Overlay OAM MUS=
T support fault localization of Loss of
            Continuity check.
Does the “localization” maps to overlay node/link context ? Can= we have a “MAY” requirement for mapping
it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement
to narrow down to underlay for a speedier fault management.

<Nagendra> MAY statement sounds reasonable.

REQ#22 — REQ#25 refer to “per-segment”. 
A “segment” maps to a NVO-tunnel? 

<Nagendra> Yes, a segment referes to NVO tunnel between NVEs. Mu= ltiple such segments may comprise an end-to-end tunnel.

 Shouldn’t there be on a  per-VNI basis as well.

<Nagendra>I think  the granularity should definitely at per= -VNI level. 

>>>>> REQ#7:  Overlay OAM MUS=
T support bi-directional OAM methods.  Such
            OAM methods MAY combine in-band monitoring or measurement in
            forward direction and out-of-band notification in the
            reverse direction, i.e. from egress to ingress end point of
            the OAM test session.

In case of optical deployments like, fiber management (both request an= d response) can be out-of-band, hence may
need a mention here. 
<Nagendra> I see. We will check this.

Thanks for your comments.

Regards,
Nagendra


Thanks
Saumya

From: nvo3 <nvo3-bounces@ietf.org> on behalf of Gregory Mir= sky <gregory.mirsky@erics= son.com>
Date: Tuesday, April 5, 2016 at 1:3= 9 AM
To: "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org<= /a>" <sfc@ietf.org>, "<= a href=3D"mailto:nvo3@ietf.org">nvo3@ietf.org" <nvo3@ietf.org>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: [nvo3] Comments to OOAM Re= quirements draft from Ron Bonica

Dear All,

Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> tag= . The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Networks: Gap Analysis.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_D39FBA4116A342naikumarciscocom_-- From nobody Mon Jul 4 11:09: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 5364A12D53C; Mon, 4 Jul 2016 11:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 GJMY2jTAxC0d; Mon, 4 Jul 2016 11:09:05 -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 A98A812D109; Mon, 4 Jul 2016 11:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20363; q=dns/txt; s=iport; t=1467655744; x=1468865344; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sfCkdqhwnABCOAha2s0GVsPHR6nKw2F0ARaVmIdNmvg=; b=FK7jzLiewfNqKs3UJLfmsBhfHL7nYFFtnfwQ/NoVJSs4Z2eloieLeEXX HKTkdLC13/6su4SZn5jkjlPLzCqRwu6YqIpGP0vopsDxMqQOOgdluJNlM BbJnvFrH+cVzFizcfC6XjF7zonv4gi2RjzIHeHP1zZrzh4D48FLj/sKwu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgAZpXpX/5BdJa1bgnBOVnwGtyaCD?= =?us-ascii?q?4F5IoV2AoE5OBQBAQEBAQEBZSeETAEBBS1MEAIBCBEDAQIoBzIUCQgCBAENBYg?= =?us-ascii?q?wDrkPAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4RNhBIRASoShTsFjjyFHYU6A?= =?us-ascii?q?YYIiD6BaoRWiGqQCQEeNoNwbodXNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,575,1459814400"; d="scan'208,217";a="293564810" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2016 18:09:03 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u64I93jn023782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jul 2016 18:09:03 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 4 Jul 2016 13:09:02 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 4 Jul 2016 13:09:02 -0500 From: "Saumya Dikshit (sadikshi)" To: "Nagendra Kumar Nainar (naikumar)" , Gregory Mirsky , "BIER (bier@ietf.org)" , "sfc@ietf.org" , "nvo3@ietf.org" , "rtg-ooam-dt@ietf.org" , "rtgwg@ietf.org" Thread-Topic: [Bier] [nvo3] Comments to OOAM Requirements draft from Ron Bonica Thread-Index: AQHR1dNfu0FhL91PBUWmOM4v6y61oaAIcTgAgADRbIA= Date: Mon, 4 Jul 2016 18:09:02 +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/14.6.5.160527 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.35.209] Content-Type: multipart/alternative; boundary="_000_D3A0A20568FC7sadikshiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rbonica@juniper.net" Subject: Re: [sfc] [Bier] [nvo3] Comments to OOAM Requirements draft from Ron Bonica X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Jul 2016 18:09:08 -0000 --_000_D3A0A20568FC7sadikshiciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nagendra, Thanks for the response. I missed this one in the below email: >>>>> REQ#14: Overlay OAM MUST have the ability to discover and exercise equal cost multipath (ECMP) paths in its transport network. This will require the underlay nodes/router/switches to support OAM semanti= cs, which may not be possible in case of brownfield deployments (deploying NVO tunnels over existing IP-c= ore network). Regards, Saumya. From: "Nagendra Kumar Nainar (naikumar)" > Date: Monday, July 4, 2016 at 4:39 PM To: sadikshi >, Gregory Mirsk= y >, "BIER = (bier@ietf.org)" = >, "sfc@ietf.org" >,= "nvo3@ietf.org" = >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: Re: [Bier] [nvo3] Comments to OOAM Requirements draft from Ron Bon= ica HI Saumya, Please see inline.. Hi Greg, I have following queries on Overlay OAM Requirements: >>>>> REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic, i.e. in-band with the monitored traffic, i.e. follow exactly the same path as data plane traffic, in forward direction, i.e. from ingress toward egress end point(s) of the OAM test session. "Exactly same path", should be made explicit if it's referring to the under= lay transport path. Yes, that is the intention. We will clarify it. "OAM packets SHOULD be fate sharing with data traffic" will not apply to "R= EQ#3: centralized controller". I think "SHOULD" should be treated as a "MUST" if the reference is within t= he document :) >>>>> REQ#11: Overlay OAM MUST support fault localization of Loss of Continuity check. Does the "localization" maps to overlay node/link context ? Can we have a "= MAY" requirement for mapping it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement to narrow down to underlay for a speedier fault management. MAY statement sounds reasonable. REQ#22 - REQ#25 refer to "per-segment". A "segment" maps to a NVO-tunnel? Yes, a segment referes to NVO tunnel between NVEs. Multiple such= segments may comprise an end-to-end tunnel. Shouldn't there be on a per-VNI basis as well. I think the granularity should definitely at per-VNI level. >>>>> REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such OAM methods MAY combine in-band monitoring or measurement in forward direction and out-of-band notification in the reverse direction, i.e. from egress to ingress end point of the OAM test session. In case of optical deployments like, fiber management (both request and res= ponse) can be out-of-band, hence may need a mention here. I see. We will check this. Thanks for your comments. Regards, Nagendra Thanks Saumya From: nvo3 > on behalf = of Gregory Mirsky > Date: Tuesday, April 5, 2016 at 1:39 AM To: "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: [nvo3] Comments to OOAM Requirements draft from Ron Bonica Dear All, Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> = tag. The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Net= works: Gap Analysis. Regards, Greg --_000_D3A0A20568FC7sadikshiciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0C2F24C0473AED42BE12D97790DE4DA6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Nagendra,

Thanks for the response. I missed this one in the below email:

>>>>> REQ#14: Overlay OAM MUS=
T have the ability to discover and exercise
            equal cost multipath (ECMP) paths in its transport network.

This will require the underlay nodes/router/switches to support OAM se= mantics, which may not be possible 
in case of brownfield deployments (deploying NVO tunnels over existing= IP-core network). 


Regards,
Saumya.


From: "Nagendra Kumar Nainar (= naikumar)" <naikumar@cisco.co= m>
Date: Monday, July 4, 2016 at 4:39 = PM
To: sadikshi <sadikshi@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>= , "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@= ietf.org" <nvo3@ietf.org&g= t;, "rtg-ooam-dt@ietf.org&= quot; <rtg-ooam-dt@ietf.org>, = "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [Bier] [nvo3] Comments= to OOAM Requirements draft from Ron Bonica

HI Saumya,

Please see inline..

Hi Greg,

I have following queries on  Overlay OAM Requirements:

>>>>> REQ#6:  Overlay OAM pac=
kets SHOULD be fate sharing with data traffic,
            i.e. in-band with the monitored traffic, i.e. follow exactly
            the same path as data plane traffic, in forward direction,
            i.e. from ingress toward egress end point(s) of the OAM test
            session.

“Exactly same path”, should be made explicit if it’s refe= rring to the underlay transport path.

<Nagendra> Yes, that is the intention. We will clarify it.

"OAM packets SHOULD be fate sharing wit= h data traffic&= #8221; will not apply to "REQ#3:  centralized controller&#= 8221;.
I think “SHOULD” should be treated as= a “MUST” if the reference is within the document :)
 


>>>>> REQ#11: Overlay OAM MUS=
T support fault localization of Loss of
            Continuity check.
Does the “localization” maps to overlay node/link context ? Can= we have a “MAY” requirement for mapping
it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement
to narrow down to underlay for a speedier fault management.

<Nagendra> MAY statement sounds reasonable.

REQ#22 — REQ#25 refer to “per-segment”. 
A “segment” maps to a NVO-tunnel? 

<Nagendra> Yes, a segment referes to NVO tunnel between NVEs. Mu= ltiple such segments may comprise an end-to-end tunnel.

 Shouldn’t there be on a  per-VNI basis as well.

<Nagendra>I think  the granularity should definitely at per= -VNI level. 

>>>>> REQ#7:  Overlay OAM MUS=
T support bi-directional OAM methods.  Such
            OAM methods MAY combine in-band monitoring or measurement in
            forward direction and out-of-band notification in the
            reverse direction, i.e. from egress to ingress end point of
            the OAM test session.

In case of optical deployments like, fiber management (both request an= d response) can be out-of-band, hence may
need a mention here. 
<Nagendra> I see. We will check this.

Thanks for your comments.

Regards,
Nagendra


Thanks
Saumya

From: nvo3 <nvo3-bounces@ietf.org> on behalf of Gregory Mir= sky <gregory.mirsky@erics= son.com>
Date: Tuesday, April 5, 2016 at 1:3= 9 AM
To: "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org<= /a>" <sfc@ietf.org>, "<= a href=3D"mailto:nvo3@ietf.org">nvo3@ietf.org" <nvo3@ietf.org>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: [nvo3] Comments to OOAM Re= quirements draft from Ron Bonica

Dear All,

Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> tag= . The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Networks: Gap Analysis.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_D3A0A20568FC7sadikshiciscocom_-- From nobody Mon Jul 4 23:50: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 06EE912D124 for ; Mon, 4 Jul 2016 23:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 v5hoRCFZyNoH for ; Mon, 4 Jul 2016 23:50:04 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D40112B05F for ; Mon, 4 Jul 2016 23:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3585; q=dns/txt; s=iport; t=1467701390; x=1468910990; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=cYwwgjwjrGTGM7rKC+ZBWb3sTPsD6o1pWw/uJdwAzg0=; b=DB54o0nvQcszOnHlcqFqV/OKkqEHf+EAI1UHjia54izPlqqK9B1ihf1r to28kzwLtCNT+Bx3zARtpwNV64CrMtlMp/ysZ8dufyWV+KaC8QTPQ2Pvn HxLU5vNL3ANsAhIV1KeI6Y9zVTdPWUQqgNxaS5QBKY5hLXRot7GWF5SwU E=; X-IronPort-AV: E=Sophos;i="5.26,578,1459814400"; d="scan'208,217";a="678086228" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 06:49:48 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u656nms7002486; Tue, 5 Jul 2016 06:49:48 GMT To: "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <1887AD82-ADDE-4E24-BBE7-194587238E10@cisco.com> <4hhqh71ldm67l002vss8oro6.1467568574188@email.android.com> From: Benoit Claise Message-ID: <165ac404-168c-51c3-4abe-f8241263c58d@cisco.com> Date: Tue, 5 Jul 2016 08:49:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4hhqh71ldm67l002vss8oro6.1467568574188@email.android.com> Content-Type: multipart/alternative; boundary="------------EFB1922D68370BE555DE6B30" Archived-At: Subject: Re: [sfc] SFC meeting Berlin X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 05 Jul 2016 06:50:06 -0000 This is a multi-part message in MIME format. --------------EFB1922D68370BE555DE6B30 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Mis-manipulation on my mobile. Sorry for the empty email. Regards, Benoit > > > > > Sent from my Samsung Galaxy smartphone. > > > -------- Original message -------- > From: "Jim Guichard (jguichar)" > Date: 03/07/2016 14:04 (GMT+01:00) > To: sfc@ietf.org > Subject: [sfc] SFC meeting Berlin > > Dear WG: > > We have received only a small number of agenda requests for Berlin, > and the overall agenda at this point would be rather light. > > If anyone is planning on requesting agenda time, please do so now, so > that we can determine whether a meeting is justified. > > Thanks! > > Jim, Thomas, and Martin > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --------------EFB1922D68370BE555DE6B30 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Mis-manipulation on my mobile. Sorry for the empty email.

Regards, Benoit




Sent from my Samsung Galaxy smartphone.


-------- Original message --------
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Date: 03/07/2016 14:04 (GMT+01:00)
Subject: [sfc] SFC meeting Berlin

Dear WG:

We have received only a small number of agenda requests for Berlin, and the overall agenda at this point would be rather light. 

If anyone is planning on requesting agenda time, please do so now, so that we can determine whether a meeting is justified.

Thanks!

Jim, Thomas, and Martin


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

--------------EFB1922D68370BE555DE6B30-- From nobody Tue Jul 5 05:05: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 4646212D742; Fri, 1 Jul 2016 08:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 DZ9rm18Wr_eA; Fri, 1 Jul 2016 08:38:48 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420F012D675; Fri, 1 Jul 2016 08:38:46 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-29-57768e4586a2 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 6E.CD.03614.54E86775; Fri, 1 Jul 2016 17:37:41 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0294.000; Fri, 1 Jul 2016 11:38:44 -0400 From: Gregory Mirsky To: "huubatwork@gmail.com" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" , "sfc@ietf.org" , "BIER (bier@ietf.org)" , "nvo3@ietf.org" Thread-Topic: [sfc] New documents published by Overlay OAM DT Thread-Index: AdGEaT578BdMGmKpSI6z+qZCjRGO1hPYO3KAAAcznfA= Date: Fri, 1 Jul 2016 15:38:44 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221ABE855@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A217BD@eusaamb103.ericsson.se> <57768471.4080707@gmail.com> In-Reply-To: <57768471.4080707@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221ABE855eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUyuXRPlK5rX1m4Qe9NBYtPDy8xWyydsYfJ 4tO7HSwW5yYtY7f4ueoTu8WM2ZdZLT43drJYvJ44lc3iZecGNoun8yUt1jc3MVt8/rON0eLC m9/MFs+ePmK2ePJgK7sDv8eU3xtZPSY2v2P32DnrLrvHkiU/mTyeTT/M5PG0u5klgC2KyyYl NSezLLVI3y6BK2PLiu2MBafiK45cOMfUwDgzpIuRk0NCwETizNKlTBC2mMSFe+vZuhi5OIQE jjJKTJ0yiRXCWcYoMfHnKmaQKjYBI4kXG3vYQRIiAi8ZJRafusAC4jALzGWR2DnhBDtIlbCA jUTjnOtgHSICthKt/zewQNhWEi03HoPZLAIqEvdabgDVcHDwCvhKrPvlDBIWEsiRaDr5jAkk zCmgKXF9lgBImBHouu+n1oBdyiwgLnHryXyoqwUkluw5zwxhi0q8fPyPFcJWkvj4ez47yBhm gXyJDe9UQcK8AoISJ2c+YZnAKDoLyaRZCFWzkFRBlOhILNj9iQ3C1pZYtvA1M4x95sBjJmTx BYzsqxg5SosLcnLTjQw3MQJj/5gEm+MOxr29nocYBTgYlXh4F5wrDRdiTSwrrsw9xCjBwawk wtvTVRYuxJuSWFmVWpQfX1Sak1p8iFGag0VJnFf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgbFv h+g//ZrtNzttv/FMe5XX4mGkcelf7ek+vxmBPF9m/pseW7Bt1ozd39z1rdYK10ssKuzfftz8 5r20Lvf47z4KnUUdtWVZHWU7HrjoW2xUlbn751c3t/ekK8v+5/OlWPndttxY1a/SW/f3maLc iZi9f2vdclOtplmmnI6evC2UeWpJ4ryUj0osxRmJhlrMRcWJAAWTREf5AgAA Archived-At: X-Mailman-Approved-At: Tue, 05 Jul 2016 05:04:59 -0700 Cc: "Ignas Bagdonas \(ibagdona@gmail.com\)" , "Carlos Pignataro \(cpignata\) \(cpignata@cisco.com\)" , "Erik Nordmark \(nordmark@sonic.net\)" , "dekumar@cisco.com" , "Petr Lapukhov \(petr@fb.com\)" , "Nagendra Kumar \(naikumar\) \(naikumar@cisco.com\)" , "Alia Atlas \(akatlas@gmail.com\)" , "santosh.pallagatti@gmail.com" , "David Mozes \(davidm@mellanox.com\)" Subject: Re: [sfc] New documents published by Overlay OAM DT X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 01 Jul 2016 15:38:51 -0000 --_000_7347100B5761DC41A166AC17F22DF11221ABE855eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huub, thank you for your interest in these documents and the questions. Frankly, I don't have an example of passive FM among ITEF-developed OAM too= ls. Distinction between proactive and on-demand may be subjective if we conside= r how a Measurement Agent from LMAP framework executes measurement tasks, i= .e. performs PM operation, based on pre-defined schedule. Is that proactive= or on-demand PM operation? Perhaps such distinction is unnecessary but we = used these categories because traditionally we refer to ping and traceroute= to be on-demand while BFD as proactive OAM. What would you suggest? Regards, Greg From: Huub van Helvoort [mailto:huubatwork@gmail.com] Sent: Friday, July 01, 2016 7:56 AM To: Gregory Mirsky; rtg-bfd@ietf.org; rtgwg@ietf.org; sfc@ietf.org; BIER (b= ier@ietf.org); nvo3@ietf.org Cc: Ignas Bagdonas (ibagdona@gmail.com); Carlos Pignataro (cpignata) (cpign= ata@cisco.com); Erik Nordmark (nordmark@sonic.net); dekumar@cisco.com; Petr= Lapukhov (petr@fb.com); santosh.pallagatti@gmail.com; Alia Atlas (akatlas@= gmail.com); Nagendra Kumar (naikumar) (naikumar@cisco.com); David Mozes (da= vidm@mellanox.com) Subject: Re: [sfc] New documents published by Overlay OAM DT Dear Greg, You wrote: the design team had published two documents: * Overlay OAM Requirements https://tools.ietf.org/html/draft-ooamdt= -rtgwg-ooam-requirement-00 * OAM for Overlay Networks: Gap Analysis https://tools.ietf.org/htm= l/draft-ooamdt-rtgwg-oam-gap-analysis-00 Both documents have subsections pro-active and on-demand for FM but active and passive for PM. Why is there no distinction made for active and passive FM, and pro-active and on-demand for PM? Best regards, Huub. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... --_000_7347100B5761DC41A166AC17F22DF11221ABE855eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huub,

thank you for your int= erest in these documents and the questions.

Frankly, I don’t= have an example of passive FM among ITEF-developed OAM tools.

Distinction between pr= oactive and on-demand may be subjective if we consider how a Measurement Ag= ent from LMAP framework executes measurement tasks, i.e. performs PM operat= ion, based on pre-defined schedule. Is that proactive or on-demand PM operation? Perhaps such distinction is u= nnecessary but we used these categories because traditionally we refer to p= ing and traceroute to be on-demand while BFD as proactive OAM.

What would you suggest= ?

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Huub van Helvoort [mailto:huubatwork@gmail.com]
Sent: Friday, July 01, 2016 7:56 AM
To: Gregory Mirsky; rtg-bfd@ietf.org; rtgwg@ietf.org; sfc@ietf.org; = BIER (bier@ietf.org); nvo3@ietf.org
Cc: Ignas Bagdonas (ibagdona@gmail.com); Carlos Pignataro (cpignata)= (cpignata@cisco.com); Erik Nordmark (nordmark@sonic.net); dekumar@cisco.co= m; Petr Lapukhov (petr@fb.com); santosh.pallagatti@gmail.com; Alia Atlas (a= katlas@gmail.com); Nagendra Kumar (naikumar) (naikumar@cisco.com); David Mozes (davidm@mellanox.com)
Subject: Re: [sfc] New documents published by Overlay OAM DT

 

Dear Greg,

You wrote:

the design team had published two documents:

·         Overlay OAM Requirements https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-requirement-00=

·         OAM for Overlay Networks: Gap Analysis https://tools.ietf.org/html/draft-ooamdt-rtgwg-oam-gap-analysis-00=


Both documents have subsections pro-active and on-demand for FM
but active and passive for PM.

Why is there no distinction made for active and passive FM,
and pro-active and on-demand for PM?

Best regards, Huub.



-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Always remember that you are unique...just like everyone else...<=
/o:p>
--_000_7347100B5761DC41A166AC17F22DF11221ABE855eusaamb103erics_-- From nobody Tue Jul 5 12:58: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 BB5D112D610 for ; Tue, 5 Jul 2016 12:58:51 -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 jgwlV4ettx4Z for ; Tue, 5 Jul 2016 12:58:46 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5123212D5FB for ; Tue, 5 Jul 2016 12:58:43 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id k68so192070110vkb.0 for ; Tue, 05 Jul 2016 12:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=7X3MLBhs19q2GfZyjXuI2H3yRpIzzhQiv3ureJbPFxc=; b=HDv4FEktB8GgXhw1KuQX3IBWWDCOX1s3wlbrilNRGAeD/CJhJ186fml9rMp0PzVyxA gC3DomOEpJ5Zr3mr82aftkcnBEZewV4+J4B7btHesoe/k/dWdeosXqpaxYuccI2wSsMX WggkBPviXgb3SOhG7Yfess+O3br/3XdsC1S6/PISw3Am3thXGlCKr/kdmqch0WeR3mnE gsP5WAdhNK2VmqP90pSYfZvLyGHfqEYQGGr1NFmll963WjFs6dYSY7cd3vmmTHZTmnIP nLzZJtJpeqIadR/MwiWNC1FrIHO8P9eCBkBSYghFIOoKlfrLQJd1gKbRVYmI2p0RgkMy fbiQ== 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:from:date:message-id :subject:to:cc; bh=7X3MLBhs19q2GfZyjXuI2H3yRpIzzhQiv3ureJbPFxc=; b=KwqMAs1H647gRGYNOAvOqoN5FfHXrRb3r5tR3UP13OTukUCOYqO3oVXpTMoyrXpq2+ Lfl5coeOwjOybTjeGVWWJioEG5bgfgw5jwcpROiVYvZiL3+LgRPuOBR9doXSp2t4Bz1n ZeOaNCXKH3l3QrL/Klqc/RAS7cgYf4hDF0PwyJW9iD/6lN7zHbsfjn5iPX7mJtwPRLkD Pu6wQg22VRsTldn70XY8yLErh2EZO4UMo7myPDxC9llmXAQZkjBwAy4pTAKGi0C8MMvA PloKWr2dVSDiIHoTKmxee5FsaP/JvUCrQfLC1xHSnA/pCm23gjgyb0tu9JP6TFAyOros 4JbQ== X-Gm-Message-State: ALyK8tIVD9p3M14sQ5/lQcIUsblLZ+1bRTGPL1szV4VkvxuA/e1F5fV25qr8ut+4t1U8Ku0Cm4QITRUCVrivTA== X-Received: by 10.31.192.14 with SMTP id q14mr8456323vkf.51.1467748722450; Tue, 05 Jul 2016 12:58:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.112 with HTTP; Tue, 5 Jul 2016 12:58:41 -0700 (PDT) From: Behcet Sarikaya Date: Tue, 5 Jul 2016 14:58:41 -0500 Message-ID: To: "sfc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mohamed Boucadair , "Dirk.von-Hugo@telekom.de" Subject: [sfc] New Version Notification for draft-sarikaya-sfc-hostid-serviceheader-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 19:58:52 -0000 Hi all, We submitted Rev. 03 of our draft entitled Service Function Chaining Service, Subscriber and Host Identification Use Cases and Metadata Chairs: we would like to ask for a slot in Berlin to present this draft. Regards, Behcet A new version of I-D, draft-sarikaya-sfc-hostid-serviceheader-03.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-sfc-hostid-serviceheader Revision: 03 Title: Service Function Chaining Service, Subscriber and Host Identification Use Cases and Metadata Document date: 2016-07-05 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-sarikaya-sfc-hostid-serviceheader-03.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-sfc-hostid-serviceheader/ Htmlized: https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-sarikaya-sfc-hostid-serviceheader-03 Abstract: This document discusses considerations related to passing service-, host- and subscriber-related information to upstream Service Functions for the sake of policy enforcement and appropriate SFC- inferred forwarding. Once the information is consumed by SFC-aware elements of an SFC-enabled domain, the information is stripped from packets so that privacy-sensitive information is not leaked outside an SFC-enabled domain. 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 From nobody Tue Jul 5 16:06: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 4703712D115; Tue, 5 Jul 2016 16:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E02BRbu8XBqX; Tue, 5 Jul 2016 16:06:11 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752F812B02F; Tue, 5 Jul 2016 16:06:11 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-17-577c3d20af9d Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 84.44.03614.02D3C775; Wed, 6 Jul 2016 01:05:05 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0294.000; Tue, 5 Jul 2016 19:06:08 -0400 From: Gregory Mirsky To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC meeting Berlin Thread-Index: AQHR1SMD9Ue452SxPkWJZtVgYi20TqAKdvIQ Date: Tue, 5 Jul 2016 23:06:08 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221AC167A@eusaamb103.ericsson.se> References: <1887AD82-ADDE-4E24-BBE7-194587238E10@cisco.com> In-Reply-To: <1887AD82-ADDE-4E24-BBE7-194587238E10@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221AC167Aeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyuXRPiK6ibU24waGbTBafHl5itlg6T93i X+teVosnD7ayO7B4TPm9kdVj56y77B5LlvxkCmCO4rJJSc3JLEst0rdL4Mq4u8WnYJN7xZ7j n5kbGLe4djFyckgImEjc+3SHEcIWk7hwbz0biC0kcJRRYu1Jpy5GLiB7GaPEo+2HWEESbAJG Ei829rCD2CICwRKv5v4Aa2YWyJTY3nAPrEZYQF5i5udnjBA1ChIznjwDqucAso0kVvQ4goRZ BFQkdv/5D7aLV8BXYtHeLrASIQEbib3dSSBhTgFbifX/dzKD2IxAp30/tYYJYpO4xK0n85kg ThaQWLLnPDOELSrx8vE/VghbSWLS0nOsEPX5EjMfv2WFWCUocXLmE5YJjKKzkIyahaRsFpKy WUAXMQtoSqzfpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjBylxQU5uelGhpsYgZF2TILNcQfj 3l7PQ4wCHIxKPLwLvlaHC7EmlhVX5h5ilOBgVhLh7bCsCRfiTUmsrEotyo8vKs1JLT7EKM3B oiTOq/9SMVxIID2xJDU7NbUgtQgmy8TBKdXAKGb0LN/PpcZ/av1y2YXBNZVvr7+9soBBL2e/ jNLNkCfbv/71fnx+dqUVlyqHwUKvAwsncwmczP3ywvJo/E3dvPNcS36YCdbu4Eq5ZrEm7034 umRFvjyz2gXOm/Ys3Lxw47k7xrkPl52PnmOtnywo7Cfs3XRL8sZ+uyWKq+K2XGb1L5+6N/nG DiWW4oxEQy3mouJEAGKMPtmwAgAA Archived-At: Cc: "rtg-ooam-dt@ietf.org" , "Alia Atlas \(akatlas@gmail.com\)" Subject: Re: [sfc] SFC meeting Berlin X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 05 Jul 2016 23:06:13 -0000 --_000_7347100B5761DC41A166AC17F22DF11221AC167Aeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBKaW0sIFdHIENoYWlycywgZXQuIGFsLA0KVGhlIE92ZXJsYXkgT0FNIGRlc2lnbiB0ZWFt IHdvdWxkIGFwcHJlY2lhdGUgb3Bwb3J0dW5pdHkgdG8gcmVwb3J0IG9uIG91ciB3b3JrLCBwcmVz ZW50IGFuZCBkaXNjdXNzIGN1cnJlbnQgc3RhdGUgb2YgZG9jdW1lbnRzICh1cGRhdGVzIHRvIHR3 byBleGlzdGluZyBkcmFmdHMgYW5kIHR3byBuZXcgd2lsbCBiZSBzdWJtaXR0ZWQgYmVmb3JlIHRo ZSBjdXQtb2ZmIGRhdGUpIHRvIHRoZSBTRkMgV0cuIFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGdy YW50IDMwIG1pbnV0ZXMgZm9yIHRoZSBwcmVzZW50YXRpb24gYW5kIFEmQT8gV2hhdCB3b3VsZCBi ZSB0aGUgZGVhZGxpbmUgdG8gc3VibWl0IHRoZSBwcmVzZW50YXRpb24gc2xpZGVzPw0KDQogICAg ICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3Jl Zw0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpTZW50OiBTdW5kYXksIEp1bHkgMDMsIDIwMTYgNTow NCBBTQ0KVG86IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogW3NmY10gU0ZDIG1lZXRpbmcgQmVybGlu DQpJbXBvcnRhbmNlOiBIaWdoDQoNCkRlYXIgV0c6DQoNCldlIGhhdmUgcmVjZWl2ZWQgb25seSBh IHNtYWxsIG51bWJlciBvZiBhZ2VuZGEgcmVxdWVzdHMgZm9yIEJlcmxpbiwgYW5kIHRoZSBvdmVy YWxsIGFnZW5kYSBhdCB0aGlzIHBvaW50IHdvdWxkIGJlIHJhdGhlciBsaWdodC4NCg0KSWYgYW55 b25lIGlzIHBsYW5uaW5nIG9uIHJlcXVlc3RpbmcgYWdlbmRhIHRpbWUsIHBsZWFzZSBkbyBzbyBu b3csIHNvIHRoYXQgd2UgY2FuIGRldGVybWluZSB3aGV0aGVyIGEgbWVldGluZyBpcyBqdXN0aWZp ZWQuDQoNClRoYW5rcyENCg0KSmltLCBUaG9tYXMsIGFuZCBNYXJ0aW4NCg== --_000_7347100B5761DC41A166AC17F22DF11221AC167Aeusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RGVhciBKaW0sIFdHIENoYWlycywgZXQuIGFsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIE92ZXJsYXkgT0FNIGRl c2lnbiB0ZWFtIHdvdWxkIGFwcHJlY2lhdGUgb3Bwb3J0dW5pdHkgdG8gcmVwb3J0IG9uIG91ciB3 b3JrLCBwcmVzZW50IGFuZCBkaXNjdXNzIGN1cnJlbnQgc3RhdGUgb2YgZG9jdW1lbnRzICh1cGRh dGVzIHRvIHR3byBleGlzdGluZyBkcmFmdHMgYW5kIHR3byBuZXcgd2lsbA0KIGJlIHN1Ym1pdHRl ZCBiZWZvcmUgdGhlIGN1dC1vZmYgZGF0ZSkgdG8gdGhlIFNGQyBXRy4gV291bGQgaXQgYmUgcG9z c2libGUgdG8gZ3JhbnQgMzAgbWludXRlcyBmb3IgdGhlIHByZXNlbnRhdGlvbiBhbmQgUSZhbXA7 QT8gV2hhdCB3b3VsZCBiZSB0aGUgZGVhZGxpbmUgdG8gc3VibWl0IHRoZSBwcmVzZW50YXRpb24g c2xpZGVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkppbSBHdWljaGFyZCAoamd1aWNoYXIpPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVs eSAwMywgMjAxNiA1OjA0IEFNPGJyPg0KPGI+VG86PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW3NmY10gU0ZDIG1lZXRpbmcgQmVybGluPGJyPg0KPGI+SW1wb3J0YW5jZTo8 L2I+IEhpZ2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5X ZSBoYXZlIHJlY2VpdmVkIG9ubHkgYSBzbWFsbCBudW1iZXIgb2YgYWdlbmRhIHJlcXVlc3RzIGZv ciBCZXJsaW4sIGFuZCB0aGUgb3ZlcmFsbCBhZ2VuZGEgYXQgdGhpcyBwb2ludCB3b3VsZCBiZSBy YXRoZXIgbGlnaHQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPklmIGFueW9uZSBpcyBwbGFubmluZyBvbiBy ZXF1ZXN0aW5nIGFnZW5kYSB0aW1lLCBwbGVhc2UgZG8gc28gbm93LCBzbyB0aGF0IHdlIGNhbiBk ZXRlcm1pbmUgd2hldGhlciBhIG1lZXRpbmcgaXMganVzdGlmaWVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFu a3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPkppbSwgVGhvbWFzLCBhbmQgTWFydGluPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF11221AC167Aeusaamb103erics_-- From nobody Wed Jul 6 01:26: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 05BE412D6B3 for ; Wed, 6 Jul 2016 01:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426] 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 GM3KwNILKq6c for ; Wed, 6 Jul 2016 01:26:04 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B6612D563 for ; Wed, 6 Jul 2016 01:26:03 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail31.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 06 Jul 2016 10:25:59 +0200 X-IronPort-AV: E=Sophos;i="5.28,318,1464645600"; d="scan'208,217";a="486555843" Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 06 Jul 2016 10:25:59 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 6 Jul 2016 10:25:59 +0200 From: To: , Date: Wed, 6 Jul 2016 10:27:04 +0200 Thread-Topic: [sfc] Query on SFC/SFP High Availablility Thread-Index: AdHSC5meP7jxeogmRASxO2iOxpBhfwFU37fw Message-ID: <05C81A773E48DD49B181B04BA21A342A41F45BA315@HE113484.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A41F45BA315HE113484emea1_" MIME-Version: 1.0 Archived-At: Cc: anil.sn@huawei.com, gaurav.agrawal@huawei.com, mohamed.boucadair@orange.com, sarikaya@ieee.org, vinods.kumar@gmail.com Subject: Re: [sfc] Query on SFC/SFP High Availablility X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 08:26:07 -0000 --_000_05C81A773E48DD49B181B04BA21A342A41F45BA315HE113484emea1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbmlsLA0KUGxlYXNlIHNlZSB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9mIG91ciBzZXJ2aWNl IGhlYWRlciBkcmFmdCBhdmFpbGFibGUgaGVyZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc2FyaWtheWEtc2ZjLWhvc3RpZC1zZXJ2aWNlaGVhZGVyLTAzDQpXZSBoYXZlIGFkZGVk IGEgbmV3IFRMViB0eXBlIGluIHRoZSBoZWFkZXIgdG8gY2FycnkgbWV0YWRhdGEgb24gc2xpY2Ug YW5kIHNlcnZpY2Ugc3BlY2lmaWMgcmVxdWlyZW1lbnRzIHN1Y2ggYXMgdmVyeSBsb3cgbGF0ZW5j eSBvciBoaWdoIHJlbGlhYmlsaXR5Lg0KWW91IGFyZSB2ZXJ5IHdlbGNvbWUgdG8gcGxlYXNlIHBv c3QgeW91ciBjb21tZW50cywgc3VnZ2VzdGlvbnMsIGFuZCBxdWVzdGlvbnMgLSBhbmQgd2hldGhl ciB0aGlzIGFkZHJlc3NlcyB5b3VyIHJlcXVlc3QhDQpUaGFua3MhDQpCZXN0IFJlZ2FyZHMNCkRp cmsNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QW5pbCBLdW1hcg0KU2VudDogTWl0dHdvY2gsIDI5LiBKdW5pIDIwMTYgMTU6MzkNClRvOiBzZmNA aWV0Zi5vcmcNCkNjOiBBbmlsIEt1bWFyIFMgTjsgR2F1cmF2IGFncmF3YWw7IFZpbm9kIEt1bWFy DQpTdWJqZWN0OiBbc2ZjXSBRdWVyeSBvbiBTRkMvU0ZQIEhpZ2ggQXZhaWxhYmxpbGl0eQ0KDQpI aSBBbGwsDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiBzb21lIHdvcmsgaXMgZG9uZSBpbiB0aGUg YXJlYSBvZiBoaWdoIGF2YWlsYWJpbGl0eSBmb3IgU0ZQLCB3ZSBjb3VsZG4ndCBmaW5kIGl0IGZy b20gbGlzdCBvZiBhdmFpbGFibGUgZHJhZnRzLg0KDQpXaXRoIFJlZ2FyZHMsDQpBbmlsIEt1bWFy IFMgTg0KDQo= --_000_05C81A773E48DD49B181B04BA21A342A41F45BA315HE113484emea1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglw YW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJs dWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkRlYXIgQW5pbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGxlYXNlIHNlZSB0aGUg dXBkYXRlZCB2ZXJzaW9uIG9mIG91ciBzZXJ2aWNlIGhlYWRlciBkcmFmdCBhdmFpbGFibGUgaGVy ZSA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmll cic+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhcmlrYXlhLXNm Yy1ob3N0aWQtc2VydmljZWhlYWRlci0wMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNhcmlrYXlhLXNmYy1ob3N0aWQtc2VydmljZWhlYWRlci0wMzwvYT4gPC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldlIGhhdmUgYWRkZWQgYSBuZXcgVExWIHR5cGUgaW4g dGhlIGhlYWRlciB0byBjYXJyeSBtZXRhZGF0YSBvbiBzbGljZSBhbmQgc2VydmljZSBzcGVjaWZp YyByZXF1aXJlbWVudHMgc3VjaCBhcyB2ZXJ5IGxvdyBsYXRlbmN5IG9yIGhpZ2ggcmVsaWFiaWxp dHkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPllvdSBhcmUgdmVyeSB3ZWxjb21lIHRvIHBsZWFzZSBwb3N0IHlvdXIgY29tbWVu dHMsIHN1Z2dlc3Rpb25zLCBhbmQgcXVlc3Rpb25zIC0gYW5kIHdoZXRoZXIgdGhpcyBhZGRyZXNz ZXMgeW91ciByZXF1ZXN0ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0OjBjbTt0ZXh0LWF1dG9zcGFjZTpub25lJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5CZXN0IFJlZ2FyZHM8YnI+RGlyayA8L3NwYW4+PHNwYW4gbGFuZz1E RSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+QW5pbCBLdW1hcjxicj48Yj5TZW50 OjwvYj4gTWl0dHdvY2gsIDI5LiBKdW5pIDIwMTYgMTU6Mzk8YnI+PGI+VG86PC9iPiBzZmNAaWV0 Zi5vcmc8YnI+PGI+Q2M6PC9iPiBBbmlsIEt1bWFyIFMgTjsgR2F1cmF2IGFncmF3YWw7IFZpbm9k IEt1bWFyPGJyPjxiPlN1YmplY3Q6PC9iPiBbc2ZjXSBRdWVyeSBvbiBTRkMvU0ZQIEhpZ2ggQXZh aWxhYmxpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGkgQWxsLDxvOnA+PC9vOnA+ PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPlBsZWFzZSBsZXQgdXMga25vdyBpZiBzb21lIHdvcmsgaXMg ZG9uZSBpbiB0aGUgYXJlYSBvZiBoaWdoIGF2YWlsYWJpbGl0eSBmb3IgU0ZQLCB3ZSBjb3VsZG4n dCBmaW5kIGl0IGZyb20gbGlzdCBvZiBhdmFpbGFibGUgZHJhZnRzLjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V2l0aCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkFuaWwgS3VtYXIgUyBOPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_05C81A773E48DD49B181B04BA21A342A41F45BA315HE113484emea1_-- From nobody Wed Jul 6 03:49: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 5B07212D1A4 for ; Wed, 6 Jul 2016 03:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 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.426] 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 cBZIJgVs4HBp for ; Wed, 6 Jul 2016 03:49:47 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1051512B049 for ; Wed, 6 Jul 2016 03:49:44 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 06 Jul 2016 12:49:41 +0200 X-IronPort-AV: E=Sophos;i="5.28,318,1464645600"; d="scan'208,217";a="486675780" Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 06 Jul 2016 12:49:41 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 6 Jul 2016 12:49:41 +0200 From: To: , Date: Wed, 6 Jul 2016 12:50:49 +0200 Thread-Topic: Updated draft Thread-Index: AQHRyfiUnbQmhcgLfU6RMps+FtOWoqALLwaA Message-ID: <05C81A773E48DD49B181B04BA21A342A41F45BA3EB@HE113484.emea1.cds.t-internal.com> References: <5E562D18-7BDE-426A-87DA-3A9505482551@telefonica.com> In-Reply-To: <5E562D18-7BDE-426A-87DA-3A9505482551@telefonica.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A41F45BA3EBHE113484emea1_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Updated draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 10:49:51 -0000 --_000_05C81A773E48DD49B181B04BA21A342A41F45BA3EBHE113484emea1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzLA0KVGhhbmtzIGEgbG90IGZvciB0aGUgdXBkYXRlIQ0KSSBhcHByZWNpYXRl IHZlcnkgbXVjaCB0aGlzIGRlc2NyaXB0aW9uIG9mIGFwcGxpY2F0aW9ucyBmb3IgU0ZDIGNvbmNl cHQgd2l0aCByZXNwZWN0IHRvIGZ1dHVyZSA1Ry4NCg0KUXVlc3Rpb25zIEkgaGF2ZSBhcmU6DQpD aC4gMi4xLjEuDQpXaGF0IGRvIHlvdSBoYXZlIGluIG1pbmQgZm9yIOKAmGNsYXNzaWZpY2F0aW9u IHNjaGVtZXMgZm9yIDVHIG5ldHdvcmtz4oCZIOKAkyBhcmUgeW91IHJlZmVycmluZyB0byB0aGUg c2xpY2luZyBjb25jZXB0IG9mIHNlcGFyYXRlZCBsb2dpY2FsIG5ldHdvcmtzIGV4aGliaXRpbmcg YSBzcGVjaWZpYyBwZXJmb3JtYW5jZSBhbmQgaW5jbHVkaW5nIHRhaWxvcmVkIG5ldHdvcmsgc2Vy dmljZSBmdW5jdGlvbnM/DQoNCkNoLiAyLjMNCklNTyBuZWVkcyBub3QgdG8gcmVwZWF0IG5lYXJs eSBmdWxsIGNvbnRlbnQgb2YgY2guIDEuMyDigJMgYnV0IG1heSBqdXN0IG1ha2UgcmVmZXJlbmNl IHRvIGl0DQoNCmV4dGVuZCBTRkMg4oCYc2NvcGUgdG8gZnVuY3Rpb25zIGluIHRoZSBSYWRpbyBB Y2Nlc3MgTmV0d29ya+KAmSA9PiB0aGlzIGFsc28gY29tcHJpc2VzIHRoZSBDb3JlIE5ldHdvcmsg d2l0aCBlbGVtZW50cyBzaG93biBpbiBGaWcuIDEgKGJlc2lkZSBTR2ktTEFOKSDigKYgYXMgZGV0 YWlsZWQgbGF0ZXIgb24sIHJpZ2h0Pw0KDQpPbmUgbWF5IGFsc28gbWVudGlvbiBoZXJlIHRoYXQg b3BlcmF0b3JzIGFyZSBmb3JjZWQgdG8gaGlnaCBlZmZpY2llbmN5IHdpdGggcmVzcGVjdCB0byBj b3N0IGFuZCByZXNvdXJjZXMgaW4gZGVwbG95bWVudCBhbmQgb3BlcmF0aW9uIHRvIG9mZmVyIGFm Zm9yZGFibGUgc2VydmljZXMgdG8gdGhlaXIgY3VzdG9tZXJzIOKAkyB3aGF0IGlzIGFsc28gc3Vw cG9ydGVkIGJ5IG1lYW5zIG9mIGZsZXhpYmxlIHRhaWxvcmVkIHNlcnZpY2UgY2hhaW5pbmcuDQoN CkJUVyBkbyB5b3UgcGxhbiB0byBkZXRhaWwgYWxzbyBvbiB0aGUgb3JjaGVzdHJhdGlvbiBwcm9j ZXNzZXMgcGxhbm5lZCDigJMgZS5nLiB1c2luZyBFVFNJIE5GViBNQU5PIGNvbmNlcHRzIG9yIHNp bWlsYXI/DQoNCg0KQWxzbyBJIGRldGVjdGVkIHNvbWUgbWlub3Igbml0cyB5b3UgbWF5IGNvbnNp ZGVyIGR1cmluZyBuZXh0IHVwZGF0ZToNCg0KdmlydHVhbGl6ZWQvdmlydHVhbGl6YXRpb24gdnMu IHZpcnR1YWxpc2VkL3ZpcnR1YWxpemF0aW9uLCBvcHRpbWl6YXRpb24gdnMuIG9wdGltaXphdGlv biA9PiBjb25zaXN0ZW50IHVzYWdlIG9mIG9uZSBmb3JtIG9ubHksIHBsZWFzZQ0KDQpQLiAxLzM6 IGNvbiA9PiBjYW4NCg0KUC4gNDogbXVjaCBlYXJsaWVyIHRoYXQgaW4gdGhlIGN1cnJlbnQgM0dQ UCBhcmNoaXRlY3R1cmUgPT4gbXVjaCBlYXJsaWVyIHRoYW4gaW4gdGhlIGN1cnJlbnQgM0dQUCBh cmNoaXRlY3R1cmUgT1INCuKAmGFscmVhZHkgdmVyeSBuZWFyIHRvIHRoZSBhY2Nlc3PigJkNCg0K cC4gNTogcGFydG5lcnNoaXAgKDVHUFBQKSBbNV0gPT4gcGFydG5lcnNoaXAoNUdQUFApIFsyXQ0K aSkgTWVkaXVtID0+IGlpKSBNZWRpdW0NCnAuIDY6IEZpZ3VyZSAyID0+IEZpZ3VyZSAxDQoNCnAu IDg6IFRoaXMgYXBwcm9hY2ggZW5hYmxlcyBlbmFibGVzID0+IFRoaXMgYXBwcm9hY2ggZW5hYmxl cw0KDQpwLiA5Og0KSSBzdWdnZXN0IHRvIGFsaWduIHRoZSB3b3JkaW5nIGluIEZpZy4gMiBhbmQg dGhlIG1lbnRpb25lZCBleGFtcGxlcyBlLmcuIOKAmEhhcHRpYy9UYWN0aWxlIEludGVybmV04oCZ LCDigJhCcm9hZGJhbmQgSW50ZXJuZXQgQWNjZXNz4oCZDQphbmQgdG8gYWRkIGEgcmVmZXJlbmNl IHRvIEZpZ3VyZSAyIGhlcmUNCg0KVk5GcyA9PiBORnMgW29yIGRlZmluZSBWTkZdDQpvZiB0aGUg dGhlIG5ldHdvcmsgPT4gb2YgdGhlIG5ldHdvcmsNCg0KcC4gMTA6IHRoZXNlIGZ1bmN0aW9ucyB3 ZXJlID0+IHRoZXNlIGZ1bmN0aW9ucyBhcmUNCnRyYWRpdGlvbmFsIGFjY2Vzcy1jb3JlIGRlcGxv eW1lbnQgPT4gdHJhZGl0aW9uYWxseSBzZXBhcmF0ZWQgZGVwbG95bWVudCBvZiBhY2Nlc3MgYW5k IGNvcmUgZG9tYWlucw0KcC4xMzogZGVsZXRlIFs1XSBodHRwczovLzVnLXBwcC5ldQ0KDQo7LSkN ClRoYW5rcyAmIEJlc3QgUmVnYXJkcw0KRGlyaw0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBFRFJPIEFORFJFUyBBUkFOREEgR1VUSUVSUkVa DQpTZW50OiBTb25udGFnLCAxOS4gSnVuaSAyMDE2IDA5OjAzDQpUbzogc2ZjQGlldGYub3JnDQpT dWJqZWN0OiBbc2ZjXSBVcGRhdGVkIGRyYWZ0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1hcmFuZGEtc2ZjLWRwLW1vYmlsZS0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgUGVkcm8gQS4gQXJhbmRhIEd1dGllcnJleiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVU RiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgZHJhZnQtYXJhbmRhLXNmYy1kcC1tb2JpbGUN ClJldmlzaW9uOiAgICAwMQ0KVGl0bGU6ICAgICAgIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcg RGF0YXBsYW5lIEVsZW1lbnRzIGluIE1vYmlsZSBOZXR3b3Jrcw0KRG9jdW1lbnQgZGF0ZTogICAy MDE2LTA2LTEzDQpHcm91cDogICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAg ICAgMTQNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYXJhbmRhLXNmYy1kcC1tb2JpbGUtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXJhbmRhLXNmYy1kcC1tb2JpbGUv DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFyYW5k YS1zZmMtZHAtbW9iaWxlLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWFyYW5kYS1zZmMtZHAtbW9iaWxlLTAxDQoNCkFic3RyYWN0Og0K ICAgVGhlIGV2b2x1dGlvbiBvZiB0aGUgbmV0d29yayB0b3dhcmRzIDVHIGltcGxpZXMgYSBjaGFs bGVuZ2UgZm9yIHRoZQ0KICAgaW5mcmFzdHJ1Y3R1cmUuICBUaGUgdGFyZ2V0ZWQgc2VydmljZXMg YW5kIHRoZSBmdWxsIGRlcGxveW1lbnQgb2YNCiAgIHZpcnR1YWxpemF0aW9uIGluIGFsbCBzZWdt ZW50cyBvZiB0aGUgbmV0d29yayB3aWxsIG5lZWQgc2VydmljZQ0KICAgZnVuY3Rpb24gY2hhaW5z IHRoYXQgcHJldmlvdXNseSByZXNpZGVkIGluIHRoZShsb2NhbCBhbmQgcmVtb3RlKQ0KICAgaW5m cmFzdHJ1Y3R1cmUgb2YgdGhlIE5ldHdvcmsgb3BlcmF0b3JzIHRvIGV4dGVuZCB0byB0aGUgcmFk aW8gYWNjZXNzDQogICBuZXR3b3JrIChSQU4pLg0KDQogICBJbiB0aGlzIGRyYWZ0IHdlIHByb3Zp ZGUgYSBub24tZXhoYXVzdGl2ZSBidXQgcmVwcmVzZW50YXRpdmUgbGlzdCBvZg0KICAgc2Vydmlj ZSBmdW5jdGlvbnMgaW4gNEcgYW5kIDVHIG5ldHdvcmtzLCBhbmQgZXhwbG9yZSBkaWZmZXJlbnQN CiAgIHNjZW5hcmlvcyBmb3Igc2VydmljZS1hd2FyZSBvcmNoZXN0cmF0aW9uLg0KDQogICBXZSBi YXNlIG9uIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBbUkZDNzQ5OF0gYW5kIGFyY2hpdGVjdHVyZSBm cmFtZXdvcmsNCiAgIFtSRkM3NjY1XSAgb2YgdGhlIFNGQyB3b3JraW5nIGdyb3VwLCBhcyB3ZWxs IG9uIHRoZSBleGlzdGluZyBtb2JpbGUNCiAgIG5ldHdvcmtzIHVzZSBjYXNlcyBbSS1ELmlldGYt c2ZjLXVzZS1jYXNlLW1vYmlsaXR5XSAgYW5kIHRoZQ0KICAgcmVxdWlyZW1lbnQgZ2F0aGVyaW5n IHByb2Nlc3Mgb2YgdGhlIElUVS1SIElNVCAyMDIwIFsxXSBhbmQgZGlmZmVyZW50DQogICBpbml0 aWF0aXZlcyBpbiBFdXJvcGUgWzJdLCBLb3JlYSBbM10gYW5kIENoaW5hIFs0XSB0byBhbnRpY2lw YXRlDQogICBuZXR3b3JrIGVsZW1lbnRzIHRoYXQgd2lsbCBiZSBuZWVkZWQgaW4gNUcgbmV0d29y a3MuDQoNCiAgIFdlIHRoZW4gZXhwbG9yZSBzZXJ2aWNlLWF3YXJlIG9yY2hlc3RyYXRpb24gc2Nl bmFyaW9zIGlkZW50aWZ5aW5nDQogICB3aGVyZSBkaWZmZXJlbnQgbmV0d29yayBmdW5jdGlvbnMg Y29uIGJlIGRlcGxveWVkIGluIGEgZnVsbHkNCiAgIHZpcnR1YWxpc2VkIGZ1dHVyZSBuZXR3b3Jr LCB3aGVyZSBib3RoIHRoZSBjb3JlIGFuZCB0aGUgZWRnZSBwcm92aWRlDQogICBhZHZhbmNlZCB2 aXJ0dWFsaXNhdGlvbiBjYXBhYmlsaXRpZXMuDQoNCg0KLS0tDQpEci4gUGVkcm8gQS4gQXJhbmRh IEd1dGnDqXJyZXoNCg0KVGVjaG5vbG9neSBFeHBsb3JhdGlvbiAtDQpOZXR3b3JrIElubm92YXRp b24gJiBWaXJ0dWFsaXNhdGlvbg0KZW1haWw6IHBlZHJvYSBkMHQgYXJhbmRhIEF0IHRlbGVmb25p Y2EgZDB0IGNvbQ0KVGVsZWbDs25pY2EsIEludmVzdGlnYWNpw7NuIHkgRGVzYXJyb2xsbw0KQy8g WnVyYmFyw6FuLDEyDQoyODAxMCBNYWRyaWQsIFNwYWluDQoNCkZyYWdlbiBzaW5kIG5pY2h0IGRh LCB1bSBiZWFudHdvcnRldCB6dSB3ZXJkZW4uDQpGcmFnZW4gc2luZCBkYSwgdW0gZ2VzdGVsbHQg enUgd2VyZGVuLg0KR2VvcmcgS3JlaXNsZXINCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNp dmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHBy aXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBw ZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRh cmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXph Y2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0 YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEg cmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNv bXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1 IGRlc3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5z bWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5k ZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJv dmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJy b3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRl ciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQg dGhlbiBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2Vt IGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1h w6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2 byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5o b3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBs ZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3Jp emHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZp Z2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVl IG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2Nl ZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQo= --_000_05C81A773E48DD49B181B04BA21A342A41F45BA3EBHE113484emea1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0 IjsNCglwYW5vc2UtMToyIDE1IDMgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5Ok1vbmFjbzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KaDENCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6 IkhlYWRpbmcgMSBDaGFyIjsNCgltYXJnaW4tdG9wOjEyLjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtaW5kZW50Oi0yMS42cHQ7 DQoJbGluZS1oZWlnaHQ6MTIwJTsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCWZvbnQtc2l6 ZToxNi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLCJzYW5zLXNlcmlmIjsNCglm b250LXZhcmlhbnQ6c21hbGwtY2FwczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpJVDsNCglmb250 LXdlaWdodDpub3JtYWw7fQ0KaDINCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxl LWxpbms6IkhlYWRpbmcgMiBDaGFyIjsNCgltYXJnaW4tdG9wOjE4LjBwdDsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206Ni4wcHQ7DQoJbWFyZ2luLWxlZnQ6MjguOHB0Ow0KCXRl eHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWluZGVudDotMjguOHB0Ow0KCWxpbmUtaGVpZ2h0OjEy MCU7DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCglmb250LXNpemU6MTQuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIExpZ2h0Iiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6SVQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsO30NCmgzDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDMgQ2hhciI7DQoJbWFyZ2luLXRvcDoxOC4wcHQ7 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjYuMHB0Ow0KCW1hcmdpbi1sZWZ0 OjM2LjBwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1pbmRlbnQ6LTM2LjBwdDsNCgls aW5lLWhlaWdodDoxMjAlOw0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsInNhbnMtc2VyaWYiOw0KCWZvbnQt dmFyaWFudDpzbWFsbC1jYXBzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOklUOw0KCWZvbnQtd2Vp Z2h0Om5vcm1hbDt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGlu azoiSGVhZGluZyA0IENoYXIiOw0KCW1hcmdpbi10b3A6MTAuMHB0Ow0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250 LXN0eWxlOml0YWxpYzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K c3Bhbi5IZWFkaW5nMUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMSBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAxIjsNCglmb250 LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCgljb2xvcjojMzY1RjkxOw0KCWZvbnQtd2VpZ2h0 OmJvbGQ7fQ0Kc3Bhbi5IZWFkaW5nMkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMiBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAy IjsNCglmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCgljb2xvcjojNEY4MUJEOw0KCWZv bnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5IZWFkaW5nM0NoYXINCgl7bXNvLXN0eWxlLW5hbWU6Ikhl YWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi SGVhZGluZyAzIjsNCglmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCgljb2xvcjojNEY4 MUJEOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5UdHVsbzMsIGxpLlR0dWxvMywgZGl2LlR0dWxv Mw0KCXttc28tc3R5bGUtbmFtZToiVMOtdHVsbyAzIjsNCgltc28tc3R5bGUtbGluazoiVMOtdHVs byAzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4u VHR1bG8zQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUw610dWxvIDMgQ2FyIjsNCgltc28tc3R5bGUt bGluazoiVMOtdHVsbyAzIjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsInNhbnMtc2Vy aWYiOw0KCWZvbnQtdmFyaWFudDpzbWFsbC1jYXBzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOklU O30NCnAuVHR1bG8yLCBsaS5UdHVsbzIsIGRpdi5UdHVsbzINCgl7bXNvLXN0eWxlLW5hbWU6IlTD rXR1bG8gMiI7DQoJbXNvLXN0eWxlLWxpbms6IlTDrXR1bG8gMiBDYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlR0dWxvMkNhcg0KCXttc28tc3R5bGUt bmFtZToiVMOtdHVsbyAyIENhciI7DQoJbXNvLXN0eWxlLWxpbms6IlTDrXR1bG8gMiI7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLCJzYW5zLXNlcmlmIjsNCglmb250LXZhcmlhbnQ6c21h bGwtY2FwczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpJVDt9DQpwLlR0dWxvMSwgbGkuVHR1bG8x LCBkaXYuVHR1bG8xDQoJe21zby1zdHlsZS1uYW1lOiJUw610dWxvIDEiOw0KCW1zby1zdHlsZS1s aW5rOiJUw610dWxvIDEgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5UdHVsbzFDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlTDrXR1bG8gMSBDYXIiOw0K CW1zby1zdHlsZS1saW5rOiJUw610dWxvIDEiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0 Iiwic2Fucy1zZXJpZiI7DQoJZm9udC12YXJpYW50OnNtYWxsLWNhcHM7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6SVQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkhlYWRpbmc0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQiOw0KCWZv bnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiM0RjgxQkQ7DQoJZm9udC13ZWln aHQ6Ym9sZDsNCglmb250LXN0eWxlOml0YWxpYzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzAuODVwdCAzLjBjbSA3MC44 NXB0IDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwv aGVhZD48Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tVVMgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5EZWFyIGF1dGhvcnMsPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5UaGFua3MgYSBsb3QgZm9yIHRoZSB1cGRhdGUhPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5JIGFwcHJlY2lhdGUgdmVyeSBtdWNoIHRoaXMgZGVz Y3JpcHRpb24gb2YgYXBwbGljYXRpb25zIGZvciBTRkMgY29uY2VwdCB3aXRoIHJlc3BlY3QgdG8g ZnV0dXJlIDVHLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6IzFGNDk3RCc+UXVlc3Rpb25zIEkgaGF2ZSBhcmU6PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEJz5DaC4gMi4xLjEuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5XaGF0IGRv IHlvdSBoYXZlIGluIG1pbmQgZm9yIOKAmGNsYXNzaWZpY2F0aW9uIHNjaGVtZXMgZm9yIDVHIG5l dHdvcmtz4oCZIOKAkyBhcmUgeW91IHJlZmVycmluZyB0byB0aGUgc2xpY2luZyBjb25jZXB0IG9m IHNlcGFyYXRlZCBsb2dpY2FsIG5ldHdvcmtzIGV4aGliaXRpbmcgYSBzcGVjaWZpYyBwZXJmb3Jt YW5jZSBhbmQgaW5jbHVkaW5nIHRhaWxvcmVkIG5ldHdvcmsgc2VydmljZSBmdW5jdGlvbnM/IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0 OTdEJz5DaC4gMi4zIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+SU1PIG5lZWRzIG5vdCB0 byByZXBlYXQgbmVhcmx5IGZ1bGwgY29udGVudCBvZiBjaC4gMS4zIOKAkyBidXQgbWF5IGp1c3Qg bWFrZSByZWZlcmVuY2UgdG8gaXQgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+ZXh0ZW5kIFNGQyDigJhzY29wZSB0 byBmdW5jdGlvbnMgaW4gdGhlIFJhZGlvIEFjY2VzcyBOZXR3b3Jr4oCZID0mZ3Q7IHRoaXMgYWxz byBjb21wcmlzZXMgdGhlIENvcmUgTmV0d29yayB3aXRoIGVsZW1lbnRzIHNob3duIGluIEZpZy4g MSAoYmVzaWRlIFNHaS1MQU4pIOKApiBhcyBkZXRhaWxlZCBsYXRlciBvbiwgcmlnaHQ/PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEJz5PbmUgbWF5IGFsc28gbWVudGlvbiBoZXJlIHRoYXQgb3BlcmF0b3Jz IGFyZSBmb3JjZWQgdG8gaGlnaCBlZmZpY2llbmN5IHdpdGggcmVzcGVjdCB0byBjb3N0IGFuZCBy ZXNvdXJjZXMgaW4gZGVwbG95bWVudCBhbmQgb3BlcmF0aW9uIHRvIG9mZmVyIGFmZm9yZGFibGUg c2VydmljZXMgdG8gdGhlaXIgY3VzdG9tZXJzIOKAkyB3aGF0IGlzIGFsc28gc3VwcG9ydGVkIGJ5 IG1lYW5zIG9mIGZsZXhpYmxlIHRhaWxvcmVkIHNlcnZpY2UgY2hhaW5pbmcuIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5CVFcg ZG8geW91IHBsYW4gdG8gZGV0YWlsIGFsc28gb24gdGhlIG9yY2hlc3RyYXRpb24gcHJvY2Vzc2Vz IHBsYW5uZWQg4oCTIGUuZy4gdXNpbmcgRVRTSSBORlYgTUFOTyBjb25jZXB0cyBvciBzaW1pbGFy PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPkFsc28gSSBkZXRlY3Rl ZCBzb21lIG1pbm9yIG5pdHMgeW91IG1heSBjb25zaWRlciBkdXJpbmcgbmV4dCB1cGRhdGU6PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QnPnZpcnR1YWxpemVkL3ZpcnR1YWxpemF0aW9uIHZzLiB2aXJ0dWFsaXNlZC92aXJ0dWFsaXph dGlvbiwgb3B0aW1pemF0aW9uIHZzLiBvcHRpbWl6YXRpb24gPSZndDsgY29uc2lzdGVudCB1c2Fn ZSBvZiBvbmUgZm9ybSBvbmx5LCBwbGVhc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+UC4gMS8zOiBjb24gPSZndDsgY2FuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QnPlAuIDQ6IG11Y2ggZWFybGllciB0aGF0IGluIHRoZSBjdXJyZW50IDNHUFAgYXJjaGl0ZWN0 dXJlID0mZ3Q7IG11Y2ggZWFybGllciB0aGFuIGluIHRoZSBjdXJyZW50IDNHUFAgYXJjaGl0ZWN0 dXJlIE9SPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz7igJhhbHJlYWR5IHZlcnkgbmVhciB0 byB0aGUgYWNjZXNz4oCZIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtjb2xvcjojMUY0OTdEJz5wLiA1OiBwYXJ0bmVyc2hpcCAoNUdQUFApIFs1XSA9Jmd0 OyBwYXJ0bmVyc2hpcCg1R1BQUCkgWzJdPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5pKSBN ZWRpdW0gPSZndDsgaWkpIE1lZGl1bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+cC4gNjogRmlndXJlIDIgPSZndDsgRmlndXJlIDE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCc+cC4gODogVGhpcyBhcHByb2FjaCBlbmFibGVzIGVuYWJsZXMgPSZndDsgVGhpcyBhcHByb2Fj aCBlbmFibGVzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QnPnAuIDk6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+SSBzdWdn ZXN0IHRvIGFsaWduIHRoZSB3b3JkaW5nIGluIEZpZy4gMiBhbmQgdGhlIG1lbnRpb25lZCBleGFt cGxlcyBlLmcuIOKAmEhhcHRpYy9UYWN0aWxlIEludGVybmV04oCZLCDigJhCcm9hZGJhbmQgSW50 ZXJuZXQgQWNjZXNz4oCZPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5hbmQgdG8gYWRkIGEg cmVmZXJlbmNlIHRvIEZpZ3VyZSAyIGhlcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+Vk5GcyA9Jmd0OyBORnMgW29yIGRlZmlu ZSBWTkZdPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5vZiB0aGUgdGhlIG5ldHdvcmsgPSZn dDsgb2YgdGhlIG5ldHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPnAuIDEwOiB0aGVzZSBmdW5jdGlvbnMgd2VyZSA9Jmd0OyB0 aGVzZSBmdW5jdGlvbnMgYXJlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPnRyYWRpdGlvbmFsIGFjY2Vzcy1jb3JlIGRlcGxveW1lbnQgPSZndDsg dHJhZGl0aW9uYWxseSBzZXBhcmF0ZWQgZGVwbG95bWVudCBvZiBhY2Nlc3MgYW5kIGNvcmUgZG9t YWluczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7 bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9RVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+cC4xMzogZGVsZXRlIFs1XSA8YSBocmVmPSJodHRwczovLzVnLXBwcC5ldSI+aHR0 cHM6Ly81Zy1wcHAuZXU8L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFu IGxhbmc9RVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDowY207dGV4dC1hdXRvc3BhY2U6 bm9uZSc+PHNwYW4gbGFuZz1FUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz47LSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0OjBjbTt0ZXh0LWF1 dG9zcGFjZTpub25lJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFua3MgJmFtcDsgQmVzdCBSZWdh cmRzPGJyPkRpcmsgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSA8 Yj5PbiBCZWhhbGYgT2YgPC9iPlBFRFJPIEFORFJFUyBBUkFOREEgR1VUSUVSUkVaPGJyPjxiPlNl bnQ6PC9iPiBTb25udGFnLCAxOS4gSnVuaSAyMDE2IDA5OjAzPGJyPjxiPlRvOjwvYj4gc2ZjQGll dGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbc2ZjXSBVcGRhdGVkIGRyYWZ0PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFu IGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28n PkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hcmFuZGEtc2ZjLWRwLW1vYmlsZS0wMS50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9z cGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9u dC1mYW1pbHk6TW9uYWNvJz5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBlZHJv IEEuIEFyYW5kYSBHdXRpZXJyZXogYW5kIHBvc3RlZCB0byB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBs YW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvJz5J RVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250 LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4g bGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyc+ TmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtYXJh bmRhLXNmYy1kcC1tb2JpbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2Zv bnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvJz5SZXZpc2lvbjombmJzcDsmbmJzcDsm bmJzcDsgMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0 ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZTox NC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvJz5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBEYXRhcGxhbmUgRWxlbWVudHMg aW4gTW9iaWxlIE5ldHdvcmtzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdm b250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyc+RG9jdW1lbnQgZGF0ZTombmJzcDsm bmJzcDsgMjAxNi0wNi0xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9u dC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28nPkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48c3Bh biBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNv Jz5QYWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25l Jz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6 TW9uYWNvJz5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFyYW5kYS1zZmMtZHAtbW9iaWxlLTAxLnR4dCI+PHNwYW4g c3R5bGU9J2NvbG9yOiMwMDAwRTknPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1hcmFuZGEtc2ZjLWRwLW1vYmlsZS0wMS50eHQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUn PjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpN b25hY28nPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXJh bmRhLXNmYy1kcC1tb2JpbGUvIj48c3BhbiBzdHlsZT0nY29sb3I6IzAwMDBFOSc+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXJhbmRhLXNmYy1kcC1tb2JpbGUvPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0 LWF1dG9zcGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4w cHQ7Zm9udC1mYW1pbHk6TW9uYWNvJz5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFy YW5kYS1zZmMtZHAtbW9iaWxlLTAxIj48c3BhbiBzdHlsZT0nY29sb3I6IzAwMDBFOSc+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFyYW5kYS1zZmMtZHAtbW9iaWxlLTAxPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0 LWF1dG9zcGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4w cHQ7Zm9udC1mYW1pbHk6TW9uYWNvJz5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYXJhbmRhLXNmYy1kcC1tb2JpbGUtMDEiPjxzcGFuIHN0 eWxlPSdjb2xvcjojMDAwMEU5Jz5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtYXJhbmRhLXNmYy1kcC1tb2JpbGUtMDE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxh bmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28nPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQt YXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjE0LjBw dDtmb250LWZhbWlseTpNb25hY28nPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9RVMt VFJBRCBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28nPiZuYnNwOyZu YnNwOyBUaGUgZXZvbHV0aW9uIG9mIHRoZSBuZXR3b3JrIHRvd2FyZHMgNUcgaW1wbGllcyBhIGNo YWxsZW5nZSBmb3IgdGhlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250 LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyc+Jm5ic3A7Jm5ic3A7IGluZnJhc3RydWN0 dXJlLiZuYnNwOyZuYnNwO1RoZSB0YXJnZXRlZCBzZXJ2aWNlcyBhbmQgdGhlIGZ1bGwgZGVwbG95 bWVudCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3Rl eHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjE0 LjBwdDtmb250LWZhbWlseTpNb25hY28nPiZuYnNwOyZuYnNwOyB2aXJ0dWFsaXphdGlvbiBpbiBh bGwgc2VnbWVudHMgb2YgdGhlIG5ldHdvcmsgd2lsbCBuZWVkIHNlcnZpY2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48 c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9u YWNvJz4mbmJzcDsmbmJzcDsgZnVuY3Rpb24gY2hhaW5zIHRoYXQgcHJldmlvdXNseSByZXNpZGVk IGluIHRoZShsb2NhbCBhbmQgcmVtb3RlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9RVMtVFJBRCBz dHlsZT0nZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28nPiZuYnNwOyZuYnNwOyBp bmZyYXN0cnVjdHVyZSBvZiB0aGUgTmV0d29yayBvcGVyYXRvcnMgdG8gZXh0ZW5kIHRvIHRoZSBy YWRpbyBhY2Nlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSd0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6 ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvJz4mbmJzcDsmbmJzcDsgbmV0d29yayAoUkFOKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9z cGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9u dC1mYW1pbHk6TW9uYWNvJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5 bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvJz4mbmJzcDsmbmJzcDsgSW4g dGhpcyBkcmFmdCB3ZSBwcm92aWRlIGEgbm9uLWV4aGF1c3RpdmUgYnV0IHJlcHJlc2VudGF0aXZl IGxpc3Qgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0 ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZTox NC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvJz4mbmJzcDsmbmJzcDsgc2VydmljZSBmdW5jdGlvbnMg aW4gNEcgYW5kIDVHIG5ldHdvcmtzLCBhbmQgZXhwbG9yZSBkaWZmZXJlbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48 c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9u YWNvJz4mbmJzcDsmbmJzcDsgc2NlbmFyaW9zIGZvciBzZXJ2aWNlLWF3YXJlIG9yY2hlc3RyYXRp b24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1h dXRvc3BhY2U6bm9uZSc+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNpemU6MTQuMHB0 O2ZvbnQtZmFtaWx5Ok1vbmFjbyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gbGFuZz1FUy1UUkFE IHN0eWxlPSdmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyc+Jm5ic3A7Jm5ic3A7 IFdlIGJhc2Ugb24gdGhlIHByb2JsZW0gc3RhdGVtZW50IFtSRkM3NDk4XSBhbmQgYXJjaGl0ZWN0 dXJlIGZyYW1ld29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1z aXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28nPiZuYnNwOyZuYnNwOyBbUkZDNzY2NV0mbmJz cDsmbmJzcDtvZiB0aGUgU0ZDIHdvcmtpbmcgZ3JvdXAsIGFzIHdlbGwgb24gdGhlIGV4aXN0aW5n IG1vYmlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3Rl eHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjE0 LjBwdDtmb250LWZhbWlseTpNb25hY28nPiZuYnNwOyZuYnNwOyBuZXR3b3JrcyB1c2UgY2FzZXMg W0ktRC5pZXRmLXNmYy11c2UtY2FzZS1tb2JpbGl0eV0mbmJzcDsmbmJzcDthbmQgdGhlPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6 bm9uZSc+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFt aWx5Ok1vbmFjbyc+Jm5ic3A7Jm5ic3A7IHJlcXVpcmVtZW50IGdhdGhlcmluZyBwcm9jZXNzIG9m IHRoZSBJVFUtUiBJTVQgMjAyMCBbMV0gYW5kIGRpZmZlcmVudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxh bmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28nPiZu YnNwOyZuYnNwOyBpbml0aWF0aXZlcyBpbiBFdXJvcGUgWzJdLCBLb3JlYSBbM10gYW5kIENoaW5h IFs0XSB0byBhbnRpY2lwYXRlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdm b250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyc+Jm5ic3A7Jm5ic3A7IG5ldHdvcmsg ZWxlbWVudHMgdGhhdCB3aWxsIGJlIG5lZWRlZCBpbiA1RyBuZXR3b3Jrcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25lJz48 c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9u YWNvJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSd0ZXh0LWF1dG9zcGFjZTpub25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6 ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvJz4mbmJzcDsmbmJzcDsgV2UgdGhlbiBleHBsb3Jl IHNlcnZpY2UtYXdhcmUgb3JjaGVzdHJhdGlvbiBzY2VuYXJpb3MgaWRlbnRpZnlpbmc8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpu b25lJz48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1p bHk6TW9uYWNvJz4mbmJzcDsmbmJzcDsgd2hlcmUgZGlmZmVyZW50IG5ldHdvcmsgZnVuY3Rpb25z IGNvbiBiZSBkZXBsb3llZCBpbiBhIGZ1bGx5PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gbGFuZz1FUy1UUkFE IHN0eWxlPSdmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyc+Jm5ic3A7Jm5ic3A7 IHZpcnR1YWxpc2VkIGZ1dHVyZSBuZXR3b3JrLCB3aGVyZSBib3RoIHRoZSBjb3JlIGFuZCB0aGUg ZWRnZSBwcm92aWRlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNp emU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyc+Jm5ic3A7Jm5ic3A7IGFkdmFuY2VkIHZpcnR1 YWxpc2F0aW9uIGNhcGFiaWxpdGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBz dHlsZT0nZm9udC1zaXplOjExLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOkVTLVRSQUQnPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RVMt VFJBRCc+RHIuIFBlZHJvIEEuIEFyYW5kYSBHdXRpw6lycmV6PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0n Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpFUy1UUkFEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOkVTLVRSQUQnPlRlY2hub2xvZ3kgRXhwbG9yYXRpb24gLTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVTLVRSQUQgc3R5 bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RVMtVFJBRCc+TmV0d29yayBJbm5vdmF0aW9uICZhbXA7IFZpcnR1 YWxpc2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFUy1UUkFEJz5lbWFp bDogcGVkcm9hIGQwdCBhcmFuZGEgQXQgdGVsZWZvbmljYSBkMHQgY29tPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RVMtVFJBRCBz dHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjaztt c28tZmFyZWFzdC1sYW5ndWFnZTpFUy1UUkFEJz5UZWxlZsOzbmljYSwgSW52ZXN0aWdhY2nDs24g eSBEZXNhcnJvbGxvPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFUy1UUkFEJz5D LyBadXJiYXLDoW4sMTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVTLVRSQUQn PjI4MDEwIE1hZHJpZCwgU3BhaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVT LVRSQUQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RVMtVFJBRCc+ RnJhZ2VuIHNpbmQgbmljaHQgZGEsIHVtIGJlYW50d29ydGV0IHp1IHdlcmRlbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FUy1U UkFEIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs YWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVTLVRSQUQnPkZyYWdlbiBzaW5kIGRhLCB1bSBnZXN0 ZWxsdCB6dSB3ZXJkZW4uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFUy1UUkFE Jz5HZW9yZyBLcmVpc2xlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXIn PjxzcGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIic+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPjwvc3Bhbj48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Z3JheSc+PGJyPkVz dGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3Ug ZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8g Y29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRp ZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8s IHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxn YWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEg ZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3Rl IG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVk aWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7Nu Ljxicj48YnI+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBp cyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRo ZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5 b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRp b24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5v dCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxl dGUgaXQuPGJyPjxicj5Fc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNs dXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6Nv IHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEg cGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEg byBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVy YSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fD o28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRl LiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3Mg byBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEg c3VhIGRlc3RydWnDp8Ojbzwvc3Bhbj48c3BhbiBsYW5nPUVTLVRSQUQgc3R5bGU9J2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2JvZHk+PC9odG1sPg== --_000_05C81A773E48DD49B181B04BA21A342A41F45BA3EBHE113484emea1_-- From nobody Wed Jul 6 06:17: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 A0DE212B047 for ; Wed, 6 Jul 2016 06:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 hcjYEPOXimg9 for ; Wed, 6 Jul 2016 06:17:44 -0700 (PDT) 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 26F7C12B036 for ; Wed, 6 Jul 2016 06:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6238; q=dns/txt; s=iport; t=1467811064; x=1469020664; h=from:to:subject:date:message-id:mime-version; bh=E5iZ3ws6GXI3i+b2Pa3o+lA/pB66aGbLiO+nuyeVcVc=; b=gi5BLMhAnMr5z86SeqRv+ScRL3cNwRwcPk3ivtcvUI6ux+gsqn0FRW2d bwk71op45THi7WkSODVdGcrSaGfV5NUSqWBOeIe5DBxrkzv//73vVsBNS s53I8Pbm2ePZiNmhqbzItY0dhpCSRFBmJWu3uYaLSoOXhpzv/85hWclxQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLBQBsBH1X/40NJK1dgnBOgVi0KoUBg?= =?us-ascii?q?XeGGB6BDTkTAQEBAQEBAWUcC4RTHQZoAUoCBDAnBIhDnFCPYo92AQEBAQEBBAE?= =?us-ascii?q?BAQEBAQEBAR6GJ4F4hmcRATOCaiuCLwWTWYU6AYEwjRaBaoRWiGqQCQEfATSDc?= =?us-ascii?q?IgrNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,319,1464652800"; d="scan'208,217";a="293602380" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2016 13:17:43 +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 u66DHhkx010325 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jul 2016 13:17:43 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; Wed, 6 Jul 2016 08:17:42 -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; Wed, 6 Jul 2016 08:17:42 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUQ== Date: Wed, 6 Jul 2016 13:17:41 +0000 Message-ID: <3404B156-BE82-48CE-B34F-153318837E78@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.183] Content-Type: multipart/alternative; boundary="_000_3404B156BE8248CEB34F153318837E78ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 13:17:45 -0000 --_000_3404B156BE8248CEB34F153318837E78ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRzoNCg0KVGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBv ZiBkcmFmdC1wZW5uby1zZmMtaGllcmFyY2hpY2FsLTA2IGFzIGEgV0cgZG9jdW1lbnQuIFRoZSBj YWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1biBmb3IgMiB3ZWVrcyBlbmRpbmcgNy8yNS8yMDE2Lg0K DQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYSBjYWxsIGZvciBhZG9wdGlvbiwgYW5kIG5vdCBh IGxhc3QgY2FsbCBmb3IgY29udGVudCBvZiB0aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9j dW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQgdGhlIFdHIHdpbGwgZm9jdXMgaXRzIGVmZm9ydHMgb24g dGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZvcndhcmQsIGFuZCB1c2UgdGhhdCBkb2N1bWVu dCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFuZCBkb2N1bWVudGluZyB0aGUgV0figJlzIGRl Y2lzaW9ucy4NCg0KUGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24g Zm9yIG5vdCwgYW5kIGlmIG5vdCB3aHkuIElzc3VlcyB5b3UgaGF2ZSB3aXRoIHRoZSBjdXJyZW50 IGRvY3VtZW50IGl0c2VsZiBjYW4gYWxzbyBiZSByYWlzZWQsIGJ1dCB0aGV5IHNob3VsZCBiZSBy YWlzZWQgaW4gdGhlIGNvbnRleHQgb2Ygd2hhdCBzaG91bGQgYmUgY2hhbmdlZCBpbiB0aGUgZG9j dW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVyIHRoYW4gYSBwcmUtY29uZGl0aW9uIGZvciBhZG9w dGlvbi4NCg0KRmluYWxseSwgbm93IGlzIGFsc28gYSBnb29kIHRpbWUgdG8gcG9sbCBmb3Iga25v d2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIGluIGxpbmUgd2l0 aCB0aGUgSVBSIGRpc2Nsb3N1cmUgb2JsaWdhdGlvbnMgZm9yIFdHIHBhcnRpY2lwYW50cyAoc2Vl IFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4gSWYgeW91 IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBl bWFpbCAodG8gdGhlIGNoYWlycykgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkg cmVsZXZhbnQgSVBSLg0KDQpUaGFua3MhDQoNClNGQyBDaGFpcnMNCg== --_000_3404B156BE8248CEB34F153318837E78ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IDEycHg7Ij5EZWFyIFdHOjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiAxMnB4OyI+ PGJyPg0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsiPlRoaXMgZW1haWwgc2VydmVzIGFzIGEgY2FsbCBm b3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWhpZXJhcmNoaWNhbC0wNiBhcyBhIFdH IGRvY3VtZW50LiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBydW4gZm9yIDINCiB3ZWVrcyBl bmRpbmcgNy8yNS8yMDE2Ljwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTJweDsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTJweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7Ij5QbGVhc2Ugbm90 ZSB0aGF0IHRoaXMgaXMgYSBjYWxsIGZvciBhZG9wdGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBm b3IgY29udGVudCBvZiB0aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5 IG1lYW5zIHRoYXQNCiB0aGUgV0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0IHBhcnRp Y3VsYXIgZHJhZnQgZ29pbmcgZm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRvY3VtZW50IGZvciByZXNv bHZpbmcgb3BlbiBpc3N1ZXMgYW5kIGRvY3VtZW50aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25zLjwv c3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsi PiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7Ij5QbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ug c3VwcG9ydCBhZG9wdGlvbiBmb3Igbm90LCBhbmQgaWYgbm90IHdoeS4gSXNzdWVzIHlvdSBoYXZl IHdpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNhbiBhbHNvIGJlIHJhaXNlZCwNCiBi dXQgdGhleSBzaG91bGQgYmUgcmFpc2VkIGluIHRoZSBjb250ZXh0IG9mIHdoYXQgc2hvdWxkIGJl IGNoYW5nZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQsIHJhdGhlciB0aGFuIGEgcHJl LWNvbmRpdGlvbiBmb3IgYWRvcHRpb24uJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IDEycHg7Ij5GaW5hbGx5LCBu b3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBwb2xsIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0 aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgaW4gbGluZSB3aXRoIHRoZSBJUFIgZGlzY2xvc3Vy ZSBvYmxpZ2F0aW9ucyBmb3IgV0cgcGFydGljaXBhbnRzDQogKHNlZSBSRkNzIDM5NzksIDQ4Nzks IDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEg ZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgKHRvIHRoZSBjaGFp cnMpIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogMTJw eDsiPjxicj4NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsg Zm9udC1zaXplOiAxMnB4OyI+VGhhbmtzITwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBDb25zb2xhczsgZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IDEycHg7Ij5TRkMgQ2hhaXJz PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2 IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3404B156BE8248CEB34F153318837E78ciscocom_-- From nobody Wed Jul 6 06:19: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 B678812B069 for ; Wed, 6 Jul 2016 06:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 8dD3v9J4LzBg for ; Wed, 6 Jul 2016 06:19:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0849012B047 for ; Wed, 6 Jul 2016 06:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8768; q=dns/txt; s=iport; t=1467811166; x=1469020766; h=from:to:subject:date:message-id:mime-version; bh=KUwazcvxCFqcYlPyaaSp4xwJW8gy6voeN9N6wKlF5AU=; b=C2vn7QxUK6FAxTzu0RIhIIgr6gDKBxcyJtYVXTXrokYRkeMpl3p2UL1f YsaHvbZme8XuJyGQ/tPHPqYSZJEOhzGKcSD7HfaJzgnL6PPTkmGexLB19 B7APW4jyHa2+DUkxclYEDFiv8BYlCUfZigkplpl6d8PJdnps2GT1LAzeL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgBsBH1X/5FdJa1dgnBOgVIGtCqFA?= =?us-ascii?q?YF3hhgCHIENOBQBAQEBAQEBZRwLhEwBAQUdBmgBCBEDAQIoAwIEMBQJCgQTiDC?= =?us-ascii?q?cUI9ij3YBAQEBAQEBAwEBAQEBAQEBAQEBHIYngXiCVYQSEQEzCRaCSyuCLwWTW?= =?us-ascii?q?YU6AY5GgWqEVoMuhTyQCQEeNoNwboc9Nn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,319,1464652800"; d="scan'208,217";a="122932083" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 13:19:25 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u66DJPZu028785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jul 2016 13:19:25 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; Wed, 6 Jul 2016 08:19:24 -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; Wed, 6 Jul 2016 08:19:23 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14kDWWZtljiaXEKuqE++y3FX4w== Date: Wed, 6 Jul 2016 13:19:23 +0000 Message-ID: <60B45C4E-916C-4CE7-B076-34110590BD61@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.183] Content-Type: multipart/alternative; boundary="_000_60B45C4E916C4CE7B07634110590BD61ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 13:19:28 -0000 --_000_60B45C4E916C4CE7B07634110590BD61ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ycmVjdGlvbi4NCg0KVGhlIHRleHQgc2hvdWxkIHJlYWQg4oCYZHJhZnQtZG9sc29uLXNmYy1o aWVyYXJjaGljYWwtMDbigJkgLi4NCg0KU0ZDIENoYWlycw0KDQpGcm9tOiBzZmMgPHNmYy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBK aW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29t Pj4NCkRhdGU6IFdlZG5lc2RheSwgSnVseSA2LCAyMDE2IGF0IDk6MTcgQU0NClRvOiAic2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtZG9s c29uLXNmYy1oaWVyYXJjaGljYWwtMDYNCg0KRGVhciBXRzoNCg0KVGhpcyBlbWFpbCBzZXJ2ZXMg YXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtaGllcmFyY2hpY2Fs LTA2IGFzIGEgV0cgZG9jdW1lbnQuIFRoZSBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1biBmb3Ig MiB3ZWVrcyBlbmRpbmcgNy8yNS8yMDE2Lg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYSBj YWxsIGZvciBhZG9wdGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29udGVudCBvZiB0aGUg ZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQgdGhlIFdH IHdpbGwgZm9jdXMgaXRzIGVmZm9ydHMgb24gdGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZv cndhcmQsIGFuZCB1c2UgdGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFu ZCBkb2N1bWVudGluZyB0aGUgV0figJlzIGRlY2lzaW9ucy4NCg0KUGxlYXNlIGluZGljYXRlIHdo ZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlmIG5vdCB3aHkuIElzc3Vl cyB5b3UgaGF2ZSB3aXRoIHRoZSBjdXJyZW50IGRvY3VtZW50IGl0c2VsZiBjYW4gYWxzbyBiZSBy YWlzZWQsIGJ1dCB0aGV5IHNob3VsZCBiZSByYWlzZWQgaW4gdGhlIGNvbnRleHQgb2Ygd2hhdCBz aG91bGQgYmUgY2hhbmdlZCBpbiB0aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVyIHRo YW4gYSBwcmUtY29uZGl0aW9uIGZvciBhZG9wdGlvbi4NCg0KRmluYWxseSwgbm93IGlzIGFsc28g YSBnb29kIHRpbWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVz IHRvIHRoaXMgZHJhZnQsIGluIGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1cmUgb2JsaWdhdGlv bnMgZm9yIFdHIHBhcnRpY2lwYW50cyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3 OCBmb3IgbW9yZSBkZXRhaWxzKS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRo b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCAodG8gdGhlIGNoYWlycykgd2hldGhlciBv ciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KDQpUaGFua3MhDQoNClNG QyBDaGFpcnMNCg== --_000_60B45C4E916C4CE7B07634110590BD61ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkNvcnJlY3Rpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgdGV4dCBz aG91bGQgcmVhZCDigJhkcmFmdC08Yj5kb2xzb248L2I+LXNmYy1oaWVyYXJjaGljYWwtMDbigJkg Li48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNGQyBDaGFpcnM8L2Rpdj4NCjxkaXY+ DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4 dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP UkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU OiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7 IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5zZmMgJmx0OzxhIGhyZWY9Im1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBi ZWhhbGYgb2YgSmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28u Y29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBKdWx5IDYsIDIwMTYgYXQgOToxNyBB TTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90Ozxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bc2ZjXSBDYWxsIGZv ciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ29u c29sYXM7IGZvbnQtc2l6ZTogMTJweDsiPkRlYXIgV0c6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IENvbnNvbGFzOyI+VGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBv ZiBkcmFmdC1wZW5uby1zZmMtaGllcmFyY2hpY2FsLTA2IGFzIGEgV0cgZG9jdW1lbnQuIFRoZSBj YWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1biBmb3IgMg0KIHdlZWtzIGVuZGluZyA3LzI1LzIwMTYu PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4 OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsiPlBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBh IGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEgbGFzdCBjYWxsIGZvciBjb250ZW50IG9mIHRo ZSBkb2N1bWVudC4gQWRvcHRpbmcgYSBXRyBkb2N1bWVudCBzaW1wbHkgbWVhbnMgdGhhdA0KIHRo ZSBXRyB3aWxsIGZvY3VzIGl0cyBlZmZvcnRzIG9uIHRoYXQgcGFydGljdWxhciBkcmFmdCBnb2lu ZyBmb3J3YXJkLCBhbmQgdXNlIHRoYXQgZG9jdW1lbnQgZm9yIHJlc29sdmluZyBvcGVuIGlzc3Vl cyBhbmQgZG9jdW1lbnRpbmcgdGhlIFdH4oCZcyBkZWNpc2lvbnMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+Jm5ic3A7PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb25zb2xhczsiPlBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9u IGZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJc3N1ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3VycmVu dCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28gYmUgcmFpc2VkLA0KIGJ1dCB0aGV5IHNob3VsZCBi ZSByYWlzZWQgaW4gdGhlIGNvbnRleHQgb2Ygd2hhdCBzaG91bGQgYmUgY2hhbmdlZCBpbiB0aGUg ZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVyIHRoYW4gYSBwcmUtY29uZGl0aW9uIGZvciBh ZG9wdGlvbi4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEycHg7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQ29uc29sYXM7IGZvbnQtc2l6ZTogMTJweDsiPkZpbmFsbHksIG5vdyBpcyBhbHNvIGEgZ29v ZCB0aW1lIHRvIHBvbGwgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0 aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQUiBkaXNjbG9zdXJlIG9ibGlnYXRpb25zIGZv ciBXRyBwYXJ0aWNpcGFudHMNCiAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBm b3IgbW9yZSBkZXRhaWxzKS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Ig cGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCAodG8gdGhlIGNoYWlycykgd2hldGhlciBvciBu b3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IDEycHg7 Ij5UaGFua3MhPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBm b250LXNpemU6IDEycHg7Ij48YnI+DQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQ29uc29sYXM7IGZvbnQtc2l6ZTogMTJweDsiPlNGQyBDaGFpcnM8L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvc3Bhbj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_60B45C4E916C4CE7B07634110590BD61ciscocom_-- From nobody Wed Jul 6 06:20: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 73ABE12D0DF for ; Wed, 6 Jul 2016 06:20:52 -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 oGk94P4uUW3K for ; Wed, 6 Jul 2016 06:20:50 -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 CD86E12B047 for ; Wed, 6 Jul 2016 06:20:49 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 11FCA22C882; Wed, 6 Jul 2016 15:20:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DF4ED27C0B0; Wed, 6 Jul 2016 15:20:47 +0200 (CEST) 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.0294.000; Wed, 6 Jul 2016 15:20:47 +0200 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14kDWWZtljiaXEKuqE++y3FX46ALY0Ag Date: Wed, 6 Jul 2016 13:20:46 +0000 Message-ID: <28584_1467811248_577D05AF_28584_2788_1_88132E969123D14D9BD844E1CD516EDE130992F6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <60B45C4E-916C-4CE7-B076-34110590BD61@cisco.com> In-Reply-To: <60B45C4E-916C-4CE7-B076-34110590BD61@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_88132E969123D14D9BD844E1CD516EDE130992F6OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.6.125415 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 13:20:52 -0000 --_000_88132E969123D14D9BD844E1CD516EDE130992F6OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJj aGljYWwgYXMgYSBzZmMgV0cgZG9jdW1lbnQuDQoNCkNoZWVycywNCg0KQ2hyaXN0aWFuLg0KDQoN CkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmlt IEd1aWNoYXJkIChqZ3VpY2hhcikNCkVudm95w6kgOiBtZXJjcmVkaSA2IGp1aWxsZXQgMjAxNiAx NToxOQ0Kw4AgOiBzZmNAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtzZmNdIENhbGwgZm9yIFdHIGFk b3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2DQoNCkNvcnJlY3Rpb24u DQoNClRoZSB0ZXh0IHNob3VsZCByZWFkIOKAmGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2Fs LTA24oCZIC4uDQoNClNGQyBDaGFpcnMNCg0KRnJvbTogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJk IDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQpEYXRlOiBX ZWRuZXNkYXksIEp1bHkgNiwgMjAxNiBhdCA5OjE3IEFNDQpUbzogInNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClN1 YmplY3Q6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGll cmFyY2hpY2FsLTA2DQoNCkRlYXIgV0c6DQoNClRoaXMgZW1haWwgc2VydmVzIGFzIGEgY2FsbCBm b3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWhpZXJhcmNoaWNhbC0wNiBhcyBhIFdH IGRvY3VtZW50LiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBydW4gZm9yIDIgd2Vla3MgZW5k aW5nIDcvMjUvMjAxNi4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgY2FsbCBmb3IgYWRv cHRpb24sIGFuZCBub3QgYSBsYXN0IGNhbGwgZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBB ZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyB0aGF0IHRoZSBXRyB3aWxsIGZvY3Vz IGl0cyBlZmZvcnRzIG9uIHRoYXQgcGFydGljdWxhciBkcmFmdCBnb2luZyBmb3J3YXJkLCBhbmQg dXNlIHRoYXQgZG9jdW1lbnQgZm9yIHJlc29sdmluZyBvcGVuIGlzc3VlcyBhbmQgZG9jdW1lbnRp bmcgdGhlIFdH4oCZcyBkZWNpc2lvbnMuDQoNClBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBz dXBwb3J0IGFkb3B0aW9uIGZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJc3N1ZXMgeW91IGhhdmUg d2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28gYmUgcmFpc2VkLCBidXQg dGhleSBzaG91bGQgYmUgcmFpc2VkIGluIHRoZSBjb250ZXh0IG9mIHdoYXQgc2hvdWxkIGJlIGNo YW5nZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQsIHJhdGhlciB0aGFuIGEgcHJlLWNv bmRpdGlvbiBmb3IgYWRvcHRpb24uDQoNCkZpbmFsbHksIG5vdyBpcyBhbHNvIGEgZ29vZCB0aW1l IHRvIHBvbGwgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRy YWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQUiBkaXNjbG9zdXJlIG9ibGlnYXRpb25zIGZvciBXRyBw YXJ0aWNpcGFudHMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUg ZGV0YWlscykuIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSBy ZXNwb25kIHRvIHRoaXMgZW1haWwgKHRvIHRoZSBjaGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBh cmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NCg0KVGhhbmtzIQ0KDQpTRkMgQ2hhaXJzDQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_88132E969123D14D9BD844E1CD516EDE130992F6OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0 eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojNzAzMEEw Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojNzAzMEEwIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGll cmFyY2hpY2FsIGFzIGEgc2ZjIFdHIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMw QTAiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5DaHJpc3RpYW4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Izcw MzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEppbSBHdWljaGFyZCAoamd1aWNo YXIpPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDYganVpbGxldCAyMDE2IDE1 OjE5PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNw Ozo8L2I+IFJlOiBbc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1kb2xzb24tc2Zj LWhpZXJhcmNoaWNhbC0wNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Q29ycmVjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+VGhlIHRleHQgc2hvdWxkIHJlYWQg4oCYZHJhZnQtPGI+ZG9sc29uPC9iPi1zZmMtaGllcmFy Y2hpY2FsLTA24oCZIC4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlNGQyBD aGFpcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnNmYyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpq Z3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPldlZG5lc2RheSwgSnVseSA2LCAyMDE2IGF0IDk6MTcgQU08YnI+DQo8Yj5UbzogPC9i PiZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPltzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0 LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ RGVhciBXRzo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRo aXMgZW1haWwgc2VydmVzIGFzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8t c2ZjLWhpZXJhcmNoaWNhbC0wNiBhcyBhIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBmb3IgYWRvcHRp b24gd2lsbCBydW4gZm9yIDIgd2Vla3MgZW5kaW5nIDcvMjUvMjAxNi48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5QbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYSBjYWxsIGZv ciBhZG9wdGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29udGVudCBvZiB0aGUgZG9jdW1l bnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQgdGhlIFdHIHdpbGwg Zm9jdXMgaXRzIGVmZm9ydHMgb24gdGhhdA0KIHBhcnRpY3VsYXIgZHJhZnQgZ29pbmcgZm9yd2Fy ZCwgYW5kIHVzZSB0aGF0IGRvY3VtZW50IGZvciByZXNvbHZpbmcgb3BlbiBpc3N1ZXMgYW5kIGRv Y3VtZW50aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25zLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6YmxhY2siPlBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9u IGZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJc3N1ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3VycmVu dCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28gYmUgcmFpc2VkLCBidXQgdGhleSBzaG91bGQgYmUg cmFpc2VkIGluIHRoZSBjb250ZXh0DQogb2Ygd2hhdCBzaG91bGQgYmUgY2hhbmdlZCBpbiB0aGUg ZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVyIHRoYW4gYSBwcmUtY29uZGl0aW9uIGZvciBh ZG9wdGlvbi4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5GaW5h bGx5LCBub3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBwb2xsIGZvciBrbm93bGVkZ2Ugb2YgYW55 IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgaW4gbGluZSB3aXRoIHRoZSBJUFIgZGlz Y2xvc3VyZSBvYmxpZ2F0aW9ucyBmb3IgV0cgcGFydGljaXBhbnRzIChzZWUgUkZDcyAzOTc5LA0K IDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuIElmIHlvdSBhcmUgbGlzdGVk IGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgKHRvIHRo ZSBjaGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQ Ui48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoYW5rcyE8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlNGQyBDaGFpcnM8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_88132E969123D14D9BD844E1CD516EDE130992F6OPEXCLILMA3corp_-- From nobody Wed Jul 6 06:37: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 5BA6912D796 for ; Wed, 6 Jul 2016 06:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsfdE-Bd8GrF for ; Wed, 6 Jul 2016 06:37:06 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id C36AE12D798 for ; Wed, 6 Jul 2016 06:37:02 -0700 (PDT) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id u66Db2V3002601 for ; Wed, 6 Jul 2016 22:37:02 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 367045F69F for ; Wed, 6 Jul 2016 22:37:02 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 297725F680 for ; Wed, 6 Jul 2016 22:37:02 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.28]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTP id 20D8040030A for ; Wed, 6 Jul 2016 22:37:02 +0900 (JST) References: <60B45C4E-916C-4CE7-B076-34110590BD61@cisco.com> From: Shunsuke Homma Message-ID: <3b000af1-7282-7c61-fb6a-ef6f3a9b9e4f@lab.ntt.co.jp> Date: Wed, 6 Jul 2016 22:37:34 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <60B45C4E-916C-4CE7-B076-34110590BD61@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit To: sfc@ietf.org X-TM-AS-MML: disable Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 13:37:11 -0000 Hi, As a coauthor, I support the adoption of draft-dolson-sfc-hierarchical. Shunsuke On 2016/07/06 22:19, Jim Guichard (jguichar) wrote: > Correction. > > The text should read ‘draft-*dolson*-sfc-hierarchical-06’ .. > > SFC Chairs > > From: sfc > on behalf > of Jim Guichard > > Date: Wednesday, July 6, 2016 at 9:17 AM > To: "sfc@ietf.org " > > Subject: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 > > Dear WG: > > > This email serves as a call for WG adoption of > draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption > will run for 2 weeks ending 7/25/2016. > > > > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a WG document simply means that the WG > will focus its efforts on that particular draft going forward, and use > that document for resolving open issues and documenting the WG’s decisions. > > > > Please indicate whether you support adoption for not, and if not why. > Issues you have with the current document itself can also be raised, but > they should be raised in the context of what should be changed in the > document going forward, rather than a pre-condition for adoption. > > > > Finally, now is also a good time to poll for knowledge of any IPR that > applies to this draft, in line with the IPR disclosure obligations for > WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as a document author please respond to this email (to > the chairs) whether or not you are aware of any relevant IPR. > > > Thanks! > > > SFC Chairs > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service Systems Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Wed Jul 6 06:44: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 C103412B069 for ; Wed, 6 Jul 2016 06:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 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.426] 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 Er1pR4fmZKNM for ; Wed, 6 Jul 2016 06:44:50 -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 CF87312B024 for ; Wed, 6 Jul 2016 06:44:46 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 09:44:45 -0400 From: Dave Dolson To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14kDWWZtljiaXEKuqE++y3FX46ALaaQA Date: Wed, 6 Jul 2016 13:44:44 +0000 Message-ID: References: <60B45C4E-916C-4CE7-B076-34110590BD61@cisco.com> In-Reply-To: <60B45C4E-916C-4CE7-B076-34110590BD61@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_E8355113905631478EFF04F5AA706E9830FE6681wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 13:44:53 -0000 --_000_E8355113905631478EFF04F5AA706E9830FE6681wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYSBjby1hdXRob3IsIEkgc3VwcG9ydCBpdC4NCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpT ZW50OiBXZWRuZXNkYXksIEp1bHkgMDYsIDIwMTYgOToxOSBBTQ0KVG86IHNmY0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1z ZmMtaGllcmFyY2hpY2FsLTA2DQoNCkNvcnJlY3Rpb24uDQoNClRoZSB0ZXh0IHNob3VsZCByZWFk IOKAmGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA24oCZIC4uDQoNClNGQyBDaGFpcnMN Cg0KRnJvbTogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFp bHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgNiwgMjAxNiBh dCA5OjE3IEFNDQpUbzogInNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClN1YmplY3Q6IFtzZmNdIENhbGwgZm9yIFdH IGFkb3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2DQoNCkRlYXIgV0c6 DQoNClRoaXMgZW1haWwgc2VydmVzIGFzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQt cGVubm8tc2ZjLWhpZXJhcmNoaWNhbC0wNiBhcyBhIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBmb3Ig YWRvcHRpb24gd2lsbCBydW4gZm9yIDIgd2Vla3MgZW5kaW5nIDcvMjUvMjAxNi4NCg0KUGxlYXNl IG5vdGUgdGhhdCB0aGlzIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24sIGFuZCBub3QgYSBsYXN0IGNh bGwgZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBBZG9wdGluZyBhIFdHIGRvY3VtZW50IHNp bXBseSBtZWFucyB0aGF0IHRoZSBXRyB3aWxsIGZvY3VzIGl0cyBlZmZvcnRzIG9uIHRoYXQgcGFy dGljdWxhciBkcmFmdCBnb2luZyBmb3J3YXJkLCBhbmQgdXNlIHRoYXQgZG9jdW1lbnQgZm9yIHJl c29sdmluZyBvcGVuIGlzc3VlcyBhbmQgZG9jdW1lbnRpbmcgdGhlIFdH4oCZcyBkZWNpc2lvbnMu DQoNClBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9uIGZvciBub3Qs IGFuZCBpZiBub3Qgd2h5LiBJc3N1ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVu dCBpdHNlbGYgY2FuIGFsc28gYmUgcmFpc2VkLCBidXQgdGhleSBzaG91bGQgYmUgcmFpc2VkIGlu IHRoZSBjb250ZXh0IG9mIHdoYXQgc2hvdWxkIGJlIGNoYW5nZWQgaW4gdGhlIGRvY3VtZW50IGdv aW5nIGZvcndhcmQsIHJhdGhlciB0aGFuIGEgcHJlLWNvbmRpdGlvbiBmb3IgYWRvcHRpb24uDQoN CkZpbmFsbHksIG5vdyBpcyBhbHNvIGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yIGtub3dsZWRnZSBv ZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQ UiBkaXNjbG9zdXJlIG9ibGlnYXRpb25zIGZvciBXRyBwYXJ0aWNpcGFudHMgKHNlZSBSRkNzIDM5 NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuIElmIHlvdSBhcmUgbGlz dGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgKHRv IHRoZSBjaGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50 IElQUi4NCg0KVGhhbmtzIQ0KDQpTRkMgQ2hhaXJzDQo= --_000_E8355113905631478EFF04F5AA706E9830FE6681wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BcyBhIGNvLWF1dGhvciwgSSBzdXBwb3J0IGl0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmltIEd1aWNo YXJkIChqZ3VpY2hhcik8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDA2LCAyMDE2 IDk6MTkgQU08YnI+DQo8Yj5Ubzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNmYy1oaWVy YXJjaGljYWwtMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkNvcnJlY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRo ZSB0ZXh0IHNob3VsZCByZWFkIOKAmGRyYWZ0LTxiPmRvbHNvbjwvYj4tc2ZjLWhpZXJhcmNoaWNh bC0wNuKAmSAuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TRkMgQ2hhaXJz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5zZmMgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgSmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNo YXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5XZWRuZXNkYXksIEp1bHkgNiwgMjAxNiBhdCA5OjE3IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVv dDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5bc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1kb2xz b24tc2ZjLWhpZXJhcmNoaWNhbC0wNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkRlYXIg V0c6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UaGlzIGVt YWlsIHNlcnZlcyBhcyBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy1o aWVyYXJjaGljYWwtMDYgYXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdp bGwgcnVuIGZvciAyIHdlZWtzIGVuZGluZyA3LzI1LzIwMTYuPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjpibGFjayI+UGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgY2FsbCBmb3IgYWRv cHRpb24sIGFuZCBub3QgYSBsYXN0IGNhbGwgZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBB ZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyB0aGF0IHRoZSBXRyB3aWxsIGZvY3Vz IGl0cyBlZmZvcnRzIG9uIHRoYXQNCiBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZvcndhcmQsIGFu ZCB1c2UgdGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFuZCBkb2N1bWVu dGluZyB0aGUgV0figJlzIGRlY2lzaW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OmJsYWNrIj5QbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBmb3Ig bm90LCBhbmQgaWYgbm90IHdoeS4gSXNzdWVzIHlvdSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgZG9j dW1lbnQgaXRzZWxmIGNhbiBhbHNvIGJlIHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNl ZCBpbiB0aGUgY29udGV4dA0KIG9mIHdoYXQgc2hvdWxkIGJlIGNoYW5nZWQgaW4gdGhlIGRvY3Vt ZW50IGdvaW5nIGZvcndhcmQsIHJhdGhlciB0aGFuIGEgcHJlLWNvbmRpdGlvbiBmb3IgYWRvcHRp b24uJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+RmluYWxseSwg bm93IGlzIGFsc28gYSBnb29kIHRpbWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIg dGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIGluIGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1 cmUgb2JsaWdhdGlvbnMgZm9yIFdHIHBhcnRpY2lwYW50cyAoc2VlIFJGQ3MgMzk3OSwNCiA0ODc5 LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBh IGRvY3VtZW50IGF1dGhvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsICh0byB0aGUgY2hh aXJzKSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UaGFua3MhPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5TRkMgQ2hhaXJzPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_E8355113905631478EFF04F5AA706E9830FE6681wtlexchp2sandvi_-- From nobody Wed Jul 6 06:52: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 9F17112D51B for ; Wed, 6 Jul 2016 06:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8KBLnZIDltw for ; Wed, 6 Jul 2016 06:52:55 -0700 (PDT) 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 021D012D0B4 for ; Wed, 6 Jul 2016 06:52:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E86BF1C038E; Wed, 6 Jul 2016 06:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1467813174; bh=tFTyY0yuBPcP4MCyRTHGx5+Qp4/i5qu+7cdLZFdN8QA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=P/7aMZqdoxOU9rAkDiNBOrafxXdMpYlEbZWpAwZlPxapli/LLRlKycBVGkfU7X0iu 3IEBwq8/m+XDoqg4A3TKEOH8wASFemgizjUghZyQVMkIcIJDV0o47QFigNfhPD1iIJ xnc93+HsSiELFww0+WJ5CCQlPY2n7vX0dMtgZ69c= 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 82CB91C01C9; Wed, 6 Jul 2016 06:52:54 -0700 (PDT) To: "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> From: "Joel M. Halpern" Message-ID: <990af5e6-d764-e23d-b4a0-1bd02dd71097@joelhalpern.com> Date: Wed, 6 Jul 2016 09:52:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 13:52:56 -0000 I support the working group adopting this draft. It serves as a good basis for discussing and resolving issues in larger scale situations. Yours, Joel On 7/6/16 9:17 AM, Jim Guichard (jguichar) wrote: > Dear WG: > > > This email serves as a call for WG adoption of > draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption > will run for 2 weeks ending 7/25/2016. > > > > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a WG document simply means that the WG > will focus its efforts on that particular draft going forward, and use > that document for resolving open issues and documenting the WG’s decisions. > > > > Please indicate whether you support adoption for not, and if not why. > Issues you have with the current document itself can also be raised, but > they should be raised in the context of what should be changed in the > document going forward, rather than a pre-condition for adoption. > > > > Finally, now is also a good time to poll for knowledge of any IPR that > applies to this draft, in line with the IPR disclosure obligations for > WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as a document author please respond to this email (to > the chairs) whether or not you are aware of any relevant IPR. > > > Thanks! > > > SFC Chairs > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 6 09:09: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 4326812B04C for ; Wed, 6 Jul 2016 09:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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.426, 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 v8vv8Lz38DB7 for ; Wed, 6 Jul 2016 09:09:13 -0700 (PDT) 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 DD8E312D124 for ; Wed, 6 Jul 2016 09:09:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSD43312; Wed, 06 Jul 2016 16:09:09 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Jul 2016 17:09:08 +0100 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, 6 Jul 2016 09:09:03 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUaALkhkQ Date: Wed, 6 Jul 2016 16:09:03 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657EDC8AE@dfweml501-mbb> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.150] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657EDC8AEdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.577D2D26.005A, 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: 6e53fc4181284bf53caeeb36d306d85e Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 16:09:16 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657EDC8AEdfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCAgZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDYgdG8gYmVjb21lIFdHIGRy YWZ0LiBHb29kIGRyYWZ0Lg0KDQpMaW5kYQ0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpTZW50OiBX ZWRuZXNkYXksIEp1bHkgMDYsIDIwMTYgODoxOCBBTQ0KVG86IHNmY0BpZXRmLm9yZw0KU3ViamVj dDogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJj aGljYWwtMDYNCg0KRGVhciBXRzoNCg0KVGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBX RyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtaGllcmFyY2hpY2FsLTA2IGFzIGEgV0cgZG9j dW1lbnQuIFRoZSBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1biBmb3IgMiB3ZWVrcyBlbmRpbmcg Ny8yNS8yMDE2Lg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYSBjYWxsIGZvciBhZG9wdGlv biwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29udGVudCBvZiB0aGUgZG9jdW1lbnQuIEFkb3B0 aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQgdGhlIFdHIHdpbGwgZm9jdXMgaXRz IGVmZm9ydHMgb24gdGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZvcndhcmQsIGFuZCB1c2Ug dGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFuZCBkb2N1bWVudGluZyB0 aGUgV0figJlzIGRlY2lzaW9ucy4NCg0KUGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IHN1cHBv cnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlmIG5vdCB3aHkuIElzc3VlcyB5b3UgaGF2ZSB3aXRo IHRoZSBjdXJyZW50IGRvY3VtZW50IGl0c2VsZiBjYW4gYWxzbyBiZSByYWlzZWQsIGJ1dCB0aGV5 IHNob3VsZCBiZSByYWlzZWQgaW4gdGhlIGNvbnRleHQgb2Ygd2hhdCBzaG91bGQgYmUgY2hhbmdl ZCBpbiB0aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVyIHRoYW4gYSBwcmUtY29uZGl0 aW9uIGZvciBhZG9wdGlvbi4NCg0KRmluYWxseSwgbm93IGlzIGFsc28gYSBnb29kIHRpbWUgdG8g cG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQs IGluIGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1cmUgb2JsaWdhdGlvbnMgZm9yIFdHIHBhcnRp Y2lwYW50cyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRh aWxzKS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3IgcGxlYXNlIHJlc3Bv bmQgdG8gdGhpcyBlbWFpbCAodG8gdGhlIGNoYWlycykgd2hldGhlciBvciBub3QgeW91IGFyZSBh d2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KDQpUaGFua3MhDQoNClNGQyBDaGFpcnMNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657EDC8AEdfweml501mbb_ 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 e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdXBwb3J0ICZuYnNwO2RyYWZ0LWRvbHNvbi1zZmMt aGllcmFyY2hpY2FsLTA2IHRvIGJlY29tZSBXRyBkcmFmdC4gR29vZCBkcmFmdC4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+TGluZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmltIEd1aWNoYXJkIChqZ3VpY2hhcik8YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDA2LCAyMDE2IDg6MTggQU08YnI+DQo8Yj5Ubzo8 L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2ZjXSBDYWxsIGZvciBXRyBh ZG9wdGlvbiBvZiBkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPkRlYXIgV0c6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNr Ij5UaGlzIGVtYWlsIHNlcnZlcyBhcyBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXBl bm5vLXNmYy1oaWVyYXJjaGljYWwtMDYgYXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFk b3B0aW9uIHdpbGwgcnVuIGZvciAyIHdlZWtzIGVuZGluZyA3LzI1LzIwMTYuPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+UGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgY2Fs bCBmb3IgYWRvcHRpb24sIGFuZCBub3QgYSBsYXN0IGNhbGwgZm9yIGNvbnRlbnQgb2YgdGhlIGRv Y3VtZW50LiBBZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyB0aGF0IHRoZSBXRyB3 aWxsIGZvY3VzIGl0cyBlZmZvcnRzIG9uIHRoYXQNCiBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZv cndhcmQsIGFuZCB1c2UgdGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFu ZCBkb2N1bWVudGluZyB0aGUgV0figJlzIGRlY2lzaW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrIj5QbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9w dGlvbiBmb3Igbm90LCBhbmQgaWYgbm90IHdoeS4gSXNzdWVzIHlvdSBoYXZlIHdpdGggdGhlIGN1 cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNhbiBhbHNvIGJlIHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxk IGJlIHJhaXNlZCBpbiB0aGUgY29udGV4dA0KIG9mIHdoYXQgc2hvdWxkIGJlIGNoYW5nZWQgaW4g dGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQsIHJhdGhlciB0aGFuIGEgcHJlLWNvbmRpdGlvbiBm b3IgYWRvcHRpb24uJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ RmluYWxseSwgbm93IGlzIGFsc28gYSBnb29kIHRpbWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9m IGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIGluIGxpbmUgd2l0aCB0aGUgSVBS IGRpc2Nsb3N1cmUgb2JsaWdhdGlvbnMgZm9yIFdHIHBhcnRpY2lwYW50cyAoc2VlIFJGQ3MgMzk3 OSwNCiA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLiBJZiB5b3UgYXJlIGxp c3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsICh0 byB0aGUgY2hhaXJzKSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFu dCBJUFIuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UaGFu a3MhPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5TRkMgQ2hh aXJzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657EDC8AEdfweml501mbb_-- From nobody Wed Jul 6 09:44: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 BACA412D13D for ; Wed, 6 Jul 2016 09:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 qohP3PVSgQjD for ; Wed, 6 Jul 2016 09:43:58 -0700 (PDT) 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 7247812B039 for ; Wed, 6 Jul 2016 09:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1907; q=dns/txt; s=iport; t=1467823438; x=1469033038; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HJqR8+p6CBxWQnRxQ9zSp4KDZU60nf/e5epb1S2/F6k=; b=Iqx8MSRT9pwdHI3wVPs+cMIqo+J3YcZLEGr3E1Q5KHXoVmVu3kTtVb4n HXQm97IznU6xO/wBWj8cOj4c2l4X+zfpG2TIKhWgs7vTdTWnDRu1WvUhK VTfSPganIaS8AEyny+8Ks5kBXBhxnZ6kKt+zRYnfc1TBItqMzZHSqjnc4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgB3NH1X/4wNJK1dgz5WfAa5FYF3I?= =?us-ascii?q?oV2AoEqOBQBAQEBAQEBZSeETAEBBAEBARtRCwULAgEIGC4nCyUCBA4FiCgIDrw?= =?us-ascii?q?eAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4F4glWEEhEBHIMsgi8BBJkTAY5Gg?= =?us-ascii?q?WqEVohqkAkBHjaDcG6HPTZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,319,1464652800"; d="scan'208";a="293705764" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2016 16:43:57 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u66Ghv4k005556 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 16:43:57 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; Wed, 6 Jul 2016 11:43:57 -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; Wed, 6 Jul 2016 11:43:56 -0500 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUaALwCKAgAAvygA= Date: Wed, 6 Jul 2016 16:43:56 +0000 Message-ID: <1128EAA0-BC93-471B-A879-9B581395C119@cisco.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> <990af5e6-d764-e23d-b4a0-1bd02dd71097@joelhalpern.com> In-Reply-To: <990af5e6-d764-e23d-b4a0-1bd02dd71097@joelhalpern.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.102] Content-Type: text/plain; charset="Windows-1252" Content-ID: <36F4A153F232464589A3D12225D29E21@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 16:44:03 -0000 +1 > On Jul 6, 2016, at 9:52 AM, Joel M. Halpern wrote: >=20 > I support the working group adopting this draft. It serves as a good bas= is for discussing and resolving issues in larger scale situations. >=20 > Yours, > Joel >=20 > On 7/6/16 9:17 AM, Jim Guichard (jguichar) wrote: >> Dear WG: >>=20 >>=20 >> This email serves as a call for WG adoption of >> draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption >> will run for 2 weeks ending 7/25/2016. >>=20 >>=20 >>=20 >> Please note that this is a call for adoption, and not a last call for >> content of the document. Adopting a WG document simply means that the WG >> will focus its efforts on that particular draft going forward, and use >> that document for resolving open issues and documenting the WG=92s decis= ions. >>=20 >>=20 >>=20 >> Please indicate whether you support adoption for not, and if not why. >> Issues you have with the current document itself can also be raised, but >> they should be raised in the context of what should be changed in the >> document going forward, rather than a pre-condition for adoption. >>=20 >>=20 >>=20 >> Finally, now is also a good time to poll for knowledge of any IPR that >> applies to this draft, in line with the IPR disclosure obligations for >> WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). >> If you are listed as a document author please respond to this email (to >> the chairs) whether or not you are aware of any relevant IPR. >>=20 >>=20 >> Thanks! >>=20 >>=20 >> SFC Chairs >>=20 >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 6 10:01: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 6720F12D129 for ; Wed, 6 Jul 2016 10:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.426, 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=lucidvision.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 WRPIKH1s40ML for ; Wed, 6 Jul 2016 10:01:06 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 E286E12D0EB for ; Wed, 6 Jul 2016 10:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1467824382; bh=WMq464gBbT50JufRHMRuGd6D6ZfiKOihWkz08+g3pMk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=rVCmhHF14tF3aNdNnjdFZLycuNH3/VpF0hxmT7gPekAfk/c8umZIDA6zwftT27Xv5 6N8Ah1wjarOUkmdA4DxRILlJrhefhETqAAkbsY6SIDsTapiNCAqEWaNkcAtc1ztQcN gsiQMoI81+W/YFGHJvrstchGHdjgqGx5PLzpd1rk= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.57.129; Content-Type: multipart/alternative; boundary=Apple-Mail-16AA20EE-2227-4E7A-A46E-C49C13E74E5E Mime-Version: 1.0 (1.0) From: thomas nadeau X-Mailer: iPhone Mail (13F69) In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> Date: Wed, 6 Jul 2016 13:00:21 -0400 Content-Transfer-Encoding: 7bit Message-Id: <893B624C-DD06-4070-96A5-25C37A96967A@lucidvision.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> To: "Jim Guichard (jguichar)" X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Unknown ip=166.177.57.129 X-IP-stats: No info recorded yet ip=166.177.57.129 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 17:01:08 -0000 --Apple-Mail-16AA20EE-2227-4E7A-A46E-C49C13E74E5E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jul 6, 2016, at 9:17 AM, Jim Guichard (jguichar) w= rote: >=20 > Dear WG: >=20 > This email serves as a call for WG adoption of draft-penno-sfc-hierarchica= l-06 as a WG document. The call for adoption will run for 2 weeks ending 7/2= 5/2016. > =20 > Please note that this is a call for adoption, and not a last call for cont= ent of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that documen= t for resolving open issues and documenting the WG=E2=80=99s decisions. > =20 > Please indicate whether you support adoption for not, and if not why. Issu= es you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goin= g forward, rather than a pre-condition for adoption.=20 > =20 > Finally, now is also a good time to poll for knowledge of any IPR that app= lies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are li= sted as a document author please respond to this email (to the chairs) wheth= er or not you are aware of any relevant IPR. >=20 > Thanks! >=20 > SFC Chairs > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-16AA20EE-2227-4E7A-A46E-C49C13E74E5E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Jul 6= , 2016, at 9:17 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:


This email serves as a= call for WG adoption of draft-penno-sfc-hierarchical-06 as a WG document. T= he call for adoption will run for 2 weeks ending 7/25/2016.

 

Please note that this= is a call for adoption, and not a last call for content of the document. Ad= opting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and u= se that document for resolving open issues and documenting the WG=E2=80=99s d= ecisions.

 

Please indicate wheth= er you support adoption for not, and if not why. Issues you have with the cu= rrent document itself can also be raised, but they should be raised in the context of what should be changed in the d= ocument going forward, rather than a pre-condition for adoption. 

 

Finally, now is also a good time to p= oll for knowledge of any IPR that applies to this draft, in line with the IP= R disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as= a document author please respond to this email (to the chairs) whether or n= ot you are aware of any relevant IPR.


Thanks!


SFC Chairs

____________________= ___________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/lis= tinfo/sfc
= --Apple-Mail-16AA20EE-2227-4E7A-A46E-C49C13E74E5E-- From nobody Wed Jul 6 10:01: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 6E35612D129 for ; Wed, 6 Jul 2016 10:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.426, 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=lucidvision.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 MqIl-ct0Es2J for ; Wed, 6 Jul 2016 10:01:03 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 F0F4812D0DB for ; Wed, 6 Jul 2016 10:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1467824379; bh=WocNQBCT3FsHz3XIz5IA/bUp+q0b7lnqaSpB/Pwrwyk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=1YdV3Mz0JgqcDmYedmkO4oqrsx9Hz7ikqvsX0+83qoiZjkMJ71RH7kEiiL8+/MO+2 fy4InGVXMBQ2t9tGd9r7RHVs0djdKqwkzNHYRBRcg1V9Dt98GHmlDhMpoLzaOlKPOu kTBqyd/m5g3ta0CeF2c2kS/ttErKPAhoUWZWPdmo= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.57.129; Content-Type: multipart/alternative; boundary=Apple-Mail-5BE90527-3D2A-4DD9-954A-074AD779F49C Mime-Version: 1.0 (1.0) From: thomas nadeau X-Mailer: iPhone Mail (13F69) In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> Date: Wed, 6 Jul 2016 13:00:36 -0400 Content-Transfer-Encoding: 7bit Message-Id: <34332C6D-28A8-4BF4-BB7C-8343A9FB399F@lucidvision.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> To: "Jim Guichard (jguichar)" X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=1 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=166.177.57.129 X-IP-stats: Notspam Incoming Last 0, First 0, in=1, out=0, spam=0 Known=true ip=166.177.57.129 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 17:01:09 -0000 --Apple-Mail-5BE90527-3D2A-4DD9-954A-074AD779F49C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 > On Jul 6, 2016, at 9:17 AM, Jim Guichard (jguichar) w= rote: >=20 > Dear WG: >=20 > This email serves as a call for WG adoption of draft-penno-sfc-hierarchica= l-06 as a WG document. The call for adoption will run for 2 weeks ending 7/2= 5/2016. > =20 > Please note that this is a call for adoption, and not a last call for cont= ent of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that documen= t for resolving open issues and documenting the WG=E2=80=99s decisions. > =20 > Please indicate whether you support adoption for not, and if not why. Issu= es you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goin= g forward, rather than a pre-condition for adoption.=20 > =20 > Finally, now is also a good time to poll for knowledge of any IPR that app= lies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are li= sted as a document author please respond to this email (to the chairs) wheth= er or not you are aware of any relevant IPR. >=20 > Thanks! >=20 > SFC Chairs > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-5BE90527-3D2A-4DD9-954A-074AD779F49C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

On Jul 6, 2= 016, at 9:17 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:


This email serves as a= call for WG adoption of draft-penno-sfc-hierarchical-06 as a WG document. T= he call for adoption will run for 2 weeks ending 7/25/2016.

 

Please note that this= is a call for adoption, and not a last call for content of the document. Ad= opting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and u= se that document for resolving open issues and documenting the WG=E2=80=99s d= ecisions.

 

Please indicate wheth= er you support adoption for not, and if not why. Issues you have with the cu= rrent document itself can also be raised, but they should be raised in the context of what should be changed in the d= ocument going forward, rather than a pre-condition for adoption. 

 

Finally, now is also a good time to p= oll for knowledge of any IPR that applies to this draft, in line with the IP= R disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as= a document author please respond to this email (to the chairs) whether or n= ot you are aware of any relevant IPR.


Thanks!


SFC Chairs

____________________= ___________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/lis= tinfo/sfc
= --Apple-Mail-5BE90527-3D2A-4DD9-954A-074AD779F49C-- From nobody Wed Jul 6 10:02: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 1819312B039 for ; Wed, 6 Jul 2016 10:02:31 -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, 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] 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 hFoNgWjmnxZO for ; Wed, 6 Jul 2016 10:02:28 -0700 (PDT) Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com [209.85.216.182]) (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 7827312D0AC for ; Wed, 6 Jul 2016 10:02:28 -0700 (PDT) Received: by mail-qt0-f182.google.com with SMTP id c34so119483484qte.0 for ; Wed, 06 Jul 2016 10:02:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VJ0RCjBrJtu2JXtAYEpQqeQQFo5y6SN4jl4tZDEhs8I=; b=LhYFB3Lpi5hQXLyaSqbT99m8RgqBiwCtLqJPzJOtT66lDpHxskhtGWpf24ga3bp2IG VvFFr+NgwXGO94ggKgpncC2P9bXrxylFLa6O3xjAc61diBjBy5pg12J6Id01G/1af7wt AbCmkzdVoCfl0vbaE7t+Ki1Y8eU7HOqssHg0wLeJ4DKXTfiMFMBEYCkr4JHApl1HPogC p1+v0zdpkE7FE1FJ2ee06x0JyZMbJ8uBU5+fGoUlHbcU+Frs5cfLaJ7BiBNZp7ZSHyjd kAj5wipFIwV162xlShleb11hfie92ml9Epv41UAeHlvJBn1ebvqtL6F22xM2wrty/I/O ykmw== X-Gm-Message-State: ALyK8tIcRanRIh/5SDsmNmL4ZuLza6Zr+cIixNze97mpyyWXiHHVh9KdUNYHUFXyHk3YJzna X-Received: by 10.200.48.46 with SMTP id f43mr37462105qte.10.1467824547552; Wed, 06 Jul 2016 10:02:27 -0700 (PDT) Received: from [192.168.128.95] (dhcp-0-18-a-37-4a-35.cpe.townisp.com. [216.195.26.69]) by smtp.gmail.com with ESMTPSA id v4sm1617347qkh.28.2016.07.06.10.02.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jul 2016 10:02:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DA12DDB1-95CA-4F08-B38D-0730479354E6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Azhar Sayeed In-Reply-To: <34332C6D-28A8-4BF4-BB7C-8343A9FB399F@lucidvision.com> Date: Wed, 6 Jul 2016 13:02:26 -0400 Message-Id: <025C2314-A44B-417B-8B9E-0A639A6CAB57@redhat.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> <34332C6D-28A8-4BF4-BB7C-8343A9FB399F@lucidvision.com> To: Thomas Nadeau X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jim Guichard , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 17:02:31 -0000 --Apple-Mail=_DA12DDB1-95CA-4F08-B38D-0730479354E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 Azhar > On Jul 6, 2016, at 1:00 PM, thomas nadeau = wrote: >=20 > +1 >=20 > On Jul 6, 2016, at 9:17 AM, Jim Guichard (jguichar) = > wrote: >=20 >> Dear WG: >>=20 >> This email serves as a call for WG adoption of = draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption = will run for 2 weeks ending 7/25/2016. >> =20 >> Please note that this is a call for adoption, and not a last call for = content of the document. Adopting a WG document simply means that the WG = will focus its efforts on that particular draft going forward, and use = that document for resolving open issues and documenting the WG=E2=80=99s = decisions. >> =20 >> Please indicate whether you support adoption for not, and if not why. = Issues you have with the current document itself can also be raised, but = they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption.=20 >> =20 >> Finally, now is also a good time to poll for knowledge of any IPR = that applies to this draft, in line with the IPR disclosure obligations = for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more = details). If you are listed as a document author please respond to this = email (to the chairs) whether or not you are aware of any relevant IPR. >>=20 >> Thanks! >>=20 >> SFC Chairs >> _______________________________________________ >> 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 --Apple-Mail=_DA12DDB1-95CA-4F08-B38D-0730479354E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

Azhar

On Jul 6, 2016, at 1:00 PM, = thomas nadeau <tnadeau@lucidvision.com> wrote:

+1

On Jul 6, 2016, at = 9:17 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear = WG:

This email serves as a call for WG adoption of = draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption = will run for 2 weeks ending 7/25/2016.

 

Please= note that this is a call for adoption, and not a last call for content = of the document. Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, = and use that document for resolving open issues and documenting the = WG=E2=80=99s decisions.

 

Please= indicate whether you support adoption for not, and if not why. Issues = you have with the current document itself can also be raised, but they should be raised in the context of what should be changed in = the document going forward, rather than a pre-condition for = adoption. 

 

Finally, now is also a good time = to poll for knowledge of any IPR that applies to this draft, in line = with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are = listed as a document author please respond to this email (to the chairs) = whether or not you are aware of any relevant IPR.

Thanks!

SFC = Chairs
_______________________________________________
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

= --Apple-Mail=_DA12DDB1-95CA-4F08-B38D-0730479354E6-- From nobody Wed Jul 6 10:16: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 A72F612D0F9 for ; Wed, 6 Jul 2016 10:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amm3cEMaaH0l for ; Wed, 6 Jul 2016 10:16:09 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) (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 D040E12D0AA for ; Wed, 6 Jul 2016 10:07:15 -0700 (PDT) Received: from [85.158.137.35] by server-16.bemta-3.messagelabs.com id 41/5E-23871-2CA3D775; Wed, 06 Jul 2016 17:07:14 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRWlGSWpSXmKPExsVybg1jku5Bq9p wg98HlCyWzlO3ePJgK7sDk8eU3xtZPZYs+ckUwBTFmpmXlF+RwJoxedketoIPnhUTVz1ga2B8 4dHFyMkhIeAncX/TJPYuRi4OIYF9jBKTd61iBEkICVxnlHj5QRQicYJRYvbv2+wgCTYBS4kVm 2ezgtgiAkES3c0T2UBsYQFXievPL7FBxN0kbjy4yAJhG0lcXbYeLM4ioCKx58okMJtXwEdiz4 aFLBDLbCTmHr0FZHNwcArYSux8XgQSZhQQk/h+ag0TiM0sIC5x68l8JoijBSSW7DnPDGGLSrx 8/I8VwjaQ2Lp0HwuELS9x690cNojePIm3x6+yQ6wVlDg58wlUjaTEwRU3oE5Qlvi1fw8jxL8L GSU2d85jBrlHQsBe4n2v9wRGyVlIzpiFZOwsJGNnAXUwC2hKrN+lD1GiKDGl+yE7hK0h0TpnL juy+AJG9lWMGsWpRWWpRbrGBnpJRZnpGSW5iZk5uoYGxnq5qcXFiempOYlJxXrJ+bmbGIFxXs /AwLiDsfOE3yFGSQ4mJVFelm/V4UJ8SfkplRmJxRnxRaU5qcWHGGU4OJQkeOda1oYLCRalpqd WpGXmABMOTFqCg0dJhNcWJM1bXJCYW5yZDpE6xagoJc6bDJIQAElklObBtcGS3CVGWSlhXkYG BgYhnoLUotzMElT5V4ziHIxKwrzLQabwZOaVwE1/BbSYCWjxT5dqkMUliQgpqQZGdsvUqs23v m3fssUjwO3BCp8nDE++bowXY5tqdvTMbcGgz5fO+ZU93PZyU8rDz7+Tfwb6z3U5MPfqoq61L9 iMPIzXGz69O8FcPl+nM+BA0NO5Z/YJuNzau1c4vTbgbfiEKTeEn63Tl16zrrPgmV3Y/9BnYla 2Drdm1Zb+8T2atNLATWdDeV+AoBJLcUaioRZzUXEiAHrl3jhtAwAA X-Env-Sender: daniel.bernier@bell.ca X-Msg-Ref: server-10.tower-134.messagelabs.com!1467824832!38318960!1 X-Originating-IP: [206.172.1.98] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32256 invoked from network); 6 Jul 2016 17:07:13 -0000 Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (206.172.1.98) by server-10.tower-134.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 6 Jul 2016 17:07:13 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE01-DOR.bell.corp.bce.ca Received: from DG3MBX02-WYN.bell.corp.bce.ca (198.235.121.230) by EX13EDGE01-DOR.bell.corp.bce.ca (198.235.121.54) with Microsoft SMTP Server id 15.0.1076.9; Wed, 6 Jul 2016 13:02:34 -0400 Received: from DG3MBX04-WYN.bell.corp.bce.ca (2002:8eb6:121a::8eb6:121a) by DG3MBX02-WYN.bell.corp.bce.ca (2002:8eb6:1218::8eb6:1218) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jul 2016 13:07:10 -0400 Received: from DG3MBX04-WYN.bell.corp.bce.ca ([fe80::e80a:ff7:7f77:7b18]) by DG3MBX04-WYN.bell.corp.bce.ca ([fe80::e80a:ff7:7f77:7b18%22]) with mapi id 15.00.1104.000; Wed, 6 Jul 2016 13:07:10 -0400 From: "Bernier, Daniel (520165)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUaALooOA Date: Wed, 6 Jul 2016 17:07:10 +0000 Message-ID: References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@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: [172.24.25.6] Content-Type: multipart/alternative; boundary="_000_d0ba202cb1ca44c78eb55d815801110fDG3MBX04WYNbellcorpbcec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: SoftFail (EX13EDGE01-DOR.bell.corp.bce.ca: domain of transitioning daniel.bernier@bell.ca discourages use of 198.235.121.230 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE01-DOR.bell.corp.bce.ca Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 17:16:11 -0000 --_000_d0ba202cb1ca44c78eb55d815801110fDG3MBX04WYNbellcorpbcec_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KU2VudDogSnVseS0wNi0xNiA5OjE4IEFNDQpUbzog c2ZjQGlldGYub3JnDQpTdWJqZWN0OiBbc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFm dC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNg0KDQpEZWFyIFdHOg0KDQpUaGlzIGVtYWlsIHNl cnZlcyBhcyBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy1oaWVyYXJj aGljYWwtMDYgYXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgcnVu IGZvciAyIHdlZWtzIGVuZGluZyA3LzI1LzIwMTYuDQoNClBsZWFzZSBub3RlIHRoYXQgdGhpcyBp cyBhIGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEgbGFzdCBjYWxsIGZvciBjb250ZW50IG9m IHRoZSBkb2N1bWVudC4gQWRvcHRpbmcgYSBXRyBkb2N1bWVudCBzaW1wbHkgbWVhbnMgdGhhdCB0 aGUgV0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0IHBhcnRpY3VsYXIgZHJhZnQgZ29p bmcgZm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRvY3VtZW50IGZvciByZXNvbHZpbmcgb3BlbiBpc3N1 ZXMgYW5kIGRvY3VtZW50aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25zLg0KDQpQbGVhc2UgaW5kaWNh dGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBmb3Igbm90LCBhbmQgaWYgbm90IHdoeS4g SXNzdWVzIHlvdSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNhbiBhbHNv IGJlIHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNlZCBpbiB0aGUgY29udGV4dCBvZiB3 aGF0IHNob3VsZCBiZSBjaGFuZ2VkIGluIHRoZSBkb2N1bWVudCBnb2luZyBmb3J3YXJkLCByYXRo ZXIgdGhhbiBhIHByZS1jb25kaXRpb24gZm9yIGFkb3B0aW9uLg0KDQpGaW5hbGx5LCBub3cgaXMg YWxzbyBhIGdvb2QgdGltZSB0byBwb2xsIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gdGhpcyBkcmFmdCwgaW4gbGluZSB3aXRoIHRoZSBJUFIgZGlzY2xvc3VyZSBvYmxp Z2F0aW9ucyBmb3IgV0cgcGFydGljaXBhbnRzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFu ZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50 IGF1dGhvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsICh0byB0aGUgY2hhaXJzKSB3aGV0 aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuDQoNClRoYW5rcyEN Cg0KU0ZDIENoYWlycw0K --_000_d0ba202cb1ca44c78eb55d815801110fDG3MBX04WYNbellcorpbcec_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmltIEd1aWNoYXJk IChqZ3VpY2hhcik8YnI+DQo8Yj5TZW50OjwvYj4gSnVseS0wNi0xNiA5OjE4IEFNPGJyPg0KPGI+ VG86PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NmY10gQ2FsbCBmb3Ig V0cgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OmJsYWNrIj5EZWFyIFdHOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpi bGFjayI+VGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFm dC1wZW5uby1zZmMtaGllcmFyY2hpY2FsLTA2IGFzIGEgV0cgZG9jdW1lbnQuIFRoZSBjYWxsIGZv ciBhZG9wdGlvbiB3aWxsIHJ1biBmb3IgMiB3ZWVrcyBlbmRpbmcgNy8yNS8yMDE2Ljwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBh IGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEgbGFzdCBjYWxsIGZvciBjb250ZW50IG9mIHRo ZSBkb2N1bWVudC4gQWRvcHRpbmcgYSBXRyBkb2N1bWVudCBzaW1wbHkgbWVhbnMgdGhhdCB0aGUg V0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0DQogcGFydGljdWxhciBkcmFmdCBnb2lu ZyBmb3J3YXJkLCBhbmQgdXNlIHRoYXQgZG9jdW1lbnQgZm9yIHJlc29sdmluZyBvcGVuIGlzc3Vl cyBhbmQgZG9jdW1lbnRpbmcgdGhlIFdH4oCZcyBkZWNpc2lvbnMuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+UGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IHN1cHBvcnQg YWRvcHRpb24gZm9yIG5vdCwgYW5kIGlmIG5vdCB3aHkuIElzc3VlcyB5b3UgaGF2ZSB3aXRoIHRo ZSBjdXJyZW50IGRvY3VtZW50IGl0c2VsZiBjYW4gYWxzbyBiZSByYWlzZWQsIGJ1dCB0aGV5IHNo b3VsZCBiZSByYWlzZWQgaW4gdGhlIGNvbnRleHQNCiBvZiB3aGF0IHNob3VsZCBiZSBjaGFuZ2Vk IGluIHRoZSBkb2N1bWVudCBnb2luZyBmb3J3YXJkLCByYXRoZXIgdGhhbiBhIHByZS1jb25kaXRp b24gZm9yIGFkb3B0aW9uLiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPkZpbmFsbHksIG5vdyBpcyBhbHNvIGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yIGtub3dsZWRn ZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhl IElQUiBkaXNjbG9zdXJlIG9ibGlnYXRpb25zIGZvciBXRyBwYXJ0aWNpcGFudHMgKHNlZSBSRkNz IDM5NzksDQogNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4gSWYgeW91IGFy ZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bCAodG8gdGhlIGNoYWlycykgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVs ZXZhbnQgSVBSLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ VGhhbmtzITwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+U0ZD IENoYWlyczwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d0ba202cb1ca44c78eb55d815801110fDG3MBX04WYNbellcorpbcec_-- From nobody Wed Jul 6 12:09: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 8ECCA12D1E0 for ; Wed, 6 Jul 2016 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.446 X-Spam-Level: X-Spam-Status: No, score=-8.446 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.426, 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 69KGUv1imuNs for ; Wed, 6 Jul 2016 12:09:48 -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 79CA812D1C2 for ; Wed, 6 Jul 2016 12:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1467832188; x=1499368188; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aw1oD1TJEsTK4nAdkezQLb2y6nTX3z34j6axr5I+iK4=; b=iyxwZ22kjpmAkIez5sc6TzUa4XT+3FcULWNbN1S6gAEREshfhLzPie1p F70DLfQW7hmmNG+WOIaIYdJkHKK+iKbDdXu8mgznv81k9IkSFpvoM7nUr 9IVc5d4TgTRJQhjAAomxbm5uiSc3JGuZanE6gbEH4OXplYzKoo1AqVGeB w=; X-IronPort-AV: E=Sophos;i="5.28,320,1464652800"; d="scan'208,217";a="228037461" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 06 Jul 2016 19:09:48 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 6 Jul 2016 12:09:47 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1178.000; Wed, 6 Jul 2016 12:09:47 -0700 From: Sumandra Majee To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR17n2TT7k6EsYv0KpDJRZOD24TQ== Date: Wed, 6 Jul 2016 19:09:47 +0000 Message-ID: References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_DA1922FC0A9B4E759D3F709E9AB8473CF5com_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 19:09:54 -0000 --_000_DA1922FC0A9B4E759D3F709E9AB8473CF5com_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Sent from my iPhone On Jul 6, 2016, at 6:17 AM, Jim Guichard (jguichar) > wrote: Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-hierarchical= -06 as a WG document. The call for adoption will run for 2 weeks ending 7/2= 5/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_DA1922FC0A9B4E759D3F709E9AB8473CF5com_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support

Sent from my iPhone

On Jul 6, 2016, at 6:17 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:


This email serves a= s a call for WG adoption of draft-penno-sfc-hierarchical-06 as a WG documen= t. The call for adoption will run for 2 weeks ending 7/25/2016.

 

Please note that th= is is a call for adoption, and not a last call for content of the document.= Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and = use that document for resolving open issues and documenting the WG’s = decisions.

 

Please indicate whe= ther you support adoption for not, and if not why. Issues you have with the= current document itself can also be raised, but they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. 

 

Finally, now is also a good time to= poll for knowledge of any IPR that applies to this draft, in line with the= IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed a= s a document author please respond to this email (to the chairs) whether or= not you are aware of any relevant IPR.


Thanks!


SFC Chairs

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_DA1922FC0A9B4E759D3F709E9AB8473CF5com_-- From nobody Wed Jul 6 12:33: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 E975912D123 for ; Wed, 6 Jul 2016 12:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHLIyaIcJV2T for ; Wed, 6 Jul 2016 12:33:38 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DD812D0CD for ; Wed, 6 Jul 2016 12:33:34 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-f5-577d526a8f8f Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 0B.98.09012.A625D775; Wed, 6 Jul 2016 20:48:11 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Wed, 6 Jul 2016 15:33:33 -0400 From: Gregory Mirsky To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14kDWWZtljiaXEKuqE++y3FX46ALyTHg Date: Wed, 6 Jul 2016 19:33:32 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221AC3425@eusaamb103.ericsson.se> References: <60B45C4E-916C-4CE7-B076-34110590BD61@cisco.com> In-Reply-To: <60B45C4E-916C-4CE7-B076-34110590BD61@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221AC3425eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZXLonUDc7qDbc4NERDoul89QtnjzYyu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZdx7soO94FVNxarrU9gbGPdUdjFyckgImEic 2fKfFcIWk7hwbz1bFyMXh5DAUUaJb0tPskA4yxglDi05zAZSxSZgJPFiYw87iC0iECzxau4P RhBbWMBb4tC9/ywQcR+JdQdPQ9UYSVyadhKsl0VAReLi3MNgcV4BX4ltDzcygdhCAjYSK7Y+ B7uCU8BW4vye02AzGYEu+n5qDVgNs4C4xK0n85kgLhWQWLLnPDOELSrx8vE/qA+UJCYtPccK UZ8v0fq9hxFil6DEyZlPWCYwisxCMmoWkrJZSMpmMXIAxTUl1u/ShyhRlJjS/ZAdwtaQaJ0z lx1ZfAEj+ypGjtLigpzcdCODTYzA2Dkmwaa7g/H+dM9DjAIcjEo8vAu+VocLsSaWFVfmHmKU 4GBWEuE9ElEbLsSbklhZlVqUH19UmpNafIhRmoNFSZxX7JFiuJBAemJJanZqakFqEUyWiYNT qoFxQ1ZbQesNvXk7jv3Sd4k/vpVpRVPeErnqa35itY/bPCIUdLbb5hs6phen5lub35/DGRXw Kl/h90mrsDzBd9KXHl/Y3iK0JsA+99j/2LnHOpJD/Goyjxyv8Hjz34PPx8r9gtynVNcDvYas tdM/bvp3sHXhm4e3N2uJFfWYiVnMvj/v5YF9P24rsRRnJBpqMRcVJwIA6q+vlZkCAAA= Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 19:33:40 -0000 --_000_7347100B5761DC41A166AC17F22DF11221AC3425eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 eWVzL3N1cHBvcnQNCknigJl2ZSByZWFkIHRoZSBkb2N1bWVudCBhbmQgYmVsaWV2ZSBpdCBpcyB2 ZXJ5IHVzZWZ1bCB3b3JrLiBJIHdvbmRlciB3aGV0aGVyIEluZm9ybWF0aW9uYWwgaXMgdGhlIHJp Z2h0IHRyYWNrIGFzIHNvbWUgbWF0ZXJpYWwgaW4gc2VjdGlvbnMgMy4xLjUsIDMuMiwgMy4zIG1h eSB1c2UgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBhbmQgbWFuZGF0ZSB1c2Ugb2YgdGhlIFN0YW5k YXJkIHRyYWNrLg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpTZW50OiBXZWRuZXNk YXksIEp1bHkgMDYsIDIwMTYgNjoxOSBBTQ0KVG86IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hp Y2FsLTA2DQoNCkNvcnJlY3Rpb24uDQoNClRoZSB0ZXh0IHNob3VsZCByZWFkIOKAmGRyYWZ0LWRv bHNvbi1zZmMtaGllcmFyY2hpY2FsLTA24oCZIC4uDQoNClNGQyBDaGFpcnMNCg0KRnJvbTogc2Zj IDxzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFy QGNpc2NvLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgNiwgMjAxNiBhdCA5OjE3IEFNDQpU bzogInNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPj4NClN1YmplY3Q6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9m IGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2DQoNCkRlYXIgV0c6DQoNClRoaXMgZW1h aWwgc2VydmVzIGFzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWhp ZXJhcmNoaWNhbC0wNiBhcyBhIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gd2ls bCBydW4gZm9yIDIgd2Vla3MgZW5kaW5nIDcvMjUvMjAxNi4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0 aGlzIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24sIGFuZCBub3QgYSBsYXN0IGNhbGwgZm9yIGNvbnRl bnQgb2YgdGhlIGRvY3VtZW50LiBBZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyB0 aGF0IHRoZSBXRyB3aWxsIGZvY3VzIGl0cyBlZmZvcnRzIG9uIHRoYXQgcGFydGljdWxhciBkcmFm dCBnb2luZyBmb3J3YXJkLCBhbmQgdXNlIHRoYXQgZG9jdW1lbnQgZm9yIHJlc29sdmluZyBvcGVu IGlzc3VlcyBhbmQgZG9jdW1lbnRpbmcgdGhlIFdH4oCZcyBkZWNpc2lvbnMuDQoNClBsZWFzZSBp bmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9uIGZvciBub3QsIGFuZCBpZiBub3Qg d2h5LiBJc3N1ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCBpdHNlbGYgY2Fu IGFsc28gYmUgcmFpc2VkLCBidXQgdGhleSBzaG91bGQgYmUgcmFpc2VkIGluIHRoZSBjb250ZXh0 IG9mIHdoYXQgc2hvdWxkIGJlIGNoYW5nZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQs IHJhdGhlciB0aGFuIGEgcHJlLWNvbmRpdGlvbiBmb3IgYWRvcHRpb24uDQoNCkZpbmFsbHksIG5v dyBpcyBhbHNvIGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRo YXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQUiBkaXNjbG9zdXJl IG9ibGlnYXRpb25zIGZvciBXRyBwYXJ0aWNpcGFudHMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2 NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9j dW1lbnQgYXV0aG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgKHRvIHRoZSBjaGFpcnMp IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NCg0KVGhh bmtzIQ0KDQpTRkMgQ2hhaXJzDQo= --_000_7347100B5761DC41A166AC17F22DF11221AC3425eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj55ZXMvc3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SeKAmXZlIHJlYWQgdGhlIGRvY3Vt ZW50IGFuZCBiZWxpZXZlIGl0IGlzIHZlcnkgdXNlZnVsIHdvcmsuIEkgd29uZGVyIHdoZXRoZXIg SW5mb3JtYXRpb25hbCBpcyB0aGUgcmlnaHQgdHJhY2sgYXMgc29tZSBtYXRlcmlhbCBpbiBzZWN0 aW9ucyAzLjEuNSwgMy4yLCAzLjMgbWF5IHVzZSB0aGUgbm9ybWF0aXZlDQogbGFuZ3VhZ2UgYW5k IG1hbmRhdGUgdXNlIG9mIHRoZSBTdGFuZGFyZCB0cmFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg R3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KaW0gR3VpY2hhcmQgKGpndWljaGFyKTxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMDYsIDIwMTYgNjoxOSBBTTxicj4NCjxi PlRvOjwvYj4gc2ZjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBDYWxs IGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q29ycmVjdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+VGhlIHRleHQgc2hvdWxkIHJlYWQg4oCYZHJhZnQtPGI+ZG9sc29uPC9iPi1zZmMtaGllcmFy Y2hpY2FsLTA24oCZIC4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlNGQyBDaGFpcnM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnNmYyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPldlZG5lc2RheSwgSnVseSA2LCAyMDE2IGF0IDk6MTcgQU08YnI+DQo8Yj5UbzogPC9iPiZx dW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPltzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWRv bHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+RGVhciBXRzo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoaXMgZW1haWwg c2VydmVzIGFzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWhpZXJh cmNoaWNhbC0wNiBhcyBhIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBy dW4gZm9yIDIgd2Vla3MgZW5kaW5nIDcvMjUvMjAxNi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpi bGFjayI+UGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24sIGFuZCBu b3QgYSBsYXN0IGNhbGwgZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBBZG9wdGluZyBhIFdH IGRvY3VtZW50IHNpbXBseSBtZWFucyB0aGF0IHRoZSBXRyB3aWxsIGZvY3VzIGl0cyBlZmZvcnRz IG9uIHRoYXQNCiBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZvcndhcmQsIGFuZCB1c2UgdGhhdCBk b2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFuZCBkb2N1bWVudGluZyB0aGUgV0fi gJlzIGRlY2lzaW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+UGxlYXNlIGluZGlj YXRlIHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlmIG5vdCB3aHku IElzc3VlcyB5b3UgaGF2ZSB3aXRoIHRoZSBjdXJyZW50IGRvY3VtZW50IGl0c2VsZiBjYW4gYWxz byBiZSByYWlzZWQsIGJ1dCB0aGV5IHNob3VsZCBiZSByYWlzZWQgaW4gdGhlIGNvbnRleHQNCiBv ZiB3aGF0IHNob3VsZCBiZSBjaGFuZ2VkIGluIHRoZSBkb2N1bWVudCBnb2luZyBmb3J3YXJkLCBy YXRoZXIgdGhhbiBhIHByZS1jb25kaXRpb24gZm9yIGFkb3B0aW9uLiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOmJsYWNrIj5GaW5hbGx5LCBub3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBw b2xsIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwg aW4gbGluZSB3aXRoIHRoZSBJUFIgZGlzY2xvc3VyZSBvYmxpZ2F0aW9ucyBmb3IgV0cgcGFydGlj aXBhbnRzIChzZWUgUkZDcyAzOTc5LA0KIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0 YWlscykuIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSByZXNw b25kIHRvIHRoaXMgZW1haWwgKHRvIHRoZSBjaGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUg YXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoYW5rcyE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlNGQyBDaGFpcnM8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF11221AC3425eusaamb103erics_-- From nobody Wed Jul 6 12: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 6B0A012D10F for ; Wed, 6 Jul 2016 12:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7pvzZKCPQ4q for ; Wed, 6 Jul 2016 12:36:41 -0700 (PDT) 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 C3EA312D0CD for ; Wed, 6 Jul 2016 12:36:41 -0700 (PDT) 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.0266.001; Wed, 6 Jul 2016 12:36:41 -0700 From: Ron Parker To: Sumandra Majee , "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUaAMOjOA//+SKDA= Date: Wed, 6 Jul 2016 19:36:41 +0000 Message-ID: References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [96.230.30.248] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B6D8070F3MBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 19:36:44 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D8070F3MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee Sent: Wednesday, July 6, 2016 3:10 PM To: Jim Guichard (jguichar) Cc: sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Support Sent from my iPhone On Jul 6, 2016, at 6:17 AM, Jim Guichard (jguichar) > wrote: Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-hierarchical= -06 as a WG document. The call for adoption will run for 2 weeks ending 7/2= 5/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D8070F3MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

   Ron

&nbs= p;

From: sfc [mailto:sfc-bounces@ietf.o= rg] On Behalf Of Sumandra Majee
Sent: Wednesday, July 6, 2016 3:10 PM
To: Jim Guichard (jguichar) <jguichar@cisco.com>
Cc: sfc@ietf.org
Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarch= ical-06

 

Support

Sent from my iPhone


On Jul 6, 2016, at 6:17 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:

 

This email serves as a call for WG adoption of draft-penno-sfc-hierarchica= l-06 as a WG document. The call for adoption will run for 2 weeks ending 7/= 25/2016.

 

Please note that this is a call for adoption, and not a last call for cont= ent of the document. Adopting a WG document simply means that the WG will f= ocus its efforts on that particular draft going forward, and use that document for resolving open issues and d= ocumenting the WG’s decisions.

 

Please indicate whether you support adoption for not, and if not why. Issu= es you have with the current document itself can also be raised, but they s= hould be raised in the context of what should be changed in the document going forward, rather than a pre-conditi= on for adoption. 

 

Finally, now is also a good time to poll for knowledge of any IPR that app= lies to this draft, in line with the IPR disclosure obligations for WG part= icipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please = respond to this email (to the chairs) whether or not you are aware of any r= elevant IPR.

 

Thanks!

 

SFC Chairs

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

--_000_CDF2F015F4429F458815ED2A6C2B6B0B6D8070F3MBX021W3CA2exch_-- From nobody Wed Jul 6 12:37: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 2FA7B12D0CD for ; Wed, 6 Jul 2016 12:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 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.426] 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 NH2UHb9fXQMx for ; Wed, 6 Jul 2016 12:37:25 -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 9934112D10F for ; Wed, 6 Jul 2016 12:37:24 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 15:37:23 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: Comments on ietf-sfc-oam-framework Thread-Index: AdHXvdDiytqAWO1+RbyDLL3gzTuvmA== Date: Wed, 6 Jul 2016 19:37:22 +0000 Message-ID: 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_E8355113905631478EFF04F5AA706E9830FE7543wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Comments on ietf-sfc-oam-framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 19:37:27 -0000 --_000_E8355113905631478EFF04F5AA706E9830FE7543wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The sfc-oam-framework document discusses monitoring of SFs, but I'm having = some trouble with the descriptions. (1) Firstly, in section 3, SFs may be SFC-aware or SFC-unaware. An SFC-aware SF is one that understands the SFC encapsulation has the SFF component co-resident with the SF sub-component . An SFC-unware SF is one that does not understand the SFC encapsulation (i.e. a legacy SF) and has to be accessed via an separate SFF and potentially an SFC proxy function. The second sentence is grammatically confusing. I think it intended "... an= d has the SFF component co-resident..." But as I understand it, an SF can be SFC-aware without a co-resident SFF. I propose rewording, allowing non-resident SFF: SFs may be SFC-aware or SFC-unaware. An SFC-aware SF is one that understands the SFC encapsulation. An SFC-unware SF is one that does no= t understand the SFC encapsulation (i.e. a legacy SF) and has to be accessed via an SFC proxy function. (2) Secondly, in section 3.1.1, monitoring of the SF is considered out of scope= , which seems to mean monitoring of the SF from afar. However, we see a very real need for standardization of monitoring the SF f= rom the SFF. I propose adding something like this: There is a requirement for an SFF to monitor health of connected SFs. It is beyond the scope of this document to specify how to monitor full functionality of an SF because the functions provided by the SF are out of scope of SFC. However, to provide rapid fail-over detection, there is a requirement for an SFF to determine if an SF is capable of forwarding packets. An optional capability may allow an SF to indicate a measure of load to the SFF, assisting in load-balancing to equivalent SFs. Concretely, I'm trying to explain the need for a single-hop ping-like mecha= nism between SFF and SF. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830FE7543wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The sfc-oam-framework document discusses monitoring = of SFs, but I’m having some trouble with the descriptions.=

 

(1)

Firstly, in section 3,

 

=    SFs may be SFC-aware or SFC-unaware.  An SFC-aware SF is = one that

=    understands the SFC encapsulation has the SFF component co-res= ident with

=    the SF sub-component .  An SFC-unware SF is one that does= not understand

=    the SFC encapsulation (i.e. a legacy SF) and has to be accesse= d via an

=    separate SFF and potentially an SFC proxy function.=

 

The second sentence is grammatically confusing. I th= ink it intended “… and has the SFF component co-resident…= ”

But as I understand it, an SF can be SFC-aware witho= ut a co-resident SFF.

 

I propose rewording, allowing non-resident SFF:=

=    SFs may be SFC-aware or SFC-unaware.  An SFC-aware SF is = one that

=    understands the SFC encapsulation.  An SFC-unware SF is o= ne that does not understand

=    the SFC encapsulation (i.e. a legacy SF) and has to be accesse= d via an

=    SFC proxy function.

 

(2)

Secondly, in section 3.1.1, monitoring of the SF is = considered out of scope, which seems to mean monitoring of the SF from afar= .

However, we see a very real need for standardization= of monitoring the SF from the SFF.

I propose adding something like this:

=    There is a requirement for an SFF to monitor health of connect= ed SFs.

=    It is beyond the scope of this document to specify how to=

=    monitor full functionality of an SF because<= /p>

=    the functions provided by the SF are out of scope of SFC.=

=    However, to provide rapid fail-over detection, there is a requ= irement

=    for an SFF to determine if an SF is capable of forwarding= packets.

=    An optional capability may allow an SF to indicate a measure o= f load

=    to the SFF, assisting in load-balancing to equivalent SFs.

 

 

Concretely, I’m trying to explain the need for= a single-hop ping-like mechanism between SFF and SF.

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_E8355113905631478EFF04F5AA706E9830FE7543wtlexchp2sandvi_-- From nobody Wed Jul 6 16:50: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 7D0D312D0FD for ; Wed, 6 Jul 2016 16:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 ou5WZ33TGp7T for ; Wed, 6 Jul 2016 16:50:32 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id A53F512B022 for ; Wed, 6 Jul 2016 16:50:32 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP; 06 Jul 2016 16:50:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,322,1464678000"; d="scan'208";a="990393517" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by orsmga001.jf.intel.com with ESMTP; 06 Jul 2016 16:50:32 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.140]) by ORSMSX104.amr.corp.intel.com ([169.254.4.216]) with mapi id 14.03.0248.002; Wed, 6 Jul 2016 16:50:31 -0700 From: "Elzur, Uri" To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUaAL4amAgAAxVuA= Date: Wed, 6 Jul 2016 23:50:31 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B8995858943C8F1@ORSMSX114.amr.corp.intel.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> <990af5e6-d764-e23d-b4a0-1bd02dd71097@joelhalpern.com> In-Reply-To: <990af5e6-d764-e23d-b4a0-1bd02dd71097@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzY3ODM2OGUtNzA1OC00OWNiLTk5OTMtNWM1MzBjOTUzM2Y0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjkxRkczQmQrWGdcLzdsZHZMUGcwNVBYejJvSWszeHJFZXJiQ204UzBJSHVzPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Jul 2016 23:50:35 -0000 +1 It seems to be aligned with NSH's basic support and hope we keep it that wa= y Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, July 6, 2016 6:53 AM To: Jim Guichard (jguichar) ; sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 I support the working group adopting this draft. It serves as a good basis= for discussing and resolving issues in larger scale situations. Yours, Joel On 7/6/16 9:17 AM, Jim Guichard (jguichar) wrote: > Dear WG: > > > This email serves as a call for WG adoption of > draft-penno-sfc-hierarchical-06 as a WG document. The call for=20 > adoption will run for 2 weeks ending 7/25/2016. > > > > Please note that this is a call for adoption, and not a last call for=20 > content of the document. Adopting a WG document simply means that the=20 > WG will focus its efforts on that particular draft going forward, and=20 > use that document for resolving open issues and documenting the WG's deci= sions. > > > > Please indicate whether you support adoption for not, and if not why. > Issues you have with the current document itself can also be raised,=20 > but they should be raised in the context of what should be changed in=20 > the document going forward, rather than a pre-condition for adoption. > > > > Finally, now is also a good time to poll for knowledge of any IPR that=20 > applies to this draft, in line with the IPR disclosure obligations for=20 > WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as a document author please respond to this email=20 > (to the chairs) whether or not you are aware of any relevant IPR. > > > Thanks! > > > SFC Chairs > > > > _______________________________________________ > 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 Jul 6 20:01: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 136B212D5B1 for ; Wed, 6 Jul 2016 20:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2B3OLP6uMbZ for ; Wed, 6 Jul 2016 20:01:00 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 753CE12B062 for ; Wed, 6 Jul 2016 20:01:00 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 53D14D87CF20F; Thu, 7 Jul 2016 03:00:58 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u6730wJi014379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2016 03:00:59 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u6730wZC025336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jul 2016 03:00:58 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.234]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 23:00:58 -0400 From: "Dolganow, Andrew (Nokia - SG)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR1/vJEqH1/8u6bEuwnhRb18qj/A== Date: Thu, 7 Jul 2016 03:00:58 +0000 Message-ID: <00DD6376-EF84-4B58-8664-515A9A21636F@nokia.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_00DD6376EF844B588664515A9A21636Fnokiacom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 03:01:07 -0000 --_000_00DD6376EF844B588664515A9A21636Fnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support Andrew Sent from my iPhone On Jul 6, 2016, at 9:17 PM, Jim Guichard (jguichar) > wrote: Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-hierarchical= -06 as a WG document. The call for adoption will run for 2 weeks ending 7/2= 5/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG=92s decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_00DD6376EF844B588664515A9A21636Fnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Support

Andrew

Sent from my iPhone

On Jul 6, 2016, at 9:17 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:


This email serves a= s a call for WG adoption of draft-penno-sfc-hierarchical-06 as a WG documen= t. The call for adoption will run for 2 weeks ending 7/25/2016.

 

Please note that th= is is a call for adoption, and not a last call for content of the document.= Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and = use that document for resolving open issues and documenting the WG=92s deci= sions.

 

Please indicate whe= ther you support adoption for not, and if not why. Issues you have with the= current document itself can also be raised, but they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. 

 

Finally, now is also a good time to= poll for knowledge of any IPR that applies to this draft, in line with the= IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed a= s a document author please respond to this email (to the chairs) whether or= not you are aware of any relevant IPR.


Thanks!


SFC Chairs

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_00DD6376EF844B588664515A9A21636Fnokiacom_-- From nobody Wed Jul 6 20:02: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 6D98412B04A; Wed, 6 Jul 2016 20:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 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.426, 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 62S85CnVkeFa; Wed, 6 Jul 2016 20:02:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3E57812B062; Wed, 6 Jul 2016 20:02:47 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 877734DC6CDA7; Thu, 7 Jul 2016 11:02:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u6732VGR065034; Thu, 7 Jul 2016 11:02:31 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> To: "Jim Guichard (jguichar)" MIME-Version: 1.0 X-KeepSent: CEFB6AE4:1F43B0C1-48257FE9:0010811E; 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, 7 Jul 2016 11:02:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-07 11:02:31, Serialize complete at 2016-07-07 11:02:31 Content-Type: multipart/alternative; boundary="=_alternative 0010B64448257FE9_=" X-MAIL: mse01.zte.com.cn u6732VGR065034 Archived-At: Cc: sfc , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 03:02:49 -0000 This is a multipart message in MIME format. --=_alternative 0010B64448257FE9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IFN1cHBvcnQhIENvbXByZWhlbnNpdmUgY29udGVudC4NCg0KQlJzLA0KTGluZGEgV2FuZw0KDQoi c2ZjIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+INC009ogMjAxNi8wNy8wNiAyMToxNzo0MToNCg0K PiAiSmltIEd1aWNoYXJkIChqZ3VpY2hhcikiIDxqZ3VpY2hhckBjaXNjby5jb20+IA0KPiC3orz+ yMs6ICAic2ZjIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+DQo+IA0KPiAyMDE2LzA3LzA2IDIxOjE3 DQo+IA0KPiDK1bz+yMsNCj4gDQo+ICJzZmNAaWV0Zi5vcmciIDxzZmNAaWV0Zi5vcmc+LCANCj4g DQo+ILOty80NCj4gDQo+INb3zOINCj4gDQo+IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9m IGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2DQo+IA0KPiBEZWFyIFdHOg0KPiANCj4g VGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5u by1zZmMtDQo+IGhpZXJhcmNoaWNhbC0wNiBhcyBhIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBmb3Ig YWRvcHRpb24gd2lsbCBydW4gZm9yDQo+IDIgd2Vla3MgZW5kaW5nIDcvMjUvMjAxNi4NCj4gDQo+ IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEg bGFzdCBjYWxsIA0KPiBmb3IgY29udGVudCBvZiB0aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cg ZG9jdW1lbnQgc2ltcGx5IG1lYW5zIA0KPiB0aGF0IHRoZSBXRyB3aWxsIGZvY3VzIGl0cyBlZmZv cnRzIG9uIHRoYXQgcGFydGljdWxhciBkcmFmdCBnb2luZyANCj4gZm9yd2FyZCwgYW5kIHVzZSB0 aGF0IGRvY3VtZW50IGZvciByZXNvbHZpbmcgb3BlbiBpc3N1ZXMgYW5kIA0KPiBkb2N1bWVudGlu ZyB0aGUgV0ehr3MgZGVjaXNpb25zLg0KPiANCj4gUGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91 IHN1cHBvcnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlmIG5vdCANCj4gd2h5LiBJc3N1ZXMgeW91 IGhhdmUgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28gYmUgDQo+IHJh aXNlZCwgYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNlZCBpbiB0aGUgY29udGV4dCBvZiB3aGF0IHNo b3VsZCBiZSANCj4gY2hhbmdlZCBpbiB0aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVy IHRoYW4gYSBwcmUtY29uZGl0aW9uIA0KPiBmb3IgYWRvcHRpb24uIA0KPiANCj4gRmluYWxseSwg bm93IGlzIGFsc28gYSBnb29kIHRpbWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIg DQo+IHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQUiBkaXNj bG9zdXJlIA0KPiBvYmxpZ2F0aW9ucyBmb3IgV0cgcGFydGljaXBhbnRzIChzZWUgUkZDcyAzOTc5 LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IA0KPiBmb3IgbW9yZSBkZXRhaWxzKS4gSWYgeW91IGFyZSBs aXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3IgcGxlYXNlIA0KPiByZXNwb25kIHRvIHRoaXMgZW1h aWwgKHRvIHRoZSBjaGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgDQo+IG9mIGFu eSByZWxldmFudCBJUFIuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBTRkMgQ2hhaXJzX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlz dA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCg0K --=_alternative 0010B64448257FE9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO1N1cHBvcnQhIENvbXByZWhlbnNp dmUgY29udGVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkJScyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxpbmRh IFdhbmc8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtzZmMmcXVvdDsg Jmx0O3NmYy1ib3VuY2VzQGlldGYub3JnJmd0OyDQtNPaDQoyMDE2LzA3LzA2IDIxOjE3OjQxOjxi cj4NCjxicj4NCiZndDsgJnF1b3Q7SmltIEd1aWNoYXJkIChqZ3VpY2hhcikmcXVvdDsgJmx0O2pn dWljaGFyQGNpc2NvLmNvbSZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ILeivP7IyzogJm5ic3A7JnF1b3Q7c2ZjJnF1b3Q7ICZsdDtzZmMtYm91bmNlc0BpZXRmLm9y ZyZndDs8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAy MDE2LzA3LzA2IDIxOjE3PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsgJnF1b3Q7c2ZjQGlldGYub3JnJnF1b3Q7ICZsdDtzZmNAaWV0Zi5vcmcmZ3Q7LCA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM4jwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFtzZmNdIENhbGwg Zm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgRGVhciBXRzo8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGlzIGVtYWls IHNlcnZlcyBhcyBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy08YnI+ DQomZ3Q7IGhpZXJhcmNoaWNhbC0wNiBhcyBhIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBmb3IgYWRv cHRpb24gd2lsbCBydW4gZm9yPGJyPg0KJmd0OyAyIHdlZWtzIGVuZGluZyA3LzI1LzIwMTYuPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYSBjYWxs IGZvciBhZG9wdGlvbiwNCmFuZCBub3QgYSBsYXN0IGNhbGwgPGJyPg0KJmd0OyBmb3IgY29udGVu dCBvZiB0aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIDxi cj4NCiZndDsgdGhhdCB0aGUgV0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0IHBhcnRp Y3VsYXIgZHJhZnQgZ29pbmcNCjxicj4NCiZndDsgZm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRvY3Vt ZW50IGZvciByZXNvbHZpbmcgb3BlbiBpc3N1ZXMgYW5kIDxicj4NCiZndDsgZG9jdW1lbnRpbmcg dGhlIFdHoa9zIGRlY2lzaW9ucy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFBsZWFzZSBp bmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9uDQpmb3Igbm90LCBhbmQgaWYgbm90 IDxicj4NCiZndDsgd2h5LiBJc3N1ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVu dCBpdHNlbGYgY2FuIGFsc28gYmUNCjxicj4NCiZndDsgcmFpc2VkLCBidXQgdGhleSBzaG91bGQg YmUgcmFpc2VkIGluIHRoZSBjb250ZXh0IG9mIHdoYXQgc2hvdWxkIGJlDQo8YnI+DQomZ3Q7IGNo YW5nZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQsIHJhdGhlciB0aGFuIGEgcHJlLWNv bmRpdGlvbg0KPGJyPg0KJmd0OyBmb3IgYWRvcHRpb24uIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgRmluYWxseSwgbm93IGlzIGFsc28gYSBnb29kIHRpbWUgdG8gcG9sbCBmb3INCmtub3ds ZWRnZSBvZiBhbnkgSVBSIDxicj4NCiZndDsgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIGlu IGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1cmUgPGJyPg0KJmd0OyBvYmxpZ2F0aW9ucyBmb3Ig V0cgcGFydGljaXBhbnRzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4DQo8YnI+ DQomZ3Q7IGZvciBtb3JlIGRldGFpbHMpLiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50 IGF1dGhvciBwbGVhc2UgPGJyPg0KJmd0OyByZXNwb25kIHRvIHRoaXMgZW1haWwgKHRvIHRoZSBj aGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUNCjxicj4NCiZndDsgb2YgYW55IHJl bGV2YW50IElQUi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K Jmd0OyBUaGFua3MhPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N CiZndDsgU0ZDIENoYWlyc19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBzZmNAaWV0Zi5vcmc8 YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmM+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwv Zm9udD48L3R0Pg0K --=_alternative 0010B64448257FE9_=-- From nobody Wed Jul 6 20:06: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 A50A912D737; Wed, 6 Jul 2016 20:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 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.426, 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 oBlbH4s4mPJB; Wed, 6 Jul 2016 20:06:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0673B12B062; Wed, 6 Jul 2016 20:06:20 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 5A5CAC0E7B41F; Thu, 7 Jul 2016 11:06:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u67360Q5074155; Thu, 7 Jul 2016 11:06:00 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> To: "Jim Guichard (jguichar)" MIME-Version: 1.0 X-KeepSent: E02EA512:AEF080B2-48257FE9:00110AE4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: meng.wei2@zte.com.cn Date: Thu, 7 Jul 2016 11:06:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-07 11:06:00, Serialize complete at 2016-07-07 11:06:00 Content-Type: multipart/alternative; boundary="=_alternative 0011056E48257FE9_=" X-MAIL: mse01.zte.com.cn u67360Q5074155 Archived-At: Cc: sfc , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 03:06:22 -0000 This is a multipart message in MIME format. --=_alternative 0011056E48257FE9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydCENCg0KInNmYyIgPHNmYy1ib3VuY2VzQGlldGYub3JnPiDQtNPaIDIwMTYvMDcvMDYg MjE6MTc6NDE6DQoNCj4gIkppbSBHdWljaGFyZCAoamd1aWNoYXIpIiA8amd1aWNoYXJAY2lzY28u Y29tPiANCj4gt6K8/sjLOiAgInNmYyIgPHNmYy1ib3VuY2VzQGlldGYub3JnPg0KPiANCj4gMjAx Ni8wNy8wNiAyMToxNw0KPiANCj4gytW8/sjLDQo+IA0KPiAic2ZjQGlldGYub3JnIiA8c2ZjQGll dGYub3JnPiwgDQo+IA0KPiCzrcvNDQo+IA0KPiDW98ziDQo+IA0KPiBbc2ZjXSBDYWxsIGZvciBX RyBhZG9wdGlvbiBvZiBkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNg0KPiANCj4gRGVh ciBXRzoNCj4gDQo+IFRoaXMgZW1haWwgc2VydmVzIGFzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24g b2YgZHJhZnQtcGVubm8tc2ZjLQ0KPiBoaWVyYXJjaGljYWwtMDYgYXMgYSBXRyBkb2N1bWVudC4g VGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgcnVuIGZvcg0KPiAyIHdlZWtzIGVuZGluZyA3LzI1 LzIwMTYuDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYSBjYWxsIGZvciBhZG9wdGlv biwgYW5kIG5vdCBhIGxhc3QgY2FsbCANCj4gZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBB ZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyANCj4gdGhhdCB0aGUgV0cgd2lsbCBm b2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0IHBhcnRpY3VsYXIgZHJhZnQgZ29pbmcgDQo+IGZvcndh cmQsIGFuZCB1c2UgdGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFuZCAN Cj4gZG9jdW1lbnRpbmcgdGhlIFdHoa9zIGRlY2lzaW9ucy4NCj4gDQo+IFBsZWFzZSBpbmRpY2F0 ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9uIGZvciBub3QsIGFuZCBpZiBub3QgDQo+IHdo eS4gSXNzdWVzIHlvdSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNhbiBh bHNvIGJlIA0KPiByYWlzZWQsIGJ1dCB0aGV5IHNob3VsZCBiZSByYWlzZWQgaW4gdGhlIGNvbnRl eHQgb2Ygd2hhdCBzaG91bGQgYmUgDQo+IGNoYW5nZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZv cndhcmQsIHJhdGhlciB0aGFuIGEgcHJlLWNvbmRpdGlvbiANCj4gZm9yIGFkb3B0aW9uLiANCj4g DQo+IEZpbmFsbHksIG5vdyBpcyBhbHNvIGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yIGtub3dsZWRn ZSBvZiBhbnkgSVBSIA0KPiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgaW4gbGluZSB3aXRo IHRoZSBJUFIgZGlzY2xvc3VyZSANCj4gb2JsaWdhdGlvbnMgZm9yIFdHIHBhcnRpY2lwYW50cyAo c2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCANCj4gZm9yIG1vcmUgZGV0YWlscyku IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSANCj4gcmVzcG9u ZCB0byB0aGlzIGVtYWlsICh0byB0aGUgY2hhaXJzKSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3 YXJlIA0KPiBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gU0ZDIENo YWlyc19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNm YyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== --=_alternative 0011056E48257FE9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnQhPC9mb250Pg0KPGJyPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7c2ZjJnF1b3Q7ICZsdDtzZmMtYm91bmNlc0BpZXRmLm9y ZyZndDsg0LTT2g0KMjAxNi8wNy8wNiAyMToxNzo0MTo8YnI+DQo8YnI+DQomZ3Q7ICZxdW90O0pp bSBHdWljaGFyZCAoamd1aWNoYXIpJnF1b3Q7ICZsdDtqZ3VpY2hhckBjaXNjby5jb20mZ3Q7IDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyC3orz+yMs6ICZuYnNwOyZxdW90 O3NmYyZxdW90OyAmbHQ7c2ZjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyA8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMjAxNi8wNy8wNiAyMToxNzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IMrVvP7IyzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZxdW90O3NmY0BpZXRm Lm9yZyZxdW90OyAmbHQ7c2ZjQGlldGYub3JnJmd0OywgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgs63LzTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7INb3zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBbc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFm dC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyA8YnI+DQomZ3Q7IERlYXIgV0c6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBX RyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtPGJyPg0KJmd0OyBoaWVyYXJjaGljYWwtMDYg YXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgcnVuIGZvcjxicj4N CiZndDsgMiB3ZWVrcyBlbmRpbmcgNy8yNS8yMDE2LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24sDQphbmQgbm90 IGEgbGFzdCBjYWxsIDxicj4NCiZndDsgZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBBZG9w dGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyA8YnI+DQomZ3Q7IHRoYXQgdGhlIFdHIHdp bGwgZm9jdXMgaXRzIGVmZm9ydHMgb24gdGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nDQo8YnI+ DQomZ3Q7IGZvcndhcmQsIGFuZCB1c2UgdGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4g aXNzdWVzIGFuZCA8YnI+DQomZ3Q7IGRvY3VtZW50aW5nIHRoZSBXR6GvcyBkZWNpc2lvbnMuPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3Vw cG9ydCBhZG9wdGlvbg0KZm9yIG5vdCwgYW5kIGlmIG5vdCA8YnI+DQomZ3Q7IHdoeS4gSXNzdWVz IHlvdSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNhbiBhbHNvIGJlDQo8 YnI+DQomZ3Q7IHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNlZCBpbiB0aGUgY29udGV4 dCBvZiB3aGF0IHNob3VsZCBiZQ0KPGJyPg0KJmd0OyBjaGFuZ2VkIGluIHRoZSBkb2N1bWVudCBn b2luZyBmb3J3YXJkLCByYXRoZXIgdGhhbiBhIHByZS1jb25kaXRpb24NCjxicj4NCiZndDsgZm9y IGFkb3B0aW9uLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZpbmFsbHksIG5vdyBpcyBh bHNvIGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yDQprbm93bGVkZ2Ugb2YgYW55IElQUiA8YnI+DQom Z3Q7IHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQUiBkaXNj bG9zdXJlIDxicj4NCiZndDsgb2JsaWdhdGlvbnMgZm9yIFdHIHBhcnRpY2lwYW50cyAoc2VlIFJG Q3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OA0KPGJyPg0KJmd0OyBmb3IgbW9yZSBkZXRhaWxz KS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3IgcGxlYXNlIDxicj4NCiZn dDsgcmVzcG9uZCB0byB0aGlzIGVtYWlsICh0byB0aGUgY2hhaXJzKSB3aGV0aGVyIG9yIG5vdCB5 b3UgYXJlIGF3YXJlDQo8YnI+DQomZ3Q7IG9mIGFueSByZWxldmFudCBJUFIuPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhhbmtzITwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFNGQyBDaGFpcnNfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2ZjIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgc2ZjQGlldGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48 YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPjx0dD48Zm9u dCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2ZvbnQ+ PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 0011056E48257FE9_=-- From nobody Wed Jul 6 20:14: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 3A25712D597 for ; Wed, 6 Jul 2016 20:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDLdlD144N4S for ; Wed, 6 Jul 2016 20:13:49 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70E112D7A5 for ; Wed, 6 Jul 2016 20:13:48 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id t190so1963365pfb.3 for ; Wed, 06 Jul 2016 20:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=41CSG/XpmlYw9eeehQgkby2sdQz2fuXwfN2Kkl+klzo=; b=rnSL4cvCtZ7EoOw3XRKgobNcxBjVTEGScllzDajeJ4DUqM+2+cDR8m1RXr6Lf3Rt4B eNE+IOU4RJaZ3muzk2HSXMu1y5RyC+5+OG3N+7qNtUo60V8wM/eurPPYx2SspJujtGQj 3VVDTvD8ngEStjufARzDy0QM1kpnkU7Pzyy4+Ufy9Zu6ohKoYHRwOfpkBAMcGJMuWEu1 3rphTenlTIKlBQRJdpmRKTRRhsg7H7+OhFb4E+NCbXOnRRMwIdTJJzBT0dN1g2wDCZge JwYyU7SDIkemarN+eQyY9eQok8QQVQMuo2pUh4HetzShDLIHdiNiehQ1wcXfGeqpISp/ zkkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=41CSG/XpmlYw9eeehQgkby2sdQz2fuXwfN2Kkl+klzo=; b=H0XLA2TTeQtA0y6+NXRVwUPO2kRZfUsT/SyjbTjWsvBUdbyeEtCJevfyjb0G5rLy8A K7qKohobqaRBoPIL9sbZzIeRPxJaVuevXsotv4twp4REKfMHa1OFXc9ksCnGrolNvBgW UUZpM1RnU9M6FeYF7k3xuIG+1G7BjZPeJu3IcI/8796s+u4J9CcFaPsvm5VwbzaJofeh f+gBFwXGo0ijphkbeZkzT5mGP5mWlBgGWXgGxg7MRwuiXBKBGH+6qfRHTVakGOhheAQb OpkhZUbpzdc9mkuElW1K46KdrDCRgb1FPAJk2ID+6hqJSh92wGeCMk66lBmsOEi14B7f U4yw== X-Gm-Message-State: ALyK8tIFWdq6uju7LZGZmKR9rXEOqRuOpufHjkHKTuxOWwtUUnTILh1HbkIRAlB7Ys9+lQ== X-Received: by 10.98.222.130 with SMTP id h124mr1259326pfg.78.1467861228233; Wed, 06 Jul 2016 20:13:48 -0700 (PDT) Received: from [127.0.0.1] ([39.115.19.138]) by smtp.googlemail.com with ESMTPSA id bt5sm647054pac.47.2016.07.06.20.13.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2016 20:13:47 -0700 (PDT) To: sfc@ietf.org References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> From: VictorVu Message-ID: Date: Thu, 7 Jul 2016 12:13:50 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> Content-Type: multipart/alternative; boundary="------------2A42E9966CCE83A8C2252755" X-Antivirus: avast! (VPS 160706-1, 07/07/2016), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 03:13:51 -0000 This is a multi-part message in MIME format. --------------2A42E9966CCE83A8C2252755 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, As a co-author, I support the adoption of draft-dolson-sfc-hierarchical-06 as a WG document BR, On 7/6/16 10:17 PM, Jim Guichard (jguichar) wrote: > > Dear WG: > > > This email serves as a call for WG adoption of > draft-penno-sfc-hierarchical-06 as a WG document. The call for > adoption will run for 2 weeks ending 7/25/2016. > > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a WG document simply means that the > WG will focus its efforts on that particular draft going forward, and > use that document for resolving open issues and documenting the WG’s > decisions. > > Please indicate whether you support adoption for not, and if not why. > Issues you have with the current document itself can also be raised, > but they should be raised in the context of what should be changed in > the document going forward, rather than a pre-condition for adoption. > > Finally, now is also a good time to poll for knowledge of any IPR that > applies to this draft, in line with the IPR disclosure obligations for > WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as a document author please respond to this email > (to the chairs) whether or not you are aware of any relevant IPR. > > > Thanks! > > > SFC Chairs > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus --------------2A42E9966CCE83A8C2252755 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

As a co-author, I support the adoption of draft-dolson-sfc-hierarchical-06 as a WG document

BR,


On 7/6/16 10:17 PM, Jim Guichard (jguichar) wrote:

Dear WG:


This email serves as a call for WG adoption of draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption will run for 2 weeks ending 7/25/2016.

 

Please note that this is a call for adoption, and not a last call for content of the document. Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and use that document for resolving open issues and documenting the WG’s decisions.

 

Please indicate whether you support adoption for not, and if not why. Issues you have with the current document itself can also be raised, but they should be raised in the context of what should be changed in the document going forward, rather than a pre-condition for adoption. 

 

Finally, now is also a good time to poll for knowledge of any IPR that applies to this draft, in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this email (to the chairs) whether or not you are aware of any relevant IPR.


Thanks!


SFC Chairs



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



Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com


--------------2A42E9966CCE83A8C2252755-- From nobody Thu Jul 7 00:13: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 DC7BE12D0CA; Thu, 7 Jul 2016 00:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 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.426, 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 aUsjgfyW9p-Z; Thu, 7 Jul 2016 00:13:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E7E7012D52D; Thu, 7 Jul 2016 00:13:12 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 46FEB9450B08B; Thu, 7 Jul 2016 15:13:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u677CpLd071589; Thu, 7 Jul 2016 15:12:51 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: References: <1a80281212814b3fb29a9bb9092567b5@XCH-RCD-020.cisco.com> To: Dave Dolson MIME-Version: 1.0 X-KeepSent: E3915538:97F5B966-48257FE9:00131AA3; 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, 7 Jul 2016 15:13:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-07 15:12:51, Serialize complete at 2016-07-07 15:12:51 Content-Type: multipart/alternative; boundary="=_alternative 0027A2B648257FE9_=" X-MAIL: mse01.zte.com.cn u677CpLd071589 Archived-At: Cc: sfc , "Surendra Kumar \(smkumar\)" , Christian Koenning , "sfc@ietf.org" , "Bottorff, Paul" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 07:13:24 -0000 This is a multipart message in MIME format. --=_alternative 0027A2B648257FE9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBEYXZlLA0KDQogIFNGQy1QYWNrZXQgaXMgcmVhbGx5IGEgcHJhY3RpY2FsIGRyYWZ0IHdo aWNoIGd1aWRlcyB1cyBhYm91dCBob3cgdG8gDQpnZW5lcmF0ZSB0aGUgcmV2ZXJzZSBwYWNrZXQg ZHVyaW5nIG91ciBTRkMgZGVwbG95bWVudC4NCiAgQW5kIGhlcmUgSSBzdGlsbCBoYXZlIHNvbWUg Y29uZnVzaW9uLCBjb3VsZCB5b3UgcGxlYXNlIGhlbHAgbWUgb3V0Pw0KDQogIDEuICBTZWN0aW9u IDUuNC4yIGRlc2NyaWJpbmcgRmxpcCBQYXRoLUlEIGFuZCBJbmRleCBIaWdoIE9yZGVyIGJpdHMg aXMgDQpyZWFsbHkgYSBmZWFzaWJsZSBzb2x1dGlvbi4gDQogICAgICAgSSBndWVzcyBoZXJlIG1l YW5zIGZsaXAgUGF0aC1pZCBvciBTZXJ2aWNlIEluZGV4IGhpZ2ggb3JkZXIgYml0IA0KZWl0aGVy LCBub3QgZmxpcCBib3RoIFBhdGgtaWQgYW5kIFNlcnZpY2UgSW5kZXggaGlnaCBvcmRlciBiaXQs IHJpZ2h0PyANCiAgICAgICBBbmQgdGhlIFNQSSBtZW50aW9uZWQgaW4gdGhpcyBzZWN0aW9uIG1l YW5zIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIA0Kb3IgU2VydmljZSBQYXRoIEluZGV4PyBCZWNh dXNlIHRoaXMgc2VjdGlvbiBmaXJzdCBzYXlzICd0byBtYWtlDQogICAgICAgdXNlIG9mIGEgZGlm ZmVyZW50IFNlcnZpY2UgUGF0aCBJRCcsIHNvIEkgZ3Vlc3MgU1BJIGhlcmUgeW91IG1lYW4gDQpp cyBTZXJ2aWNlIFBhdGggSWRlbnRpZmllciwgYnV0IGxhdGVyIGl0IHRha2VzIDgtYml0IFNQSSA2 IGFuZCAxMzQgZm9yIA0KZXhhbXBsZS4NCg0KICAyLiAgIFNlY3Rpb24gNS4yIHVzaW5nIHR3byBk aWZmZXJlbnQgc29sdXRpb25zIHRvIHJlcXVlc3QgU0ZGIA0KY29vcGVyYXRpb24sIG9uZSBpcyBP QU0gcGFja2V0IGFuZCB0aGUgb3RoZXIgb25lIGlzIFJlc2VydmVkIGJpdC4gDQogICAgICAgIFdl IHJlYWxseSBsaWtlIHRoZSBSZXNlcnZlZCBiaXQgc29sdXRpb24sIGJ1dCBpdCBtZW50aW9ucyBh biBpc3N1ZSANCid0aGUgbWV0YWRhdGEgaW4gdGhlIG9yaWdpbmFsIHBhY2tldCBtaWdodCBiZSBv dmVyd3JpdHRlbiBieSBTRnMgb3IgU0ZGcycuDQogICAgICAgIEkgY2Fubm90IHVuZGVyc3RhbmQg d2hhdCB0aGUgaXNzdWUgYWN0dWFsbHkgaXMgPw0KDQogIDMuICAgVGhpcyBkcmFmdCBhaW1zIGhv dyBTRnMgZ2VuZXJhdGUgcmV2ZXJzZSBwYWNrZXRzLiBCdXQgaW4gZmFjdCwgDQpzZWN0aW9uIDUu MyBhbmQgc2VjdGlvbiA1LjQgIGNhbiBiZSBhbHNvIHVzZWQgYXMgYSBzeW5jaHJvbm91cyBtZWNo YW5pc20gDQogICAgICAgIGJldHdlZW4gbWlycm9yZWQgY2xhc3NpZmllcnMuDQoNCg0KIE1hbnkg dGhhbmtzOikNCg0KQlJzLA0KTGluZGEgV2FuZw0KDQoNCg0KDQoic2ZjIiA8c2ZjLWJvdW5jZXNA aWV0Zi5vcmc+INC009ogMjAxNi8wNS8yNyAwNToyODozNToNCg0KPiBEYXZlIERvbHNvbiA8ZGRv bHNvbkBzYW5kdmluZS5jb20+IA0KPiC3orz+yMs6ICAic2ZjIiA8c2ZjLWJvdW5jZXNAaWV0Zi5v cmc+DQo+IA0KPiAyMDE2LzA1LzI3IDA1OjI4DQo+IA0KPiDK1bz+yMsNCj4gDQo+ICJTdXJlbmRy YSBLdW1hciAoc21rdW1hcikiIDxzbWt1bWFyQGNpc2NvLmNvbT4sICJCb3R0b3JmZiwgUGF1bCIg DQo+IDxwYXVsLmJvdHRvcmZmQGhwZS5jb20+LCBDaHJpc3RpYW4gS29lbm5pbmcgPEMuS29lbm5p bmdARjUuY29tPiwgDQo+ICJzZmNAaWV0Zi5vcmciIDxzZmNAaWV0Zi5vcmc+LCANCj4gDQo+ILOt y80NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbc2ZjXSBTZXJ2aWNlIFBhdGggSWRlbnRpZmllciAo U1BJKSBhbmQgc3ltbWV0cnkNCj4gDQo+IFRoaXMgcXVlc3Rpb24gb2YgdGhlIHJldmVyc2FsIHBy b2JsZW0gKGFuZCBwYWNrZXQgaW5qZWN0aW9uIGluIA0KPiBnZW5lcmFsKSBrZWVwcyBjb21pbmcg dXAuDQo+IA0KPiBQbGVhc2UgcmVhZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt cGVubm8tc2ZjLXBhY2tldC0wMw0KPiBhbmQgcHJvdmlkZSBmZWVkLWJhY2suDQo+IA0KPiBJbiBw YXJ0aWN1bGFyLCB2YXJpb3VzIG1ldGhvZHMgYXJlIGRpc2N1c3NlZCB1c2luZyAoYSkgT0FNIHBh Y2tldHMsIA0KPiAoYikgcmV2ZXJzYWwgaW5mb3JtYXRpb24gaW4gbWV0YS1kYXRhLCAoYykgYWxn b3JpdGhtaWMgYXBwcm9hY2hlcyB0bw0KPiBjb21wdXRpbmcgcmV2ZXJzZWQgZmllbGRzLg0KPiAN Cj4gTGV0IHVzIGtub3cgd2hhdCB3b3JrcyBmb3IgeW91Lg0KPiANCj4gLURhdmUNCj4gDQo+IA0K PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1 cmVuZHJhIEt1bWFyIA0KKHNta3VtYXIpDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMjYsIDIwMTYg Mjo0NiBQTQ0KPiBUbzogQm90dG9yZmYsIFBhdWw7IENocmlzdGlhbiBLb2VubmluZzsgc2ZjQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIFBhdGggSWRlbnRpZmllciAoU1BJ KSBhbmQgc3ltbWV0cnkNCj4gDQo+IEhpIFBhdWwsDQo+IA0KPiBJbiBnZW5lcmFsIEkgY2FuIHNl ZSBob3cgaGF2aW5nIHR3byBTZXJ2aWNlIGhlYWRlcnMgbWF5IGhlbHAuDQo+IEluIHByYWN0aWNl IGhvd2V2ZXIsIGEgc2luZ2xlIG9uZSB3aXRoIGhpZ2gtb3JkZXIgYml0IA0KPiBkaWZmZXJlbnRp YXRpbmcgdGhlIGZvcndhcmQvcmV2ZXJzZSBuYW1lIHNwYWNlIHdvcmtzIHdlbGwgd2hlcmUgYmkt DQo+IGRpcmVjdGlvbmFsIGJlaGF2aW9yIGlzIG5lZWRlZCBhbmQgaGFzIGZvciB1cy4gSSBzdXBw b3J0IHVzaW5nIHRoZSANCj4gaGlnaC1vcmRlciBiaXQgYXMgYW4gaW1wbGVtZW50YXRpb24gZGV0 YWlsLg0KPiANCj4gT25lIG9wdGlvbiB3aXRoIE1ELVRZUEUyIG1heSBiZSB0byB1c2UgVExWcyB0 byBjYXJyeSB0aGUgb3RoZXIgDQo+IHNlcnZpY2UtaGVhZGVyLCB0aGF0IGFjaGlldmVzIHRoZSBk ZXNpcmVkIGVmZmVjdCB3aGlsZSBub3QgdGF4aW5nIA0KPiBhbGwgaW1wbGVtZW50YXRpb25zLg0K PiANCj4gU3VyZW5kcmEuDQo+IA0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJvdHRvcmZmLCBQYXVsDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkg MjYsIDIwMTYgMTE6MDIgQU0NCj4gVG86IENocmlzdGlhbiBLb2VubmluZyA8Qy5Lb2VubmluZ0BG NS5jb20+OyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgUGF0aCBJ ZGVudGlmaWVyIChTUEkpIGFuZCBzeW1tZXRyeQ0KPiANCj4gSGkgQ2hyaXN0aWFuOg0KPiANCj4g QSB2ZXJ5IGdvb2QgcXVlc3Rpb24uDQo+IA0KPiBJTUhPIHRoZSBTUEkgY2Fuoa90IGJlIGJpLWRp cmVjdGlvbmFsIGJlY2F1c2UgdGhlIGZvcndhcmRpbmcgDQo+IGRpcmVjdGlvbiB3b3VsZCBiZSBh bWJpZ3VvdXMgZm9yIHNpbmdsZSBhcm1lZCBTRnMuDQo+IA0KPiBUaGUgcmV2ZXJzYWwgcHJvYmxl bSBwb2ludHMgb3V0IGEgYmFzaWMgZGVmaWNpZW5jeSBvZiB0aGUgU1BJK1NJIE5TSA0KPiBmaWVs ZHMuIFRoZXNlIGZpZWxkcyBmb3JtIHRoZSBzZXJ2ZXIgbGF5ZXIgbmV0d29yayBhZGRyZXNzIChu b3QgdGhlIA0KPiB0cmFuc3BvcnQgbGF5ZXIgYWRkcmVzcykuIFdoYXQgd2UgbGFjayBpcyBhIHdh eSB0byBlbmNvZGUgdGhlIA0KPiByZXZlcnNlIGFkZHJlc3MuIA0KPiANCj4gVGhlIGRpcmVjdCBt ZXRob2QgZm9yIGhhbmRsaW5nIGZvcndhcmQgYW5kIGJhY2t3YXJkIGFkZHJlc3NpbmcgaXMgdG8N Cj4gZW5jb2RlIGJvdGggYSBmb3J3YXJkIGFuZCByZXZlcnNlIHBhdGggaW4gdGhlIE5TSCBoZWFk ZXIgKFNQSUYvDQo+IFNQSVIpLiBUaGlzIHdvdWxkIGJlIHNpbWlsYXIgdG8gRXRoZXJuZXQgREEv U0Egb3IgSVAgU0lQL1NJUC4gU3VjaCANCj4gYW4gZW5jb2Rpbmcgd291bGQgYmUgdGhlIG1vc3Qg ZmxleGlibGUgd2F5IHRvIGJ1aWxkIHRoZSBOU0ggaGVhZGVyLCANCj4gaG93ZXZlciBmb3IgYSBt b3JlIHNwYWNlIGVmZmljaWVudCBtZXRob2Qgd2hpY2ggb2ZmZXJzIHRoZSBtaW5pbXVtIA0KPiBt b2RpZmljYXRpb24gdG8gdGhlIGV4aXN0aW5nIE5TSCBmaWVsZHMgd2UgaGF2ZSBoYWQgc3VjY2Vz cyBlbmNvZGluZw0KPiBhIHJldmVyc2UgYWRkcmVzcyBieSByZXNlcnZpbmcgdGhlIGhpZ2ggb3Jk ZXIgYml0IG9mIHRoZSBTUEkgdG8gDQo+IGRlc2lnbmF0ZSB0aGUgcmV2ZXJzZSBhZGRyZXNzLiBT byBpbiB0aGlzIG1ldGhvZCB0aGUgU1BJRiBhbHdheXMgaGFzDQo+IGhpZ2ggb3JkZXIgYml0IDAg YW5kIHRoZSBTUElSIGFsd2F5cyBoYXMgaGlnaCBvcmRlciBiaXQgMS4gQW4gU0Ygb3IgDQo+IE9B TSB3aGljaCBuZWVkcyB0byBzZW5kIGFsb25nIHRoZSByZXZlcnNlIHBhdGggY2FuIGFsd2F5cyBm b3JtIHRoZSANCj4gcmV2ZXJzZSBhZGRyZXNzIGJ5IGZsaXBwaW5nIHRoZSBoaWdoIG9yZGVyIGJp dCBvZiB0aGUgU1BJLg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gUGF1bCANCj4gDQo+IEZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEtv ZW5uaW5nDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMjo0OSBQTQ0KPiBUbzogc2Zj QGlldGYub3JnDQo+IFN1YmplY3Q6IFtzZmNdIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIChTUEkp IGFuZCBzeW1tZXRyeQ0KPiANCj4gR29vZCBFdmVuaW5nLA0KPiANCj4gbG9va2luZyBhdCBSRkMg NzY2NSANCj4gU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1cmUNCj4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2NjUNCj4gDQo+IHRoZXJlIGlzIGEgY2xl YXIgZGVmaW5pdGlvbiBvZiBjaGFpbiBzeW1ldHJ5DQo+IA0KPiAiDQo+IDIuMi4gIFNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW4gU3ltbWV0cnkNCj4gDQo+ICAgIFNGQ3MgbWF5IGJlIHVuaWRpcmVjdGlv bmFsIG9yIGJpZGlyZWN0aW9uYWwuICBBIHVuaWRpcmVjdGlvbmFsIFNGQw0KPiAgICByZXF1aXJl cyB0aGF0IHRyYWZmaWMgYmUgZm9yd2FyZGVkIHRocm91Z2ggdGhlIG9yZGVyZWQgU0ZzIGluIG9u ZQ0KPiAgICBkaXJlY3Rpb24gKHNmMSAtPiBzZjIgLT4gc2YzKSwgd2hlcmVhcyBhIGJpZGlyZWN0 aW9uYWwgU0ZDIHJlcXVpcmVzIGENCj4gICAgc3ltbWV0cmljIHBhdGggKHNmMSAtPiBzZjIgLT4g c2YzIGFuZCBzZjMgLT4gc2YyIC0+IHNmMSksIGFuZCBpbg0KPiAgICB3aGljaCB0aGUgU0YgaW5z dGFuY2VzIGFyZSB0aGUgc2FtZSBpbiBvcHBvc2l0ZSBkaXJlY3Rpb25zLiAgQSBoeWJyaWQNCj4g ICAgU0ZDIGhhcyBhdHRyaWJ1dGVzIG9mIGJvdGggdW5pZGlyZWN0aW9uYWwgYW5kIGJpZGlyZWN0 aW9uYWwgU0ZDczsNCj4gICAgdGhhdCBpcyB0byBzYXkgc29tZSBTRnMgcmVxdWlyZSBzeW1tZXRy aWMgdHJhZmZpYywgd2hlcmVhcyBvdGhlciBTRnMNCj4gICAgZG8gbm90IHByb2Nlc3MgcmV2ZXJz ZSB0cmFmZmljIG9yIGFyZSBpbmRlcGVuZGVudCBvZiB0aGUNCj4gICAgY29ycmVzcG9uZGluZyBm b3J3YXJkIHRyYWZmaWMuDQo+IA0KPiAgICAuLi4NCj4gDQo+ICAgICBGdXJ0aGVyLCB0aGVyZSBh cmUgc3RhdGUgdHJhZGUtb2ZmcyBpbiBzeW1tZXRyeS4gIFN5bW1ldHJ5IG1heSBiZQ0KPiAgICBy ZWFsaXplZCBpbiBzZXZlcmFsIHdheXMgZGVwZW5kaW5nIG9uIHRoZSBTRkYgYW5kIGNsYXNzaWZp ZXINCj4gICAgZnVuY3Rpb25hbGl0eS4gIEluIHNvbWUgY2FzZXMsICJtaXJyb3JlZCIgY2xhc3Np ZmljYXRpb24gKGkuZS4sIGZyb20NCj4gICAgU291cmNlIHRvIERlc3RpbmF0aW9uIGFuZCBmcm9t IERlc3RpbmF0aW9uIHRvIFNvdXJjZSkgcG9saWN5IG1heSBiZQ0KPiAgICBkZXBsb3llZCwgd2hl cmVhcyBpbiBvdGhlcnMgc2hhcmVkIHN0YXRlIGJldHdlZW4gY2xhc3NpZmllcnMgbWF5IGJlDQo+ ICAgIHVzZWQgdG8gZW5zdXJlIHRoYXQgc3ltbWV0cmljIGZsb3dzIGFyZSBjb3JyZWN0bHkgaWRl bnRpZmllZCwgdGhlbg0KPiAgICBzdGVlcmVkIGFsb25nIHRoZSByZXF1aXJlZCBTRlAuICBBdCBh IGhpZ2ggbGV2ZWwsIHRoZXJlIGFyZSB2YXJpb3VzDQo+ICAgIGNvbW1vbiBjYXNlcy4gIEluIGEg bm9uLWV4aGF1c3RpdmUgd2F5LCB0aGVyZSBjYW4gYmUgZm9yIGV4YW1wbGU6DQo+IA0KPiAgICBv ICBBIHNpbmdsZSBjbGFzc2lmaWVyIChvciBhIHNtYWxsIG51bWJlciBvZiBjbGFzc2lmaWVycyks IGluIHdoaWNoDQo+ICAgICAgIGNhc2UgYm90aCBpbmNvbWluZyBhbmQgb3V0Z29pbmcgZmxvd3Mg Y291bGQgYmUgcmVjb2duaXplZCBhdCB0aGUNCj4gICAgICAgc2FtZSBjbGFzc2lmaWVyLCBzbyB0 aGUgc3luY2hyb25pemF0aW9uIHdvdWxkIGJlIGZlYXNpYmxlIGJ5DQo+ICAgICAgIGludGVybmFs IG1lY2hhbmlzbXMgaW50ZXJuYWwgdG8gdGhlIGNsYXNzaWZpZXIuDQo+IA0KPiAgICBvICBTdGF0 ZWZ1bCBjbGFzc2lmaWVycyB3aGVyZSBzZXZlcmFsIGNsYXNzaWZpZXJzIG1heSBiZSBjbHVzdGVy ZWQNCj4gICAgICAgYW5kIHNoYXJlIHN0YXRlLg0KPiANCj4gICAgbyAgRnVsbHkgZGlzdHJpYnV0 ZWQgY2xhc3NpZmllcnMsIHdoZXJlIHN5bmNocm9uaXphdGlvbiBuZWVkcyB0byBiZQ0KPiAgICAg ICBwcm92aWRlZCB0aHJvdWdoIHVuc3BlY2lmaWVkIG1lYW5zLg0KPiANCj4gICAgbyAgQSBjbGFz c2lmaWVyIHRoYXQgbGVhcm5zIHN0YXRlIGZyb20gdGhlIGVncmVzcyBwYWNrZXRzL2Zsb3dzIHRo YXQNCj4gICAgICAgaXMgdGhlbiB1c2VkIHRvIHByb3ZpZGUgc3RhdGUgZm9yIHRoZSByZXR1cm4g cGFja2V0cy9mbG93Lg0KPiANCj4gICAgbyAgU3ltbWV0cnkgbWF5IGFsc28gYmUgcHJvdmlkZWQg Ynkgc3RhdGVmdWwgZm9yd2FyZGluZyBsb2dpYyBpbiB0aGUNCj4gICAgICAgU0ZGIGluIHNvbWUg aW1wbGVtZW50YXRpb25zLg0KPiANCj4gICAgVGhpcyBpcyBhIG5vbi1jb21wcmVoZW5zaXZlIGxp c3Qgb2YgY29tbW9uIGNhc2VzLiAiDQo+IA0KPiANCj4gSG93ZXZlciwgd2hlbiBsb29raW5nIGF0 IHRoaXMgdG9nZXRoZXIgd2l0aCANCj4gTmV0d29yayBTZXJ2aWNlIEhlYWRlcg0KPiBkcmFmdC1p ZXRmLXNmYy1uc2gtMDQudHh0DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXNmYy1uc2gtMDQNCj4gDQo+IDMuMy4gIFNlcnZpY2UgUGF0aCBIZWFkZXINCj4gDQo+ICIN Cj4gICAgU2VydmljZSBQYXRoIElkZW50aWZpZXIgKFNQSSk6IGlkZW50aWZpZXMgYSBzZXJ2aWNl IHBhdGguDQo+ICAgIFBhcnRpY2lwYXRpbmcgbm9kZXMgTVVTVCB1c2UgdGhpcyBpZGVudGlmaWVy IGZvciBTZXJ2aWNlIEZ1bmN0aW9uDQo+ICAgIFBhdGggc2VsZWN0aW9uLg0KPiAiDQo+IA0KPiB0 aGVyZSBpcyBubyBub3Rpb24gb2Ygc3ltbWV0cnkuIA0KPiANCj4gDQo+IENhbiB5b3UgcGxlYXNl IGNvbmZpcm0gdGhhdCBhIGJpZGlyZWN0aW9uYWwgU2VydmljZSBGdW5jdGlvbiBDaGFpbiANCj4g d2lsbCBiZSByZXByZXNlbnRlZCBieSBvbmUgc2luZ2xlIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVy LCBpbmdyZXNzIA0KPiBzeW1tZXRyaWMgdG8gZWdyZXNzID8NCj4gDQo+IA0KPiBQbGVhc2UgYWxs b3cgdXMgdG8gY2xhcmlmeSB0aGlzLg0KPiANCj4gTWFueSBUaGFua3MNCj4gDQo+IENocmlzdGlh biBLb2VubmluZw0KPiAtLQ0KPiBGNSBOZXR3b3JrcyBJbmMuDQo+IGNocmlzdGlhbkBmNS5jb20N Cj4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNm YyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== --=_alternative 0027A2B648257FE9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkRlYXIgRGF2ZSw8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPiZuYnNwOyBTRkMtUGFja2V0IGlzIHJlYWxseSBh IHByYWN0aWNhbA0KZHJhZnQgd2hpY2ggZ3VpZGVzIHVzIGFib3V0IGhvdyB0byBnZW5lcmF0ZSB0 aGUgcmV2ZXJzZSBwYWNrZXQgZHVyaW5nIG91cg0KU0ZDIGRlcGxveW1lbnQuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgQW5kIGhlcmUgSSBzdGlsbCBoYXZl IHNvbWUgY29uZnVzaW9uLA0KY291bGQgeW91IHBsZWFzZSBoZWxwIG1lIG91dD88L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAxLiAmbmJzcDtTZWN0 aW9uIDUuNC4yIGRlc2NyaWJpbmcNCkZsaXAgUGF0aC1JRCBhbmQgSW5kZXggSGlnaCBPcmRlciBi aXRzIGlzIHJlYWxseSBhIGZlYXNpYmxlIHNvbHV0aW9uLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0kgZ3Vlc3MgaGVy ZQ0KbWVhbnMgZmxpcCBQYXRoLWlkIDxiPm9yPC9iPiBTZXJ2aWNlIEluZGV4IGhpZ2ggb3JkZXIg Yml0IGVpdGhlciwgbm90IGZsaXANCmJvdGggUGF0aC1pZCBhbmQgU2VydmljZSBJbmRleCBoaWdo IG9yZGVyIGJpdCwgcmlnaHQ/IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QW5kIHRoZSBTUEkNCm1lbnRpb25lZCBpbiB0 aGlzIHNlY3Rpb24gbWVhbnMgU2VydmljZSBQYXRoIElkZW50aWZpZXIgb3IgU2VydmljZSBQYXRo DQpJbmRleD8gQmVjYXVzZSB0aGlzIHNlY3Rpb24gZmlyc3Qgc2F5cyAndG8gbWFrZTwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7dXNlIG9mIGEgZGlmZmVyZW50DQpTZXJ2aWNlIFBhdGggSUQnLCBzbyBJIGd1ZXNzIFNQSSBo ZXJlIHlvdSBtZWFuIGlzIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVyLA0KYnV0IGxhdGVyIGl0IHRh a2VzIDgtYml0IFNQSSA2IGFuZCAxMzQgZm9yIGV4YW1wbGUuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgMi4gJm5ic3A7IFNlY3Rpb24gNS4yIHVz aW5nIHR3bw0KZGlmZmVyZW50IHNvbHV0aW9ucyB0byByZXF1ZXN0IFNGRiBjb29wZXJhdGlvbiwg b25lIGlzIE9BTSBwYWNrZXQgYW5kIHRoZQ0Kb3RoZXIgb25lIGlzIFJlc2VydmVkIGJpdC4gPC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgV2UgcmVhbGx5IGxpa2UNCnRoZSBSZXNlcnZlZCBiaXQgc29sdXRpb24sIGJ1dCBp dCBtZW50aW9ucyBhbiBpc3N1ZSAndGhlIG1ldGFkYXRhIGluIHRoZQ0Kb3JpZ2luYWwgcGFja2V0 IG1pZ2h0IGJlIG92ZXJ3cml0dGVuIGJ5IFNGcyBvciBTRkZzJy48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIGNhbm5v dCB1bmRlcnN0YW5kDQp3aGF0IHRoZSBpc3N1ZSBhY3R1YWxseSBpcyA/PC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgMy4gJm5ic3A7IFRoaXMgZHJh ZnQgYWltcyBob3cgU0ZzDQpnZW5lcmF0ZSByZXZlcnNlIHBhY2tldHMuIEJ1dCBpbiBmYWN0LCBz ZWN0aW9uIDUuMyBhbmQgc2VjdGlvbiA1LjQgJm5ic3A7Y2FuDQpiZSBhbHNvIHVzZWQgYXMgYSBz eW5jaHJvbm91cyBtZWNoYW5pc20gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxp YnJpIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmV0d2VlbiBtaXJyb3JlZA0KY2xhc3Np ZmllcnMuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJp Ij4mbmJzcDtNYW55IHRoYW5rczopPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJDYWxpYnJpIj5CUnMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj5M aW5kYSBXYW5nPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+JnF1b3Q7c2ZjJnF1b3Q7ICZsdDtzZmMtYm91bmNlc0BpZXRmLm9yZyZndDsg0LTT2g0K MjAxNi8wNS8yNyAwNToyODozNTo8YnI+DQo8YnI+DQomZ3Q7IERhdmUgRG9sc29uICZsdDtkZG9s c29uQHNhbmR2aW5lLmNvbSZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ILeivP7IyzogJm5ic3A7JnF1b3Q7c2ZjJnF1b3Q7ICZsdDtzZmMtYm91bmNlc0BpZXRmLm9y ZyZndDs8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAy MDE2LzA1LzI3IDA1OjI4PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsgJnF1b3Q7U3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpJnF1b3Q7ICZsdDtzbWt1bWFy QGNpc2NvLmNvbSZndDssICZxdW90O0JvdHRvcmZmLA0KUGF1bCZxdW90OyA8YnI+DQomZ3Q7ICZs dDtwYXVsLmJvdHRvcmZmQGhwZS5jb20mZ3Q7LCBDaHJpc3RpYW4gS29lbm5pbmcgJmx0O0MuS29l bm5pbmdARjUuY29tJmd0OywNCjxicj4NCiZndDsgJnF1b3Q7c2ZjQGlldGYub3JnJnF1b3Q7ICZs dDtzZmNAaWV0Zi5vcmcmZ3Q7LCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgPGJyPg0KJmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IDxicj4NCiZndDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8 YnI+DQomZ3Q7IFJlOiBbc2ZjXSBTZXJ2aWNlIFBhdGggSWRlbnRpZmllciAoU1BJKSBhbmQgc3lt bWV0cnk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBU aGlzIHF1ZXN0aW9uIG9mIHRoZSByZXZlcnNhbCBwcm9ibGVtIChhbmQgcGFja2V0IGluamVjdGlv biBpbiA8YnI+DQomZ3Q7IGdlbmVyYWwpIGtlZXBzIGNvbWluZyB1cC48L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IFBsZWFzZSByZWFkIDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZW5uby1zZmMtcGFja2V0LTAzIj48dHQ+PGZvbnQgc2l6 ZT0yPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZW5uby1zZmMtcGFja2V0LTAz PC9mb250PjwvdHQ+PC9hPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBhbmQgcHJvdmlkZSBm ZWVkLWJhY2suPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJbiBwYXJ0aWN1bGFyLCB2YXJp b3VzIG1ldGhvZHMgYXJlIGRpc2N1c3NlZA0KdXNpbmcgKGEpIE9BTSBwYWNrZXRzLCA8YnI+DQom Z3Q7IChiKSByZXZlcnNhbCBpbmZvcm1hdGlvbiBpbiBtZXRhLWRhdGEsIChjKSBhbGdvcml0aG1p YyBhcHByb2FjaGVzDQp0bzxicj4NCiZndDsgY29tcHV0aW5nIHJldmVyc2VkIGZpZWxkcy48L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IExldCB1cyBrbm93IHdoYXQgd29ya3MgZm9yIHlvdS48 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC1EYXZlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRnJvbTog c2ZjIFs8L2ZvbnQ+PC90dD48YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPjx0 dD48Zm9udCBzaXplPTI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9mb250PjwvdHQ+PC9h Pjx0dD48Zm9udCBzaXplPTI+XQ0KT24gQmVoYWxmIE9mIFN1cmVuZHJhIEt1bWFyIChzbWt1bWFy KTxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIE1heSAyNiwgMjAxNiAyOjQ2IFBNPGJyPg0KJmd0 OyBUbzogQm90dG9yZmYsIFBhdWw7IENocmlzdGlhbiBLb2VubmluZzsgc2ZjQGlldGYub3JnPGJy Pg0KJmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBQYXRoIElkZW50aWZpZXIgKFNQSSkg YW5kIHN5bW1ldHJ5PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBIaSBQYXVsLDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSW4gZ2VuZXJhbCBJIGNhbiBzZWUgaG93IGhhdmluZyB0d28g U2VydmljZSBoZWFkZXJzDQptYXkgaGVscC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgSW4gcHJhY3RpY2UgaG93ZXZlciwgYSBzaW5nbGUgb25lIHdpdGggaGlnaC1vcmRl cg0KYml0IDxicj4NCiZndDsgZGlmZmVyZW50aWF0aW5nIHRoZSBmb3J3YXJkL3JldmVyc2UgbmFt ZSBzcGFjZSB3b3JrcyB3ZWxsIHdoZXJlIGJpLTxicj4NCiZndDsgZGlyZWN0aW9uYWwgYmVoYXZp b3IgaXMgbmVlZGVkIGFuZCBoYXMgZm9yIHVzLiBJIHN1cHBvcnQgdXNpbmcgdGhlDQo8YnI+DQom Z3Q7IGhpZ2gtb3JkZXIgYml0IGFzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC48L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IE9uZSBvcHRpb24gd2l0aCBNRC1UWVBFMiBtYXkgYmUgdG8gdXNl IFRMVnMgdG8NCmNhcnJ5IHRoZSBvdGhlciA8YnI+DQomZ3Q7IHNlcnZpY2UtaGVhZGVyLCB0aGF0 IGFjaGlldmVzIHRoZSBkZXNpcmVkIGVmZmVjdCB3aGlsZSBub3QgdGF4aW5nDQo8YnI+DQomZ3Q7 IGFsbCBpbXBsZW1lbnRhdGlvbnMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTdXJlbmRy YS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZyb206IHNmYyBbPC9mb250PjwvdHQ+PGEg aHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPl0N Ck9uIEJlaGFsZiBPZiBCb3R0b3JmZiwgUGF1bDxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIE1h eSAyNiwgMjAxNiAxMTowMiBBTTxicj4NCiZndDsgVG86IENocmlzdGlhbiBLb2VubmluZyAmbHQ7 Qy5Lb2VubmluZ0BGNS5jb20mZ3Q7OyBzZmNAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJl OiBbc2ZjXSBTZXJ2aWNlIFBhdGggSWRlbnRpZmllciAoU1BJKSBhbmQgc3ltbWV0cnk8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEhpIENocmlzdGlhbjo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IEEgdmVyeSBnb29kIHF1ZXN0aW9uLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg SU1ITyB0aGUgU1BJIGNhbqGvdCBiZSBiaS1kaXJlY3Rpb25hbCBiZWNhdXNlDQp0aGUgZm9yd2Fy ZGluZyA8YnI+DQomZ3Q7IGRpcmVjdGlvbiB3b3VsZCBiZSBhbWJpZ3VvdXMgZm9yIHNpbmdsZSBh cm1lZCBTRnMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZn dDsgVGhlIHJldmVyc2FsIHByb2JsZW0gcG9pbnRzIG91dCBhIGJhc2ljIGRlZmljaWVuY3kgb2Yg dGhlIFNQSStTSSBOU0g8YnI+DQomZ3Q7IGZpZWxkcy4gVGhlc2UgZmllbGRzIGZvcm0gdGhlIHNl cnZlciBsYXllciBuZXR3b3JrIGFkZHJlc3MgKG5vdCB0aGUNCjxicj4NCiZndDsgdHJhbnNwb3J0 IGxheWVyIGFkZHJlc3MpLiBXaGF0IHdlIGxhY2sgaXMgYSB3YXkgdG8gZW5jb2RlIHRoZSA8YnI+ DQomZ3Q7IHJldmVyc2UgYWRkcmVzcy4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGUg ZGlyZWN0IG1ldGhvZCBmb3IgaGFuZGxpbmcgZm9yd2FyZCBhbmQgYmFja3dhcmQNCmFkZHJlc3Np bmcgaXMgdG88YnI+DQomZ3Q7IGVuY29kZSBib3RoIGEgZm9yd2FyZCBhbmQgcmV2ZXJzZSBwYXRo IGluIHRoZSBOU0ggaGVhZGVyIChTUElGLzxicj4NCiZndDsgU1BJUikuIFRoaXMgd291bGQgYmUg c2ltaWxhciB0byBFdGhlcm5ldCBEQS9TQSBvciBJUCBTSVAvU0lQLiBTdWNoDQo8YnI+DQomZ3Q7 IGFuIGVuY29kaW5nIHdvdWxkIGJlIHRoZSBtb3N0IGZsZXhpYmxlIHdheSB0byBidWlsZCB0aGUg TlNIIGhlYWRlciwNCjxicj4NCiZndDsgaG93ZXZlciBmb3IgYSBtb3JlIHNwYWNlIGVmZmljaWVu dCBtZXRob2Qgd2hpY2ggb2ZmZXJzIHRoZSBtaW5pbXVtDQo8YnI+DQomZ3Q7IG1vZGlmaWNhdGlv biB0byB0aGUgZXhpc3RpbmcgTlNIIGZpZWxkcyB3ZSBoYXZlIGhhZCBzdWNjZXNzIGVuY29kaW5n PGJyPg0KJmd0OyBhIHJldmVyc2UgYWRkcmVzcyBieSByZXNlcnZpbmcgdGhlIGhpZ2ggb3JkZXIg Yml0IG9mIHRoZSBTUEkgdG8gPGJyPg0KJmd0OyBkZXNpZ25hdGUgdGhlIHJldmVyc2UgYWRkcmVz cy4gU28gaW4gdGhpcyBtZXRob2QgdGhlIFNQSUYgYWx3YXlzIGhhczxicj4NCiZndDsgaGlnaCBv cmRlciBiaXQgMCBhbmQgdGhlIFNQSVIgYWx3YXlzIGhhcyBoaWdoIG9yZGVyIGJpdCAxLiBBbiBT RiBvcg0KPGJyPg0KJmd0OyBPQU0gd2hpY2ggbmVlZHMgdG8gc2VuZCBhbG9uZyB0aGUgcmV2ZXJz ZSBwYXRoIGNhbiBhbHdheXMgZm9ybSB0aGUNCjxicj4NCiZndDsgcmV2ZXJzZSBhZGRyZXNzIGJ5 IGZsaXBwaW5nIHRoZSBoaWdoIG9yZGVyIGJpdCBvZiB0aGUgU1BJLjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgQ2hlZXJzLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyA8YnI+DQomZ3Q7IFBhdWwgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9t OiBzZmMgWzwvZm9udD48L3R0PjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+ PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD48 L2E+PHR0Pjxmb250IHNpemU9Mj5dDQpPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEtvZW5uaW5nPGJy Pg0KJmd0OyBTZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYgMTI6NDkgUE08YnI+DQomZ3Q7IFRv OiBzZmNAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFtzZmNdIFNlcnZpY2UgUGF0aCBJZGVu dGlmaWVyIChTUEkpIGFuZCBzeW1tZXRyeTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgR29v ZCBFdmVuaW5nLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgbG9va2luZyBhdCBSRkMgNzY2 NSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU2VydmljZSBGdW5jdGlv biBDaGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1cmU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzY2NT48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3NjY1PC9mb250PjwvdHQ+PC9hPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgdGhlcmUgaXMgYSBjbGVhciBk ZWZpbml0aW9uIG9mIGNoYWluIHN5bWV0cnk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZx dW90OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyLjIuICZuYnNwO1Nl cnZpY2UgRnVuY3Rpb24gQ2hhaW4gU3ltbWV0cnk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZuYnNwOyAmbmJzcDtTRkNzIG1heSBiZSB1bmlkaXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFs Lg0KJm5ic3A7QSB1bmlkaXJlY3Rpb25hbCBTRkM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO3JlcXVpcmVzIHRoYXQgdHJhZmZpYyBiZSBmb3J3YXJk ZWQNCnRocm91Z2ggdGhlIG9yZGVyZWQgU0ZzIGluIG9uZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ZGlyZWN0aW9uIChzZjEgLSZndDsgc2YyIC0m Z3Q7IHNmMyksDQp3aGVyZWFzIGEgYmlkaXJlY3Rpb25hbCBTRkMgcmVxdWlyZXMgYTwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7c3ltbWV0cmljIHBh dGggKHNmMSAtJmd0OyBzZjIgLSZndDsNCnNmMyBhbmQgc2YzIC0mZ3Q7IHNmMiAtJmd0OyBzZjEp LCBhbmQgaW48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZu YnNwO3doaWNoIHRoZSBTRiBpbnN0YW5jZXMgYXJlIHRoZSBzYW1lDQppbiBvcHBvc2l0ZSBkaXJl Y3Rpb25zLiAmbmJzcDtBIGh5YnJpZDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyAmbmJzcDsgJm5ic3A7U0ZDIGhhcyBhdHRyaWJ1dGVzIG9mIGJvdGggdW5pZGlyZWN0aW9u YWwNCmFuZCBiaWRpcmVjdGlvbmFsIFNGQ3M7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDt0aGF0IGlzIHRvIHNheSBzb21lIFNGcyByZXF1aXJlDQpz eW1tZXRyaWMgdHJhZmZpYywgd2hlcmVhcyBvdGhlciBTRnM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO2RvIG5vdCBwcm9jZXNzIHJldmVyc2UgdHJh ZmZpYyBvcg0KYXJlIGluZGVwZW5kZW50IG9mIHRoZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7Y29ycmVzcG9uZGluZyBmb3J3YXJkIHRyYWZmaWMu PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDs8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOy4uLjwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgRnVydGhlciwgdGhl cmUgYXJlIHN0YXRlIHRyYWRlLW9mZnMNCmluIHN5bW1ldHJ5LiAmbmJzcDtTeW1tZXRyeSBtYXkg YmU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO3Jl YWxpemVkIGluIHNldmVyYWwgd2F5cyBkZXBlbmRpbmcNCm9uIHRoZSBTRkYgYW5kIGNsYXNzaWZp ZXI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO2Z1 bmN0aW9uYWxpdHkuICZuYnNwO0luIHNvbWUgY2FzZXMsDQomcXVvdDttaXJyb3JlZCZxdW90OyBj bGFzc2lmaWNhdGlvbiAoaS5lLiwgZnJvbTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAmbmJzcDsgJm5ic3A7U291cmNlIHRvIERlc3RpbmF0aW9uIGFuZCBmcm9tIERlc3Rp bmF0aW9uDQp0byBTb3VyY2UpIHBvbGljeSBtYXkgYmU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO2RlcGxveWVkLCB3aGVyZWFzIGluIG90aGVycyBz aGFyZWQNCnN0YXRlIGJldHdlZW4gY2xhc3NpZmllcnMgbWF5IGJlPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDt1c2VkIHRvIGVuc3VyZSB0aGF0IHN5 bW1ldHJpYyBmbG93cw0KYXJlIGNvcnJlY3RseSBpZGVudGlmaWVkLCB0aGVuPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtzdGVlcmVkIGFsb25nIHRo ZSByZXF1aXJlZCBTRlAuDQombmJzcDtBdCBhIGhpZ2ggbGV2ZWwsIHRoZXJlIGFyZSB2YXJpb3Vz PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtjb21t b24gY2FzZXMuICZuYnNwO0luIGEgbm9uLWV4aGF1c3RpdmUNCndheSwgdGhlcmUgY2FuIGJlIGZv ciBleGFtcGxlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO28gJm5i c3A7QSBzaW5nbGUgY2xhc3NpZmllciAob3INCmEgc21hbGwgbnVtYmVyIG9mIGNsYXNzaWZpZXJz KSwgaW4gd2hpY2g8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgY2FzZSBib3RoIGluY29taW5nIGFuZCBvdXRnb2luZw0KZmxvd3MgY291 bGQgYmUgcmVjb2duaXplZCBhdCB0aGU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2FtZSBjbGFzc2lmaWVyLCBzbyB0aGUNCnN5bmNo cm9uaXphdGlvbiB3b3VsZCBiZSBmZWFzaWJsZSBieTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbnRlcm5hbCBtZWNoYW5pc21zIGlu dGVybmFsDQp0byB0aGUgY2xhc3NpZmllci48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZu YnNwOyAmbmJzcDtvICZuYnNwO1N0YXRlZnVsIGNsYXNzaWZpZXJzIHdoZXJlDQpzZXZlcmFsIGNs YXNzaWZpZXJzIG1heSBiZSBjbHVzdGVyZWQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYW5kIHNoYXJlIHN0YXRlLjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7RnVsbHkgZGlzdHJpYnV0ZWQg Y2xhc3NpZmllcnMsDQp3aGVyZSBzeW5jaHJvbml6YXRpb24gbmVlZHMgdG8gYmU8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJvdmlk ZWQgdGhyb3VnaCB1bnNwZWNpZmllZA0KbWVhbnMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDsgJm5ic3A7byAmbmJzcDtBIGNsYXNzaWZpZXIgdGhhdCBsZWFybnMNCnN0YXRlIGZy b20gdGhlIGVncmVzcyBwYWNrZXRzL2Zsb3dzIHRoYXQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXMgdGhlbiB1c2VkIHRvIHByb3Zp ZGUNCnN0YXRlIGZvciB0aGUgcmV0dXJuIHBhY2tldHMvZmxvdy48L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtvICZuYnNwO1N5bW1ldHJ5IG1heSBhbHNvIGJlIHByb3Zp ZGVkDQpieSBzdGF0ZWZ1bCBmb3J3YXJkaW5nIGxvZ2ljIGluIHRoZTwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTRkYgaW4gc29tZSBp bXBsZW1lbnRhdGlvbnMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZu YnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7 VGhpcyBpcyBhIG5vbi1jb21wcmVoZW5zaXZlIGxpc3QNCm9mIGNvbW1vbiBjYXNlcy4gJnF1b3Q7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDs8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEhvd2V2ZXIsIHdoZW4gbG9va2luZyBhdCB0aGlzIHRv Z2V0aGVyIHdpdGggPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE5ldHdv cmsgU2VydmljZSBIZWFkZXI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg ZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1zZmMtbnNoLTA0Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMDQ8L2ZvbnQ+PC90dD48L2E+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAzLjMuICZuYnNwO1NlcnZpY2UgUGF0aCBIZWFkZXI8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZxdW90OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDsgJm5ic3A7U2VydmljZSBQYXRoIElkZW50aWZpZXIgKFNQSSk6IGlkZW50aWZpZXMNCmEg c2VydmljZSBwYXRoLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDsgJm5ic3A7UGFydGljaXBhdGluZyBub2RlcyBNVVNUIHVzZSB0aGlzDQppZGVudGlmaWVyIGZv ciBTZXJ2aWNlIEZ1bmN0aW9uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZuYnNwOyAmbmJzcDtQYXRoIHNlbGVjdGlvbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyB0aGVyZSBpcyBu byBub3Rpb24gb2Ygc3ltbWV0cnkuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IENhbiB5b3UgcGxlYXNlIGNv bmZpcm0gdGhhdCBhIGJpZGlyZWN0aW9uYWwgU2VydmljZQ0KRnVuY3Rpb24gQ2hhaW4gPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHdpbGwgYmUgcmVwcmVzZW50ZWQgYnkg b25lIHNpbmdsZSBTZXJ2aWNlIFBhdGgNCklkZW50aWZpZXIsIGluZ3Jlc3MgPGJyPg0KJmd0OyBz eW1tZXRyaWMgdG8gZWdyZXNzID88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBQbGVhc2UgYWxsb3cgdXMgdG8g Y2xhcmlmeSB0aGlzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgTWFueSBUaGFua3M8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IENocmlzdGlhbiBLb2VubmluZzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtLTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBGNSBOZXR3b3JrcyBJbmMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IGNocmlzdGlhbkBmNS5jb208L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHNmY0BpZXRmLm9yZzxi cj4NCiZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9m b250PjwvdHQ+DQo= --=_alternative 0027A2B648257FE9_=-- From nobody Thu Jul 7 00:17: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 110CF12D0CA for ; Thu, 7 Jul 2016 00:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.047 X-Spam-Level: X-Spam-Status: No, score=-4.047 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, RP_MATCHES_RCVD=-1.426, 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 5VOKYcdkj08M for ; Thu, 7 Jul 2016 00:17:47 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F7212B04B for ; Thu, 7 Jul 2016 00:17:47 -0700 (PDT) Received: from smtptc.telefonica.com (tgtim3c03.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EDC623A06B6; Thu, 7 Jul 2016 09:17:44 +0200 (CEST) Received: from ESTGVMSP105.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP105", Issuer "ESTGVMSP105" (not verified)) by smtptc.telefonica.com (Postfix) with ESMTPS id D66A53A0646; Thu, 7 Jul 2016 09:17:44 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.51) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Jul 2016 09:17:43 +0200 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0640.eurprd06.prod.outlook.com (10.161.13.146) with Microsoft SMTP Server (TLS) id 15.1.534.14; Thu, 7 Jul 2016 07:17:40 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0534.020; Thu, 7 Jul 2016 07:17:40 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUaALbFCAgAFFb4A= Date: Thu, 7 Jul 2016 07:17:40 +0000 Message-ID: References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> <990af5e6-d764-e23d-b4a0-1bd02dd71097@joelhalpern.com> In-Reply-To: <990af5e6-d764-e23d-b4a0-1bd02dd71097@joelhalpern.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-ms-office365-filtering-correlation-id: 68100173-54f9-497b-315f-08d3a636c81f x-microsoft-exchange-diagnostics: 1; DB4PR06MB0640; 6:FH/bJpDgbse3EBTqUj2f76rr1jMB2gtCqVhqyV7Byrx8EpOYh+G7ZloyJgX3+m/ip0XeXPCA/UejQBy/wXmtlI3NdVsxngJ5yRVs/mKiVq0/RythbTR3jvjEhwzKA3qGiPKzTyA7CkqVOH1Bf+EB8Hf8k5vd21DGodYUlfbrjClH86VL5bKUVssQ9IZoL9VfF3iK8yWY4cCRnl4XXj08l36dotzCs5jz1qXZioqutdqmEWtKkYbg4lFbgARC6FJ5XwD/1sOcxbpd2ddCmt3Zg83VhvQ+bLkS8KKVrT95pLY=; 5:NHHEMqHwdfHQu4cStkn31IuQhFSsUywTV+9C5P1bMBegD6sr7PbP1lmlHauMGc+okjHa9N2uD3sk6Hqu/Xi8eOnM5FryBfQgRychSe8yTvSFmApJk6fBNbCa4p7NnBVicEx3Y4rdgqGsHFs3r365Rw==; 24:WDrdUYhLOPIvlUViu8EhEErDv5hGBI4jUy49VnRq7KAROuTb2z5I6hiz2Bd8S84SlCai5dP6QBuq3T+MVtBwxa81ldZvYEAguravNDa855c=; 7:dMQR5/D3V9H5i/nV/u3S8zalMml+TEF5y9VXwXy3lH9yIP1xBWv3hNR/8ywzuDwQrcvItHYwOnx9Yk2YydKVvZTKusAA3QR7qtigRpT5c634zhMDT9/t0Pdsmc1DueXQP5lkuZqJsUXW6zQ6mVDbw+QkoSOiP9v+7BHb4YvNMgKWC7pSRkxaGvr/EJVu+GlzkMDQfshSD/hJ5zSKxCCz2f8EFjxdz7H1WArSj8IB5886XgAcMOYWgV2+Li6ntAgj x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0640; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR06MB0640; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0640; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(59124004)(189002)(24454002)(33656002)(101416001)(76176999)(107886002)(54356999)(586003)(6116002)(3846002)(102836003)(189998001)(50986999)(8676002)(81166006)(81156014)(77096005)(83716003)(305945005)(5001770100001)(122556002)(4001350100001)(19580395003)(11100500001)(97736004)(19580405001)(82746002)(83506001)(7846002)(2906002)(7736002)(92566002)(3280700002)(3660700001)(87936001)(36756003)(10400500002)(105586002)(8936002)(106356001)(106116001)(230783001)(5002640100001)(86362001)(68736007)(2501003)(575784001)(15975445007)(2950100001)(2900100001)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0640; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 07:17:40.3772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0640 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 07:17:50 -0000 KzENCg0KLS0tDQpEci4gUGVkcm8gQS4gQXJhbmRhIEd1dGnDqXJyZXoNCg0KDQpUZWNobm9sb2d5 IEV4cGxvcmF0aW9uDQplbWFpbDogcGVkcm9hIGQwdCBhcmFuZGEgQXQgdGVsZWZvbmljYSBkMHQg Y29tDQpUZWxlZsOzbmljYSwgSW52ZXN0aWdhY2nDs24geSBEZXNhcnJvbGxvIOKAkyBHQ1RPIFVu aXQNCkMvIFp1cmJhcsOhbiwxMg0KDQoyODAxMCBNYWRyaWQsIFNwYWluDQoNCg0KRnJhZ2VuIHNp bmQgbmljaHQgZGEsIHVtIGJlYW50d29ydGV0IHp1IHdlcmRlbi4NCkZyYWdlbiBzaW5kIGRhLCB1 bSBnZXN0ZWxsdCB6dSB3ZXJkZW4uDQoNCkdlb3JnIEtyZWlzbGVyDQoNCi0tLS0tTWVuc2FqZSBv cmlnaW5hbC0tLS0tDQpEZTogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRl ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KRmVjaGE6IG1pw6lyY29s ZXMsIDYgZGUganVsaW8gZGUgMjAxNiwgMTU6NTINClBhcmE6ICJKaW0gR3VpY2hhcmQgKGpndWlj aGFyKSIgPGpndWljaGFyQGNpc2NvLmNvbT4sICJzZmNAaWV0Zi5vcmciIDxzZmNAaWV0Zi5vcmc+ DQpBc3VudG86IFJlOiBbc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1kb2xzb24t c2ZjLWhpZXJhcmNoaWNhbC0wNg0KDQpJIHN1cHBvcnQgdGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRp bmcgdGhpcyBkcmFmdC4gIEl0IHNlcnZlcyBhcyBhIGdvb2QNCmJhc2lzIGZvciBkaXNjdXNzaW5n IGFuZCByZXNvbHZpbmcgaXNzdWVzIGluIGxhcmdlciBzY2FsZSBzaXR1YXRpb25zLg0KDQpZb3Vy cywNCkpvZWwNCg0KT24gNy82LzE2IDk6MTcgQU0sIEppbSBHdWljaGFyZCAoamd1aWNoYXIpIHdy b3RlOg0KPiBEZWFyIFdHOg0KPg0KPg0KPiBUaGlzIGVtYWlsIHNlcnZlcyBhcyBhIGNhbGwgZm9y IFdHIGFkb3B0aW9uIG9mDQo+IGRyYWZ0LXBlbm5vLXNmYy1oaWVyYXJjaGljYWwtMDYgYXMgYSBX RyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uDQo+IHdpbGwgcnVuIGZvciAyIHdlZWtz IGVuZGluZyA3LzI1LzIwMTYuDQo+DQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBh IGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEgbGFzdCBjYWxsIGZvcg0KPiBjb250ZW50IG9m IHRoZSBkb2N1bWVudC4gQWRvcHRpbmcgYSBXRyBkb2N1bWVudCBzaW1wbHkgbWVhbnMgdGhhdCB0 aGUgV0cNCj4gd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0IHBhcnRpY3VsYXIgZHJhZnQg Z29pbmcgZm9yd2FyZCwgYW5kIHVzZQ0KPiB0aGF0IGRvY3VtZW50IGZvciByZXNvbHZpbmcgb3Bl biBpc3N1ZXMgYW5kIGRvY3VtZW50aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25zLg0KPg0KPg0KPg0K PiBQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBmb3Igbm90LCBh bmQgaWYgbm90IHdoeS4NCj4gSXNzdWVzIHlvdSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgZG9jdW1l bnQgaXRzZWxmIGNhbiBhbHNvIGJlIHJhaXNlZCwgYnV0DQo+IHRoZXkgc2hvdWxkIGJlIHJhaXNl ZCBpbiB0aGUgY29udGV4dCBvZiB3aGF0IHNob3VsZCBiZSBjaGFuZ2VkIGluIHRoZQ0KPiBkb2N1 bWVudCBnb2luZyBmb3J3YXJkLCByYXRoZXIgdGhhbiBhIHByZS1jb25kaXRpb24gZm9yIGFkb3B0 aW9uLg0KPg0KPg0KPg0KPiBGaW5hbGx5LCBub3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBwb2xs IGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0DQo+IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwg aW4gbGluZSB3aXRoIHRoZSBJUFIgZGlzY2xvc3VyZSBvYmxpZ2F0aW9ucyBmb3INCj4gV0cgcGFy dGljaXBhbnRzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRl dGFpbHMpLg0KPiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBwbGVhc2Ug cmVzcG9uZCB0byB0aGlzIGVtYWlsICh0bw0KPiB0aGUgY2hhaXJzKSB3aGV0aGVyIG9yIG5vdCB5 b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuDQo+DQo+DQo+IFRoYW5rcyENCj4NCj4N Cj4gU0ZDIENoYWlycw0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0K c2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHkg c3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8s IHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwg eSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGlu by4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZp Y2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNv cGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUg bGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3Ig ZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9y IGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQg Y29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMg bWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNl IGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3RhIG1l bnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVz dGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25m aWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRl IGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGlj YWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1 bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlk YSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVu c2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFt ZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0K From nobody Thu Jul 7 00:19: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 EB8D412D16C for ; Thu, 7 Jul 2016 00:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 0v_Xi34uw_TD for ; Thu, 7 Jul 2016 00:19:50 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3EE12B04B for ; Thu, 7 Jul 2016 00:19:49 -0700 (PDT) Received: from smtptc.telefonica.com (tgtim3c04.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 22D4C88594; Thu, 7 Jul 2016 09:19:48 +0200 (CEST) Received: from ESTGVMSP101.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP101", Issuer "ESTGVMSP101" (not verified)) by smtptc.telefonica.com (Postfix) with ESMTPS id F2F9B88592; Thu, 7 Jul 2016 09:19:47 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.49) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Jul 2016 09:19:46 +0200 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0638.eurprd06.prod.outlook.com (10.161.13.144) with Microsoft SMTP Server (TLS) id 15.1.534.14; Thu, 7 Jul 2016 07:19:44 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0534.020; Thu, 7 Jul 2016 07:19:44 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: "Dirk.von-Hugo@telekom.de" , "sfc@ietf.org" Thread-Topic: Updated draft Thread-Index: AQHRyfiUnbQmhcgLfU6RMps+FtOWoqALLwaAgAGebgA= Date: Thu, 7 Jul 2016 07:19:44 +0000 Message-ID: <2804D2DB-130F-45A8-A61D-F3C87B5E83AB@telefonica.com> References: <5E562D18-7BDE-426A-87DA-3A9505482551@telefonica.com> <05C81A773E48DD49B181B04BA21A342A41F45BA3EB@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A41F45BA3EB@HE113484.emea1.cds.t-internal.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-ms-office365-filtering-correlation-id: 6546fb42-c1ad-4cce-3448-08d3a637121f x-microsoft-exchange-diagnostics: 1; DB4PR06MB0638; 6:eD8n0gY5SdAh1q8oZ4ZN4ZI/LBTFHIDzB1sFhQ5yNz4/ZFbXjd+gd4OV76WC7x9wCm/2hDWSgW0mNfQXKqL40D0IFeS5uLwhQJ8ro3gKJ3L0KnE1Rek3C5dDgghcQHTMALki2Oo1uIAzBD87COypiBHsAvDtBPVYykJo50hXErxoaoh/VVm+hxk6bJVvSd49DIjR8nx8YapEfvh8sKkoTVuwv+NP8MilGcaezN52TEyt2qeKA9A53pk3XOcfZ80258E27gomU5U9M77PueAGptUyAUyQ0xj7dv1K159+GwU=; 5:GS9/wJTNVUjmJGn+MMTmOI8T69LgWaR7Aa4cnBLNOcmFMqAj0v0jXGrWSnFESdA8qVqHMvZaAVOCrG31a1/D6K36SRnXJXfLlzJGsoWI29zTpSphZFxPN0JArN/sVxQ6zYFkvWFjXgcZfJxXVje2Dg==; 24:1LArvgLX44nwez24ek9Mj7FJscUV67bZwvzIz8OMG5BZpUdLFfEoDM6ZhOfCEr0NO/iZMnDVKff2Tzih/YcfM86pyZ9SkNZVA12Ktg8neS0=; 7:iQKzCRb09zg7rZjLtvsw0Mkbgwv+e6lEKejVISyuD221+GWa3k+jUHz9dz+VsQglMmPSulupAyH4RC3PklHLhW+wpkABKj0fA9kgQ/2HllvYZiz/VSL+QaxFg/bqS5BAi2QGUP93HgfDRE5eYP9mMck59PTfJKvj4x7cJRyRmlC4JizaPX223ZJpJSfZZQsopLR3eAXKOqr5WC6m4jPtPpnbGV90rykgqFoAhbriwP0uAlpMq4XX9FkkP+5hFWJC x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0638; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(278428928389397)(120809045254105)(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR06MB0638; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0638; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(40134004)(189002)(25724002)(51914003)(377424004)(199003)(10710500007)(97736004)(81156014)(81166006)(68736007)(4001350100001)(8676002)(36756003)(3660700001)(7736002)(92566002)(105586002)(106116001)(2900100001)(5001770100001)(6116002)(7846002)(102836003)(15650500001)(106356001)(2950100001)(2420400007)(2501003)(3846002)(77096005)(586003)(8936002)(122556002)(2906002)(15975445007)(83506001)(19300405004)(221733001)(82746002)(54356999)(50986999)(83716003)(66066001)(19617315012)(10400500002)(76176999)(107886002)(87936001)(5002640100001)(101416001)(575784001)(19625215002)(7906003)(86362001)(7110500001)(3280700002)(189998001)(19580405001)(19580395003)(3480700004)(11100500001)(33656002)(16236675004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0638; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2804D2DB130F45A8A61DF3C87B5E83ABtelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 07:19:44.5788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0638 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [sfc] Updated draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 07:19:54 -0000 --_000_2804D2DB130F45A8A61DF3C87B5E83ABtelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBEaXJrDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCB3aWxsIGJlIGR1bHkgdGFrZW4g aW50byBhY2NvdW50IGluIG91ciBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0DQoNCkJlc3QsIC9Q QQ0KLS0tDQpEci4gUGVkcm8gQS4gQXJhbmRhIEd1dGnDqXJyZXoNCg0KVGVjaG5vbG9neSBFeHBs b3JhdGlvbg0KZW1haWw6IHBlZHJvYSBkMHQgYXJhbmRhIEF0IHRlbGVmb25pY2EgZDB0IGNvbQ0K VGVsZWbDs25pY2EsIEludmVzdGlnYWNpw7NuIHkgRGVzYXJyb2xsbyDigJMgR0NUTyBVbml0DQpD LyBadXJiYXLDoW4sMTINCjI4MDEwIE1hZHJpZCwgU3BhaW4NCg0KRnJhZ2VuIHNpbmQgbmljaHQg ZGEsIHVtIGJlYW50d29ydGV0IHp1IHdlcmRlbi4NCkZyYWdlbiBzaW5kIGRhLCB1bSBnZXN0ZWxs dCB6dSB3ZXJkZW4uDQoNCkdlb3JnIEtyZWlzbGVyDQoNCkRlOiAiRGlyay52b24tSHVnb0B0ZWxl a29tLmRlIiA8RGlyay52b24tSHVnb0B0ZWxla29tLmRlPg0KRmVjaGE6IG1pw6lyY29sZXMsIDYg ZGUganVsaW8gZGUgMjAxNiwgMTI6NTANClBhcmE6IHBhYWcgPHBlZHJvYS5hcmFuZGFAdGVsZWZv bmljYS5jb20+LCAic2ZjQGlldGYub3JnIiA8c2ZjQGlldGYub3JnPg0KQXN1bnRvOiBSRTogVXBk YXRlZCBkcmFmdA0KDQpEZWFyIGF1dGhvcnMsDQpUaGFua3MgYSBsb3QgZm9yIHRoZSB1cGRhdGUh DQpJIGFwcHJlY2lhdGUgdmVyeSBtdWNoIHRoaXMgZGVzY3JpcHRpb24gb2YgYXBwbGljYXRpb25z IGZvciBTRkMgY29uY2VwdCB3aXRoIHJlc3BlY3QgdG8gZnV0dXJlIDVHLg0KDQpRdWVzdGlvbnMg SSBoYXZlIGFyZToNCkNoLiAyLjEuMS4NCldoYXQgZG8geW91IGhhdmUgaW4gbWluZCBmb3Ig4oCY Y2xhc3NpZmljYXRpb24gc2NoZW1lcyBmb3IgNUcgbmV0d29ya3PigJkg4oCTIGFyZSB5b3UgcmVm ZXJyaW5nIHRvIHRoZSBzbGljaW5nIGNvbmNlcHQgb2Ygc2VwYXJhdGVkIGxvZ2ljYWwgbmV0d29y a3MgZXhoaWJpdGluZyBhIHNwZWNpZmljIHBlcmZvcm1hbmNlIGFuZCBpbmNsdWRpbmcgdGFpbG9y ZWQgbmV0d29yayBzZXJ2aWNlIGZ1bmN0aW9ucz8NCg0KQ2guIDIuMw0KSU1PIG5lZWRzIG5vdCB0 byByZXBlYXQgbmVhcmx5IGZ1bGwgY29udGVudCBvZiBjaC4gMS4zIOKAkyBidXQgbWF5IGp1c3Qg bWFrZSByZWZlcmVuY2UgdG8gaXQNCg0KZXh0ZW5kIFNGQyDigJhzY29wZSB0byBmdW5jdGlvbnMg aW4gdGhlIFJhZGlvIEFjY2VzcyBOZXR3b3Jr4oCZID0+IHRoaXMgYWxzbyBjb21wcmlzZXMgdGhl IENvcmUgTmV0d29yayB3aXRoIGVsZW1lbnRzIHNob3duIGluIEZpZy4gMSAoYmVzaWRlIFNHaS1M QU4pIOKApiBhcyBkZXRhaWxlZCBsYXRlciBvbiwgcmlnaHQ/DQoNCk9uZSBtYXkgYWxzbyBtZW50 aW9uIGhlcmUgdGhhdCBvcGVyYXRvcnMgYXJlIGZvcmNlZCB0byBoaWdoIGVmZmljaWVuY3kgd2l0 aCByZXNwZWN0IHRvIGNvc3QgYW5kIHJlc291cmNlcyBpbiBkZXBsb3ltZW50IGFuZCBvcGVyYXRp b24gdG8gb2ZmZXIgYWZmb3JkYWJsZSBzZXJ2aWNlcyB0byB0aGVpciBjdXN0b21lcnMg4oCTIHdo YXQgaXMgYWxzbyBzdXBwb3J0ZWQgYnkgbWVhbnMgb2YgZmxleGlibGUgdGFpbG9yZWQgc2Vydmlj ZSBjaGFpbmluZy4NCg0KQlRXIGRvIHlvdSBwbGFuIHRvIGRldGFpbCBhbHNvIG9uIHRoZSBvcmNo ZXN0cmF0aW9uIHByb2Nlc3NlcyBwbGFubmVkIOKAkyBlLmcuIHVzaW5nIEVUU0kgTkZWIE1BTk8g Y29uY2VwdHMgb3Igc2ltaWxhcj8NCg0KDQpBbHNvIEkgZGV0ZWN0ZWQgc29tZSBtaW5vciBuaXRz IHlvdSBtYXkgY29uc2lkZXIgZHVyaW5nIG5leHQgdXBkYXRlOg0KDQp2aXJ0dWFsaXplZC92aXJ0 dWFsaXphdGlvbiB2cy4gdmlydHVhbGlzZWQvdmlydHVhbGl6YXRpb24sIG9wdGltaXphdGlvbiB2 cy4gb3B0aW1pemF0aW9uID0+IGNvbnNpc3RlbnQgdXNhZ2Ugb2Ygb25lIGZvcm0gb25seSwgcGxl YXNlDQoNClAuIDEvMzogY29uID0+IGNhbg0KDQpQLiA0OiBtdWNoIGVhcmxpZXIgdGhhdCBpbiB0 aGUgY3VycmVudCAzR1BQIGFyY2hpdGVjdHVyZSA9PiBtdWNoIGVhcmxpZXIgdGhhbiBpbiB0aGUg Y3VycmVudCAzR1BQIGFyY2hpdGVjdHVyZSBPUg0K4oCYYWxyZWFkeSB2ZXJ5IG5lYXIgdG8gdGhl IGFjY2Vzc+KAmQ0KDQpwLiA1OiBwYXJ0bmVyc2hpcCAoNUdQUFApIFs1XSA9PiBwYXJ0bmVyc2hp cCg1R1BQUCkgWzJdDQppKSBNZWRpdW0gPT4gaWkpIE1lZGl1bQ0KcC4gNjogRmlndXJlIDIgPT4g RmlndXJlIDENCg0KcC4gODogVGhpcyBhcHByb2FjaCBlbmFibGVzIGVuYWJsZXMgPT4gVGhpcyBh cHByb2FjaCBlbmFibGVzDQoNCnAuIDk6DQpJIHN1Z2dlc3QgdG8gYWxpZ24gdGhlIHdvcmRpbmcg aW4gRmlnLiAyIGFuZCB0aGUgbWVudGlvbmVkIGV4YW1wbGVzIGUuZy4g4oCYSGFwdGljL1RhY3Rp bGUgSW50ZXJuZXTigJksIOKAmEJyb2FkYmFuZCBJbnRlcm5ldCBBY2Nlc3PigJkNCmFuZCB0byBh ZGQgYSByZWZlcmVuY2UgdG8gRmlndXJlIDIgaGVyZQ0KDQpWTkZzID0+IE5GcyBbb3IgZGVmaW5l IFZORl0NCm9mIHRoZSB0aGUgbmV0d29yayA9PiBvZiB0aGUgbmV0d29yaw0KDQpwLiAxMDogdGhl c2UgZnVuY3Rpb25zIHdlcmUgPT4gdGhlc2UgZnVuY3Rpb25zIGFyZQ0KdHJhZGl0aW9uYWwgYWNj ZXNzLWNvcmUgZGVwbG95bWVudCA9PiB0cmFkaXRpb25hbGx5IHNlcGFyYXRlZCBkZXBsb3ltZW50 IG9mIGFjY2VzcyBhbmQgY29yZSBkb21haW5zDQpwLjEzOiBkZWxldGUgWzVdIGh0dHBzOi8vNWct cHBwLmV1DQoNCjstKQ0KVGhhbmtzICYgQmVzdCBSZWdhcmRzDQpEaXJrDQoNCkZyb206IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUEVEUk8gQU5EUkVTIEFS QU5EQSBHVVRJRVJSRVoNClNlbnQ6IFNvbm50YWcsIDE5LiBKdW5pIDIwMTYgMDk6MDMNClRvOiBz ZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFtzZmNdIFVwZGF0ZWQgZHJhZnQNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWFyYW5kYS1zZmMtZHAtbW9iaWxlLTAxLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQZWRybyBBLiBBcmFuZGEgR3V0aWVycmV6IGFuZCBwb3N0 ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICBkcmFmdC1hcmFuZGEt c2ZjLWRwLW1vYmlsZQ0KUmV2aXNpb246ICAgIDAxDQpUaXRsZTogICAgICAgU2VydmljZSBGdW5j dGlvbiBDaGFpbmluZyBEYXRhcGxhbmUgRWxlbWVudHMgaW4gTW9iaWxlIE5ldHdvcmtzDQpEb2N1 bWVudCBkYXRlOiAgIDIwMTYtMDYtMTMNCkdyb3VwOiAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOiAgICAgICAxNA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hcmFuZGEtc2ZjLWRwLW1vYmlsZS0wMS50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hcmFuZGEt c2ZjLWRwLW1vYmlsZS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYXJhbmRhLXNmYy1kcC1tb2JpbGUtMDENCkRpZmY6ICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYXJhbmRhLXNmYy1kcC1tb2JpbGUtMDEN Cg0KQWJzdHJhY3Q6DQogICBUaGUgZXZvbHV0aW9uIG9mIHRoZSBuZXR3b3JrIHRvd2FyZHMgNUcg aW1wbGllcyBhIGNoYWxsZW5nZSBmb3IgdGhlDQogICBpbmZyYXN0cnVjdHVyZS4gIFRoZSB0YXJn ZXRlZCBzZXJ2aWNlcyBhbmQgdGhlIGZ1bGwgZGVwbG95bWVudCBvZg0KICAgdmlydHVhbGl6YXRp b24gaW4gYWxsIHNlZ21lbnRzIG9mIHRoZSBuZXR3b3JrIHdpbGwgbmVlZCBzZXJ2aWNlDQogICBm dW5jdGlvbiBjaGFpbnMgdGhhdCBwcmV2aW91c2x5IHJlc2lkZWQgaW4gdGhlKGxvY2FsIGFuZCBy ZW1vdGUpDQogICBpbmZyYXN0cnVjdHVyZSBvZiB0aGUgTmV0d29yayBvcGVyYXRvcnMgdG8gZXh0 ZW5kIHRvIHRoZSByYWRpbyBhY2Nlc3MNCiAgIG5ldHdvcmsgKFJBTikuDQoNCiAgIEluIHRoaXMg ZHJhZnQgd2UgcHJvdmlkZSBhIG5vbi1leGhhdXN0aXZlIGJ1dCByZXByZXNlbnRhdGl2ZSBsaXN0 IG9mDQogICBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiA0RyBhbmQgNUcgbmV0d29ya3MsIGFuZCBleHBs b3JlIGRpZmZlcmVudA0KICAgc2NlbmFyaW9zIGZvciBzZXJ2aWNlLWF3YXJlIG9yY2hlc3RyYXRp b24uDQoNCiAgIFdlIGJhc2Ugb24gdGhlIHByb2JsZW0gc3RhdGVtZW50IFtSRkM3NDk4XSBhbmQg YXJjaGl0ZWN0dXJlIGZyYW1ld29yaw0KICAgW1JGQzc2NjVdICBvZiB0aGUgU0ZDIHdvcmtpbmcg Z3JvdXAsIGFzIHdlbGwgb24gdGhlIGV4aXN0aW5nIG1vYmlsZQ0KICAgbmV0d29ya3MgdXNlIGNh c2VzIFtJLUQuaWV0Zi1zZmMtdXNlLWNhc2UtbW9iaWxpdHldICBhbmQgdGhlDQogICByZXF1aXJl bWVudCBnYXRoZXJpbmcgcHJvY2VzcyBvZiB0aGUgSVRVLVIgSU1UIDIwMjAgWzFdIGFuZCBkaWZm ZXJlbnQNCiAgIGluaXRpYXRpdmVzIGluIEV1cm9wZSBbMl0sIEtvcmVhIFszXSBhbmQgQ2hpbmEg WzRdIHRvIGFudGljaXBhdGUNCiAgIG5ldHdvcmsgZWxlbWVudHMgdGhhdCB3aWxsIGJlIG5lZWRl ZCBpbiA1RyBuZXR3b3Jrcy4NCg0KICAgV2UgdGhlbiBleHBsb3JlIHNlcnZpY2UtYXdhcmUgb3Jj aGVzdHJhdGlvbiBzY2VuYXJpb3MgaWRlbnRpZnlpbmcNCiAgIHdoZXJlIGRpZmZlcmVudCBuZXR3 b3JrIGZ1bmN0aW9ucyBjb24gYmUgZGVwbG95ZWQgaW4gYSBmdWxseQ0KICAgdmlydHVhbGlzZWQg ZnV0dXJlIG5ldHdvcmssIHdoZXJlIGJvdGggdGhlIGNvcmUgYW5kIHRoZSBlZGdlIHByb3ZpZGUN CiAgIGFkdmFuY2VkIHZpcnR1YWxpc2F0aW9uIGNhcGFiaWxpdGllcy4NCg0KDQotLS0NCkRyLiBQ ZWRybyBBLiBBcmFuZGEgR3V0acOpcnJleg0KDQpUZWNobm9sb2d5IEV4cGxvcmF0aW9uIC0NCk5l dHdvcmsgSW5ub3ZhdGlvbiAmIFZpcnR1YWxpc2F0aW9uDQplbWFpbDogcGVkcm9hIGQwdCBhcmFu ZGEgQXQgdGVsZWZvbmljYSBkMHQgY29tDQpUZWxlZsOzbmljYSwgSW52ZXN0aWdhY2nDs24geSBE ZXNhcnJvbGxvDQpDLyBadXJiYXLDoW4sMTINCjI4MDEwIE1hZHJpZCwgU3BhaW4NCg0KRnJhZ2Vu IHNpbmQgbmljaHQgZGEsIHVtIGJlYW50d29ydGV0IHp1IHdlcmRlbi4NCkZyYWdlbiBzaW5kIGRh LCB1bSBnZXN0ZWxsdCB6dSB3ZXJkZW4uDQpHZW9yZyBLcmVpc2xlcg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBk aXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBp bmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhj bHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVk LiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxl Y3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFj acOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2 aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9z IHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEg eSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRp c3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlv biBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5z bWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBs eSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9u IGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5l eG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUg Y29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFy YSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6Nv IMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmlj YWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8Oz cGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBs ZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCBy b2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVz bWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJp Z2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZv cm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVz aXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBl bCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1 cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOz biBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdl bnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1 ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBw cm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3Nl bWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz c2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0 byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGlu IGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9z IHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29u dGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1 c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOp IHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRv IGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlh IHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdp c2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dh bW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEg dmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== --_000_2804D2DB130F45A8A61DF3C87B5E83ABtelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiOw0KCXBhbm9z ZS0xOjIgMTUgMyAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWluZ0xpVTsNCglwYW5vc2UtMToyIDIgNSA5IDAgMCAw IDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYTsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6TW9uYWNvOw0KCXBhbm9zZS0xOjIgMCA1IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseTpDYWxpYnJpO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1z by1zdHlsZS1saW5rOiJUw610dWxvIDEgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1z dHlsZS1saW5rOiJUw610dWxvIDIgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJZm9u dC13ZWlnaHQ6bm9ybWFsO30NCmgzDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHls ZS1saW5rOiJUw610dWxvIDMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJZm9udC13 ZWlnaHQ6bm9ybWFsO30NCmg0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiJUw610dWxvIDQgQ2FyIjsNCgltYXJnaW4tdG9wOjEwLjBwdDsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXN0eWxlOml0 YWxpYzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5UdHVs bzNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlTDrXR1bG8gMyBDYXIiOw0KCW1zby1zdHlsZS1saW5r OiJUw610dWxvIDMiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IjsNCglmb250LXZhcmlh bnQ6c21hbGwtY2FwczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpJVDt9DQpzcGFuLlR0dWxvMkNh cg0KCXttc28tc3R5bGUtbmFtZToiVMOtdHVsbyAyIENhciI7DQoJbXNvLXN0eWxlLWxpbms6IlTD rXR1bG8gMiI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiOw0KCWZvbnQtdmFyaWFudDpz bWFsbC1jYXBzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOklUO30NCnNwYW4uVHR1bG8xQ2FyDQoJ e21zby1zdHlsZS1uYW1lOiJUw610dWxvIDEgQ2FyIjsNCgltc28tc3R5bGUtbGluazoiVMOtdHVs byAxIjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCI7DQoJZm9udC12YXJpYW50OnNtYWxs LWNhcHM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SVQ7fQ0Kc3Bhbi5UdHVsbzRDYXINCgl7bXNv LXN0eWxlLW5hbWU6IlTDrXR1bG8gNCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1z by1zdHlsZS1saW5rOiJUw610dWxvIDQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IjsN Cgljb2xvcjojMkU3NEI1Ow0KCWZvbnQtc3R5bGU6aXRhbGljO30NCnAuSGVhZGluZzEsIGxpLkhl YWRpbmcxLCBkaXYuSGVhZGluZzENCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMSI7DQoJbXNv LXN0eWxlLWxpbms6IkhlYWRpbmcgMSBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0K c3Bhbi5IZWFkaW5nMUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMSBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAxIjsNCglmb250 LWZhbWlseTpDYW1icmlhOw0KCWNvbG9yOiMzNjVGOTE7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpw LkhlYWRpbmcyLCBsaS5IZWFkaW5nMiwgZGl2LkhlYWRpbmcyDQoJe21zby1zdHlsZS1uYW1lOiJI ZWFkaW5nIDIiOw0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTpDYWxpYnJpO30NCnNwYW4uSGVhZGluZzJDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFk aW5nIDIgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Ikhl YWRpbmcgMiI7DQoJZm9udC1mYW1pbHk6Q2FtYnJpYTsNCgljb2xvcjojNEY4MUJEOw0KCWZvbnQt d2VpZ2h0OmJvbGQ7fQ0KcC5IZWFkaW5nMywgbGkuSGVhZGluZzMsIGRpdi5IZWFkaW5nMw0KCXtt c28tc3R5bGUtbmFtZToiSGVhZGluZyAzIjsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLkhlYWRpbmczQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSGVhZGluZyAzIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1z by1zdHlsZS1saW5rOiJIZWFkaW5nIDMiOw0KCWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJY29sb3I6 IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC5IZWFkaW5nNCwgbGkuSGVh ZGluZzQsIGRpdi5IZWFkaW5nNA0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA0IjsNCgltc28t c3R5bGUtbGluazoiSGVhZGluZyA0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpz cGFuLkhlYWRpbmc0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQiOw0KCWZvbnQt ZmFtaWx5OkNhbWJyaWE7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkOw0KCWZv bnQtc3R5bGU6aXRhbGljO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUt bmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgMy4wY20gNzAuODVwdCAzLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOi01Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMjA2NDI4NDg7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiUxOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMS42cHQ7 DQoJdGV4dC1pbmRlbnQ6LTIxLjZwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXN0 eWxlLWxpbms6IlTDrXR1bG8gMiI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4lMiI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjI4LjhwdDsNCgl0ZXh0LWluZGVudDotMjguOHB0O30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiVMOtdHVsbyAzIjsNCgltc28tbGV2ZWwtdGV4dDoi JTFcLiUyXC4lMyI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgl0ZXh0LWluZGVudDotMzYu MHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTQi Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDo0My4ycHQ7DQoJdGV4dC1pbmRlbnQ6LTQzLjJwdDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNSI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjUwLjRwdDsNCgl0ZXh0LWluZGVudDotNTAuNHB0O30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNiI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjU3LjZwdDsNCgl0ZXh0LWluZGVudDotNTcuNnB0O30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTciOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDo2NC44cHQ7DQoJdGV4dC1pbmRlbnQ6LTY0LjhwdDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNVwuJTZcLiU3XC4lOCI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjcyLjBwdDsNCgl0ZXh0LWluZGVudDotNzIuMHB0O30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTdcLiU4 XC4lOSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojc5LjJwdDsNCgl0ZXh0LWluZGVudDotNzkuMnB0O30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjYwMjU0MTkzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxOTAwODY4NzY0O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoi VMOtdHVsbyAxIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTQuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1sZWdhbC1mb3JtYXQ6eWVzOw0KCW1z by1sZXZlbC10ZXh0OiIlMVwuJTJcLiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojk2LjU1cHQ7DQoJdGV4 dC1pbmRlbnQ6LTQyLjU1cHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC10ZXh0OiIl MVwuJTJcLiUzXC4iOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5Ny4ycHQ7DQoJdGV4dC1pbmRlbnQ6LTI1 LjJwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0 XC4iOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjIuNHB0Ow0KCXRleHQtaW5kZW50Oi0zMi40cHQ7fQ0K QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzXC4lNFwuJTVcLiI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE0Ny42cHQ7DQoJdGV4dC1pbmRlbnQ6LTM5LjZwdDt9DQpAbGlz dCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNVwuJTZcLiI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE3Mi44cHQ7DQoJdGV4dC1pbmRlbnQ6LTQ2LjhwdDt9DQpAbGlz dCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNVwuJTZcLiU3 XC4iOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoxOTguMHB0Ow0KCXRleHQtaW5kZW50Oi01NC4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzXC4lNFwuJTVcLiU2 XC4lN1wuJThcLiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIyMy4ycHQ7DQoJdGV4dC1pbmRlbnQ6LTYx LjJwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0 XC4lNVwuJTZcLiU3XC4lOFwuJTlcLiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI1Mi4wcHQ7DQoJdGV4 dC1pbmRlbnQ6LTcyLjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hp dGUiIGxhbmc9IkVTLVRSQUQiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkRlYXIgRGlyazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgZm9yIHRoZSBjb21tZW50cywgd2lsbCBiZSBkdWx5 IHRha2VuIGludG8gYWNjb3VudCBpbiBvdXIgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5CZXN0LCAvUEE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+RHIuIFBlZHJvIEEuIEFyYW5kYSBHdXRpw6lycmV6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs YWNrIj5UZWNobm9sb2d5IEV4cGxvcmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6YmxhY2siPmVtYWlsOiBwZWRyb2EgZDB0IGFyYW5kYSBBdCB0ZWxlZm9u aWNhIGQwdCBjb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpi bGFjayI+VGVsZWbDs25pY2EsIEludmVzdGlnYWNpw7NuIHkgRGVzYXJyb2xsbyDigJMgR0NUTyBV bml0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkMv IFp1cmJhcsOhbiwxMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4yODAxMCBNYWRyaWQsIFNwYWluPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5GcmFn ZW4gc2luZCBuaWNodCBkYSwgdW0gYmVhbnR3b3J0ZXQgenUgd2VyZGVuLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5GcmFnZW4gc2luZCBkYSwgdW0g Z2VzdGVsbHQgenUgd2VyZGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkdlb3JnIEtyZWlzbGVyPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkRlOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JnF1b3Q7RGlyay52 b24tSHVnb0B0ZWxla29tLmRlJnF1b3Q7ICZsdDtEaXJrLnZvbi1IdWdvQHRlbGVrb20uZGUmZ3Q7 PGJyPg0KPGI+RmVjaGE6IDwvYj5tacOpcmNvbGVzLCA2IGRlIGp1bGlvIGRlIDIwMTYsIDEyOjUw PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlVO2NvbG9yOmJsYWNrIj48YnI+ DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QYXJhOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+cGFhZyAmbHQ7cGVkcm9hLmFyYW5kYUB0ZWxlZm9uaWNh LmNvbSZndDssICZxdW90O3NmY0BpZXRmLm9yZyZxdW90OyAmbHQ7c2ZjQGlldGYub3JnJmd0Ozxi cj4NCjxiPkFzdW50bzogPC9iPlJFOiBVcGRhdGVkIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1s ZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGNtIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5EZWFyIGF1 dGhvcnMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGEgbG90IGZvciB0aGUgdXBkYXRlITwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPkkgYXBwcmVjaWF0ZSB2ZXJ5IG11Y2ggdGhpcyBkZXNjcmlwdGlvbiBvZiBhcHBsaWNh dGlvbnMgZm9yIFNGQyBjb25jZXB0IHdpdGggcmVzcGVjdCB0byBmdXR1cmUgNUcuDQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5RdWVzdGlvbnMgSSBoYXZlIGFyZTo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj5DaC4gMi4xLjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+V2hhdCBkbyB5b3UgaGF2ZSBpbiBtaW5k IGZvciDigJhjbGFzc2lmaWNhdGlvbiBzY2hlbWVzIGZvciA1RyBuZXR3b3Jrc+KAmSDigJMgYXJl IHlvdSByZWZlcnJpbmcgdG8gdGhlIHNsaWNpbmcgY29uY2VwdCBvZiBzZXBhcmF0ZWQgbG9naWNh bCBuZXR3b3JrcyBleGhpYml0aW5nIGEgc3BlY2lmaWMgcGVyZm9ybWFuY2UgYW5kDQogaW5jbHVk aW5nIHRhaWxvcmVkIG5ldHdvcmsgc2VydmljZSBmdW5jdGlvbnM/IDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPkNoLiAyLjMNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPklNTyBuZWVkcyBub3Qg dG8gcmVwZWF0IG5lYXJseSBmdWxsIGNvbnRlbnQgb2YgY2guIDEuMyDigJMgYnV0IG1heSBqdXN0 IG1ha2UgcmVmZXJlbmNlIHRvIGl0DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5l eHRlbmQgU0ZDIOKAmHNjb3BlIHRvIGZ1bmN0aW9ucyBpbiB0aGUgUmFkaW8gQWNjZXNzIE5ldHdv cmvigJkgPSZndDsgdGhpcyBhbHNvIGNvbXByaXNlcyB0aGUgQ29yZSBOZXR3b3JrIHdpdGggZWxl bWVudHMgc2hvd24gaW4gRmlnLiAxIChiZXNpZGUgU0dpLUxBTikg4oCmIGFzIGRldGFpbGVkIGxh dGVyIG9uLCByaWdodD88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5PbmUgbWF5IGFsc28g bWVudGlvbiBoZXJlIHRoYXQgb3BlcmF0b3JzIGFyZSBmb3JjZWQgdG8gaGlnaCBlZmZpY2llbmN5 IHdpdGggcmVzcGVjdCB0byBjb3N0IGFuZCByZXNvdXJjZXMgaW4gZGVwbG95bWVudCBhbmQgb3Bl cmF0aW9uIHRvIG9mZmVyIGFmZm9yZGFibGUgc2VydmljZXMgdG8gdGhlaXIgY3VzdG9tZXJzDQog 4oCTIHdoYXQgaXMgYWxzbyBzdXBwb3J0ZWQgYnkgbWVhbnMgb2YgZmxleGlibGUgdGFpbG9yZWQg c2VydmljZSBjaGFpbmluZy4gPC9zcGFuPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5C VFcgZG8geW91IHBsYW4gdG8gZGV0YWlsIGFsc28gb24gdGhlIG9yY2hlc3RyYXRpb24gcHJvY2Vz c2VzIHBsYW5uZWQg4oCTIGUuZy4gdXNpbmcgRVRTSSBORlYgTUFOTyBjb25jZXB0cyBvciBzaW1p bGFyPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QiPkFsc28gSSBkZXRlY3RlZCBzb21lIG1pbm9yIG5pdHMgeW91IG1heSBjb25zaWRlciBkdXJp bmcgbmV4dCB1cGRhdGU6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+dmlydHVh bGl6ZWQvdmlydHVhbGl6YXRpb24gdnMuIHZpcnR1YWxpc2VkL3ZpcnR1YWxpemF0aW9uLCBvcHRp bWl6YXRpb24gdnMuIG9wdGltaXphdGlvbiA9Jmd0OyBjb25zaXN0ZW50IHVzYWdlIG9mIG9uZSBm b3JtIG9ubHksIHBsZWFzZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlAuIDEv MzogY29uID0mZ3Q7IGNhbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlAuIDQ6 IG11Y2ggZWFybGllciB0aGF0IGluIHRoZSBjdXJyZW50IDNHUFAgYXJjaGl0ZWN0dXJlID0mZ3Q7 IG11Y2ggZWFybGllciB0aGFuIGluIHRoZSBjdXJyZW50IDNHUFAgYXJjaGl0ZWN0dXJlIE9SPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+4oCYYWxyZWFkeSB2ZXJ5IG5lYXIgdG8gdGhlIGFjY2Vzc+KAmQ0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+cC4gNTogcGFydG5lcnNoaXAgKDVHUFBQKSBb NV0gPSZndDsgcGFydG5lcnNoaXAoNUdQUFApIFsyXTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPmkpIE1lZGl1bSA9 Jmd0OyBpaSkgTWVkaXVtPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+cC4gNjogRmlndXJlIDIgPSZndDsgRmlndXJl IDE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5wLiA4OiBUaGlzIGFwcHJvYWNo IGVuYWJsZXMgZW5hYmxlcyA9Jmd0OyBUaGlzIGFwcHJvYWNoIGVuYWJsZXM8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjojMUY0OTdEIj5wLiA5Og0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SSBzdWdnZXN0IHRv IGFsaWduIHRoZSB3b3JkaW5nIGluIEZpZy4gMiBhbmQgdGhlIG1lbnRpb25lZCBleGFtcGxlcyBl LmcuIOKAmEhhcHRpYy9UYWN0aWxlIEludGVybmV04oCZLCDigJhCcm9hZGJhbmQgSW50ZXJuZXQg QWNjZXNz4oCZPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+YW5kIHRvIGFkZCBhIHJlZmVyZW5jZSB0byBGaWd1cmUg MiBoZXJlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Vk5GcyA9Jmd0OyBORnMg W29yIGRlZmluZSBWTkZdPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+b2YgdGhlIHRoZSBuZXR3b3JrID0mZ3Q7IG9m IHRoZSBuZXR3b3JrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6 MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOiMxRjQ5N0QiPnAuIDEwOiB0aGVzZSBmdW5jdGlvbnMgd2VyZSA9Jmd0OyB0 aGVzZSBmdW5jdGlvbnMgYXJlDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0 OjBjbTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMUY0OTdEIj50cmFkaXRpb25h bCBhY2Nlc3MtY29yZSBkZXBsb3ltZW50ID0mZ3Q7IHRyYWRpdGlvbmFsbHkgc2VwYXJhdGVkIGRl cGxveW1lbnQgb2YgYWNjZXNzIGFuZCBjb3JlIGRvbWFpbnM8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0O21hcmdpbi1sZWZ0OjBjbTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMUY0OTdE Ij5wLjEzOiBkZWxldGUgWzVdDQo8YSBocmVmPSJodHRwczovLzVnLXBwcC5ldSI+aHR0cHM6Ly81 Zy1wcHAuZXU8L2E+IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3Rl eHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4g bGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y OiMxRjQ5N0QiPjstKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3Rl eHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAmYW1wOyBCZXN0 IFJlZ2FyZHM8YnI+DQpEaXJrIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpUYWhvbWEiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+UEVEUk8gQU5EUkVTIEFSQU5EQSBHVVRJRVJSRVo8YnI+DQo8Yj5TZW50Ojwv Yj4gU29ubnRhZywgMTkuIEp1bmkgMjAxNiAwOTowMzxicj4NCjxiPlRvOjwvYj4gc2ZjQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzZmNdIFVwZGF0ZWQgZHJhZnQ8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+QSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFyYW5kYS1zZmMtZHAtbW9iaWxlLTAxLnR4dDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBQZWRybyBBLiBBcmFuZGEgR3V0aWVycmV6IGFuZCBwb3N0ZWQgdG8gdGhlPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox NC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvIj5JRVRGIHJlcG9zaXRvcnkuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7 Zm9udC1mYW1pbHk6TW9uYWNvIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25h Y28iPk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0 LWFyYW5kYS1zZmMtZHAtbW9iaWxlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvIj5S ZXZpc2lvbjombmJzcDsmbmJzcDsmbmJzcDsgMDE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1 dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpN b25hY28iPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5nIERhdGFwbGFuZSBFbGVtZW50cyBpbiBNb2JpbGUgTmV0d29ya3M8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28iPkRvY3VtZW50IGRhdGU6Jm5ic3A7Jm5i c3A7IDIwMTYtMDYtMTM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28iPkdyb3VwOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28iPlBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAxNDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNl Om5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+ VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1hcmFuZGEtc2ZjLWRwLW1vYmlsZS0wMS50eHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAwMEU5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt YXJhbmRhLXNmYy1kcC1tb2JpbGUtMDEudHh0PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250 LWZhbWlseTpNb25hY28iPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWFyYW5kYS1zZmMtZHAtbW9iaWxlLyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwRTki Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFyYW5kYS1zZmMtZHAtbW9i aWxlLzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvIj5IdG1saXpl ZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hcmFuZGEtc2ZjLWRwLW1vYmlsZS0wMSI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDAwRTkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1h cmFuZGEtc2ZjLWRwLW1vYmlsZS0wMTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1p bHk6TW9uYWNvIj5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWFyYW5kYS1zZmMtZHAtbW9iaWxlLTAxIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMDBFOSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFyYW5kYS1z ZmMtZHAtbW9iaWxlLTAxPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25h Y28iPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+QWJzdHJhY3Q6PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvIj4mbmJzcDsmbmJzcDsgVGhlIGV2b2x1dGlv biBvZiB0aGUgbmV0d29yayB0b3dhcmRzIDVHIGltcGxpZXMgYSBjaGFsbGVuZ2UgZm9yIHRoZTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+Jm5ic3A7Jm5ic3A7IGluZnJhc3RydWN0 dXJlLiZuYnNwOyZuYnNwO1RoZSB0YXJnZXRlZCBzZXJ2aWNlcyBhbmQgdGhlIGZ1bGwgZGVwbG95 bWVudCBvZjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+Jm5ic3A7Jm5ic3A7IHZp cnR1YWxpemF0aW9uIGluIGFsbCBzZWdtZW50cyBvZiB0aGUgbmV0d29yayB3aWxsIG5lZWQgc2Vy dmljZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+Jm5ic3A7Jm5ic3A7IGZ1bmN0 aW9uIGNoYWlucyB0aGF0IHByZXZpb3VzbHkgcmVzaWRlZCBpbiB0aGUobG9jYWwgYW5kIHJlbW90 ZSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28iPiZuYnNwOyZuYnNwOyBpbmZyYXN0 cnVjdHVyZSBvZiB0aGUgTmV0d29yayBvcGVyYXRvcnMgdG8gZXh0ZW5kIHRvIHRoZSByYWRpbyBh Y2Nlc3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28iPiZuYnNwOyZuYnNwOyBuZXR3 b3JrIChSQU4pLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvIj4mbmJzcDsmbmJzcDsgSW4gdGhpcyBkcmFmdCB3 ZSBwcm92aWRlIGEgbm9uLWV4aGF1c3RpdmUgYnV0IHJlcHJlc2VudGF0aXZlIGxpc3Qgb2Y8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28iPiZuYnNwOyZuYnNwOyBzZXJ2aWNlIGZ1bmN0 aW9ucyBpbiA0RyBhbmQgNUcgbmV0d29ya3MsIGFuZCBleHBsb3JlIGRpZmZlcmVudDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+Jm5ic3A7Jm5ic3A7IHNjZW5hcmlvcyBmb3Igc2Vy dmljZS1hd2FyZSBvcmNoZXN0cmF0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFj byI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvIj4mbmJzcDsmbmJzcDsg V2UgYmFzZSBvbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgW1JGQzc0OThdIGFuZCBhcmNoaXRlY3R1 cmUgZnJhbWV3b3JrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvIj4mbmJzcDsmbmJz cDsgW1JGQzc2NjVdJm5ic3A7Jm5ic3A7b2YgdGhlIFNGQyB3b3JraW5nIGdyb3VwLCBhcyB3ZWxs IG9uIHRoZSBleGlzdGluZyBtb2JpbGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28i PiZuYnNwOyZuYnNwOyBuZXR3b3JrcyB1c2UgY2FzZXMgW0ktRC5pZXRmLXNmYy11c2UtY2FzZS1t b2JpbGl0eV0mbmJzcDsmbmJzcDthbmQgdGhlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRv c3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9u YWNvIj4mbmJzcDsmbmJzcDsgcmVxdWlyZW1lbnQgZ2F0aGVyaW5nIHByb2Nlc3Mgb2YgdGhlIElU VS1SIElNVCAyMDIwIFsxXSBhbmQgZGlmZmVyZW50PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h dXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6 TW9uYWNvIj4mbmJzcDsmbmJzcDsgaW5pdGlhdGl2ZXMgaW4gRXVyb3BlIFsyXSwgS29yZWEgWzNd IGFuZCBDaGluYSBbNF0gdG8gYW50aWNpcGF0ZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1v bmFjbyI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmsgZWxlbWVudHMgdGhhdCB3aWxsIGJlIG5lZWRlZCBp biA1RyBuZXR3b3Jrcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpNb25hY28iPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5Ok1vbmFjbyI+Jm5ic3A7Jm5ic3A7IFdlIHRoZW4gZXhw bG9yZSBzZXJ2aWNlLWF3YXJlIG9yY2hlc3RyYXRpb24gc2NlbmFyaW9zIGlkZW50aWZ5aW5nPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvIj4mbmJzcDsmbmJzcDsgd2hlcmUgZGlmZmVy ZW50IG5ldHdvcmsgZnVuY3Rpb25zIGNvbiBiZSBkZXBsb3llZCBpbiBhIGZ1bGx5PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox NC4wcHQ7Zm9udC1mYW1pbHk6TW9uYWNvIj4mbmJzcDsmbmJzcDsgdmlydHVhbGlzZWQgZnV0dXJl IG5ldHdvcmssIHdoZXJlIGJvdGggdGhlIGNvcmUgYW5kIHRoZSBlZGdlIHByb3ZpZGU8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE0LjBwdDtmb250LWZhbWlseTpNb25hY28iPiZuYnNwOyZuYnNwOyBhZHZhbmNlZCB2aXJ0dWFs aXNhdGlvbiBjYXBhYmlsaXRpZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6YmxhY2siPi0tLTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkRyLiBQ ZWRybyBBLiBBcmFuZGEgR3V0acOpcnJlejwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRlY2hub2xvZ3kg RXhwbG9yYXRpb24gLTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPk5ldHdvcmsg SW5ub3ZhdGlvbiAmYW1wOyBWaXJ0dWFsaXNhdGlvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6YmxhY2siPmVtYWlsOiBwZWRyb2EgZDB0IGFyYW5kYSBBdCB0ZWxlZm9uaWNhIGQwdCBjb208 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UZWxlZsOzbmljYSwgSW52ZXN0aWdh Y2nDs24geSBEZXNhcnJvbGxvPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+Qy8g WnVyYmFyw6FuLDEyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+MjgwMTAgTWFk cmlkLCBTcGFpbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkZyYWdlbiBzaW5kIG5pY2h0IGRhLCB1bSBi ZWFudHdvcnRldCB6dSB3ZXJkZW4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ RnJhZ2VuIHNpbmQgZGEsIHVtIGdlc3RlbGx0IHp1IHdlcmRlbi48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrIj5HZW9yZyBLcmVpc2xlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPg0KPGhyIHNpemU9IjIi IHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6Z3JheSI+PGJyPg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4g ZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFj acOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8g ZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRl c3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGENCiBsZWN0dXJh LCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24g cHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50 ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUg bm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJv Y2VkYSBhIHN1IGRlc3RydWNjacOzbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTpNaW5nTGlVO2NvbG9yOmdyYXkiPjxicj4NCjxicj4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmdyYXkiPlRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9m IHRoaXMgbWVzc2FnZSBpcyBub3QNCiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhl cmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29w eWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0 LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlDQog cmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC48 YnI+DQo8YnI+DQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNp dmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHBy aXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVz c29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBk ZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGENCiBsZWl0dXJh LCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8Oj byBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUu IFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBv IGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBz dWEgZGVzdHJ1acOnw6NvPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxi cj4NCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRl IGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdp YWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEg byBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5k aWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhDQogbGVjdHVyYSwgdXRpbGl6YWNpw7Nu LCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHBy b2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2li aWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlx dWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0 cnVjY2nDs24uPGJyPg0KPGJyPg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRy YW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50 ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQg YWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9u LA0KIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBp biBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUg c2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y IGFuZCB0aGVuIGRlbGV0ZSBpdC48YnI+DQo8YnI+DQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4 b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBj b250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJh IHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28g w6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNh ZG8gZGUgcXVlIGENCiBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPD s3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEg bGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywg cm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1l c21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvPGJyPg0KPC9mb250Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_2804D2DB130F45A8A61DF3C87B5E83ABtelefonicacom_-- From nobody Thu Jul 7 01:54: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 160ED12D618 for ; Thu, 7 Jul 2016 01:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426] 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 Wr-879LhgQni for ; Thu, 7 Jul 2016 01:54:51 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855A412D169 for ; Thu, 7 Jul 2016 01:54:50 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail31.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 07 Jul 2016 10:54:11 +0200 X-IronPort-AV: E=Sophos;i="5.28,324,1464645600"; d="scan'208,217";a="913951950" Received: from he105660.emea1.cds.t-internal.com ([10.169.119.56]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES256-SHA; 07 Jul 2016 10:54:10 +0200 Received: from HE105662.EMEA1.cds.t-internal.com (10.169.119.58) by HE105660.emea1.cds.t-internal.com (10.169.119.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 7 Jul 2016 10:54:10 +0200 Received: from HE105662.EMEA1.cds.t-internal.com ([fe80::442c:834e:c489:d2c4]) by HE105662.emea1.cds.t-internal.com ([fe80::442c:834e:c489:d2c4%26]) with mapi id 15.00.1178.000; Thu, 7 Jul 2016 10:54:10 +0200 From: To: , Thread-Topic: Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUaAMqu/g Date: Thu, 7 Jul 2016 08:54:10 +0000 Message-ID: <53c05ed0042b4bb186b55fe1c71a2713@HE105662.emea1.cds.t-internal.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.171.164] Content-Type: multipart/alternative; boundary="_000_53c05ed0042b4bb186b55fe1c71a2713HE105662emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 08:54:56 -0000 --_000_53c05ed0042b4bb186b55fe1c71a2713HE105662emea1cdstintern_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCnN1cHBvcnQuDQoNCnJlZ2FyZHMNCg0KTmljDQoNClZvbjogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIEppbSBHdWljaGFyZCAoamd1aWNoYXIp DQpHZXNlbmRldDogTWl0dHdvY2gsIDYuIEp1bGkgMjAxNiAxNToxOA0KQW46IHNmY0BpZXRmLm9y Zw0KQmV0cmVmZjogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNm Yy1oaWVyYXJjaGljYWwtMDYNCg0KRGVhciBXRzoNCg0KVGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBj YWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtaGllcmFyY2hpY2FsLTA2IGFz IGEgV0cgZG9jdW1lbnQuIFRoZSBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1biBmb3IgMiB3ZWVr cyBlbmRpbmcgNy8yNS8yMDE2Lg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYSBjYWxsIGZv ciBhZG9wdGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29udGVudCBvZiB0aGUgZG9jdW1l bnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQgdGhlIFdHIHdpbGwg Zm9jdXMgaXRzIGVmZm9ydHMgb24gdGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZvcndhcmQs IGFuZCB1c2UgdGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFuZCBkb2N1 bWVudGluZyB0aGUgV0figJlzIGRlY2lzaW9ucy4NCg0KUGxlYXNlIGluZGljYXRlIHdoZXRoZXIg eW91IHN1cHBvcnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlmIG5vdCB3aHkuIElzc3VlcyB5b3Ug aGF2ZSB3aXRoIHRoZSBjdXJyZW50IGRvY3VtZW50IGl0c2VsZiBjYW4gYWxzbyBiZSByYWlzZWQs IGJ1dCB0aGV5IHNob3VsZCBiZSByYWlzZWQgaW4gdGhlIGNvbnRleHQgb2Ygd2hhdCBzaG91bGQg YmUgY2hhbmdlZCBpbiB0aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVyIHRoYW4gYSBw cmUtY29uZGl0aW9uIGZvciBhZG9wdGlvbi4NCg0KRmluYWxseSwgbm93IGlzIGFsc28gYSBnb29k IHRpbWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRo aXMgZHJhZnQsIGluIGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1cmUgb2JsaWdhdGlvbnMgZm9y IFdHIHBhcnRpY2lwYW50cyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3Ig bW9yZSBkZXRhaWxzKS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3IgcGxl YXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCAodG8gdGhlIGNoYWlycykgd2hldGhlciBvciBub3Qg eW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KDQpUaGFua3MhDQoNClNGQyBDaGFp cnMNCg== --_000_53c05ed0042b4bb186b55fe1c71a2713HE105662emea1cdstintern_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5zdXBwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cmVnYXJkczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Vm9uOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPkltIEF1ZnRyYWcgdm9uIDwvYj5KaW0gR3VpY2hhcmQgKGpndWljaGFyKTxi cj4NCjxiPkdlc2VuZGV0OjwvYj4gTWl0dHdvY2gsIDYuIEp1bGkgMjAxNiAxNToxODxicj4NCjxi PkFuOjwvYj4gc2ZjQGlldGYub3JnPGJyPg0KPGI+QmV0cmVmZjo8L2I+IFtzZmNdIENhbGwgZm9y IFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+RGVhciBXRzo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 YmxhY2siPlRoaXMgZW1haWwgc2VydmVzIGFzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJh ZnQtcGVubm8tc2ZjLWhpZXJhcmNoaWNhbC0wNiBhcyBhIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBm b3IgYWRvcHRpb24gd2lsbCBydW4gZm9yIDIgd2Vla3MgZW5kaW5nIDcvMjUvMjAxNi48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5QbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMg YSBjYWxsIGZvciBhZG9wdGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29udGVudCBvZiB0 aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQgdGhl IFdHIHdpbGwgZm9jdXMgaXRzIGVmZm9ydHMgb24gdGhhdA0KIHBhcnRpY3VsYXIgZHJhZnQgZ29p bmcgZm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRvY3VtZW50IGZvciByZXNvbHZpbmcgb3BlbiBpc3N1 ZXMgYW5kIGRvY3VtZW50aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25zLjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6YmxhY2siPlBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0 IGFkb3B0aW9uIGZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJc3N1ZXMgeW91IGhhdmUgd2l0aCB0 aGUgY3VycmVudCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28gYmUgcmFpc2VkLCBidXQgdGhleSBz aG91bGQgYmUgcmFpc2VkIGluIHRoZSBjb250ZXh0DQogb2Ygd2hhdCBzaG91bGQgYmUgY2hhbmdl ZCBpbiB0aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVyIHRoYW4gYSBwcmUtY29uZGl0 aW9uIGZvciBhZG9wdGlvbi4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs YWNrIj5GaW5hbGx5LCBub3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBwb2xsIGZvciBrbm93bGVk Z2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgaW4gbGluZSB3aXRoIHRo ZSBJUFIgZGlzY2xvc3VyZSBvYmxpZ2F0aW9ucyBmb3IgV0cgcGFydGljaXBhbnRzIChzZWUgUkZD cyAzOTc5LA0KIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuIElmIHlvdSBh cmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1h aWwgKHRvIHRoZSBjaGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJl bGV2YW50IElQUi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2si PlRoYW5rcyE8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlNG QyBDaGFpcnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_53c05ed0042b4bb186b55fe1c71a2713HE105662emea1cdstintern_-- From nobody Thu Jul 7 02:02: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 6F74412B078 for ; Thu, 7 Jul 2016 02:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 ATLgF3vc3ILE for ; Thu, 7 Jul 2016 02:02:06 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD66912B015 for ; Thu, 7 Jul 2016 02:02:05 -0700 (PDT) Received: from smtpjc.telefonica.com (tgtimjc802.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EF1A92D0260; Thu, 7 Jul 2016 11:02:03 +0200 (CEST) Received: from ESTGVMSP111.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP111", Issuer "ESTGVMSP111" (not verified)) by smtpjc.telefonica.com (Postfix) with ESMTPS id D60C62D0249; Thu, 7 Jul 2016 11:02:03 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.54) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Jul 2016 11:02:03 +0200 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) with Microsoft SMTP Server (TLS) id 15.1.534.14; Thu, 7 Jul 2016 09:02:01 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0534.020; Thu, 7 Jul 2016 09:02:01 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: "Dirk.von-Hugo@telekom.de" , "anil.ietf@gmail.com" , "sfc@ietf.org" Thread-Topic: [sfc] Query on SFC/SFP High Availablility Thread-Index: AQHR12AggApUVLZVf0+OHzZ9VioGi6AMzzgA Date: Thu, 7 Jul 2016 09:02:01 +0000 Message-ID: References: <05C81A773E48DD49B181B04BA21A342A41F45BA315@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A41F45BA315@HE113484.emea1.cds.t-internal.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-ms-office365-filtering-correlation-id: a6547f6f-2274-4c2c-f976-08d3a6455bf7 x-microsoft-exchange-diagnostics: 1; DB4PR06MB0639; 6:tXMkun1qF2wqrk/rdcWdWLJBgDRsX4rZcGfEf7S+YjdNbyvtpRA3ufdWIr3Eor/q5Pnl4FplPOWJNuUPtA4cLCUugN8lV3ZH3pT8hOVt8o15o5HK4c3BAyMMfHk6aG+UxPfAYsDtrl16ApypR8TCWJ691YyPNUnLOTdEK1LqTknz9kKdv0WWyydVadnQqXWK1EIlQuijWUq97+LTe4K9zag34sMU8WGHIXOa+/JCMU3vvhet1rL9ajDWUO8msUuWwjBONs1Pj5rwaVnUd6agfxRKBIe0xmtTcaF1NfkWGyE=; 5:nkBZbbZ6PzYd4yxjfBVnI67y+jH2anpGyZNvbqs++sloRV3Bcx3N51rLp8qIOjmeBSvaEhEsUFexBclmSlYydKkPgw5IM77tKBExugtFbDfSDraGbeN8oyUtez6zCloNBW1TnO0S1QKggPXA4bMOMw==; 24:lQOPVHdEzwO0NjuOkKEvWE2k2WG5GpZLPxpHRwLD7zRPx61WYfCmLfd54J2JQOO9EiOI1IAvJu/4E7ecJWWUfSLLoR3i33H1Rx/vIIBoew0=; 7:Bd3Fc0xtIFArtcXPl/P3H9NaiCtLXr6HAP3ByHl2GxgvRK5gpB/HpvqlILFqGoUVHEe60snEH6ODO81HE30rEbXXNvzkhpTA7TGwO2ZigtI8lXcpv29u4tMraff5h+n3RE2TPahxwy7FaZaooajkc620m9Qv+SNsfm7idrxiiRH0tIskDIFPuN9IsSZlZV3jK3d0sxT17NfT7GkWwbjMw1me+fBT4mu4QRPyeQK4RfrlTVA/b0MsdlnUEsZd1Ey1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR06MB0639; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0639; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(189002)(199003)(53754006)(10400500002)(122556002)(66066001)(5002640100001)(11100500001)(92566002)(8936002)(19300405004)(16236675004)(36756003)(106116001)(106356001)(105586002)(2906002)(4326007)(19617315012)(19625215002)(83506001)(97736004)(3660700001)(7906003)(87936001)(7736002)(82746002)(7846002)(5001770100001)(83716003)(50986999)(189998001)(54356999)(76176999)(2201001)(33656002)(4001350100001)(3280700002)(2950100001)(2900100001)(81156014)(8676002)(81166006)(3846002)(102836003)(6116002)(19580405001)(586003)(2501003)(19580395003)(86362001)(575784001)(101416001)(68736007)(77096005)(15975445007)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0639; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A9390AB1C46F4843B49F96B8115B3815telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 09:02:01.3192 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0639 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Cc: "anil.sn@huawei.com" , "gaurav.agrawal@huawei.com" , "mohamed.boucadair@orange.com" , "sarikaya@ieee.org" , "vinods.kumar@gmail.com" Subject: Re: [sfc] Query on SFC/SFP High Availablility X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 09:02:10 -0000 --_000_A9390AB1C46F4843B49F96B8115B3815telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzLA0KDQpBIGNvdXBsZSBvZiBjb21tZW50cyByZWdhcmRpbmcgdGhlIHJlZmVy ZW5jZWQgSS1EOg0KDQpTZWN0aW9uIDMuMToNCg0KDQoxLiAgICAgICBVbmlmeSDigJhQYXJlbnRh bCBjb250cm9sIHNlcnZpY2UgZnVuY3Rpb27igJkgYW5kIOKAmFBhcmVudGFsIGNvbnRyb2wgZnVu Y3Rpb27igJkNCg0KMi4gICAgICAgVXNlIGFydGljbGVzIHdoZW4gc2luZ3VsYXIgaXMgaW50ZW5k ZWQgKGkuZS4gVGhlIHBhcmVudGFsIGNvbnRyb2wgKHNlcnZpY2UpIGZ1bmN0aW9uKSBvciBwbHVy YWwgKHdoaWNoIEkgdGhpbmsgc2hvdWxkIGJlIHRoZSBjYXNlIGluIHRoaXMgc2VjdGlvbiBleGNl cHQgaW4gdGhlIGZpcnN0IHNlbnRlbmNlKQ0KDQozLiAgICAgICBzL3NvIHRoYXQgdXBzdHJlYW0g ZnVuY3Rpb24vc28gdGhhdCB1cHN0cmVhbSBmdW5jdGlvbnMvDQoNClNlY3Rpb24gMy40DQpzL3Nv LWNhbGxlZCDigJg1R+KAmS9zby1jYWxsZWQgNUcvDQpUaGUgaHlwaGVucyBzaG93IGEgaGlnaCBs ZXZlbCBvZiBzY2VwdGljaXNtIDstKQ0KDQpQYWdlIDgNCg0Kcy9DYW4gYmUgSVB2NCBvciBJUHY2 IGFkZHJlc3MsIElQdjYgcHJlZml4L0NhbiBiZSBhbiBJUHY0IG9yIElQdjYgYWRkcmVzcywgYW4g SVB2NiBwcmVmaXgvDQoNCg0KDQotLS0NCkRyLiBQZWRybyBBLiBBcmFuZGEgR3V0acOpcnJleg0K DQpUZWNobm9sb2d5IEV4cGxvcmF0aW9uDQplbWFpbDogcGVkcm9hIGQwdCBhcmFuZGEgQXQgdGVs ZWZvbmljYSBkMHQgY29tDQpUZWxlZsOzbmljYSwgSW52ZXN0aWdhY2nDs24geSBEZXNhcnJvbGxv IOKAkyBHQ1RPIFVuaXQNCkMvIFp1cmJhcsOhbiwxMg0KMjgwMTAgTWFkcmlkLCBTcGFpbg0KDQpG cmFnZW4gc2luZCBuaWNodCBkYSwgdW0gYmVhbnR3b3J0ZXQgenUgd2VyZGVuLg0KRnJhZ2VuIHNp bmQgZGEsIHVtIGdlc3RlbGx0IHp1IHdlcmRlbi4NCg0KR2VvcmcgS3JlaXNsZXINCg0KRGU6IHNm YyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+IGVuIG5vbWJyZSBkZSAiRGlyay52b24tSHVnb0B0ZWxl a29tLmRlIiA8RGlyay52b24tSHVnb0B0ZWxla29tLmRlPg0KRmVjaGE6IG1pw6lyY29sZXMsIDYg ZGUganVsaW8gZGUgMjAxNiwgMTA6MjcNClBhcmE6ICJhbmlsLmlldGZAZ21haWwuY29tIiA8YW5p bC5pZXRmQGdtYWlsLmNvbT4sICJzZmNAaWV0Zi5vcmciIDxzZmNAaWV0Zi5vcmc+DQpDQzogImFu aWwuc25AaHVhd2VpLmNvbSIgPGFuaWwuc25AaHVhd2VpLmNvbT4sICJnYXVyYXYuYWdyYXdhbEBo dWF3ZWkuY29tIiA8Z2F1cmF2LmFncmF3YWxAaHVhd2VpLmNvbT4sICJtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4sICJzYXJpa2F5YUBp ZWVlLm9yZyIgPHNhcmlrYXlhQGllZWUub3JnPiwgInZpbm9kcy5rdW1hckBnbWFpbC5jb20iIDx2 aW5vZHMua3VtYXJAZ21haWwuY29tPg0KQXN1bnRvOiBSZTogW3NmY10gUXVlcnkgb24gU0ZDL1NG UCBIaWdoIEF2YWlsYWJsaWxpdHkNCg0KRGVhciBBbmlsLA0KUGxlYXNlIHNlZSB0aGUgdXBkYXRl ZCB2ZXJzaW9uIG9mIG91ciBzZXJ2aWNlIGhlYWRlciBkcmFmdCBhdmFpbGFibGUgaGVyZSBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FyaWtheWEtc2ZjLWhvc3RpZC1zZXJ2aWNl aGVhZGVyLTAzDQpXZSBoYXZlIGFkZGVkIGEgbmV3IFRMViB0eXBlIGluIHRoZSBoZWFkZXIgdG8g Y2FycnkgbWV0YWRhdGEgb24gc2xpY2UgYW5kIHNlcnZpY2Ugc3BlY2lmaWMgcmVxdWlyZW1lbnRz IHN1Y2ggYXMgdmVyeSBsb3cgbGF0ZW5jeSBvciBoaWdoIHJlbGlhYmlsaXR5Lg0KWW91IGFyZSB2 ZXJ5IHdlbGNvbWUgdG8gcGxlYXNlIHBvc3QgeW91ciBjb21tZW50cywgc3VnZ2VzdGlvbnMsIGFu ZCBxdWVzdGlvbnMgLSBhbmQgd2hldGhlciB0aGlzIGFkZHJlc3NlcyB5b3VyIHJlcXVlc3QhDQpU aGFua3MhDQpCZXN0IFJlZ2FyZHMNCkRpcmsNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5pbCBLdW1hcg0KU2VudDogTWl0dHdvY2gsIDI5LiBK dW5pIDIwMTYgMTU6MzkNClRvOiBzZmNAaWV0Zi5vcmcNCkNjOiBBbmlsIEt1bWFyIFMgTjsgR2F1 cmF2IGFncmF3YWw7IFZpbm9kIEt1bWFyDQpTdWJqZWN0OiBbc2ZjXSBRdWVyeSBvbiBTRkMvU0ZQ IEhpZ2ggQXZhaWxhYmxpbGl0eQ0KDQpIaSBBbGwsDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiBz b21lIHdvcmsgaXMgZG9uZSBpbiB0aGUgYXJlYSBvZiBoaWdoIGF2YWlsYWJpbGl0eSBmb3IgU0ZQ LCB3ZSBjb3VsZG4ndCBmaW5kIGl0IGZyb20gbGlzdCBvZiBhdmFpbGFibGUgZHJhZnRzLg0KDQpX aXRoIFJlZ2FyZHMsDQpBbmlsIEt1bWFyIFMgTg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBl eGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNp w7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBk ZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVz dGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1 dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVl ZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4g U2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9z IGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2Vk YSBhIHN1IGRlc3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24g aW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFt ZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhl IHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciBhbmQgdGhlbiBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBk aXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBp bmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4 Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3Nz YSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBx dWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0g YXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOn w6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1s aGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBl IHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQo= --_000_A9390AB1C46F4843B49F96B8115B3815telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <7F2374BCB3556447BEA940E1471232EA@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpBcmlhbDsNCglwYW5v c2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJD YW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCI7DQoJcGFub3NlLTE6MiAxNSAzIDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29s YXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiA1IDkgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpoMQ0K CXttc28tc3R5bGUtbGluazoiVMOtdHVsbyAxIENhciI7DQoJbWFyZ2luLXRvcDoxMi4wcHQ7DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDoyMS42 cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0 LWluZGVudDotMjEuNnB0Ow0KCWxpbmUtaGVpZ2h0OjEyMCU7DQoJcGFnZS1icmVhay1hZnRlcjph dm9pZDsNCgltc28tbGlzdDpsMSBsZXZlbDEgbGZvNTsNCglmb250LXNpemU6MTYuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IjsNCglmb250LXZhcmlhbnQ6c21hbGwtY2FwczsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpJVDsNCglmb250LXdlaWdodDpub3JtYWw7fQ0KaDINCgl7bXNv LXN0eWxlLWxpbms6IlTDrXR1bG8gMiBDYXIiOw0KCW1hcmdpbi10b3A6MTguMHB0Ow0KCW1hcmdp bi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTo2LjBwdDsNCgltYXJnaW4tbGVmdDoyOC44cHQ7 DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtaW5kZW50Oi0yOC44cHQ7DQoJbGluZS1oZWln aHQ6MTIwJTsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1zby1saXN0OmwwIGxldmVsMiBs Zm83Ow0KCWZvbnQtc2l6ZToxNC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOklUOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDt9DQpoMw0KCXtt c28tc3R5bGUtbGluazoiVMOtdHVsbyAzIENhciI7DQoJbWFyZ2luLXRvcDoxOC4wcHQ7DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjYuMHB0Ow0KCW1hcmdpbi1sZWZ0OjM2LjBw dDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1pbmRlbnQ6LTM2LjBwdDsNCglsaW5lLWhl aWdodDoxMjAlOw0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDAgbGV2ZWwz IGxmbzc7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCI7 DQoJZm9udC12YXJpYW50OnNtYWxsLWNhcHM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SVQ7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdp bi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uVHR1bG8zQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJU w610dWxvIDMgQ2FyIjsNCgltc28tc3R5bGUtbGluazoiVMOtdHVsbyAzIjsNCglmb250LWZhbWls eToiQ2FsaWJyaSBMaWdodCI7DQoJZm9udC12YXJpYW50OnNtYWxsLWNhcHM7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6SVQ7fQ0Kc3Bhbi5UdHVsbzJDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlTDrXR1 bG8gMiBDYXIiOw0KCW1zby1zdHlsZS1saW5rOiJUw610dWxvIDIiOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIExpZ2h0IjsNCglmb250LXZhcmlhbnQ6c21hbGwtY2FwczsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpJVDt9DQpzcGFuLlR0dWxvMUNhcg0KCXttc28tc3R5bGUtbmFtZToiVMOtdHVsbyAx IENhciI7DQoJbXNvLXN0eWxlLWxpbms6IlTDrXR1bG8gMSI7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkgTGlnaHQiOw0KCWZvbnQtdmFyaWFudDpzbWFsbC1jYXBzOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOklUO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxl LW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOi01Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMjA2NDI4NDg7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiUxOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMS42 cHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjZwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LXN0eWxlLWxpbms6IlTDrXR1bG8gMiI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4lMiI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjI4LjhwdDsNCgl0ZXh0LWluZGVudDotMjguOHB0O30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiVMOtdHVsbyAzIjsNCgltc28tbGV2ZWwtdGV4 dDoiJTFcLiUyXC4lMyI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgl0ZXh0LWluZGVudDot MzYuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wu JTQiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDo0My4ycHQ7DQoJdGV4dC1pbmRlbnQ6LTQzLjJwdDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNSI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjUwLjRwdDsNCgl0ZXh0LWluZGVudDotNTAuNHB0O30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNiI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjU3LjZwdDsNCgl0ZXh0LWluZGVudDotNTcuNnB0O30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTciOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDo2NC44cHQ7DQoJdGV4dC1pbmRlbnQ6LTY0LjhwdDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNVwuJTZcLiU3XC4lOCI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjcyLjBwdDsNCgl0ZXh0LWluZGVudDotNzIuMHB0O30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTdc LiU4XC4lOSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojc5LjJwdDsNCgl0ZXh0LWluZGVudDotNzkuMnB0 O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjYwMjU0MTkzOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxOTAwODY4NzY0O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3R5bGUtbGlu azoiVMOtdHVsbyAxIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTQuMHB0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1sZWdhbC1mb3JtYXQ6eWVzOw0K CW1zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojk2LjU1cHQ7DQoJ dGV4dC1pbmRlbnQ6LTQyLjU1cHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC10ZXh0 OiIlMVwuJTJcLiUzXC4iOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5Ny4ycHQ7DQoJdGV4dC1pbmRlbnQ6 LTI1LjJwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNc LiU0XC4iOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjIuNHB0Ow0KCXRleHQtaW5kZW50Oi0zMi40cHQ7 fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzXC4lNFwuJTVc LiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE0Ny42cHQ7DQoJdGV4dC1pbmRlbnQ6LTM5LjZwdDt9DQpA bGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNVwuJTZc LiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE3Mi44cHQ7DQoJdGV4dC1pbmRlbnQ6LTQ2LjhwdDt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNVwuJTZc LiU3XC4iOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxOTguMHB0Ow0KCXRleHQtaW5kZW50Oi01NC4wcHQ7 fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzXC4lNFwuJTVc LiU2XC4lN1wuJThcLiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIyMy4ycHQ7DQoJdGV4dC1pbmRlbnQ6 LTYxLjJwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNc LiU0XC4lNVwuJTZcLiU3XC4lOFwuJTlcLiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI1Mi4wcHQ7DQoJ dGV4dC1pbmRlbnQ6LTcyLjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo2MzIxNzYxNjc7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDYzMzI4 NzA2IDY3NzY0MjM5IDY3NzY0MjQ5IDY3NzY0MjUxIDY3NzY0MjM5IDY3NzY0MjQ5IDY3NzY0MjUx IDY3NzY0MjM5IDY3NzY0MjQ5IDY3NzY0MjUxO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI3Ii8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIi8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRVMtVFJBRCIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkRlYXIgYXV0aG9ycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkEgY291cGxlIG9mIGNv bW1lbnRzIHJlZ2FyZGluZyB0aGUgcmVmZXJlbmNlZCBJLUQ6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TZWN0aW9uIDMuMToNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxm bzkiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlVuaWZ5IOKAmFBhcmVudGFsIGNvbnRyb2wgc2VydmljZSBmdW5j dGlvbuKAmSBhbmQg4oCYUGFyZW50YWwgY29udHJvbCBmdW5jdGlvbuKAmTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvOSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VXNlIGFydGlj bGVzIHdoZW4gc2luZ3VsYXIgaXMgaW50ZW5kZWQgKGkuZS4gVGhlIHBhcmVudGFsIGNvbnRyb2wg KHNlcnZpY2UpIGZ1bmN0aW9uKSBvciBwbHVyYWwgKHdoaWNoIEkgdGhpbmsgc2hvdWxkIGJlIHRo ZSBjYXNlIGluIHRoaXMNCiBzZWN0aW9uIGV4Y2VwdCBpbiB0aGUgZmlyc3Qgc2VudGVuY2UpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm85Ij48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5zL3NvIHRoYXQgdXBzdHJlYW0gZnVuY3Rpb24vc28gdGhhdCB1cHN0cmVhbSBmdW5jdGlvbnMv PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TZWN0aW9u IDMuNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5zL3NvLWNhbGxlZCDigJg1R+KAmS9zby1jYWxsZWQg NUcvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBoeXBoZW5zIHNob3cgYSBoaWdoIGxldmVsIG9m IHNjZXB0aWNpc20gOy0pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5QYWdlIDgNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+cy9DYW4gYmUgSVB2NCBvciBJUHY2IGFkZHJlc3MsIElQdjYgcHJlZml4L0NhbiBi ZSBhbiBJUHY0IG9yIElQdjYgYWRkcmVzcywgYW4gSVB2NiBwcmVmaXgvPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6YmxhY2siPkRyLiBQZWRybyBBLiBBcmFuZGEgR3V0acOpcnJlejxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj ayI+VGVjaG5vbG9neSBFeHBsb3JhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOmJsYWNrIj5lbWFpbDogcGVkcm9hIGQwdCBhcmFuZGEgQXQgdGVsZWZvbmlj YSBkMHQgY29tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPlRlbGVmw7NuaWNhLCBJbnZlc3RpZ2FjacOzbiB5IERlc2Fycm9sbG8g4oCTIEdDVE8gVW5p dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5DLyBa dXJiYXLDoW4sMTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+MjgwMTAgTWFkcmlkLCBTcGFpbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+RnJhZ2Vu IHNpbmQgbmljaHQgZGEsIHVtIGJlYW50d29ydGV0IHp1IHdlcmRlbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+RnJhZ2VuIHNpbmQgZGEsIHVtIGdl c3RlbGx0IHp1IHdlcmRlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5HZW9yZyBLcmVpc2xlcjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJs YWNrIj5EZTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2Nv bG9yOmJsYWNrIj5zZmMgJmx0O3NmYy1ib3VuY2VzQGlldGYub3JnJmd0OyBlbiBub21icmUgZGUg JnF1b3Q7RGlyay52b24tSHVnb0B0ZWxla29tLmRlJnF1b3Q7ICZsdDtEaXJrLnZvbi1IdWdvQHRl bGVrb20uZGUmZ3Q7PGJyPg0KPGI+RmVjaGE6IDwvYj5tacOpcmNvbGVzLCA2IGRlIGp1bGlvIGRl IDIwMTYsIDEwOjI3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlVO2NvbG9y OmJsYWNrIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7 Y29sb3I6YmxhY2siPlBhcmE6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7Y29sb3I6YmxhY2siPiZxdW90O2FuaWwuaWV0ZkBnbWFpbC5jb20mcXVvdDsgJmx0O2Fu aWwuaWV0ZkBnbWFpbC5jb20mZ3Q7LCAmcXVvdDtzZmNAaWV0Zi5vcmcmcXVvdDsgJmx0O3NmY0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5DQzogPC9iPiZxdW90O2FuaWwuc25AaHVhd2VpLmNvbSZxdW90 OyAmbHQ7YW5pbC5zbkBodWF3ZWkuY29tJmd0OywgJnF1b3Q7Z2F1cmF2LmFncmF3YWxAaHVhd2Vp LmNvbSZxdW90OyAmbHQ7Z2F1cmF2LmFncmF3YWxAaHVhd2VpLmNvbSZndDssICZxdW90O21vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mcXVvdDsgJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20mZ3Q7LCAmcXVvdDtzYXJpa2F5YUBpZWVlLm9yZyZxdW90OyAmbHQ7c2FyaWtheWFAaWVl ZS5vcmcmZ3Q7LCAmcXVvdDt2aW5vZHMua3VtYXJAZ21haWwuY29tJnF1b3Q7ICZsdDt2aW5vZHMu a3VtYXJAZ21haWwuY29tJmd0Ozxicj4NCjxiPkFzdW50bzogPC9iPlJlOiBbc2ZjXSBRdWVyeSBv biBTRkMvU0ZQIEhpZ2ggQXZhaWxhYmxpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9 Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5EZWFyIEFuaWwsPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIHRoZSB1cGRhdGVkIHZlcnNpb24g b2Ygb3VyIHNlcnZpY2UgaGVhZGVyIGRyYWZ0IGF2YWlsYWJsZSBoZXJlDQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIi PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYXJpa2F5YS1zZmMt aG9zdGlkLXNlcnZpY2VoZWFkZXItMDMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zYXJpa2F5YS1zZmMtaG9zdGlkLXNlcnZpY2VoZWFkZXItMDM8L2E+DQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOiMxRjQ5N0QiPldlIGhhdmUgYWRkZWQgYSBuZXcgVExWIHR5cGUgaW4gdGhl IGhlYWRlciB0byBjYXJyeSBtZXRhZGF0YSBvbiBzbGljZSBhbmQgc2VydmljZSBzcGVjaWZpYyBy ZXF1aXJlbWVudHMgc3VjaCBhcyB2ZXJ5IGxvdyBsYXRlbmN5IG9yIGhpZ2ggcmVsaWFiaWxpdHku PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5Zb3UgYXJlIHZlcnkgd2VsY29tZSB0 byBwbGVhc2UgcG9zdCB5b3VyIGNvbW1lbnRzLCBzdWdnZXN0aW9ucywgYW5kIHF1ZXN0aW9ucyAt IGFuZCB3aGV0aGVyIHRoaXMgYWRkcmVzc2VzIHlvdXIgcmVxdWVzdCE8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0O21hcmdpbi1sZWZ0OjBjbTt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjojMUY0OTdEIj5UaGFua3MhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDow Y207dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRz PGJyPg0KRGlyayA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hIj4g c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFu aWwgS3VtYXI8YnI+DQo8Yj5TZW50OjwvYj4gTWl0dHdvY2gsIDI5LiBKdW5pIDIwMTYgMTU6Mzk8 YnI+DQo8Yj5Ubzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gQW5pbCBLdW1hciBT IE47IEdhdXJhdiBhZ3Jhd2FsOyBWaW5vZCBLdW1hcjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2Zj XSBRdWVyeSBvbiBTRkMvU0ZQIEhpZ2ggQXZhaWxhYmxpbGl0eTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgQWxsLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBsZXQgdXMga25vdyBpZiBzb21lIHdvcmsg aXMgZG9uZSBpbiB0aGUgYXJlYSBvZiBoaWdoIGF2YWlsYWJpbGl0eSBmb3IgU0ZQLCB3ZSBjb3Vs ZG4ndCBmaW5kIGl0IGZyb20gbGlzdCBvZiBhdmFpbGFibGUgZHJhZnRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldpdGggUmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QW5pbCBLdW1hciBTIE48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxi cj4NCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRl IGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdp YWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEg byBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5k aWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhDQogbGVjdHVyYSwgdXRpbGl6YWNpw7Nu LCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHBy b2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2li aWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlx dWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0 cnVjY2nDs24uPGJyPg0KPGJyPg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRy YW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50 ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQg YWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9u LA0KIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBp biBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUg c2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y IGFuZCB0aGVuIGRlbGV0ZSBpdC48YnI+DQo8YnI+DQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4 b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBj b250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJh IHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28g w6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNh ZG8gZGUgcXVlIGENCiBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPD s3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEg bGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywg cm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1l c21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvPGJyPg0KPC9mb250Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_A9390AB1C46F4843B49F96B8115B3815telefonicacom_-- From nobody Thu Jul 7 02:02: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 76D7412D169 for ; Thu, 7 Jul 2016 02:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 l3xERgUJeFLt for ; Thu, 7 Jul 2016 02:02:40 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A1612B078 for ; Thu, 7 Jul 2016 02:02:40 -0700 (PDT) Received: from smtpjc.telefonica.com (tgtimjc802.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6524F2D066C for ; Thu, 7 Jul 2016 11:02:37 +0200 (CEST) Received: from ESTGVMSP102.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP102", Issuer "ESTGVMSP102" (not verified)) by smtpjc.telefonica.com (Postfix) with ESMTPS id 4B1762D066B for ; Thu, 7 Jul 2016 11:02:37 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.49) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Jul 2016 11:02:35 +0200 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2166.eurprd06.prod.outlook.com (10.168.57.25) with Microsoft SMTP Server (TLS) id 15.1.523.4; Thu, 7 Jul 2016 09:02:34 +0000 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) with mapi id 15.01.0523.019; Thu, 7 Jul 2016 09:02:34 +0000 From: "Diego R. Lopez" To: "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUaAMqu/ggAACmQA= Date: Thu, 7 Jul 2016 09:02:34 +0000 Message-ID: References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> <53c05ed0042b4bb186b55fe1c71a2713@HE105662.emea1.cds.t-internal.com> In-Reply-To: <53c05ed0042b4bb186b55fe1c71a2713@HE105662.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [88.20.193.224] x-ms-office365-filtering-correlation-id: 70404e6c-8cc5-4b8c-d904-08d3a6456f7c x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2166; 6:NzkGZZSPrI2gdwKViad2AGMfxiyHcqF6yPqiy7yXPj/anQOsXw2eCXnYjAVrehLUv0zQ7f4Dx6UFokuF5EP+1NtR9KBj+z+oOcYzKDcdO+QsMEXSLOvsIWR1e79R1Qj6v87aYEL4AwxeIv446De1mqo7TGgsYEkJOaznO1yCI+Si4GV5ETyADe1Uq9E1qRWQk/tmgpcXJdyf7Pm1TZ15iPio6E3d1duK5lymUq9ZO3/UzEU2ftcU1K6uVjY6WlrPr5VmFIROm1NOy4S8jXy5rAEOKtS7VQwbrBHOoAxenK3z5V3vymU69oXtqdcS0/lH; 5:hXoEbn/AjlhQJAOFRiEZqwFnt7eemfMXEHL59KZePT0KO48vJ8/pYQg2DLA2qRdNzdtjDNMXbbT23YH+arhlurocJuJAdQ6G899al70bf0Ru53Yr6IlatGmvnY3+0UnHgAqGKMQWGjEFN0RDGC9oPg==; 24:eCNyDiltDAJLvh+CmMe8aVwJ7tEcpOsG6riENaNMbZ/nZi8AsyTDm9cKbvaDpF97xRZd5E2/ASl6XU29YVtu1TtoY9DhcekqQWUUZQDTBng=; 7:Mmq23mVZW64lZ6L+eZ5XKxQGc2sHveG+5Cqd9sax75/y4VyKZ7Meiqk9oJ1Fb6zUdxXM/1TWTNv6/ggLbUR08V84jk2k8dKTvqptdczm6AgXk24rewWK0th7xGnt4cLBfHvZR2liRhJI/WBBqx8JCXAyeeqdLyTme98B1FTtfqr5EK9WO2CBfrHgwOgojj+bWp4IlLp9xrCY/YTZL+pJAYY2ChHEy5zXHQ1IW5Tdj3QODFv3AyZteQlxObWLeB8DcjJWtz0HxMDgfST5m71y5g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0601MB2166; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB6PR0601MB2166; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2166; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(252514010)(24454002)(189002)(105586002)(106116001)(5640700001)(110136002)(106356001)(3660700001)(81156014)(82746002)(10400500002)(19580395003)(5002640100001)(97736004)(19580405001)(83716003)(189998001)(230783001)(1730700003)(81166006)(8676002)(33656002)(2900100001)(6116002)(2906002)(586003)(8936002)(16236675004)(87936001)(7736002)(3280700002)(36756003)(54356999)(2501003)(19617315012)(50986999)(68736007)(7846002)(15975445007)(77096005)(66066001)(76176999)(101416001)(107886002)(86362001)(2351001)(122556002)(92566002)(11100500001)(3846002)(2950100001)(450100001)(102836003)(7906003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2166; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BC6167C2DDD140E8BACD471FF1CFE25Ftelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 09:02:34.1978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2166 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 09:02:43 -0000 --_000_BC6167C2DDD140E8BACD471FF1CFE25Ftelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29hdXRob3IgKzENCg0KT24gNyBKdWwgMjAxNiwgYXQgMTA6NTQgLCBOLkxleW1hbm5AdGVsZWtv bS5kZTxtYWlsdG86Ti5MZXltYW5uQHRlbGVrb20uZGU+IHdyb3RlOg0KDQpIaSwNCg0Kc3VwcG9y dC4NCg0KcmVnYXJkcw0KDQpOaWMNCg0KVm9uOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gSW0gQXVmdHJhZyB2b24gSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNCkdlc2VuZGV0OiBN aXR0d29jaCwgNi4gSnVsaSAyMDE2IDE1OjE4DQpBbjogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQpCZXRyZWZmOiBbc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1k b2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNg0KDQpEZWFyIFdHOg0KDQpUaGlzIGVtYWlsIHNlcnZl cyBhcyBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy1oaWVyYXJjaGlj YWwtMDYgYXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgcnVuIGZv ciAyIHdlZWtzIGVuZGluZyA3LzI1LzIwMTYuDQoNClBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBh IGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEgbGFzdCBjYWxsIGZvciBjb250ZW50IG9mIHRo ZSBkb2N1bWVudC4gQWRvcHRpbmcgYSBXRyBkb2N1bWVudCBzaW1wbHkgbWVhbnMgdGhhdCB0aGUg V0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0IHBhcnRpY3VsYXIgZHJhZnQgZ29pbmcg Zm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRvY3VtZW50IGZvciByZXNvbHZpbmcgb3BlbiBpc3N1ZXMg YW5kIGRvY3VtZW50aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25zLg0KDQpQbGVhc2UgaW5kaWNhdGUg d2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBmb3Igbm90LCBhbmQgaWYgbm90IHdoeS4gSXNz dWVzIHlvdSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNhbiBhbHNvIGJl IHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNlZCBpbiB0aGUgY29udGV4dCBvZiB3aGF0 IHNob3VsZCBiZSBjaGFuZ2VkIGluIHRoZSBkb2N1bWVudCBnb2luZyBmb3J3YXJkLCByYXRoZXIg dGhhbiBhIHByZS1jb25kaXRpb24gZm9yIGFkb3B0aW9uLg0KDQpGaW5hbGx5LCBub3cgaXMgYWxz byBhIGdvb2QgdGltZSB0byBwb2xsIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxp ZXMgdG8gdGhpcyBkcmFmdCwgaW4gbGluZSB3aXRoIHRoZSBJUFIgZGlzY2xvc3VyZSBvYmxpZ2F0 aW9ucyBmb3IgV0cgcGFydGljaXBhbnRzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1 Mzc4IGZvciBtb3JlIGRldGFpbHMpLiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1 dGhvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsICh0byB0aGUgY2hhaXJzKSB3aGV0aGVy IG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuDQoNClRoYW5rcyENCg0K U0ZDIENoYWlycw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KLS0NCiJFc3RhIHZl eiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpU ZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFp bDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbQ0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDEN Ck1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWpl IHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFy aW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNp YWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVz dGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90 aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9v IGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQg ZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBw b3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUg cG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBh bmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRo aXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcg b2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxl YXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3Rh IG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUg ZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBj b25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRl IGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGlu ZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBk aXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9p YmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEg bWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlh dGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0K --_000_BC6167C2DDD140E8BACD471FF1CFE25Ftelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQ29hdXRob3IgJiM0MzsxDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gNyBKdWwgMjAxNiwgYXQgMTA6NTQg LCA8YSBocmVmPSJtYWlsdG86Ti5MZXltYW5uQHRlbGVrb20uZGUiIGNsYXNzPSIiPg0KTi5MZXlt YW5uQHRlbGVrb20uZGU8L2E+IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi IHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBMdWNpZGFHcmFuZGU7IGZv bnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5IaSw8bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+c3VwcG9ydC48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+cmVnYXJkczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5OaWM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25l IG5vbmU7IGJvcmRlci10b3AtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLXRvcC13 aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGNtIDBjbTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj5Wb246PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5J bQ0KIEF1ZnRyYWcgdm9uPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5KaW0gR3VpY2hhcmQgKGpndWljaGFyKTxiciBjbGFzcz0iIj4NCjxiIGNsYXNz PSIiPkdlc2VuZGV0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+TWl0dHdvY2gsIDYuIEp1bGkgMjAxNiAxNToxODxiciBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPkFuOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+c2ZjQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkJldHJlZmY6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBv ZiBkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDlwdDsgZm9udC1mYW1pbHk6IENvbnNvbGFzOyIgY2xhc3M9IiI+RGVhciBXRzo8L3NwYW4+ PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9IiIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlw dDsgZm9udC1mYW1pbHk6IENvbnNvbGFzOyIgY2xhc3M9IiI+VGhpcyBlbWFpbCBzZXJ2ZXMgYXMg YSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtaGllcmFyY2hpY2FsLTA2 IGFzIGEgV0cgZG9jdW1lbnQuIFRoZSBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1biBmb3IgMiB3 ZWVrcyBlbmRpbmcgNy8yNS8yMDE2Ljwvc3Bhbj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IiBjbGFz cz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQ29u c29sYXM7IiBjbGFzcz0iIj5QbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYSBjYWxsIGZvciBhZG9w dGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29udGVudCBvZiB0aGUgZG9jdW1lbnQuIEFk b3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQgdGhlIFdHIHdpbGwgZm9jdXMg aXRzIGVmZm9ydHMgb24gdGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nDQogZm9yd2FyZCwgYW5k IHVzZSB0aGF0IGRvY3VtZW50IGZvciByZXNvbHZpbmcgb3BlbiBpc3N1ZXMgYW5kIGRvY3VtZW50 aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25zLjwvc3Bhbj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IiBj bGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTog Q29uc29sYXM7IiBjbGFzcz0iIj5QbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBh ZG9wdGlvbiBmb3Igbm90LCBhbmQgaWYgbm90IHdoeS4gSXNzdWVzIHlvdSBoYXZlIHdpdGggdGhl IGN1cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNhbiBhbHNvIGJlIHJhaXNlZCwgYnV0IHRoZXkgc2hv dWxkIGJlIHJhaXNlZCBpbiB0aGUgY29udGV4dCBvZiB3aGF0IHNob3VsZA0KIGJlIGNoYW5nZWQg aW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQsIHJhdGhlciB0aGFuIGEgcHJlLWNvbmRpdGlv biBmb3IgYWRvcHRpb24uJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsiIGNsYXNz PSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBDb25z b2xhczsiIGNsYXNzPSIiPkZpbmFsbHksIG5vdyBpcyBhbHNvIGEgZ29vZCB0aW1lIHRvIHBvbGwg Zm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCBpbiBs aW5lIHdpdGggdGhlIElQUiBkaXNjbG9zdXJlIG9ibGlnYXRpb25zIGZvciBXRyBwYXJ0aWNpcGFu dHMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yDQogbW9yZSBkZXRhaWxz KS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3IgcGxlYXNlIHJlc3BvbmQg dG8gdGhpcyBlbWFpbCAodG8gdGhlIGNoYWlycykgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgcmVsZXZhbnQgSVBSLjwvc3Bhbj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj4mbmJzcDs8L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQ29uc29sYXM7IiBj bGFzcz0iIj5UaGFua3MhPC9zcGFuPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBDb25zb2xhczsiIGNsYXNzPSIi PlNGQyBDaGFpcnM8L3NwYW4+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogTHVjaWRhR3JhbmRlOyBmb250LXNpemU6IDExcHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTog aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBMdWNpZGFH cmFuZGU7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogTHVjaWRhR3JhbmRl OyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5zZmMN CiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogTHVjaWRhR3JhbmRl OyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBMdWNpZGFH cmFuZGU7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTog THVjaWRhR3JhbmRlOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogTHVjaWRhR3JhbmRlOyBmb250LXNpemU6IDExcHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRy dWUiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQotLTxiciBjbGFz cz0iIj4NCiZxdW90O0VzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyZxdW90 OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkRyIERpZWdvIFIuIExvcGV6PGJyIGNsYXNz PSIiPg0KVGVsZWZvbmljYSBJJiM0MztEPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3Bl b3BsZS50aWQuZXMvZGllZ28ubG9wZXovIiBjbGFzcz0iIj5odHRwOi8vcGVvcGxlLnRpZC5lcy9k aWVnby5sb3Blei88L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KZS1tYWlsOiBkaWVn by5yLmxvcGV6QHRlbGVmb25pY2EuY29tPGJyIGNsYXNzPSIiPg0KVGVsOiAmbmJzcDsgJm5ic3A7 JiM0MzszNCA5MTMgMTI5IDA0MTxiciBjbGFzcz0iIj4NCk1vYmlsZTogJiM0MzszNCA2ODIgMDUx IDA5MTxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2Rp dj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxicj4NCkVzdGUgbWVuc2FqZSB5IHN1cyBh ZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVk ZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMg cGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNp IG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8g ZGUgcXVlIGxhDQogbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlh IHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEg bGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJy b3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVz dGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uPGJyPg0KPGJyPg0KVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2Vk IGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2Yg dGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLA0KIGRpc3RyaWJ1dGlvbiBvciBjb3B5 aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQu IFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC48YnI+ DQo8YnI+DQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFt ZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZp bGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29h IG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0 aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGENCiBsZWl0dXJhLCB1 dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBw b2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNl IHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNv bXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEg ZGVzdHJ1acOnw6NvPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BC6167C2DDD140E8BACD471FF1CFE25Ftelefonicacom_-- From nobody Thu Jul 7 02: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 CBE0B12D15F for ; Thu, 7 Jul 2016 02:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 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.426, 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 E4-OpB6bYeRO for ; Thu, 7 Jul 2016 02:36:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id BEB9B12D15A for ; Thu, 7 Jul 2016 02:36:44 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id D21478D4C4049 for ; Thu, 7 Jul 2016 17:36:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u679aSOD096068 for ; Thu, 7 Jul 2016 17:36:28 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) To: "sfc@ietf.org" MIME-Version: 1.0 X-KeepSent: D3DCDC26:86C92819-48257FE9:00346BF4; 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, 7 Jul 2016 17:36:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-07 17:36:28, Serialize complete at 2016-07-07 17:36:28 Content-Type: multipart/alternative; boundary="=_alternative 0034C92548257FE9_=" X-MAIL: mse01.zte.com.cn u679aSOD096068 Archived-At: Subject: [sfc] New Version Notification for draft-jing-sfc-flow-release-notify-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, 07 Jul 2016 09:36:47 -0000 This is a multipart message in MIME format. --=_alternative 0034C92548257FE9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgQSBuZXcgZHJhZnQgYWJvdXQgaG93IHRvIHJlbGVhc2UgdGhlIHN0YXRl cy9yZXNvdXJjZXMgb2NjdXBpZWQgYnkgU0ZDIA0KUHJveGllcyBhbmQgU0ZzIHN5bmNocm9ub3Vz bHkgaGFzIHN1Ym1pdHRlZC4NCiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpp bmctc2ZjLWZsb3ctcmVsZWFzZS1ub3RpZnktMDAgDQoNCiAgUGxlYXNlIGZlZWwgZnJlZSB0byBn aXZlIGNvbW1lbnRzLg0KICBNYW55IHRoYW5rcy4NCg0KQlJzLA0KTGluZGEgV2FuZw0KDQoNCi0t LS0tINeqt6LIyyDN9bTkMDg3MTc1L3VzZXIvenRlX2x0ZCDKsbzkIDIwMTYvMDcvMDcgMTc6MzIg LS0tLS0NCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnINC009ogMjAxNi8wNy8wNyAxNzoyNzow OToNCg0KPiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQo+IDIwMTYvMDcvMDcgMTc6MjcNCj4g DQo+IMrVvP7Iyw0KPiANCj4gIkN1aSBXYW5nIiA8d2FuZy5jdWkxQHp0ZS5jb20uY24+LCAiWHV6 aG91IFpoYW4iIA0KPiA8emhhbi54dXpob3VAenRlLmNvbS5jbj4sICJIb25nYm8gQ2FpIiA8Y2Fp Lmhvbmdib0B6dGUuY29tLmNuPiwgDQo+ICJXZWlEb25nIEppbmciIDxqaW5nLndlaWRvbmcxQHp0 ZS5jb20uY24+LCAiSmluZ2JvIFpoYW8iIA0KPiA8emhhby5qaW5nYm9AenRlLmNvbS5jbj4sIA0K PiANCj4gs63LzQ0KPiANCj4g1vfM4g0KPiANCj4gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1qaW5nLXNmYy1mbG93LXJlbGVhc2Utbm90aWZ5LTAwLnR4dA0KPiANCj4gDQo+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qaW5nLXNmYy1mbG93LXJlbGVhc2Utbm90aWZ5LTAw LnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEN1aShMaW5kYSkgV2Fu ZyBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOiAgICAg IGRyYWZ0LWppbmctc2ZjLWZsb3ctcmVsZWFzZS1ub3RpZnkNCj4gUmV2aXNpb246ICAgMDANCj4g VGl0bGU6ICAgICAgRmxvdyBSZWxlYXNlIE5vdGlmeQ0KPiBEb2N1bWVudCBkYXRlOiAgIDIwMTYt MDctMDcNCj4gR3JvdXA6ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOiAgICAg IDE1DQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtamluZy1zZmMtDQo+IGZsb3ctcmVsZWFzZS1ub3RpZnktMDAudHh0DQo+IFN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaW5nLXNm Yy0NCj4gZmxvdy1yZWxlYXNlLW5vdGlmeS8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaW5nLXNmYy1mbG93LQ0KPiByZWxlYXNlLW5vdGlmeS0w MA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBTZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGlzIHRo ZSBkZWZpbml0aW9uIG9mIGFuIG9yZGVyZWQgc2V0IG9mIHNlcnZpY2UNCj4gICAgZnVuY3Rpb25z LiAgQWZ0ZXIgaW5zdGFudGlhdGVkLCB0aGUgc2VydmljZSBmdW5jdGlvbiBwYXRoIGlzIGNyZWF0 ZWQNCj4gICAgYW5kIHRoZSBjbGFzc2lmaWVkIHRyYWZmaWMgaXMgc3RlZXJlZCB0aHJvdWdoIHRo ZSBjb3JyZXNwb25kaW5nDQo+ICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBhbmQgdGhlbiBmb3J3 YXJkZWQgdG8gdGhlIGZpbmFsIGRlc3RpbmF0aW9uLg0KPiAgICBTRnMgYW5kIFNGQyBQcm94aWVz IGRvIG5vdCBrbm93IHRoZSB0ZXJtaW5hdGlvbiBvZiBhIHNlcnZpY2UgZmxvdy4NCj4gICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8gbm90aWZ5IHRoZSBTRnMgYW5kIFNGQyBQ cm94aWVzDQo+ICAgIHRoZSB0ZXJtaW5hdGlvbiBvZiBhIHNlcnZpY2UgZmxvdy4NCj4gDQo+ICAg IFdoZW4gb25lIHNlcnZpY2UgZmxvdyBnb2VzIHRocm91Z2ggdGhlIFNGUCwgdGhlcmUgbWF5IGNy ZWF0ZSBzb21lDQo+ICAgIHN0YXRlcyBpbiBzb21lIFNGcyBvciBTRkMgUHJveGllcy4gIEhvd2V2 ZXIsIHdoZW4gdGhlIHNlcnZpY2UgZmxvdw0KPiAgICB0ZXJtaW5hdGVzLCB0aGUgU0ZzIGFuZCBT RkMgUHJveGllcyBhcmUgdW5hd2FyZSBvZiB0aGF0IGFuZCBtYWludGFpbg0KPiAgICB0aGUgc3Rh dGVzIGFzIHdlbGwuVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8gbm90aWZ5IHRo ZSBTRnMNCj4gICAgYW5kIFNGQyBQcm94aWVzIHRoZSB0ZXJtaW5hdGlvbiBvZiBhIHNlcnZpY2Ug ZmxvdyBhbmQgcmVsZWFzZSB0aGUNCj4gICAgcmVzb3VyY2VzIG9jY3VwaWVkIGJ5IHRoZSBmbG93 Lg0KPiANCj4gIA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0Kc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQoNCg== --=_alternative 0034C92548257FE9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgYWxsLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEEgbmV3IGRyYWZ0IGFib3V0 IGhvdyB0byByZWxlYXNlDQp0aGUgc3RhdGVzL3Jlc291cmNlcyBvY2N1cGllZCBieSBTRkMgUHJv eGllcyBhbmQgU0ZzIHN5bmNocm9ub3VzbHkgaGFzDQpzdWJtaXR0ZWQuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgPC9mb250PjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaW5nLXNmYy1mbG93LXJlbGVhc2Utbm90aWZ5 LTAwIj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWppbmctc2ZjLWZsb3ctcmVsZWFzZS1ub3RpZnktMDA8L2ZvbnQ+PC9hPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFBsZWFzZSBmZWVsIGZyZWUgdG8gZ2l2ZSBj b21tZW50cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyBNYW55IHRoYW5rcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkJScyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxp bmRhIFdhbmc8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM4MDAw ODAgZmFjZT0ic2Fucy1zZXJpZiI+LS0tLS0g16q3osjLIM31tOQwODcxNzUvdXNlci96dGVfbHRk DQrKsbzkIDIwMTYvMDcvMDcgMTc6MzIgLS0tLS08L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg0LTT2iAyMDE2LzA3LzA3IDE3OjI3OjA5 Ojxicj4NCjxicj4NCiZndDsgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyMDE2LzA3LzA3IDE3OjI3PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJnF1b3Q7Q3VpIFdhbmcmcXVvdDsg Jmx0O3dhbmcuY3VpMUB6dGUuY29tLmNuJmd0OywgJnF1b3Q7WHV6aG91IFpoYW4mcXVvdDsNCjxi cj4NCiZndDsgJmx0O3poYW4ueHV6aG91QHp0ZS5jb20uY24mZ3Q7LCAmcXVvdDtIb25nYm8gQ2Fp JnF1b3Q7ICZsdDtjYWkuaG9uZ2JvQHp0ZS5jb20uY24mZ3Q7LA0KPGJyPg0KJmd0OyAmcXVvdDtX ZWlEb25nIEppbmcmcXVvdDsgJmx0O2ppbmcud2VpZG9uZzFAenRlLmNvbS5jbiZndDssICZxdW90 O0ppbmdibw0KWmhhbyZxdW90OyA8YnI+DQomZ3Q7ICZsdDt6aGFvLmppbmdib0B6dGUuY29tLmNu Jmd0OywgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg s63LzTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7INb3 zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWppbmctc2ZjLWZsb3ctcmVsZWFzZS1ub3Rp ZnktMDAudHh0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtamluZy1zZmMtZmxvdy1y ZWxlYXNlLW5vdGlmeS0wMC50eHQ8YnI+DQomZ3Q7IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgQ3VpKExpbmRhKSBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KJmd0OyBJRVRG IHJlcG9zaXRvcnkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5hbWU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ZHJhZnQtamluZy1zZmMtZmxvdy1yZWxlYXNlLW5vdGlmeTxicj4NCiZndDsgUmV2aXNpb246 ICZuYnNwOyAwMDxicj4NCiZndDsgVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmxvdyBSZWxl YXNlIE5vdGlmeTxicj4NCiZndDsgRG9jdW1lbnQgZGF0ZTogJm5ic3A7IDIwMTYtMDctMDc8YnI+ DQomZ3Q7IEdyb3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwO0luZGl2aWR1YWwgU3VibWlzc2lvbjxi cj4NCiZndDsgUGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7MTU8YnI+DQomZ3Q7IFVSTDogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PC90dD48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamluZy1zZmMtIj48 dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1qaW5nLXNmYy08L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IGZs b3ctcmVsZWFzZS1ub3RpZnktMDAudHh0PGJyPg0KJmd0OyBTdGF0dXM6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1qaW5nLXNmYy0iPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamluZy1zZmMtPC9mb250PjwvdHQ+PC9hPjx0dD48 Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBmbG93LXJlbGVhc2Utbm90aWZ5Lzxicj4NCiZndDsgSHRt bGl6ZWQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaW5nLXNmYy1mbG93LSI+PHR0Pjxmb250IHNpemU9 Mj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamluZy1zZmMtZmxvdy08L2ZvbnQ+ PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IHJlbGVhc2Utbm90aWZ5LTAwPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7U2VydmljZSBmdW5jdGlvbiBjaGFpbiBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhbiBvcmRl cmVkDQpzZXQgb2Ygc2VydmljZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2Z1bmN0aW9ucy4gJm5i c3A7QWZ0ZXIgaW5zdGFudGlhdGVkLCB0aGUgc2VydmljZSBmdW5jdGlvbg0KcGF0aCBpcyBjcmVh dGVkPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YW5kIHRoZSBjbGFzc2lmaWVkIHRyYWZmaWMgaXMg c3RlZXJlZCB0aHJvdWdoIHRoZSBjb3JyZXNwb25kaW5nPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 c2VydmljZSBmdW5jdGlvbiBwYXRoIGFuZCB0aGVuIGZvcndhcmRlZCB0byB0aGUgZmluYWwNCmRl c3RpbmF0aW9uLjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1NGcyBhbmQgU0ZDIFByb3hpZXMgZG8g bm90IGtub3cgdGhlIHRlcm1pbmF0aW9uIG9mIGENCnNlcnZpY2UgZmxvdy48YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCB0byBub3RpZnkgdGhl IFNGcyBhbmQNClNGQyBQcm94aWVzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dGhlIHRlcm1pbmF0 aW9uIG9mIGEgc2VydmljZSBmbG93Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 V2hlbiBvbmUgc2VydmljZSBmbG93IGdvZXMgdGhyb3VnaCB0aGUgU0ZQLCB0aGVyZSBtYXkNCmNy ZWF0ZSBzb21lPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7c3RhdGVzIGluIHNvbWUgU0ZzIG9yIFNG QyBQcm94aWVzLiAmbmJzcDtIb3dldmVyLCB3aGVuDQp0aGUgc2VydmljZSBmbG93PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7dGVybWluYXRlcywgdGhlIFNGcyBhbmQgU0ZDIFByb3hpZXMgYXJlIHVu YXdhcmUgb2YgdGhhdA0KYW5kIG1haW50YWluPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dGhlIHN0 YXRlcyBhcyB3ZWxsLlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvDQpub3RpZnkg dGhlIFNGczxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2FuZCBTRkMgUHJveGllcyB0aGUgdGVybWlu YXRpb24gb2YgYSBzZXJ2aWNlIGZsb3cgYW5kDQpyZWxlYXNlIHRoZTxicj4NCiZndDsgJm5ic3A7 ICZuYnNwO3Jlc291cmNlcyBvY2N1cGllZCBieSB0aGUgZmxvdy48YnI+DQomZ3Q7IDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0Kc3VibWlzc2lvbjxicj4NCiZndDsg dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+ DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0034C92548257FE9_=-- From nobody Thu Jul 7 09:06: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 4F56212D5B9 for ; Thu, 7 Jul 2016 09:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 TAYwjSo12HLL for ; Thu, 7 Jul 2016 09:06:14 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) (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 6151112D801 for ; Thu, 7 Jul 2016 09:06:12 -0700 (PDT) Received: from [85.158.138.179] by server-5.bemta-3.messagelabs.com id F1/5B-02783-3FD7E775; Thu, 07 Jul 2016 16:06:11 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRWlGSWpSXmKPExsVy+MWXdt1PtXX hBnen6lssnaduMWnhFCaLJw+2sjswe0z5vZHVY8mSn0webS8VApijWDPzkvIrElgz1uybwF6w M7PiwOeMBsY/6V2MXBxCAnsZJX4/X8UO4axilPg5cTJTFyMnkLOCSeLz20yIxCFGiR/Te1kgn I2MEquvPWQEqWITcJGYMmEfmC0iUCMxq3kqK4gtLOAq8WPpPHaIuJvEjQcXWSBsK4kLJw+A2S wCKhIfDj8Cq+EVCJV4PX0S1BlNjBJTN8xmA0lwCgRKPP+wB6yBUUBWYsOG88wgNrOAuMSmZ9/ BlkkICEgs2QMRlxAQlXj5+B9QnAOoJk/i8QcWiPmCEidnPmGZwCgyC0n3LISqWUiqIMKaEut3 6UNUK0pM6X7IDmFrSLTOmcuOLL6AkX0Vo3pxalFZapGuiV5SUWZ6RkluYmaOrqGBsV5uanFxY npqTmJSsV5yfu4mRmAEMgDBDsbGL06HGCU5mJREeRX868KF+JLyUyozEosz4otKc1KLDzHKcH AoSfBuqQHKCRalpqdWpGXmAFMBTFqCg0dJhFcVmA6EeIsLEnOLM9MhUqcYFaXEeXNB+gRAEhm leXBtsPRziVFWSpiXEegQIZ6C1KLczBJU+VeM4hyMSsK8YiDjeTLzSuCmvwJazAS0+KdLNcji kkSElFQD44wrotfPz1N50G2728Z71unyHV1X9AJ7pa54F19NNpp19bhNq28le+TWKtMfGXfZg /R/3zO8N2H/19hrrrdueiz4tqNAN+NtYXgMZ+w/t8CNRfp1IdxzC8891w+er/f4i3Aqj0M02+ vlfW9PONkmT5fkPFd4WcryRI2AkmKl0K6FUZZnzeK/KrEUZyQaajEXFScCANkk9F86AwAA X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-10.tower-169.messagelabs.com!1467907570!44452718!1 X-Originating-IP: [195.232.244.135] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17596 invoked from network); 7 Jul 2016 16:06:10 -0000 Received: from mailout03.vodafone.com (HELO mailout03.vodafone.com) (195.232.244.135) by server-10.tower-169.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 7 Jul 2016 16:06:10 -0000 Received: from mailint03.vodafone.com (mailint03.vodafone.com [195.232.244.200]) by mailout03.vodafone.com (Postfix) with ESMTP id 3rljCk2Jzsz17HLq; Thu, 7 Jul 2016 18:06:10 +0200 (CEST) Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailint03.vodafone.com (Postfix) with ESMTP id 3rljCk1GfNz16PMV; Thu, 7 Jul 2016 18:06:10 +0200 (CEST) Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 3rljCk19PKz16PMQ; Thu, 7 Jul 2016 18:06:10 +0200 (CEST) Received: from VOEXC12W.internal.vodafone.com (145.230.101.14) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 7 Jul 2016 18:06:10 +0200 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.78]) by voexc12w.internal.vodafone.com ([145.230.101.14]) with mapi id 14.03.0224.002; Thu, 7 Jul 2016 18:04:29 +0200 From: "Haeffner, Walter, Vodafone DE" To: "N.Leymann@telekom.de" , "jguichar@cisco.com" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14jGUJJvsQ2mnUSMJ37PzSNaUaAMqu/ggAB4b2A= Date: Thu, 7 Jul 2016 16:04:28 +0000 Message-ID: References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> <53c05ed0042b4bb186b55fe1c71a2713@HE105662.emea1.cds.t-internal.com> In-Reply-To: <53c05ed0042b4bb186b55fe1c71a2713@HE105662.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C8C844F84E550E43865561FAE104718590101FA0VOEXM20Winterna_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 16:06:17 -0000 --_000_C8C844F84E550E43865561FAE104718590101FA0VOEXM20Winterna_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxzbyBzdXBwb3J0IOKAkyBXYWx0ZXIgSGFlZmZuZXINCg0KVm9uOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gTi5MZXltYW5uQHRlbGVrb20uZGUNCkdl c2VuZGV0OiBEb25uZXJzdGFnLCA3LiBKdWxpIDIwMTYgMTA6NTQNCkFuOiBqZ3VpY2hhckBjaXNj by5jb207IHNmY0BpZXRmLm9yZw0KQmV0cmVmZjogUmU6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0 aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2DQoNCkhpLA0KDQpzdXBwb3J0 Lg0KDQpyZWdhcmRzDQoNCk5pYw0KDQpWb246IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSBJbSBBdWZ0cmFnIHZvbiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KR2VzZW5kZXQ6IE1p dHR3b2NoLCA2LiBKdWxpIDIwMTYgMTU6MTgNCkFuOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCkJldHJlZmY6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWRv bHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2DQoNCkRlYXIgV0c6DQoNClRoaXMgZW1haWwgc2VydmVz IGFzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWhpZXJhcmNoaWNh bC0wNiBhcyBhIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBydW4gZm9y IDIgd2Vla3MgZW5kaW5nIDcvMjUvMjAxNi4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEg Y2FsbCBmb3IgYWRvcHRpb24sIGFuZCBub3QgYSBsYXN0IGNhbGwgZm9yIGNvbnRlbnQgb2YgdGhl IGRvY3VtZW50LiBBZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyB0aGF0IHRoZSBX RyB3aWxsIGZvY3VzIGl0cyBlZmZvcnRzIG9uIHRoYXQgcGFydGljdWxhciBkcmFmdCBnb2luZyBm b3J3YXJkLCBhbmQgdXNlIHRoYXQgZG9jdW1lbnQgZm9yIHJlc29sdmluZyBvcGVuIGlzc3VlcyBh bmQgZG9jdW1lbnRpbmcgdGhlIFdH4oCZcyBkZWNpc2lvbnMuDQoNClBsZWFzZSBpbmRpY2F0ZSB3 aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9uIGZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJc3N1 ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28gYmUg cmFpc2VkLCBidXQgdGhleSBzaG91bGQgYmUgcmFpc2VkIGluIHRoZSBjb250ZXh0IG9mIHdoYXQg c2hvdWxkIGJlIGNoYW5nZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQsIHJhdGhlciB0 aGFuIGEgcHJlLWNvbmRpdGlvbiBmb3IgYWRvcHRpb24uDQoNCkZpbmFsbHksIG5vdyBpcyBhbHNv IGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll cyB0byB0aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQUiBkaXNjbG9zdXJlIG9ibGlnYXRp b25zIGZvciBXRyBwYXJ0aWNpcGFudHMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUz NzggZm9yIG1vcmUgZGV0YWlscykuIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0 aG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgKHRvIHRoZSBjaGFpcnMpIHdoZXRoZXIg b3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NCg0KVGhhbmtzIQ0KDQpT RkMgQ2hhaXJzDQo= --_000_C8C844F84E550E43865561FAE104718590101FA0VOEXM20Winterna_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiU3ByZWNoYmxhc2VudGV4dCBaY2huIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlNwcmVjaGJsYXNlbnRleHRaY2huDQoJe21z by1zdHlsZS1uYW1lOiJTcHJlY2hibGFzZW50ZXh0IFpjaG4iOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazpTcHJlY2hibGFzZW50ZXh0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbHNvIHN1cHBvcnQg4oCTIFdhbHRlciBI YWVmZm5lcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Vm9uOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5JbSBBdWZ0cmFnIHZvbiA8L2I+Ti5M ZXltYW5uQHRlbGVrb20uZGU8YnI+DQo8Yj5HZXNlbmRldDo8L2I+IERvbm5lcnN0YWcsIDcuIEp1 bGkgMjAxNiAxMDo1NDxicj4NCjxiPkFuOjwvYj4gamd1aWNoYXJAY2lzY28uY29tOyBzZmNAaWV0 Zi5vcmc8YnI+DQo8Yj5CZXRyZWZmOjwvYj4gUmU6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9u IG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ c3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRF IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cmVnYXJkczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5OaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJERSIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlZvbjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn Ij5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+SW0gQXVmdHJhZyB2b24gPC9i PkppbSBHdWljaGFyZCAoamd1aWNoYXIpPGJyPg0KPGI+R2VzZW5kZXQ6PC9iPiBNaXR0d29jaCwg Ni4gSnVsaSAyMDE2IDE1OjE4PGJyPg0KPGI+QW46PC9iPiA8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+QmV0cmVmZjo8L2I+IFtzZmNdIENhbGwg Zm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkRFIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+RGVhciBXRzo8L3Nw YW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPlRoaXMgZW1haWwgc2VydmVzIGFzIGEgY2FsbCBmb3IgV0cgYWRvcHRp b24gb2YgZHJhZnQtcGVubm8tc2ZjLWhpZXJhcmNoaWNhbC0wNiBhcyBhIFdHIGRvY3VtZW50LiBU aGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBydW4gZm9yIDIgd2Vla3MgZW5kaW5nIDcvMjUvMjAx Ni48L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+UGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgY2FsbCBm b3IgYWRvcHRpb24sIGFuZCBub3QgYSBsYXN0IGNhbGwgZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3Vt ZW50LiBBZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyB0aGF0IHRoZSBXRyB3aWxs IGZvY3VzIGl0cyBlZmZvcnRzDQogb24gdGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZvcndh cmQsIGFuZCB1c2UgdGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFuZCBk b2N1bWVudGluZyB0aGUgV0figJlzIGRlY2lzaW9ucy48L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+UGxl YXNlIGluZGljYXRlIHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlm IG5vdCB3aHkuIElzc3VlcyB5b3UgaGF2ZSB3aXRoIHRoZSBjdXJyZW50IGRvY3VtZW50IGl0c2Vs ZiBjYW4gYWxzbyBiZSByYWlzZWQsIGJ1dCB0aGV5IHNob3VsZCBiZSByYWlzZWQNCiBpbiB0aGUg Y29udGV4dCBvZiB3aGF0IHNob3VsZCBiZSBjaGFuZ2VkIGluIHRoZSBkb2N1bWVudCBnb2luZyBm b3J3YXJkLCByYXRoZXIgdGhhbiBhIHByZS1jb25kaXRpb24gZm9yIGFkb3B0aW9uLiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRFIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOmJsYWNrIj5GaW5hbGx5LCBub3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBw b2xsIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwg aW4gbGluZSB3aXRoIHRoZSBJUFIgZGlzY2xvc3VyZSBvYmxpZ2F0aW9ucyBmb3IgV0cgcGFydGlj aXBhbnRzIChzZWUNCiBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0 YWlscykuIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSByZXNw b25kIHRvIHRoaXMgZW1haWwgKHRvIHRoZSBjaGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUg YXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi48L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoYW5rcyE8L3Nw YW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPlNGQyBDaGFpcnM8L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C8C844F84E550E43865561FAE104718590101FA0VOEXM20Winterna_-- From nobody Thu Jul 7 09:08: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 2406612D818 for ; Thu, 7 Jul 2016 09:08:29 -0700 (PDT) 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 nc03X03K3bZ5 for ; Thu, 7 Jul 2016 09:08:26 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510E512D5C0 for ; Thu, 7 Jul 2016 09:08:26 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id f6so3161610ith.1 for ; Thu, 07 Jul 2016 09:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=K6bSyGIMSFk/1GWkPUGZ9NUqYUlAVAqGGgKrglkX1v0=; b=A/Ahk35SqEl/ZgjPUgXGJ34uQ7L1OMbpvXbKh6e07HSOVVllz8la+KRg8LfruMv9v5 4BTHLNrh2iDXFuhHiuHb6hWsJBXIkuHonLbYQu1fWRtjSwRWK8D7UOAv6srjn7LXl0SA 6Lfn6q/dsUI8zbJWbewy4HERLLt6dWXVY5ZXAr+wmzUAKu/+VGyG7vrblscp2fNf7ag1 uJ6Wihu35SGaL1VFpiB/KlgMp3ACShWUMzBPr4h+Gv2aHkUVO6pNZGNBI39tfqfNO4q7 BxKqoJPXesV4r6pBInmg4BesjIO/kQJU5u2nK+vItuyRxVe/oGXxChlkN8/DbOWgTXJ0 Yjpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=K6bSyGIMSFk/1GWkPUGZ9NUqYUlAVAqGGgKrglkX1v0=; b=HSJc1DSqWqeMc2Tq+Bkajz5OR4NuEkry7KO/1jx1fQSi9TLh56Gn2AqLrB+YM79cDk Ipydm6o5fkzCNJHR4EsvV35AuzqC8IRIxjaJidRDuMdofk8XDu8RqZVWiuyXFF8UlaJ7 dOVfZCGSeaFJu+PDC1YvohKUAVrdWnJxbwXv5vtsO4vI9rBl26S2Njdg95kAbIKZmgHi TZJEKtypf0c6jFYRtkQYtILKImwH5r/S9zqFu6kYnWjKfrvJt45lxkEd7BehMmDswhAW chtZ4XIYPJ0SPAawNO8XWPmr/JO2mZ+jfwlbumOGCoqQqWG4Acd2vatMQF+NVH+Z9gZS 3nlA== X-Gm-Message-State: ALyK8tInJ7DdxhAl6hRlIH4Rwo8RBMuBEIn22x5nvTqQMm1nLAdwpmU9CHrI48ccSsa294Vz6gmNZ5MJ6FtK2A== X-Received: by 10.36.111.72 with SMTP id x69mr3553467itb.71.1467907705703; Thu, 07 Jul 2016 09:08:25 -0700 (PDT) MIME-Version: 1.0 References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> From: Dapeng Liu Date: Thu, 07 Jul 2016 16:08:16 +0000 Message-ID: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a11439d445c926905370de5f1 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2016 16:08:29 -0000 --001a11439d445c926905370de5f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable support -Dapeng Liu On Wed, Jul 6, 2016 at 9:17 PM Jim Guichard (jguichar) wrote: > Dear WG: > > > This email serves as a call for WG adoption of > draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption > will run for 2 weeks ending 7/25/2016. > > > > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a WG document simply means that the WG > will focus its efforts on that particular draft going forward, and use th= at > document for resolving open issues and documenting the WG=E2=80=99s decis= ions. > > > > Please indicate whether you support adoption for not, and if not why. > Issues you have with the current document itself can also be raised, but > they should be raised in the context of what should be changed in the > document going forward, rather than a pre-condition for adoption. > > > > Finally, now is also a good time to poll for knowledge of any IPR that > applies to this draft, in line with the IPR disclosure obligations for WG > participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If yo= u > are listed as a document author please respond to this email (to the > chairs) whether or not you are aware of any relevant IPR. > > > Thanks! > > > SFC Chairs > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a11439d445c926905370de5f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
support

-Dapeng Liu

On Wed, Jul 6, 2016 at 9:17 PM Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:


This email serves as a ca= ll for WG adoption of draft-penno-sfc-hierarchical-06 as a WG document. The= call for adoption will run for 2 weeks ending 7/25/2016.

=C2=A0

Please note that this is = a call for adoption, and not a last call for content of the document. Adopt= ing a WG document simply means that the WG will focus its efforts on that particular draft going forward, and = use that document for resolving open issues and documenting the WG=E2=80=99= s decisions.

=C2=A0

Please indicate whether y= ou support adoption for not, and if not why. Issues you have with the curre= nt document itself can also be raised, but they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption.=C2=A0

=C2=A0

Finally, now is also a good time to poll = for knowledge of any IPR that applies to this draft, in line with the IPR d= isclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed a= s a document author please respond to this email (to the chairs) whether or= not you are aware of any relevant IPR.


Thanks!


SFC Chairs

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--001a11439d445c926905370de5f1-- From nobody Thu Jul 7 12:02: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 2E2E212B019 for ; Thu, 7 Jul 2016 12:02:53 -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 bOC3uIpzb7jk for ; Thu, 7 Jul 2016 12:02:51 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 2C29F12B059 for ; Thu, 7 Jul 2016 12:02:51 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id b192so32566308vke.0 for ; Thu, 07 Jul 2016 12:02:51 -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=7UHJQhuAlu136uWkSAwOSaGJWVHhIoIwnaH31PEIU7M=; b=eSzfnG/FkF3ayq0a9z5ZdytJH9BP0jLHllT9aPXutdIUgQEZkeEJncwxLRXiX90tiS T9DtWKfRMwfEP7f1zvaV/lgw979EGnk+0yIfPZEgN6FprHdnuGHKF/WoEfvpEpmmo9fU buaQao3LbX27xa0+zPmSOHb9B7QirRubwZYkdqCzOwn8vFr4pAmCBMZu4+UE0pXbxq+F PbAjCCFj52ny2E3MtvItJRf/2aXeCcYTRl8kcULU3Mj6tGdtfuwxKQ6R/iC+I51a1BXb lTowggyAv+C4ZaVYPRKtYmNnNaKTahOR0hNAK4Pktd1x9Q7rfDs1y4RUrOR3ulwvkXZC wjuQ== 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=7UHJQhuAlu136uWkSAwOSaGJWVHhIoIwnaH31PEIU7M=; b=X98ibBEqmfPXBamdcUhnyxSsHcpPuelUoBHzuKbuElQMK6PRAo66fnP4RxXdh97asH 1Ohn6jm2NlRL49evAU7Q/m2z9bCTLQmM3U4Vd4rwAXXOxRSDAldLBNuVMkyTOk1y2Rjw VtefaDuYfc1iGpIa0QeaIvCWkE0VjgH5AQP8BIC01Q/G6FJSsMbOov5jkrzhJoEe8DIA qvBHmDzctiAmitJ1MDK+bmzvC8N7Bf+VeFRydGnmzaWq6Njmj67lT3e5vpk0WTUm+gmL zEYhlY+NL2hSuNHp8lhPM4O4btMi1FtVp+JkFaMBGvTJlKUgKxrXrzPoCQ1KUAkWUxHt htGQ== X-Gm-Message-State: ALyK8tJFVBjb/c6tm2S9u7ogNjWwLwhoqMWq6jZuWTZwOX4Ev/nBg31a+4bH44XpvLQeIL77qf8p9jDvltRv0g== X-Received: by 10.31.4.4 with SMTP id 4mr872579vke.121.1467918170287; Thu, 07 Jul 2016 12:02:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.112 with HTTP; Thu, 7 Jul 2016 12:02:49 -0700 (PDT) In-Reply-To: <20160707185950.23618.84186.idtracker@ietfa.amsl.com> References: <20160707185950.23618.84186.idtracker@ietfa.amsl.com> From: Behcet Sarikaya Date: Thu, 7 Jul 2016 14:02:49 -0500 Message-ID: To: "sfc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mohamed Boucadair , "Dirk.von-Hugo@telekom.de" Subject: [sfc] Fwd: New Version Notification for draft-sarikaya-sfc-sfctlvs-00.txt 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: Thu, 07 Jul 2016 19:02:53 -0000 Hi all, We submitted a new draft on SFC metadata defined so far in so many different drafts. Please find it on the link below. It was no so easy to find all such drafts. If your draft defines one and it is not mentioned in this document, please let us know. Comments are appreciated. Behcet A new version of I-D, draft-sarikaya-sfc-sfctlvs-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-sfc-sfctlvs Revision: 00 Title: Road to the Standardization for Service Function Chaining Metadata Type 1 and Type 2 Document date: 2016-07-07 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-sarikaya-sfc-sfctlvs-00.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-sfc-sfctlvs/ Htmlized: https://tools.ietf.org/html/draft-sarikaya-sfc-sfctlvs-00 Abstract: With the definition of service function chain data plane protocol there comes the need to define the context data needed in the service function chain use cases. This document gives an account of all context data defined so far as Network Service Header metadata Type 1 and Type 2 context headers. Next, the document discusses the various options that can be made in standardizing these TLVs. 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 From nobody Thu Jul 7 17: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 9428512D122; Thu, 7 Jul 2016 17:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 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.426, 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 nI-8GlqmAGUg; Thu, 7 Jul 2016 17:27:03 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id BB055126FDC; Thu, 7 Jul 2016 17:27:02 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 21E5DE5B748AC; Fri, 8 Jul 2016 08:27:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u680QtTE054689; Fri, 8 Jul 2016 08:26:55 +0800 (GMT-8) (envelope-from ao.ting@zte.com.cn) In-Reply-To: References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> <53c05ed0042b4bb186b55fe1c71a2713@HE105662.emea1.cds.t-internal.com> To: "sfc@ietf.org" , "sfc" MIME-Version: 1.0 X-KeepSent: B29FA851:D2199682-48257FEA:0002291F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: ao.ting@zte.com.cn Date: Fri, 8 Jul 2016 08:25:32 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-07-08 08:26:55, Serialize complete at 2016-07-08 08:26:55 Content-Type: multipart/alternative; boundary="=_alternative 0002786348257FEA_=" X-MAIL: mse01.zte.com.cn u680QtTE054689 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2016 00:27:05 -0000 This is a multipart message in MIME format. --=_alternative 0002786348257FEA_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QXMgYSBjb2F1dGhvcu+8jCBJIHN1cHBvcnTvvIENCg0KDQpCUi4NClRpbmcgQW8NCiANCg0KDQoN Cg0K5Y+R5Lu25Lq6OiAgICAgICAgICJEaWVnbyBSLiBMb3BleiIgPGRpZWdvLnIubG9wZXpAdGVs ZWZvbmljYS5jb20+DQrmlLbku7bkuro6ICAgICAgICAgInNmY0BpZXRmLm9yZyIgPHNmY0BpZXRm Lm9yZz4sIA0K5pel5pyfOiAgIDIwMTYvMDcvMDcgMTc6MDQNCuS4u+mimDogICBSZTogW3NmY10g Q2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDYN CuWPkeS7tuS6ujogInNmYyIgPHNmYy1ib3VuY2VzQGlldGYub3JnPg0KDQoNCg0KQ29hdXRob3Ig KzEgDQoNCk9uIDcgSnVsIDIwMTYsIGF0IDEwOjU0ICwgTi5MZXltYW5uQHRlbGVrb20uZGUgd3Jv dGU6DQoNCkhpLA0KIA0Kc3VwcG9ydC4NCiANCnJlZ2FyZHMNCiANCk5pYw0KIA0KVm9uOiBzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gSmltIEd1aWNoYXJk IA0KKGpndWljaGFyKQ0KR2VzZW5kZXQ6IE1pdHR3b2NoLCA2LiBKdWxpIDIwMTYgMTU6MTgNCkFu OiBzZmNAaWV0Zi5vcmcNCkJldHJlZmY6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRy YWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2DQogDQpEZWFyIFdHOg0KIA0KVGhpcyBlbWFp bCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiANCmRyYWZ0LXBlbm5vLXNmYy1o aWVyYXJjaGljYWwtMDYgYXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uIA0K d2lsbCBydW4gZm9yIDIgd2Vla3MgZW5kaW5nIDcvMjUvMjAxNi4NCiANClBsZWFzZSBub3RlIHRo YXQgdGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEgbGFzdCBjYWxsIGZvciAN CmNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBBZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBt ZWFucyB0aGF0IHRoZSBXRyANCndpbGwgZm9jdXMgaXRzIGVmZm9ydHMgb24gdGhhdCBwYXJ0aWN1 bGFyIGRyYWZ0IGdvaW5nIGZvcndhcmQsIGFuZCB1c2UgDQp0aGF0IGRvY3VtZW50IGZvciByZXNv bHZpbmcgb3BlbiBpc3N1ZXMgYW5kIGRvY3VtZW50aW5nIHRoZSBXR+KAmXMgDQpkZWNpc2lvbnMu DQogDQpQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBmb3Igbm90 LCBhbmQgaWYgbm90IHdoeS4gDQpJc3N1ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3VycmVudCBkb2N1 bWVudCBpdHNlbGYgY2FuIGFsc28gYmUgcmFpc2VkLCBidXQgDQp0aGV5IHNob3VsZCBiZSByYWlz ZWQgaW4gdGhlIGNvbnRleHQgb2Ygd2hhdCBzaG91bGQgYmUgY2hhbmdlZCBpbiB0aGUgDQpkb2N1 bWVudCBnb2luZyBmb3J3YXJkLCByYXRoZXIgdGhhbiBhIHByZS1jb25kaXRpb24gZm9yIGFkb3B0 aW9uLiANCiANCkZpbmFsbHksIG5vdyBpcyBhbHNvIGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yIGtu b3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgDQphcHBsaWVzIHRvIHRoaXMgZHJhZnQsIGluIGxpbmUg d2l0aCB0aGUgSVBSIGRpc2Nsb3N1cmUgb2JsaWdhdGlvbnMgZm9yIFdHIA0KcGFydGljaXBhbnRz IChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLiBJ ZiB5b3UgDQphcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSByZXNwb25kIHRv IHRoaXMgZW1haWwgKHRvIHRoZSANCmNoYWlycykgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KIA0KVGhhbmtzIQ0KIA0KU0ZDIENoYWlycw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxp c3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRy IERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGll Z28ubG9wZXovDQoNCmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbQ0KVGVsOiAg ICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mg c2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgDQpwdWVkZSBjb250 ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1 c28gDQpleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8g ZXMgdXN0ZWQuIGVsIA0KZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRl IHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIA0KZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBz aW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIA0KbGEg bGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJy b3IsIGxlIHJvZ2Ftb3MgDQpxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3Ig ZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IA0KZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5k IA0KY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgDQplbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2Yg dGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgDQpyZWNpcGllbnQsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciANCmNv cHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIA0KdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFk IGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gDQp0aGUgc2VuZGVyIHRoYXQgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIA0KZGVsZXRl IGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFt ZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgDQpwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJp dmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byANCmRhIHBl c3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8g ZGVzdGluYXTDoXJpbyANCmluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVy YSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSANCmPDs3BpYSBzZW0gYXV0b3JpemHD p8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIA0Kdmln ZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUg bm9zIG8gDQpjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9j ZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KDQo= --=_alternative 0002786348257FEA_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkFzIGEgY29hdXRob3LvvIwgSSBz dXBwb3J077yBPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5CUi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRp bmcgQW88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNl cmlmIj7lj5Hku7bkuro6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgPC9mb250Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtEaWVnbw0KUi4gTG9wZXomcXVvdDsgJmx0 O2RpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPuaUtuS7tuS6ujogJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90O3NmY0BpZXRmLm9yZyZxdW90Ow0KJmx0O3NmY0BpZXRmLm9yZyZndDssIDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj7ml6XmnJ86ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDE2LzA3LzA3DQoxNzowNDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9 IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj7kuLvpopg6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbc2ZjXSBDYWxs DQpmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDY8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+5Y+R 5Lu25Lq6OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtzZmMmcXVvdDsNCiZsdDtzZmMtYm91bmNlc0BpZXRmLm9y ZyZndDs8L2ZvbnQ+DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTM+Q29hdXRob3IgKzEgPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5PbiA3IEp1 bCAyMDE2LCBhdCAxMDo1NCAsIDwvZm9udD48YSBocmVmPW1haWx0bzpOLkxleW1hbm5AdGVsZWtv bS5kZT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5OLkxleW1hbm5AdGVsZWtvbS5kZTwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCndyb3RlOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5IaSw8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPnN1cHBvcnQuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5yZWdhcmRz PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJp Ij5OaWM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPlZvbjo8 L2I+IHNmYyBbPC9mb250PjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+PGZv bnQgc2l6ZT0yIGNvbG9yPSM4MDAwODAgZmFjZT0iVGFob21hIj48dT5tYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8 Yj5JbSBBdWZ0cmFnIHZvbiA8L2I+SmltIEd1aWNoYXJkIChqZ3VpY2hhcik8Yj48YnI+DQpHZXNl bmRldDo8L2I+IE1pdHR3b2NoLCA2LiBKdWxpIDIwMTYgMTU6MTg8Yj48YnI+DQpBbjo8L2I+IDwv Zm9udD48YSBocmVmPW1haWx0bzpzZmNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAw ODAgZmFjZT0iVGFob21hIj48dT5zZmNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpCZXRyZWZmOjwvYj4gW3NmY10gQ2FsbCBmb3IgV0cg YWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDY8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MSBmYWNlPSJDb25zb2xhcyI+RGVhciBXRzo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MSBmYWNlPSJDb25zb2xhcyI+VGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9w dGlvbg0Kb2YgZHJhZnQtcGVubm8tc2ZjLWhpZXJhcmNoaWNhbC0wNiBhcyBhIFdHIGRvY3VtZW50 LiBUaGUgY2FsbCBmb3IgYWRvcHRpb24NCndpbGwgcnVuIGZvciAyIHdlZWtzIGVuZGluZyA3LzI1 LzIwMTYuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0iQ29uc29sYXMiPlBsZWFzZSBub3Rl IHRoYXQgdGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uLA0KYW5kIG5vdCBhIGxhc3QgY2FsbCBm b3IgY29udGVudCBvZiB0aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQNCnNpbXBs eSBtZWFucyB0aGF0IHRoZSBXRyB3aWxsIGZvY3VzIGl0cyBlZmZvcnRzIG9uIHRoYXQgcGFydGlj dWxhciBkcmFmdA0KZ29pbmcgZm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRvY3VtZW50IGZvciByZXNv bHZpbmcgb3BlbiBpc3N1ZXMgYW5kIGRvY3VtZW50aW5nDQp0aGUgV0figJlzIGRlY2lzaW9ucy48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJDb25zb2xhcyI+UGxlYXNlIGluZGljYXRlIHdo ZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24NCmZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJc3N1 ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCBpdHNlbGYNCmNhbiBhbHNvIGJl IHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNlZCBpbiB0aGUgY29udGV4dCBvZiB3aGF0 IHNob3VsZA0KYmUgY2hhbmdlZCBpbiB0aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVy IHRoYW4gYSBwcmUtY29uZGl0aW9uIGZvcg0KYWRvcHRpb24uIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTEgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0xIGZhY2U9IkNvbnNvbGFzIj5GaW5hbGx5LCBub3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBw b2xsDQpmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQs IGluIGxpbmUgd2l0aCB0aGUgSVBSDQpkaXNjbG9zdXJlIG9ibGlnYXRpb25zIGZvciBXRyBwYXJ0 aWNpcGFudHMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kDQo1Mzc4IGZvciBtb3JlIGRl dGFpbHMpLiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBwbGVhc2UgcmVz cG9uZA0KdG8gdGhpcyBlbWFpbCAodG8gdGhlIGNoYWlycykgd2hldGhlciBvciBub3QgeW91IGFy ZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQNCklQUi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNl PSJDb25zb2xhcyI+VGhhbmtzITwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkNvbnNvbGFz Ij5TRkMgQ2hhaXJzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MT5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8L2ZvbnQ+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM4MDAwODA+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1h aWx0bzpzZmNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPSM4MDAwODA+PHU+c2ZjQGlldGYu b3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGNvbG9yPSM4MDAwODA+PHU+PGJyPg0KPC91 PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj Pjxmb250IHNpemU9MSBjb2xvcj0jODAwMDgwPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjPC91PjwvZm9udD48L2E+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPi0t PGJyPg0KJnF1b3Q7RXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vJnF1b3Q7 PGJyPg0KPGJyPg0KRHIgRGllZ28gUi4gTG9wZXo8YnI+DQpUZWxlZm9uaWNhIEkrRDwvZm9udD48 Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cDov L3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0 dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6LzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 Mz48YnI+DQo8YnI+DQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb208YnI+DQpU ZWw6ICZuYnNwOyAmbmJzcDsrMzQgOTEzIDEyOSAwNDE8YnI+DQpNb2JpbGU6ICszNCA2ODIgMDUx IDA5MTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxocj48Zm9udCBzaXplPTEgY29sb3I9 IzgwODA4MCBmYWNlPSJBcmlhbCI+PGJyPg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNl IGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sDQpwdWVkZSBjb250ZW5l ciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28g ZXhjbHVzaXZvDQpkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1 c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLA0KcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUg bGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhDQpzaW4gYXV0 b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFj acOzbiB2aWdlbnRlLg0KU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUg cm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZQ0KaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlz bWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uPGJyPg0KPGJyPg0KVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBj b25maWRlbnRpYWwNCmluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkDQphYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlz IG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdQ0KYXJlIGhlcmVieSBu b3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBv Zg0KdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uDQppbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBs ZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91DQpoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuPGJyPg0K PGJyPg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVu dGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sDQpwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmls ZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2bw0KZGEgcGVzc29h IG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0 aW5hdMOhcmlvDQppbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0 aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UNCmPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBw b2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuDQpT ZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBj b211bmlxdWUgaW1lZGlhdGFtZW50ZQ0KcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1 YSBkZXN0cnVpw6fDo288L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQpz ZmNAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48 YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0002786348257FEA_=-- From nobody Fri Jul 8 04:49: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 C759912D1B8 for ; Fri, 8 Jul 2016 04:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 5A-imgwluv8u for ; Fri, 8 Jul 2016 04:49:28 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1CCA12D093 for ; Fri, 8 Jul 2016 04:49:27 -0700 (PDT) Received: from smtpjc.telefonica.com (tgtimjc804.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A4DFEE0254 for ; Fri, 8 Jul 2016 13:49:25 +0200 (CEST) Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP103", Issuer "ESTGVMSP103" (not verified)) by smtpjc.telefonica.com (Postfix) with ESMTPS id 84377E017A for ; Fri, 8 Jul 2016 13:49:25 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.50) with Microsoft SMTP Server (TLS) id 14.3.266.1; Fri, 8 Jul 2016 13:49:24 +0200 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0640.eurprd06.prod.outlook.com (10.161.13.146) with Microsoft SMTP Server (TLS) id 15.1.534.14; Fri, 8 Jul 2016 11:49:23 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0534.020; Fri, 8 Jul 2016 11:49:23 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-aranda-sfc-dp-mobile-02.txt Thread-Index: AQHR2EtP3PJdiFIe70+UAtJIwDTgqqAOjnkA Date: Fri, 8 Jul 2016 11:49:23 +0000 Message-ID: <9B900EA4-F3CF-4345-B560-0516D6553B00@telefonica.com> References: <20160707122941.23613.86660.idtracker@ietfa.amsl.com> In-Reply-To: <20160707122941.23613.86660.idtracker@ietfa.amsl.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-ms-office365-filtering-correlation-id: d32dbe37-84a9-455a-926e-08d3a725e7c8 x-microsoft-exchange-diagnostics: 1; DB4PR06MB0640; 6:dyPN6zRv7Bsi42egy5HwXGhdWpPqtHFYOt01jx4596t26RIW3LiNLphde6brhaGWq6Qul17qZkz8swcvOy+XCbm4qtYcHA3lLoHjMWco2TrA8p7nJxyN15lynrzCBKcPcEQ3CvO/HJGeKoAvogQjJ8X7vDf11azLnyvXrqi29fDuEZB8ln0j1bqDIe2ch3X5VOdQNSW2DNCXPE2yfM1DPjwmUk0wi8YQBlCFFECAJ2zX0nnLO4U2XIk72Oo5L/M0Lua4R2cmffKslVsYfosiogSAtFFyWVxCAHggigK4S2k=; 5:JkbXDIikmHu/V3O3nuboXzsckg+AANglyqEVCLobgoYmCPYOfzBH6f7MDgpizUldZL9AN8Iw2QF3Oz1hTGNcWUZj0ahNlsujh8wsPxbw8C84V0wKg2f2Tq446KCRG8RREH9n+kLDRSx2BGWiqZUL4g==; 24:IZet9KMSGWV8rzaGuJA9SRuuSM5JutWsubnxt282cP74p1vnjfQYzxGMy+h7l+pxQuQ61ovOwHIzCY1Xmq9dUhzQP50C1f/EEvPaitdc+9M=; 7:i66wksXf4s4ZEqspomkTIQLHs6jPwC0ypR246XWBpIklNwzcgukflvwslYDlChNa2hoz4OvVMekDnj79pGjRaLt6Jw52/lflrJp2eUKF1+zuyHLLJrq8f4o2ZGF661kxTEmlSS8+h+MH+JjSUBSGs7oUj4wr969ZcfDJ0q0MiY5i6B5w55GP4B0wCs5O1KO4vkLn7Q4cFMX/vU6z1YUejg2kY9F0RjXvAbojVKNPJqkRfD5SYNXe+UJB6+ZiFHTu x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0640; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67444318432085)(40392960112811)(120809045254105)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR06MB0640; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0640; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377424004)(199003)(59124004)(189002)(33656002)(101416001)(50986999)(76176999)(107886002)(54356999)(586003)(3846002)(6116002)(102836003)(110136002)(77096005)(189998001)(81156014)(8676002)(83716003)(19580405001)(81166006)(1730700003)(305945005)(2906002)(19580395003)(122556002)(11100500001)(82746002)(83506001)(7846002)(7736002)(450100001)(92566002)(3280700002)(3660700001)(36756003)(10400500002)(97736004)(4001350100001)(87936001)(5002640100001)(2351001)(105586002)(230783001)(106356001)(106116001)(8936002)(5640700001)(86362001)(575784001)(68736007)(2501003)(2900100001)(15975445007)(2950100001)(15650500001)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0640; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 11:49:23.2431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0640 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Subject: [sfc] FW: New Version Notification for draft-aranda-sfc-dp-mobile-02.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: Fri, 08 Jul 2016 11:49:32 -0000 SGkNCg0KSSBoYXZlIHVwZGF0ZWQgbXkgZHJhZnQgYWNjb3JkaW5nIHRvIHRoZSBsYXN0IGNvbW1l bnRzIGFuZCByZXF1ZXN0IChhZ2FpbikgYSBzbG90IHRvIHByZXNlbnQgaXTigKYNCg0KQmVzdCwg L1BBDQoNCi0tLQ0KRHIuIFBlZHJvIEEuIEFyYW5kYSBHdXRpw6lycmV6DQoNCg0KVGVjaG5vbG9n eSBFeHBsb3JhdGlvbg0KZW1haWw6IHBlZHJvYSBkMHQgYXJhbmRhIEF0IHRlbGVmb25pY2EgZDB0 IGNvbQ0KVGVsZWbDs25pY2EsIEludmVzdGlnYWNpw7NuIHkgRGVzYXJyb2xsbyDigJMgR0NUTyBV bml0DQpDLyBadXJiYXLDoW4sMTINCg0KMjgwMTAgTWFkcmlkLCBTcGFpbg0KDQoNCkZyYWdlbiBz aW5kIG5pY2h0IGRhLCB1bSBiZWFudHdvcnRldCB6dSB3ZXJkZW4uDQpGcmFnZW4gc2luZCBkYSwg dW0gZ2VzdGVsbHQgenUgd2VyZGVuLg0KDQpHZW9yZyBLcmVpc2xlcg0KDQotLS0tLU1lbnNhamUg b3JpZ2luYWwtLS0tLQ0KRGU6ICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+DQpGZWNoYToganVldmVzLCA3IGRlIGp1bGlvIGRlIDIwMTYsIDE0OjI5 DQpQYXJhOiAiRGllZ28gUi4gTG9wZXoiIDxkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPiwg TWFyY28gR3JhbWFnbGlhIDxtYXJjby5ncmFtYWdsaWFAaW1kZWEub3JnPiwgcGFhZyA8cGVkcm9h LmFyYW5kYUB0ZWxlZm9uaWNhLmNvbT4sIFdhbHRlciBIYWVmZm5lciA8d2FsdGVyLmhhZWZmbmVy QHZvZGFmb25lLmNvbT4sIHBhYWcgPHBlZHJvYS5hcmFuZGFAdGVsZWZvbmljYS5jb20+DQpBc3Vu dG86IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYXJhbmRhLXNmYy1kcC1tb2Jp bGUtMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFyYW5kYS1zZmMtZHAt bW9iaWxlLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQZWRybyBB LiBBcmFuZGEgR3V0aWVycmV6IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoN Ck5hbWU6ICAgICAgICAgICBkcmFmdC1hcmFuZGEtc2ZjLWRwLW1vYmlsZQ0KUmV2aXNpb246ICAg ICAgIDAyDQpUaXRsZTogICAgICAgICAgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBEYXRhcGxh bmUgRWxlbWVudHMgaW4gTW9iaWxlIE5ldHdvcmtzDQpEb2N1bWVudCBkYXRlOiAgMjAxNi0wNy0w Nw0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAg IDE0DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWFyYW5kYS1zZmMtZHAtbW9iaWxlLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFyYW5kYS1zZmMtZHAtbW9iaWxlLw0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hcmFuZGEt c2ZjLWRwLW1vYmlsZS0wMg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1hcmFuZGEtc2ZjLWRwLW1vYmlsZS0wMg0KDQpBYnN0cmFjdDoNCiAg IFRoZSBldm9sdXRpb24gb2YgdGhlIG5ldHdvcmsgdG93YXJkcyA1RyBpbXBsaWVzIGEgY2hhbGxl bmdlIGZvciB0aGUNCiAgIGluZnJhc3RydWN0dXJlLiAgVGhlIHRhcmdldGVkIHNlcnZpY2VzIGFu ZCB0aGUgZnVsbCBkZXBsb3ltZW50IG9mDQogICB2aXJ0dWFsaXphdGlvbiBpbiBhbGwgc2VnbWVu dHMgb2YgdGhlIG5ldHdvcmsgd2lsbCBiZSBwb3NzaWJsZSBhbmQNCiAgIG5lY2Vzc2FyeSB0byBw cm92aWRlIHNvbWUgdHJhZmZpYy1zcGVjaWZpYyBzZXJ2aWNlcyBuZWFyIHRoZSBuZXh0DQogICBn ZW5lcmF0aW9uIGJhc2Ugc3RhdGlvbnMgd2hlcmUgdGhlIHJhZGlvIGlzIHByb2Nlc3NlZC4gIFRo dXMsIHNlcnZpY2UNCiAgIGZ1bmN0aW9uIGNoYWlucyB0aGF0IGN1cnJlbnRseSByZXNpZGUgaW4g dGhlIGluZnJhc3RydWN0dXJlIG9mIHRoZQ0KICAgTmV0d29yayBvcGVyYXRvciAobGlrZSwgZS5n LiB0aGUgRXhwZWRlZCBQYWNrZXQgR2F0ZXdheShFUEcpKSB3aWxsIGJlDQogICBleHRlbmRlZCB0 byB0aGUgcmFkaW8gYWNjZXNzIG5ldHdvcmsgKFJBTikuDQoNCiAgIEluIHRoaXMgZHJhZnQgd2Ug cHJvdmlkZSBhIG5vbi1leGhhdXN0aXZlIGJ1dCByZXByZXNlbnRhdGl2ZSBsaXN0IG9mDQogICBz ZXJ2aWNlIGZ1bmN0aW9ucyBpbiA0RyBhbmQgNUcgbmV0d29ya3MsIGFuZCBleHBsb3JlIGRpZmZl cmVudA0KICAgc2NlbmFyaW9zIGZvciBzZXJ2aWNlLWF3YXJlIG9yY2hlc3RyYXRpb24uDQoNCiAg IFdlIGJhc2Ugb24gdGhlIHByb2JsZW0gc3RhdGVtZW50IFtSRkM3NDk4XSBhbmQgYXJjaGl0ZWN0 dXJlIGZyYW1ld29yaw0KICAgW1JGQzc2NjVdICBvZiB0aGUgU0ZDIHdvcmtpbmcgZ3JvdXAsIGFz IHdlbGwgb24gdGhlIGV4aXN0aW5nIG1vYmlsZQ0KICAgbmV0d29ya3MgdXNlIGNhc2VzIFtJLUQu aWV0Zi1zZmMtdXNlLWNhc2UtbW9iaWxpdHldICBhbmQgdGhlDQogICByZXF1aXJlbWVudCBnYXRo ZXJpbmcgcHJvY2VzcyBvZiB0aGUgSVRVLVIgSU1UIDIwMjAgWzFdIGFuZCBkaWZmZXJlbnQNCiAg IGluaXRpYXRpdmVzIGluIEV1cm9wZSBbMl0sIEtvcmVhIFszXSBhbmQgQ2hpbmEgWzRdIHRvIGFu dGljaXBhdGUNCiAgIG5ldHdvcmsgZWxlbWVudHMgdGhhdCB3aWxsIGJlIG5lZWRlZCBpbiA1RyBu ZXR3b3Jrcy4NCg0KICAgV2UgdGhlbiBleHBsb3JlIHNlcnZpY2UtYXdhcmUgb3JjaGVzdHJhdGlv biBzY2VuYXJpb3MgaWRlbnRpZnlpbmcNCiAgIHdoZXJlIGRpZmZlcmVudCBuZXR3b3JrIGZ1bmN0 aW9ucyBjYW4gYmUgZGVwbG95ZWQgaW4gYSBmdWxseQ0KICAgdmlydHVhbGlzZWQgZnV0dXJlIG5l dHdvcmssIHdoZXJlIGJvdGggdGhlIGNvcmUgYW5kIHRoZSBlZGdlIHByb3ZpZGUNCiAgIGFkdmFu Y2VkIHZpcnR1YWxpc2F0aW9uIGNhcGFiaWxpdGllcy4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9z IHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRl bmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVz byBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMg dXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUg bGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRv cml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNp w7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJv Z2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEg dsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFs IGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh bnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg dHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5 IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj YXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1 cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywg cG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDD qSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNl IG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5v dGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9v dSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRl IGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVy cm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0 YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0K From nobody Fri Jul 8 13:47: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 D6F3612D0BC for ; Fri, 8 Jul 2016 13:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 a9sGdfqvbPIo for ; Fri, 8 Jul 2016 13:47:36 -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 E412312B004 for ; Fri, 8 Jul 2016 13:47:35 -0700 (PDT) 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.0195.001; Fri, 8 Jul 2016 16:47:34 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-dolson-sfc-oam-sff-sf-cv-00.txt Thread-Index: AQHR2UkaiKN5DBTrtEGG86zzwghDMqAO/uVg Date: Fri, 8 Jul 2016 20:47:34 +0000 Message-ID: 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: Cc: Kyle Larose Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-oam-sff-sf-cv-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: Fri, 08 Jul 2016 20:47:38 -0000 V2Ugc3VibWl0dGVkIHRoaXMgZHJhZnQgdG8gc2hvdyBob3cgU0ZGcyBjYW4gYWN0aXZlbHkgbW9u aXRvciANCmNvbm5lY3Rpdml0eSB0byBTRnMgYW5kIG90aGVyIFNGRnMuDQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZG9sc29uLXNmYy1vYW0tc2ZmLXNmLWN2LTAwIA0KDQoNCiAg ICAgICAgICAgT0FNIE1lY2hhbmlzbSBmb3IgU0ZGLVNGIENvbm5lY3Rpdml0eSBWZXJpZmljYXRp b24NCiAgICAgICAgICAgICAgICAgICBkcmFmdC1kb2xzb24tc2ZjLW9hbS1zZmYtc2YtY3YtMDAN Cg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gYW5k IHBhY2tldCBmb3JtYXQgZm9yIGFsbG93aW5nIGENCiAgIFNlcnZpY2UgRnVuY3Rpb24gRm9yd2Fy ZGVyIChTRkYpIHRvIHZlcmlmeSBjb25uZWN0aXZpdHkgb2YgYW4NCiAgIGNvbm5lY3RlZCBTRkYg b3IgU2VydmljZSBGdW5jdGlvbiAoU0YpLg0KDQoNCg0KSW4gYnJpZWYsIGl0J3MgYW4gZWNobyBy ZXF1ZXN0IGZyb20gU0ZGIHRvIFNGIChvciB0byBhbm90aGVyIFNGRiksDQp1dGlsaXppbmcgdGhl IHJlY2VudCBvdXRwdXQgb2YgdGhlIE92ZXJsYXkgT0FNIERlc2lnbiBUZWFtOg0KIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vb2FtZHQtcnRnd2ctZGVtYW5kLWNjLWN2LTAwDQpU aGUgT09BTSBQaW5nIGZvcm1hdCBpcyBwbGFjZWQgd2l0aGluIE5TSCBhbmQgZGVsaXZlcmVkIGlu LWJhbmQuDQoNClRoaXMgaXMgbm90IGEgcGF0aCBjaGVjaywganVzdCBhIGNvbm5lY3Rpdml0eSBj aGVjayB0byBOU0ggcGVlcnMuDQoNCg0KT2YgY291cnNlIGZlZWRiYWNrIGlzIGFsd2F5cyB3ZWxj b21lLg0KDQoNCi1EYXZlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANClNlbnQ6IEZyaWRheSwgSnVseSAwOCwgMjAxNiAyOjQ3IFBNDQpUbzogRGF2ZSBEb2xzb247 IEt5bGUgTGFyb3NlDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWRvbHNvbi1zZmMtb2FtLXNmZi1zZi1jdi0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtZG9sc29uLXNmYy1vYW0tc2ZmLXNmLWN2LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBEYXZpZCBEb2xzb24gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYg cmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWRvbHNvbi1zZmMtb2FtLXNmZi1zZi1jdg0KUmV2 aXNpb246CTAwDQpUaXRsZToJCU9BTSBNZWNoYW5pc20gZm9yIFNGRi1TRiBDb25uZWN0aXZpdHkg VmVyaWZpY2F0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE2LTA3LTA4DQpHcm91cDoJCUluZGl2aWR1 YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk2DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRvbHNvbi1zZmMtb2FtLXNmZi1zZi1jdi0wMC50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1kb2xzb24tc2ZjLW9hbS1zZmYtc2YtY3YvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbHNvbi1zZmMtb2FtLXNmZi1zZi1jdi0wMA0KDQoNCkFi c3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gYW5kIHBhY2tl dCBmb3JtYXQgZm9yIGFsbG93aW5nIGENCiAgIFNlcnZpY2UgRnVuY3Rpb24gRm9yd2FyZGVyIChT RkYpIHRvIHZlcmlmeSBjb25uZWN0aXZpdHkgb2YgYW4NCiAgIGNvbm5lY3RlZCBTRkYgb3IgU2Vy dmljZSBGdW5jdGlvbiAoU0YpLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sat Jul 9 06:25: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 A86FA12D50B for ; Sat, 9 Jul 2016 06:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 i77YJVjYdBcL for ; Sat, 9 Jul 2016 06:25:10 -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 B101A12B03B for ; Sat, 9 Jul 2016 06:25:10 -0700 (PDT) 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.0195.001; Sat, 9 Jul 2016 09:25:09 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-dolson-sfc-oam-sff-sf-cv-00.txt Thread-Index: AQHR2Vn5GoVFNSykt0+msF5bjuwnz6AQF+1P Date: Sat, 9 Jul 2016 13:25:09 +0000 Message-ID: <20160709132508.5673043.80477.95951@sandvine.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Kyle Larose Subject: Re: [sfc] FW: New Version Notification for draft-dolson-sfc-oam-sff-sf-cv-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: Sat, 09 Jul 2016 13:25:13 -0000 Oops, apparently the packet format in this draft is missing the ooam header= defined by =FDhttps://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-0= 0 Original Message From: Dave Dolson Sent: Friday, July 8, 2016 4:47 PM To: sfc@ietf.org Cc: Kyle Larose Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-oam-sff-sf= -cv-00.txt We submitted this draft to show how SFFs can actively monitor connectivity to SFs and other SFFs. https://tools.ietf.org/html/draft-dolson-sfc-oam-sff-sf-cv-00 OAM Mechanism for SFF-SF Connectivity Verification draft-dolson-sfc-oam-sff-sf-cv-00 Abstract This document describes a mechanism and packet format for allowing a Service Function Forwarder (SFF) to verify connectivity of an connected SFF or Service Function (SF). In brief, it's an echo request from SFF to SF (or to another SFF), utilizing the recent output of the Overlay OAM Design Team: https://tools.ietf.org/html/draft-ooamdt-rtgwg-demand-cc-cv-00 The OOAM Ping format is placed within NSH and delivered in-band. This is not a path check, just a connectivity check to NSH peers. Of course feedback is always welcome. -Dave -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, July 08, 2016 2:47 PM To: Dave Dolson; Kyle Larose Subject: New Version Notification for draft-dolson-sfc-oam-sff-sf-cv-00.txt A new version of I-D, draft-dolson-sfc-oam-sff-sf-cv-00.txt has been successfully submitted by David Dolson and posted to the IETF repository. Name: draft-dolson-sfc-oam-sff-sf-cv Revision: 00 Title: OAM Mechanism for SFF-SF Connectivity Verification Document date: 2016-07-08 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-dolson-sfc-oam-s= ff-sf-cv-00.txt Status: https://datatracker.ietf.org/doc/draft-dolson-sfc-oam-sff-s= f-cv/ Htmlized: https://tools.ietf.org/html/draft-dolson-sfc-oam-sff-sf-cv-= 00 Abstract: This document describes a mechanism and packet format for allowing a Service Function Forwarder (SFF) to verify connectivity of an connected SFF or Service Function (SF). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Jul 9 13:32: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 B1B8112B059 for ; Sat, 9 Jul 2016 13:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 b_DzkZQyp7X8 for ; Sat, 9 Jul 2016 13:32:47 -0700 (PDT) Received: from mail.cnit.it (demetra.cnit.it [217.9.64.12]) by ietfa.amsl.com (Postfix) with ESMTP id E9B8F12B02A for ; Sat, 9 Jul 2016 13:32:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cnit.it (Postfix) with ESMTP id 41EDA53FCD for ; Sat, 9 Jul 2016 22:32:45 +0200 (CEST) X-Virus-Scanned: by cnit.it Received: from mail.cnit.it ([127.0.0.1]) by localhost (demetra.cnit.it [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2F93eUZVSpXL for ; Sat, 9 Jul 2016 22:32:45 +0200 (CEST) Received: from giove (giove.cnit.it [217.9.64.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cnit.it (Postfix) with ESMTPSA id 26C4653F0B for ; Sat, 9 Jul 2016 22:32:45 +0200 (CEST) Received: from host127-130-dynamic.235-95-r.retail.telecomitalia.it (host127-130-dynamic.235-95-r.retail.telecomitalia.it [95.235.130.127]) by webmail.cnit.it (Horde Framework) with HTTP; Sat, 09 Jul 2016 20:32:44 +0000 Date: Sat, 09 Jul 2016 20:32:44 +0000 Message-ID: <20160709203244.Horde.3ieYHNQhm8u6mcMZtV6IVQ5@webmail.cnit.it> From: Barbara Martini To: sfc@ietf.org User-Agent: Internet Messaging Program (IMP) H5 (6.1.7) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: [sfc] CFP - 2nd IEEE Workshop on Orchestration for Software-Defined Infrastructures (O4SDI-2) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2016 20:32:50 -0000 ------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CFP ------------------------------------------------------------------------- CALL FOR PAPERS 2nd IEEE Workshop on Orchestration for Software-Defined Infrastructures (O4SDI-2) To be held in conjunction with the 2016 IEEE Conference on Network Function Virtualization and Software Defined Networks (IEEE NFV-SDN 2016) November 7, 2016 - Palo Alto, California, USA http://o4sdi.unibo.it/o4sdi2 ------------------------------------------------------------------------- IMPORTANT DATES Paper submission deadline: July 15, 2016 Acceptance notification: September 16, 2016 Camera-ready papers: October 7, 2016 SUBMISSION INFORMATION Paper submissions are handled on-line through the EDAS system: https://edas.info/newPaper.php?c=22175&track=81344 ----------------------------------------------------------------------- SCOPE The current industry trend of convergence between computing and networking eco-systems clearly shows that software will play an unprecedented dominant role also in future communication environments. Computing, storage, and connectivity services, as well as any other present and future application instances, will be deployed in the form of virtualized assets within a software-defined infrastructure running on top of general-purpose processing and communication hardware, all managed and made available under the cloud “As A Service†paradigm. This technological convergence and infrastructure sharing between the computing and communication systems portend a scenario with a “fog†of micro-clouds composed of generalized virtual functions providing both applications and network services that supplement those deployed in traditional cloud datacenters. The Second IEEE Workshop on Orchestration for Software-Defined Infrastructures (O4SDI) addresses the challenges that will facilitate orchestration and programmability of generalized virtual functions in Software Defined Infrastructures (SDI), enabling cloud and network providers to deploy integrated services across different resource domains. Orchestration mechanisms will facilitate the live deployment and lifecycle management of these virtual elements, at the application level, the server level, and the network level within a single domain and across multiple domains. Without such orchestration it will not be possible to enable dynamic establishment of generalized virtual function chains, according to service requirements. These challenges of orchestration are many-fold, with many open questions that need to be addressed in the areas of: - network "softwarization," which requires unified management of computing, storage, and network resources for the effective deployment, lifecycle management, and run-time configuration of generalized virtual functions; - abstraction models and open standard interfaces, needed for assuring vendor interoperability; - adaptation and optimization mechanisms, which must be enforced at global and/or local level for coping with user demand, application requirements, resource unavailability, etc. O4SDI aims at providing an international forum for researchers and practitioners from academia, industry, network operators, and service providers to discuss and address the challenges deriving from such emerging scenario where systems, processes, and workflows used in both computing and communications domains are converging. ------------------------------------------------------------------------- TOPICS OF INTEREST Due to the highly interdisciplinary scope of the workshop, contributions are expected from both computing and network-oriented research communities, with the aim of facilitating discussion, cross- fertilization and exchange of ideas and practices, and successfully promote innovative solutions toward a real programmatic use of software- defined infrastructures as a whole. Contributions that discuss lessons learnt and best practices, describe practical deployment and implementation experiences, and demonstrate innovative use-cases are especially encouraged for presentation and publication. We are particularly interested in papers that cover, but are not limited to, the following topics: - single domain and cross domain orchestration issues - integrated network and computing resource control and management - control and abstraction of heterogeneous networks - orchestration in SDN/NFV - run-time orchestration - orchestration for next-generation IP and optical networks - orchestration in 5G networks - QoS/QoE in software-defined infrastructures - orchestration for high-availability and resilience in software-defined infrastructures - intent-based orchestration - dynamic service composition and delivery - network programmability for service chaining - software engineering and operating systems techniques applied to orchestration - description, specification, and abstraction languages for orchestration - optimal orchestration algorithms - context-aware orchestration - functional architectures of orchestrating elements - testbed experiments on orchestrations - performance evaluation of orchestration elements - standardization issues in orchestration ------------------------------------------------------------------------- WORKSHOP CO-CHAIRS Stuart Clayman, University College London, UK - s.clayman@ucl.ac.uk Walter Cerroni, University of Bologna, Italy - walter.cerroni@unibo.it Barbara Martini, CNIT, Pisa, Italy - barbara.martini@cnit.it Federica Paganelli, CNIT, Firenze, Italy - federica.paganelli@cnit.it TECHNICAL PROGRAM COMMITEE To be announced soon ------------------------------------------------------------------------- AUTHOR GUIDELINES Prospective authors are invited to submit high-quality, original technical papers for presentation at the workshop and publication in the O4SDI Proceedings and IEEE Xplore. Papers must be written in English, unpublished and not submitted elsewhere. Full papers must be formatted as the standard IEEE double-column conference template. All final submissions should have a maximum paper length of six (6) printed pages (10-point font), including figures, without incurring additional page charges. To be published in the Workshop Proceedings and to be eligible for publication in IEEE Xplore, at least one author of an accepted paper is required to register and present the paper at the workshop. The IEEE reserves the right to exclude a paper from distribution after the conference (including its removal from IEEE Xplore) if the paper is not presented at the conference. Papers are reviewed on the basis that they do not contain plagiarized material and have not been submitted to any other conference at the same time (double submission). For additional author guidelines, please refer to: http://nfvsdn2016.ieee-nfvsdn.org/authors/call-for-papers/submission-guidelines/ From nobody Mon Jul 11 00:41: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 0254812D0C2 for ; Mon, 11 Jul 2016 00:41:02 -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 H1jxvqLQtwRl for ; Mon, 11 Jul 2016 00:40:59 -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 4850212B01C for ; Mon, 11 Jul 2016 00:40:59 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A2D3926422B; Mon, 11 Jul 2016 09:40:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7E22627C073; Mon, 11 Jul 2016 09:40:57 +0200 (CEST) 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.0301.000; Mon, 11 Jul 2016 09:40:57 +0200 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14kDWWZtljiaXEKuqE++y3FX46AS3ytA Date: Mon, 11 Jul 2016 07:40:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DCDA99@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <60B45C4E-916C-4CE7-B076-34110590BD61@cisco.com> In-Reply-To: <60B45C4E-916C-4CE7-B076-34110590BD61@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_787AE7BB302AE849A7480A190F8B933008DCDA99OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.11.72417 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2016 07:41:02 -0000 --_000_787AE7BB302AE849A7480A190F8B933008DCDA99OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBjaGFpcnMsDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBhcyBh IFdHIGRvY3VtZW50Lg0KDQpBcyBhIGNvLWF1dGhvciwgSSB3b3VsZCBsaWtlIHRvIG1lbnRpb24g dGhhdCBJIGRvbuKAmXQgaGF2ZSBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdCBmd2l3Lg0K DQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g RGUgbGEgcGFydCBkZSBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KRW52b3nDqSA6IG1lcmNyZWRp IDYganVpbGxldCAyMDE2IDE1OjE5DQrDgCA6IHNmY0BpZXRmLm9yZw0KT2JqZXQgOiBSZTogW3Nm Y10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwt MDYNCg0KQ29ycmVjdGlvbi4NCg0KVGhlIHRleHQgc2hvdWxkIHJlYWQg4oCYZHJhZnQtZG9sc29u LXNmYy1oaWVyYXJjaGljYWwtMDbigJkgLi4NCg0KU0ZDIENoYWlycw0KDQpGcm9tOiBzZmMgPHNm Yy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFs ZiBvZiBKaW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lz Y28uY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgSnVseSA2LCAyMDE2IGF0IDk6MTcgQU0NClRvOiAi c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJh ZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDYNCg0KRGVhciBXRzoNCg0KVGhpcyBlbWFpbCBz ZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtaGllcmFy Y2hpY2FsLTA2IGFzIGEgV0cgZG9jdW1lbnQuIFRoZSBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1 biBmb3IgMiB3ZWVrcyBlbmRpbmcgNy8yNS8yMDE2Lg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMg aXMgYSBjYWxsIGZvciBhZG9wdGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29udGVudCBv ZiB0aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQg dGhlIFdHIHdpbGwgZm9jdXMgaXRzIGVmZm9ydHMgb24gdGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdv aW5nIGZvcndhcmQsIGFuZCB1c2UgdGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNz dWVzIGFuZCBkb2N1bWVudGluZyB0aGUgV0figJlzIGRlY2lzaW9ucy4NCg0KUGxlYXNlIGluZGlj YXRlIHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlmIG5vdCB3aHku IElzc3VlcyB5b3UgaGF2ZSB3aXRoIHRoZSBjdXJyZW50IGRvY3VtZW50IGl0c2VsZiBjYW4gYWxz byBiZSByYWlzZWQsIGJ1dCB0aGV5IHNob3VsZCBiZSByYWlzZWQgaW4gdGhlIGNvbnRleHQgb2Yg d2hhdCBzaG91bGQgYmUgY2hhbmdlZCBpbiB0aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0 aGVyIHRoYW4gYSBwcmUtY29uZGl0aW9uIGZvciBhZG9wdGlvbi4NCg0KRmluYWxseSwgbm93IGlz IGFsc28gYSBnb29kIHRpbWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBh cHBsaWVzIHRvIHRoaXMgZHJhZnQsIGluIGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1cmUgb2Js aWdhdGlvbnMgZm9yIFdHIHBhcnRpY2lwYW50cyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBh bmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVu dCBhdXRob3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCAodG8gdGhlIGNoYWlycykgd2hl dGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KDQpUaGFua3Mh DQoNClNGQyBDaGFpcnMNCg== --_000_787AE7BB302AE849A7480A190F8B933008DCDA99OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0 eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsN Cglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgY2hhaXJzLA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRy YWZ0IGFzIGEgV0cgZG9jdW1lbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+QXMgYSBjby1hdXRob3IsIEkgd291bGQgbGlrZSB0byBtZW50aW9u IHRoYXQgSSBkb27igJl0IGhhdmUgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQgZndpdy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gSmltIEd1aWNoYXJkIChqZ3Vp Y2hhcik8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3I8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPmVkaSA2IGp1aWxsZXQgMjAxNiAxNToxOTxicj4NCjxiPsOAJm5ic3A7 OjwvYj4gc2ZjQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3NmY10gQ2Fs bCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNvcnJlY3Rp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSB0ZXh0IHNob3VsZCBy ZWFkIOKAmGRyYWZ0LTxiPmRvbHNvbjwvYj4tc2ZjLWhpZXJhcmNoaWNhbC0wNuKAmSAuLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TRkMgQ2hhaXJzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5zZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYg b2YgSmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5q Z3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEp1 bHkgNiwgMjAxNiBhdCA5OjE3IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5bc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNo aWNhbC0wNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkRlYXIgV0c6PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UaGlzIGVtYWlsIHNlcnZlcyBhcyBh IGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy1oaWVyYXJjaGljYWwtMDYg YXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgcnVuIGZvciAyIHdl ZWtzIGVuZGluZyA3LzI1LzIwMTYuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj ayI+UGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24sIGFuZCBub3Qg YSBsYXN0IGNhbGwgZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBBZG9wdGluZyBhIFdHIGRv Y3VtZW50IHNpbXBseSBtZWFucyB0aGF0IHRoZSBXRyB3aWxsIGZvY3VzIGl0cyBlZmZvcnRzIG9u IHRoYXQNCiBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZvcndhcmQsIGFuZCB1c2UgdGhhdCBkb2N1 bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFuZCBkb2N1bWVudGluZyB0aGUgV0figJlz IGRlY2lzaW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5QbGVhc2Ug aW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBmb3Igbm90LCBhbmQgaWYgbm90 IHdoeS4gSXNzdWVzIHlvdSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNh biBhbHNvIGJlIHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNlZCBpbiB0aGUgY29udGV4 dA0KIG9mIHdoYXQgc2hvdWxkIGJlIGNoYW5nZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndh cmQsIHJhdGhlciB0aGFuIGEgcHJlLWNvbmRpdGlvbiBmb3IgYWRvcHRpb24uJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+RmluYWxseSwgbm93IGlzIGFsc28gYSBn b29kIHRpbWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRv IHRoaXMgZHJhZnQsIGluIGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1cmUgb2JsaWdhdGlvbnMg Zm9yIFdHIHBhcnRpY2lwYW50cyAoc2VlIFJGQ3MgMzk3OSwNCiA0ODc5LCAzNjY5IGFuZCA1Mzc4 IGZvciBtb3JlIGRldGFpbHMpLiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhv ciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsICh0byB0aGUgY2hhaXJzKSB3aGV0aGVyIG9y IG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UaGFua3MhPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5TRkMgQ2hhaXJzPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933008DCDA99OPEXCLILMA3corp_-- From nobody Mon Jul 11 09:49: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 C8AFB12D5D3 for ; Mon, 11 Jul 2016 09:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 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.287, 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 kZJf7FtlYbdf for ; Mon, 11 Jul 2016 09:49:17 -0700 (PDT) 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 F204A12D5D2 for ; Mon, 11 Jul 2016 09:49:15 -0700 (PDT) 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 CSJ97564; Mon, 11 Jul 2016 16:49:12 +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; Mon, 11 Jul 2016 17:49:11 +0100 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; Mon, 11 Jul 2016 09:49:07 -0700 From: Linda Dunbar To: "Elzur, Uri" , Sunil Vallamkonda , "Joel M. Halpern" , Dave Dolson , "Bottorff, Paul" , "sfc@ietf.org" Thread-Topic: Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-01.txt Thread-Index: AQHR25QjJwGNzKblm0W3i6lJNGK83g== Date: Mon, 11 Jul 2016 16:49:07 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657EF832D@dfweml501-mbb> References: <56FB0D84.9050602@joelhalpern.com> <56FB1186.7070807@joelhalpern.com> <56FC02BC.8060203@joelhalpern.com> <880ca7e35d334ab48898aa4c78984ac1@SEAEXCHMBX06.olympus.F5Net.com> <56FC0C62.1050200@joelhalpern.com> <56FC1318.6070703@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B8995858932536C@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B8995858932536C@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.119] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657EF832Ddfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5783CE0A.000A, 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: 9fd98577ee986f8a92129423d18fe1f2 Archived-At: Subject: [sfc] Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-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: Mon, 11 Jul 2016 16:49:30 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657EF832Ddfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model/ has = the examples of metadata that may need to be passed among SFs along a SFP, = e.g. SF1 may at real-time attach DoS information for the next SF in downst= ream. SF1 provides the hint and it is up to the downstream SFs to process i= t or ignore it. However if a downstream SF chooses to processes, it needs s= tandardized metadata data model to understand the hint encoded by SF1 in pa= ckets. To minimize the extra bytes added to packets in NSH, it is necessary to hav= e compact encoding of the metadata carried by data packets. Achieving this = goal will need control plane to inform the encoding mechanisms to SFs via o= ut of band control channels. What do people think about the proposed framework for metadata exchanged am= ong SFs on a SFP? Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Elzur, Uri Sent: Friday, April 01, 2016 5:56 PM To: Sunil Vallamkonda; Joel M. Halpern; Dave Dolson; Bottorff, Paul; sfc@ie= tf.org Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-m= etadata-model-00.txt Sunil To advance your point, it may be of advantage, IMHO, if you provide a concr= ete example of what metadata can be shared, and requires interoperability a= mong vendors, in a specific example e.g. FW LB NAT (or choose your favorite= ). Notice some proposed directions in your draft. The thread reads very theoretical and suggests limited value for inter vend= or interaction. Seems like you wish to counter it. A specific example may h= elp bring the conversation down to ground level. Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sunil Vallamkonda Sent: Wednesday, March 30, 2016 11:04 AM To: Joel M. Halpern >; Dave= Dolson >; Bottorff, Paul= >; sfc@ietf.org Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-m= etadata-model-00.txt Joel, Good point, we are not trying to enumerate all the possible algorithmic beh= aviors. Yes, the proposal addresses both vendor and standardized metadata, where la= tter could be a flavor of former. In below MD-2, ignoring all metadata is a simple implementation, though wit= h limited capabilities. However in all elements the sender and receiver nee= d to co-ordinate metadata in a dynamic and scalable way to take intelligent= actions. Re: #1: Is there a definite limitation in framework for metadata to be same= for all packets ? It should not limit or mandate either way. Re: #2: If there is no need for receiver to understand the semantics across= vendors and products and releases, I do not believe it would be a scalabl= e solution. The code semantics and actions need to be aware by elements for= metadata, without which we might well use only 'reserved' part of header o= r just treat MD-2 as a 'reserved' header itself, IMHO. Again to clarify, the intent and focus is have the ability to understand an= d extend metadata semantics for deployment. The goal is not to enumerate ev= ery possible situation but to provide semantics to customize and support al= gorithmic and other situations as individual case may be. Thanks, Sunil -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Wednesday, March 30, 2016 10:56 AM To: Dave Dolson >; Sunil = Vallamkonda >; Bottorff, Paul >; sfc@ietf.org Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-m= etadata-model-00.txt In terms of copied information, control tells the SF what to copy. It does= not matter what the granularity is. Given that "flow" does not have a consistent meaning (sometimes it means 5-= tuple, sometimes it means other things) trying to define control instructio= ns at other granularities than packet gets us into algorithmic behaviors. = And I do not think we want to try to enumerate all of the "supported" algor= ithmic behaviors. Similarly, if the information is not the same as that from the prompting pa= cket, we are again finding ourselves getting into algorithmic instructions = (maybe you complement this field, or add 100 to that field, or bounce the t= hird field off the roof.) If we neeed algorithmic behavior, it seems to me that the SF has to know wh= at it is doing. It can not rely on control to tell it. Yes, this places s= ome limits on generality of inserting metadata in produced packets. I woul= d be interested in improvement, but I have not seen one. Yours, Joel On 3/30/16 1:47 PM, Dave Dolson wrote: > Joel, > I'd like to examine this point of yours: >> 2) Metadata to be copied from a prompting packet. This would seem to >> be provided by control as a list of type codes, with no need to >> understand semantics. > > Yes, I think control should provide information about different type code= s. > But we believe there *is* some requirement to understand certain semantic= s. > E.g., > - is the metadata about the packet, about the flow or about the source or= destination end-point? > - is the metadata important enough to add to new packets, or is it option= al? > - is the metadata direction-specific, or can the value be cloned from a r= equest to a response? > > If we don't address different types of semantics, I think we need to > agree there is only one type that works in all cases, or that certain > types should not be used in an opaque manner, or that certain types shoul= d not be used with service functions that need to inject packets. > > > Personally, I think that per-packet opaque metadata is problematic and pr= obably to be avoided. > E.g., a metadata that is checksum of the packet. > If this is opaque to a function, the function may modify the packet or > clone the metadata from one packet to another without being able to updat= e it. > > -Dave > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, March 30, 2016 1:27 PM > To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding > draft-vallamkonda-sfc-metadata-model-00.txt > > I think you are mixing two concepts. > There is vendor metadata and standardized metadata. > > I do not think anything in the framework I have seen will make vendor > metadata interoperate without coordination between vendors. > > And as far as I can tell, there is nothing needed from the framework > to make standard metadata interoperate. > > That leaves the corner case of experimental or developmental metadata. > Experiments almost always need coordiantion. > > If we are talking about MD-2, it seems to me that SF and SFF will > simply ignore any metadata that they do not understand. In the common > case, SFF will ignore all metadata entirely. > > You have raised the question of what metadata shoudl go on packets > originated by service functions. This seems to be a complex question, > that is not helped by the framework. As far as I can tell, I can see > the following cases: > 1) Metadata about the SF originating the packet. This is common > across all packets, and can be provided to the SF by control means in > an opaque blob. > 2) Metadata to be copied from a prompting packet. This would seem to > be provided by control as a list of type codes, with no need to > understand semantics. > 3) Metadata derived algorithmically from information available to the > service function. This is hard. I do not see how the framework helps > here at all. Is it needed? > > Yours, > Joel > > On 3/30/16 1:06 PM, Sunil Vallamkonda wrote: >> When metadata is exchanged between SFFs, SFs, SFCs, it begs to the quest= ions of interpretations. Without a framework for opaque metadata, the ambig= uity between vendor products in service chain makes it incompatible unless = the resolution is hardcoded across of releases and platforms, and vendor sp= ecific information encoded. The flexibility and ability for metadata to be= interoperable and scale are benefits that are much needed for rapid deploy= ments and adoption. >> >> >> Thanks, >> Sunil >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 30, 2016 9:46 AM >> To: Bottorff, Paul >= ; Dave Dolson >> >; Sunil Vallamkonda <= sunilvk@f5.com>; >> sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> I don't see why we would specify which metadata is of interest to a spec= ific SF. It is up to the SF what it is interested in, not up to service ch= aining to control that. >> As for preserving forwarding addresses, while I see value in doing so fo= r some transports, I don't see how SFC can mandate that since it is a trans= port dependent behavior. >> >> Yours, >> Joel >> >> On 3/30/16 12:31 PM, Bottorff, Paul wrote: >>> Hi Dave and Joel: >>> >>> IMHO the most important thing to standardize is how an SFs couple to a = chain. We are already implying that it would be desirable for SFs to pass b= oth chain forwarding addresses and meta-data from ingress to egress (proxy = forwarding always comes with a cost), however this alone does not provide e= nough guidance for SF network interfacing. We also have issues like how for= warding reversals are indicated at L4-Higher SFs and what meta-data is opaq= ue and what is for SF consumption. >>> >>> Cheers, >>> >>> Paul >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: Tuesday, March 29, 2016 7:30 PM >>> To: Joel Halpern Direct >; Sunil >>> Vallamkonda >; Joel M. Halpern >; >>> sfc@ietf.org >>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> Joel, >>> Consider a Service Function that needs to inject a packet, such as >>> articulated in https://tools.ietf.org/html/draft-penno-sfc-packet-02 >>> The question arises, what metadata should be put in the NSH header of a= n injected packet? >>> >>> Without some kind of rigorous description of a type of metadata, I don'= t know how to program the Service Function to do it properly. >>> >>> The alternative is to hard-code each service function with the supporte= d types of metadata. >>> This wouldn't allow a function to handle metadata it wasn't programmed = for. >>> >>> >>> So unless there is some easier way of understanding this, there seems t= o be a gap in specifying Service Function behaviour. >>> This is one thing we're trying to figure out. >>> >>> >>> -Dave >>> >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >>> Direct >>> Sent: Tuesday, March 29, 2016 7:37 PM >>> To: Sunil Vallamkonda; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> It may help to see some use cases. >>> >>> But it sounds, at best, like a specific control plane solution to some = set of problems. >>> Specific control plane solutions, as distinct from descriptions of requ= irements, are out of scope for the working group. >>> >>> Yours, >>> Joel >>> >>> On 3/29/16 7:32 PM, Sunil Vallamkonda wrote: >>>> The focus is ability for vendor compatibility and extensibility in SF = eco-system without hardcoding and human guessing. >>>> The categorization and rest may or may not be a fallout of this. With= out such a framework, it makes interpretations harder across implementation= s. This would be normal case rather than exception, IMHO. The goal is not t= o standardize any vendor data, but provide a framework to promote vendor co= mpatibility and extensibility across systems. As a clarification we can wa= lk through use cases to understand the benefits. >>>> >>>> >>>> Thank you, >>>> Sunil. >>>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Tuesday, March 29, 2016 4:20 PM >>>> To: Sunil Vallamkonda >; sfc@iet= f.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> I am sorry. I don't see the value in this. >>>> >>>> Trying to categorize metadata does not seem to help anything. >>>> Trying to standardize a descriptive langauge for metadata seems to imp= ly something that can consume such a language. I can not imagine anything = that can usefully consume this. >>>> >>>> I can understand how a human being would use a registry (which we have= to have) to know what T codes are defined, and where to find descriptions = of their meaning. >>>> But that meaning description is going to be in English. A file that t= ells me that value 17 is the Dragaeran Corporate type code for Houses does = not tell me anything. >>>> >>>> The only corner case for the YANG is if my system has some understandi= ng of the semantics of various pieces of metadata, but wants to know what c= ode is associated with a particular usage. >>>> The problem is that we have mutliple different protocols that may want= to provide that information, so all that SFC can define is that the contro= l system must include a way to provide that information. >>>> >>>> Given that much of the metadata is not vendor specific, the structure = seems very odd. >>>> ANd it seems likely that any vendor specific metadata will need the se= mantics to already be known, since we can not standardize that. >>>> >>>> Yours in puzzlement, >>>> Joel >>>> >>>> On 3/29/16 6:33 PM, Sunil Vallamkonda wrote: >>>>> Metadata is a vital element of SFC and thus NFV. >>>>> >>>>> Additionally, interoperability and vendor support challenges need >>>>> to be addressed in a scalable and adaptable way for rapid deployment. >>>>> >>>>> In January we uploaded draft-vallamkonda-sfc-metadata-model-00, >>>>> which proposes terminology for talking about metadata in an extensibl= e fashion. >>>>> >>>>> If there are no objections, we'd like to start pushing this >>>>> terminology into drafts about NSH and the control-plane. >>>>> >>>>> Please let us know what you think. >>>>> >>>>> Thank you, >>>>> >>>>> Sunil. >>>>> >>>>> =3D=3D >>>>> >>>>> A new version of I-D, draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> has been successfully submitted by Sunil Vallamkonda and posted to >>>>> the IETF repository. >>>>> >>>>> Name: draft-vallamkonda-sfc-metadata-model >>>>> >>>>> Revision: 00 >>>>> >>>>> Title: Information Model for SFC Metadata >>>>> >>>>> Document date: 2016-01-28 >>>>> >>>>> Group: Individual Submission >>>>> >>>>> Pages: 9 >>>>> >>>>> URL: >>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadat >>>>> a- >>>>> m >>>>> o >>>>> del-00.txt >>>>> >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-mo >>>>> de >>>>> l >>>>> / >>>>> >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-0 >>>>> 0 >>>>> >>>>> Abstract: >>>>> >>>>> Various types of metadata are applicable to Service >>>>> Function Chaining >>>>> >>>>> (SFC). A Service Function (SF) needs information about >>>>> all metadata >>>>> >>>>> passing through it. The metadata could be used to convey >>>>> >>>>> preprocessing information about the packet by other nodes >>>>> and an SF >>>>> >>>>> can attach post processing information as deemed necessary. >>>>> >>>>> The purpose of this document is to rigorously define the >>>>> classes of >>>>> >>>>> metadata and provide a vocabulary and information model for m= etadata. >>>>> >>>>> Each item of metadata refers to a subject, examples of >>>>> which are IP >>>>> >>>>> endpoint, flow or individual packet. >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_4A95BA014132FF49AE685FAB4B9F17F657EF832Ddfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
https://datatracker.= ietf.org/doc/draft-vallamkonda-sfc-metadata-model/ has the examples of metadata that may need to be passed among SFs along a SFP, e.g. =
 
SF1 may at real-time attach DoS information for the next SF in downstre= am. SF1 provides the hint and it is up to the downstream SFs to process it = or ignore it. However if a downstream SF chooses to processes, it needs standardized metadata data model to under= stand the hint encoded by SF1 in packets.
 
To minimize the extra bytes added to packets i= n NSH, it is necessary to have compact encoding of the metadata carried by = data packets. Achieving this goal will need control plane to inform the enc= oding mechanisms to SFs via out of band control channels.
 
What do people think about the proposed framew= ork for metadata exchanged among SFs on a SFP?
 
 
Linda
 
 
 
-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Elzur, Uri
Sent: Friday, April 01, 2016 5:56 PM
To: Sunil Vallamkonda; Joel M. Halpern; Dave Dolson; Bottorff, Paul; sfc@ie= tf.org
Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-m= etadata-model-00.txt
 
Sunil
 
To advance your point, it may be of advantage,= IMHO, if you provide a concrete example of what metadata can be shared, an= d requires interoperability among vendors, in a specific example e.g. FW LB= NAT (or choose your favorite). Notice some proposed directions in your draft.
 
The thread reads very theoretical and suggests= limited value for inter vendor interaction. Seems like you wish to counter= it. A specific example may help bring the conversation down to ground leve= l.
 
Thx
 
Uri ("Oo-Ree")
C: 949-378-7568
 
-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sunil Vallamkonda=
Sent: Wednesday, March 30, 2016 11:04 AM
To: Joel M. Halpern <jmh@joelhalpern.com>; Dave Dolson <ddolson@sandvine.com>; Bottorff, Paul <= ;paul.bottorff@hpe.com>; sfc@ietf.org
Subject: Re: [sfc] SFC Metadata: Comments rega= rding draft-vallamkonda-sfc-metadata-model-00.txt
 
Joel,
 
Good point, we are not trying to enumerate all= the possible algorithmic behaviors.
Yes, the proposal addresses both vendor and st= andardized metadata, where latter could be a flavor of former.
In below MD-2, ignoring all metadata is a simp= le implementation, though with limited capabilities. However in all element= s the sender and receiver need to co-ordinate metadata in a dynamic and sca= lable way to take intelligent actions.
 
Re: #1: Is there a definite limitation in fram= ework for metadata to be same for all packets ? It should not limit or mand= ate either way.
Re: #2: If there is no need for receiver to un= derstand the semantics across vendors and products and releases, I do not b= elieve  it would be a scalable solution. The code semantics and action= s need to be aware by elements for metadata, without which we might well use only 'reserved' part of header or just trea= t MD-2 as a 'reserved' header itself, IMHO.
 
Again to clarify, the intent and focus is have= the ability to understand and extend metadata semantics for deployment. Th= e goal is not to enumerate every possible situation but to provide semantic= s to customize and support algorithmic and other situations as individual case may be.
 
 
Thanks,
Sunil
 
-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Wednesday, March 30, 2016 10:56 AM
To: Dave Dolson <ddolson@sandvine.com>; Sunil Vallamkonda <sunilvk@f5.com>; Bottorff, Paul <paul.bottorff@hpe.com>; sfc@ietf.org
Subject: Re: [sfc] SFC Metadata: Comments rega= rding draft-vallamkonda-sfc-metadata-model-00.txt
 
In terms of copied information, control tells = the SF what to copy.  It does not matter what the granularity is.
 
Given that "flow" does not have a co= nsistent meaning (sometimes it means 5-tuple, sometimes it means other thin= gs) trying to define control instructions at other granularities than packe= t gets us into algorithmic behaviors.  And I do not think we want to try to enumerate all of the "supported" a= lgorithmic behaviors.
 
Similarly, if the information is not the same = as that from the prompting packet, we are again finding ourselves getting i= nto algorithmic instructions (maybe you complement this field, or add 100 t= o that field, or bounce the third field off the roof.)
 
If we neeed algorithmic behavior, it seems to = me that the SF has to know what it is doing.  It can not rely on contr= ol to tell it.  Yes, this places some limits on generality of insertin= g metadata in produced packets.  I would be interested in improvement, but I have not seen one.
 
Yours,
Joel
 
On 3/30/16 1:47 PM, Dave Dolson wrote:<= /div>
> Joel,
> I'd like to examine this point of yours:<= /font>
>> 2) Metadata to be copied from a promp= ting packet.  This would seem to
>> be provided by control as a list of t= ype codes, with no need to
>> understand semantics.
>
> Yes, I think control should provide infor= mation about different type codes.
> But we believe there *is* some requiremen= t to understand certain semantics.
> E.g.,
> - is the metadata about the packet, about= the flow or about the source or destination end-point?
> - is the metadata important enough to add= to new packets, or is it optional?
> - is the metadata direction-specific, or = can the value be cloned from a request to a response?
>
> If we don't address different types of se= mantics, I think we need to
> agree there is only one type that works i= n all cases, or that certain
> types should not be used in an opaque man= ner, or that certain types should not be used with service functions that n= eed to inject packets.
>
>
> Personally, I think that per-packet opaqu= e metadata is problematic and probably to be avoided.
> E.g., a metadata that is checksum of the = packet.
> If this is opaque to a function, the func= tion may modify the packet or
> clone the metadata from one packet to ano= ther without being able to update it.
>
> -Dave
>
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Wednesday, March 30, 2016 1:27 PM
> To: Sunil Vallamkonda; Bottorff, Paul; Da= ve Dolson; sfc@ietf.org
> Subject: Re: [sfc] SFC Metadata: Comments= regarding
> draft-vallamkonda-sfc-metadata-model-00.t= xt
>
> I think you are mixing two concepts.
> There is vendor metadata and standardized= metadata.
>
> I do not think anything in the framework = I have seen will make vendor
> metadata interoperate without coordinatio= n between vendors.
>
> And as far as I can tell, there is nothin= g needed from the framework
> to make standard metadata interoperate.
>
> That leaves the corner case of experiment= al or developmental metadata.
> Experiments almost always need coordianti= on.
>
> If we are talking about MD-2, it seems to= me that SF and SFF will
> simply ignore any metadata that they do n= ot understand.  In the common
> case, SFF will ignore all metadata entire= ly.
>
> You have raised the question of what meta= data shoudl go on packets
> originated by service functions.  Th= is seems to be a complex question,
> that is not helped by the framework. = ; As far as I can tell, I can see
> the following cases:
> 1) Metadata about the SF originating the = packet.  This is common
> across all packets, and can be provided t= o the SF by control means in
> an opaque blob.
> 2) Metadata to be copied from a prompting= packet.  This would seem to
> be provided by control as a list of type = codes, with no need to
> understand semantics.
> 3) Metadata derived algorithmically from = information available to the
> service function.  This is hard.&nbs= p; I do not see how the framework helps
> here at all.  Is it needed?
>
> Yours,
> Joel
>
> On 3/30/16 1:06 PM, Sunil Vallamkonda wro= te:
>> When metadata is exchanged between SF= Fs, SFs, SFCs, it begs to the questions of interpretations. Without a frame= work for opaque metadata, the ambiguity between vendor products in service = chain makes it incompatible unless the resolution is hardcoded across of releases and platforms, and vendor specific informat= ion encoded.  The flexibility and ability for metadata to be interoper= able and scale are benefits that are much needed for rapid deployments and = adoption.
>>
>>
>> Thanks,
>> Sunil
>>
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Wednesday, March 30, 2016 9:46 = AM
>> To: Bottorff, Paul <paul.bottorff@hpe.com>; Dave Dolson
>> <ddolson@sandvine.com>; Sunil Vallamkonda <sunilvk@f5.com>;
>> Subject: Re: [sfc] SFC Metadata: Comm= ents regarding
>> draft-vallamkonda-sfc-metadata-model-= 00.txt
>>
>> I don't see why we would specify whic= h metadata is of interest to a specific SF.  It is up to the SF what i= t is interested in, not up to service chaining to control that.
>> As for preserving forwarding addresse= s, while I see value in doing so for some transports, I don't see how SFC c= an mandate that since it is a transport dependent behavior.
>>
>> Yours,
>> Joel
>>
>> On 3/30/16 12:31 PM, Bottorff, Paul w= rote:
>>> Hi Dave and Joel:
>>>
>>> IMHO the most important thing to = standardize is how an SFs couple to a chain. We are already implying that i= t would be desirable for SFs to pass both chain forwarding addresses and me= ta-data from ingress to egress (proxy forwarding always comes with a cost), however this alone does not provide enough guida= nce for SF network interfacing. We also have issues like how forwarding rev= ersals are indicated at L4-Higher SFs and what meta-data is opaque and what= is for SF consumption.
>>>
>>> Cheers,
>>>
>>> Paul
>>>
>>> -----Original Message-----=
>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson=
>>> Sent: Tuesday, March 29, 2016 7:3= 0 PM
>>> To: Joel Halpern Direct <jmh.direct@joelhalpern.com>= ; Sunil
>>> Vallamkonda <sunilvk@f5.com>; Joel M. Halpern <jmh@joelhalpern.com>;
>>> Subject: Re: [sfc] SFC Metadata: = Comments regarding
>>> draft-vallamkonda-sfc-metadata-mo= del-00.txt
>>>
>>> Joel,
>>> Consider a Service Function that = needs to inject a packet, such as
>>> The question arises, what metadat= a should be put in the NSH header of an injected packet?
>>>
>>> Without some kind of rigorous des= cription of a type of metadata, I don't know how to program the Service Fun= ction to do it properly.
>>>
>>> The alternative is to hard-code e= ach service function with the supported types of metadata.
>>> This wouldn't allow a function to= handle metadata it wasn't programmed for.
>>>
>>>
>>> So unless there is some easier wa= y of understanding this, there seems to be a gap in specifying Service Func= tion behaviour.
>>> This is one thing we're trying to= figure out.
>>>
>>>
>>> -Dave
>>>
>>>
>>>
>>> -----Original Message-----=
>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halper= n
>>> Direct
>>> Sent: Tuesday, March 29, 2016 7:3= 7 PM
>>> To: Sunil Vallamkonda; Joel M. Ha= lpern; sfc@ietf.org
>>> Subject: Re: [sfc] SFC Metadata: = Comments regarding
>>> draft-vallamkonda-sfc-metadata-mo= del-00.txt
>>>
>>> It may help to see some use cases= .
>>>
>>> But it sounds, at best, like a sp= ecific control plane solution to some set of problems.
>>> Specific control plane solutions,= as distinct from descriptions of requirements, are out of scope for the wo= rking group.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 3/29/16 7:32 PM, Sunil Vallamk= onda wrote:
>>>> The focus is ability for vend= or compatibility and extensibility in SF eco-system without hardcoding and = human guessing.
>>>> The categorization and rest m= ay or may not be a fallout of this.  Without such a framework, it make= s interpretations harder across implementations. This would be normal case = rather than exception, IMHO. The goal is not to standardize any vendor data, but provide a framework to promote vendor compatibility an= d extensibility across systems.  As a clarification we can walk throug= h use cases to understand the benefits.
>>>>
>>>>
>>>> Thank you,
>>>> Sunil.
>>>>
>>>> -----Original Message-----
>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>>> Sent: Tuesday, March 29, 2016= 4:20 PM
>>>> To: Sunil Vallamkonda <sunilvk@f5.com>; sfc@ietf.org
>>>> Subject: Re: [sfc] SFC Metada= ta: Comments regarding
>>>> draft-vallamkonda-sfc-metadat= a-model-00.txt
>>>>
>>>> I am sorry.  I don't see= the value in this.
>>>>
>>>> Trying to categorize metadata= does not seem to help anything.
>>>> Trying to standardize a descr= iptive langauge for metadata seems to imply something that can consume such= a language.  I can not imagine anything that can usefully consume thi= s.
>>>>
>>>> I can understand how a human = being would use a registry (which we have to have) to know what T codes are= defined, and where to find descriptions of their meaning.
>>>> But that meaning description = is going to be in English.  A file that tells me that value 17 is the = Dragaeran Corporate type code for Houses does not tell me anything.<= /div>
>>>>
>>>> The only corner case for the = YANG is if my system has some understanding of the semantics of various pie= ces of metadata, but wants to know what code is associated with a particula= r usage.
>>>> The problem is that we have m= utliple different protocols that may want to provide that information, so a= ll that SFC can define is that the control system must include a way to pro= vide that information.
>>>>
>>>> Given that much of the metada= ta is not vendor specific, the structure seems very odd.
>>>> ANd it seems likely that any = vendor specific metadata will need the semantics to already be known, since= we can not standardize that.
>>>>
>>>> Yours in puzzlement,
>>>> Joel
>>>>
>>>> On 3/29/16 6:33 PM, Sunil Val= lamkonda wrote:
>>>>> Metadata is a vital eleme= nt of SFC and thus NFV.
>>>>>
>>>>> Additionally,  inter= operability and vendor support challenges need
>>>>> to be addressed in a scal= able and adaptable way for rapid deployment.
>>>>>
>>>>> In January we uploaded dr= aft-vallamkonda-sfc-metadata-model-00,
>>>>> which proposes terminolog= y for talking about metadata in an extensible fashion.
>>>>>
>>>>> If there are no objection= s, we'd like to start pushing this
>>>>> terminology into drafts a= bout NSH and the control-plane.
>>>>>
>>>>> Please let us know what y= ou think.
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Sunil.
>>>>>
>>>>> =3D=3D
>>>>>
>>>>> A new version of I-D, dra= ft-vallamkonda-sfc-metadata-model-00.txt
>>>>>
>>>>> has been successfully sub= mitted by Sunil Vallamkonda and posted to
>>>>> the IETF repository.
>>>>>
>>>>> Name:   &n= bsp;            = ; draft-vallamkonda-sfc-metadata-model
>>>>>
>>>>> Revision:  &nbs= p;         00
>>>>>
>>>>> Title:   &= nbsp;           &nbs= p;    Information Model for SFC Metadata
>>>>>
>>>>> Document date:  = ;            2016-01= -28
>>>>>
>>>>> Group:   &= nbsp;            Ind= ividual Submission
>>>>>
>>>>> Pages:   &= nbsp;           &nbs= p; 9
>>>>>
>>>>> URL:
>>>>> a-
>>>>> m
>>>>> o
>>>>> del-00.txt
>>>>>
>>>>> Status:
>>>>> de
>>>>> l
>>>>> /
>>>>>
>>>>> Htmlized:
>>>>> 0
>>>>>
>>>>> Abstract:
>>>>>
>>>>>    &n= bsp;    Various types of metadata are applicable to Service =
>>>>> Function Chaining<= /div>
>>>>>
>>>>>    &n= bsp;    (SFC).  A Service Function (SF) needs informati= on about
>>>>> all metadata
>>>>>
>>>>>    &n= bsp;    passing through it.  The metadata could be used= to convey
>>>>>
>>>>>    &n= bsp;    preprocessing information about the packet by other = nodes
>>>>> and an SF
>>>>>
>>>>>    &n= bsp;    can attach post processing information as deemed nec= essary.
>>>>>
>>>>>    &n= bsp;    The purpose of this document is to rigorously define= the
>>>>> classes of
>>>>>
>>>>>    &n= bsp;    metadata and provide a vocabulary and information mo= del for metadata.
>>>>>
>>>>>    &n= bsp;    Each item of metadata refers to a subject, examples = of
>>>>> which are IP
>>>>>
>>>>>    &n= bsp;    endpoint, flow or individual packet.
>>>>>
>>>>> Please note that it may t= ake a couple of minutes from the time of
>>>>> submission until the html= ized version and diff are available at
>>>>> tools.ietf.org.
>>>>>
>>>>> The IETF Secretariat
>>>>>
>>>>>
>>>>>
>>>>> _________________________= ______________________
>>>>> sfc mailing list
>>>>>
>>>
>>> _________________________________= ______________
>>> sfc mailing list
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> _________________________________= ______________
>>> sfc mailing list
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
 
______________________________________________= _
sfc mailing list
 
______________________________________________= _
sfc mailing list
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F657EF832Ddfweml501mbb_-- From nobody Mon Jul 11 10:09:47 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 0DB7012D093 for ; Mon, 11 Jul 2016 10:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY2RADrZt6n7 for ; Mon, 11 Jul 2016 10:09:40 -0700 (PDT) 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 DC93F12D5F9 for ; Mon, 11 Jul 2016 10:09:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B31503C2F10; Mon, 11 Jul 2016 10:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1468256980; bh=7cLSvMa895FqU3cAogmw6ukm/iiRWMqrciw+Vf3KZYA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q1kVy0UJVvvZnPu1qY5G7rdTJVYONkZX8dAsmPTPuGa9rsgqunXlP+fj1FaRV4bLw mFNpSE+PGWXYwLHVpAVDCY0/0gNMtCcFsX2knh8iJdGeoihKTk0STchhNT8ywtc2HE 34z/RGl0ck8BkxWF1+E6GWqF3zFTm+pRDNC6xDHc= 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 A63363C2EB7; Mon, 11 Jul 2016 10:09:39 -0700 (PDT) To: Linda Dunbar , "Elzur, Uri" , Sunil Vallamkonda , Dave Dolson , "Bottorff, Paul" , "sfc@ietf.org" References: <56FB0D84.9050602@joelhalpern.com> <56FB1186.7070807@joelhalpern.com> <56FC02BC.8060203@joelhalpern.com> <880ca7e35d334ab48898aa4c78984ac1@SEAEXCHMBX06.olympus.F5Net.com> <56FC0C62.1050200@joelhalpern.com> <56FC1318.6070703@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B8995858932536C@ORSMSX114.amr.corp.intel.com> <4A95BA014132FF49AE685FAB4B9F17F657EF832D@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: Date: Mon, 11 Jul 2016 13:09:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657EF832D@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-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: Mon, 11 Jul 2016 17:09:46 -0000 I find it very hard to understand the advantage of the proposed framework. I am usually of the opinion that indirection is helpful in solving protocol identification problems. In this case however, I can not see any value in having control specify to an SF "You will find field X under TLV code A" using a quasi-standard X. For things with standard type code, there is clearly no need for such. For things with vendor defined type codes, the label X is no more useful than the vendor defined type code. After all, if the meaning of X were standard, then there would presuambly be a standard type code assigned to it. We have lots of space. Yours, Joel On 7/11/16 12:49 PM, Linda Dunbar wrote: > _https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model/_has > the examples of metadata that may need to be passed among SFs along a > SFP, e.g. > > /SF1 may at real-time attach DoS information for the next SF in > downstream. SF1 provides the hint and it is up to the downstream SFs to > process it or ignore it. However if a downstream SF chooses to > processes, it needs standardized metadata data model to understand the > hint encoded by SF1 in packets./ > > To minimize the extra bytes added to packets in NSH, it is necessary to > have compact encoding of the metadata carried by data packets. Achieving > this goal will need control plane to inform the encoding mechanisms to > SFs via out of band control channels. > > What do people think about the proposed framework for metadata exchanged > among SFs on a SFP? > > > Linda > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Elzur, Uri > Sent: Friday, April 01, 2016 5:56 PM > To: Sunil Vallamkonda; Joel M. Halpern; Dave Dolson; Bottorff, Paul; > sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding > draft-vallamkonda-sfc-metadata-model-00.txt > > Sunil > > To advance your point, it may be of advantage, IMHO, if you provide a > concrete example of what metadata can be shared, and requires > interoperability among vendors, in a specific example e.g. FW LB NAT (or > choose your favorite). Notice some proposed directions in your draft. > > The thread reads very theoretical and suggests limited value for inter > vendor interaction. Seems like you wish to counter it. A specific > example may help bring the conversation down to ground level. > > Thx > > Uri ("Oo-Ree") > C: 949-378-7568 > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sunil Vallamkonda > Sent: Wednesday, March 30, 2016 11:04 AM > To: Joel M. Halpern >; > Dave Dolson >; > Bottorff, Paul >; > sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding > draft-vallamkonda-sfc-metadata-model-00.txt > > Joel, > > Good point, we are not trying to enumerate all the possible algorithmic > behaviors. > Yes, the proposal addresses both vendor and standardized metadata, where > latter could be a flavor of former. > In below MD-2, ignoring all metadata is a simple implementation, though > with limited capabilities. However in all elements the sender and > receiver need to co-ordinate metadata in a dynamic and scalable way to > take intelligent actions. > > Re: #1: Is there a definite limitation in framework for metadata to be > same for all packets ? It should not limit or mandate either way. > Re: #2: If there is no need for receiver to understand the semantics > across vendors and products and releases, I do not believe it would be > a scalable solution. The code semantics and actions need to be aware by > elements for metadata, without which we might well use only 'reserved' > part of header or just treat MD-2 as a 'reserved' header itself, IMHO. > > Again to clarify, the intent and focus is have the ability to understand > and extend metadata semantics for deployment. The goal is not to > enumerate every possible situation but to provide semantics to customize > and support algorithmic and other situations as individual case may be. > > > Thanks, > Sunil > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, March 30, 2016 10:56 AM > To: Dave Dolson >; > Sunil Vallamkonda >; Bottorff, > Paul >; > sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding > draft-vallamkonda-sfc-metadata-model-00.txt > > In terms of copied information, control tells the SF what to copy. It > does not matter what the granularity is. > > Given that "flow" does not have a consistent meaning (sometimes it means > 5-tuple, sometimes it means other things) trying to define control > instructions at other granularities than packet gets us into algorithmic > behaviors. And I do not think we want to try to enumerate all of the > "supported" algorithmic behaviors. > > Similarly, if the information is not the same as that from the prompting > packet, we are again finding ourselves getting into algorithmic > instructions (maybe you complement this field, or add 100 to that field, > or bounce the third field off the roof.) > > If we neeed algorithmic behavior, it seems to me that the SF has to know > what it is doing. It can not rely on control to tell it. Yes, this > places some limits on generality of inserting metadata in produced > packets. I would be interested in improvement, but I have not seen one. > > Yours, > Joel > > On 3/30/16 1:47 PM, Dave Dolson wrote: >> Joel, >> I'd like to examine this point of yours: >>> 2) Metadata to be copied from a prompting packet. This would seem to >>> be provided by control as a list of type codes, with no need to >>> understand semantics. >> >> Yes, I think control should provide information about different type codes. >> But we believe there *is* some requirement to understand certain semantics. >> E.g., >> - is the metadata about the packet, about the flow or about the source or destination end-point? >> - is the metadata important enough to add to new packets, or is it optional? >> - is the metadata direction-specific, or can the value be cloned from a request to a response? >> >> If we don't address different types of semantics, I think we need to >> agree there is only one type that works in all cases, or that certain >> types should not be used in an opaque manner, or that certain types should not be used with service functions that need to inject packets. >> >> >> Personally, I think that per-packet opaque metadata is problematic and probably to be avoided. >> E.g., a metadata that is checksum of the packet. >> If this is opaque to a function, the function may modify the packet or >> clone the metadata from one packet to another without being able to update it. >> >> -Dave >> >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 30, 2016 1:27 PM >> To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> I think you are mixing two concepts. >> There is vendor metadata and standardized metadata. >> >> I do not think anything in the framework I have seen will make vendor >> metadata interoperate without coordination between vendors. >> >> And as far as I can tell, there is nothing needed from the framework >> to make standard metadata interoperate. >> >> That leaves the corner case of experimental or developmental metadata. >> Experiments almost always need coordiantion. >> >> If we are talking about MD-2, it seems to me that SF and SFF will >> simply ignore any metadata that they do not understand. In the common >> case, SFF will ignore all metadata entirely. >> >> You have raised the question of what metadata shoudl go on packets >> originated by service functions. This seems to be a complex question, >> that is not helped by the framework. As far as I can tell, I can see >> the following cases: >> 1) Metadata about the SF originating the packet. This is common >> across all packets, and can be provided to the SF by control means in >> an opaque blob. >> 2) Metadata to be copied from a prompting packet. This would seem to >> be provided by control as a list of type codes, with no need to >> understand semantics. >> 3) Metadata derived algorithmically from information available to the >> service function. This is hard. I do not see how the framework helps >> here at all. Is it needed? >> >> Yours, >> Joel >> >> On 3/30/16 1:06 PM, Sunil Vallamkonda wrote: >>> When metadata is exchanged between SFFs, SFs, SFCs, it begs to the questions of interpretations. Without a framework for opaque metadata, the ambiguity between vendor products in service chain makes it incompatible unless the resolution is hardcoded across of releases and platforms, and vendor specific > information encoded. The flexibility and ability for metadata to be > interoperable and scale are benefits that are much needed for rapid > deployments and adoption. >>> >>> >>> Thanks, >>> Sunil >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Wednesday, March 30, 2016 9:46 AM >>> To: Bottorff, Paul >; Dave Dolson >>> >; Sunil Vallamkonda > >; >>> sfc@ietf.org >>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> I don't see why we would specify which metadata is of interest to a specific SF. It is up to the SF what it is interested in, not up to service chaining to control that. >>> As for preserving forwarding addresses, while I see value in doing so for some transports, I don't see how SFC can mandate that since it is a transport dependent behavior. >>> >>> Yours, >>> Joel >>> >>> On 3/30/16 12:31 PM, Bottorff, Paul wrote: >>>> Hi Dave and Joel: >>>> >>>> IMHO the most important thing to standardize is how an SFs couple to a chain. We are already implying that it would be desirable for SFs to pass both chain forwarding addresses and meta-data from ingress to egress (proxy forwarding always comes with a cost), however this alone does not provide enough > guidance for SF network interfacing. We also have issues like how > forwarding reversals are indicated at L4-Higher SFs and what meta-data > is opaque and what is for SF consumption. >>>> >>>> Cheers, >>>> >>>> Paul >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>>> Sent: Tuesday, March 29, 2016 7:30 PM >>>> To: Joel Halpern Direct >; Sunil >>>> Vallamkonda >; Joel M. Halpern > >; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> Joel, >>>> Consider a Service Function that needs to inject a packet, such as >>>> articulated in https://tools.ietf.org/html/draft-penno-sfc-packet-02 >>>> The question arises, what metadata should be put in the NSH header of an injected packet? >>>> >>>> Without some kind of rigorous description of a type of metadata, I don't know how to program the Service Function to do it properly. >>>> >>>> The alternative is to hard-code each service function with the supported types of metadata. >>>> This wouldn't allow a function to handle metadata it wasn't programmed for. >>>> >>>> >>>> So unless there is some easier way of understanding this, there seems to be a gap in specifying Service Function behaviour. >>>> This is one thing we're trying to figure out. >>>> >>>> >>>> -Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >>>> Direct >>>> Sent: Tuesday, March 29, 2016 7:37 PM >>>> To: Sunil Vallamkonda; Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> It may help to see some use cases. >>>> >>>> But it sounds, at best, like a specific control plane solution to some set of problems. >>>> Specific control plane solutions, as distinct from descriptions of requirements, are out of scope for the working group. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 3/29/16 7:32 PM, Sunil Vallamkonda wrote: >>>>> The focus is ability for vendor compatibility and extensibility in SF eco-system without hardcoding and human guessing. >>>>> The categorization and rest may or may not be a fallout of this. Without such a framework, it makes interpretations harder across implementations. This would be normal case rather than exception, IMHO. The goal is not to standardize any vendor data, but provide a framework to promote vendor > compatibility and extensibility across systems. As a clarification we > can walk through use cases to understand the benefits. >>>>> >>>>> >>>>> Thank you, >>>>> Sunil. >>>>> >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Tuesday, March 29, 2016 4:20 PM >>>>> To: Sunil Vallamkonda >; sfc@ietf.org >>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> I am sorry. I don't see the value in this. >>>>> >>>>> Trying to categorize metadata does not seem to help anything. >>>>> Trying to standardize a descriptive langauge for metadata seems to imply something that can consume such a language. I can not imagine anything that can usefully consume this. >>>>> >>>>> I can understand how a human being would use a registry (which we have to have) to know what T codes are defined, and where to find descriptions of their meaning. >>>>> But that meaning description is going to be in English. A file that tells me that value 17 is the Dragaeran Corporate type code for Houses does not tell me anything. >>>>> >>>>> The only corner case for the YANG is if my system has some understanding of the semantics of various pieces of metadata, but wants to know what code is associated with a particular usage. >>>>> The problem is that we have mutliple different protocols that may want to provide that information, so all that SFC can define is that the control system must include a way to provide that information. >>>>> >>>>> Given that much of the metadata is not vendor specific, the structure seems very odd. >>>>> ANd it seems likely that any vendor specific metadata will need the semantics to already be known, since we can not standardize that. >>>>> >>>>> Yours in puzzlement, >>>>> Joel >>>>> >>>>> On 3/29/16 6:33 PM, Sunil Vallamkonda wrote: >>>>>> Metadata is a vital element of SFC and thus NFV. >>>>>> >>>>>> Additionally, interoperability and vendor support challenges need >>>>>> to be addressed in a scalable and adaptable way for rapid deployment. >>>>>> >>>>>> In January we uploaded draft-vallamkonda-sfc-metadata-model-00, >>>>>> which proposes terminology for talking about metadata in an extensible fashion. >>>>>> >>>>>> If there are no objections, we'd like to start pushing this >>>>>> terminology into drafts about NSH and the control-plane. >>>>>> >>>>>> Please let us know what you think. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Sunil. >>>>>> >>>>>> == >>>>>> >>>>>> A new version of I-D, draft-vallamkonda-sfc-metadata-model-00.txt >>>>>> >>>>>> has been successfully submitted by Sunil Vallamkonda and posted to >>>>>> the IETF repository. >>>>>> >>>>>> Name: draft-vallamkonda-sfc-metadata-model >>>>>> >>>>>> Revision: 00 >>>>>> >>>>>> Title: Information Model for SFC Metadata >>>>>> >>>>>> Document date: 2016-01-28 >>>>>> >>>>>> Group: Individual Submission >>>>>> >>>>>> Pages: 9 >>>>>> >>>>>> URL: >>>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadat >>>>>> a- >>>>>> m >>>>>> o >>>>>> del-00.txt >>>>>> >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-mo >>>>>> de >>>>>> l >>>>>> / >>>>>> >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-0 >>>>>> 0 >>>>>> >>>>>> Abstract: >>>>>> >>>>>> Various types of metadata are applicable to Service >>>>>> Function Chaining >>>>>> >>>>>> (SFC). A Service Function (SF) needs information about >>>>>> all metadata >>>>>> >>>>>> passing through it. The metadata could be used to convey >>>>>> >>>>>> preprocessing information about the packet by other nodes >>>>>> and an SF >>>>>> >>>>>> can attach post processing information as deemed necessary. >>>>>> >>>>>> The purpose of this document is to rigorously define the >>>>>> classes of >>>>>> >>>>>> metadata and provide a vocabulary and information model for metadata. >>>>>> >>>>>> Each item of metadata refers to a subject, examples of >>>>>> which are IP >>>>>> >>>>>> endpoint, flow or individual packet. >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission until the htmlized version and diff are available at >>>>>> tools.ietf.org. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> 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 Jul 11 10:24: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 83CCE12D0C4 for ; Mon, 11 Jul 2016 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 ggeXDJKQV2Xz for ; Mon, 11 Jul 2016 10:24:40 -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 B2E3912D0B4 for ; Mon, 11 Jul 2016 10:24:39 -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.195.1; Mon, 11 Jul 2016 13:24:38 -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.0294.000; Mon, 11 Jul 2016 13:24:38 -0400 From: Dave Dolson To: "Joel M. Halpern" , Linda Dunbar , "Elzur, Uri" , "Sunil Vallamkonda" , "Bottorff, Paul" , "sfc@ietf.org" Thread-Topic: Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-01.txt Thread-Index: AQHR25cE1MVLufCHw0uzCCc+6GJ9o6ATeEFg Date: Mon, 11 Jul 2016 17:24:37 +0000 Message-ID: References: <56FB0D84.9050602@joelhalpern.com> <56FB1186.7070807@joelhalpern.com> <56FC02BC.8060203@joelhalpern.com> <880ca7e35d334ab48898aa4c78984ac1@SEAEXCHMBX06.olympus.F5Net.com> <56FC0C62.1050200@joelhalpern.com> <56FC1318.6070703@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B8995858932536C@ORSMSX114.amr.corp.intel.com> <4A95BA014132FF49AE685FAB4B9F17F657EF832D@dfweml501-mbb> 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: Subject: Re: [sfc] Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-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: Mon, 11 Jul 2016 17:24:43 -0000 Clearly metadata passed between two SFs needs to be understood by both.=20 I think Joel is correct that standardization covers this case -- at least for AVPs in MD-Type 2. But I don't believe standardization covers the MD-Type-1 format, since there doesn't seem to be an allocation that fits all. Control-plane indication of "what are in slots 1..4?" seems necessary. And another issue is that such metadata may need to pass through an=20 intermediary SF that does NOT know the standardization, and may NOT know the semantics of the metadata. We are also attempting to provide sufficient description of the metadata that an intermediary can avoid breaking things. When an intermediary injects packets into a chain it is particularly important for it to be aware of the semantics -- perhaps including the case when packets cannot be injected. -Dave -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, July 11, 2016 1:10 PM To: Linda Dunbar; Elzur, Uri; Sunil Vallamkonda; Dave Dolson; Bottorff, Pau= l; sfc@ietf.org Subject: Re: Examples of Metadata that need to be passed among SFs : regard= ing draft-vallamkonda-sfc-metadata-model-01.txt I find it very hard to understand the advantage of the proposed=20 framework. I am usually of the opinion that indirection is helpful in=20 solving protocol identification problems. In this case however, I can=20 not see any value in having control specify to an SF "You will find=20 field X under TLV code A" using a quasi-standard X. For things with=20 standard type code, there is clearly no need for such. For things with=20 vendor defined type codes, the label X is no more useful than the vendor=20 defined type code. After all, if the meaning of X were standard, then=20 there would presuambly be a standard type code assigned to it. We have=20 lots of space. Yours, Joel On 7/11/16 12:49 PM, Linda Dunbar wrote: > _https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model/_h= as > the examples of metadata that may need to be passed among SFs along a > SFP, e.g. > > /SF1 may at real-time attach DoS information for the next SF in > downstream. SF1 provides the hint and it is up to the downstream SFs to > process it or ignore it. However if a downstream SF chooses to > processes, it needs standardized metadata data model to understand the > hint encoded by SF1 in packets./ > > To minimize the extra bytes added to packets in NSH, it is necessary to > have compact encoding of the metadata carried by data packets. Achieving > this goal will need control plane to inform the encoding mechanisms to > SFs via out of band control channels. > > What do people think about the proposed framework for metadata exchanged > among SFs on a SFP? > > > Linda > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Elzur, Uri > Sent: Friday, April 01, 2016 5:56 PM > To: Sunil Vallamkonda; Joel M. Halpern; Dave Dolson; Bottorff, Paul; > sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding > draft-vallamkonda-sfc-metadata-model-00.txt > > Sunil > > To advance your point, it may be of advantage, IMHO, if you provide a > concrete example of what metadata can be shared, and requires > interoperability among vendors, in a specific example e.g. FW LB NAT (or > choose your favorite). Notice some proposed directions in your draft. > > The thread reads very theoretical and suggests limited value for inter > vendor interaction. Seems like you wish to counter it. A specific > example may help bring the conversation down to ground level. > > Thx > > Uri ("Oo-Ree") > C: 949-378-7568 > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sunil Vallamkonda > Sent: Wednesday, March 30, 2016 11:04 AM > To: Joel M. Halpern >; > Dave Dolson >; > Bottorff, Paul >; > sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding > draft-vallamkonda-sfc-metadata-model-00.txt > > Joel, > > Good point, we are not trying to enumerate all the possible algorithmic > behaviors. > Yes, the proposal addresses both vendor and standardized metadata, where > latter could be a flavor of former. > In below MD-2, ignoring all metadata is a simple implementation, though > with limited capabilities. However in all elements the sender and > receiver need to co-ordinate metadata in a dynamic and scalable way to > take intelligent actions. > > Re: #1: Is there a definite limitation in framework for metadata to be > same for all packets ? It should not limit or mandate either way. > Re: #2: If there is no need for receiver to understand the semantics > across vendors and products and releases, I do not believe it would be > a scalable solution. The code semantics and actions need to be aware by > elements for metadata, without which we might well use only 'reserved' > part of header or just treat MD-2 as a 'reserved' header itself, IMHO. > > Again to clarify, the intent and focus is have the ability to understand > and extend metadata semantics for deployment. The goal is not to > enumerate every possible situation but to provide semantics to customize > and support algorithmic and other situations as individual case may be. > > > Thanks, > Sunil > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, March 30, 2016 10:56 AM > To: Dave Dolson >; > Sunil Vallamkonda >; Bottorff, > Paul >; > sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding > draft-vallamkonda-sfc-metadata-model-00.txt > > In terms of copied information, control tells the SF what to copy. It > does not matter what the granularity is. > > Given that "flow" does not have a consistent meaning (sometimes it means > 5-tuple, sometimes it means other things) trying to define control > instructions at other granularities than packet gets us into algorithmic > behaviors. And I do not think we want to try to enumerate all of the > "supported" algorithmic behaviors. > > Similarly, if the information is not the same as that from the prompting > packet, we are again finding ourselves getting into algorithmic > instructions (maybe you complement this field, or add 100 to that field, > or bounce the third field off the roof.) > > If we neeed algorithmic behavior, it seems to me that the SF has to know > what it is doing. It can not rely on control to tell it. Yes, this > places some limits on generality of inserting metadata in produced > packets. I would be interested in improvement, but I have not seen one. > > Yours, > Joel > > On 3/30/16 1:47 PM, Dave Dolson wrote: >> Joel, >> I'd like to examine this point of yours: >>> 2) Metadata to be copied from a prompting packet. This would seem to >>> be provided by control as a list of type codes, with no need to >>> understand semantics. >> >> Yes, I think control should provide information about different type cod= es. >> But we believe there *is* some requirement to understand certain semanti= cs. >> E.g., >> - is the metadata about the packet, about the flow or about the source o= r destination end-point? >> - is the metadata important enough to add to new packets, or is it optio= nal? >> - is the metadata direction-specific, or can the value be cloned from a = request to a response? >> >> If we don't address different types of semantics, I think we need to >> agree there is only one type that works in all cases, or that certain >> types should not be used in an opaque manner, or that certain types shou= ld not be used with service functions that need to inject packets. >> >> >> Personally, I think that per-packet opaque metadata is problematic and p= robably to be avoided. >> E.g., a metadata that is checksum of the packet. >> If this is opaque to a function, the function may modify the packet or >> clone the metadata from one packet to another without being able to upda= te it. >> >> -Dave >> >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 30, 2016 1:27 PM >> To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> I think you are mixing two concepts. >> There is vendor metadata and standardized metadata. >> >> I do not think anything in the framework I have seen will make vendor >> metadata interoperate without coordination between vendors. >> >> And as far as I can tell, there is nothing needed from the framework >> to make standard metadata interoperate. >> >> That leaves the corner case of experimental or developmental metadata. >> Experiments almost always need coordiantion. >> >> If we are talking about MD-2, it seems to me that SF and SFF will >> simply ignore any metadata that they do not understand. In the common >> case, SFF will ignore all metadata entirely. >> >> You have raised the question of what metadata shoudl go on packets >> originated by service functions. This seems to be a complex question, >> that is not helped by the framework. As far as I can tell, I can see >> the following cases: >> 1) Metadata about the SF originating the packet. This is common >> across all packets, and can be provided to the SF by control means in >> an opaque blob. >> 2) Metadata to be copied from a prompting packet. This would seem to >> be provided by control as a list of type codes, with no need to >> understand semantics. >> 3) Metadata derived algorithmically from information available to the >> service function. This is hard. I do not see how the framework helps >> here at all. Is it needed? >> >> Yours, >> Joel >> >> On 3/30/16 1:06 PM, Sunil Vallamkonda wrote: >>> When metadata is exchanged between SFFs, SFs, SFCs, it begs to the ques= tions of interpretations. Without a framework for opaque metadata, the ambi= guity between vendor products in service chain makes it incompatible unless= the resolution is hardcoded across of releases and platforms, and vendor s= pecific > information encoded. The flexibility and ability for metadata to be > interoperable and scale are benefits that are much needed for rapid > deployments and adoption. >>> >>> >>> Thanks, >>> Sunil >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Wednesday, March 30, 2016 9:46 AM >>> To: Bottorff, Paul >; Dave Dolson >>> >; Sunil Vallamkonda > >; >>> sfc@ietf.org >>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> I don't see why we would specify which metadata is of interest to a spe= cific SF. It is up to the SF what it is interested in, not up to service c= haining to control that. >>> As for preserving forwarding addresses, while I see value in doing so f= or some transports, I don't see how SFC can mandate that since it is a tran= sport dependent behavior. >>> >>> Yours, >>> Joel >>> >>> On 3/30/16 12:31 PM, Bottorff, Paul wrote: >>>> Hi Dave and Joel: >>>> >>>> IMHO the most important thing to standardize is how an SFs couple to a= chain. We are already implying that it would be desirable for SFs to pass = both chain forwarding addresses and meta-data from ingress to egress (proxy= forwarding always comes with a cost), however this alone does not provide = enough > guidance for SF network interfacing. We also have issues like how > forwarding reversals are indicated at L4-Higher SFs and what meta-data > is opaque and what is for SF consumption. >>>> >>>> Cheers, >>>> >>>> Paul >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>>> Sent: Tuesday, March 29, 2016 7:30 PM >>>> To: Joel Halpern Direct >; Sunil >>>> Vallamkonda >; Joel M. Halpern > >; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> Joel, >>>> Consider a Service Function that needs to inject a packet, such as >>>> articulated in https://tools.ietf.org/html/draft-penno-sfc-packet-02 >>>> The question arises, what metadata should be put in the NSH header of = an injected packet? >>>> >>>> Without some kind of rigorous description of a type of metadata, I don= 't know how to program the Service Function to do it properly. >>>> >>>> The alternative is to hard-code each service function with the support= ed types of metadata. >>>> This wouldn't allow a function to handle metadata it wasn't programmed= for. >>>> >>>> >>>> So unless there is some easier way of understanding this, there seems = to be a gap in specifying Service Function behaviour. >>>> This is one thing we're trying to figure out. >>>> >>>> >>>> -Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >>>> Direct >>>> Sent: Tuesday, March 29, 2016 7:37 PM >>>> To: Sunil Vallamkonda; Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> It may help to see some use cases. >>>> >>>> But it sounds, at best, like a specific control plane solution to some= set of problems. >>>> Specific control plane solutions, as distinct from descriptions of req= uirements, are out of scope for the working group. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 3/29/16 7:32 PM, Sunil Vallamkonda wrote: >>>>> The focus is ability for vendor compatibility and extensibility in SF= eco-system without hardcoding and human guessing. >>>>> The categorization and rest may or may not be a fallout of this. Wit= hout such a framework, it makes interpretations harder across implementatio= ns. This would be normal case rather than exception, IMHO. The goal is not = to standardize any vendor data, but provide a framework to promote vendor > compatibility and extensibility across systems. As a clarification we > can walk through use cases to understand the benefits. >>>>> >>>>> >>>>> Thank you, >>>>> Sunil. >>>>> >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Tuesday, March 29, 2016 4:20 PM >>>>> To: Sunil Vallamkonda >; sfc@i= etf.org >>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> I am sorry. I don't see the value in this. >>>>> >>>>> Trying to categorize metadata does not seem to help anything. >>>>> Trying to standardize a descriptive langauge for metadata seems to im= ply something that can consume such a language. I can not imagine anything= that can usefully consume this. >>>>> >>>>> I can understand how a human being would use a registry (which we hav= e to have) to know what T codes are defined, and where to find descriptions= of their meaning. >>>>> But that meaning description is going to be in English. A file that = tells me that value 17 is the Dragaeran Corporate type code for Houses does= not tell me anything. >>>>> >>>>> The only corner case for the YANG is if my system has some understand= ing of the semantics of various pieces of metadata, but wants to know what = code is associated with a particular usage. >>>>> The problem is that we have mutliple different protocols that may wan= t to provide that information, so all that SFC can define is that the contr= ol system must include a way to provide that information. >>>>> >>>>> Given that much of the metadata is not vendor specific, the structure= seems very odd. >>>>> ANd it seems likely that any vendor specific metadata will need the s= emantics to already be known, since we can not standardize that. >>>>> >>>>> Yours in puzzlement, >>>>> Joel >>>>> >>>>> On 3/29/16 6:33 PM, Sunil Vallamkonda wrote: >>>>>> Metadata is a vital element of SFC and thus NFV. >>>>>> >>>>>> Additionally, interoperability and vendor support challenges need >>>>>> to be addressed in a scalable and adaptable way for rapid deployment= . >>>>>> >>>>>> In January we uploaded draft-vallamkonda-sfc-metadata-model-00, >>>>>> which proposes terminology for talking about metadata in an extensib= le fashion. >>>>>> >>>>>> If there are no objections, we'd like to start pushing this >>>>>> terminology into drafts about NSH and the control-plane. >>>>>> >>>>>> Please let us know what you think. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Sunil. >>>>>> >>>>>> =3D=3D >>>>>> >>>>>> A new version of I-D, draft-vallamkonda-sfc-metadata-model-00.txt >>>>>> >>>>>> has been successfully submitted by Sunil Vallamkonda and posted to >>>>>> the IETF repository. >>>>>> >>>>>> Name: draft-vallamkonda-sfc-metadata-model >>>>>> >>>>>> Revision: 00 >>>>>> >>>>>> Title: Information Model for SFC Metadata >>>>>> >>>>>> Document date: 2016-01-28 >>>>>> >>>>>> Group: Individual Submission >>>>>> >>>>>> Pages: 9 >>>>>> >>>>>> URL: >>>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadat >>>>>> a- >>>>>> m >>>>>> o >>>>>> del-00.txt >>>>>> >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-mo >>>>>> de >>>>>> l >>>>>> / >>>>>> >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-0 >>>>>> 0 >>>>>> >>>>>> Abstract: >>>>>> >>>>>> Various types of metadata are applicable to Service >>>>>> Function Chaining >>>>>> >>>>>> (SFC). A Service Function (SF) needs information about >>>>>> all metadata >>>>>> >>>>>> passing through it. The metadata could be used to convey >>>>>> >>>>>> preprocessing information about the packet by other nodes >>>>>> and an SF >>>>>> >>>>>> can attach post processing information as deemed necessary. >>>>>> >>>>>> The purpose of this document is to rigorously define the >>>>>> classes of >>>>>> >>>>>> metadata and provide a vocabulary and information model for = metadata. >>>>>> >>>>>> Each item of metadata refers to a subject, examples of >>>>>> which are IP >>>>>> >>>>>> endpoint, flow or individual packet. >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission until the htmlized version and diff are available at >>>>>> tools.ietf.org. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> 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 Jul 11 10:27: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 9A11B12D5DB for ; Mon, 11 Jul 2016 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 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.287, 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 vS7DXlg5y6uE for ; Mon, 11 Jul 2016 10:27:33 -0700 (PDT) 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 EFDCA12D0B4 for ; Mon, 11 Jul 2016 10:27:31 -0700 (PDT) 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 CSK01036; Mon, 11 Jul 2016 17:27:25 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 11 Jul 2016 18:26:53 +0100 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; Mon, 11 Jul 2016 10:26:48 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "Elzur, Uri" , Sunil Vallamkonda , Dave Dolson , "Bottorff, Paul" , "sfc@ietf.org" Thread-Topic: Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-01.txt Thread-Index: AQHR25cNTgTIYcL6/kKDXqW+tTstoqATeydw Date: Mon, 11 Jul 2016 17:26:48 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657EF8595@dfweml501-mbb> References: <56FB0D84.9050602@joelhalpern.com> <56FB1186.7070807@joelhalpern.com> <56FC02BC.8060203@joelhalpern.com> <880ca7e35d334ab48898aa4c78984ac1@SEAEXCHMBX06.olympus.F5Net.com> <56FC0C62.1050200@joelhalpern.com> <56FC1318.6070703@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B8995858932536C@ORSMSX114.amr.corp.intel.com> <4A95BA014132FF49AE685FAB4B9F17F657EF832D@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.119] 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.5783D6FF.0041, 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: 60d22760c904e9466c6cff2764d5788d Archived-At: Subject: Re: [sfc] Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-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: Mon, 11 Jul 2016 17:27:36 -0000 Joel,=20 Are you suggesting that it is better to have standard type code for each me= tadata?=20 Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, July 11, 2016 12:10 PM To: Linda Dunbar; Elzur, Uri; Sunil Vallamkonda; Dave Dolson; Bottorff, Pau= l; sfc@ietf.org Subject: Re: Examples of Metadata that need to be passed among SFs : regard= ing draft-vallamkonda-sfc-metadata-model-01.txt I find it very hard to understand the advantage of the proposed framework. = I am usually of the opinion that indirection is helpful in solving protoco= l identification problems. In this case however, I can not see any value i= n having control specify to an SF "You will find field X under TLV code A" = using a quasi-standard X. For things with standard type code, there is cle= arly no need for such. For things with vendor defined type codes, the labe= l X is no more useful than the vendor defined type code. After all, if the= meaning of X were standard, then there would presuambly be a standard type= code assigned to it. We have lots of space. Yours, Joel On 7/11/16 12:49 PM, Linda Dunbar wrote: > _https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model > /_has the examples of metadata that may need to be passed among SFs=20 > along a SFP, e.g. > > /SF1 may at real-time attach DoS information for the next SF in=20 > downstream. SF1 provides the hint and it is up to the downstream SFs=20 > to process it or ignore it. However if a downstream SF chooses to=20 > processes, it needs standardized metadata data model to understand the=20 > hint encoded by SF1 in packets./ > > To minimize the extra bytes added to packets in NSH, it is necessary=20 > to have compact encoding of the metadata carried by data packets.=20 > Achieving this goal will need control plane to inform the encoding=20 > mechanisms to SFs via out of band control channels. > > What do people think about the proposed framework for metadata=20 > exchanged among SFs on a SFP? > > > Linda > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Elzur, Uri > Sent: Friday, April 01, 2016 5:56 PM > To: Sunil Vallamkonda; Joel M. Halpern; Dave Dolson; Bottorff, Paul;=20 > sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding=20 > draft-vallamkonda-sfc-metadata-model-00.txt > > Sunil > > To advance your point, it may be of advantage, IMHO, if you provide a=20 > concrete example of what metadata can be shared, and requires=20 > interoperability among vendors, in a specific example e.g. FW LB NAT=20 > (or choose your favorite). Notice some proposed directions in your draft. > > The thread reads very theoretical and suggests limited value for inter=20 > vendor interaction. Seems like you wish to counter it. A specific=20 > example may help bring the conversation down to ground level. > > Thx > > Uri ("Oo-Ree") > C: 949-378-7568 > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sunil Vallamkonda > Sent: Wednesday, March 30, 2016 11:04 AM > To: Joel M. Halpern >; Dave Dolson >; Bottorff, Paul >; sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding=20 > draft-vallamkonda-sfc-metadata-model-00.txt > > Joel, > > Good point, we are not trying to enumerate all the possible=20 > algorithmic behaviors. > Yes, the proposal addresses both vendor and standardized metadata,=20 > where latter could be a flavor of former. > In below MD-2, ignoring all metadata is a simple implementation,=20 > though with limited capabilities. However in all elements the sender=20 > and receiver need to co-ordinate metadata in a dynamic and scalable=20 > way to take intelligent actions. > > Re: #1: Is there a definite limitation in framework for metadata to be=20 > same for all packets ? It should not limit or mandate either way. > Re: #2: If there is no need for receiver to understand the semantics=20 > across vendors and products and releases, I do not believe it would=20 > be a scalable solution. The code semantics and actions need to be=20 > aware by elements for metadata, without which we might well use only 'res= erved' > part of header or just treat MD-2 as a 'reserved' header itself, IMHO. > > Again to clarify, the intent and focus is have the ability to=20 > understand and extend metadata semantics for deployment. The goal is=20 > not to enumerate every possible situation but to provide semantics to=20 > customize and support algorithmic and other situations as individual case= may be. > > > Thanks, > Sunil > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, March 30, 2016 10:56 AM > To: Dave Dolson >;=20 > Sunil Vallamkonda >; Bottorff,=20 > Paul >;=20 > sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding=20 > draft-vallamkonda-sfc-metadata-model-00.txt > > In terms of copied information, control tells the SF what to copy. It=20 > does not matter what the granularity is. > > Given that "flow" does not have a consistent meaning (sometimes it=20 > means 5-tuple, sometimes it means other things) trying to define=20 > control instructions at other granularities than packet gets us into=20 > algorithmic behaviors. And I do not think we want to try to enumerate=20 > all of the "supported" algorithmic behaviors. > > Similarly, if the information is not the same as that from the=20 > prompting packet, we are again finding ourselves getting into=20 > algorithmic instructions (maybe you complement this field, or add 100=20 > to that field, or bounce the third field off the roof.) > > If we neeed algorithmic behavior, it seems to me that the SF has to=20 > know what it is doing. It can not rely on control to tell it. Yes,=20 > this places some limits on generality of inserting metadata in=20 > produced packets. I would be interested in improvement, but I have not s= een one. > > Yours, > Joel > > On 3/30/16 1:47 PM, Dave Dolson wrote: >> Joel, >> I'd like to examine this point of yours: >>> 2) Metadata to be copied from a prompting packet. This would seem=20 >>> to be provided by control as a list of type codes, with no need to=20 >>> understand semantics. >> >> Yes, I think control should provide information about different type cod= es. >> But we believe there *is* some requirement to understand certain semanti= cs. >> E.g., >> - is the metadata about the packet, about the flow or about the source o= r destination end-point? >> - is the metadata important enough to add to new packets, or is it optio= nal? >> - is the metadata direction-specific, or can the value be cloned from a = request to a response? >> >> If we don't address different types of semantics, I think we need to=20 >> agree there is only one type that works in all cases, or that certain=20 >> types should not be used in an opaque manner, or that certain types shou= ld not be used with service functions that need to inject packets. >> >> >> Personally, I think that per-packet opaque metadata is problematic and p= robably to be avoided. >> E.g., a metadata that is checksum of the packet. >> If this is opaque to a function, the function may modify the packet=20 >> or clone the metadata from one packet to another without being able to u= pdate it. >> >> -Dave >> >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 30, 2016 1:27 PM >> To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; sfc@ietf.org=20 >> >> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> I think you are mixing two concepts. >> There is vendor metadata and standardized metadata. >> >> I do not think anything in the framework I have seen will make vendor=20 >> metadata interoperate without coordination between vendors. >> >> And as far as I can tell, there is nothing needed from the framework=20 >> to make standard metadata interoperate. >> >> That leaves the corner case of experimental or developmental metadata. >> Experiments almost always need coordiantion. >> >> If we are talking about MD-2, it seems to me that SF and SFF will=20 >> simply ignore any metadata that they do not understand. In the=20 >> common case, SFF will ignore all metadata entirely. >> >> You have raised the question of what metadata shoudl go on packets=20 >> originated by service functions. This seems to be a complex=20 >> question, that is not helped by the framework. As far as I can tell,=20 >> I can see the following cases: >> 1) Metadata about the SF originating the packet. This is common=20 >> across all packets, and can be provided to the SF by control means in=20 >> an opaque blob. >> 2) Metadata to be copied from a prompting packet. This would seem to=20 >> be provided by control as a list of type codes, with no need to=20 >> understand semantics. >> 3) Metadata derived algorithmically from information available to the=20 >> service function. This is hard. I do not see how the framework=20 >> helps here at all. Is it needed? >> >> Yours, >> Joel >> >> On 3/30/16 1:06 PM, Sunil Vallamkonda wrote: >>> When metadata is exchanged between SFFs, SFs, SFCs, it begs to the=20 >>> questions of interpretations. Without a framework for opaque=20 >>> metadata, the ambiguity between vendor products in service chain=20 >>> makes it incompatible unless the resolution is hardcoded across of=20 >>> releases and platforms, and vendor specific > information encoded. The flexibility and ability for metadata to be=20 > interoperable and scale are benefits that are much needed for rapid=20 > deployments and adoption. >>> >>> >>> Thanks, >>> Sunil >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Wednesday, March 30, 2016 9:46 AM >>> To: Bottorff, Paul >> >; Dave Dolson >> >; Sunil Vallamkonda > >; >>> sfc@ietf.org >>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> I don't see why we would specify which metadata is of interest to a spe= cific SF. It is up to the SF what it is interested in, not up to service c= haining to control that. >>> As for preserving forwarding addresses, while I see value in doing so f= or some transports, I don't see how SFC can mandate that since it is a tran= sport dependent behavior. >>> >>> Yours, >>> Joel >>> >>> On 3/30/16 12:31 PM, Bottorff, Paul wrote: >>>> Hi Dave and Joel: >>>> >>>> IMHO the most important thing to standardize is how an SFs couple=20 >>>> to a chain. We are already implying that it would be desirable for=20 >>>> SFs to pass both chain forwarding addresses and meta-data from=20 >>>> ingress to egress (proxy forwarding always comes with a cost),=20 >>>> however this alone does not provide enough > guidance for SF network interfacing. We also have issues like how=20 > forwarding reversals are indicated at L4-Higher SFs and what meta-data=20 > is opaque and what is for SF consumption. >>>> >>>> Cheers, >>>> >>>> Paul >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>>> Sent: Tuesday, March 29, 2016 7:30 PM >>>> To: Joel Halpern Direct >>> >; Sunil Vallamkonda=20 >>>> >; Joel M. Halpern > >; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> Joel, >>>> Consider a Service Function that needs to inject a packet, such as=20 >>>> articulated in=20 >>>> https://tools.ietf.org/html/draft-penno-sfc-packet-02 >>>> The question arises, what metadata should be put in the NSH header of = an injected packet? >>>> >>>> Without some kind of rigorous description of a type of metadata, I don= 't know how to program the Service Function to do it properly. >>>> >>>> The alternative is to hard-code each service function with the support= ed types of metadata. >>>> This wouldn't allow a function to handle metadata it wasn't programmed= for. >>>> >>>> >>>> So unless there is some easier way of understanding this, there seems = to be a gap in specifying Service Function behaviour. >>>> This is one thing we're trying to figure out. >>>> >>>> >>>> -Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern=20 >>>> Direct >>>> Sent: Tuesday, March 29, 2016 7:37 PM >>>> To: Sunil Vallamkonda; Joel M. Halpern; sfc@ietf.org=20 >>>> >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> It may help to see some use cases. >>>> >>>> But it sounds, at best, like a specific control plane solution to some= set of problems. >>>> Specific control plane solutions, as distinct from descriptions of req= uirements, are out of scope for the working group. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 3/29/16 7:32 PM, Sunil Vallamkonda wrote: >>>>> The focus is ability for vendor compatibility and extensibility in SF= eco-system without hardcoding and human guessing. >>>>> The categorization and rest may or may not be a fallout of this. =20 >>>>> Without such a framework, it makes interpretations harder across=20 >>>>> implementations. This would be normal case rather than exception,=20 >>>>> IMHO. The goal is not to standardize any vendor data, but provide=20 >>>>> a framework to promote vendor > compatibility and extensibility across systems. As a clarification we=20 > can walk through use cases to understand the benefits. >>>>> >>>>> >>>>> Thank you, >>>>> Sunil. >>>>> >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Tuesday, March 29, 2016 4:20 PM >>>>> To: Sunil Vallamkonda >;=20 >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> I am sorry. I don't see the value in this. >>>>> >>>>> Trying to categorize metadata does not seem to help anything. >>>>> Trying to standardize a descriptive langauge for metadata seems to im= ply something that can consume such a language. I can not imagine anything= that can usefully consume this. >>>>> >>>>> I can understand how a human being would use a registry (which we hav= e to have) to know what T codes are defined, and where to find descriptions= of their meaning. >>>>> But that meaning description is going to be in English. A file that = tells me that value 17 is the Dragaeran Corporate type code for Houses does= not tell me anything. >>>>> >>>>> The only corner case for the YANG is if my system has some understand= ing of the semantics of various pieces of metadata, but wants to know what = code is associated with a particular usage. >>>>> The problem is that we have mutliple different protocols that may wan= t to provide that information, so all that SFC can define is that the contr= ol system must include a way to provide that information. >>>>> >>>>> Given that much of the metadata is not vendor specific, the structure= seems very odd. >>>>> ANd it seems likely that any vendor specific metadata will need the s= emantics to already be known, since we can not standardize that. >>>>> >>>>> Yours in puzzlement, >>>>> Joel >>>>> >>>>> On 3/29/16 6:33 PM, Sunil Vallamkonda wrote: >>>>>> Metadata is a vital element of SFC and thus NFV. >>>>>> >>>>>> Additionally, interoperability and vendor support challenges=20 >>>>>> need to be addressed in a scalable and adaptable way for rapid deplo= yment. >>>>>> >>>>>> In January we uploaded draft-vallamkonda-sfc-metadata-model-00, >>>>>> which proposes terminology for talking about metadata in an extensib= le fashion. >>>>>> >>>>>> If there are no objections, we'd like to start pushing this=20 >>>>>> terminology into drafts about NSH and the control-plane. >>>>>> >>>>>> Please let us know what you think. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Sunil. >>>>>> >>>>>> =3D=3D >>>>>> >>>>>> A new version of I-D, draft-vallamkonda-sfc-metadata-model-00.txt >>>>>> >>>>>> has been successfully submitted by Sunil Vallamkonda and posted=20 >>>>>> to the IETF repository. >>>>>> >>>>>> Name: draft-vallamkonda-sfc-metadata-model >>>>>> >>>>>> Revision: 00 >>>>>> >>>>>> Title: Information Model for SFC Metadata >>>>>> >>>>>> Document date: 2016-01-28 >>>>>> >>>>>> Group: Individual Submission >>>>>> >>>>>> Pages: 9 >>>>>> >>>>>> URL: >>>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metada >>>>>> t >>>>>> a- >>>>>> m >>>>>> o >>>>>> del-00.txt >>>>>> >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-m >>>>>> o >>>>>> de >>>>>> l >>>>>> / >>>>>> >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model- >>>>>> 0 >>>>>> 0 >>>>>> >>>>>> Abstract: >>>>>> >>>>>> Various types of metadata are applicable to Service=20 >>>>>> Function Chaining >>>>>> >>>>>> (SFC). A Service Function (SF) needs information about=20 >>>>>> all metadata >>>>>> >>>>>> passing through it. The metadata could be used to convey >>>>>> >>>>>> preprocessing information about the packet by other nodes=20 >>>>>> and an SF >>>>>> >>>>>> can attach post processing information as deemed necessary. >>>>>> >>>>>> The purpose of this document is to rigorously define the=20 >>>>>> classes of >>>>>> >>>>>> metadata and provide a vocabulary and information model for = metadata. >>>>>> >>>>>> Each item of metadata refers to a subject, examples of=20 >>>>>> which are IP >>>>>> >>>>>> endpoint, flow or individual packet. >>>>>> >>>>>> 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. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jul 11 11:11: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 3D85812D5E7 for ; Mon, 11 Jul 2016 11:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gCprwS5gmkg for ; Mon, 11 Jul 2016 11:11:17 -0700 (PDT) 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 12C5D12D5C9 for ; Mon, 11 Jul 2016 11:11:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 03B213C2EE1; Mon, 11 Jul 2016 11:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1468260677; bh=R1e6x/gynjBDlvPzlX0hGuFE9oRkxpwshg+EhT7PUUs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Nw9Ucfi5vvoGAc+DF6tYo9/Ae+kqnK1eFPfWF7PoMuiiX1qHfPemgD2qXyzkX2DoY p86h5dGkYDcryTYRPqQAcnb+qRmivVZtRJyWpsjKXPus2OHz7iJ0VQO4vYm5si7EqS RwoZmjnVdilq8jppdR3FaOMiodgza1ttlmKk2Ya0= 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 E6BEA1C0B99; Mon, 11 Jul 2016 11:11:15 -0700 (PDT) To: Linda Dunbar , "Elzur, Uri" , Sunil Vallamkonda , Dave Dolson , "Bottorff, Paul" , "sfc@ietf.org" References: <56FB0D84.9050602@joelhalpern.com> <56FB1186.7070807@joelhalpern.com> <56FC02BC.8060203@joelhalpern.com> <880ca7e35d334ab48898aa4c78984ac1@SEAEXCHMBX06.olympus.F5Net.com> <56FC0C62.1050200@joelhalpern.com> <56FC1318.6070703@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B8995858932536C@ORSMSX114.amr.corp.intel.com> <4A95BA014132FF49AE685FAB4B9F17F657EF832D@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EF8595@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: <1287481e-0f87-9868-0f91-48de25ea1252@joelhalpern.com> Date: Mon, 11 Jul 2016 14:11:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657EF8595@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-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: Mon, 11 Jul 2016 18:11:19 -0000 Whenever we have agreement on meaning and there being some utility, I would expect to see a standard code point assigned for that metadata usage. This does mean that someone has to do the work to write down the meaning. I do not expect all code points to be standardized. But standardization is intended precisely to ddress inter-vendor interoperability. Having said that, I do expect there to be cases where vendors need to agree on code point usage without having (yet or ever) standardized. For that case, they need to communicated. I do not see hwo this framework helps that communication. Yours, Joel On 7/11/16 1:26 PM, Linda Dunbar wrote: > Joel, > > Are you suggesting that it is better to have standard type code for each metadata? > > Linda > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, July 11, 2016 12:10 PM > To: Linda Dunbar; Elzur, Uri; Sunil Vallamkonda; Dave Dolson; Bottorff, Paul; sfc@ietf.org > Subject: Re: Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-01.txt > > I find it very hard to understand the advantage of the proposed framework. I am usually of the opinion that indirection is helpful in solving protocol identification problems. In this case however, I can not see any value in having control specify to an SF "You will find field X under TLV code A" using a quasi-standard X. For things with standard type code, there is clearly no need for such. For things with vendor defined type codes, the label X is no more useful than the vendor defined type code. After all, if the meaning of X were standard, then there would presuambly be a standard type code assigned to it. We have lots of space. > > Yours, > Joel > > On 7/11/16 12:49 PM, Linda Dunbar wrote: >> _https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model >> /_has the examples of metadata that may need to be passed among SFs >> along a SFP, e.g. >> >> /SF1 may at real-time attach DoS information for the next SF in >> downstream. SF1 provides the hint and it is up to the downstream SFs >> to process it or ignore it. However if a downstream SF chooses to >> processes, it needs standardized metadata data model to understand the >> hint encoded by SF1 in packets./ >> >> To minimize the extra bytes added to packets in NSH, it is necessary >> to have compact encoding of the metadata carried by data packets. >> Achieving this goal will need control plane to inform the encoding >> mechanisms to SFs via out of band control channels. >> >> What do people think about the proposed framework for metadata >> exchanged among SFs on a SFP? >> >> >> Linda >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Elzur, Uri >> Sent: Friday, April 01, 2016 5:56 PM >> To: Sunil Vallamkonda; Joel M. Halpern; Dave Dolson; Bottorff, Paul; >> sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> Sunil >> >> To advance your point, it may be of advantage, IMHO, if you provide a >> concrete example of what metadata can be shared, and requires >> interoperability among vendors, in a specific example e.g. FW LB NAT >> (or choose your favorite). Notice some proposed directions in your draft. >> >> The thread reads very theoretical and suggests limited value for inter >> vendor interaction. Seems like you wish to counter it. A specific >> example may help bring the conversation down to ground level. >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sunil Vallamkonda >> Sent: Wednesday, March 30, 2016 11:04 AM >> To: Joel M. Halpern > >; Dave Dolson > >; Bottorff, Paul > >; sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> Joel, >> >> Good point, we are not trying to enumerate all the possible >> algorithmic behaviors. >> Yes, the proposal addresses both vendor and standardized metadata, >> where latter could be a flavor of former. >> In below MD-2, ignoring all metadata is a simple implementation, >> though with limited capabilities. However in all elements the sender >> and receiver need to co-ordinate metadata in a dynamic and scalable >> way to take intelligent actions. >> >> Re: #1: Is there a definite limitation in framework for metadata to be >> same for all packets ? It should not limit or mandate either way. >> Re: #2: If there is no need for receiver to understand the semantics >> across vendors and products and releases, I do not believe it would >> be a scalable solution. The code semantics and actions need to be >> aware by elements for metadata, without which we might well use only 'reserved' >> part of header or just treat MD-2 as a 'reserved' header itself, IMHO. >> >> Again to clarify, the intent and focus is have the ability to >> understand and extend metadata semantics for deployment. The goal is >> not to enumerate every possible situation but to provide semantics to >> customize and support algorithmic and other situations as individual case may be. >> >> >> Thanks, >> Sunil >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 30, 2016 10:56 AM >> To: Dave Dolson >; >> Sunil Vallamkonda >; Bottorff, >> Paul >; >> sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> In terms of copied information, control tells the SF what to copy. It >> does not matter what the granularity is. >> >> Given that "flow" does not have a consistent meaning (sometimes it >> means 5-tuple, sometimes it means other things) trying to define >> control instructions at other granularities than packet gets us into >> algorithmic behaviors. And I do not think we want to try to enumerate >> all of the "supported" algorithmic behaviors. >> >> Similarly, if the information is not the same as that from the >> prompting packet, we are again finding ourselves getting into >> algorithmic instructions (maybe you complement this field, or add 100 >> to that field, or bounce the third field off the roof.) >> >> If we neeed algorithmic behavior, it seems to me that the SF has to >> know what it is doing. It can not rely on control to tell it. Yes, >> this places some limits on generality of inserting metadata in >> produced packets. I would be interested in improvement, but I have not seen one. >> >> Yours, >> Joel >> >> On 3/30/16 1:47 PM, Dave Dolson wrote: >>> Joel, >>> I'd like to examine this point of yours: >>>> 2) Metadata to be copied from a prompting packet. This would seem >>>> to be provided by control as a list of type codes, with no need to >>>> understand semantics. >>> >>> Yes, I think control should provide information about different type codes. >>> But we believe there *is* some requirement to understand certain semantics. >>> E.g., >>> - is the metadata about the packet, about the flow or about the source or destination end-point? >>> - is the metadata important enough to add to new packets, or is it optional? >>> - is the metadata direction-specific, or can the value be cloned from a request to a response? >>> >>> If we don't address different types of semantics, I think we need to >>> agree there is only one type that works in all cases, or that certain >>> types should not be used in an opaque manner, or that certain types should not be used with service functions that need to inject packets. >>> >>> >>> Personally, I think that per-packet opaque metadata is problematic and probably to be avoided. >>> E.g., a metadata that is checksum of the packet. >>> If this is opaque to a function, the function may modify the packet >>> or clone the metadata from one packet to another without being able to update it. >>> >>> -Dave >>> >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Wednesday, March 30, 2016 1:27 PM >>> To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; sfc@ietf.org >>> >>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> I think you are mixing two concepts. >>> There is vendor metadata and standardized metadata. >>> >>> I do not think anything in the framework I have seen will make vendor >>> metadata interoperate without coordination between vendors. >>> >>> And as far as I can tell, there is nothing needed from the framework >>> to make standard metadata interoperate. >>> >>> That leaves the corner case of experimental or developmental metadata. >>> Experiments almost always need coordiantion. >>> >>> If we are talking about MD-2, it seems to me that SF and SFF will >>> simply ignore any metadata that they do not understand. In the >>> common case, SFF will ignore all metadata entirely. >>> >>> You have raised the question of what metadata shoudl go on packets >>> originated by service functions. This seems to be a complex >>> question, that is not helped by the framework. As far as I can tell, >>> I can see the following cases: >>> 1) Metadata about the SF originating the packet. This is common >>> across all packets, and can be provided to the SF by control means in >>> an opaque blob. >>> 2) Metadata to be copied from a prompting packet. This would seem to >>> be provided by control as a list of type codes, with no need to >>> understand semantics. >>> 3) Metadata derived algorithmically from information available to the >>> service function. This is hard. I do not see how the framework >>> helps here at all. Is it needed? >>> >>> Yours, >>> Joel >>> >>> On 3/30/16 1:06 PM, Sunil Vallamkonda wrote: >>>> When metadata is exchanged between SFFs, SFs, SFCs, it begs to the >>>> questions of interpretations. Without a framework for opaque >>>> metadata, the ambiguity between vendor products in service chain >>>> makes it incompatible unless the resolution is hardcoded across of >>>> releases and platforms, and vendor specific >> information encoded. The flexibility and ability for metadata to be >> interoperable and scale are benefits that are much needed for rapid >> deployments and adoption. >>>> >>>> >>>> Thanks, >>>> Sunil >>>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Wednesday, March 30, 2016 9:46 AM >>>> To: Bottorff, Paul >>> >; Dave Dolson >>> >; Sunil Vallamkonda >> >; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> I don't see why we would specify which metadata is of interest to a specific SF. It is up to the SF what it is interested in, not up to service chaining to control that. >>>> As for preserving forwarding addresses, while I see value in doing so for some transports, I don't see how SFC can mandate that since it is a transport dependent behavior. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 3/30/16 12:31 PM, Bottorff, Paul wrote: >>>>> Hi Dave and Joel: >>>>> >>>>> IMHO the most important thing to standardize is how an SFs couple >>>>> to a chain. We are already implying that it would be desirable for >>>>> SFs to pass both chain forwarding addresses and meta-data from >>>>> ingress to egress (proxy forwarding always comes with a cost), >>>>> however this alone does not provide enough >> guidance for SF network interfacing. We also have issues like how >> forwarding reversals are indicated at L4-Higher SFs and what meta-data >> is opaque and what is for SF consumption. >>>>> >>>>> Cheers, >>>>> >>>>> Paul >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>>>> Sent: Tuesday, March 29, 2016 7:30 PM >>>>> To: Joel Halpern Direct >>>> >; Sunil Vallamkonda >>>>> >; Joel M. Halpern >> >; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> Joel, >>>>> Consider a Service Function that needs to inject a packet, such as >>>>> articulated in >>>>> https://tools.ietf.org/html/draft-penno-sfc-packet-02 >>>>> The question arises, what metadata should be put in the NSH header of an injected packet? >>>>> >>>>> Without some kind of rigorous description of a type of metadata, I don't know how to program the Service Function to do it properly. >>>>> >>>>> The alternative is to hard-code each service function with the supported types of metadata. >>>>> This wouldn't allow a function to handle metadata it wasn't programmed for. >>>>> >>>>> >>>>> So unless there is some easier way of understanding this, there seems to be a gap in specifying Service Function behaviour. >>>>> This is one thing we're trying to figure out. >>>>> >>>>> >>>>> -Dave >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >>>>> Direct >>>>> Sent: Tuesday, March 29, 2016 7:37 PM >>>>> To: Sunil Vallamkonda; Joel M. Halpern; sfc@ietf.org >>>>> >>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> It may help to see some use cases. >>>>> >>>>> But it sounds, at best, like a specific control plane solution to some set of problems. >>>>> Specific control plane solutions, as distinct from descriptions of requirements, are out of scope for the working group. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 3/29/16 7:32 PM, Sunil Vallamkonda wrote: >>>>>> The focus is ability for vendor compatibility and extensibility in SF eco-system without hardcoding and human guessing. >>>>>> The categorization and rest may or may not be a fallout of this. >>>>>> Without such a framework, it makes interpretations harder across >>>>>> implementations. This would be normal case rather than exception, >>>>>> IMHO. The goal is not to standardize any vendor data, but provide >>>>>> a framework to promote vendor >> compatibility and extensibility across systems. As a clarification we >> can walk through use cases to understand the benefits. >>>>>> >>>>>> >>>>>> Thank you, >>>>>> Sunil. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>> Sent: Tuesday, March 29, 2016 4:20 PM >>>>>> To: Sunil Vallamkonda >; >>>>>> sfc@ietf.org >>>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>>>> >>>>>> I am sorry. I don't see the value in this. >>>>>> >>>>>> Trying to categorize metadata does not seem to help anything. >>>>>> Trying to standardize a descriptive langauge for metadata seems to imply something that can consume such a language. I can not imagine anything that can usefully consume this. >>>>>> >>>>>> I can understand how a human being would use a registry (which we have to have) to know what T codes are defined, and where to find descriptions of their meaning. >>>>>> But that meaning description is going to be in English. A file that tells me that value 17 is the Dragaeran Corporate type code for Houses does not tell me anything. >>>>>> >>>>>> The only corner case for the YANG is if my system has some understanding of the semantics of various pieces of metadata, but wants to know what code is associated with a particular usage. >>>>>> The problem is that we have mutliple different protocols that may want to provide that information, so all that SFC can define is that the control system must include a way to provide that information. >>>>>> >>>>>> Given that much of the metadata is not vendor specific, the structure seems very odd. >>>>>> ANd it seems likely that any vendor specific metadata will need the semantics to already be known, since we can not standardize that. >>>>>> >>>>>> Yours in puzzlement, >>>>>> Joel >>>>>> >>>>>> On 3/29/16 6:33 PM, Sunil Vallamkonda wrote: >>>>>>> Metadata is a vital element of SFC and thus NFV. >>>>>>> >>>>>>> Additionally, interoperability and vendor support challenges >>>>>>> need to be addressed in a scalable and adaptable way for rapid deployment. >>>>>>> >>>>>>> In January we uploaded draft-vallamkonda-sfc-metadata-model-00, >>>>>>> which proposes terminology for talking about metadata in an extensible fashion. >>>>>>> >>>>>>> If there are no objections, we'd like to start pushing this >>>>>>> terminology into drafts about NSH and the control-plane. >>>>>>> >>>>>>> Please let us know what you think. >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> Sunil. >>>>>>> >>>>>>> == >>>>>>> >>>>>>> A new version of I-D, draft-vallamkonda-sfc-metadata-model-00.txt >>>>>>> >>>>>>> has been successfully submitted by Sunil Vallamkonda and posted >>>>>>> to the IETF repository. >>>>>>> >>>>>>> Name: draft-vallamkonda-sfc-metadata-model >>>>>>> >>>>>>> Revision: 00 >>>>>>> >>>>>>> Title: Information Model for SFC Metadata >>>>>>> >>>>>>> Document date: 2016-01-28 >>>>>>> >>>>>>> Group: Individual Submission >>>>>>> >>>>>>> Pages: 9 >>>>>>> >>>>>>> URL: >>>>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metada >>>>>>> t >>>>>>> a- >>>>>>> m >>>>>>> o >>>>>>> del-00.txt >>>>>>> >>>>>>> Status: >>>>>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-m >>>>>>> o >>>>>>> de >>>>>>> l >>>>>>> / >>>>>>> >>>>>>> Htmlized: >>>>>>> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model- >>>>>>> 0 >>>>>>> 0 >>>>>>> >>>>>>> Abstract: >>>>>>> >>>>>>> Various types of metadata are applicable to Service >>>>>>> Function Chaining >>>>>>> >>>>>>> (SFC). A Service Function (SF) needs information about >>>>>>> all metadata >>>>>>> >>>>>>> passing through it. The metadata could be used to convey >>>>>>> >>>>>>> preprocessing information about the packet by other nodes >>>>>>> and an SF >>>>>>> >>>>>>> can attach post processing information as deemed necessary. >>>>>>> >>>>>>> The purpose of this document is to rigorously define the >>>>>>> classes of >>>>>>> >>>>>>> metadata and provide a vocabulary and information model for metadata. >>>>>>> >>>>>>> Each item of metadata refers to a subject, examples of >>>>>>> which are IP >>>>>>> >>>>>>> endpoint, flow or individual packet. >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission until the htmlized version and diff are available at >>>>>>> tools.ietf.org. >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> 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 Jul 11 12:00: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 D39F712D750 for ; Mon, 11 Jul 2016 12:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 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.287] 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 7ji52jgQH0yT for ; Mon, 11 Jul 2016 12:00:37 -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 50DF512D765 for ; Mon, 11 Jul 2016 12:00:33 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Mon, 11 Jul 2016 15:00:32 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: A problem with NSH TLV Thread-Index: AdHbpn9FIK2jtVK+Qw+RjM80Xmdatw== Date: Mon, 11 Jul 2016 19:00:31 +0000 Message-ID: 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_E8355113905631478EFF04F5AA706E9830FF3AEDwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2016 19:00:42 -0000 --_000_E8355113905631478EFF04F5AA706E9830FF3AEDwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830FF3AEDwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 

This is the TLV format:

=         0     &= nbsp;           &nbs= p; 1            = ;       2      =              3<= o:p>

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

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;   Metadata Class       |C|&nb= sp;   Type     |R|R|R|   Len &= nbsp; |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;           &nbs= p;   Variable Metadata       &= nbsp;           &nbs= p;    |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

 

Len is defined as number of 4-byte words.=

The problem with this is that strings aren’t a= lways multiples of 4 bytes in length.

 

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 

   10.  Universal Resource Identifier= (URI)

 

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |       &= nbsp; TLV Class =3D 0x0       |C|  =   Type=3D0xA |R|R|R|   L=3Dvar |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |UT(4)  |     =            URI  = ;            &n= bsp;            = ;         |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       ~       &= nbsp;           &nbs= p;    URI        &nb= sp;            =             &nb= sp;  ~

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

 

Despite the confusing part about the first nybble be= ing used for UT field (supposed to be an octet?),

if the URI is not a multiple of 4 bytes, how is it t= o be terminated?

 

Diameter (RFC6733) solves this problem nicely by mak= ing the length indicate a number of octets, while specifying padding to 4-o= ctet alignment for the next element.

 

So my proposal is to recruit two of the ‘RR= 17; bits into the ‘L’ field, and have it indicate number of oct= ets; and also say that padding is to be inserted so that each TLV is a mult= iple of 4 octets in length.

 

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_E8355113905631478EFF04F5AA706E9830FF3AEDwtlexchp2sandvi_-- From nobody Mon Jul 11 12:12: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 40E9B12B05F for ; Mon, 11 Jul 2016 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRpHqAIOp40a for ; Mon, 11 Jul 2016 12:12:30 -0700 (PDT) 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 1996D12B041 for ; Mon, 11 Jul 2016 12:12:30 -0700 (PDT) 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.0266.001; Mon, 11 Jul 2016 12:12:29 -0700 From: Ron Parker To: Dave Dolson , "sfc@ietf.org" Thread-Topic: A problem with NSH TLV Thread-Index: AdHbpn9FIK2jtVK+Qw+RjM80XmdatwAANXVg Date: Mon, 11 Jul 2016 19:12:28 +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: [50.205.79.154] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809904MBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2016 19:12:32 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809904MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809904MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron<= /o:p>

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On= Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 

This is the TLV format:

=         0     &= nbsp;           &nbs= p; 1            = ;       2      =              3<= o:p>

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

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;   Metadata Class       |C|&nb= sp;   Type     |R|R|R|   Len &= nbsp; |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;           &nbs= p;   Variable Metadata       &= nbsp;           &nbs= p;    |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

 

Len is defined as number of 4-byte words.=

The problem with this is that strings aren’t a= lways multiples of 4 bytes in length.

 

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 

   10.  Universal Resource Identifier= (URI)

 

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |       &= nbsp; TLV Class =3D 0x0       |C|  =   Type=3D0xA |R|R|R|   L=3Dvar |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |UT(4)  |     =            URI  = ;            &n= bsp;            = ;         |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       ~       &= nbsp;           &nbs= p;    URI        &nb= sp;            =             &nb= sp;  ~

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

 

Despite the confusing part about the first nybble be= ing used for UT field (supposed to be an octet?),

if the URI is not a multiple of 4 bytes, how is it t= o be terminated?

 

Diameter (RFC6733) solves this problem nicely by mak= ing the length indicate a number of octets, while specifying padding to 4-o= ctet alignment for the next element.

 

So my proposal is to recruit two of the ‘RR= 17; bits into the ‘L’ field, and have it indicate number of oct= ets; and also say that padding is to be inserted so that each TLV is a mult= iple of 4 octets in length.

 

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809904MBX021W3CA2exch_-- From nobody Mon Jul 11 13:15: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 BD7F712D0B8 for ; Mon, 11 Jul 2016 13:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 X_C0aN-XCSrL for ; Mon, 11 Jul 2016 13:15:05 -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 9FFA912D0B7 for ; Mon, 11 Jul 2016 13:15:05 -0700 (PDT) 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.0195.001; Mon, 11 Jul 2016 16:15:03 -0400 From: Dave Dolson To: Ron Parker , "sfc@ietf.org" Thread-Topic: A problem with NSH TLV Thread-Index: AdHbpn9FIK2jtVK+Qw+RjM80XmdatwAANXVgAAJQshA= Date: Mon, 11 Jul 2016 20:15:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FF3E3Dwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2016 20:15:08 -0000 --_000_E8355113905631478EFF04F5AA706E9830FF3E3Dwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830FF3E3Dwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ron,=

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Park= er [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org
Subject: RE: A problem with NSH TLV

 

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron<= /o:p>

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 

This is the TLV format:

=         0     &= nbsp;           &nbs= p; 1            = ;       2      =              3<= o:p>

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

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;   Metadata Class       |C|&nb= sp;   Type     |R|R|R|   Len &= nbsp; |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;           &nbs= p;   Variable Metadata       &= nbsp;           &nbs= p;    |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

 

Len is defined as number of 4-byte words.=

The problem with this is that strings aren’t a= lways multiples of 4 bytes in length.

 

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 

   10.  Universal Resource Identifier= (URI)

 

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |       &= nbsp; TLV Class =3D 0x0       |C|  =   Type=3D0xA |R|R|R|   L=3Dvar |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |UT(4)  |     =            URI  = ;            &n= bsp;            = ;         |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       ~       &= nbsp;           &nbs= p;    URI        &nb= sp;            =             &nb= sp;  ~

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

 

Despite the confusing part about the first nybble be= ing used for UT field (supposed to be an octet?),

if the URI is not a multiple of 4 bytes, how is it t= o be terminated?

 

Diameter (RFC6733) solves this problem nicely by mak= ing the length indicate a number of octets, while specifying padding to 4-o= ctet alignment for the next element.

 

So my proposal is to recruit two of the ‘RR= 17; bits into the ‘L’ field, and have it indicate number of oct= ets; and also say that padding is to be inserted so that each TLV is a mult= iple of 4 octets in length.

 

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_E8355113905631478EFF04F5AA706E9830FF3E3Dwtlexchp2sandvi_-- From nobody Mon Jul 11 13:51: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 B6AA912D50E for ; Mon, 11 Jul 2016 13:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 w9IzEvdp6VUu for ; Mon, 11 Jul 2016 13:51:25 -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 5032312D1E6 for ; Mon, 11 Jul 2016 13:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20371; q=dns/txt; s=iport; t=1468270285; x=1469479885; h=from:to:subject:date:message-id:mime-version; bh=+xy9GAHye0oncwq/s5UE5xp/HcIJjATHEvGPrznBfPs=; b=fw572gDLbZXvuIk5FF90ixeZQrzmuNXLS+3JB/chcnX9lFbdenfpYatY VswE2rYH5luQsLbLyMSXTm4v1BudEQK3MprwMw6+VnEdIoDys7rT2tj9Y MMG9VdvO1w/jFPteWFqLi/h3xMxwipCVwhmBZXAYO/wHofjaZDe8LsBPd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnBQDeBYRX/4gNJK1cgnBOVnwGuH+Be?= =?us-ascii?q?iSCGCWDNwKBKzoSAQEBAQEBAWUnhFwBAQUMIV4BCA4DAwEBASg5FAkKBAESFAe?= =?us-ascii?q?IFQ6/HgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhieETYRPEhaFJQWIe4VDiloBh?= =?us-ascii?q?gyIRY8skA4BJQYpggYfgUxuAQGIPn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,348,1464652800"; d="scan'208,217";a="294672472" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2016 20:51:24 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6BKpOgK015114 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2016 20:51:24 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 15:51:23 -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; Mon, 11 Jul 2016 15:51:23 -0500 From: "Reinaldo Penno (repenno)" To: Dave Dolson , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR27X7XMarZA5RR0+l5xlFeVgJdg== Date: Mon, 11 Jul 2016 20:51:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.245.109] Content-Type: multipart/alternative; boundary="_000_D3A98CBF27B78repennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2016 20:51:28 -0000 --_000_D3A98CBF27B78repennociscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why does it need to be backward compatible? If you had (or have) this probl= em now you would not be able to make it work anyway. We solved this some time back by specifying the following for strings that = do not finish on proper boundaries. SF Type: A string representing the SF type padded to a 4-byte boundary and encoded with UTF-8. Service types can be found and registered in [I-D.penno-sfc-yang]. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_D3A98CBF27B78repennociscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <40A51508FF72C04B9C857B60996910EF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Why does it need to be backward compatible? If you had (or have) this = problem now you would not be able to make it work anyway.

We solved this some time back by specifying the following for strings = that do not finish on proper boundaries.

   SF Type:  A string representing the SF type padde=
d to a 4-byte
      boundary and encoded with UTF-8.  Service types can be found and
      registered in [I-D.penno-sfc-yang].




From: sfc <sfc-bounces@ietf.org> on behalf of Dave Dolson &l= t;ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15= PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>,= "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] A problem with N= SH TLV

Ron,=

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron<= /o:p>

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 

This is the TLV format:

=         0     &= nbsp;           &nbs= p; 1            = ;       2      =              3<= o:p>

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

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;   Metadata Class       |C|&nb= sp;   Type     |R|R|R|   Len &= nbsp; |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;           &nbs= p;   Variable Metadata       &= nbsp;           &nbs= p;    |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

 

Len is defined as number of 4-byte words.=

The problem with this is that strings aren’t a= lways multiples of 4 bytes in length.

 

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 

   10.  Universal Resource Identifier= (URI)

 

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |       &= nbsp; TLV Class =3D 0x0       |C|  =   Type=3D0xA |R|R|R|   L=3Dvar |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |UT(4)  |     =            URI  = ;            &n= bsp;            = ;         |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       ~       &= nbsp;           &nbs= p;    URI        &nb= sp;            =             &nb= sp;  ~

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

 

Despite the confusing part about the first nybble be= ing used for UT field (supposed to be an octet?),

if the URI is not a multiple of 4 bytes, how is it t= o be terminated?

 

Diameter (RFC6733) solves this problem nicely by mak= ing the length indicate a number of octets, while specifying padding to 4-o= ctet alignment for the next element.

 

So my proposal is to recruit two of the ‘RR= 17; bits into the ‘L’ field, and have it indicate number of oct= ets; and also say that padding is to be inserted so that each TLV is a mult= iple of 4 octets in length.

 

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

 --_000_D3A98CBF27B78repennociscocom_-- From nobody Mon Jul 11 13:59: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 B2AF712D0F7 for ; Mon, 11 Jul 2016 13:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkjJSUYTpyb6 for ; Mon, 11 Jul 2016 13:59:06 -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 2EBBC12D0E1 for ; Mon, 11 Jul 2016 13:59:06 -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.0266.001; Mon, 11 Jul 2016 13:59:05 -0700 From: Ron Parker To: "Reinaldo Penno (repenno)" , Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR27X7XMarZA5RR0+l5xlFeVgJdqATtZNA Date: Mon, 11 Jul 2016 20:59:05 +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: [50.205.79.154] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809A5FMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2016 20:59:09 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809A5FMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reinaldo, Regarding backward compatibility, this was a question to the community, not= a statement. Thanks for providing your answer. For strings, NULL termination and padding makes sense, but we would want to= be explicit that strings always included the NULL. For small native types (1 octet, 2 octet), there could also be explicit lan= guage about how to map into the 4 octet field. But, for arbitrary octet strings, only an octet oriented length (or the oct= et pad length) would suffice. I feel that type 2 metadata should include = the ability to carry octet strings. Ron From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 4:51 PM To: Dave Dolson ; Ron Parker ; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV Why does it need to be backward compatible? If you had (or have) this probl= em now you would not be able to make it work anyway. We solved this some time back by specifying the following for strings that = do not finish on proper boundaries. SF Type: A string representing the SF type padded to a 4-byte boundary and encoded with UTF-8. Service types can be found and registered in [I-D.penno-sfc-yang]. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809A5FMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reinaldo,

 

Regarding backward com= patibility, this was a question to the community, not a statement. &nb= sp; Thanks for providing your answer.

 

For strings, NULL term= ination and padding makes sense, but we would want to be explicit that stri= ngs always included the NULL.

 

For small native types= (1 octet, 2 octet), there could also be explicit language about how to map= into the 4 octet field.

 

But, for arbitrary oct= et strings, only an octet oriented length (or the octet pad length) would s= uffice.   I feel that type 2 metadata should include the ability = to carry octet strings.

 

   Ron<= /o:p>

 

 

From: Reinaldo Penno (repenno) [mailto:repenn= o@cisco.com]
Sent: Monday, July 11, 2016 4:51 PM
To: Dave Dolson <ddolson@sandvine.com>; Ron Parker <Ron_Par= ker@affirmednetworks.com>; sfc@ietf.org
Subject: Re: [sfc] A problem with NSH TLV

 

Why doe= s it need to be backward compatible? If you had (or have) this problem now = you would not be able to make it work anyway.

&n= bsp;

We solv= ed this some time back by specifying the following for strings that do not = finish on proper boundaries.

&n= bsp;

   SF Type:  A string repre=
senting the SF type padded to a 4-byte
      boundary an=
d encoded with UTF-8.  Service types can be found and
      registered =
in [I-D.penno-sfc-yang].

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809A5FMBX021W3CA2exch_-- From nobody Mon Jul 11 14:02: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 1233B12D1BE for ; Mon, 11 Jul 2016 14:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 GrntT8I9SZ3y for ; Mon, 11 Jul 2016 14:02:03 -0700 (PDT) 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 1D76D12D103 for ; Mon, 11 Jul 2016 14:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29580; q=dns/txt; s=iport; t=1468270923; x=1469480523; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bZxlghRP6/JDGE4omApOfCKnFhP/rIBiu5MO8zAPXZw=; b=VxzoVZKvN9IJc9yCUd6tlsWtaNMEUqrUCeUOo2G2JmMvV0D3jjgQKWCg pA5aqTMJCZIUQ+tzc56hFvn4o8nJw1nRM5F740HwEaLg1xhsI3Zh3rmVc RYbUSURHaMTwtQEze0n+VJNYKVQx70VcQm96pdUhhC2WLxbbsAy+1mICL 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoBQCjCIRX/49dJa1cgnBOVnwGuH+Be?= =?us-ascii?q?iSCGCWDNwKBKzoSAQEBAQEBAWUnhFwBAQUMIVwCAQgRAwEBASEBBgcyFAkIAgQ?= =?us-ascii?q?BEhQHiBUOvyMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYnhE2ETxIWhSUFiHuQH?= =?us-ascii?q?QGGDIhFjyyQDgEkAS+CBh+BTG4BAYg+fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,348,1464652800"; d="scan'208,217";a="127623595" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2016 21:02:01 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6BL21Oq000529 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2016 21: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; Mon, 11 Jul 2016 16:02:00 -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; Mon, 11 Jul 2016 16:02:01 -0500 From: "Reinaldo Penno (repenno)" To: Ron Parker , Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR27X7XMarZA5RR0+l5xlFeVgJdqATtZNAgAAjbwA= Date: Mon, 11 Jul 2016 21:02:01 +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/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.245.109] Content-Type: multipart/alternative; boundary="_000_D3A98F4F27B7Erepennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2016 21:02:05 -0000 --_000_D3A98F4F27B7Erepennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Ron Parker > Date: Monday, July 11, 2016 at 5:59 PM To: Reinaldo Penno >, Dave Dols= on >, "sfc@ietf.org" > Subject: RE: [sfc] A problem with NSH TLV Reinaldo, Regarding backward compatibility, this was a question to the community, not= a statement. Thanks for providing your answer. For strings, NULL termination and padding makes sense, but we would want to= be explicit that strings always included the NULL. For small native types (1 octet, 2 octet), there could also be explicit lan= guage about how to map into the 4 octet field. [RP] Right, if the minimum size is 4 octets for example. But, for arbitrary octet strings, only an octet oriented length (or the oct= et pad length) would suffice. I feel that type 2 metadata should include = the ability to carry octet strings. Ron From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 4:51 PM To: Dave Dolson >; Ron Pa= rker >; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV Why does it need to be backward compatible? If you had (or have) this probl= em now you would not be able to make it work anyway. We solved this some time back by specifying the following for strings that = do not finish on proper boundaries. SF Type: A string representing the SF type padded to a 4-byte boundary and encoded with UTF-8. Service types can be found and registered in [I-D.penno-sfc-yang]. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I=92d be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well =96 fields whose lengths are = not multiples of 4 are =93left justified=94 towards the lower octet numbers= with zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren=92t always multiples of 4 bytes = in length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the =91R=92 bits into the =91L=92 field= , and have it indicate number of octets; and also say that padding is to be= inserted so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_D3A98F4F27B7Erepennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2002948ED0833F4283788E203E9BD10A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: Ron Parker <Ron_Parker@affirmednetworks.com>= ;
Date: Monday, July 11, 2016 at 5:59= PM
To: Reinaldo Penno <repenno@cisco.com>, Dave Dolson <ddolson@sandvine.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] A problem with N= SH TLV

Reinaldo,

 

Regarding backward com= patibility, this was a question to the community, not a statement. &nb= sp; Thanks for providing your answer.

 

For strings, NULL term= ination and padding makes sense, but we would want to be explicit that stri= ngs always included the NULL.

 

For small native types= (1 octet, 2 octet), there could also be explicit language about how to map= into the 4 octet field.

[RP] Right, if the minimum size is 4 octets for example. 

 

But, for arbitrary oct= et strings, only an octet oriented length (or the octet pad length) would s= uffice.   I feel that type 2 metadata should include the ability = to carry octet strings.

 

   Ron<= /o:p>

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 4:51 PM
To: Dave Dolson <ddolson@= sandvine.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: Re: [sfc] A problem with NSH TLV

 

Why doe= s it need to be backward compatible? If you had (or have) this problem now = you would not be able to make it work anyway.

&n= bsp;

We solv= ed this some time back by specifying the following for strings that do not = finish on proper boundaries.

&n= bsp;

   SF Type:  A string repre=
senting the SF type padded to a 4-byte
      boundary an=
d encoded with UTF-8.  Service types can be found and
      registered =
in [I-D.penno-sfc-yang].

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I=92d be OK with that.=

 

-Dave

 

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well =96 fields whose lengths are not multiples of 4 are =93left justified=94 towards the lower = octet numbers with zero-value padding inserted at the higher octet numbers.=

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren=92t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the =91R=92 bits into the =91L=92 field, and have it indicate n= umber of octets; and also say that padding is to be inserted so that each T= LV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_D3A98F4F27B7Erepennociscocom_-- From nobody Mon Jul 11 14:09: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 0C54212D12B for ; Mon, 11 Jul 2016 14:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 siL71q32RAca for ; Mon, 11 Jul 2016 14:09:19 -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 2B4C012D0FC for ; Mon, 11 Jul 2016 14:09:19 -0700 (PDT) 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.0195.001; Mon, 11 Jul 2016 17:09:17 -0400 From: Dave Dolson To: "Reinaldo Penno (repenno)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR27X7XMarZA5RR0+l5xlFeVgJdqATtZNAgAAjbwD//97GgA== Date: Mon, 11 Jul 2016 21:09:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FF417Dwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2016 21:09:21 -0000 --_000_E8355113905631478EFF04F5AA706E9830FF417Dwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I feel that binary data should be supported. (I believe Ron is saying the s= ame by "octet strings") I.e., strings with nulls in them. Hence, without length it would not be known whether null padding is part of= the data or not. From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 5:02 PM To: Ron Parker; Dave Dolson; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV From: Ron Parker > Date: Monday, July 11, 2016 at 5:59 PM To: Reinaldo Penno >, Dave Dols= on >, "sfc@ietf.org" > Subject: RE: [sfc] A problem with NSH TLV Reinaldo, Regarding backward compatibility, this was a question to the community, not= a statement. Thanks for providing your answer. For strings, NULL termination and padding makes sense, but we would want to= be explicit that strings always included the NULL. For small native types (1 octet, 2 octet), there could also be explicit lan= guage about how to map into the 4 octet field. [RP] Right, if the minimum size is 4 octets for example. But, for arbitrary octet strings, only an octet oriented length (or the oct= et pad length) would suffice. I feel that type 2 metadata should include = the ability to carry octet strings. Ron From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 4:51 PM To: Dave Dolson >; Ron Pa= rker >; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV Why does it need to be backward compatible? If you had (or have) this probl= em now you would not be able to make it work anyway. We solved this some time back by specifying the following for strings that = do not finish on proper boundaries. SF Type: A string representing the SF type padded to a 4-byte boundary and encoded with UTF-8. Service types can be found and registered in [I-D.penno-sfc-yang]. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830FF417Dwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I feel that binary dat= a should be supported. (I believe Ron is saying the same by “octet st= rings”)

I.e., strings with nul= ls in them.

Hence, without length = it would not be known whether null padding is part of the data or not.=

 

 

 

From: Reinaldo= Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 5:02 PM
To: Ron Parker; Dave Dolson; sfc@ietf.org
Subject: Re: [sfc] A problem with NSH TLV

 

&n= bsp;

&n= bsp;

From: Ron Parker <Ron_Parker@affirmednetworks.com>
Date: Monday, July 11, 2016 at 5:59 PM
To: Reinaldo Penno <repenno@= cisco.com>, Dave Dolson <= ddolson@sandvine.com>, "sfc@iet= f.org" <sfc@ietf.org> Subject: RE: [sfc] A problem with NSH TLV

&n= bsp;

Reinaldo,

 

Regarding backward com= patibility, this was a question to the community, not a statement. &nb= sp; Thanks for providing your answer.

 

For strings, NULL term= ination and padding makes sense, but we would want to be explicit that stri= ngs always included the NULL.=

 

For small native types= (1 octet, 2 octet), there could also be explicit language about how to map= into the 4 octet field.

&n= bsp;

[RP] Ri= ght, if the minimum size is 4 octets for example. 

 

But, for arbitrary oct= et strings, only an octet oriented length (or the octet pad length) would s= uffice.   I feel that type 2 metadata should include the ability = to carry octet strings.

 

   Ron

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 4:51 PM
To: Dave Dolson <ddolson@= sandvine.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: Re: [sfc] A problem with NSH TLV

 =

Why doe= s it need to be backward compatible? If you had (or have) this problem now = you would not be able to make it work anyway.

 <= /span>

We solv= ed this some time back by specifying the following for strings that do not = finish on proper boundaries.<= /span>

 <= /span>

   SF Type:  A string repre=
senting the SF type padded to a 4-byte
      boundary an=
d encoded with UTF-8.  Service types can be found and
      registered =
in [I-D.penno-sfc-yang].

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

 <= /span>

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_E8355113905631478EFF04F5AA706E9830FF417Dwtlexchp2sandvi_-- From nobody Mon Jul 11 14:12: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 C68ED12D110 for ; Mon, 11 Jul 2016 14:12:30 -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, 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] 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 5a4emIr0AGiv for ; Mon, 11 Jul 2016 14:12:28 -0700 (PDT) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EDA112D0FC for ; Mon, 11 Jul 2016 14:12:28 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0266.001; Mon, 11 Jul 2016 14:12:27 -0700 From: Ron Parker To: Dave Dolson , "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR27X7XMarZA5RR0+l5xlFeVgJdqATtZNAgAAjbwD//97GgIAAAnqg Date: Mon, 11 Jul 2016 21:12:27 +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: [50.205.79.154] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809AD8MBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2016 21:12:31 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809AD8MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, by octet strings I was meaning binary (as opposed to UTF-8/ASCII type = strings). Thanks. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Monday, July 11, 2016 5:09 PM To: Reinaldo Penno (repenno) ; Ron Parker ; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV I feel that binary data should be supported. (I believe Ron is saying the s= ame by "octet strings") I.e., strings with nulls in them. Hence, without length it would not be known whether null padding is part of= the data or not. From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 5:02 PM To: Ron Parker; Dave Dolson; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV From: Ron Parker > Date: Monday, July 11, 2016 at 5:59 PM To: Reinaldo Penno >, Dave Dols= on >, "sfc@ietf.org" > Subject: RE: [sfc] A problem with NSH TLV Reinaldo, Regarding backward compatibility, this was a question to the community, not= a statement. Thanks for providing your answer. For strings, NULL termination and padding makes sense, but we would want to= be explicit that strings always included the NULL. For small native types (1 octet, 2 octet), there could also be explicit lan= guage about how to map into the 4 octet field. [RP] Right, if the minimum size is 4 octets for example. But, for arbitrary octet strings, only an octet oriented length (or the oct= et pad length) would suffice. I feel that type 2 metadata should include = the ability to carry octet strings. Ron From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 4:51 PM To: Dave Dolson >; Ron Pa= rker >; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV Why does it need to be backward compatible? If you had (or have) this probl= em now you would not be able to make it work anyway. We solved this some time back by specifying the following for strings that = do not finish on proper boundaries. SF Type: A string representing the SF type padded to a 4-byte boundary and encoded with UTF-8. Service types can be found and registered in [I-D.penno-sfc-yang]. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809AD8MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, by octet strings = I was meaning binary (as opposed to UTF-8/ASCII type strings).

 

Thanks.

 

   Ron<= /o:p>

 

 

From: Dave Dolson [mailto:ddolson@sandvine.co= m]
Sent: Monday, July 11, 2016 5:09 PM
To: Reinaldo Penno (repenno) <repenno@cisco.com>; Ron Parker &= lt;Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

I feel that binary dat= a should be supported. (I believe Ron is saying the same by “octet st= rings”)

I.e., strings with nul= ls in them.

Hence, without length = it would not be known whether null padding is part of the data or not.=

 

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 5:02 PM
To: Ron Parker; Dave Dolson; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 

&n= bsp;

&n= bsp;

From: Ron Parker <Ron_Parker@affirmednetworks.com>
Date: Monday, July 11, 2016 at 5:59 PM
To: Reinaldo Penno <repenno@= cisco.com>, Dave Dolson <= ddolson@sandvine.com>, "sfc@iet= f.org" <sfc@ietf.org> Subject: RE: [sfc] A problem with NSH TLV

&n= bsp;

Reinaldo,

 

Regarding backward com= patibility, this was a question to the community, not a statement. &nb= sp; Thanks for providing your answer.

 

For strings, NULL term= ination and padding makes sense, but we would want to be explicit that stri= ngs always included the NULL.=

 

For small native types= (1 octet, 2 octet), there could also be explicit language about how to map= into the 4 octet field.

&n= bsp;

[RP] Ri= ght, if the minimum size is 4 octets for example. 

 

But, for arbitrary oct= et strings, only an octet oriented length (or the octet pad length) would s= uffice.   I feel that type 2 metadata should include the ability = to carry octet strings.

 

   Ron

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 4:51 PM
To: Dave Dolson <ddolson@= sandvine.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: Re: [sfc] A problem with NSH TLV

 =

Why doe= s it need to be backward compatible? If you had (or have) this problem now = you would not be able to make it work anyway.

 <= /span>

We solv= ed this some time back by specifying the following for strings that do not = finish on proper boundaries.<= /span>

 <= /span>

   SF Type:  A string repre=
senting the SF type padded to a 4-byte
      boundary an=
d encoded with UTF-8.  Service types can be found and
      registered =
in [I-D.penno-sfc-yang].

 <= /span>

 <= /span>

 <= /span>

 <= /span>

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

 <= /span>

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_CDF2F015F4429F458815ED2A6C2B6B0B6D809AD8MBX021W3CA2exch_-- From nobody Mon Jul 11 17:04: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 E264512B02A for ; Mon, 11 Jul 2016 17:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 bh3QHysqGw4q for ; Mon, 11 Jul 2016 17:04:32 -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 7268212B01D for ; Mon, 11 Jul 2016 17:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19620; q=dns/txt; s=iport; t=1468281872; x=1469491472; h=from:to:subject:date:message-id:mime-version; bh=ro1yg65quHDLa4Xfi8XXiaTI3UVK/IW4VjmKf0A4NGg=; b=L43VFDR4mPX/+BveAcazk41e49XONHKDIUncoKzZf/HbVWCq+t7kVInW 9VZ9CrSXzKmSCJHpPt8s+S/p04VFfWFbtm9lxOk15jIGG3A6cEzdczOa3 Wl0UxObLLasZa5y05wXAsasg0pEPR4DPxbyHh2ipWWhU9vfNXwzl7Uy97 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzBQCkMoRX/4gNJK1cgnBOVnwGuQKBe?= =?us-ascii?q?iKCGiWDNwKBLTkTAQEBAQEBAWUnhFwBAQUMIV4BCA4DAwEBASg5FAkKBAESFAe?= =?us-ascii?q?IFQ6/IAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqETYRPEhaFJQWIe4VEilsBh?= =?us-ascii?q?g6IRY8tkBABIAMxggYfgUxuAQGIPn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,348,1464652800"; d="scan'208,217";a="128418447" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2016 00:04:31 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6C04Vdx018347 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2016 00:04:31 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 19:04:30 -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; Mon, 11 Jul 2016 19:04:30 -0500 From: "Reinaldo Penno (repenno)" To: Dave Dolson , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdg== Date: Tue, 12 Jul 2016 00:04:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.245.109] Content-Type: multipart/alternative; boundary="_000_D3A9BA0427BA4repennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 12 Jul 2016 00:04:35 -0000 --_000_D3A9BA0427BA4repennociscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_D3A9BA0427BA4repennociscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <901CE45F05A8EA4D8A6EAD4033890CFC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
This is not really a new problem and hopefully we can leverage widely = used solutions.  IPfix for example also relies on TLVs and has encodin= gs for octets strings, binary and all other formats known to man.  &nb= sp;

From: sfc <sfc-bounces@ietf.org> on behalf of Dave Dolson &l= t;ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15= PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>,= "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] A problem with N= SH TLV

Ron,=

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron<= /o:p>

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 

This is the TLV format:

=         0     &= nbsp;           &nbs= p; 1            = ;       2      =              3<= o:p>

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

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;   Metadata Class       |C|&nb= sp;   Type     |R|R|R|   Len &= nbsp; |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

=        |      &= nbsp;           &nbs= p;   Variable Metadata       &= nbsp;           &nbs= p;    |

=        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

 

Len is defined as number of 4-byte words.=

The problem with this is that strings aren’t a= lways multiples of 4 bytes in length.

 

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 

   10.  Universal Resource Identifier= (URI)

 

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |       &= nbsp; TLV Class =3D 0x0       |C|  =   Type=3D0xA |R|R|R|   L=3Dvar |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       |UT(4)  |     =            URI  = ;            &n= bsp;            = ;         |

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

=       ~       &= nbsp;           &nbs= p;    URI        &nb= sp;            =             &nb= sp;  ~

=       +-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;

 

Despite the confusing part about the first nybble be= ing used for UT field (supposed to be an octet?),

if the URI is not a multiple of 4 bytes, how is it t= o be terminated?

 

Diameter (RFC6733) solves this problem nicely by mak= ing the length indicate a number of octets, while specifying padding to 4-o= ctet alignment for the next element.

 

So my proposal is to recruit two of the ‘RR= 17; bits into the ‘L’ field, and have it indicate number of oct= ets; and also say that padding is to be inserted so that each TLV is a mult= iple of 4 octets in length.

 

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

 --_000_D3A9BA0427BA4repennociscocom_-- From nobody Mon Jul 11 17:06: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 F2F9412D69F for ; Mon, 11 Jul 2016 17:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.307 X-Spam-Level: X-Spam-Status: No, score=-8.307 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.287, 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 xnjlgjV0AeWg for ; Mon, 11 Jul 2016 17:06:06 -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 94EDB12B02A for ; Mon, 11 Jul 2016 17:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1468281966; x=1499817966; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ni8UQeqagzoPnAzLpf4YtYQVkR6zKDOQN+3YbrQ+Dfc=; b=HeX/8ZJwMCUsFrr0FzfN44FAefaTfz1aWGtxyOS+ck9/3LLtbnHSBWFS rLZbvd0ElGKpnOK7Jw33OlQ7fkwdMWwtNo+0xMg3/uNaBbt5XLD1jJU+X 54tdKywdWRFHT2mOzKcjHJWp3XQKaiEdkTw3RtQOiiD1VVsquwar2hiGD E=; X-IronPort-AV: E=Sophos;i="5.28,348,1464652800"; d="scan'208,217";a="228960131" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 12 Jul 2016 00:06:06 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX07.olympus.F5Net.com (192.168.15.50) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 11 Jul 2016 17:06:05 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1178.000; Mon, 11 Jul 2016 17:06:06 -0700 From: Sumandra Majee To: Ron Parker , "Reinaldo Penno (repenno)" , Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR27X7XMarZA5RR0+l5xlFeVgJdqATtZNAgAA1cAA= Date: Tue, 12 Jul 2016 00:06:05 +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/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_D3A9818A55914smajeef5com_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 12 Jul 2016 00:06:08 -0000 --_000_D3A9818A55914smajeef5com_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >>But, for arbitrary octet strings, only an octet oriented length (or the o= ctet pad length) would suffice. I feel that type 2 metadata should includ= e the ability to carry octet strings Yeah, I agree that it is better to represent LEN as number of octets. I bel= ieve the current LEN is set as number of 4 byte/octet because it makes it c= onsistent with the main NSH header length. But I agree that individual TLV = len should be represented as number of octets. From: sfc > on behalf of = Ron Parker > Date: Monday, July 11, 2016 at 1:59 PM To: "Reinaldo Penno (repenno)" = >, Dave Dolson >, "sfc@ie= tf.org" > Subject: Re: [sfc] A problem with NSH TLV But, for arbitrary octet strings, only an octet oriented length (or the oct= et pad length) would suffice. I feel that type 2 metadata should include = the ability to carry octet strings --_000_D3A9818A55914smajeef5com_ Content-Type: text/html; charset="us-ascii" Content-ID: <37F9A8586B53C74AB518079EB17149DB@F5.com> Content-Transfer-Encoding: quoted-printable
>>But, for = arbitrary octet strings, only an octet oriented length (or the octet pad le= ngth) would suffice.   I feel that type 2 metadata should include= the ability to carry octet strings

Yeah, I agree that it is better= to represent LEN as number of octets. I believe the current LEN is se= t as number of 4 byte/octet because it makes it consistent with the main NSH header length. But I agree that individual TLV len should be represented as number of= octets.  

From: sfc <sfc-bounces@ietf.org> on behalf of Ron Parker <= ;Ron_Parker@affirmednetw= orks.com>
Date: Monday, July 11, 2016 at 1:59= PM
To: "Reinaldo Penno (repenno)&= quot; <repenno@cisco.com>, D= ave Dolson <ddolson@sandvine.com= >, "sfc@ietf.org" <= sfc@ietf.org>
Subject: Re: [sfc] A problem with N= SH TLV

But, for arbitrary octet strings, only an octet oriented length (or the octet p= ad length) would suffice.   I feel that type 2 metadata should in= clude the ability to carry octet strings --_000_D3A9818A55914smajeef5com_-- From nobody Mon Jul 11 21: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 9FCF912D094; Mon, 11 Jul 2016 21:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRKPTwWXb3xP; Mon, 11 Jul 2016 21:10:28 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:a::4]) by ietfa.amsl.com (Postfix) with ESMTP id 081E712B05A; Mon, 11 Jul 2016 21:10:28 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id D984C4E66F; Tue, 12 Jul 2016 13:10:26 +0900 (JST) Received: from [127.0.0.1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTPSA id C8EA03AC83; Tue, 12 Jul 2016 13:10:26 +0900 (JST) References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3501127B-E55B-4FA1-9A63-47D046371132@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62C02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <30650369-47D3-4387-B535-C2B7756B246A@cisco.com> <787AE7BB302AE849A7480A190F8B933008D6310A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <738e733a-8962-cc66-e7e7-1863dd4f6627@joelhalpern.com> To: "sfc@ietf.org" From: Kengo NAITO Message-ID: <6513b6fb-959f-c100-81bc-944744879e40@nttv6.jp> Date: Tue, 12 Jul 2016 13:10:28 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <738e733a-8962-cc66-e7e7-1863dd4f6627@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 12 Jul 2016 04:10:29 -0000 I have sent comments below to authors. I would also like to post to the ML. comments: 1. Why not allow other alternatives? The document, from the introduction part, says too much that you focus on IPFIX. Using IPFIX application ID format is one most valuable way to describe application, however, focusing too much on IPFIX may sometime mislead people. So why not, - first write, "This is a draft to discuss using application identification as a context" - and then write, "There are many alternatives, such as json and other formats to describe application identification" - finally, "the format of IPFIX application ID is one best practice of the metadata format". 2. Concrete use case or "purpose" is needed This is needed to mention what WG want to solve, or what WG want NSH to do. I as a carrier engineer have a justification to carry application identification. There are three points: -L7 identification is now useful in many ways. Visualization of traffic, or co-operation with other functions. - The cost of application identification(say, DPI) is quite high.(traffic handling, and also the cost of DPI equipments) -There are many data centers to place SFs, and chain them. We cannot DPI in every data centers for re-classification or SFForwarding. If we can carry and re-use(or share) app-id information across DCs, it would make good cost reduction. I think that NSH is the best practice to do such things. (Also, use case of traversing several data centers is written in draft-ietf-sfc-dc-use-cases, which is a WG doucment.) 3. Consideration of MD-Type is needed I think that consideration is needed before you say "we use MD-Type1". There may be some case that MD-Type1 is helpful to convey application identification. Good example is as is written in current draft. On the other hand, MD-Type2 may be needed, when the identification format do not fit to 4byte x4 context headers. For example, giving application name as a string or long bit json as a metadata, in result of DPI or other functions. Please let me hear your opinion. Best regards, Kengo On 2016/05/04 1:59, Joel M. Halpern wrote: > I read this document. > The problem / task is clearly useful, so I support having the WG adopt a > document to address it. > The proposed information structure seems a good start, so I support > adoption of this document. > > I think it would be helped by a little bit of text explaining how this > would appear, with what length, in an MD-2 TLV, and what happens if the > inner implicit length and the outer explicit length don't match. > > What is unclear to me is: what is the purpose of the YANG model? > I have no problem with having separate documents defining additional > TLVs. We are clearly going to need them. > But defining a YANG model for each TLV seems really strange. > > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc -- ------------------------------------------------ Kengo NAITO Technology Development NTT Communications Corporation Tel: +81-50-3813-6053 E-mail: k.naito@nttv6.jp ------------------------------------------------ From nobody Tue Jul 12 09:51: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 8DA4112D17B for ; Tue, 12 Jul 2016 09:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 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.287] 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 XRvJNOc5wK8I for ; Tue, 12 Jul 2016 09:51:41 -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 331F912D100 for ; Tue, 12 Jul 2016 09:51:41 -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.195.1; Tue, 12 Jul 2016 12:51:40 -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.0294.000; Tue, 12 Jul 2016 12:51:39 -0400 From: Dave Dolson To: "Reinaldo Penno (repenno)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPw Date: Tue, 12 Jul 2016 16:51:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FF6388wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 12 Jul 2016 16:51:43 -0000 --_000_E8355113905631478EFF04F5AA706E9830FF6388wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. ... I don't see the point of that unless it comes from some legacy. Why waste b= ytes in the information element when length could have been placed in the l= ength field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, "the length gives the number of bytes" ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I'm not aware of any formats in which variable-length string fields are enc= oded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn't like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830FF6388wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Informal survey of th= e binary formats I could think of)

 

---------

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element Fie= ld Length is recorded

   as 65535.  This reserved length value notif= ies the Collecting Process

   that the length value of the Information Element= will be carried in

   the Information Element content itself.

…

I don’t see the = point of that unless it comes from some legacy. Why waste bytes in the info= rmation element when length could have been placed in the length field?

 

----------<= /span>

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary da= ta of variable length.  Unless

      otherwise noted, the AVP Lengt= h field MUST be set to at least 8

      (12 if the 'V' bit is enabled)= .  AVP values of this type that are

      not a multiple of 4 octets in = length are followed by the necessary

      padding so that the next AVP (= if any) will start on a 32-bit

      boundary.

 

---------

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, “the length gi= ves the number of bytes”

 

----------<= /span>

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-length (= counted) opaque data,

   defined as a sequence of n (numbered 0 through n= -1) arbitrary bytes

   to be the number n encoded as an unsigned intege= r (as described

   below), and followed by the n bytes of the seque= nce.

 

   Byte m of the sequence always precedes byte m= 3;1 of the sequence, and

   byte 0 of the sequence always follows the sequen= ce's length (count).

   If n is not a multiple of four, then the n bytes= are followed by

   enough (0 to 3) residual zero bytes, r, to make = the total byte count

   a multiple of four...

 

-------

I’m not aware of= any formats in which variable-length string fields are encoded with number= of words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn’t l= ike to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo= Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@ietf.org
Subject: Re: [sfc] A problem with NSH TLV

 

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_E8355113905631478EFF04F5AA706E9830FF6388wtlexchp2sandvi_-- From nobody Tue Jul 12 09:58: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 EAC2E12D1E6 for ; Tue, 12 Jul 2016 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 KZHD5poHfZlW for ; Tue, 12 Jul 2016 09:58:18 -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 3AE4312D550 for ; Tue, 12 Jul 2016 09:58:18 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 12 Jul 2016 12:58:17 -0400 From: Dave Dolson To: "Haeffner, Walter, Vodafone DE" , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-penno-sfc-packet-03.txt Thread-Index: AQHRoi6oDJmE1p92I0K/S46gKGKcvJ+yWd1ggACRU9CAYoxKUA== Date: Tue, 12 Jul 2016 16:58:16 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] New Version Notification for draft-penno-sfc-packet-03.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: Tue, 12 Jul 2016 16:58:20 -0000 Walter, (Sorry for taking so long to follow up; I somehow missed it.) It seems like your examples are all providing metadata about the user's dev= ice or session, and not about individual traffic flows. I think it's fairly easy to talk about how a service function can add such = metadata to injected packets. I would say those examples are "clonable". Do you see them as being the same for both directions (in/out) of traffic, = or different metadata for inbound vs. outbound traffic? The answer indicates whether they are unidirectional clonable or bidirectio= nal clonable. -Dave -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]=20 Sent: Tuesday, May 10, 2016 8:37 PM To: Dave Dolson; sfc@ietf.org Subject: AW: New Version Notification for draft-penno-sfc-packet-03.txt Section 7: >From a user point of view the md classification sounds very technical and m= ost definitions may not be obvious for people who simply deploy an sfc. Fo= r a specific service these folks expect to have a certain set of static me= tadata and a set of dynamic metadata. Static md may be related to a user, a= service profile etc. That is, md you know in advance. Dynamic md may be re= lated to user location, network conditions, user-selected value added servi= ce identifier etc. These are md which can even change on the fly. Because = of dynamic md a user-related service maps rather onto a sf-graph than a sf-= chain. I can e.g. think about dynamic md which enforce reclassification. Well, i= f I would use a md2-slot from nsh to signal reclassification, I could also = understand "md from reclassification ".=20 BR, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 10. Mai 2016 17:27 An: sfc@ietf.org Betreff: [sfc] FW: New Version Notification for draft-penno-sfc-packet-03.t= xt This was submitted a couple of weeks ago. Features: Section 5.3.2 - a new optimized method of encoding reverse-path information= in metadata that requires only 32 bits. I'm interested to know which approaches people expect to use.=20 (We expect to provide at least the approach of section 5.4.1 as a mode of o= peration.) Section 7 - some fleshing out of the section on injecting metadata, definin= g several types of metadata: - Service-Path-Invariant Metadata - Service-Path-Default Metadata - Bidirectional Clonable Metadata - Unidirectional Clonable Metadata - Service-Function-Mastered Metadata - Metadata from Reclassification I'd like to know if this taxonomy of metadata makes sense to people. -Dave -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, April 29, 2016 11:49 AM To: Eric Wang; Reinaldo Penno; Chui-Tin Yen; Dave Dolson; Carlos Pignataro;= Kent Leung Subject: New Version Notification for draft-penno-sfc-packet-03.txt A new version of I-D, draft-penno-sfc-packet-03.txt has been successfully submitted by Reinaldo Penno and posted to the IETF repository. Name: draft-penno-sfc-packet Revision: 03 Title: Packet Generation in Service Function Chains Document date: 2016-04-29 Group: Individual Submission Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-penno-sfc-packet= -03.txt Status: https://datatracker.ietf.org/doc/draft-penno-sfc-packet/ Htmlized: https://tools.ietf.org/html/draft-penno-sfc-packet-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-packet-= 03 Abstract: Service Functions (e.g., Firewall, NAT, Proxies and Intrusion Prevention Systems) generate packets in the reverse flow direction to the source of the current in-process packet/flow. In this document we discuss and propose how to support this required functionality within the SFC framework. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jul 12 10:04: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 6733812D5A2 for ; Tue, 12 Jul 2016 10:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVOG9yr7t8w4 for ; Tue, 12 Jul 2016 10:04:14 -0700 (PDT) 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 52C7712D5BC for ; Tue, 12 Jul 2016 10:04:09 -0700 (PDT) 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.0266.001; Tue, 12 Jul 2016 10:04:08 -0700 From: Ron Parker To: Dave Dolson , "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAAMEmA= Date: Tue, 12 Jul 2016 17:04:08 +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: [50.205.79.154] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B6D80A45EMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 12 Jul 2016 17:04:17 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D80A45EMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Dave. I agree that length in octets, excluding header, is the right way to go. = This includes your proposed expansion of the length field by 2 bits. I al= so suggest the addition of text regarding padding to 4 octet boundaries wit= h zeroes,and "justification" of small native bytes towards the lower number= ed bytes with padding at the higher numbered bytes. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 12, 2016 12:52 PM To: Reinaldo Penno (repenno) ; Ron Parker ; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. ... I don't see the point of that unless it comes from some legacy. Why waste b= ytes in the information element when length could have been placed in the l= ength field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, "the length gives the number of bytes" ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I'm not aware of any formats in which variable-length string fields are enc= oded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn't like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D80A45EMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Dave.

 

I agree that length in= octets, excluding header, is the right way to go.   This include= s your proposed expansion of the length field by 2 bits.   I also= suggest the addition of text regarding padding to 4 octet boundaries with zeroes,and “justification” of small native byt= es towards the lower numbered bytes with padding at the higher numbered byt= es.

 

   Ron<= /o:p>

 

 

From: Dave Dolson [mailto:ddolson@sandvine.co= m]
Sent: Tuesday, July 12, 2016 12:52 PM
To: Reinaldo Penno (repenno) <repenno@cisco.com>; Ron Parker &= lt;Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

(Informal survey of th= e binary formats I could think of)

 

---------

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element Fie= ld Length is recorded

   as 65535.  This reserved length value notif= ies the Collecting Process

   that the length value of the Information Element= will be carried in

   the Information Element content itself.

…

I don’t see the = point of that unless it comes from some legacy. Why waste bytes in the info= rmation element when length could have been placed in the length field?

 

----------<= /span>

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary da= ta of variable length.  Unless

      otherwise noted, the AVP Lengt= h field MUST be set to at least 8

      (12 if the 'V' bit is enabled)= .  AVP values of this type that are

      not a multiple of 4 octets in = length are followed by the necessary

      padding so that the next AVP (= if any) will start on a 32-bit

      boundary.

 

---------

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, “the length gi= ves the number of bytes”

 

----------<= /span>

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-length (= counted) opaque data,

   defined as a sequence of n (numbered 0 through n= -1) arbitrary bytes

   to be the number n encoded as an unsigned intege= r (as described

   below), and followed by the n bytes of the seque= nce.

 

   Byte m of the sequence always precedes byte m= 3;1 of the sequence, and

   byte 0 of the sequence always follows the sequen= ce's length (count).

   If n is not a multiple of four, then the n bytes= are followed by

   enough (0 to 3) residual zero bytes, r, to make = the total byte count

   a multiple of four...

 

-------

I’m not aware of= any formats in which variable-length string fields are encoded with number= of words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn’t l= ike to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_CDF2F015F4429F458815ED2A6C2B6B0B6D80A45EMBX021W3CA2exch_-- From nobody Tue Jul 12 10:19: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 31A8212D60C for ; Tue, 12 Jul 2016 10:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 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.287] 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 zKyOdxRKw6qq for ; Tue, 12 Jul 2016 10:19:32 -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 232EA12D536 for ; Tue, 12 Jul 2016 10:19:32 -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.195.1; Tue, 12 Jul 2016 13:19: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.0294.000; Tue, 12 Jul 2016 13:19:30 -0400 From: Dave Dolson To: Ron Parker , "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAAMEmCAAAHYIA== Date: Tue, 12 Jul 2016 17:19:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FF662Ewtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 12 Jul 2016 17:19:41 -0000 --_000_E8355113905631478EFF04F5AA706E9830FF662Ewtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed, padding should be at the end of the string. (If I understood correc= tly.) E.g., encoding of octet string{0x31 0xff 0x00 0x21 0x00}: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R| Len=3D5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x31 | 0xff | 0x00 | 0x21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | X | X | X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X means "don't care". We could say "should be 0" From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, July 12, 2016 1:04 PM To: Dave Dolson; Reinaldo Penno (repenno); sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV Hi, Dave. I agree that length in octets, excluding header, is the right way to go. = This includes your proposed expansion of the length field by 2 bits. I al= so suggest the addition of text regarding padding to 4 octet boundaries wit= h zeroes,and "justification" of small native bytes towards the lower number= ed bytes with padding at the higher numbered bytes. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 12, 2016 12:52 PM To: Reinaldo Penno (repenno) >;= Ron Parker >; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. ... I don't see the point of that unless it comes from some legacy. Why waste b= ytes in the information element when length could have been placed in the l= ength field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, "the length gives the number of bytes" ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I'm not aware of any formats in which variable-length string fields are enc= oded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn't like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830FF662Ewtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed, padding should= be at the end of the string. (If I understood correctly.)

 

E.g., encoding of octe= t string{0x31 0xff 0x00 0x21 0x00}:

 

 

      0    &n= bsp;            = ;  1           =         2     &= nbsp;           &nbs= p; 3

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

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |    &n= bsp;     TLV Class      &= nbsp;     |C|    Type   &= nbsp; |R|    Len=3D5    |

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |    0x31&nb= sp;      |   0xff    = ;    |    0x00     &= nbsp; |    0x21       |

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |    0x00&nb= sp;      |      X &n= bsp;      |      &nb= sp; X      |       X=        |

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

 

X means “donR= 17;t care”. We could say “should be 0”<= /p>

 

 

 

From: Ron Park= er [mailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, July 12, 2016 1:04 PM
To: Dave Dolson; Reinaldo Penno (repenno); sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

Hi, Dave.

 

I agree that length in= octets, excluding header, is the right way to go.   This include= s your proposed expansion of the length field by 2 bits.   I also= suggest the addition of text regarding padding to 4 octet boundaries with zeroes,and “justification” of small native byt= es towards the lower numbered bytes with padding at the higher numbered byt= es.

 

   Ron<= /o:p>

 

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Tuesday, July 12, 2016 12:52 PM
To: Reinaldo Penno (repenno) <repenno@cisco.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

(Informal survey of th= e binary formats I could think of)

 

---------

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element Fie= ld Length is recorded

   as 65535.  This reserved length value notif= ies the Collecting Process

   that the length value of the Information Element= will be carried in

   the Information Element content itself.

…

I don’t see the = point of that unless it comes from some legacy. Why waste bytes in the info= rmation element when length could have been placed in the length field?

 

----------<= /span>

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary da= ta of variable length.  Unless

      otherwise noted, the AVP Lengt= h field MUST be set to at least 8

      (12 if the 'V' bit is enabled)= .  AVP values of this type that are

      not a multiple of 4 octets in = length are followed by the necessary

      padding so that the next AVP (= if any) will start on a 32-bit

      boundary.

 

---------

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, “the length gi= ves the number of bytes”

 

----------<= /span>

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-length (= counted) opaque data,

   defined as a sequence of n (numbered 0 through n= -1) arbitrary bytes

   to be the number n encoded as an unsigned intege= r (as described

   below), and followed by the n bytes of the seque= nce.

 

   Byte m of the sequence always precedes byte m= 3;1 of the sequence, and

   byte 0 of the sequence always follows the sequen= ce's length (count).

   If n is not a multiple of four, then the n bytes= are followed by

   enough (0 to 3) residual zero bytes, r, to make = the total byte count

   a multiple of four...

 

-------

I’m not aware of= any formats in which variable-length string fields are encoded with number= of words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn’t l= ike to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo= Penno (repenno) [mailto:repenno@cisco= .com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_E8355113905631478EFF04F5AA706E9830FF662Ewtlexchp2sandvi_-- From nobody Tue Jul 12 23:09: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 49CC012B01D for ; Tue, 12 Jul 2016 23:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 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.287, 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 y9aqRTsizuaG for ; Tue, 12 Jul 2016 23:09:35 -0700 (PDT) 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 DBF47126579 for ; Tue, 12 Jul 2016 23:09:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNP07998; Wed, 13 Jul 2016 06:09:32 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 13 Jul 2016 07:09:32 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 13 Jul 2016 14:09:23 +0800 From: Youjianjie To: "sfc@ietf.org" Thread-Topic: Legacy SF Thread-Index: AdHczRmAyl5Qh16/SWyKukFcQVIMcg== Date: Wed, 13 Jul 2016 06:09:22 +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.136.78.148] 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.5785DB1D.0070, 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: 2c66b9f9dc239be41d5ace123d360b33 Archived-At: Subject: [sfc] Legacy SF X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 06:09:37 -0000 Dear all, This document provides a mechanism between an SFC proxy and an SFC-unaware = service function (herein termed "legacy SF"), to identify the SFC header as= sociated with a packet that is returned from a legacy SF, without an SFC he= ader being explicitly carried in the wired protocol between SFC proxy and l= egacy SF. The motivation for supporting legacy SF is that existing service functions = don't need to be upgraded to support SFC, removing one barrier to wide adop= tion of SFC. https://tools.ietf.org/html/draft-song-sfc-legacy-sf-mapping-07=20 Your comments and suggestions are welcome! Regards, Jianjie From nobody Wed Jul 13 06:35: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 F2DB112D7DD for ; Wed, 13 Jul 2016 06:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKdrSGkN4IAx for ; Wed, 13 Jul 2016 06:35:39 -0700 (PDT) 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 9DDEF12D7C9 for ; Wed, 13 Jul 2016 06:35:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 874DA640506; Wed, 13 Jul 2016 06:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1468416939; bh=4fQr8gPKYfFqWWvdn+qgEfRdymVdqGNXRPNKT3RCJeI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NVpjZ6tLVpMgTyMV2iFbamlwIfc5EpXMWoNfdSMtvoJXrb6CNAMFmR0vlA+c3962s edpvWDBGYPJqM5CQ+oqVAOJeMB/A61WjM1FLhwku3K8HyE6GAQwb+261NvqugKPEKw n53T99GvXima/2ZZk6PDposDDtVP4LF1618ddam4= 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 227E0640032; Wed, 13 Jul 2016 06:35:39 -0700 (PDT) To: Youjianjie , "sfc@ietf.org" References: From: "Joel M. Halpern" Message-ID: <5b3015ba-5bc5-2ef2-6999-65d6e3aaf017@joelhalpern.com> Date: Wed, 13 Jul 2016 09:35:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Legacy SF X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 13:35:41 -0000 I would describe the document you have provided somewhat differently. It seems to be a survey of some of the known methods for building and operating a legacy SF Proxy. There is no question that deployments will need such proxies. The architecture identifies them for that reason. What is unclear to me is whether such a survey is helpful to future implementors. It may be. On the other hand, the choice of technique depends very heavily on the behavior of the legacy SF to be supported. Yours, Joel On 7/13/16 2:09 AM, Youjianjie wrote: > Dear all, > > This document provides a mechanism between an SFC proxy and an SFC-unaware service function (herein termed "legacy SF"), to identify the SFC header associated with a packet that is returned from a legacy SF, without an SFC header being explicitly carried in the wired protocol between SFC proxy and legacy SF. > > The motivation for supporting legacy SF is that existing service functions don't need to be upgraded to support SFC, removing one barrier to wide adoption of SFC. > https://tools.ietf.org/html/draft-song-sfc-legacy-sf-mapping-07 > > Your comments and suggestions are welcome! > > Regards, > Jianjie > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 13 06:45: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 CF30712D106 for ; Wed, 13 Jul 2016 06:44:58 -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 5NcQEwWsTvqe for ; Wed, 13 Jul 2016 06:44: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 D4A7012D142 for ; Wed, 13 Jul 2016 06:44:51 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 4056C3B40D8; Wed, 13 Jul 2016 15:44:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1B6FC23806E; Wed, 13 Jul 2016 15:44:50 +0200 (CEST) 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.0301.000; Wed, 13 Jul 2016 15:44:49 +0200 From: To: Dave Dolson , "Reinaldo Penno (repenno)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAFk/OA= Date: Wed, 13 Jul 2016 13:44:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DE6825@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008DE6825OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.13.124518 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 13:44:59 -0000 --_000_787AE7BB302AE849A7480A190F8B933008DE6825OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, I agree with your proposal: "length field is the number of octets of the da= ta". FWIW, this is one of the pending issues raised during the WGLC (see: https:= //www.ietf.org/mail-archive/web/sfc/current/msg04522.html). For the record, Stewart and Azhar raised a point whether 256 bytes is suffi= cient. If there is really a need to define large context elements, I sugges= ted an idea that is close to the TCP scaling window: use one of the reserve= d bits to shift the length by a number that the WG will agrees on (scale fa= ctor bit). Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : mardi 12 juillet 2016 18:52 =C0 : Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Objet : Re: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. ... I don't see the point of that unless it comes from some legacy. Why waste b= ytes in the information element when length could have been placed in the l= ength field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, "the length gives the number of bytes" ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I'm not aware of any formats in which variable-length string fields are enc= oded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn't like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_787AE7BB302AE849A7480A190F8B933008DE6825OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

I agree with your proposal: = 220;length field is the= number of octets of the data”.

 

FWIW, this is one of the pe=
nding issues raised during the WGLC (see: https://www.ietf.org/mail-archiv=
e/web/sfc/current/msg04522.html). 
 

For the record, Stewart and=
 Azhar raised a point whether 256 bytes is sufficient. If there is really a need to define large context elements, I sugge=
sted an idea that is close to the TCP scaling window: use one of the reserv=
ed bits to shift the length by a number that the WG will agrees on (scale f=
actor bit).


 


Cheers,


Med



 








De : sfc [mailto:sfc-bounces@ietf.org]
De la part de Dave Dolson

Envoy=E9 : mardi 12 juillet 2016 18:52

=C0 : Reinaldo Penno (repenno); Ron Parker; =
sfc@ietf.org

Objet : Re: [sfc] A problem with NSH TLV






 


(Inform=
al survey of the binary formats I could think of)


&n=
bsp;


-------=
--


IPFix u=
ses Field Length of octets for the Field Specifier, but also made a bit of =
a mess of variable-length fields, IMO:


https://tools.ietf.org/h=
tml/rfc7011#section-7


&n=
bsp;


   In the Template Set, the Informat=
ion Element Field Length is recorded


   as 65535.  This reserved len=
gth value notifies the Collecting Process


   that the length value of the Info=
rmation Element will be carried in


   the Information Element content i=
tself.


…=



I don&#=
8217;t see the point of that unless it comes from some legacy. Why waste by=
tes in the information element when length could have been placed in the le=
ngth field?


&n=
bsp;


-------=
---


Diamete=
r (RFC 6733) AVPs have a length field in octets that includes the AVP heade=
r. Note the format requires padding if the length is not a multiple of 4.


&n=
bsp;


   OctetString


 


      The data contai=
ns arbitrary data of variable length.  Unless


      otherwise noted=
, the AVP Length field MUST be set to at least 8


      (12 if the 'V' =
bit is enabled).  AVP values of this type that are

      not a multiple =
of 4 octets in length are followed by the necessary


      padding so that=
 the next AVP (if any) will start on a 32-bit


      boundary.<=
/o:p>


&n=
bsp;


-------=
--


CBOR (<=
a href=3D"https://tools.ietf.org/html/rfc7049#section-2.1">https://tools.ie=
tf.org/html/rfc7049#section-2.1) - for Major type 3 -text string, ̶=
0;the length gives the number of bytes”


&n=
bsp;


-------=
---


ASN.1 -=
 although there are different ways of encoding the length, the value of len=
gth field indicates number of octets.


&n=
bsp;


-------=
-


XDR - <=
a href=3D"https://tools.ietf.org/html/rfc4506#section-4.10">
https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by=
tes, with padding to multiple of 4:


 


4.10.  Variable-Length Opaque Data


 


   The standard also provides for va=
riable-length (counted) opaque data,


   defined as a sequence of n (numbe=
red 0 through n-1) arbitrary bytes


   to be the number n encoded as an =
unsigned integer (as described


   below), and followed by the n byt=
es of the sequence.


 


   Byte m of the sequence always pre=
cedes byte m+1 of the sequence, and


   byte 0 of the sequence always fol=
lows the sequence's length (count).


   If n is not a multiple of four, t=
hen the n bytes are followed by


   enough (0 to 3) residual zero byt=
es, r, to make the total byte count


   a multiple of four...<=
/span>


&n=
bsp;


-------=



I’=
;m not aware of any formats in which variable-length string fields are enco=
ded with number of words vs. number of octets.


&n=
bsp;


I recom=
mend the length field is the number of octets of the data (not including th=
e header), with 0 as a valid value representing the empty string.


Some im=
plementers may prefer to have padding to 4-byte alignment.


&n=
bsp;


But I w=
ouldn’t like to see the IPFix approach.


&n=
bsp;


-Dave


&n=
bsp;


&n=
bsp;






From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]


Sent: Monday, July 11, 2016 8:05 PM

To: Dave Dolson; Ron Parker; sfc@iet=
f.org

Subject: Re: [sfc] A problem with NSH TLV






 




This is not really a new problem and hopefully we can leverage wide=
ly used solutions.  IPfix for example also relies on TLVs and has enco=
dings for octets strings, binary and all other
 formats known to man.   






 






From: =
sfc <sfc-bounces@ietf.org> on behalf of Dave D=
olson <ddolson@sandvine.com&=
gt;

Date: Monday, July 11, 2016 at 5:15 PM

To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o=
rg>

Subject: Re: [sfc] A problem with NSH TLV






 








Ron,


I agree=
 your solution to use bits 25-26 to indicate padding would be backwards com=
patible if anyone is concerned about backwards compatibility.


I’=
;d be OK with that.<=
/o:p>


 <=
/span>


-Dave


 <=
/span>


 <=
/span>



 


Hi, Dav=
e.


 <=
/span>


I agree=
 that valid length must be indicated even when not a multiple of 4 octets a=
nd agree with your solution.   A description of alignment within =
the 4 octets should be part of the text, as well
 – fields whose lengths are not multiples of 4 are “left justif=
ied” towards the lower octet numbers with zero-value padding inserted=
 at the higher octet numbers.


 <=
/span>


Do you =
think this is justification to bump the version number of the NSH, since im=
plementations are already fielded?    In v0, the length is i=
nterpreted as a 5-bit count of 4-octet units.   In v1,
 the length is interpreted as a 7-bit count of octets.    


 <=
/span>


If the =
community is opposed to bumping the version, another approach would be to u=
se bits 25 and 26 as a pad-length field.  Bits 27-31 would continue to=
 be length in 4-octet units, but 25 and 26
 specify how many of the bytes at the highest octet numbers are considered =
to be pad bytes (values 0..3).


 <=
/span>


 &=
nbsp; Ron


 <=
/span>


 






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

Sent: Monday, July 11, 2016 3:01 PM

To: sfc@ietf.org

Subject: [sfc] A problem with NSH TLV






 


As specif=
ied in 
https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1


 


This is t=
he TLV format:


        0&nbs=
p;            &=
nbsp;     1       &n=
bsp;           2 &nb=
sp;            =
     3


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


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+


       | &nbs=
p;        Metadata Class  &nbs=
p;    |C|    Type     |R|=
R|R|   Len   |


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+


       | &nbs=
p;            &=
nbsp;       Variable Metadata  &nbs=
p;            &=
nbsp;        |


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+


 


Len is de=
fined as number of 4-byte words.


The probl=
em with this is that strings aren’t always multiples of 4 bytes in le=
ngth.


 


E.g., in =

https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is=
 given:


 


 &nb=
sp; 10.  Universal Resource Identifier (URI)


 


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


      |  &nbs=
p;      TLV Class =3D 0x0    &=
nbsp;  |C|    Type=3D0xA |R|R|R|   L=3Dvar |<=
/span>


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


      |UT(4)  |&nb=
sp;            =
   URI          =
;            &n=
bsp;            &nbs=
p;|


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


      ~  &nbs=
p;            &=
nbsp;        URI    =
            &nb=
sp;            =
       ~


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


 


Despite t=
he confusing part about the first nybble being used for UT field (supposed =
to be an octet?),



if the UR=
I is not a multiple of 4 bytes, how is it to be terminated?


 


Diameter =
(RFC6733) solves this problem nicely by making the length indicate a number=
 of octets, while specifying padding to 4-octet alignment for the next elem=
ent.


 


So my pro=
posal is to recruit two of the ‘R’ bits into the ‘L’=
; field, and have it indicate number of octets; and also say that padding i=
s to be inserted so that each TLV is a multiple of 4 octets in
 length.


 


 


 


David Dol=
son


Senior So=
ftware Architect, Sandvine Inc.


 
--_000_787AE7BB302AE849A7480A190F8B933008DE6825OPEXCLILMA3corp_-- From nobody Wed Jul 13 07:57: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 8751712DA28 for ; Wed, 13 Jul 2016 07:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 APYtLBIbu6r1 for ; Wed, 13 Jul 2016 07:57:23 -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 ADE1212DA13 for ; Wed, 13 Jul 2016 07:57:22 -0700 (PDT) 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.0195.001; Wed, 13 Jul 2016 10:57:21 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "Reinaldo Penno (repenno)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAFk/OCAABWkoA== Date: Wed, 13 Jul 2016 14:57:20 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008DE6825@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DE6825@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.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FF9EE7wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 14:57:26 -0000 --_000_E8355113905631478EFF04F5AA706E9830FF9EE7wtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I assume you mean 255 (not 256) would be the limit. For data that is added to packets that might already be 1500 bytes in size,= this would seem to be a sensible limit. What use-case would require larger? From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, July 13, 2016 9:45 AM To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV Hi Dave, I agree with your proposal: "length field is the number of octets of the da= ta". FWIW, this is one of the pending issues raised during the WGLC (see: https:= //www.ietf.org/mail-archive/web/sfc/current/msg04522.html). For the record, Stewart and Azhar raised a point whether 256 bytes is suffi= cient. If there is really a need to define large context elements, I sugges= ted an idea that is close to the TCP scaling window: use one of the reserve= d bits to shift the length by a number that the WG will agrees on (scale fa= ctor bit). Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : mardi 12 juillet 2016 18:52 =C0 : Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Objet : Re: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. ... I don't see the point of that unless it comes from some legacy. Why waste b= ytes in the information element when length could have been placed in the l= ength field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, "the length gives the number of bytes" ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I'm not aware of any formats in which variable-length string fields are enc= oded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn't like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830FF9EE7wtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I assume you mean 255 = (not 256) would be the limit.

For data that is added= to packets that might already be 1500 bytes in size, this would seem to be= a sensible limit.

What use-case would re= quire larger?

 

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, July 13, 2016 9:45 AM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org<= br> Subject: RE: [sfc] A problem with NSH TLV

 

Hi Dave,

 

I agree with your proposal: “length field is the number of octets of the data&= #8221;.

 

FWIW, this is one of the pending issues ra=
ised during the WGLC (see: https://www.ietf.org/mail-archive/web/sfc/curre=
nt/msg04522.html). 
 
For the record, Stewart and Azhar raised a=
 point whether 256 bytes is sufficient. If there is really a need to=
 define large context elements, I suggested an idea that is close to the TC=
P scaling window: use one of the reserved bits to shift the length by a num=
ber that the WG will agrees on (scale factor bit).

 

Cheers,

Med

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson
Envoy=E9 : mardi 12 juillet 2016 18:52
=C0 : Reinaldo Penno (repenno); = Ron Parker; sfc@ietf.org
Objet : Re: [sfc] A problem with NSH TLV

 

(Informal survey of th= e binary formats I could think of)

 

---------

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element Fie= ld Length is recorded

   as 65535.  This reserved length value notif= ies the Collecting Process

   that the length value of the Information Element= will be carried in

   the Information Element content itself.

…

I don’t see the = point of that unless it comes from some legacy. Why waste bytes in the info= rmation element when length could have been placed in the length field?

 

----------<= /span>

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary da= ta of variable length.  Unless

      otherwise noted, the AVP Lengt= h field MUST be set to at least 8

      (12 if the 'V' bit is enabled)= .  AVP values of this type that are

      not a multiple of 4 octets in = length are followed by the necessary

      padding so that the next AVP (= if any) will start on a 32-bit

      boundary.

 

---------

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, “the length gi= ves the number of bytes”

 

----------<= /span>

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-length (= counted) opaque data,

   defined as a sequence of n (numbered 0 through n= -1) arbitrary bytes

   to be the number n encoded as an unsigned intege= r (as described

   below), and followed by the n bytes of the seque= nce.

 

   Byte m of the sequence always precedes byte m= 3;1 of the sequence, and

   byte 0 of the sequence always follows the sequen= ce's length (count).

   If n is not a multiple of four, then the n bytes= are followed by

   enough (0 to 3) residual zero bytes, r, to make = the total byte count

   a multiple of four...

 

-------

I’m not aware of= any formats in which variable-length string fields are encoded with number= of words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn’t l= ike to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo= Penno (repenno) [mailto:repenno@cisco= .com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_E8355113905631478EFF04F5AA706E9830FF9EE7wtlexchp2sandvi_-- From nobody Wed Jul 13 08:10: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 425FB12D105 for ; Wed, 13 Jul 2016 08:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF3czPniuY_l for ; Wed, 13 Jul 2016 08:09:59 -0700 (PDT) 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 9508412D19F for ; Wed, 13 Jul 2016 08:09:59 -0700 (PDT) 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.0266.001; Wed, 13 Jul 2016 08:09:58 -0700 From: Ron Parker To: Dave Dolson , "mohamed.boucadair@orange.com" , "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAFk/OCAABWkoIAABGQg Date: Wed, 13 Jul 2016 15:09:58 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008DE6825@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.205.79.154] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B6D80AFC7MBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 15:10:06 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D80AFC7MBX021W3CA2exch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree. We are talking about "inband" augmentation of packets and not "o= ut-of-band" reporting. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Wednesday, July 13, 2016 10:57 AM To: mohamed.boucadair@orange.com; Reinaldo Penno (repenno) ; Ron Parker ; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV I assume you mean 255 (not 256) would be the limit. For data that is added to packets that might already be 1500 bytes in size,= this would seem to be a sensible limit. What use-case would require larger? From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, July 13, 2016 9:45 AM To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV Hi Dave, I agree with your proposal: "length field is the number of octets of the da= ta". FWIW, this is one of the pending issues raised during the WGLC (see: https:= //www.ietf.org/mail-archive/web/sfc/current/msg04522.html). For the record, Stewart and Azhar raised a point whether 256 bytes is suffi= cient. If there is really a need to define large context elements, I sugges= ted an idea that is close to the TCP scaling window: use one of the reserve= d bits to shift the length by a number that the WG will agrees on (scale fa= ctor bit). Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : mardi 12 juillet 2016 18:52 =C0 : Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Objet : Re: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. ... I don't see the point of that unless it comes from some legacy. Why waste b= ytes in the information element when length could have been placed in the l= ength field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, "the length gives the number of bytes" ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I'm not aware of any formats in which variable-length string fields are enc= oded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn't like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D80AFC7MBX021W3CA2exch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree.   W= e are talking about “inband” augmentation of packets and not &#= 8220;out-of-band” reporting.

 

   Ron<= /o:p>

 

From: Dave Dolson [mailto:ddolson@sandvine.co= m]
Sent: Wednesday, July 13, 2016 10:57 AM
To: mohamed.boucadair@orange.com; Reinaldo Penno (repenno) <repen= no@cisco.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@i= etf.org
Subject: RE: [sfc] A problem with NSH TLV

 

I assume you mean 255 = (not 256) would be the limit.

For data that is added= to packets that might already be 1500 bytes in size, this would seem to be= a sensible limit.

What use-case would re= quire larger?

 

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, July 13, 2016 9:45 AM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

Hi Dave,

 

I agree with your proposal: “length field is the number of octets of the data&= #8221;.

 

FWIW, this is one of the pending issues ra=
ised during the WGLC (see: https://www.ietf.org/mail-archive/web/sfc/curre=
nt/msg04522.html). 
 
For the record, Stewart and Azhar raised a=
 point whether 256 bytes is sufficient. If there is really a need to=
 define large context elements, I suggested an idea that is close to the TC=
P scaling window: use one of the reserved bits to shift the length by a num=
ber that the WG will agrees on (scale factor bit).

 

Cheers,

Med

 

De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson
Envoy=E9 : mardi 12 juillet 2016 18:52
=C0 : Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org
Objet : Re: [sfc] A problem with NSH TLV

 

(Informal survey of th= e binary formats I could think of)

 

---------<= /o:p>

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element Fie= ld Length is recorded

   as 65535.  This reserved length value notif= ies the Collecting Process

   that the length value of the Information Element= will be carried in

   the Information Element content itself.

…

I don’t see the = point of that unless it comes from some legacy. Why waste bytes in the info= rmation element when length could have been placed in the length field?

 

----------=

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary da= ta of variable length.  Unless

      otherwise noted, the AVP Lengt= h field MUST be set to at least 8

      (12 if the 'V' bit is enabled)= .  AVP values of this type that are

      not a multiple of 4 octets in = length are followed by the necessary

      padding so that the next AVP (= if any) will start on a 32-bit

      boundary.

 

---------<= /o:p>

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, “the length gi= ves the number of bytes”

 

----------=

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-length (= counted) opaque data,

   defined as a sequence of n (numbered 0 through n= -1) arbitrary bytes

   to be the number n encoded as an unsigned intege= r (as described

   below), and followed by the n bytes of the seque= nce.

 

   Byte m of the sequence always precedes byte m= 3;1 of the sequence, and

   byte 0 of the sequence always follows the sequen= ce's length (count).

   If n is not a multiple of four, then the n bytes= are followed by

   enough (0 to 3) residual zero bytes, r, to make = the total byte count

   a multiple of four...

 

-------

I’m not aware of= any formats in which variable-length string fields are encoded with number= of words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn’t l= ike to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   

 <= /span>

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

 <= /span>

Ron,=

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.<= /o:p>

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    <= /o:p>

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1<= o:p>

 =

This is the TLV format:<= /span>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |=

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson=

Senior Software Architec= t, Sandvine Inc.

 =

--_000_CDF2F015F4429F458815ED2A6C2B6B0B6D80AFC7MBX021W3CA2exch_-- From nobody Wed Jul 13 08:12: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 2682012D859 for ; Wed, 13 Jul 2016 08:12:38 -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 zlQhQ29awYkm for ; Wed, 13 Jul 2016 08:12:35 -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 81D2412D105 for ; Wed, 13 Jul 2016 08:12:34 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3598726437D; Wed, 13 Jul 2016 17:12:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 08E6335C174; Wed, 13 Jul 2016 17:12:33 +0200 (CEST) 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.0301.000; Wed, 13 Jul 2016 17:12:32 +0200 From: To: Dave Dolson , "Reinaldo Penno (repenno)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAFk/OCAABWkoIAAA3EA Date: Wed, 13 Jul 2016 15:12:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DE6919@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008DE6825@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_787AE7BB302AE849A7480A190F8B933008DE6919OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.13.142418 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 15:12:38 -0000 --_000_787AE7BB302AE849A7480A190F8B933008DE6919OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : mercredi 13 juillet 2016 16:57 =C0 : BOUCADAIR Mohamed IMT/OLN; Reinaldo Penno (repenno); Ron Parker; sfc@= ietf.org Objet : RE: [sfc] A problem with NSH TLV I assume you mean 255 (not 256) would be the limit. [Med] I meant the max is 2^^8 bytes (8 bits to encode the length). For data that is added to packets that might already be 1500 bytes in size,= this would seem to be a sensible limit. What use-case would require larger? [Med] I'm not convinced there is a need for such large elements, but Stewar= t mentioned this case: "So, the question becomes, might you need to use mor= e than 256 bytes in describing why you sent a packet somewhere, and I suspe= ct that you might, for example if you needed to provide the rule set for th= e selection of the packet.". From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, July 13, 2016 9:45 AM To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV Hi Dave, I agree with your proposal: "length field is the number of octets of the da= ta". FWIW, this is one of the pending issues raised during the WGLC (see: https:= //www.ietf.org/mail-archive/web/sfc/current/msg04522.html). For the record, Stewart and Azhar raised a point whether 256 bytes is suffi= cient. If there is really a need to define large context elements, I sugges= ted an idea that is close to the TCP scaling window: use one of the reserve= d bits to shift the length by a number that the WG will agrees on (scale fa= ctor bit). Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : mardi 12 juillet 2016 18:52 =C0 : Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Objet : Re: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. ... I don't see the point of that unless it comes from some legacy. Why waste b= ytes in the information element when length could have been placed in the l= ength field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, "the length gives the number of bytes" ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I'm not aware of any formats in which variable-length string fields are enc= oded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn't like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_787AE7BB302AE849A7480A190F8B933008DE6919OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : mercredi 13 juillet 2016 16:57
=C0 : BOUCADAIR Mohamed IMT/OLN; Reinaldo Penno (repenno); Ron = Parker; sfc@ietf.org
Objet : RE: [sfc] A problem with NSH TLV

 

I assum= e you mean 255 (not 256) would be the limit.

[Med] I meant the max is 2^^8 b= ytes (8 bits to encode the length).

For dat= a that is added to packets that might already be 1500 bytes in size, this w= ould seem to be a sensible limit.

 

What us= e-case would require larger?<= /p>

[Med] I’m not convinced t= here is a need for such large elements, but Stewart mentioned this case: &#= 8220;So, the question becomes, might you need to use more than 256 bytes in describ= ing why you sent a packet somewhere, and I suspect that you might, for exam= ple if you needed to provide the rule set for the selection of the packet.<= /span>”.

 <= /span>

 <= /span>

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, July 13, 2016 9:45 AM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

Hi Dave,

 <= /span>

I agree with your proposal: = 220;length field is the= number of octets of the data”.

 

FWIW, this is one of the pending issues raised du=
ring the WGLC (see: https://www.ietf.org/mail-archive/web/sfc/current/msg0=
4522.html). 
 
For the record, Stewart and Azhar raised a point =
whether 256 bytes is sufficient. If there is really a need =
to define large context elements, I suggested an idea that is close to the =
TCP scaling window: use one of the reserved bits to shift the length by a n=
umber that the WG will agrees on (scale factor bit).

 


Cheers,


Med



 








De : sfc [mail=
to:sfc-bounces@ietf.org]
De la part de Dave Dolson

Envoy=E9 : mardi 12 juillet 2016 18:52

=C0 : Reinaldo Penno (repenno); Ron Parker;
sfc@ietf.org

Objet : Re: [sfc] A problem with NSH TLV






 


(Inform=
al survey of the binary formats I could think of)


 <=
/span>


-------=
--


IPFix u=
ses Field Length of octets for the Field Specifier, but also made a bit of =
a mess of variable-length fields, IMO:


https://tools.ietf.org/h=
tml/rfc7011#section-7


 <=
/span>


   In the Template Set, the Informat=
ion Element Field Length is recorded=



   as 65535.  This reserved len=
gth value notifies the Collecting Process<=
/o:p>


   that the length value of the Info=
rmation Element will be carried in


   the Information Element content i=
tself.


…=



I don&#=
8217;t see the point of that unless it comes from some legacy. Why waste by=
tes in the information element when length could have been placed in the le=
ngth field?


 <=
/span>


-------=
---


Diamete=
r (RFC 6733) AVPs have a length field in octets that includes the AVP heade=
r. Note the format requires padding if the length is not a multiple of 4.


 <=
/span>


   OctetString


 <=
/span>


      The data contai=
ns arbitrary data of variable length.  Unless


      otherwise noted=
, the AVP Length field MUST be set to at least 8


      (12 if the 'V' =
bit is enabled).  AVP values of this type that are


      not a multiple =
of 4 octets in length are followed by the necessary


      padding so that=
 the next AVP (if any) will start on a 32-bit


      boundary.


 <=
/span>


-------=
--


CBOR (<=
a href=3D"https://tools.ietf.org/html/rfc7049#section-2.1">https://tools.ie=
tf.org/html/rfc7049#section-2.1) - for Major type 3 -text string, ̶=
0;the length gives the number of bytes”


 <=
/span>


-------=
---


ASN.1 -=
 although there are different ways of encoding the length, the value of len=
gth field indicates number of octets.


 <=
/span>


-------=
-


XDR - <=
a href=3D"https://tools.ietf.org/html/rfc4506#section-4.10">
https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by=
tes, with padding to multiple of 4:<=
/span>


 <=
/span>


4.10.  Variable-Length Opaque Data=



 <=
/span>


   The standard also provides for va=
riable-length (counted) opaque data,=



   defined as a sequence of n (numbe=
red 0 through n-1) arbitrary bytes


   to be the number n encoded as an =
unsigned integer (as described


   below), and followed by the n byt=
es of the sequence.


 <=
/span>


   Byte m of the sequence always pre=
cedes byte m+1 of the sequence, and


   byte 0 of the sequence always fol=
lows the sequence's length (count).<=
/span>


   If n is not a multiple of four, t=
hen the n bytes are followed by


   enough (0 to 3) residual zero byt=
es, r, to make the total byte count<=
/span>


   a multiple of four...


 <=
/span>


-------=



I’=
;m not aware of any formats in which variable-length string fields are enco=
ded with number of words vs. number of octets.<=
o:p>


 <=
/span>


I recom=
mend the length field is the number of octets of the data (not including th=
e header), with 0 as a valid value representing the empty string.


Some im=
plementers may prefer to have padding to 4-byte alignment.


 <=
/span>


But I w=
ouldn’t like to see the IPFix approach.


 <=
/span>


-Dave


 <=
/span>


 <=
/span>






From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]


Sent: Monday, July 11, 2016 8:05 PM

To: Dave Dolson; Ron Parker; sfc@iet=
f.org

Subject: Re: [sfc] A problem with NSH TLV






 




This is not really a new problem and hopefully we can leverage wide=
ly used solutions.  IPfix for example also relies on TLVs and has enco=
dings for octets strings, binary and all other
 formats known to man.   <=
/span>






 






From: =
sfc <sfc-bounces@ietf.org> on behalf of Dave D=
olson <ddolson@sandvine.com&=
gt;

Date: Monday, July 11, 2016 at 5:15 PM

To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o=
rg>

Subject: Re: [sfc] A problem with NSH TLV






 








Ron,


I agree=
 your solution to use bits 25-26 to indicate padding would be backwards com=
patible if anyone is concerned about backwards compatibility.


I’=
;d be OK with that.


 <=
/span>


-Dave


 <=
/span>


 <=
/span>



 


Hi, Dav=
e.


 <=
/span>


I agree=
 that valid length must be indicated even when not a multiple of 4 octets a=
nd agree with your solution.   A description of alignment within =
the 4 octets should be part of the text, as well
 – fields whose lengths are not multiples of 4 are “left justif=
ied” towards the lower octet numbers with zero-value padding inserted=
 at the higher octet numbers.=



 <=
/span>


Do you =
think this is justification to bump the version number of the NSH, since im=
plementations are already fielded?    In v0, the length is i=
nterpreted as a 5-bit count of 4-octet units.   In v1,
 the length is interpreted as a 7-bit count of octets.    


 <=
/span>


If the =
community is opposed to bumping the version, another approach would be to u=
se bits 25 and 26 as a pad-length field.  Bits 27-31 would continue to=
 be length in 4-octet units, but 25 and 26
 specify how many of the bytes at the highest octet numbers are considered =
to be pad bytes (values 0..3).


 <=
/span>


 &=
nbsp; Ron


 <=
/span>


 






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

Sent: Monday, July 11, 2016 3:01 PM

To: sfc@ietf.org

Subject: [sfc] A problem with NSH TLV






 


As specif=
ied in 
https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1<=
span lang=3D"EN-US">


 


This is t=
he TLV format:


        0&nbs=
p;            &=
nbsp;     1       &n=
bsp;           2 &nb=
sp;            =
     3

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


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+=



       | &nbs=
p;        Metadata Class  &nbs=
p;    |C|    Type     |R|=
R|R|   Len   |


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+=



       | &nbs=
p;            &=
nbsp;       Variable Metadata  &nbs=
p;            &=
nbsp;        |


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+=



 


Len is de=
fined as number of 4-byte words.


The probl=
em with this is that strings aren’t always multiples of 4 bytes in le=
ngth.


 


E.g., in =

https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is=
 given:


 


 &nb=
sp; 10.  Universal Resource Identifier (URI)


 


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


      |  &nbs=
p;      TLV Class =3D 0x0    &=
nbsp;  |C|    Type=3D0xA |R|R|R|   L=3Dvar |<=
/span>


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


      |UT(4)  |&nb=
sp;            =
   URI          =
;            &n=
bsp;            &nbs=
p;|


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


      ~  &nbs=
p;            &=
nbsp;        URI    =
            &nb=
sp;            =
       ~


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


 


Despite t=
he confusing part about the first nybble being used for UT field (supposed =
to be an octet?),



if the UR=
I is not a multiple of 4 bytes, how is it to be terminated?


 


Diameter =
(RFC6733) solves this problem nicely by making the length indicate a number=
 of octets, while specifying padding to 4-octet alignment for the next elem=
ent.


 


So my pro=
posal is to recruit two of the ‘R’ bits into the ‘L’=
; field, and have it indicate number of octets; and also say that padding i=
s to be inserted so that each TLV is a multiple of 4 octets in
 length.


 


 


 


David Dol=
son


Senior So=
ftware Architect, Sandvine Inc.


 
--_000_787AE7BB302AE849A7480A190F8B933008DE6919OPEXCLILMA3corp_-- From nobody Wed Jul 13 08:36: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 97F6D12D198 for ; Wed, 13 Jul 2016 08:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 nttYinMDjEZJ for ; Wed, 13 Jul 2016 08:36:29 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5ED912D0E2 for ; Wed, 13 Jul 2016 08:36:26 -0700 (PDT) Received: from smtpjc.telefonica.com (localhost6.localdomain6 [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 10B131B86E3; Wed, 13 Jul 2016 17:36:24 +0200 (CEST) Received: from ESTGVMSP104.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP104", Issuer "ESTGVMSP104" (not verified)) by smtpjc.telefonica.com (Postfix) with ESMTPS id E9A981B86B4; Wed, 13 Jul 2016 17:36:23 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.50) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 13 Jul 2016 17:36:23 +0200 Received: from AM4PR0601MB2161.eurprd06.prod.outlook.com (10.167.123.150) by AM4PR0601MB2161.eurprd06.prod.outlook.com (10.167.123.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.4; Wed, 13 Jul 2016 15:36:22 +0000 Received: from AM4PR0601MB2161.eurprd06.prod.outlook.com ([10.167.123.150]) by AM4PR0601MB2161.eurprd06.prod.outlook.com ([10.167.123.150]) with mapi id 15.01.0544.004; Wed, 13 Jul 2016 15:36:21 +0000 From: "Diego R. Lopez" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR14kDWWZtljiaXEKuqE++y3FX46AWiYeA Date: Wed, 13 Jul 2016 15:36:21 +0000 Message-ID: <864F9EF8-9E1B-46B6-867B-E9F8E455F8CA@telefonica.com> References: <60B45C4E-916C-4CE7-B076-34110590BD61@cisco.com> In-Reply-To: <60B45C4E-916C-4CE7-B076-34110590BD61@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [176.94.165.74] x-ms-office365-filtering-correlation-id: 551d1c5c-0b2a-4089-71af-08d3ab33712f x-microsoft-exchange-diagnostics: 1; AM4PR0601MB2161; 6:TPzUmpyTL3/JBySx3oR++KuqXYvJVt/5PuwIFPvl7yPmRF4go86gCQYYfhFnrv8JviYTXLUN1WWSn7d2VlQN8ylg5JTm68qEzmm1t9oMdktEBWy+7K98ZedFPUi+iqy4HaN2q5ppaYSlrtXwaGXF78XmOGXg5C0RALREox1iE7cMvCBnZflm/UNkCj53XD2cbkmoECifM4ksWT80fnYafLoKUB1O1anBZZedLPISnpJo5hLgSDx6RpB1dO74ARS7s84wgZojDJ3lnAUZ6o6EtRe+bTvZtpx8k4skJswQ0d4=; 5:znvppVze96aYH7MbeShuMNLY+DW296WXF0rXii3741wT6PIo7e2kET+Ar9t301DUG+dNNT7fZbIg5fGK3sFVvLSGEgFpIuvhpfOecnoeNfY9zFiTh6uvUouBuJAoVVslOKg9voAVA+QOAzdJ3OPqrw==; 24:L/iKNnyktlSmHWl9WT02+k1WahF3h7I25ykrwMuKa5HJRpEtQaYBMOsHDhTRNrjvrJ/rqh+az6NRHc1poLKyVAaEBF6VgB9enl79gBYMAII=; 7:JUeUQcQPLxi7U+2H9LqInJGh6jTpQr7e/kpm7idByjiXpT2zphTd6i/GcnEFDyvc2ZpwniiVUFi4fDHF+Uaa0FJIumbSlbCO60LqQiGkm0Cg3woP9sixdeZuWBFEFMD93zot1gibNl026ZoXVO52v0sfn7PD1VDRlPH7R7xd9nzcLwzGzafYnuB5BAmrZb1WJaOPIbho27z4COhzPVLNcf9V91hZmv7Gd4g+NqMzFN9SDszxTepI9cWDFig7FinN x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0601MB2161; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM4PR0601MB2161; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0601MB2161; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(252514010)(189002)(377454003)(199003)(24454002)(5002640100001)(3660700001)(66066001)(92566002)(83716003)(101416001)(106116001)(77096005)(122556002)(16236675004)(15975445007)(106356001)(3280700002)(54356999)(19617315012)(76176999)(2950100001)(33656002)(50986999)(82746002)(19580395003)(2900100001)(189998001)(2906002)(230783001)(105586002)(81166006)(36756003)(4326007)(10400500002)(8936002)(102836003)(87936001)(81156014)(586003)(6116002)(8676002)(7736002)(7906003)(3846002)(97736004)(110136002)(68736007)(7846002)(86362001)(19580405001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0601MB2161; H:AM4PR0601MB2161.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_864F9EF89E1B46B6867BE9F8E455F8CAtelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 15:36:21.9417 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0601MB2161 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 15:36:32 -0000 --_000_864F9EF89E1B46B6867BE9F8E455F8CAtelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkhpLA0KDQpSZWdhcmRpbmcgdGhlIElQUiBpc3N1ZSBJIGFtIG5vdCBhd2FyZSBvZiBh bnkgSVBSIHJlbGV2YW50IHRvIHdoYXQgaXMgc3BlY2lmaWVkIGluIGRyYWZ0LWRvbHNvbi1zZmMt aGllcmFyY2hpY2FsDQoNCkJlIGdvb2RlLA0KDQpPbiA2IEp1bCAyMDE2LCBhdCAxNToxOSAsIEpp bSBHdWljaGFyZCAoamd1aWNoYXIpIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFy QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpDb3JyZWN0aW9uLg0KDQpUaGUgdGV4dCBzaG91bGQgcmVh ZCDigJhkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNuKAmSAuLg0KDQpTRkMgQ2hhaXJz DQoNCkZyb206IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnPj4gb24gYmVoYWxmIG9mIEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1h aWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdWx5IDYsIDIwMTYg YXQgOToxNyBBTQ0KVG86ICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbc2ZjXSBDYWxsIGZvciBX RyBhZG9wdGlvbiBvZiBkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wNg0KDQpEZWFyIFdH Og0KDQpUaGlzIGVtYWlsIHNlcnZlcyBhcyBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0 LXBlbm5vLXNmYy1oaWVyYXJjaGljYWwtMDYgYXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9y IGFkb3B0aW9uIHdpbGwgcnVuIGZvciAyIHdlZWtzIGVuZGluZyA3LzI1LzIwMTYuDQoNClBsZWFz ZSBub3RlIHRoYXQgdGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEgbGFzdCBj YWxsIGZvciBjb250ZW50IG9mIHRoZSBkb2N1bWVudC4gQWRvcHRpbmcgYSBXRyBkb2N1bWVudCBz aW1wbHkgbWVhbnMgdGhhdCB0aGUgV0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0IHBh cnRpY3VsYXIgZHJhZnQgZ29pbmcgZm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRvY3VtZW50IGZvciBy ZXNvbHZpbmcgb3BlbiBpc3N1ZXMgYW5kIGRvY3VtZW50aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25z Lg0KDQpQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBmb3Igbm90 LCBhbmQgaWYgbm90IHdoeS4gSXNzdWVzIHlvdSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgZG9jdW1l bnQgaXRzZWxmIGNhbiBhbHNvIGJlIHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNlZCBp biB0aGUgY29udGV4dCBvZiB3aGF0IHNob3VsZCBiZSBjaGFuZ2VkIGluIHRoZSBkb2N1bWVudCBn b2luZyBmb3J3YXJkLCByYXRoZXIgdGhhbiBhIHByZS1jb25kaXRpb24gZm9yIGFkb3B0aW9uLg0K DQpGaW5hbGx5LCBub3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBwb2xsIGZvciBrbm93bGVkZ2Ug b2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgaW4gbGluZSB3aXRoIHRoZSBJ UFIgZGlzY2xvc3VyZSBvYmxpZ2F0aW9ucyBmb3IgV0cgcGFydGljaXBhbnRzIChzZWUgUkZDcyAz OTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLiBJZiB5b3UgYXJlIGxp c3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsICh0 byB0aGUgY2hhaXJzKSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFu dCBJUFIuDQoNClRoYW5rcyENCg0KU0ZDIENoYWlycw0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoN CkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMv ZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbQ0KVGVs OiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZh bWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2 aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVy c29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJp byBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNp w7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFy IHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJl Y2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211 bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBk ZXN0cnVjY2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21p c3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVk IG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3Zl LiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlz dHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9y LCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIg dGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRo ZW4gZGVsZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBl eGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOn w6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8g ZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9y aWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVp dHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXph w6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdl bnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBu b3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRh IGEgc3VhIGRlc3RydWnDp8Ojbw0K --_000_864F9EF89E1B46B6867BE9F8E455F8CAtelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5IaSw8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZGluZyB0aGUgSVBS IGlzc3VlIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsZXZhbnQgdG8gd2hhdCBpcyBzcGVj aWZpZWQgaW4mbmJzcDtkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QmUgZ29vZGUsPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gNiBKdWwgMjAxNiwgYXQgMTU6MTkg LCBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbSIgY2xhc3M9IiI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Q29ycmVjdGlvbi48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSB0 ZXh0IHNob3VsZCByZWFkIOKAmGRyYWZ0LTxiIGNsYXNzPSIiPmRvbHNvbjwvYj4tc2ZjLWhpZXJh cmNoaWNhbC0wNuKAmSAuLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+U0ZDIENoYWlyczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg aWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSIgY2xhc3M9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpOyBmb250LXNpemU6IDEycHQ7IHRleHQtYWxpZ246IGxlZnQ7IGJvcmRlci13aWR0 aDogMXB0IG1lZGl1bSBtZWRpdW07IGJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBwYWRk aW5nOiAzcHQgMGluIDBpbjsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+RnJvbTog PC9zcGFuPnNmYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiBjbGFz cz0iIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKaW0gR3VpY2hh cmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iIGNsYXNzPSIiPmpndWlj aGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiIGNsYXNzPSIiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIEp1bHkgNiwgMjAxNiBh dCA5OjE3IEFNPGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiIGNs YXNzPSIiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgY2xh c3M9IiI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyIgY2xhc3M9IiI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+U3ViamVjdDogPC9zcGFuPltzZmNdIENh bGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENv bnNvbGFzOyBmb250LXNpemU6IDEycHg7IiBjbGFzcz0iIj5EZWFyIFdHOjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7IiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyIgY2xhc3M9IiI+VGhpcyBlbWFp bCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtaGll cmFyY2hpY2FsLTA2IGFzIGEgV0cgZG9jdW1lbnQuIFRoZSBjYWxsIGZvciBhZG9wdGlvbiB3aWxs DQogcnVuIGZvciAyIHdlZWtzIGVuZGluZyA3LzI1LzIwMTYuPC9zcGFuPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7IiBjbGFzcz0i Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IiBjbGFzcz0iIj5QbGVhc2Ugbm90ZSB0aGF0 IHRoaXMgaXMgYSBjYWxsIGZvciBhZG9wdGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29u dGVudCBvZiB0aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5DQogbWVh bnMgdGhhdCB0aGUgV0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0IHBhcnRpY3VsYXIg ZHJhZnQgZ29pbmcgZm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRvY3VtZW50IGZvciByZXNvbHZpbmcg b3BlbiBpc3N1ZXMgYW5kIGRvY3VtZW50aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25zLjwvc3Bhbj48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MnB4OyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7IiBj bGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyIgY2xhc3M9IiI+UGxl YXNlIGluZGljYXRlIHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlm IG5vdCB3aHkuIElzc3VlcyB5b3UgaGF2ZSB3aXRoIHRoZSBjdXJyZW50IGRvY3VtZW50IGl0c2Vs ZiBjYW4NCiBhbHNvIGJlIHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNlZCBpbiB0aGUg Y29udGV4dCBvZiB3aGF0IHNob3VsZCBiZSBjaGFuZ2VkIGluIHRoZSBkb2N1bWVudCBnb2luZyBm b3J3YXJkLCByYXRoZXIgdGhhbiBhIHByZS1jb25kaXRpb24gZm9yIGFkb3B0aW9uLiZuYnNwOzwv c3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMnB4OyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog Q29uc29sYXM7IGZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPkZpbmFsbHksIG5vdyBpcyBhbHNv IGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll cyB0byB0aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQUiBkaXNjbG9zdXJlIG9ibGlnYXRp b25zIGZvciBXRyBwYXJ0aWNpcGFudHMNCiAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg NTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBh dXRob3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCAodG8gdGhlIGNoYWlycykgd2hldGhl ciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZv bnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPlRoYW5rcyE8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IDEycHg7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IiBj bGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IDEy cHg7IiBjbGFzcz0iIj5TRkMgQ2hhaXJzPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj4NCjxkaXYgaWQ9IiIgY2xhc3M9IiI+PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvc3Bhbj48 L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy IGNsYXNzPSIiPg0Kc2ZjIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGFwcGxlLWNv bnRlbnQtZWRpdGVkPSJ0cnVlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNz PSIiPg0KLS08YnIgY2xhc3M9IiI+DQomcXVvdDtFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0 b3IgSW5maWVybm8mcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpEciBEaWVnbyBS LiBMb3BlejxiciBjbGFzcz0iIj4NClRlbGVmb25pY2EgSSYjNDM7RDxiciBjbGFzcz0iIj4NCjxh IGhyZWY9Imh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6LyIgY2xhc3M9IiI+aHR0cDov L3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTxiciBjbGFzcz0iIj4NClRl bDogJm5ic3A7ICZuYnNwOyYjNDM7MzQgOTEzIDEyOSAwNDE8YnIgY2xhc3M9IiI+DQpNb2JpbGU6 ICYjNDM7MzQgNjgyIDA1MSAwOTE8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyPg0K PGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpFc3Rl IG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRl c3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNv bmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRh ZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBx dWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYQ0KIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxn YWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEg ZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3Rl IG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVk aWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7Nu Ljxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Np b24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9u bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJ ZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwNCiBkaXN0 cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0 aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhl biBkZWxldGUgaXQuPGJyPg0KPGJyPg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRp cmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGlu Zm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhj bHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3Nh IHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1 ZSBhDQogbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2Vt IGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHD p8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3Mt bGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEg ZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbzxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_864F9EF89E1B46B6867BE9F8E455F8CAtelefonicacom_-- From nobody Wed Jul 13 10:11: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 1BEB412D15A for ; Wed, 13 Jul 2016 10:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 JQBiy3IV0TE1 for ; Wed, 13 Jul 2016 10:11:51 -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 79C1C12D0EF for ; Wed, 13 Jul 2016 10:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45137; q=dns/txt; s=iport; t=1468429911; x=1469639511; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Lkh2uBE675OOmwrW3LEywejo77BExHPdHPBe8BXNLDM=; b=HSSg24qWfNCDDVd9AcapnN7LChOvWs6UXtZ62uLcmntkDj7J6WP8beDz EYHSbCgyujIgbBipHzwRNHmtWe5zc2V+AECNt/K6H6F5z1v9/ceyem9Oo cFrLHJWzQJOtuz0fNEQCAWwEKLo1ZX1803Fkdfc/4UjIz4xQiSYn/p7Ut g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAgBBdYZX/4QNJK1bgnBOVnwGuGOBe?= =?us-ascii?q?iKCGiWDNwKBLjgUAQEBAQEBAWUnhFwBAQUMDBU6IgIBCA4DAwEBASEBBgcyFAk?= =?us-ascii?q?IAgQBEhQHiBUOwHMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2ETxIWAoUjB?= =?us-ascii?q?YgcX4pjhT4BhhCIRo8vkBYBHjaCBh+BTG4BAYg2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,358,1464652800"; d="scan'208,217";a="297459321" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2016 17:11:50 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6DHBoCF019207 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jul 2016 17:11:50 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, 13 Jul 2016 12:11:49 -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, 13 Jul 2016 12:11:49 -0500 From: "Reinaldo Penno (repenno)" To: Dave Dolson , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAAMEmCAAAHYIIABtN0A Date: Wed, 13 Jul 2016 17:11:48 +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/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.242.226] Content-Type: multipart/alternative; boundary="_000_D3ABFC6327C13repennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 17:11:54 -0000 --_000_D3ABFC6327C13repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I suggest we say it =93must be=94 null character. It will help detect any = parsing problems, buffer overrun attacks, etc. From: Dave Dolson > Date: Tuesday, July 12, 2016 at 2:19 PM To: Ron Parker >, Reinaldo Penno >= , "sfc@ietf.org" > Subject: RE: [sfc] A problem with NSH TLV Agreed, padding should be at the end of the string. (If I understood correc= tly.) E.g., encoding of octet string{0x31 0xff 0x00 0x21 0x00}: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R| Len=3D5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x31 | 0xff | 0x00 | 0x21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | X | X | X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X means =93don=92t care=94. We could say =93should be 0=94 From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, July 12, 2016 1:04 PM To: Dave Dolson; Reinaldo Penno (repenno); sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV Hi, Dave. I agree that length in octets, excluding header, is the right way to go. = This includes your proposed expansion of the length field by 2 bits. I al= so suggest the addition of text regarding padding to 4 octet boundaries wit= h zeroes,and =93justification=94 of small native bytes towards the lower nu= mbered bytes with padding at the higher numbered bytes. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 12, 2016 12:52 PM To: Reinaldo Penno (repenno) >;= Ron Parker >; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. =85 I don=92t see the point of that unless it comes from some legacy. Why waste= bytes in the information element when length could have been placed in the= length field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, =93the length gives the number of bytes=94 ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I=92m not aware of any formats in which variable-length string fields are e= ncoded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn=92t like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I=92d be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well =96 fields whose lengths are = not multiples of 4 are =93left justified=94 towards the lower octet numbers= with zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren=92t always multiples of 4 bytes = in length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the =91R=92 bits into the =91L=92 field= , and have it indicate number of octets; and also say that padding is to be= inserted so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_D3ABFC6327C13repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I suggest we say it =93must be=94 null character.  It will help d= etect any parsing problems, buffer overrun attacks, etc. 

From: Dave Dolson <ddolson@sandvine.com>
Date: Tuesday, July 12, 2016 at 2:1= 9 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>,= Reinaldo Penno <repenno@cisco.com<= /a>>, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] A problem with N= SH TLV

Agreed, padding should= be at the end of the string. (If I understood correctly.)

 

E.g., encoding of octe= t string{0x31 0xff 0x00 0x21 0x00}:

 

 

      0    &n= bsp;            = ;  1           =         2     &= nbsp;           &nbs= p; 3

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

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |    &n= bsp;     TLV Class      &= nbsp;     |C|    Type   &= nbsp; |R|    Len=3D5    |

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |    0x31&nb= sp;      |   0xff    = ;    |    0x00     &= nbsp; |    0x21       |

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |    0x00&nb= sp;      |      X &n= bsp;      |      &nb= sp; X      |       X=        |

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

 

X means =93don=92t car= e=94. We could say =93should be 0=94

 

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, July 12, 2016 1:04 PM
To: Dave Dolson; Reinaldo Penno (repenno); sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

Hi, Dave.

 

I agree that length in= octets, excluding header, is the right way to go.   This include= s your proposed expansion of the length field by 2 bits.   I also= suggest the addition of text regarding padding to 4 octet boundaries with zeroes,and =93justification=94 of small native bytes towar= ds the lower numbered bytes with padding at the higher numbered bytes.=

 

   Ron<= /o:p>

 

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Tuesday, July 12, 2016 12:52 PM
To: Reinaldo Penno (repenno) <repenno@cisco.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

(Informal survey of th= e binary formats I could think of)

 

---------

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element Fie= ld Length is recorded

   as 65535.  This reserved length value notif= ies the Collecting Process

   that the length value of the Information Element= will be carried in

   the Information Element content itself.

=85<= /p>

I don=92t see the poin= t of that unless it comes from some legacy. Why waste bytes in the informat= ion element when length could have been placed in the length field?

 

----------<= /span>

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary da= ta of variable length.  Unless

      otherwise noted, the AVP Lengt= h field MUST be set to at least 8

      (12 if the 'V' bit is enabled)= .  AVP values of this type that are

      not a multiple of 4 octets in = length are followed by the necessary

      padding so that the next AVP (= if any) will start on a 32-bit

      boundary.

 

---------

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, =93the length gives = the number of bytes=94

 

----------<= /span>

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-length (= counted) opaque data,

   defined as a sequence of n (numbered 0 through n= -1) arbitrary bytes

   to be the number n encoded as an unsigned intege= r (as described

   below), and followed by the n bytes of the seque= nce.

 

   Byte m of the sequence always precedes byte m= 3;1 of the sequence, and

   byte 0 of the sequence always follows the sequen= ce's length (count).

   If n is not a multiple of four, then the n bytes= are followed by

   enough (0 to 3) residual zero bytes, r, to make = the total byte count

   a multiple of four...

 

-------

I=92m not aware of any= formats in which variable-length string fields are encoded with number of = words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn=92t like = to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I=92d be OK with that.=

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks= .com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well =96 fields whose lengths are not multiples of 4 are =93left justified=94 towards the lower = octet numbers with zero-value padding inserted at the higher octet numbers.=

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren=92t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the =91R=92 bits into the =91L=92 field, and have it indicate n= umber of octets; and also say that padding is to be inserted so that each T= LV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_D3ABFC6327C13repennociscocom_-- From nobody Wed Jul 13 10:16: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 3B83012D193 for ; Wed, 13 Jul 2016 10:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 c-9qVHv2T4cE for ; Wed, 13 Jul 2016 10:16:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FC612D176 for ; Wed, 13 Jul 2016 10:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53385; q=dns/txt; s=iport; t=1468430189; x=1469639789; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DA8L+kLk/veQQbOhdmq+PyOg3Os0WhnOEeLZyOZW8wE=; b=PiY9Bn48vTWOhg9NpwoOTeQBWxIZkQnEL6WUFelFXV/wGyQFroht5PkL v2cwOar58/66XWYaV6zXFec+E0pyoDT2oXRvkOlRA5whFt/pkqbPnfWYP 0sS8pwo0GhLAMYV9b1nOmAW3iRc/MOjsxUnhWjB2jAyfHc37pUGu4W/gZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAgBKdoZX/49dJa1bgnBOVnwGuGOBe?= =?us-ascii?q?iKCGiWDNwKBLjgUAQEBAQEBAWUnhFwBAQUMDBU6IgIBCBEDAQEBIQEGBzIUCQg?= =?us-ascii?q?CBAESFAeIFQ7AdAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqETYQeBgEBKRIWA?= =?us-ascii?q?oUjBYgcX4pjhT4BhhCIRoFrhFmIa5AWAR42ggYfgUxuAQGHcg4XH38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,358,1464652800"; d="scan'208,217";a="125680944" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2016 17:16:28 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6DHGSJl010583 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jul 2016 17:16:28 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 13 Jul 2016 12:16:27 -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, 13 Jul 2016 12:16:26 -0500 From: "Reinaldo Penno (repenno)" To: "mohamed.boucadair@orange.com" , Dave Dolson , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAFk/OCAABWkoIAAA3EAgABF/wA= Date: Wed, 13 Jul 2016 17:16:26 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008DE6825@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008DE6919@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DE6919@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/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.242.226] Content-Type: multipart/alternative; boundary="_000_D3ABFCE327C85repennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 17:16:32 -0000 --_000_D3ABFCE327C85repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92m with Med that if you need more than 256 then you should switch to an = out of band protocol. I=92m sure somebody might dig up some fringe use-cas= e for more than 256 but at the same time it seems defeating the purpose of = a high-speed, in-band exchange of data. From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Wednesday, July 13, 2016 at 12:12 PM To: Dave Dolson >, Reinal= do Penno >, Ron Parker >, "sfc@iet= f.org" > Subject: RE: [sfc] A problem with NSH TLV Re-, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : mercredi 13 juillet 2016 16:57 =C0 : BOUCADAIR Mohamed IMT/OLN; Reinaldo Penno (repenno); Ron Parker; sfc@= ietf.org Objet : RE: [sfc] A problem with NSH TLV I assume you mean 255 (not 256) would be the limit. [Med] I meant the max is 2^^8 bytes (8 bits to encode the length). For data that is added to packets that might already be 1500 bytes in size,= this would seem to be a sensible limit. What use-case would require larger? [Med] I=92m not convinced there is a need for such large elements, but Stew= art mentioned this case: =93So, the question becomes, might you need to use= more than 256 bytes in describing why you sent a packet somewhere, and I s= uspect that you might, for example if you needed to provide the rule set fo= r the selection of the packet.=94. From:mohamed.boucadair@orange.com [mai= lto:mohamed.boucadair@orange.com] Sent: Wednesday, July 13, 2016 9:45 AM To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV Hi Dave, I agree with your proposal: =93length field is the number of octets of the = data=94. FWIW, this is one of the pending issues raised during the WGLC (see: https:= //www.ietf.org/mail-archive/web/sfc/current/msg04522.html). For the record, Stewart and Azhar raised a point whether 256 bytes is suffi= cient. If there is really a need to define large context elements, I sugges= ted an idea that is close to the TCP scaling window: use one of the reserve= d bits to shift the length by a number that the WG will agrees on (scale fa= ctor bit). Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : mardi 12 juillet 2016 18:52 =C0 : Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Objet : Re: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. =85 I don=92t see the point of that unless it comes from some legacy. Why waste= bytes in the information element when length could have been placed in the= length field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, =93the length gives the number of bytes=94 ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I=92m not aware of any formats in which variable-length string fields are e= ncoded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn=92t like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I=92d be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well =96 fields whose lengths are = not multiples of 4 are =93left justified=94 towards the lower octet numbers= with zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren=92t always multiples of 4 bytes = in length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the =91R=92 bits into the =91L=92 field= , and have it indicate number of octets; and also say that padding is to be= inserted so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_D3ABFCE327C85repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9A4955ABFE54DA48B589C94460480171@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I=92m with Med that if you need more than 256 then you should switch t= o an out of band protocol. I=92m sure somebody might dig up some fringe &nb= sp;use-case for more than 256 but at the same time it seems defeating the p= urpose of a high-speed, in-band exchange of data.  

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;
Date: Wednesday, July 13, 2016 at 1= 2:12 PM
To: Dave Dolson <ddolson@sandvine.com>, Reinaldo Penno <<= a href=3D"mailto:repenno@cisco.com">repenno@cisco.com>, Ron Parker &= lt;Ron_Parker@affirmedne= tworks.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] A problem with N= SH TLV

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dave Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : mercredi 13 juillet 2016 16:57
=C0 : BOUCADAIR Mohamed IMT/OLN; Reinaldo Penno (repenno); Ron = Parker; sfc@ietf.org
Objet : RE: [sfc] A problem with NSH TLV

 

I assum= e you mean 255 (not 256) would be the limit.

[Med] I meant the max is 2^^8 b= ytes (8 bits to encode the length).

For dat= a that is added to packets that might already be 1500 bytes in size, this w= ould seem to be a sensible limit.

 

What us= e-case would require larger?<= /p>

[Med] I=92m not convinced there= is a need for such large elements, but Stewart mentioned this case: =93So, the question becomes, might you need to use more than 256 bytes in describ= ing why you sent a packet somewhere, and I suspect that you might, for exam= ple if you needed to provide the rule set for the selection of the packet.<= /span>=94.

 <= /span>

 <= /span>

From:mohamed.boucadair@orange.com [mailto:mohamed.boucadair@= orange.com]
Sent: Wednesday, July 13, 2016 9:45 AM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

Hi Dave,

 <= /span>

I agree with your proposal: =93= length field is the num= ber of octets of the data=94.

 

FWIW, this is one of the pending issues raised du=
ring the WGLC (see: https://www.ietf.org/mail-archive/web/sfc/current/msg0=
4522.html). 
 
For the record, Stewart and Azhar raised a point =
whether 256 bytes is sufficient. If there is really a need =
to define large context elements, I suggested an idea that is close to the =
TCP scaling window: use one of the reserved bits to shift the length by a n=
umber that the WG will agrees on (scale factor bit).

 


Cheers,


Med



 








De : sfc [mailto:sfc-bounces@ietf.org]
De la part de Dave Dolson

Envoy=E9 : mardi 12 juillet 2016 18:52

=C0 : Reinaldo Penno (repenno); Ron Parker;
sfc@ietf.org

Objet : Re: [sfc] A problem with NSH TLV






 


(Inform=
al survey of the binary formats I could think of)


 <=
/span>


-------=
--


IPFix u=
ses Field Length of octets for the Field Specifier, but also made a bit of =
a mess of variable-length fields, IMO:


https://tools.ietf.org/h=
tml/rfc7011#section-7


 <=
/span>


   In the Template Set, the Informat=
ion Element Field Length is recorded=



   as 65535.  This reserved len=
gth value notifies the Collecting Process<=
/o:p>


   that the length value of the Info=
rmation Element will be carried in


   the Information Element content i=
tself.


=85


I don=
=92t see the point of that unless it comes from some legacy. Why waste byte=
s in the information element when length could have been placed in the leng=
th field?


 <=
/span>


-------=
---


Diamete=
r (RFC 6733) AVPs have a length field in octets that includes the AVP heade=
r. Note the format requires padding if the length is not a multiple of 4.


 <=
/span>


   OctetString


 <=
/span>


      The data contai=
ns arbitrary data of variable length.  Unless


      otherwise noted=
, the AVP Length field MUST be set to at least 8


      (12 if the 'V' =
bit is enabled).  AVP values of this type that are


      not a multiple =
of 4 octets in length are followed by the necessary


      padding so that=
 the next AVP (if any) will start on a 32-bit


      boundary.


 <=
/span>


-------=
--


CBOR (<=
a href=3D"https://tools.ietf.org/html/rfc7049#section-2.1">https://tools.ie=
tf.org/html/rfc7049#section-2.1) - for Major type 3 -text string, =93th=
e length gives the number of bytes=94


 <=
/span>


-------=
---


ASN.1 -=
 although there are different ways of encoding the length, the value of len=
gth field indicates number of octets.


 <=
/span>


-------=
-


XDR - <=
a href=3D"https://tools.ietf.org/html/rfc4506#section-4.10">
https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by=
tes, with padding to multiple of 4:<=
/span>


 <=
/span>


4.10.  Variable-Length Opaque Data=



 <=
/span>


   The standard also provides for va=
riable-length (counted) opaque data,=



   defined as a sequence of n (numbe=
red 0 through n-1) arbitrary bytes


   to be the number n encoded as an =
unsigned integer (as described


   below), and followed by the n byt=
es of the sequence.


 <=
/span>


   Byte m of the sequence always pre=
cedes byte m+1 of the sequence, and


   byte 0 of the sequence always fol=
lows the sequence's length (count).<=
/span>


   If n is not a multiple of four, t=
hen the n bytes are followed by


   enough (0 to 3) residual zero byt=
es, r, to make the total byte count<=
/span>


   a multiple of four...


 <=
/span>


-------=



I=92m n=
ot aware of any formats in which variable-length string fields are encoded =
with number of words vs. number of octets.=



 <=
/span>


I recom=
mend the length field is the number of octets of the data (not including th=
e header), with 0 as a valid value representing the empty string.


Some im=
plementers may prefer to have padding to 4-byte alignment.


 <=
/span>


But I w=
ouldn=92t like to see the IPFix approach.<=
/o:p>


 <=
/span>


-Dave


 <=
/span>


 <=
/span>






From: Reinaldo Penno (rep=
enno) [mailto:repenno@cisco.com]


Sent: Monday, July 11, 2016 8:05 PM

To: Dave Dolson; Ron Parker; sfc@iet=
f.org

Subject: Re: [sfc] A problem with NSH TLV






 




This is not really a new problem and hopefully we can leverage wide=
ly used solutions.  IPfix for example also relies on TLVs and has enco=
dings for octets strings, binary and all other
 formats known to man.   <=
/span>






 






From: =
sfc <sfc-bounces@ietf.org> on behalf of Dave D=
olson <ddolson@sandvine.com&=
gt;

Date: Monday, July 11, 2016 at 5:15 PM

To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o=
rg>

Subject: Re: [sfc] A problem with NSH TLV






 








Ron,


I agree=
 your solution to use bits 25-26 to indicate padding would be backwards com=
patible if anyone is concerned about backwards compatibility.


I=92d b=
e OK with that.


 <=
/span>


-Dave


 <=
/span>


 <=
/span>






From: Ron Parker [mail=
to:Ron_Parker@affirmednetworks.com]


Sent: Monday, July 11, 2016 3:12 PM

To: Dave Dolson; sfc@ietf.org
Subject: RE: A problem with NSH TLV=







 


Hi, Dav=
e.


 <=
/span>


I agree=
 that valid length must be indicated even when not a multiple of 4 octets a=
nd agree with your solution.   A description of alignment within =
the 4 octets should be part of the text, as well
 =96 fields whose lengths are not multiples of 4 are =93left justified=94 t=
owards the lower octet numbers with zero-value padding inserted at the high=
er octet numbers.


 <=
/span>


Do you =
think this is justification to bump the version number of the NSH, since im=
plementations are already fielded?    In v0, the length is i=
nterpreted as a 5-bit count of 4-octet units.   In v1,
 the length is interpreted as a 7-bit count of octets.    


 <=
/span>


If the =
community is opposed to bumping the version, another approach would be to u=
se bits 25 and 26 as a pad-length field.  Bits 27-31 would continue to=
 be length in 4-octet units, but 25 and 26
 specify how many of the bytes at the highest octet numbers are considered =
to be pad bytes (values 0..3).


 <=
/span>


 &=
nbsp; Ron


 <=
/span>


 






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

Sent: Monday, July 11, 2016 3:01 PM

To: sfc@ietf.org

Subject: [sfc] A problem with NSH TLV






 


As specif=
ied in 
https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1<=
span lang=3D"EN-US">


 


This is t=
he TLV format:


        0&nbs=
p;            &=
nbsp;     1       &n=
bsp;           2 &nb=
sp;            =
     3

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


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+=



       | &nbs=
p;        Metadata Class  &nbs=
p;    |C|    Type     |R|=
R|R|   Len   |


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+=



       | &nbs=
p;            &=
nbsp;       Variable Metadata  &nbs=
p;            &=
nbsp;        |


       +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+=



 


Len is de=
fined as number of 4-byte words.


The probl=
em with this is that strings aren=92t always multiples of 4 bytes in length=
.


 


E.g., in =

https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is=
 given:


 


 &nb=
sp; 10.  Universal Resource Identifier (URI)


 


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


      |  &nbs=
p;      TLV Class =3D 0x0    &=
nbsp;  |C|    Type=3D0xA |R|R|R|   L=3Dvar |<=
/span>


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


      |UT(4)  |&nb=
sp;            =
   URI          =
;            &n=
bsp;            &nbs=
p;|


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


      ~  &nbs=
p;            &=
nbsp;        URI    =
            &nb=
sp;            =
       ~


      +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+


 


Despite t=
he confusing part about the first nybble being used for UT field (supposed =
to be an octet?),



if the UR=
I is not a multiple of 4 bytes, how is it to be terminated?


 


Diameter =
(RFC6733) solves this problem nicely by making the length indicate a number=
 of octets, while specifying padding to 4-octet alignment for the next elem=
ent.


 


So my pro=
posal is to recruit two of the =91R=92 bits into the =91L=92 field, and hav=
e it indicate number of octets; and also say that padding is to be inserted=
 so that each TLV is a multiple of 4 octets in
 length.


 


 


 


David Dol=
son


Senior So=
ftware Architect, Sandvine Inc.


 
--_000_D3ABFCE327C85repennociscocom_-- From nobody Wed Jul 13 10:18: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 B3C0312D1A3 for ; Wed, 13 Jul 2016 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 mtrZWVJVAKe2 for ; Wed, 13 Jul 2016 10:18:50 -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 0662512D193 for ; Wed, 13 Jul 2016 10:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39154; q=dns/txt; s=iport; t=1468430329; x=1469639929; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cqSu0/Oe+PZyGx/MqzY1He0o7/iV/iRZZstOWO5f6Ac=; b=Tp3okIEANLIzDQfHHr2TEing0bO3dBiZgn4tLkXW261G+a05yomADjme 10GgE4ZR38/C+/mtGf0BKxP6C0oQ4ommlL2+jVy5Yu74NQeyVg6rMHo8Z /AWVHbObGekCIPRp7vPRI3Yj2JVVPCv1a8RQyF6+QHo7ujgKvB45DIFjL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJBgBud4ZX/4ENJK1bgnBOVnwGuGOBe?= =?us-ascii?q?iKCGiWDNwKBLjkTAQEBAQEBAWUnhFwBAQUMDBU6IgIBCBEDAQEBIQEGBzIUCQg?= =?us-ascii?q?CBAESFAeIFQ7AdQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqETYRPEhYChSMFi?= =?us-ascii?q?BxfimOFPgGGEIJ6hUyPL5AWAR8BNIIGH4FMbgEBiDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,358,1464652800"; d="scan'208,217";a="123408780" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2016 17:18:48 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6DHImA1011809 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jul 2016 17:18:48 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 13 Jul 2016 12:18:47 -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, 13 Jul 2016 12:18:47 -0500 From: "Reinaldo Penno (repenno)" To: Ron Parker , Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAAMEmCAAbijgA== Date: Wed, 13 Jul 2016 17:18:47 +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/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.242.226] Content-Type: multipart/alternative; boundary="_000_D3ABFDC627C90repennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 17:18:53 -0000 --_000_D3ABFDC627C90repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry if this question was answered. But why not just pad everything to 4 b= yte boundaries (binary and strings)? Everything is transmitted in network = order, we should have no problems, right? No? From: sfc > on behalf of = Ron Parker > Date: Tuesday, July 12, 2016 at 2:04 PM To: Dave Dolson >, Reinal= do Penno >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Hi, Dave. I agree that length in octets, excluding header, is the right way to go. = This includes your proposed expansion of the length field by 2 bits. I al= so suggest the addition of text regarding padding to 4 octet boundaries wit= h zeroes,and =93justification=94 of small native bytes towards the lower nu= mbered bytes with padding at the higher numbered bytes. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 12, 2016 12:52 PM To: Reinaldo Penno (repenno) >;= Ron Parker >; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. =85 I don=92t see the point of that unless it comes from some legacy. Why waste= bytes in the information element when length could have been placed in the= length field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, =93the length gives the number of bytes=94 ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I=92m not aware of any formats in which variable-length string fields are e= ncoded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn=92t like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I=92d be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well =96 fields whose lengths are = not multiples of 4 are =93left justified=94 towards the lower octet numbers= with zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren=92t always multiples of 4 bytes = in length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the =91R=92 bits into the =91L=92 field= , and have it indicate number of octets; and also say that padding is to be= inserted so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_D3ABFDC627C90repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <41183842101F7545ABAF73912372FAF8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Sorry if this question was answered. But why not just pad everything t= o 4 byte boundaries (binary and strings)?  Everything is transmitted i= n network order, we should have no problems, right? No?

From: sfc <sfc-bounces@ietf.org> on behalf of Ron Parker <= ;Ron_Parker@affirmednetw= orks.com>
Date: Tuesday, July 12, 2016 at 2:0= 4 PM
To: Dave Dolson <ddolson@sandvine.com>, Reinaldo Penno <<= a href=3D"mailto:repenno@cisco.com">repenno@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] A problem with N= SH TLV

Hi, Dave.

 

I agree that length in= octets, excluding header, is the right way to go.   This include= s your proposed expansion of the length field by 2 bits.   I also= suggest the addition of text regarding padding to 4 octet boundaries with zeroes,and =93justification=94 of small native bytes towar= ds the lower numbered bytes with padding at the higher numbered bytes.=

 

   Ron<= /o:p>

 

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Tuesday, July 12, 2016 12:52 PM
To: Reinaldo Penno (repenno) <repenno@cisco.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 

(Informal survey of th= e binary formats I could think of)

 

---------

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element Fie= ld Length is recorded

   as 65535.  This reserved length value notif= ies the Collecting Process

   that the length value of the Information Element= will be carried in

   the Information Element content itself.

=85<= /p>

I don=92t see the poin= t of that unless it comes from some legacy. Why waste bytes in the informat= ion element when length could have been placed in the length field?

 

----------<= /span>

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary da= ta of variable length.  Unless

      otherwise noted, the AVP Lengt= h field MUST be set to at least 8

      (12 if the 'V' bit is enabled)= .  AVP values of this type that are

      not a multiple of 4 octets in = length are followed by the necessary

      padding so that the next AVP (= if any) will start on a 32-bit

      boundary.

 

---------

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, =93the length gives = the number of bytes=94

 

----------<= /span>

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-length (= counted) opaque data,

   defined as a sequence of n (numbered 0 through n= -1) arbitrary bytes

   to be the number n encoded as an unsigned intege= r (as described

   below), and followed by the n bytes of the seque= nce.

 

   Byte m of the sequence always precedes byte m= 3;1 of the sequence, and

   byte 0 of the sequence always follows the sequen= ce's length (count).

   If n is not a multiple of four, then the n bytes= are followed by

   enough (0 to 3) residual zero bytes, r, to make = the total byte count

   a multiple of four...

 

-------

I=92m not aware of any= formats in which variable-length string fields are encoded with number of = words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn=92t like = to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I=92d be OK with that.=

 

-Dave

 

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well =96 fields whose lengths are not multiples of 4 are =93left justified=94 towards the lower = octet numbers with zero-value padding inserted at the higher octet numbers.=

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren=92t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the =91R=92 bits into the =91L=92 field, and have it indicate n= umber of octets; and also say that padding is to be inserted so that each T= LV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_D3ABFDC627C90repennociscocom_-- From nobody Wed Jul 13 10:20: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 3BD5012D188 for ; Wed, 13 Jul 2016 10:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 CByi5HutDGFJ for ; Wed, 13 Jul 2016 10:20:46 -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 5CEEA12B03C for ; Wed, 13 Jul 2016 10:20:46 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 13 Jul 2016 13:20:45 -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.0294.000; Wed, 13 Jul 2016 13:20:44 -0400 From: Dave Dolson To: "Reinaldo Penno (repenno)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAAMEmCAAAHYIIABtN0A///gD6A= Date: Wed, 13 Jul 2016 17:20:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FFA70Awtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 17:20:49 -0000 --_000_E8355113905631478EFF04F5AA706E9830FFA70Awtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reinaldo, How does that help with buffer overrun attacks? Certainly the receiver should never trust that there is a null at the end. And also, a string that is a multiple of 4 would not need to have a null at= the end. To help against attacks, it might be better to specify, "should be filled w= ith random numbers" so that assumptions in receiving code are caught quickl= y. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Wednesday, July 13, 2016 1:12 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV I suggest we say it "must be" null character. It will help detect any pars= ing problems, buffer overrun attacks, etc. From: Dave Dolson > Date: Tuesday, July 12, 2016 at 2:19 PM To: Ron Parker >, Reinaldo Penno >= , "sfc@ietf.org" > Subject: RE: [sfc] A problem with NSH TLV Agreed, padding should be at the end of the string. (If I understood correc= tly.) E.g., encoding of octet string{0x31 0xff 0x00 0x21 0x00}: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R| Len=3D5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x31 | 0xff | 0x00 | 0x21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | X | X | X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X means "don't care". We could say "should be 0" From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, July 12, 2016 1:04 PM To: Dave Dolson; Reinaldo Penno (repenno); sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV Hi, Dave. I agree that length in octets, excluding header, is the right way to go. = This includes your proposed expansion of the length field by 2 bits. I al= so suggest the addition of text regarding padding to 4 octet boundaries wit= h zeroes,and "justification" of small native bytes towards the lower number= ed bytes with padding at the higher numbered bytes. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 12, 2016 12:52 PM To: Reinaldo Penno (repenno) >;= Ron Parker >; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. ... I don't see the point of that unless it comes from some legacy. Why waste b= ytes in the information element when length could have been placed in the l= ength field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, "the length gives the number of bytes" ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I'm not aware of any formats in which variable-length string fields are enc= oded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn't like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830FFA70Awtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reinaldo,

How does that help wit= h buffer overrun attacks?

 

Certainly the receiver= should never trust that there is a null at the end.

 

And also, a string tha= t is a multiple of 4 would not need to have a null at the end.

 

To help against attack= s, it might be better to specify, “should be filled with random numbe= rs” so that assumptions in receiving code are caught quickly.

 

-Dave

 

 

 

From: Reinaldo= Penno (repenno) [mailto:repenno@cisco.com]
Sent: Wednesday, July 13, 2016 1:12 PM
To: Dave Dolson; Ron Parker; sfc@ietf.org
Subject: Re: [sfc] A problem with NSH TLV

 

I sugge= st we say it “must be” null character.  It will help detec= t any parsing problems, buffer overrun attacks, etc. 

&n= bsp;

From: Dave Dolson <ddolson@sandvine.com>
Date: Tuesday, July 12, 2016 at 2:19 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Reinaldo Penno <repenno@cisco.com>, "sfc@ietf.org" <sf= c@ietf.org>
Subject: RE: [sfc] A problem with NSH TLV

&n= bsp;

Agreed, padding should= be at the end of the string. (If I understood correctly.)

 

E.g., encoding of octe= t string{0x31 0xff 0x00 0x21 0x00}:

 

 

      0  &n= bsp;            = ;    1         =           2   &= nbsp;           &nbs= p;   3

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

      +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

      |  &n= bsp;       TLV Class    &= nbsp;       |C|    Type &= nbsp;   |R|    Len=3D5    |<= span style=3D"color:black">

      +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

      |  &n= bsp; 0x31       |   0xff  = ;      |    0x00   &= nbsp;   |    0x21     &nb= sp; |

      +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

      |  &n= bsp; 0x00       |    &nbs= p; X        |    &nb= sp;   X      |    &n= bsp;  X       |

      +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

 

X means “donR= 17;t care”. We could say “should be 0”

 

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, July 12, 2016 1:04 PM
To: Dave Dolson; Reinaldo Penno (repenno); sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 =

Hi, Dave.

 

I agree that length in= octets, excluding header, is the right way to go.   This include= s your proposed expansion of the length field by 2 bits.   I also= suggest the addition of text regarding padding to 4 octet boundaries with zeroes,and “justification” of small native byt= es towards the lower numbered bytes with padding at the higher numbered byt= es.

 

   Ron

 

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Tuesday, July 12, 2016 12:52 PM
To: Reinaldo Penno (repenno) <repenno@cisco.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 =

(Informal survey of th= e binary formats I could think of)<= /o:p>

 

---------

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element Fie= ld Length is recorded<= /p>

   as 65535.  This reserved length value notif= ies the Collecting Process

   that the length value of the Information Element= will be carried in

   the Information Element content itself.

…

I don’t see the = point of that unless it comes from some legacy. Why waste bytes in the info= rmation element when length could have been placed in the length field?

 

----------

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary da= ta of variable length.  Unless=

      otherwise noted, the AVP Lengt= h field MUST be set to at least 8

      (12 if the 'V' bit is enabled)= .  AVP values of this type that are=

      not a multiple of 4 octets in = length are followed by the necessary

      padding so that the next AVP (= if any) will start on a 32-bit

      boundary.

 

---------

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, “the length gi= ves the number of bytes”

 

----------

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.=

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:=

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-length (= counted) opaque data,<= /p>

   defined as a sequence of n (numbered 0 through n= -1) arbitrary bytes

   to be the number n encoded as an unsigned intege= r (as described

   below), and followed by the n bytes of the seque= nce.

 

   Byte m of the sequence always precedes byte m= 3;1 of the sequence, and

   byte 0 of the sequence always follows the sequen= ce's length (count).

   If n is not a multiple of four, then the n bytes= are followed by

   enough (0 to 3) residual zero bytes, r, to make = the total byte count

   a multiple of four...

 

-------

I’m not aware of= any formats in which variable-length string fields are encoded with number= of words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn’t l= ike to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 =

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   <= /p>

 <= /span>

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

 <= /span>

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_E8355113905631478EFF04F5AA706E9830FFA70Awtlexchp2sandvi_-- From nobody Wed Jul 13 10:22: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 6ECC612D1A9 for ; Wed, 13 Jul 2016 10:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 KKmMNMnoL0je for ; Wed, 13 Jul 2016 10:22:39 -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 882A712D1A4 for ; Wed, 13 Jul 2016 10:22:24 -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.195.1; Wed, 13 Jul 2016 13:22:23 -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.0294.000; Wed, 13 Jul 2016 13:22:23 -0400 From: Dave Dolson To: "Reinaldo Penno (repenno)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAAMEmCAAbijgP//3yNw Date: Wed, 13 Jul 2016 17:22:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830FFA766wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 17:22:43 -0000 --_000_E8355113905631478EFF04F5AA706E9830FFA766wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reinaldo, Yes, we suggest padding to 4-byte boundaries. But the length field should b= e in units of octets so that the real end of the octets is known. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Wednesday, July 13, 2016 1:19 PM To: Ron Parker; Dave Dolson; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV Sorry if this question was answered. But why not just pad everything to 4 b= yte boundaries (binary and strings)? Everything is transmitted in network = order, we should have no problems, right? No? From: sfc > on behalf of = Ron Parker > Date: Tuesday, July 12, 2016 at 2:04 PM To: Dave Dolson >, Reinal= do Penno >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Hi, Dave. I agree that length in octets, excluding header, is the right way to go. = This includes your proposed expansion of the length field by 2 bits. I al= so suggest the addition of text regarding padding to 4 octet boundaries wit= h zeroes,and "justification" of small native bytes towards the lower number= ed bytes with padding at the higher numbered bytes. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 12, 2016 12:52 PM To: Reinaldo Penno (repenno) >;= Ron Parker >; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. ... I don't see the point of that unless it comes from some legacy. Why waste b= ytes in the information element when length could have been placed in the l= ength field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, "the length gives the number of bytes" ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I'm not aware of any formats in which variable-length string fields are enc= oded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn't like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I'd be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well - fields whose lengths are no= t multiples of 4 are "left justified" towards the lower octet numbers with = zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren't always multiples of 4 bytes in= length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the 'R' bits into the 'L' field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830FFA766wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reinaldo,

Yes, we suggest paddin= g to 4-byte boundaries. But the length field should be in units of octets s= o that the real end of the octets is known.

 

-Dave

 

 

From: Reinaldo= Penno (repenno) [mailto:repenno@cisco.com]
Sent: Wednesday, July 13, 2016 1:19 PM
To: Ron Parker; Dave Dolson; sfc@ietf.org
Subject: Re: [sfc] A problem with NSH TLV

 

Sorry i= f this question was answered. But why not just pad everything to 4 byte bou= ndaries (binary and strings)?  Everything is transmitted in network or= der, we should have no problems, right? No?

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Ron Parker <Ron_Parker@affirmednetworks.com>
Date: Tuesday, July 12, 2016 at 2:04 PM
To: Dave Dolson <ddolson@= sandvine.com>, Reinaldo Penno <repenno@cisco.com>, "sfc@iet= f.org" <sfc@ietf.org> Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Hi, Dave.

 

I agree that length in= octets, excluding header, is the right way to go.   This include= s your proposed expansion of the length field by 2 bits.   I also= suggest the addition of text regarding padding to 4 octet boundaries with zeroes,and “justification” of small native byt= es towards the lower numbered bytes with padding at the higher numbered byt= es.

 

   Ron

 

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Tuesday, July 12, 2016 12:52 PM
To: Reinaldo Penno (repenno) <repenno@cisco.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 =

(Informal survey of th= e binary formats I could think of)<= /o:p>

 

---------

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element Fie= ld Length is recorded<= /p>

   as 65535.  This reserved length value notif= ies the Collecting Process

   that the length value of the Information Element= will be carried in

   the Information Element content itself.

…

I don’t see the = point of that unless it comes from some legacy. Why waste bytes in the info= rmation element when length could have been placed in the length field?

 

----------

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary da= ta of variable length.  Unless=

      otherwise noted, the AVP Lengt= h field MUST be set to at least 8

      (12 if the 'V' bit is enabled)= .  AVP values of this type that are=

      not a multiple of 4 octets in = length are followed by the necessary

      padding so that the next AVP (= if any) will start on a 32-bit

      boundary.

 

---------

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, “the length gi= ves the number of bytes”

 

----------

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.=

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:=

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-length (= counted) opaque data,<= /p>

   defined as a sequence of n (numbered 0 through n= -1) arbitrary bytes

   to be the number n encoded as an unsigned intege= r (as described

   below), and followed by the n bytes of the seque= nce.

 

   Byte m of the sequence always precedes byte m= 3;1 of the sequence, and

   byte 0 of the sequence always follows the sequen= ce's length (count).

   If n is not a multiple of four, then the n bytes= are followed by

   enough (0 to 3) residual zero bytes, r, to make = the total byte count

   a multiple of four...

 

-------

I’m not aware of= any formats in which variable-length string fields are encoded with number= of words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn’t l= ike to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 =

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   <= /p>

 <= /span>

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

 <= /span>

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I’d be OK with t= hat.

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well – fields whose lengths are not multiples of 4 are “left justified” towards th= e lower octet numbers with zero-value padding inserted at the higher octet = numbers.

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0   &= nbsp;           &nbs= p;   1          = ;         2    =             &nb= sp;  3

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

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;     Metadata Class     &= nbsp; |C|    Type     |R|R|R|  = ; Len   |

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

       |    &= nbsp;           &nbs= p;     Variable Metadata     &= nbsp;           &nbs= p;      |<= /o:p>

       +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+<= /p>

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren’t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |     &= nbsp;   TLV Class =3D 0x0       |C|=     Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      |UT(4)  |   =              UR= I            &n= bsp;            = ;           |

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

      ~     &= nbsp;           &nbs= p;      URI      &nb= sp;            =             &nb= sp;    ~

      +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the ‘R’ bits into the ‘L’ field, and ha= ve it indicate number of octets; and also say that padding is to be inserte= d so that each TLV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_E8355113905631478EFF04F5AA706E9830FFA766wtlexchp2sandvi_-- From nobody Wed Jul 13 12:08: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 79BA712D580 for ; Wed, 13 Jul 2016 12:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.307 X-Spam-Level: X-Spam-Status: No, score=-8.307 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.287, 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 n7XMZ9NT6WS4 for ; Wed, 13 Jul 2016 12:08:27 -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 D6AAA12D575 for ; Wed, 13 Jul 2016 12:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1468436907; x=1499972907; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=e6kmJ4ZXLrAf9ujuqFnPe/ellVGz6n8Fp35WjszfipM=; b=Yg3BupryKMMl2Qpnl+vaj5gSAusBHkqBB2tJg6AEPquPcAPvdsg2uhAy RF7+AS7u0WKeJwUar2NLtk7KuZTrAQzQyJi+kLpMlDI6RV9dxCjjKFBwM 3NtmU84hS0fH/M6FE0BWqCIPOwUryKaxHOJAoCxdTc84A/5QXgRi3iQ+N 0=; X-IronPort-AV: E=Sophos;i="5.28,358,1464652800"; d="scan'208,217";a="229418137" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 13 Jul 2016 19:08:26 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 13 Jul 2016 12:08:25 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1178.000; Wed, 13 Jul 2016 12:08:24 -0700 From: Sumandra Majee To: Dave Dolson , "Reinaldo Penno (repenno)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAAMEmCAAbijgP//3yNwgAAd/YA= Date: Wed, 13 Jul 2016 19:08:24 +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/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_D3ABDE8B55A7Fsmajeef5com_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 19:08:29 -0000 --_000_D3ABDE8B55A7Fsmajeef5com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As long as the length is in octet the padding can make cache friendly. There is an open question on how to interpret a binary series of bytes, bas= ically what is the encoding. Just to make sure I am not PROPOSING that we = add that too here. As long as there is default or explicit understanding we= should be good. Opening up encoding discussion is a rathole, actually a si= nk hole that we don=92t need. From: sfc > on behalf of = Dave Dolson > Date: Wednesday, July 13, 2016 at 10:22 AM To: "Reinaldo Penno (repenno)" = >, Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Reinaldo, Yes, we suggest padding to 4-byte boundaries. But the length field should b= e in units of octets so that the real end of the octets is known. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Wednesday, July 13, 2016 1:19 PM To: Ron Parker; Dave Dolson; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV Sorry if this question was answered. But why not just pad everything to 4 b= yte boundaries (binary and strings)? Everything is transmitted in network = order, we should have no problems, right? No? From: sfc > on behalf of = Ron Parker > Date: Tuesday, July 12, 2016 at 2:04 PM To: Dave Dolson >, Reinal= do Penno >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Hi, Dave. I agree that length in octets, excluding header, is the right way to go. = This includes your proposed expansion of the length field by 2 bits. I al= so suggest the addition of text regarding padding to 4 octet boundaries wit= h zeroes,and =93justification=94 of small native bytes towards the lower nu= mbered bytes with padding at the higher numbered bytes. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 12, 2016 12:52 PM To: Reinaldo Penno (repenno) >;= Ron Parker >; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. =85 I don=92t see the point of that unless it comes from some legacy. Why waste= bytes in the information element when length could have been placed in the= length field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, =93the length gives the number of bytes=94 ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I=92m not aware of any formats in which variable-length string fields are e= ncoded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn=92t like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I=92d be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well =96 fields whose lengths are = not multiples of 4 are =93left justified=94 towards the lower octet numbers= with zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren=92t always multiples of 4 bytes = in length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the =91R=92 bits into the =91L=92 field= , and have it indicate number of octets; and also say that padding is to be= inserted so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. --_000_D3ABDE8B55A7Fsmajeef5com_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2F52962B21254047968C99265E44FDCE@F5.com> Content-Transfer-Encoding: quoted-printable
As long as the length is in octet the padding can make cache friendly.=  

There is an open question on how to interpret a binary series of bytes= , basically what is the encoding.  Just to make sure I am not PROPOSIN= G that we add that too here. As long as there is default or explicit unders= tanding we should be good. Opening up encoding discussion is a rathole, actually a sink hole that we don=92t nee= d.

From: sfc <sfc-bounces@ietf.org> on behalf of Dave Dolson &l= t;ddolson@sandvine.com>
Date: Wednesday, July 13, 2016 at 1= 0:22 AM
To: "Reinaldo Penno (repenno)&= quot; <repenno@cisco.com>, R= on Parker <Ron_Parker= @affirmednetworks.com>, "sfc@ie= tf.org" <sfc@ietf.org>
Subject: Re: [sfc] A problem with N= SH TLV

Reinaldo,

Yes, we suggest paddin= g to 4-byte boundaries. But the length field should be in units of octets s= o that the real end of the octets is known.

 

-Dave

 

 

From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Wednesday, July 13, 2016 1:19 PM
To: Ron Parker; Dave Dolson; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 

Sorry i= f this question was answered. But why not just pad everything to 4 byte bou= ndaries (binary and strings)?  Everything is transmitted in network or= der, we should have no problems, right? No?

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Ron Parker <Ron_Parker@affirmednetworks.com>
Date: Tuesday, July 12, 2016 at 2:04 PM
To: Dave Dolson <ddolson@= sandvine.com>, Reinaldo Penno <repenno@cisco.com>, "sfc@iet= f.org" <sfc@ietf.org> Subject: Re: [sfc] A problem with NSH TLV

&n= bsp;

Hi, Dave.

 

I agree that length in= octets, excluding header, is the right way to go.   This include= s your proposed expansion of the length field by 2 bits.   I also= suggest the addition of text regarding padding to 4 octet boundaries with zeroes,and =93justification=94 of small native bytes towar= ds the lower numbered bytes with padding at the higher numbered bytes.

 

   Ron

 

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Tuesday, July 12, 2016 12:52 PM
To: Reinaldo Penno (repenno) <repenno@cisco.com>; Ron Parker <Ron_Parker@affirmednetworks.com>; sfc@ietf.org
Subject: RE: [sfc] A problem with NSH TLV

 =

(Informal survey of th= e binary formats I could think of)<= /o:p>

 

---------

IPFix uses Field Lengt= h of octets for the Field Specifier, but also made a bit of a mess of varia= ble-length fields, IMO:

https://tools.ietf.org/html/rfc7011#sec= tion-7

 

   In the Template Set, the Information Element = Field Length is recorded

   as 65535.  This reserved length value no= tifies the Collecting Process=

   that the length value of the Information Elem= ent will be carried in=

   the Information Element content itself.

=85

I don=92t see the poin= t of that unless it comes from some legacy. Why waste bytes in the informat= ion element when length could have been placed in the length field?<= span style=3D"color:black">

 

----------

Diameter (RFC 6733) AV= Ps have a length field in octets that includes the AVP header. Note the for= mat requires padding if the length is not a multiple of 4.

 

   OctetString

 

      The data contains arbitrary= data of variable length.  Unless

      otherwise noted, the AVP Le= ngth field MUST be set to at least 8

      (12 if the 'V' bit is enabl= ed).  AVP values of this type that are

      not a multiple of 4 octets = in length are followed by the necessary<= o:p>

      padding so that the next AV= P (if any) will start on a 32-bit

      boundary.

 

---------

CBOR (https://tools.ietf.org/html/rfc= 7049#section-2.1) - for Major type 3 -text string, =93the length gives = the number of bytes=94=

 

----------

ASN.1 - although there= are different ways of encoding the length, the value of length field indic= ates number of octets.=

 

--------

XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in by= tes, with padding to multiple of 4:=

 

4.10.  Variable-Length Opaque Data

 

   The standard also provides for variable-lengt= h (counted) opaque data,

   defined as a sequence of n (numbered 0 throug= h n-1) arbitrary bytes=

   to be the number n encoded as an unsigned int= eger (as described

   below), and followed by the n bytes of the se= quence.

 

   Byte m of the sequence always precedes byte m= +1 of the sequence, and

   byte 0 of the sequence always follows the seq= uence's length (count).

   If n is not a multiple of four, then the n by= tes are followed by

   enough (0 to 3) residual zero bytes, r, to ma= ke the total byte count

   a multiple of four...

 

-------

I=92m not aware of any= formats in which variable-length string fields are encoded with number of = words vs. number of octets.

 

I recommend the length= field is the number of octets of the data (not including the header), with= 0 as a valid value representing the empty string.

Some implementers may = prefer to have padding to 4-byte alignment.

 

But I wouldn=92t like = to see the IPFix approach.

 

-Dave

 

 

From: Reinaldo Penno (repenn= o) [mailto:repenno@cisco.com]
Sent: Monday, July 11, 2016 8:05 PM
To: Dave Dolson; Ron Parker; sfc@iet= f.org
Subject: Re: [sfc] A problem with NSH TLV

 =

This is= not really a new problem and hopefully we can leverage widely used solutio= ns.  IPfix for example also relies on TLVs and has encodings for octet= s strings, binary and all other formats known to man.   <= /p>

 <= /span>

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.o= rg>
Subject: Re: [sfc] A problem with NSH TLV

 <= /span>

Ron,

I agree your solution = to use bits 25-26 to indicate padding would be backwards compatible if anyo= ne is concerned about backwards compatibility.

I=92d be OK with that.=

 

-Dave

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks= .com]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV

 =

Hi, Dave.

 

I agree that valid len= gth must be indicated even when not a multiple of 4 octets and agree with y= our solution.   A description of alignment within the 4 octets sh= ould be part of the text, as well =96 fields whose lengths are not multiples of 4 are =93left justified=94 towards the lower = octet numbers with zero-value padding inserted at the higher octet numbers.=

 

Do you think this is j= ustification to bump the version number of the NSH, since implementations a= re already fielded?    In v0, the length is interpreted as a= 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.    

 

If the community is op= posed to bumping the version, another approach would be to use bits 25 and = 26 as a pad-length field.  Bits 27-31 would continue to be length in 4= -octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (= values 0..3).

 

   Ron

 

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: sfc@ietf.org
Subject: [sfc] A problem with NSH TLV

 =

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

 =

This is the TLV format:<= o:p>

        0    &= nbsp;           &nbs= p;  1           = ;        2     =             &nb= sp; 3

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

       +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

       |     &= nbsp;    Metadata Class       = |C|    Type     |R|R|R|   Len&= nbsp;  |

       +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

       |     &= nbsp;           &nbs= p;    Variable Metadata      &= nbsp;           &nbs= p;     |<= /span>

       +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

 =

Len is defined as number= of 4-byte words.

The problem with this is= that strings aren=92t always multiples of 4 bytes in length.

 =

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is= given:

 =

   10.  U= niversal Resource Identifier (URI)

 =

      +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

      |      &= nbsp;  TLV Class =3D 0x0       |C| =    Type=3D0xA |R|R|R|   L=3Dvar |

      +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

      |UT(4)  |    =             URI = ;            &n= bsp;            = ;          |

      +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

      ~      &= nbsp;           &nbs= p;     URI       &nb= sp;            =             &nb= sp;   ~

      +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

 =

Despite the confusing pa= rt about the first nybble being used for UT field (supposed to be an octet?= ),

if the URI is not a mult= iple of 4 bytes, how is it to be terminated?

 =

Diameter (RFC6733) solve= s this problem nicely by making the length indicate a number of octets, whi= le specifying padding to 4-octet alignment for the next element.=

 =

So my proposal is to rec= ruit two of the =91R=92 bits into the =91L=92 field, and have it indicate n= umber of octets; and also say that padding is to be inserted so that each T= LV is a multiple of 4 octets in length.

 =

 =

 =

David Dolson<= /span>

Senior Software Architec= t, Sandvine Inc.

 =

--_000_D3ABDE8B55A7Fsmajeef5com_-- From nobody Wed Jul 13 12:18: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 882D212D53B for ; Wed, 13 Jul 2016 12:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 lLN8DOAzIP9N for ; Wed, 13 Jul 2016 12:18:04 -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 ED49412B043 for ; Wed, 13 Jul 2016 12:18:03 -0700 (PDT) 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.0195.001; Wed, 13 Jul 2016 15:18:01 -0400 From: Dave Dolson To: Sumandra Majee , "Reinaldo Penno (repenno)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] A problem with NSH TLV Thread-Index: AQHR29D2XMarZA5RR0+l5xlFeVgJdqAU+mPwgAAMEmCAAbijgP//3yNwgAAd/YCAAAKxTQ== Date: Wed, 13 Jul 2016 19:18:01 +0000 Message-ID: <20160713191800.5673043.28020.97132@sandvine.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A problem with NSH TLV X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 19:18:07 -0000 Each TLV type will have to explain the encoding--what is in the octets. I'm= just making sure the length can work for TLVs that aren't exact multiples = of 4 in length. So will the editors of -nsh agree to make the change? From: Sumandra Majee Sent: Wednesday, July 13, 2016 3:08 PM To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV As long as the length is in octet the padding can make cache friendly. There is an open question on how to interpret a binary series of bytes, bas= ically what is the encoding. Just to make sure I am not PROPOSING that we = add that too here. As long as there is default or explicit understanding we= should be good. Opening up encoding discussion is a rathole, actually a si= nk hole that we don=92t need. From: sfc > on behalf of = Dave Dolson > Date: Wednesday, July 13, 2016 at 10:22 AM To: "Reinaldo Penno (repenno)" = >, Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Reinaldo, Yes, we suggest padding to 4-byte boundaries. But the length field should b= e in units of octets so that the real end of the octets is known. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Wednesday, July 13, 2016 1:19 PM To: Ron Parker; Dave Dolson; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV Sorry if this question was answered. But why not just pad everything to 4 b= yte boundaries (binary and strings)? Everything is transmitted in network = order, we should have no problems, right? No? From: sfc > on behalf of = Ron Parker > Date: Tuesday, July 12, 2016 at 2:04 PM To: Dave Dolson >, Reinal= do Penno >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Hi, Dave. I agree that length in octets, excluding header, is the right way to go. = This includes your proposed expansion of the length field by 2 bits. I al= so suggest the addition of text regarding padding to 4 octet boundaries wit= h zeroes,and =93justification=94 of small native bytes towards the lower nu= mbered bytes with padding at the higher numbered bytes. Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 12, 2016 12:52 PM To: Reinaldo Penno (repenno) >;= Ron Parker >; sfc@ietf.org Subject: RE: [sfc] A problem with NSH TLV (Informal survey of the binary formats I could think of) --------- IPFix uses Field Length of octets for the Field Specifier, but also made a = bit of a mess of variable-length fields, IMO: https://tools.ietf.org/html/rfc7011#section-7 In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value of the Information Element will be carried in the Information Element content itself. =85 I don=92t see the point of that unless it comes from some legacy. Why waste= bytes in the information element when length could have been placed in the= length field? ---------- Diameter (RFC 6733) AVPs have a length field in octets that includes the AV= P header. Note the format requires padding if the length is not a multiple = of 4. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. --------- CBOR (https://tools.ietf.org/html/rfc7049#section-2.1) - for Major type 3 -= text string, =93the length gives the number of bytes=94 ---------- ASN.1 - although there are different ways of encoding the length, the value= of length field indicates number of octets. -------- XDR - https://tools.ietf.org/html/rfc4506#section-4.10 specifies length in = bytes, with padding to multiple of 4: 4.10. Variable-Length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four... ------- I=92m not aware of any formats in which variable-length string fields are e= ncoded with number of words vs. number of octets. I recommend the length field is the number of octets of the data (not inclu= ding the header), with 0 as a valid value representing the empty string. Some implementers may prefer to have padding to 4-byte alignment. But I wouldn=92t like to see the IPFix approach. -Dave From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Monday, July 11, 2016 8:05 PM To: Dave Dolson; Ron Parker; sfc@ietf.org Subject: Re: [sfc] A problem with NSH TLV This is not really a new problem and hopefully we can leverage widely used = solutions. IPfix for example also relies on TLVs and has encodings for oct= ets strings, binary and all other formats known to man. From: sfc > on behalf of = Dave Dolson > Date: Monday, July 11, 2016 at 5:15 PM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] A problem with NSH TLV Ron, I agree your solution to use bits 25-26 to indicate padding would be backwa= rds compatible if anyone is concerned about backwards compatibility. I=92d be OK with that. -Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 11, 2016 3:12 PM To: Dave Dolson; sfc@ietf.org Subject: RE: A problem with NSH TLV Hi, Dave. I agree that valid length must be indicated even when not a multiple of 4 o= ctets and agree with your solution. A description of alignment within the= 4 octets should be part of the text, as well =96 fields whose lengths are = not multiples of 4 are =93left justified=94 towards the lower octet numbers= with zero-value padding inserted at the higher octet numbers. Do you think this is justification to bump the version number of the NSH, s= ince implementations are already fielded? In v0, the length is interpret= ed as a 5-bit count of 4-octet units. In v1, the length is interpreted as= a 7-bit count of octets. If the community is opposed to bumping the version, another approach would = be to use bits 25 and 26 as a pad-length field. Bits 27-31 would continue = to be length in 4-octet units, but 25 and 26 specify how many of the bytes = at the highest octet numbers are considered to be pad bytes (values 0..3). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Monday, July 11, 2016 3:01 PM To: sfc@ietf.org Subject: [sfc] A problem with NSH TLV As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3= .5.1 This is the TLV format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len is defined as number of 4-byte words. The problem with this is that strings aren=92t always multiples of 4 bytes = in length. E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this examp= le is given: 10. Universal Resource Identifier (URI) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class =3D 0x0 |C| Type=3D0xA |R|R|R| L=3Dvar= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UT(4) | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ URI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite the confusing part about the first nybble being used for UT field (= supposed to be an octet?), if the URI is not a multiple of 4 bytes, how is it to be terminated? Diameter (RFC6733) solves this problem nicely by making the length indicate= a number of octets, while specifying padding to 4-octet alignment for the = next element. So my proposal is to recruit two of the =91R=92 bits into the =91L=92 field= , and have it indicate number of octets; and also say that padding is to be= inserted so that each TLV is a multiple of 4 octets in length. David Dolson Senior Software Architect, Sandvine Inc. From nobody Wed Jul 13 15:37: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 6D92112D92D for ; Wed, 13 Jul 2016 15:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.308 X-Spam-Level: X-Spam-Status: No, score=-8.308 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.287, 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 rhMXFC7Q69sc for ; Wed, 13 Jul 2016 15:37:28 -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 A21E212D97F for ; Wed, 13 Jul 2016 15:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1468449449; x=1499985449; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nwhfMnzr+vg+W9EUPAWiiiv/UA9EBNMBZNLiwuLRv7A=; b=V+og4TKJQR/8OHYsxbAW64LJhfdkBIbVlz34KzUNn+CZuU/KzILMGFp/ AqUEtzVIuj3x7gr8eXMH8RRAZvDnN/9j6H9dMcEKm9n0sVCtCKbNQZcrT upfmlkO18ugQDAbIgLAaDK3COIaGAF9ZlEnZ8MC4u/KI1NGbIeI80+Ufu Y=; X-IronPort-AV: E=Sophos;i="5.28,359,1464652800"; d="scan'208";a="229462232" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 13 Jul 2016 22:37:15 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 13 Jul 2016 15:37:14 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1178.000; Wed, 13 Jul 2016 15:37:14 -0700 From: Sumandra Majee To: Youjianjie , "sfc@ietf.org" Thread-Topic: [sfc] Legacy SF Thread-Index: AdHczRmAyl5Qh16/SWyKukFcQVIMcgAeQPUAAAQ+lwA= Date: Wed, 13 Jul 2016 22:37:13 +0000 Message-ID: References: <5b3015ba-5bc5-2ef2-6999-65d6e3aaf017@joelhalpern.com> In-Reply-To: <5b3015ba-5bc5-2ef2-6999-65d6e3aaf017@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Legacy SF X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Jul 2016 22:37:30 -0000 Hello, I agree with Joel=B9s comment that it is non exhaustive methods that can be used by the proxy to map pkts and flows belonging to SFC domain and non SFC domain. The correlation can be also be made as part of the payload in case HTTP proxy and other higher order proxy. HTTP proxies has been using X-FORWARDED-FOR HDR for many years and similar method has already been used to correlate flows etc. I have few concerns/questions on the method also. L2 transparent devices are not required to keep the pkt order at the egress. So lets assume a SF1 is connected via VLAN#10 and VLAN#20 for pathID 0x1234. If two pkts P1, P2 for two given flows with different HDR values at the ingress (VLAN#10) is sent to SF1, and SF1 spits out in reverse order then what HDR gets put on P2 at egress. For most implementation narrowing it down to flows etc are almost a requirement to support correctness. On 7/13/16, 6:35 AM, "sfc on behalf of Joel M. Halpern" wrote: >I would describe the document you have provided somewhat differently. >It seems to be a survey of some of the known methods for building and >operating a legacy SF Proxy. > >There is no question that deployments will need such proxies. The >architecture identifies them for that reason. > >What is unclear to me is whether such a survey is helpful to future >implementors. It may be. On the other hand, the choice of technique >depends very heavily on the behavior of the legacy SF to be supported. > >Yours, >Joel > >On 7/13/16 2:09 AM, Youjianjie wrote: >> Dear all, >> >> This document provides a mechanism between an SFC proxy and an >>SFC-unaware service function (herein termed "legacy SF"), to identify >>the SFC header associated with a packet that is returned from a legacy >>SF, without an SFC header being explicitly carried in the wired protocol >>between SFC proxy and legacy SF. >> >> The motivation for supporting legacy SF is that existing service >>functions don't need to be upgraded to support SFC, removing one barrier >>to wide adoption of SFC. >> https://tools.ietf.org/html/draft-song-sfc-legacy-sf-mapping-07 >> >> Your comments and suggestions are welcome! >> >> Regards, >> Jianjie >> >> _______________________________________________ >> 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 Jul 14 05:23: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 A1A1712D87E; Thu, 14 Jul 2016 05:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 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.287] 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 DJrGJxe-Zy_q; Thu, 14 Jul 2016 05:23:28 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BF9612D6A1; Thu, 14 Jul 2016 05:23:25 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 14 Jul 2016 14:23:07 +0200 X-IronPort-AV: E=Sophos;i="5.28,362,1464645600"; d="scan'208";a="918096247" Received: from he105702.emea1.cds.t-internal.com ([10.169.119.23]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES256-SHA; 14 Jul 2016 14:23:01 +0200 Received: from HE105702.EMEA1.cds.t-internal.com (10.169.119.23) by HE105702.emea1.cds.t-internal.com (10.169.119.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 14 Jul 2016 14:23:01 +0200 Received: from HE105702.EMEA1.cds.t-internal.com ([fe80::6557:5052:1c14:f5e7]) by HE105702.emea1.cds.t-internal.com ([fe80::6557:5052:1c14:f5e7%26]) with mapi id 15.00.1178.000; Thu, 14 Jul 2016 14:23:01 +0200 From: To: , Thread-Topic: [sfc] Call for Berlin SFC Agenda Topics Thread-Index: AdHQK73pJ2oSLxcNQFmsa3HZxxbt5gNngdHg Date: Thu, 14 Jul 2016 12:23:01 +0000 Message-ID: <012910a73a6148d3935398b6d6d44564@HE105702.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.17.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: sarikaya@ieee.org, mohamed.boucadair@orange.com Subject: Re: [sfc] Call for Berlin SFC 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: Thu, 14 Jul 2016 12:23:30 -0000 RGVhciBTRkMgY2hhaXJzLA0KV2UgdW5mb3J0dW5hdGVseSBtaXNzZWQgdGhlIGRlYWRsaW5lIGFz IHdlIGRpZCBub3Qgc3VjY2VlZCB0byBzdWJtaXQgdGhlIHVwZGF0ZSBvZiBvdXIgTlNIL1RMViBy ZWxhdGVkIGRyYWZ0cyBiZWZvcmUgSnVseSA1IDstKA0KTWF5IHdlIG5ldmVydGhlbGVzcyBhc2sg Zm9yIGEgc2hvcnQgc2xvdCBpbiB0aGUgYWdlbmRhIHRvIHByZXNlbnQgZHJhZnQtc2FyaWtheWEt c2ZjLWhvc3RpZC1zZXJ2aWNlaGVhZGVyIChTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIFNlcnZp Y2UsIFN1YnNjcmliZXIgYW5kIEhvc3QgSWRlbnRpZmljYXRpb24gVXNlIENhc2VzIGFuZCBNZXRh ZGF0YSkgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhcmlrYXlhLXNmYy1ob3N0 aWQtc2VydmljZWhlYWRlci0wMyBhbmQgIHJlbGF0ZWQgZHJhZnQtc2FyaWtheWEtc2ZjLXNmY3Rs dnMgKFJvYWQgdG8gdGhlIFN0YW5kYXJkaXphdGlvbiBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFp bmluZyBNZXRhZGF0YSBUeXBlIDEgYW5kIFR5cGUgMikgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNhcmlrYXlhLXNmYy1zZmN0bHZzLTAwID8NCg0KVGhhbmtzIGEgbG90IQ0KQmVz dCBSZWdhcmRzDQpEaXJrIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gU3RpZW1l cmxpbmcNClNlbnQ6IE1vbnRhZywgMjcuIEp1bmkgMjAxNiAwNjoyMw0KVG86IHNmY0BpZXRmLm9y Zw0KU3ViamVjdDogW3NmY10gQ2FsbCBmb3IgQmVybGluIFNGQyBBZ2VuZGEgVG9waWNzDQoNCkdy ZWV0aW5ncyBXRzoNCg0KT3VyIG1lZXRpbmcgaW4gQmVybGluIGlzIGZhc3QgYXBwcm9hY2hpbmcu IEFzIGFsd2F5cyB0aGUgZ29hbCBvZiB0aGUgbWVldGluZyB3aWxsIGJlIHRvIG1ha2UgdGhlIGJl c3QgdXNlIG9mIG91ciBsaW1pdGVkIGZhY2UtdG8tZmFjZSB0aW1lLiANCldpdGggdGhhdCBpbiBt aW5kIHdlIHdlbGNvbWUgcmVxdWVzdHMgZm9yIGFnZW5kYSB0aW1lLg0KDQpBcyB3ZSBidWlsZCB0 aGUgbWVldGluZyBhZ2VuZGEgb3VyIGdvYWwgd2lsbCBiZSB0byBzZWxlY3QgcHJlc2VudGF0aW9u cyB0aGF0IGJlc3QgZnVydGhlciB0aGUgd29yayBvZiB0aGUgV0csIGFuZCB0aGF0IGdlbmVyYWxs eSBtZWFucyBmb2N1c2luZyBvbiBrZXkgY2hhcnRlciBkZWxpdmVyYWJsZXMgYW5kIHRvcGljcyB3 aXRoIGltcG9ydGFudCBvcGVuIGlzc3VlcyB0byByZXNvbHZlLiBXaGVuIG1ha2luZyBhIHJlcXVl c3QgcGxlYXNlIGNvbnNpZGVyIHdoYXQgeW91IHRoaW5rIHRoZSBXRyBzaG91bGQgZG8gd2l0aCBp dHMgY29udGVudCDigJMgZm9yIGV4YW1wbGU6DQoNCi0gRG9lcyB0aGUgZG9jdW1lbnQgaGF2ZSB1 c2VmdWwgY29udGVudCB0aGF0IHNob3VsZCBiZSBtb3ZlZCBpbnRvIGFub3RoZXIgV0cgZG9jdW1l bnQgb3IgcHJvZ3Jlc3Mgb24gaXRzIG93biBtZXJpdA0KLSBEb2VzIHRoZSBjb250ZW50IGhhdmUg YSBnb29kIGJhc2lzIGZvciBvbmUgb2YgdGhlIFdHIGRvY3VtZW50cyBwZXIgdGhlIGNoYXJ0ZXIN Ci0gU2hvdWxkIHRoZSBkb2N1bWVudCBjb250ZW50IGJlIG1lcmdlZCB3aXRoIG9uZSBvciBtb3Jl IG90aGVyIGRvY3VtZW50cywgc28gdGhhdCBhIGNvbWJpbmVkIGRvY3VtZW50IGNvdWxkIGJlY29t ZSBhIFdHIGRvY3VtZW50DQoNCioqUGxlYXNlIHNlbmQgeW91ciByZXF1ZXN0IHRvIHRoZSBTRkMg Y2hhaXJzIHVudGlsIEp1bHkgMXN0LCA5IGFtIEVTVC4qKg0KDQpUaGUgcmVxdWVzdCBtdXN0IGlu Y2x1ZGUgdGhlIG5hbWUgb2YgdGhlIGRyYWZ0IHRvIGJlIHByZXNlbnRlZCwgdGltZSBmb3IgdGhl IHByZXNlbnRhdGlvbiByZXF1ZXN0ZWQsIGFuZCB0aGUgcHJlc2VudGVyLg0KDQpUaGFua3MsDQoN CkppbSwgVGhvbWFzICYgTWFydGluDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Thu Jul 14 22:05: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 98FAF12B057 for ; Thu, 14 Jul 2016 22:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzuFFD-OijHA for ; Thu, 14 Jul 2016 22:05:06 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:a::4]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD9C12B01F for ; Thu, 14 Jul 2016 22:05:06 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id C06584E67D; Fri, 15 Jul 2016 14:05:03 +0900 (JST) Received: from [127.0.0.1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTPSA id A85E03ACA5; Fri, 15 Jul 2016 14:05:03 +0900 (JST) To: "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> From: Kengo NAITO Message-ID: <2651f4d0-0929-02e2-066c-621bc50a1ecf@nttv6.jp> Date: Fri, 15 Jul 2016 14:05:06 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 15 Jul 2016 05:05:07 -0000 support Kengo On 2016/07/06 22:17, Jim Guichard (jguichar) wrote: > Dear WG: > > > This email serves as a call for WG adoption of > draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption > will run for 2 weeks ending 7/25/2016. > > > > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a WG document simply means that the WG > will focus its efforts on that particular draft going forward, and use > that document for resolving open issues and documenting the WG’s decisions. > > > > Please indicate whether you support adoption for not, and if not why. > Issues you have with the current document itself can also be raised, but > they should be raised in the context of what should be changed in the > document going forward, rather than a pre-condition for adoption. > > > > Finally, now is also a good time to poll for knowledge of any IPR that > applies to this draft, in line with the IPR disclosure obligations for > WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as a document author please respond to this email (to > the chairs) whether or not you are aware of any relevant IPR. > > > Thanks! > > > SFC Chairs > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ------------------------------------------------ Kengo NAITO Technology Development NTT Communications Corporation Tel: +81-50-3813-6053 E-mail: k.naito@nttv6.jp ------------------------------------------------ From nobody Fri Jul 15 04:58: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 54D1912D62F for ; Fri, 15 Jul 2016 04:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Kl2rdmqQ2zJr for ; Fri, 15 Jul 2016 04:58:33 -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 842C412D520 for ; Fri, 15 Jul 2016 04:58:33 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id i5so26589290wmg.0 for ; Fri, 15 Jul 2016 04:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:reply-to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=pTOck/cc7bY/M5Mb5t8ndhB5vlNMfWNTpTtzr1GHU9E=; b=Eoa9tx2EHnVv0PDlIEOE9uOstsj5TjFV09kRrfmIaq61J16iF7yVI0DML8aqdRu/Xi YR3j339nQCwvfKcTL3a+hylnmed4+RrDuo1i2tTWUyxfv1j46ppVwJz+iOTLBdvdS+3k cbLKALfPPtKXhXJpM/uUdDNRqZ9RA729uX1yx2krrHol0+Pgpp5w0dkQuVfthUkg5cej u9gYNceN9AxV+9yBRBeuOSbnKioQnoVVf+PDYWgC5pi6AMMVaauRMTfUEyxqtTn5/Lnv Aepn+ILlzFD1c7fYK2uAeQ0+LHT8Cji4N376+c6Y6jCg8JrN68nHdJQo3KhBN7n/2ELv CdvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:reply-to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=pTOck/cc7bY/M5Mb5t8ndhB5vlNMfWNTpTtzr1GHU9E=; b=GMwGhfXGS3h5zugbkmYbZD7qnh7TbseS97mJkSpGRhySWno/+BxPyn0BBw98VEPYZN NzjFpY/lDC/t2DahTQ4RFNtMhvQ6qOLfWxqkTj1kNSLkaS2QCU1f3sTDz9s+R5xRU7ua NV/ETPRiJa8mxzkkZduVcynOOH20iEFTAaBmQ544u2PO3JgQy/XFUDgwCRpMCtNVk2Io fd/FVb10EPZrOsRI/BSthzpTf7LBt1SaqaMVgbN4fq1x8qVoKGPLuGFIz0s6nsO4vrvS 3E+OBuZ6FTBMqeT2DvCXdvaKqFlcOTfU5gin1lNBXks/tOFG9GpBEKZAIAfMlIGOXyjf GXOg== X-Gm-Message-State: ALyK8tJBjID8kig3sYRBGPdB+El0Qp8vIBeM2D1gUhqrcDmNz4RJIBnaZaHmnpg6ydRHwg== X-Received: by 10.194.102.2 with SMTP id fk2mr451897wjb.143.1468583911664; Fri, 15 Jul 2016 04:58:31 -0700 (PDT) Received: from ?IPv6:2003:74:cf0f:5c53:299d:f49b:f47b:ecd9? (p2003000613606053299DF49BF47BECD9.dip0.t-ipconnect.de. [2003:6:1360:6053:299d:f49b:f47b:ecd9]) by smtp.googlemail.com with ESMTPSA id f193sm5588729wme.11.2016.07.15.04.58.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jul 2016 04:58:30 -0700 (PDT) To: sfc@ietf.org From: Martin Stiemerling Message-ID: Date: Fri, 15 Jul 2016 13:58:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] July 17th 9 pm CEST: Presentations due for SFC session! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "sfc-chairs@ietf.org" List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 11:58:35 -0000 Dear all presenters, Please send your draft slides to us the SFC chairs until Sunday, July 17th, 9 pm CEST. This will allow the chairs to upload the slides before the session. Please include also slide numbers on each slide. Thanks, Martin From nobody Mon Jul 18 02:12: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 4AF1812D5A1 for ; Mon, 18 Jul 2016 02:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 KttWjV9WF5Om for ; Mon, 18 Jul 2016 02:12:23 -0700 (PDT) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by ietfa.amsl.com (Postfix) with ESMTP id CE50A12D513 for ; Mon, 18 Jul 2016 02:12:18 -0700 (PDT) Received: from [10.30.2.111] ([10.30.2.111] verified) by sssup.it (CommuniGate Pro SMTP 6.0.10) with ESMTP id 112712076 for sfc@ietf.org; Mon, 18 Jul 2016 11:12:18 +0200 To: sfc@ietf.org From: Barbara Martini Message-ID: <45bd4140-e353-74d2-2c3c-519354227647@cnit.it> Date: Mon, 18 Jul 2016 11:12:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3C143BAB29118D50B3553675" Archived-At: Subject: [sfc] CFP - Deadline extended - The 2nd IEEE Workshop on Orchestration for Software-Defined Infrastructures (O4SDI-2) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2016 09:12:26 -0000 This is a multi-part message in MIME format. --------------3C143BAB29118D50B3553675 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ---------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CFP ---------------------------------------------------------------------------------------------- ****** DEADLINE Extended to July 31, 2016 ****** CALL FOR PAPERS 2nd IEEE Workshop on Orchestration for Software-Defined Infrastructures (O4SDI-2) To be held in conjunction with the 2016 IEEE Conference on Network Function Virtualization and Software Defined Networks (IEEE NFV-SDN 2016) November 7, 2016 - Palo Alto, California, USA http://o4sdi.unibo.it/o4sdi2 ------------------------------------------------------------------------- IMPORTANT DATES Paper submission deadline: July 31, 2016 (EXTENDED) Acceptance notification: September 16, 2016 Camera-ready papers: October 7, 2016 SUBMISSION INFORMATION Paper submissions are handled on-line through the EDAS system: https://edas.info/newPaper.php?c=22175&track=81344 ----------------------------------------------------------------------- SCOPE The current industry trend of convergence between computing and networking eco-systems clearly shows that software will play an unprecedented dominant role also in future communication environments. Computing, storage, and connectivity services, as well as any other present and future application instances, will be deployed in the form of virtualized assets within a software-defined infrastructure running on top of general-purpose processing and communication hardware, all managed and made available under the cloud “As A Service†paradigm. This technological convergence and infrastructure sharing between the computing and communication systems portend a scenario with a “fog†of micro-clouds composed of generalized virtual functions providing both applications and network services that supplement those deployed in traditional cloud datacenters. The Second IEEE Workshop on Orchestration for Software-Defined Infrastructures (O4SDI) addresses the challenges that will facilitate orchestration and programmability of generalized virtual functions in Software Defined Infrastructures (SDI), enabling cloud and network providers to deploy integrated services across different resource domains. Orchestration mechanisms will facilitate the live deployment and lifecycle management of these virtual elements, at the application level, the server level, and the network level within a single domain and across multiple domains. Without such orchestration it will not be possible to enable dynamic establishment of generalized virtual function chains, according to service requirements. These challenges of orchestration are many-fold, with many open questions that need to be addressed in the areas of: - network "softwarization," which requires unified management of computing, storage, and network resources for the effective deployment, lifecycle management, and run-time configuration of generalized virtual functions; - abstraction models and open standard interfaces, needed for assuring vendor interoperability; - adaptation and optimization mechanisms, which must be enforced at global and/or local level for coping with user demand, application requirements, resource unavailability, etc. O4SDI aims at providing an international forum for researchers and practitioners from academia, industry, network operators, and service providers to discuss and address the challenges deriving from such emerging scenario where systems, processes, and workflows used in both computing and communications domains are converging. ------------------------------------------------------------------------- TOPICS OF INTEREST Due to the highly interdisciplinary scope of the workshop, contributions are expected from both computing and network-oriented research communities, with the aim of facilitating discussion, cross- fertilization and exchange of ideas and practices, and successfully promote innovative solutions toward a real programmatic use of software- defined infrastructures as a whole. Contributions that discuss lessons learnt and best practices, describe practical deployment and implementation experiences, and demonstrate innovative use-cases are especially encouraged for presentation and publication. We are particularly interested in papers that cover, but are not limited to, the following topics: - single domain and cross domain orchestration issues - integrated network and computing resource control and management - control and abstraction of heterogeneous networks - orchestration in SDN/NFV - run-time orchestration - orchestration for next-generation IP and optical networks - orchestration in 5G networks - QoS/QoE in software-defined infrastructures - orchestration for high-availability and resilience in software-defined infrastructures - intent-based orchestration - dynamic service composition and delivery - network programmability for service chaining - software engineering and operating systems techniques applied to orchestration - description, specification, and abstraction languages for orchestration - optimal orchestration algorithms - context-aware orchestration - functional architectures of orchestrating elements - testbed experiments on orchestrations - performance evaluation of orchestration elements - standardization issues in orchestration ------------------------------------------------------------------------- WORKSHOP CO-CHAIRS Stuart Clayman, University College London, UK - s.clayman@ucl.ac.uk Walter Cerroni, University of Bologna, Italy - walter.cerroni@unibo.it Barbara Martini, CNIT, Pisa, Italy - barbara.martini@cnit.it Federica Paganelli, CNIT, Firenze, Italy - federica.paganelli@cnit.it TECHNICAL PROGRAM COMMITEE Giuseppe Bianchi, University of Rome Tor Vergata, Italy Roberto Bifulco, NEC, Germany Amina Boubendir, Orange Labs Paris, France Sanda Buda, IBM, Ireland Franco Callegati, University of Bologna, Italy Hakki Cankaya, Fujitsu Network Communications, USA Ramon Casellas, CTTC, Spain Maurizio Casoni, University of Modena and Reggio Emilia, Italy Piero Castoldi, Scuola Superiore Sant’Anna, Italy Prosper Chemouil, Orange Labs, France Chiara Contoli, University of Bologna, Italy Flavio Esposito, Saint Louis University, USA Luca Foschini, University of Bologna, Italy Molka Gharbaoui, Scuola Superiore Sant’Anna, Itally Imen Grida BenYahia, Orange Labs, France Riccardo Guerzoni, DoCoMo Eurolab, Germany Vatche Ishakian, IBM, USA Slawomir Kuklinski, Orange Poland, Poland Lefteris Mamatas, University of Macedonia, Greece Antonio Manzalini, Telecom Italia, Italy Catalin Meirosu, Ericsson, Sweden Paolo Monti, KTH, Sweden Julius Mueller, AT&T, USA Jordi Ortiz, Univ Murcia, Spain Francesca Paradiso, University of Florence, Italy Fulvio Risso, Politecnico di Torino, Italy Javier Rubio-Loyola, CINVESTAV Tamaulipas, Mexico Stefano Secci, University Pierre et Marie Curie, France Joan Serrat, Universitat Politècnica de Catalunya, Spain Antonio Fernando Skarmeta Gomez, University of Murcia, Spain Joao Soares, Ericsson, Sweden Mauro Tortonesi, University of Ferrara, Italy Daphne Tuncer, University College London, UK Ishan Vaishnavi, Huawei, Germany Mohammed Faten Zhani, University of Waterloo, Canada ------------------------------------------------------------------------- AUTHOR GUIDELINES Prospective authors are invited to submit high-quality, original technical papers for presentation at the workshop and publication in the O4SDI Proceedings and IEEE Xplore. Papers must be written in English, unpublished and not submitted elsewhere. Full papers must be formatted as the standard IEEE double-column conference template. All final submissions should have a maximum paper length of six (6) printed pages (10-point font), including figures, without incurring additional page charges. To be published in the Workshop Proceedings and to be eligible for publication in IEEE Xplore, at least one author of an accepted paper is required to register and present the paper at the workshop. The IEEE reserves the right to exclude a paper from distribution after the conference (including its removal from IEEE Xplore) if the paper is not presented at the conference. Papers are reviewed on the basis that they do not contain plagiarized material and have not been submitted to any other conference at the same time (double submission). For additional author guidelines, please refer to: http://nfvsdn2016.ieee-nfvsdn.org/authors/call-for-papers/submission-guidelines/ --------------3C143BAB29118D50B3553675 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

----------------------------------------------------------------------------------------------
 Please accept our apologies if you receive multiple copies of this CFP
----------------------------------------------------------------------------------------------

  ****** DEADLINE Extended to July 31, 2016 ******

  CALL FOR PAPERS

  2nd IEEE Workshop on
  Orchestration for Software-Defined Infrastructures (O4SDI-2)

  To be held in conjunction with the
  2016 IEEE Conference on Network Function Virtualization and Software
  Defined Networks (IEEE NFV-SDN 2016)

  November 7, 2016 - Palo Alto, California, USA

  http://o4sdi.unibo.it/o4sdi2

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

  IMPORTANT DATES

  Paper submission deadline:  July 31, 2016 (EXTENDED)
  Acceptance notification:    September 16, 2016
  Camera-ready papers:        October 7, 2016


  SUBMISSION INFORMATION

  Paper submissions are handled on-line through the EDAS system:

  https://edas.info/newPaper.php?c=22175&track=81344

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

  SCOPE

  The current industry trend of convergence between computing and
  networking eco-systems clearly shows that software will play an
  unprecedented dominant role also in future communication environments.
  Computing, storage, and connectivity services, as well as any other
  present and future application instances, will be deployed in the form
  of virtualized assets within a software-defined infrastructure running
  on top of general-purpose processing and communication hardware, all
  managed and made available under the cloud “As A Service†paradigm.
  This technological convergence and infrastructure sharing between the
  computing and communication systems portend a scenario with a “fog†of
  micro-clouds composed of generalized virtual functions providing both
  applications and network services that supplement those deployed in
  traditional cloud datacenters.

  The Second IEEE Workshop on Orchestration for Software-Defined
  Infrastructures (O4SDI) addresses the challenges that will facilitate
  orchestration and programmability of generalized virtual functions in
  Software Defined Infrastructures (SDI), enabling cloud and network
  providers to deploy integrated services across different resource
  domains. Orchestration mechanisms will facilitate the live deployment
  and lifecycle management of these virtual elements, at the application
  level, the server level, and the network level within a single domain
  and across multiple domains. Without such orchestration it will not
  be possible to enable dynamic establishment of generalized virtual
  function chains, according to service requirements.

  These challenges of orchestration are many-fold, with many open
  questions that need to be addressed in the areas of:
    -  network "softwarization," which requires unified management of
       computing, storage, and network resources for the effective
       deployment, lifecycle management, and run-time configuration of
       generalized virtual functions;
    -  abstraction models and open standard interfaces, needed for
       assuring vendor interoperability;
    -  adaptation and optimization mechanisms, which must be enforced at
       global and/or local level for coping with user demand, application
       requirements, resource unavailability, etc.

  O4SDI aims at providing an international forum for researchers and
  practitioners from academia, industry, network operators, and service
  providers to discuss and address the challenges deriving from such
  emerging scenario where systems, processes, and workflows used in both
  computing and communications domains are converging.

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

  TOPICS OF INTEREST

  Due to the highly interdisciplinary scope of the workshop,
  contributions are expected from both computing and network-oriented
  research communities, with the aim of facilitating discussion, cross-
  fertilization and exchange of ideas and practices, and successfully
  promote innovative solutions toward a real programmatic use of software-
  defined infrastructures as a whole. Contributions that discuss lessons
  learnt and best practices, describe practical deployment and
  implementation experiences, and demonstrate innovative use-cases are
  especially encouraged for presentation and publication.

  We are particularly interested in papers that cover, but are not
  limited to, the following topics:
    -  single domain and cross domain orchestration issues
    -  integrated network and computing resource control and management
    -  control and abstraction of heterogeneous networks
    -  orchestration in SDN/NFV
    -  run-time orchestration
    -  orchestration for next-generation IP and optical networks
    -  orchestration in 5G networks
    -  QoS/QoE in software-defined infrastructures
    -  orchestration for high-availability and resilience in
       software-defined infrastructures
    -  intent-based orchestration
    -  dynamic service composition and delivery
    -  network programmability for service chaining
    -  software engineering and operating systems techniques applied
       to orchestration
    -  description, specification, and abstraction languages
       for orchestration
    -  optimal orchestration algorithms
    -  context-aware orchestration
    -  functional architectures of orchestrating elements
    -  testbed experiments on orchestrations
    -  performance evaluation of orchestration elements
    -  standardization issues in orchestration

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

  WORKSHOP CO-CHAIRS

  Stuart Clayman, University College London, UK - s.clayman@ucl.ac.uk
  Walter Cerroni, University of Bologna, Italy - walter.cerroni@unibo.it
  Barbara Martini, CNIT, Pisa, Italy - barbara.martini@cnit.it
  Federica Paganelli, CNIT, Firenze, Italy - federica.paganelli@cnit.it


  TECHNICAL PROGRAM COMMITEE

  Giuseppe Bianchi, University of Rome Tor Vergata, Italy
  Roberto Bifulco, NEC, Germany
  Amina Boubendir, Orange Labs Paris, France
  Sanda Buda, IBM, Ireland
  Franco Callegati, University of Bologna, Italy
  Hakki Cankaya, Fujitsu Network Communications, USA
  Ramon Casellas, CTTC, Spain
  Maurizio Casoni, University of Modena and Reggio Emilia, Italy
  Piero Castoldi, Scuola Superiore Sant’Anna, Italy
  Prosper Chemouil, Orange Labs, France
  Chiara Contoli, University of Bologna, Italy
  Flavio Esposito, Saint Louis University, USA
  Luca Foschini, University of Bologna, Italy
  Molka Gharbaoui, Scuola Superiore Sant’Anna, Itally
  Imen Grida BenYahia, Orange Labs, France
  Riccardo Guerzoni, DoCoMo Eurolab, Germany
  Vatche Ishakian, IBM, USA
  Slawomir Kuklinski, Orange Poland, Poland
  Lefteris Mamatas, University of Macedonia, Greece
  Antonio Manzalini, Telecom Italia, Italy
  Catalin Meirosu, Ericsson, Sweden
  Paolo Monti, KTH, Sweden
  Julius Mueller, AT&T, USA
  Jordi Ortiz, Univ Murcia, Spain
  Francesca Paradiso, University of Florence, Italy
  Fulvio Risso, Politecnico di Torino, Italy
  Javier Rubio-Loyola, CINVESTAV Tamaulipas, Mexico
  Stefano Secci, University Pierre et Marie Curie, France
  Joan Serrat, Universitat Politècnica de Catalunya, Spain
  Antonio Fernando Skarmeta Gomez, University of Murcia, Spain
  Joao Soares, Ericsson, Sweden
  Mauro Tortonesi, University of Ferrara, Italy
  Daphne Tuncer, University College London, UK
  Ishan    Vaishnavi, Huawei, Germany
  Mohammed Faten Zhani, University of Waterloo, Canada

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

  AUTHOR GUIDELINES

  Prospective authors are invited to submit high-quality, original technical
  papers for presentation at the workshop and publication in the O4SDI
  Proceedings and IEEE Xplore. Papers must be written in English,
  unpublished and not submitted elsewhere. Full papers must be formatted
  as the standard IEEE double-column conference template. All final
  submissions should have a maximum paper length of six (6) printed pages
  (10-point font), including figures, without incurring additional page
  charges.

  To be published in the Workshop Proceedings and to be eligible for
  publication in IEEE Xplore, at least one author of an accepted paper is
  required to register and present the paper at the workshop. The IEEE
  reserves the right to exclude a paper from distribution after the
  conference (including its removal from IEEE Xplore) if the paper is not
  presented at the conference. Papers are reviewed on the basis that they
  do not contain plagiarized material and have not been submitted to any
  other conference at the same time (double submission).

  For additional author guidelines, please refer to:

  http://nfvsdn2016.ieee-nfvsdn.org/authors/call-for-papers/submission-guidelines/

--------------3C143BAB29118D50B3553675-- From nobody Mon Jul 18 08:22: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 0999712DAA4 for ; Mon, 18 Jul 2016 08:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9gTqhOy_wYl for ; Mon, 18 Jul 2016 08:22:04 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C52912DD7A for ; Mon, 18 Jul 2016 08:02:34 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6IExe6l012022; Mon, 18 Jul 2016 08:02:32 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 247j9jqe9v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2016 08:02:32 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Jul 2016 18:02:29 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 18 Jul 2016 18:02:28 +0300 From: Tal Mizrahi To: "fbrockne@cisco.com" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlw== Date: Mon, 18 Jul 2016 15:02:28 +0000 Message-ID: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_859929d79ea24e1b9df0f3cdccd66d31ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-18_07:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607180167 Archived-At: Subject: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2016 15:22:07 -0000 --_000_859929d79ea24e1b9df0f3cdccd66d31ILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Frank, I have a question regarding draft-brockners-proof-of-transit. (https://tools.ietf.org/html/draft-brockners-proof-of-transit-01) Unless I am missing something, the proposed mechanism does not cryptographi= cally protect the packet itself, right? It seems that there is nothing that cryptographically binds the polynomial-= based-metadata to the packet content. It appears that if you have a legitimate packet that has been stamped with = the proof-of-transport, a man-in-the-middle attacker can simply replace the= packet payload with a previously stored packet that has not passed the ent= ire service chain, thereby bypassing the service chain. How can this threat be avoided? Cheers, Tal. --_000_859929d79ea24e1b9df0f3cdccd66d31ILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Frank,

 

I have a question regarding draft-brockners-proof-of= -transit.

(https://tools.ietf.org/html/draft-brockners-proof-= of-transit-01)

 

Unless I am missing something, the proposed mechanis= m does not cryptographically protect the packet itself, right?

It seems that there is nothing that cryptographicall= y binds the polynomial-based-metadata to the packet content.

 

It appears that if you have a legitimate packet that= has been stamped with the proof-of-transport, a man-in-the-middle attacker= can simply replace the packet payload with a previously stored packet that= has not passed the entire service chain, thereby bypassing the service chain.

 

How can this threat be avoided?

 

Cheers,

Tal.

--_000_859929d79ea24e1b9df0f3cdccd66d31ILEXCH02marvellcom_-- From nobody Mon Jul 18 08:37: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 5E2D112DA48 for ; Mon, 18 Jul 2016 08:37:56 -0700 (PDT) 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 TBPIgfek_wft for ; Mon, 18 Jul 2016 08:37:50 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 2206712DA2C for ; Mon, 18 Jul 2016 08:25:00 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q83so162851114iod.1 for ; Mon, 18 Jul 2016 08:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BcA4uM4zcG9qqt4Yj4qCBPpESou0pYrGVOjdAmmbT0c=; b=mMwuf3QvBREu+HIHk7D7LIAImk/uTgWVIKPGKGnq/i3p3qacpGQJorLjEvfY5vDWpk f8LMQnbm1d7dgPgoS9ni8Toe1eRWxx5mt0cFhiG5uQTuiiKzzNwoLNLFBDhLoATfhpDO X8SvGCoSl+rvAkeRWzP3Esj7IJ0e/3dabEJv3GAMjQc0xsM+y+EinkCciAIkSUoy/Kzo TZoJkIeoa4vZJRDgeAnDErVWSB92ItzdgyQm5+/vfYdNe/zaUMM/2tOnxuZUDdKzvVLp lVkQGKuyJ4oJQY0YXRU4zRbB54SKpzpYTglDQy/i8WxaY4p1Bfm0yN5QAJA9AwgUsT9d 7vWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BcA4uM4zcG9qqt4Yj4qCBPpESou0pYrGVOjdAmmbT0c=; b=N2OcLR02LpFm3XTDcYwM2XSlxVS6HiAQwqL0b+3rTTadRUDsiR26RQ0dTE/WHOo+4e IdmhqO9Asrq3mi9R1dSRAs2rQr/iD8J2fY1hy7Er8M7j32T14lbKWkMSGN3zxNd5KkH9 eaEMmSpNzqr2Lty0/JZ1tvZU5P5sZfgyvKjCnXRDDkeW7yHrZc5nlHhFOpIfjaL7OM+E gV4hlTioqAjpJKqJIvvYBdeBb5sDBdW2hQkK2vLXOswFeQtZg3Iaw8hb3NCUYHpVyBNK KncuXPZjfYjM4NOSlRVE7Fwf0ZvAUqkB9LmxqaDet27Lytw1GDwbAmnPItv/DY0AO7Wr i6kA== X-Gm-Message-State: ALyK8tJQzCXyUOfNaRQg2n3NeNonqa8IFncP82k03d6g3CEYplUy8I+JBNSNIILMuD2MqXaaK1iZCT4b0vIFaw== X-Received: by 10.107.47.67 with SMTP id j64mr34107102ioo.21.1468855499207; Mon, 18 Jul 2016 08:24:59 -0700 (PDT) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.227.43 with HTTP; Mon, 18 Jul 2016 08:24:58 -0700 (PDT) In-Reply-To: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> From: Dhruv Dhody Date: Mon, 18 Jul 2016 17:24:58 +0200 X-Google-Sender-Auth: 2GEJ1VJu4D9ve5vlxu3-LzJxQYg Message-ID: To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=001a113a71e041b7ee0537ea923b Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2016 15:37:56 -0000 --001a113a71e041b7ee0537ea923b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support for adoption! Regards, Dhruv On Wed, Jul 6, 2016 at 3:17 PM, Jim Guichard (jguichar) wrote: > Dear WG: > > > This email serves as a call for WG adoption of > draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption > will run for 2 weeks ending 7/25/2016. > > > > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a WG document simply means that the WG > will focus its efforts on that particular draft going forward, and use th= at > document for resolving open issues and documenting the WG=E2=80=99s decis= ions. > > > > Please indicate whether you support adoption for not, and if not why. > Issues you have with the current document itself can also be raised, but > they should be raised in the context of what should be changed in the > document going forward, rather than a pre-condition for adoption. > > > > Finally, now is also a good time to poll for knowledge of any IPR that > applies to this draft, in line with the IPR disclosure obligations for WG > participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If yo= u > are listed as a document author please respond to this email (to the > chairs) whether or not you are aware of any relevant IPR. > > > Thanks! > > > SFC Chairs > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --001a113a71e041b7ee0537ea923b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support for adoption!

Regards,
Dhruv=C2=A0

On Wed, Jul 6, 2016 at 3:17 PM, Jim Guic= hard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:


This email serves as a ca= ll for WG adoption of draft-penno-sfc-hierarchical-06 as a WG document. The= call for adoption will run for 2 weeks ending 7/25/2016.

=C2=A0

Please note that this is = a call for adoption, and not a last call for content of the document. Adopt= ing a WG document simply means that the WG will focus its efforts on that particular draft going forward, and = use that document for resolving open issues and documenting the WG=E2=80=99= s decisions.

=C2=A0

Please indicate whether y= ou support adoption for not, and if not why. Issues you have with the curre= nt document itself can also be raised, but they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption.=C2=A0

=C2=A0

Finally, now is also a good time to poll = for knowledge of any IPR that applies to this draft, in line with the IPR d= isclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed a= s a document author please respond to this email (to the chairs) whether or= not you are aware of any relevant IPR.


Thanks!


SFC Chairs


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


--001a113a71e041b7ee0537ea923b-- From nobody Mon Jul 18 08:45: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 BAF7B12D9FF for ; Mon, 18 Jul 2016 08:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 c3xpy-yKXdlb for ; Mon, 18 Jul 2016 08:45:02 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7545312D09D for ; Mon, 18 Jul 2016 08:39:47 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 1C07EEF62D067; Mon, 18 Jul 2016 15:39:44 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6IFdkjV013923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 15:39:46 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u6IFdkBT022230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jul 2016 15:39:46 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.234]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 18 Jul 2016 11:39:46 -0400 From: "Dolganow, Andrew (Nokia - SG)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR4QppOx055wb8+kOcosgzr1KJC6AeUyJO Date: Mon, 18 Jul 2016 15:39:45 +0000 Message-ID: References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E941756F1B3D467DBA58F8D6B8C389E9nokiacom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2016 15:45:04 -0000 --_000_E941756F1B3D467DBA58F8D6B8C389E9nokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 Andrew Sent from my iPhone On Jul 18, 2016, at 5:38 PM, Dhruv Dhody > wrote: Support for adoption! Regards, Dhruv On Wed, Jul 6, 2016 at 3:17 PM, Jim Guichard (jguichar) > wrote: Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-hierarchical= -06 as a WG document. The call for adoption will run for 2 weeks ending 7/2= 5/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG=92s decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs _______________________________________________ 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_E941756F1B3D467DBA58F8D6B8C389E9nokiacom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1

Andrew

Sent from my iPhone

On Jul 18, 2016, at 5:38 PM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:

Support for adoption!

Regards,
Dhruv 

On Wed, Jul 6, 2016 at 3:17 PM, Jim Guichard (jg= uichar) <jguichar@cisco.= com> wrote:

Dear WG:


This email serves as a ca= ll for WG adoption of draft-penno-sfc-hierarchical-06 as a WG document. The= call for adoption will run for 2 weeks ending 7/25/2016.

 

Please note that this is = a call for adoption, and not a last call for content of the document. Adopt= ing a WG document simply means that the WG will focus its efforts on that particular draft going forward, and use = that document for resolving open issues and documenting the WG=92s decision= s.

 

Please indicate whether y= ou support adoption for not, and if not why. Issues you have with the curre= nt document itself can also be raised, but they should be raised in the context of what should be changed in the docu= ment going forward, rather than a pre-condition for adoption. <= u>

 

Finally, now is also a good time to poll = for knowledge of any IPR that applies to this draft, in line with the IPR d= isclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed a= s a document author please respond to this email (to the chairs) whether or= not you are aware of any relevant IPR.


Thanks!


SFC Chairs


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


_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_E941756F1B3D467DBA58F8D6B8C389E9nokiacom_-- From nobody Mon Jul 18 08:48: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 2B75D12D0D8 for ; Mon, 18 Jul 2016 08:48:41 -0700 (PDT) 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 QvUd22RVL4o8 for ; Mon, 18 Jul 2016 08:48:38 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89D712DAC5 for ; Mon, 18 Jul 2016 08:46:31 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id w127so185869987vkh.2 for ; Mon, 18 Jul 2016 08:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pQW8YS3WVLgzEkYeK+JJ3pBbZESpeO5eVjLmgWcNToo=; b=DbaclJXLnvL4mgb6sosxYdmtn3pE5WFPlQ0xbC0ZTSjgPifxvYJ8AvxDvmyy75bfgg NhdruOoWclP7GfDiOhWb1sxF69W1SMU6OhAtW014bN7QMRj/LW+G8GzJd1tyOb0MAMcP J3rmFP6GhPK3VEzMX+xPzI1pbYJbr1C70S9M2thMSmjNYDkkN7O449RW5hXWpbcQB4xh iYDgASK3pPX/WVU74A3qjxoTfolrVn3k60JiQ0dWX8V93gydiVfNxiKecHSMWvbW5IpI 94irL3vCl8JiqU3eWZgsvtNnD9jeg8bcjCyAFgVOamkBm2SAfeGlbCWGlz3Aun6PxikU NZrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pQW8YS3WVLgzEkYeK+JJ3pBbZESpeO5eVjLmgWcNToo=; b=AJadefkIA9mcdtGhJduhsmO21XBdX5sPJTqEVhlz7wqA+YmQtqvu+CFjpKjzWIYViV wXQS3rVEezLhdOVqtsMlEgW3JxT0skz39PhM/S2SwQ+gPK5TEduoCcygLjVjjy80wBSG YY9MgfNMOtR2mwm04EyJauVBf4W6GpRxyROlbO7w67Y6NMFocJ89Vmm1oMlBWqDJ0myx GmMT3ONvO+e0bJb0ey4RmQ/j78xS5RsnzheCzDfSnhzjnAiof5jNVsV4jFDAHExLWq2X T5Tf4ceTqWYEa1/tEa5nLeR1hP7W/9BiI4pxmH9r5ZxEosdQak6Zy2CRtR4lc0QWTVzu DU8Q== X-Gm-Message-State: ALyK8tJxf6muSE/V6p30B1Sak4IdcBT5BGOP6b5iXeAxbOWJEJgn56gZfgXlJ2RCQDMHYqyPuEbKCx62lAI5RA== X-Received: by 10.31.98.135 with SMTP id w129mr15814010vkb.106.1468856791091; Mon, 18 Jul 2016 08:46:31 -0700 (PDT) MIME-Version: 1.0 References: <3404B156-BE82-48CE-B34F-153318837E78@cisco.com> In-Reply-To: From: Anil Kumar Date: Mon, 18 Jul 2016 15:46:21 +0000 Message-ID: To: "Dolganow, Andrew (Nokia - SG)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c094e68424dd30537eadf23 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2016 15:48:41 -0000 --94eb2c094e68424dd30537eadf23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 With Regards Anil Kumar S N On Mon, Jul 18, 2016, 21:15 Dolganow, Andrew (Nokia - SG) < andrew.dolganow@nokia.com> wrote: > +1 > > > Andrew > > Sent from my iPhone > > On Jul 18, 2016, at 5:38 PM, Dhruv Dhody wrote: > > Support for adoption! > > Regards, > Dhruv > > On Wed, Jul 6, 2016 at 3:17 PM, Jim Guichard (jguichar) < > jguichar@cisco.com> wrote: > >> Dear WG: >> >> >> This email serves as a call for WG adoption of >> draft-penno-sfc-hierarchical-06 as a WG document. The call for adoption >> will run for 2 weeks ending 7/25/2016. >> >> >> >> Please note that this is a call for adoption, and not a last call for >> content of the document. Adopting a WG document simply means that the WG >> will focus its efforts on that particular draft going forward, and use t= hat >> document for resolving open issues and documenting the WG=E2=80=99s deci= sions. >> >> >> >> Please indicate whether you support adoption for not, and if not why. >> Issues you have with the current document itself can also be raised, but >> they should be raised in the context of what should be changed in the >> document going forward, rather than a pre-condition for adoption. >> >> >> >> Finally, now is also a good time to poll for knowledge of any IPR that >> applies to this draft, in line with the IPR disclosure obligations for W= G >> participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If y= ou >> are listed as a document author please respond to this email (to the >> chairs) whether or not you are aware of any relevant IPR. >> >> >> Thanks! >> >> >> SFC Chairs >> >> _______________________________________________ >> 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 > --94eb2c094e68424dd30537eadf23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1

With Regards
Anil Kumar S N


On Mon, Jul 18, 2016, 21:15= Dolganow, Andrew (Nokia - SG) <andrew.dolganow@nokia.com> wrote:
+1


Andrew

Sent from my iPhone

On Jul 18, 2016, at 5:38 PM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:

Support for adoption!

Regards,
Dhruv=C2=A0

On Wed, Jul 6, 2016 at 3:17 PM, Jim Guichard (jg= uichar) <jguichar@cisco.= com> wrote:

Dear WG:


This email serves as a ca= ll for WG adoption of draft-penno-sfc-hierarchical-06 as a WG document. The= call for adoption will run for 2 weeks ending 7/25/2016.

=C2=A0

Please note that this is = a call for adoption, and not a last call for content of the document. Adopt= ing a WG document simply means that the WG will focus its efforts on that particular draft going forward, and use = that document for resolving open issues and documenting the WG=E2=80=99s de= cisions.

=C2=A0

Please indicate whether y= ou support adoption for not, and if not why. Issues you have with the curre= nt document itself can also be raised, but they should be raised in the context of what should be changed in the docu= ment going forward, rather than a pre-condition for adoption.=C2=A0<= u>

=C2=A0

Finally, now is also a good time to poll = for knowledge of any IPR that applies to this draft, in line with the IPR d= isclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed a= s a document author please respond to this email (to the chairs) whether or= not you are aware of any relevant IPR.


Thanks!


SFC Chairs


_______________________________________________
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
--94eb2c094e68424dd30537eadf23-- From nobody Mon Jul 18 09:40: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 D8CD512D987 for ; Mon, 18 Jul 2016 09:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 h07XywmR0pYk for ; Mon, 18 Jul 2016 09:39:56 -0700 (PDT) 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 B9E7412B010 for ; Mon, 18 Jul 2016 09:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11643; q=dns/txt; s=iport; t=1468859996; x=1470069596; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=I0OormMp5DGBWgVeBFfpRFi6adiaMPPbwKb4G7dTCIY=; b=IfrNKGYkizqTC6QPN/vznIpmriIF2vVwXk6/ncjMU7tZst3gCk1SAWnd 8JCnkAxVoaDS3jqV1qWxhT6XITjLHZJQQHkeE9A5s2HLjfduTtVipu8d+ N4paQz34qpLg7Ds1TJZsH0PWNWg4qbtkQ0i0LB6FBw+SG0h3oS3/LLP8o k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgBeBY1X/5xdJa1bgnFOVnwGs16FB?= =?us-ascii?q?IF5IoV4AoE0OBQBAQEBAQEBZSeEXAEBBS1cAgEIEQQBASgHMhQJCAEBBAESCIg?= =?us-ascii?q?oDr4rAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhBIRAVKFJQWZJAGGEohFj?= =?us-ascii?q?z6QHQEeNoILHIFMboYtNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,384,1464652800"; d="scan'208,217";a="298384024" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2016 16:39:55 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6IGdt4F028081 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jul 2016 16:39:55 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; Mon, 18 Jul 2016 11:39:55 -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; Mon, 18 Jul 2016 11:39:55 -0500 From: "Frank Brockners (fbrockne)" To: Tal Mizrahi , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuw Date: Mon, 18 Jul 2016 16:39:55 +0000 Message-ID: <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> In-Reply-To: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> Accept-Language: de-DE, 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.243.120] Content-Type: multipart/alternative; boundary="_000_0cae48f5873c48dc8f5cd17e22a3e032XCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2016 16:39:59 -0000 --_000_0cae48f5873c48dc8f5cd17e22a3e032XCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal, thanks for your email. We need to differentiate * proving the path packets take, from * performing an integrity check on one or a set of packets. The former is what we do with POT - the latter is something that would typi= cally be up to the application, especially given that the content of the pa= cket might even be transformed/changed as it traverses the network. That sa= id, what the application could choose to do is use the unique sequence numb= er of POT (i.e. the identifier of the second, public polynomial - called "= random" in the draft) in the packet to "link/associate" the content to this= sequence number (i.e. "random") to detect whether the content of the packe= t has been corrupted or changed. Regards, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Montag, 18. Juli 2016 17:02 To: Frank Brockners (fbrockne) ; draft-brockners-proof-= of-transit@tools.ietf.org; sfc@ietf.org Subject: Question regarding Proof of Transit draft Dear Frank, I have a question regarding draft-brockners-proof-of-transit. (https://tools.ietf.org/html/draft-brockners-proof-of-transit-01) Unless I am missing something, the proposed mechanism does not cryptographi= cally protect the packet itself, right? It seems that there is nothing that cryptographically binds the polynomial-= based-metadata to the packet content. It appears that if you have a legitimate packet that has been stamped with = the proof-of-transport, a man-in-the-middle attacker can simply replace the= packet payload with a previously stored packet that has not passed the ent= ire service chain, thereby bypassing the service chain. How can this threat be avoided? Cheers, Tal. --_000_0cae48f5873c48dc8f5cd17e22a3e032XCHRCD008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal,

 

thanks for your email. We need to differentiate

· &nb= sp;     proving the path packets take, from

· &nb= sp;     performing an integrity check on one or a set o= f packets.

The former is what we do with POT – the latter is= something that would typically be up to the application, especially given = that the content of the packet might even be transformed/changed as it traverses the network. That said, what the appli= cation could choose to do is use the unique sequence number of POT  (i= .e. the identifier of the second, public polynomial – called “r= andom” in the draft) in the packet to “link/associate” the content to this sequence number (i.e. “random”) to detect = whether the content of the packet has been corrupted or changed.=

 

Regards, Frank

 

 

 

From: Tal Mizrahi [mailto:talmi@marvell.com]
Sent: Montag, 18. Juli 2016 17:02
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Question regarding Proof of Transit draft=

 

Dear Frank,

 

I have a question regarding dra= ft-brockners-proof-of-transit.

(https://tools.ietf.org/html/d= raft-brockners-proof-of-transit-01)

 

Unless I am missing something, = the proposed mechanism does not cryptographically protect the packet itself= , right?

It seems that there is nothing = that cryptographically binds the polynomial-based-metadata to the packet co= ntent.

 

It appears that if you have a l= egitimate packet that has been stamped with the proof-of-transport, a man-i= n-the-middle attacker can simply replace the packet payload with a previous= ly stored packet that has not passed the entire service chain, thereby bypassing the service chain.<= /span>

 

How can this threat be avoided?=

 

Cheers,

Tal.

--_000_0cae48f5873c48dc8f5cd17e22a3e032XCHRCD008ciscocom_-- From nobody Mon Jul 18 09:52: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 A69A412D0B0 for ; Mon, 18 Jul 2016 09:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtHQaoSdsuPl for ; Mon, 18 Jul 2016 09:52:46 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF6A12D0DD for ; Mon, 18 Jul 2016 09:52:46 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6IGo6Mm010382; Mon, 18 Jul 2016 09:52:45 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0b-0016f401.pphosted.com with ESMTP id 247meefkmt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2016 09:52:44 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Jul 2016 19:52:42 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 18 Jul 2016 19:52:41 +0300 From: Tal Mizrahi To: "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIA= Date: Mon, 18 Jul 2016 16:52:41 +0000 Message-ID: <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> In-Reply-To: <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_32e24976a2974b5bac63f39eec6bfe18ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-18_07:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607180186 Archived-At: Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2016 16:52:53 -0000 --_000_32e24976a2974b5bac63f39eec6bfe18ILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank, Many thanks for the prompt response. >thanks for your email. We need to differentiate ** proving the path packets take, from ** performing an integrity check on one or a set of packets. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. >That said, what the application could choose to do is use the unique seque= nce number >of POT (i.e. the identifier of the second, public polynomial - called "ra= ndom" in the >draft) in the packet to "link/associate" the content to this sequence numb= er (i.e. >"random") to detect whether the content of the packet has been corrupted o= r changed. I don't understand how that resolves the threat above. Would appreciate if = you can explain further. Cheers, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Monday, July 18, 2016 6:40 PM To: Tal Mizrahi; draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.= org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for your email. We need to differentiate * proving the path packets take, from * performing an integrity check on one or a set of packets. The former is what we do with POT - the latter is something that would typi= cally be up to the application, especially given that the content of the pa= cket might even be transformed/changed as it traverses the network. That sa= id, what the application could choose to do is use the unique sequence numb= er of POT (i.e. the identifier of the second, public polynomial - called "= random" in the draft) in the packet to "link/associate" the content to this= sequence number (i.e. "random") to detect whether the content of the packe= t has been corrupted or changed. Regards, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Montag, 18. Juli 2016 17:02 To: Frank Brockners (fbrockne) >; draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: Question regarding Proof of Transit draft Dear Frank, I have a question regarding draft-brockners-proof-of-transit. (https://tools.ietf.org/html/draft-brockners-proof-of-transit-01) Unless I am missing something, the proposed mechanism does not cryptographi= cally protect the packet itself, right? It seems that there is nothing that cryptographically binds the polynomial-= based-metadata to the packet content. It appears that if you have a legitimate packet that has been stamped with = the proof-of-transport, a man-in-the-middle attacker can simply replace the= packet payload with a previously stored packet that has not passed the ent= ire service chain, thereby bypassing the service chain. How can this threat be avoided? Cheers, Tal. --_000_32e24976a2974b5bac63f39eec6bfe18ILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Frank,

 

Many thanks for the pr= ompt response.

 

>thanks for your em= ail. We need to differentiate

>= ;·     =   proving the path packets take, from

>= ;·     =   performing an integrity check on one o= r a set of packets.

 

 

Right, I am referring = to the former. The integrity check is not the issue.

Let’s say we hav= e:

- Packet A that went t= hrough the correct path and has a correct POT.

- Packet B that did no= t go through the correct path and does not have a correct POT.

 

The attacker can ̵= 6;launder’ packet B by replacing the (incorrect) POT of packet B with= the correct POT of packet A (and drop packet A).

Thus, packet B is veri= fied correctly, even though it did not go through the correct path.

 

 

>That said, what th= e application could choose to do is use the unique sequence number

>of POT  (i.e.= the identifier of the second, public polynomial – called “rand= om” in the

>draft) in the pack= et to “link/associate” the content to this sequence number (i.e= .

>“random̶= 1;) to detect whether the content of the packet has been corrupted or chang= ed.

 

 

I don’t understa= nd how that resolves the threat above. Would appreciate if you can explain = further.

 

Cheers,

Tal.=

 

From: Frank Br= ockners (fbrockne) [mailto:fbrockne@cisco.com]
Sent: Monday, July 18, 2016 6:40 PM
To: Tal Mizrahi; draft-brockners-proof-of-transit@tools.ietf.org; sf= c@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 = ;

thanks for your email.= We need to differentiate

·       proving the path packets take, from

·       performing an integrity check on one o= r a set of packets.

The former is what we = do with POT – the latter is something that would typically be up to t= he application, especially given that the content of the packet might even = be transformed/changed as it traverses the network. That said, what the application could choose to do is use the uni= que sequence number of POT  (i.e. the identifier of the second, public= polynomial – called “random” in the draft) in the packet= to “link/associate” the content to this sequence number (i.e. “random”) to detect whether the content of the packet ha= s been corrupted or changed.

 

Regards, Frank

 

 

 

From: Tal Mizrahi [mailto:talmi@marvell.com]
Sent: Montag, 18. Juli 2016 17:02
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Question regarding Proof of Transit draft

 

Dear Frank,

 

I have a question regarding draft-brockners-proof-of= -transit.

(https://tools.ietf.org/html/draft-brockners-proof-= of-transit-01)

 

Unless I am missing something, the proposed mechanis= m does not cryptographically protect the packet itself, right?

It seems that there is nothing that cryptographicall= y binds the polynomial-based-metadata to the packet content.

 

It appears that if you have a legitimate packet that= has been stamped with the proof-of-transport, a man-in-the-middle attacker= can simply replace the packet payload with a previously stored packet that= has not passed the entire service chain, thereby bypassing the service chain.

 

How can this threat be avoided?

 

Cheers,

Tal.

--_000_32e24976a2974b5bac63f39eec6bfe18ILEXCH02marvellcom_-- From sadara@cisco.com Mon Jul 18 16:10: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 710C112DB8C for ; Mon, 18 Jul 2016 16:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 11E0MXtLjMDW for ; Mon, 18 Jul 2016 16:10:48 -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 39D4D12DB93 for ; Mon, 18 Jul 2016 16:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9390; q=dns/txt; s=iport; t=1468883447; x=1470093047; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=zwU5fwS0YOJ0B993erLwI6BlTuPKNxDPyHQI34aLpqA=; b=OjBli3MfdhapK/vwbDh49BJ6EYce+kGhRumNfhTQYUI/LRgHovcDrfQx BSl6DRdEy+obZAraHqrmtekIvsy4NREzUXR3I0zro610X/9lRah66E7Fa 6tNGgW00ts3TAPzxQCWfasfFTGCjOLwl7iHso/PJWbTvpDL1qIySwXWCF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeBwB9YY1X/4MNJK1bgnFOgVizXIUEg?= =?us-ascii?q?XqGGgKBNToSAQEBAQEBAWUnhF0BBYEJAgEIRjIlAQEEAYhCvjQBAQEBAQEBAQI?= =?us-ascii?q?BAQEBAQEBAQEBHYYqhE2KGwWIIoYihR+FQQGJDYJzgl6CAo01kB0BJQItggscg?= =?us-ascii?q?UyHUX8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,386,1464652800"; d="scan'208,217";a="299390499" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 23:10:46 +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 u6INAkkM028397 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jul 2016 23:10:46 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 18 Jul 2016 18:10:45 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Mon, 18 Jul 2016 18:10:45 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugA== Date: Mon, 18 Jul 2016 23:10:45 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> In-Reply-To: <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.76.91] Content-Type: multipart/alternative; boundary="_000_D3B359A978D94sadaraciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2016 23:13:18 -0000 --_000_D3B359A978D94sadaraciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_D3B359A978D94sadaraciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3E1926044E72F74BA6004063620B75A2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Dear Tal,
Thank you for your interest in our work. More inline with [SD] .. = ;


Right, I am referring to the forme= r. The integrity check is not the issue.

Let’s say we have:

- Packet A that went through the c= orrect path and has a correct POT.

- Packet B that did not go through= the correct path and does not have a correct POT.

 

The attacker can ‘launder= 217; packet B by replacing the (incorrect) POT of packet B with the correct= POT of packet A (and drop packet A).

Thus, packet B is verified correct= ly, even though it did not go through the correct path.

[SD] This is valid scenario and we have certain in-built mitigation te= chniques and recommendations for the same. 
There are two scenarios here 

Partial Replay of POT data (Replaying intermediate CMLs)

Attacker cannot reuse few intermediate node’s POT values (from o= lder packet traces) as it would disrupt the POLY-3 construction. 
On the other hand if the attacker tries to replay entire sequence of C= ML values, he cannot still , because notice that verifier also has a secret= share of RND-1 and participates in the reconstruction of RND-3.
Verifier’s share of RND-3 is never on wire , so attacker cannot = just observe the packet traces to reuse and replay it. 

Total Replay of POT data (Replaying complete RND-2)

Another trick, attacker could do is by completely reusing RND-2 (but n= ot intermediate CML values)
In order to prevent the “Reply Attacks” , we recommend tha= t the RND-2 (generated per packet) be a combination (I.e. RND2 =3D “T= ime Stamp + RND number”)
So in case a passive attacker tries to replay one of the correct but o= lder RND-2, the verifier first could check the current timestamp against th= e timestamp retrieved from RND-2.
If the retrieved timestamp is older than current timestamp we drop/rai= se a flag ! 

There is still a small window , where the attacker could replay it wit= hin the valid time slice itself but by carefully choosing the time slice we= can make it nearly impossible for the attacker to replay.
For example , if the Time Stamp chosen is 32 bits , we could get one s= econds level precision in the time window . So it is highly impossible for = the attacker to replay within such a small time at such a high packet rates= . 

Also , the verifier could cache, if needed, certain number of previous= ly used RND-2 to mitigate replay attacks. 

Hope this clarifies. 
 
--_000_D3B359A978D94sadaraciscocom_-- From nobody Mon Jul 18 22:40: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 5747112D133 for ; Mon, 18 Jul 2016 22:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSbYvWDFpA6k for ; Mon, 18 Jul 2016 22:40:11 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A86612D0C5 for ; Mon, 18 Jul 2016 22:40:10 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6J5ZH1F003486; Mon, 18 Jul 2016 22:40:08 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0b-0016f401.pphosted.com with ESMTP id 2494s91y10-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2016 22:40:07 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jul 2016 08:40:04 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Tue, 19 Jul 2016 08:40:04 +0300 From: Tal Mizrahi To: "Sashank Dara (sadara)" , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEA Date: Tue, 19 Jul 2016 05:40:03 +0000 Message-ID: <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_36c193705f0a4443b57ac984ed29161eILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-19_02:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607190063 Archived-At: Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Jul 2016 05:40:13 -0000 --_000_36c193705f0a4443b57ac984ed29161eILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sashank, Thanks for the detailed response. I am not sure we are on the same page. The attack I was describing is not a replay attack. Here is a more detailed description of the attack: We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? Regarding the replay mechanism you described: >There is still a small window , where the attacker could replay it >within the valid time slice itself but by carefully choosing the time >slice we can make it nearly impossible for the attacker to replay. >For example , if the Time Stamp chosen is 32 bits , we could get >one seconds level precision in the time window . So it is highly >impossible for the attacker to replay within such a small time at >such a high packet rates. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_36c193705f0a4443b57ac984ed29161eILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sashank,<= /span>

 <= /p>

Thanks for the detailed r= esponse.

 <= /p>

I am not sure we are on t= he same page.

The attack I was describi= ng is not a replay attack.

 <= /p>

Here is a more detailed d= escription of the attack:

 <= /p>

We have two consecutive p= ackets, A and B:

- Packet A that went thro= ugh the correct path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also termina= tes packet A.

There is no replay here, = because the verifier receives the correct POT only once. The problem is tha= t the correct POT happens to arrive with packet B. L

Thus, packet B appears ok= ay to the verifier, even though it did not go through the correct path.

 <= /p>

Is there a way to mitigat= e this attack?

 <= /p>

 <= /p>

Regarding the replay mech= anism you described:

 <= /p>

>There is still a small = window , where the attacker could replay it

>within the valid time s= lice itself but by carefully choosing the time

>slice we can make it ne= arly impossible for the attacker to replay.

>For example , if the Ti= me Stamp chosen is 32 bits , we could get

>one seconds level preci= sion in the time window . So it is highly

>impossible for the atta= cker to replay within such a small time at

>such a high packet rate= s. 

 <= /p>

Do you mean that there is= a one-second-vulnerability for replay attacks?

One second is practically= forever.

Effective replay preventi= on is typically performed using a sequence number, with a sliding window to= allow out-of-order packets. Wouldn’t it be possible to incorporate such a sequence number into your mechanism?<= /p>

 <= /p>

 <= /p>

Thanks,=

Tal.

 <= /p>

 <= /p>

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-o= f-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,=

Thank you for your interest= in our work. More inline with [SD] .. 

 

 

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 

[SD] This is valid scenario= and we have certain in-built mitigation techniques and recommendations for= the same. 

There are two scenarios her= e 

 

Partial Replay of POT da= ta (Replaying intermediate CMLs)

 

Attacker cannot reuse few i= ntermediate node’s POT values (from older packet traces) as it would = disrupt the POLY-3 construction. 

On the other hand if the at= tacker tries to replay entire sequence of CML values, he cannot still , bec= ause notice that verifier also has a secret share of RND-1 and participates in the reconstruction of RND-3.

Verifier’s share of R= ND-3 is never on wire , so attacker cannot just observe the packet traces t= o reuse and replay it. 

 

Total Replay of POT data= (Replaying complete RND-2)<= /span>

 

Another trick, attacker cou= ld do is by completely reusing RND-2 (but not intermediate CML values)=

In order to prevent the = 220;Reply Attacks” , we recommend that the RND-2 (generated per packe= t) be a combination (I.e. RND2 =3D “Time Stamp + RND number”= ;)

So in case a passive attack= er tries to replay one of the correct but older RND-2, the verifier first c= ould check the current timestamp against the timestamp retrieved from RND-2.

If the retrieved timestamp = is older than current timestamp we drop/raise a flag ! 

 

There is still a small wind= ow , where the attacker could replay it within the valid time slice itself = but by carefully choosing the time slice we can make it nearly impossible for the attacker to replay.

For example , if the Time S= tamp chosen is 32 bits , we could get one seconds level precision in the ti= me window . So it is highly impossible for the attacker to replay within such a small time at such a high packet rates. =

 

Also , the verifier could c= ache, if needed, certain number of previously used RND-2 to mitigate replay= attacks. 

 

Hope this clarifies. <= o:p>

 

--_000_36c193705f0a4443b57ac984ed29161eILEXCH02marvellcom_-- From nobody Mon Jul 18 23:33: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 5195812D0DE for ; Mon, 18 Jul 2016 23:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 bi9hZ5HH1How for ; Mon, 18 Jul 2016 23:33:19 -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 CDFE712B038 for ; Mon, 18 Jul 2016 23:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26794; q=dns/txt; s=iport; t=1468909998; x=1470119598; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/uDdPCdUGc6o/W4iyGgtrJi4Lab6hzVTf/cse/ZTP9w=; b=lUUC46NCVmOadBXHEJKF71FYebokZPWtXp8IUWVdNeS+WM6tCyuOxRWs MTSSCbTHtzsnR7L+5NcQFJ5yO4xB/6pRsYJT5opIzPuFpiQEKeLwO7wge CK3OO1eXHImAExEg5L0n0qORU91TK0XaaLH+DX0TmBw5eGA0doJj2MEI9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqAgCMyI1X/40NJK1bgnFOVnwGuGGBe?= =?us-ascii?q?oYaAoE1OBQBAQEBAQEBZSeEXAEBBYEJAgEIEQQBASEHBzIUCQgBAQQBEogwvWU?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqETYR2hSUFiCKGIoUfhUEBiQ2Cc4Jeg?= =?us-ascii?q?gKNNZAdAR42ggscgUxuhxF/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,388,1464652800"; d="scan'208,217";a="125243286" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2016 06:33:17 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6J6XHj9031276 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 06:33:17 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 01:33:16 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Tue, 19 Jul 2016 01:33:16 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYA= Date: Tue, 19 Jul 2016 06:33:16 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> In-Reply-To: <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.76.91] Content-Type: multipart/alternative; boundary="_000_D3B3BB9378E19sadaraciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Jul 2016 06:33:21 -0000 --_000_D3B3BB9378E19sadaraciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_D3B3BB9378E19sadaraciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Inline .. 

 

We have two consecutive packets, A = and B:

- Packet A that went through the co= rrect path and has a correct POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 Now the attacker performs a ‘mix and matchR= 17; attack, by taking the correct POT from packet A and attaching it to pac= ket B.

The attacker also terminates packet= A.

There is no replay here, because th= e verifier receives the correct POT only once. The problem is that the corr= ect POT happens to arrive with packet B. L

Thus, packet B appears okay to the = verifier, even though it did not go through the correct path.<= o:p>

 

Is there a way to mitigate this att= ack?

[SD] Ok. This is an interesting attack.  

Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5= ,6) nodes. 
Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,= 6).

If the attacker could take values from Path1 and reattach them to&nb= sp;Path2 , the reconstruction for PacketB would result in (1,3,5,6) instead o= f (1,2,3,6). 
This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken.
 It just reconstructs the particular path taken by the packets. <= /div>

Do you mean that there is a one-second-vulnerability for r= eplay attacks?

One second is practically forever.

[SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. 
 

Effective replay prevention is typi= cally performed using a sequence number, with a sliding window to allow out= -of-order packets. Wouldn’t it be possible to incorporate such a sequence number into your mechanism?

 
[SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy &n= bsp;and predictable.
that’s reason we recommend using  ( Timestamp(/ sequence number)= + RND )

 


 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. Mor= e inline with [SD] .. 

 

 

Right, I am referring to the former. The integrity check i= s not the issue.

Let’s say we have:

- Packet A that went through the correct path and has a co= rrect POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 

The attacker can ‘launder’ packet B by replaci= ng the (incorrect) POT of packet B with the correct POT of packet A (and dr= op packet A).

Thus, packet B is verified correctly, even though it did n= ot go through the correct path.

 

[SD] This is valid scenario and we have cert= ain in-built mitigation techniques and recommendations for the same. <= o:p>

There are two scenarios here 

 

Partial Replay of POT data (Replaying int= ermediate CMLs)

 

Attacker cannot reuse few intermediate node&= #8217;s POT values (from older packet traces) as it would disrupt the POLY-= 3 construction. 

On the other hand if the attacker tries to r= eplay entire sequence of CML values, he cannot still , because notice that = verifier also has a secret share of RND-1 and participates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never on = wire , so attacker cannot just observe the packet traces to reuse and repla= y it. 

 

Total Replay of POT data (Replaying compl= ete RND-2)

 

Another trick, attacker could do is by compl= etely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Attacks= ” , we recommend that the RND-2 (generated per packet) be a combinati= on (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to repla= y one of the correct but older RND-2, the verifier first could check the cu= rrent timestamp against the timestamp retrieved from RND-2.

If the retrieved timestamp is older than cur= rent timestamp we drop/raise a flag ! 

 

There is still a small window , where the at= tacker could replay it within the valid time slice itself but by carefully = choosing the time slice we can make it nearly impossible for the attacker to replay.

For example , if the Time Stamp chosen is 32= bits , we could get one seconds level precision in the time window . So it= is highly impossible for the attacker to replay within such a small time at such a high packet rates. =

 

Also , the verifier could cache, if needed, = certain number of previously used RND-2 to mitigate replay attacks. 

 

Hope this clarifies. =

 

 --_000_D3B3BB9378E19sadaraciscocom_-- From nobody Tue Jul 19 00:37: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 6B3A512B04F for ; Tue, 19 Jul 2016 00:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzv4ds-zj4lL for ; Tue, 19 Jul 2016 00:36:58 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0068812D0CB for ; Tue, 19 Jul 2016 00:36:57 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6J7ZI9n026985; Tue, 19 Jul 2016 00:36:57 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 2494s526e1-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jul 2016 00:36:56 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jul 2016 10:36:52 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Tue, 19 Jul 2016 10:36:52 +0300 From: Tal Mizrahi To: "Sashank Dara (sadara)" , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUA== Date: Tue, 19 Jul 2016 07:36:51 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_dbeafbf94c71487598f604cc2e6224b2ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-19_05:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607190082 Archived-At: Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Jul 2016 07:37:00 -0000 --_000_dbeafbf94c71487598f604cc2e6224b2ILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sashank, I appreciate the detailed responses. >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? >[SD] Not really , the verifier could cache the RND-2 numbers used in the t= ime >slice of one second and flush off after every second. There is no one-seco= nd-vulnerability >as such, if the verifier caches those values. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_dbeafbf94c71487598f604cc2e6224b2ILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sashank,<= /span>

 <= /p>

I appreciate the detailed= responses.

 <= /p>

 <= /p>

>[SD] Ok. This is an int= eresting attack.  

> 

>Lets take correct path = taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect p= ath to be Packet B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could t= ake values from Path1 and reattach them to Path2 ,

>the reconstruction= for PacketB would result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared = with topology/policy db information for any policy

>violations. POT does no= t enforce a particular path to be taken.

 <= /p>

So packet B skipped node = 5 (e.g. the firewall SF), but the verifier believes it went through the cor= rect path.

Would you agree?

 <= /p>

 <= /p>

>[SD] Not really , the v= erifier could cache the RND-2 numbers used in the time

>slice of one second and= flush off after every second. There is no one-second-vulnerability

>as such, if the verifie= r caches those values. 

 <= /p>

Hmmm… Let’s s= ay we are talking about traffic at 10 Gbps, which is roughly 1 million pack= ets per second. That would mean the verifier has to store a million values of RND-2.

Moreover, every time a pa= cket arrives, the verifier would have to compare its RND-2 value with the 1= million stored values, in order to verify there is no replay.

That does not sound feasi= ble.

Am I missing something he= re?

 <= /p>

 <= /p>

Thanks,=

Tal.

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-o= f-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. <= /span>

 

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 

[SD] Ok. This is an interes= ting attack.  

 

Lets take correct path take= n by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path = to be Packet B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take = values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). 

This could be compared with= topology/policy db information for any policy violations. POT does not enf= orce a particular path to be taken.

 It just reconstructs = the particular path taken by the packets. 

 

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 

[SD] Not really , the verif= ier could cache the RND-2 numbers used in the time slice of one second and = flush off after every second. There is no one-second-vulnerability as such, if the verifier caches those values. 

 

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentia= lly at high level sequence number (at seconds level)! The challenge with us= ing complete RND-2 as sequence number is that the differential analysis of CML values (across packets) becomes very easy  and predic= table.

that’s reason we reco= mmend using  ( Timestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_dbeafbf94c71487598f604cc2e6224b2ILEXCH02marvellcom_-- From nobody Tue Jul 19 00:56: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 B692412DBE9 for ; Tue, 19 Jul 2016 00:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 ik4Ubk09ADBy for ; Tue, 19 Jul 2016 00:56:08 -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 3098512D0E0 for ; Tue, 19 Jul 2016 00:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40585; q=dns/txt; s=iport; t=1468914968; x=1470124568; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=BnwYGMO6J/BKKRgIn2x6DDkOBFUaR5zBu2PUa42SyzY=; b=ZrlOfEvDuCHKZKhIT/LS/A+edWF2iyfXH2D94xIWd7J1rxIBaEpnEZ8E bDfgBmAH+16xnHmVuns13g5wQ3FQh7Jq1JEK5ibb/k/x+xK+XiC4osaro OsJqCsZ5thgjaSFumXcpwnUDNajk97GGgtEdjH/1000/q53w0t/91VVy5 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqAgCp3I1X/5BdJa1bgnFOVnwGuGCBe?= =?us-ascii?q?oYaAoEwOBQBAQEBAQEBZSeEXAEBBYEJAgEIEQQBASEBBgcyFAkIAgQBEogwvWM?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqETYR2hSUFiCKLQYVBAYkNgnOCXoICj?= =?us-ascii?q?TWQHQEeNoILHIFMbocRfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,388,1464652800"; d="scan'208,217";a="299516936" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 07:55:55 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6J7ttRK011228 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 07:55:55 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 02:55:54 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Tue, 19 Jul 2016 02:55:54 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIA Date: Tue, 19 Jul 2016 07:55:54 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.76.91] Content-Type: multipart/alternative; boundary="_000_D3B3D71678E9Esadaraciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Jul 2016 07:56:12 -0000 --_000_D3B3D71678E9Esadaraciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of =93proof-of-transit=94 is to prove the path pac= ket has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with =93reconstructed=94 path. Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rough= ly 1 million packets per second. That would mean the verifier has to store = a million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a =91mix and match=92 attack, by taking the corr= ect POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn=92t it be poss= ible to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that=92s reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let=92s say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can =91launder=92 packet B by replacing the (incorrect) POT of= packet B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node=92s POT values (from older pack= et traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier=92s share of RND-3 is never on wire , so attacker cannot just obse= rve the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the =93Reply Attacks=94 , we recommend that the RND-2 (= generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND n= umber=94) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_D3B3D71678E9Esadaraciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

 

 

>[SD] Ok. This is an interesting attack. =  

> 

>Lets take correct path taken by Packet A=  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Packet = B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values from Path1 and reattach them to Path2 ,

>the reconstruction for PacketB woul= d result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/pol= icy db information for any policy

>violations. POT does not enforce a parti= cular path to be taken.

 

So packet B skipped node 5 (e.g. th= e firewall SF), but the verifier believes it went through the correct path.=

Would you agree?<= /p>

 
[SD] The verifier only= constructs the path the packet took accurately, it is upto the application= to determine whether it violates any policies (I.e missing any function)&n= bsp;
The bottom line is , a= n attacker taking a different path cannot get away with it ! The whole inte= nt of =93proof-of-transit=94 is to prove the path packet has taken exactly.=  
POT does not define wh= ether it good/bad path. It is upto high level applications on what do with = =93reconstructed=94 path. 

 

Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, w= hich is roughly 1 million packets per second. That would mean the verifier has to store a million values of RND-2.<= /o:p>

Moreover, every time a packet arrives, the verifier would have= to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we coul= d use as much precision as we want to reduce the number of values to be cached !
 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A and B:<= span style=3D"color:black">

- Packet A that went through the correct path and= has a correct POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 Now the attacker performs a =91mix and match=92 atta= ck, by taking the correct POT from packet A and attaching it to packet B.

The attacker also terminates packet A.

There is no replay here, because the verifier rec= eives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the verifier, even= though it did not go through the correct path.

 

Is there a way to mitigate this attack?

 

[SD] Ok. This is an interesting attack. &nbs= p;

 

Lets take correct path taken by Packet A &nb= sp;to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B i.= e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). 

This could be compared with topology/policy = db information for any policy violations. POT does not enforce a particular= path to be taken.

 It just reconstructs the particular pa= th taken by the packets. 

 

Do you mean that there is a one-second-vulnerabil= ity for replay attacks?

One second is practically forever.=

 

[SD] Not really , the verifier could cache t= he RND-2 numbers used in the time slice of one second and flush off after e= very second. There is no one-second-vulnerability as such, if the verifier caches those values. 

 

Effective replay prevention is typically performe= d using a sequence number, with a sliding window to allow out-of-order packets. Wouldn=92t it be possible to incorpo= rate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high level= sequence number (at seconds level)! The challenge with using complete RND-= 2 as sequence number is that the differential analysis of CML values (across packets) becomes very easy  and predic= table.

that=92s reason we recommend using  ( T= imestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. More inline with = [SD] .. 

 

 

Right, I am referring to the former. The integrity check i= s not the issue.

Let=92s say we have:

- Packet A that went through the correct path and has a co= rrect POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 

The attacker can =91launder=92 packet B by replacing the (= incorrect) POT of packet B with the correct POT of packet A (and drop packe= t A).

Thus, packet B is verified correctly, even though it did n= ot go through the correct path.

 

[SD] This is valid scenario and we have certain in-built m= itigation techniques and recommendations for the same. 

There are two scenarios here 

 

Partial Replay of POT data (Replaying intermediate CMLs= )

 

Attacker cannot reuse few intermediate node=92s POT values= (from older packet traces) as it would disrupt the POLY-3 construction. <= o:p>

On the other hand if the attacker tries to replay entire s= equence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and partic= ipates in the reconstruction of RND-3.

Verifier=92s share of RND-3 is never on wire , so attacker= cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying complete RND-2)

 

Another trick, attacker could do is by completely reusing = RND-2 (but not intermediate CML values)<= o:p>

In order to prevent the =93Reply Attacks=94 , we recommend= that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND number=94)

So in case a passive attacker tries to replay one of the c= orrect but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than current timestamp= we drop/raise a flag ! =

 

There is still a small window , where the attacker could r= eplay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is 32 bits , we cou= ld get one seconds level precision in the time window . So it is highly impossible for the attacker to replay wi= thin such a small time at such a high packet rates. 

 

Also , the verifier could cache, if needed, certain number= of previously used RND-2 to mitigate replay attacks. =

 

Hope this clarifies. 

 

 --_000_D3B3D71678E9Esadaraciscocom_-- From nobody Tue Jul 19 01:28: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 161D512DCC9 for ; Tue, 19 Jul 2016 01:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGd5EnvMe3eO for ; Tue, 19 Jul 2016 01:28:33 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FB712DCBD for ; Tue, 19 Jul 2016 01:28:31 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6J8OdTa026522; Tue, 19 Jul 2016 01:28:30 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 2494s52awx-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jul 2016 01:28:29 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jul 2016 11:28:25 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Tue, 19 Jul 2016 11:28:25 +0300 From: Tal Mizrahi To: "Sashank Dara (sadara)" , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjAA= Date: Tue, 19 Jul 2016 08:28:24 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_ba8810518f5b4e518b7efae916534fb5ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-19_05:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607190091 Archived-At: Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Jul 2016 08:28:37 -0000 --_000_ba8810518f5b4e518b7efae916534fb5ILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_ba8810518f5b4e518b7efae916534fb5ILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sashank,<= /span>

 <= /p>

I really appreciate the q= uick and detailed responses.

 <= /p>

>>>Lets take correct path taken = by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g= . the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only = constructs the path the packet took accurately, it is upto

>the application to dete= rmine whether it violates any policies (I.e missing any function) 

>The bottom line is , an= attacker taking a different path cannot get away with it !

>The whole intent of = 220;proof-of-transit” is to prove the path packet has taken exactly.&= nbsp;

>POT does not define whe= ther it good/bad path. It is upto high level applications on what

>do with “reconstr= ucted” path. 

 <= /p>

 <= /p>

 <= /p>

I want to ask a simple qu= estion:

If the attacker attaches = the POT of packet A (indicating the path through 1,3,5,6) to packet B, will= the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 <= /p>

 <= /p>

>>Hmmm… Let’s say we = are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could use = as much precision as we want to reduce the number of values to be cached !

 <= /p>

My point is that assuming= reasonable resources are used, the mechanism is vulnerable to a replay att= ack.

In order to prove me wron= g, can you present concrete numbers of the timestamp resolution and the cac= he size?

Otherwise, you may consid= er using a sequence number + sliding window (e.g., as in IPsec).

 <= /p>

 <= /p>

Thanks,=

Tal.

 <= /p>

 <= /p>

 <= /p>

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-o= f-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

 

>[SD] Ok. This is an interesting attac= k.  

> 

>Lets take correct path taken by Packe= t A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Pack= et B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values fro= m Path1 and reattach them to Path2 ,

>the reconstruction for PacketB w= ould result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/= policy db information for any policy

>violations. POT does not enforce a pa= rticular path to be taken.

 

So packet B skipped node 5 (e.g. the fi= rewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only cons= tructs the path the packet took accurately, it is upto the application to d= etermine whether it violates any policies (I.e missing any function) 

The bottom line is , an att= acker taking a different path cannot get away with it ! The whole intent of= “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whether= it good/bad path. It is upto high level applications on what do with ̶= 0;reconstructed” path. 

 

 

Hmmm… Let’s say we are talk= ing about traffic at 10 Gbps, which is roughly 1 million packets per second= . That would mean the verifier has to store a million values of RND-2.

Moreover, every time a packet arrives, = the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we could use as m= uch precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 =

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 =

[SD] Ok. This is an interesting attack. &= nbsp;

 =

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B= i.e. Path2 -  (1,2,3,6).

 =

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/poli= cy db information for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular= path taken by the packets. 

 =

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 =

[SD] Not really , the verifier could cach= e the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such= , if the verifier caches those values. 

 =

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high le= vel sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that’s reason we recommend using &n= bsp;( Timestamp(/ sequence number) + RND )

 

 =

 =

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_ba8810518f5b4e518b7efae916534fb5ILEXCH02marvellcom_-- From nobody Tue Jul 19 03:19: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 4F65312D103 for ; Tue, 19 Jul 2016 03:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 DxJrc5VGZWix for ; Tue, 19 Jul 2016 03:19:54 -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 B83CB12D54F for ; Tue, 19 Jul 2016 03:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3631; q=dns/txt; s=iport; t=1468923594; x=1470133194; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5pmMNKeA7ojOL+12QPtLVuKQMUkxWYFayrhkZYRrb0M=; b=WU1fZXJQ/XsLVCVCyMCDxZnXaZTMEWKjSsTRiuIfd+qqjY08wvHcms/8 Qamrsp5PvM+dQ2bWS+1SBOindXVvLZ3lmQYpyquLpBkDrlAO3VbVcN0Wb Ve13kpsq8h5yJ2ApqwDoCflwDI9Inl467szLMvhxeTVutv1tWKRfVBHkr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAgBn/o1X/4cNJK1cgnFOgVizW4UEg?= =?us-ascii?q?XqGGgKBMjgUAQEBAQEBAWUnhF0BBYEJAgEIBEIyJQIEAYhCvHgBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAR2GKoRNihsFmSQBjmGPN5AdAR42g3OHPCsYAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,389,1464652800"; d="scan'208,217";a="127442350" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2016 10:19:53 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6JAJres026640 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 10:19:53 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 05:19:52 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Tue, 19 Jul 2016 05:19:52 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjAD//3uugA== Date: Tue, 19 Jul 2016 10:19:52 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [72.163.210.235] Content-Type: multipart/alternative; boundary="_000_D3B3E30278EDCsadaraciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Jul 2016 10:19:56 -0000 --_000_D3B3E30278EDCsadaraciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. --_000_D3B3E30278EDCsadaraciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable


I want to ask a simple question:

If the attacker attaches the POT of packet A (indicating t= he path through 1,3,5,6) to packet B, will the verifier accept packet B and= believe that its path was indeed (1,3,5,6)?

[SD] If the verifier is programmed to just validate the POT meta data = against {1,3,5,6} then yes it accepts it. 
If the verifier is programmed to consult a policy database to cross ch= eck if the reconstructed path {1,3,5,6} is as per the policies then no , it= drops it . 

But I see your point , that the parameters used in POT data donot cons= ider the path or node-ids etc . We shall discuss this internally and get ba= ck.

Also, We shall get back with more concrete numbers of the timestamp re= solution and cache sizes (or other better approaches). 

Thank you so much for all the inputs. 
--_000_D3B3E30278EDCsadaraciscocom_-- From nobody Tue Jul 19 08:53: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 9A69712DB5C; Tue, 19 Jul 2016 08:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLN2AM0WLOtM; Tue, 19 Jul 2016 08:53:30 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1524412DC62; Tue, 19 Jul 2016 08:43:49 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6JFeIE7005393; Tue, 19 Jul 2016 08:43:47 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0b-0016f401.pphosted.com with ESMTP id 2494s94wyw-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jul 2016 08:43:46 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jul 2016 18:43:44 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Tue, 19 Jul 2016 18:43:44 +0300 From: Tal Mizrahi To: "Sashank Dara (sadara)" , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAA== Date: Tue, 19 Jul 2016 15:43:43 +0000 Message-ID: <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_30883664facc48a5b1c4030c8ee9c81eILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-19_10:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607190167 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Jul 2016 15:53:36 -0000 --_000_30883664facc48a5b1c4030c8ee9c81eILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_30883664facc48a5b1c4030c8ee9c81eILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

To summarize my take on t= his thread:

The proposed mechanism ha= s two significant vulnerabilities that (in my understanding) are currently = not addressed:

1.&nbs= p;      A man-in-the-middle can replace the POT of packet A with the POT of= packet B.

2.&nbs= p;      It is possible to replay POTs within a certain time window, whose l= ength is determined by the timestamp resolution.

 <= /p>

Sashank, thanks for agree= ing to look into it further. I am looking forward to your insights on this.=

 <= /p>

Regards,

Tal.

 <= /p>

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 <= /p>

 <= /p>

 

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-o= f-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (in= dicating the path through 1,3,5,6) to packet B, will the verifier accept pa= cket B and believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is pro= grammed to just validate the POT meta data against {1,3,5,6} then yes it ac= cepts it. 

If the verifier is programm= ed to consult a policy database to cross check if the reconstructed path {1= ,3,5,6} is as per the policies then no , it drops it . 

 

But I see your point , that= the parameters used in POT data donot consider the path or node-ids etc . = We shall discuss this internally and get back.

 

Also, We shall get back wit= h more concrete numbers of the timestamp resolution and cache sizes (or oth= er better approaches). 

 

Thank you so much for all t= he inputs. 

 

 

 

From: Tal Mizr= ahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brock= ners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,<= /span>

 <= /p>

I really appreciate the q= uick and detailed responses.

 <= /p>

>>>Lets take correct path taken = by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g= . the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only = constructs the path the packet took accurately, it is upto

>the application to dete= rmine whether it violates any policies (I.e missing any function) 

>The bottom line is , an= attacker taking a different path cannot get away with it !

>The whole intent of = 220;proof-of-transit” is to prove the path packet has taken exactly.&= nbsp;

>POT does not define whe= ther it good/bad path. It is upto high level applications on what

>do with “reconstr= ucted” path. 

 <= /p>

 <= /p>

 <= /p>

I want to ask a simple qu= estion:

If the attacker attaches = the POT of packet A (indicating the path through 1,3,5,6) to packet B, will= the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 <= /p>

 <= /p>

>>Hmmm… Let’s say we = are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could use = as much precision as we want to reduce the number of values to be cached !

 <= /p>

My point is that assuming= reasonable resources are used, the mechanism is vulnerable to a replay att= ack.

In order to prove me wron= g, can you present concrete numbers of the timestamp resolution and the cac= he size?

Otherwise, you may consid= er using a sequence number + sliding window (e.g., as in IPsec).

 <= /p>

 <= /p>

Thanks,=

Tal.

 <= /p>

 <= /p>

 <= /p>

 

 

 

 

>[SD] Ok. This is an interesting attac= k.  

> 

>Lets take correct path taken by Packe= t A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Pack= et B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values fro= m Path1 and reattach them to Path2 ,

>the reconstruction for PacketB w= ould result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/= policy db information for any policy

>violations. POT does not enforce a pa= rticular path to be taken.

 

So packet B skipped node 5 (e.g. the fi= rewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only cons= tructs the path the packet took accurately, it is upto the application to d= etermine whether it violates any policies (I.e missing any function) 

The bottom line is , an att= acker taking a different path cannot get away with it ! The whole intent of= “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whether= it good/bad path. It is upto high level applications on what do with ̶= 0;reconstructed” path. 

 

 

Hmmm… Let’s say we are talk= ing about traffic at 10 Gbps, which is roughly 1 million packets per second= . That would mean the verifier has to store a million values of RND-2.

Moreover, every time a packet arrives, = the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we could use as m= uch precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 =

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 =

[SD] Ok. This is an interesting attack. &= nbsp;

 =

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B= i.e. Path2 -  (1,2,3,6).

 =

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/poli= cy db information for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular= path taken by the packets. 

 =

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 =

[SD] Not really , the verifier could cach= e the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such= , if the verifier caches those values. 

 =

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high le= vel sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that’s reason we recommend using &n= bsp;( Timestamp(/ sequence number) + RND )

 

 =

 =

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_30883664facc48a5b1c4030c8ee9c81eILEXCH02marvellcom_-- From nobody Tue Jul 19 09:07: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 3D52B12D5EC; Tue, 19 Jul 2016 09:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 SnzIgZCxWA0D; Tue, 19 Jul 2016 09:07:20 -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 7F7D712B02E; Tue, 19 Jul 2016 08:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79104; q=dns/txt; s=iport; t=1468943992; x=1470153592; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lIjuQX46C8AOUd/eGZ08IsOQk0iVFbr5NfQYPIQwx7Y=; b=TRoMrbVll0ErV1BLo0JsNHd6kDYfOQb/q5Y6hgmfFmX0BZ4oHoQWK4i+ p2b4GD92s6JBLzGOoNRa8Tr4u9vNHLHUVB+AZKA4E2Azz/vikxjQ4f+zk OXHtgbLvUDVXTADkLoVQrv83LE3eY7Puw5csv2gDY7358fJJi1tWUE0q5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgCDTY5X/40NJK1dgnFOVnwGuGWBe?= =?us-ascii?q?iKFeAKBMDgUAQEBAQEBAWUnhFwBAQUaEzoSEAIBCBEEAQEhAQYHMhQJCAIEAQ0?= =?us-ascii?q?FCBMEiBEOvGoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2EdoUlBYgii0GFQ?= =?us-ascii?q?QGGEoJ7gnOCWoIJjTWQHQEeNoILHIFMboZjKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,390,1464652800"; d="scan'208,217";a="298164813" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2016 15:59:50 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6JFxobi005835 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 15:59:50 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; Tue, 19 Jul 2016 10:59:49 -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; Tue, 19 Jul 2016 10:59:49 -0500 From: "Frank Brockners (fbrockne)" To: Tal Mizrahi , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddw Date: Tue, 19 Jul 2016 15:59:49 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> Accept-Language: de-DE, 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.244.97] Content-Type: multipart/alternative; boundary="_000_e45909b5c7924e11a1702c2aee1253eaXCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Jul 2016 16:07:25 -0000 --_000_e45909b5c7924e11a1702c2aee1253eaXCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) ; Frank Brockners (fbrockne) ; draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_e45909b5c7924e11a1702c2aee1253eaXCHRCD008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal,

 = ;

thanks for the summary. We’ll provide more details on 2. Per my = earlier point – 1. is an interesting discussion, given that we don’t claim to provide integrity protection for the packet p= ayload. Or in other terms – to be exact: What POT provides is a proof= that the POT-header/meta-data transited all the required nodes. There is n= o association (and thus proof) provided for the additional data carried along with the POT-header – neither head= er nor payload. As a consequence, attacks which change the packet payload w= on’t be detected/mitigated. We’ll explicitly state this in the = security considerations in the next rev of the document.

What we could consider is linking the RND number to CRC across the pac= ket payload or similar – but that way we’d restrict the applicability to deployments where the packet payload isn’t chan= ged across the path (which might not apply to certain deployment – e.= g. WAN optimization / compression schemes).

Do you think it is worthwhile to provide a solution for a deployment w= hich is expected to not alter the packet payload?

 

Thanks,

Frank

 

From: = Tal Mizrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sadara@cisco.com>; Frank Brockners = (fbrockne) <fbrockne@cisco.com>; draft-brockners-proof-of-transit@too= ls.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,<= /p>

 

To summarize my take o= n this thread:

The proposed mechanism= has two significant vulnerabilities that (in my understanding) are current= ly not addressed:

1.&= nbsp;      A man-in-the-m= iddle can replace the POT of packet A with the POT of packet B.<= /span>

2.&= nbsp;      It is possible= to replay POTs within a certain time window, whose length is determined by= the timestamp resolution.

 

Sashank, thanks for ag= reeing to look into it further. I am looking forward to your insights on th= is.

 

Regards,

Tal.=

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 =

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier accept= packet B and believe that its path was indeed (1,3,5,6)?

 =

[SD] If the verifier is = programmed to just validate the POT meta data against {1,3,5,6} then yes it= accepts it. 

If the verifier is progr= ammed to consult a policy database to cross check if the reconstructed path= {1,3,5,6} is as per the policies then no , it drops it . 

 =

But I see your point , t= hat the parameters used in POT data donot consider the path or node-ids etc= . We shall discuss this internally and get back.

 =

Also, We shall get back = with more concrete numbers of the timestamp resolution and cache sizes (or = other better approaches). 

 =

Thank you so much for al= l the inputs. 

 

 

 

From: Ta= l Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate th= e quick and detailed responses.

 

>>>Lets take correct path tak= en by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (= e.g. the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier on= ly constructs the path the packet took accurately, it is upto

>the application to d= etermine whether it violates any policies (I.e missing any function) <= o:p>

>The bottom line is ,= an attacker taking a different path cannot get away with it !

>The whole intent of = “proof-of-transit” is to prove the path packet has taken exactl= y. 

>POT does not define = whether it good/bad path. It is upto high level applications on what

>do with “recon= structed” path. 

 

 

 

I want to ask a simple= question:

If the attacker attach= es the POT of packet A (indicating the path through 1,3,5,6) to packet B, w= ill the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 

 

>>Hmmm… Let’s say = we are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could u= se as much precision as we want to reduce the number of values to be cached !

 

My point is that assum= ing reasonable resources are used, the mechanism is vulnerable to a replay = attack.

In order to prove me w= rong, can you present concrete numbers of the timestamp resolution and the = cache size?

Otherwise, you may con= sider using a sequence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.=

 

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 

 

>[SD] Ok. This is an interesting at= tack.  

> 

>Lets take correct path taken by Pa= cket A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be P= acket B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values = from Path1 and reattach them to Path2 ,

>the reconstruction for Packet= B would result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topolo= gy/policy db information for any policy

>violations. POT does not enforce a= particular path to be taken.

 

So packet B skipped node 5 (e.g. the= firewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only c= onstructs the path the packet took accurately, it is upto the application t= o determine whether it violates any policies (I.e missing any function) 

The bottom line is , an = attacker taking a different path cannot get away with it ! The whole intent= of “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whet= her it good/bad path. It is upto high level applications on what do with &#= 8220;reconstructed” path. 

 =

 

Hmmm… Let’s say we are t= alking about traffic at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrive= s, the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.=

Am I missing something here?<= span lang=3D"EN-US" style=3D"font-size:10.5pt;color:black">

 

[SD] Second level precision is only an example, we could use a= s much precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A a= nd B:

- Packet A that went through the cor= rect path and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 Now the attacker performs a ‘mix = and match’ attack, by taking the correct POT from packet A and attach= ing it to packet B.<= /o:p>

The attacker also terminates packet = A.

There is no replay here, because the= verifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the v= erifier, even though it did not go through the correct path.<= /p>

 

Is there a way to mitigate this atta= ck?

 

[SD] Ok. This is an interesting attack= .  

 

Lets take correct path taken by Packet= A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packe= t B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/p= olicy db information for any policy violations. POT does not enforce a particular path to be taken.

 It just reconstructs the particu= lar path taken by the packets. 

 

Do you mean that there is a one-seco= nd-vulnerability for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could c= ache the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerabil= ity as such, if the verifier caches those values. 

 

Effective replay prevention is typic= ally performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to inc= orporate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high= level sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential anal= ysis of CML values (across packets) becomes very easy  and predictable= .

that’s reason we recommend using=  ( Timestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our wor= k. More inline with [SD] .. 

 

 

Right, I am referring to the former. The inte= grity check is not the issue.

Let’s say we have:

- Packet A that went through the correct path= and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 

The attacker can ‘launder’ packet= B by replacing the (incorrect) POT of packet B with the correct POT of pac= ket A (and drop packet A).

Thus, packet B is verified correctly, even th= ough it did not go through the correct path.

 

[SD] This is valid scenario and we hav= e certain in-built mitigation techniques and recommendations for the same. =

There are two scenarios here 

 

Partial Replay of POT data (Replayi= ng intermediate CMLs)=

 

Attacker cannot reuse few intermediate= node’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker trie= s to replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and = participates in the reconstruction of RND-3.

Verifier’s share of RND-3 is nev= er on wire , so attacker cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying= complete RND-2)=

 

Another trick, attacker could do is by= completely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply A= ttacks” , we recommend that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D “Time Stamp + RND number”)=

So in case a passive attacker tries to= replay one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved fr= om RND-2.

If the retrieved timestamp is older th= an current timestamp we drop/raise a flag ! 

 

There is still a small window , where = the attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearl= y impossible for the attacker to replay.

For example , if the Time Stamp chosen= is 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay= within such a small time at such a high packet rates. 

 

Also , the verifier could cache, if ne= eded, certain number of previously used RND-2 to mitigate replay attacks. 

 

Hope this clarifies. 

 

--_000_e45909b5c7924e11a1702c2aee1253eaXCHRCD008ciscocom_-- From nobody Tue Jul 19 09:49: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 2BA4412B03A; Tue, 19 Jul 2016 09:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 R7Cp2HxAzyZB; Tue, 19 Jul 2016 09:49:15 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB27512D0AB; Tue, 19 Jul 2016 09:49:14 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6JGAewc025121; Tue, 19 Jul 2016 09:14:35 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 2494s955ea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jul 2016 09:14:34 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jul 2016 19:14:31 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Tue, 19 Jul 2016 19:14:30 +0300 From: Tal Mizrahi To: "Frank Brockners (fbrockne)" , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tA= Date: Tue, 19 Jul 2016 16:14:30 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_fe81bb4d38414067bbd78f65f8f7aae7ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-19_10:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607190172 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Jul 2016 16:49:18 -0000 --_000_fe81bb4d38414067bbd78f65f8f7aae7ILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank, The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_fe81bb4d38414067bbd78f65f8f7aae7ILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Frank,

 <= /p>

The POT replacement attac= k (1.) is not an attack on the integrity. It is an attack on the path verif= ication.

This simple attack can ca= use the verifier to accept a packet that did not go through the firewall SF= (even though it should). I believe this is exactly the problem you were aiming to address in this draft.

 <= /p>

Thanks,=

Tal.

 <= /p>

From: Frank Br= ockners (fbrockne) [mailto:fbrockne@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-tra= nsit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,<= /o:p>

 

thanks for the summary. W= e’ll provide more details on 2. Per my earlier point – 1. is an= interesting discussion, given that we don’t claim to provide integri= ty protection for the packet payload. Or in other terms – to be exact: = What POT provides is a proof that the POT-header/meta-data transited all th= e required nodes. There is no association (and thus proof) provided for the= additional data carried along with the POT-header – neither header nor payload. As a consequence, attacks w= hich change the packet payload won’t be detected/mitigated. We’= ll explicitly state this in the security considerations in the next rev of = the document.

What we could consider is= linking the RND number to CRC across the packet payload or similar –= but that way we’d restrict the applicability to deployments where the packet payload isn’t changed across the path (which might not ap= ply to certain deployment – e.g. WAN optimization / compression schem= es).

Do you think it is worthw= hile to provide a solution for a deployment which is expected to not alter = the packet payload?

 <= /p>

Thanks,=

Frank

 <= /p>

From: Tal Mi= zrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,

 <= /p>

To summarize my take on t= his thread:

The proposed mechanism ha= s two significant vulnerabilities that (in my understanding) are currently = not addressed:

1. &n= bsp;     A man-in-the-middle can replace the POT o= f packet A with the POT of packet B.

2. &n= bsp;     It is possible to replay POTs within a ce= rtain time window, whose length is determined by the timestamp resolution.<= o:p>

 <= /p>

Sashank, thanks for agree= ing to look into it further. I am looking forward to your insights on this.=

 <= /p>

Regards,

Tal.

 <= /p>

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 <= /p>

 <= /p>

 

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com<= /a>]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (in= dicating the path through 1,3,5,6) to packet B, will the verifier accept pa= cket B and believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is pro= grammed to just validate the POT meta data against {1,3,5,6} then yes it ac= cepts it. 

If the verifier is programm= ed to consult a policy database to cross check if the reconstructed path {1= ,3,5,6} is as per the policies then no , it drops it . 

 

But I see your point , that= the parameters used in POT data donot consider the path or node-ids etc . = We shall discuss this internally and get back.

 

Also, We shall get back wit= h more concrete numbers of the timestamp resolution and cache sizes (or oth= er better approaches). 

 

Thank you so much for all t= he inputs. 

 

 

 

From: Tal Mizr= ahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,<= /span>

 <= /p>

I really appreciate the q= uick and detailed responses.

 <= /p>

>>>Lets take correct path taken = by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g= . the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only = constructs the path the packet took accurately, it is upto

>the application to dete= rmine whether it violates any policies (I.e missing any function) 

>The bottom line is , an= attacker taking a different path cannot get away with it !

>The whole intent of = 220;proof-of-transit” is to prove the path packet has taken exactly.&= nbsp;

>POT does not define whe= ther it good/bad path. It is upto high level applications on what

>do with “reconstr= ucted” path. 

 <= /p>

 <= /p>

 <= /p>

I want to ask a simple qu= estion:

If the attacker attaches = the POT of packet A (indicating the path through 1,3,5,6) to packet B, will= the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 <= /p>

 <= /p>

>>Hmmm… Let’s say we = are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could use = as much precision as we want to reduce the number of values to be cached !

 <= /p>

My point is that assuming= reasonable resources are used, the mechanism is vulnerable to a replay att= ack.

In order to prove me wron= g, can you present concrete numbers of the timestamp resolution and the cac= he size?

Otherwise, you may consid= er using a sequence number + sliding window (e.g., as in IPsec).

 <= /p>

 <= /p>

Thanks,=

Tal.

 <= /p>

 <= /p>

 <= /p>

 

 

 

 

>[SD] Ok. This is an interesting attac= k.  

> 

>Lets take correct path taken by Packe= t A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Pack= et B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values fro= m Path1 and reattach them to Path2 ,

>the reconstruction for PacketB w= ould result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/= policy db information for any policy

>violations. POT does not enforce a pa= rticular path to be taken.

 

So packet B skipped node 5 (e.g. the fi= rewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only cons= tructs the path the packet took accurately, it is upto the application to d= etermine whether it violates any policies (I.e missing any function) 

The bottom line is , an att= acker taking a different path cannot get away with it ! The whole intent of= “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whether= it good/bad path. It is upto high level applications on what do with ̶= 0;reconstructed” path. 

 

 

Hmmm… Let’s say we are talk= ing about traffic at 10 Gbps, which is roughly 1 million packets per second= . That would mean the verifier has to store a million values of RND-2.

Moreover, every time a packet arrives, = the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we could use as m= uch precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 =

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 =

[SD] Ok. This is an interesting attack. &= nbsp;

 =

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B= i.e. Path2 -  (1,2,3,6).

 =

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/poli= cy db information for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular= path taken by the packets. 

 =

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 =

[SD] Not really , the verifier could cach= e the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such= , if the verifier caches those values. 

 =

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high le= vel sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that’s reason we recommend using &n= bsp;( Timestamp(/ sequence number) + RND )

 

 =

 =

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_fe81bb4d38414067bbd78f65f8f7aae7ILEXCH02marvellcom_-- From nobody Tue Jul 19 19:31: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 6DE3812D0E6; Tue, 19 Jul 2016 19:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 gCNIn-t--5wr; Tue, 19 Jul 2016 19:30:50 -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 46C8212D9DA; Tue, 19 Jul 2016 19:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=77724; q=dns/txt; s=iport; t=1468981850; x=1470191450; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=T8lFm523JTHmsUcY3s9AStaTJ5UiZyyAaJcgBCFrPl8=; b=NkjbPuweiXLf9Fv0EQ8ZFQTgEawGo9DHDkkB909mD+9mJjCD0XicIq+j q/H3fnVseHgVZZGR+mMLq24njXu7Np7KEQEuPlAM66GS+m8LTW8Dk480m 5mWs/FNjXWupjOOs9vqC4PohBX+r5nDSF/C4GpPeAoZ5FbHSdoqPzKW5V 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAD4o5X/4kNJK1dgnFOVnwGuGiBe?= =?us-ascii?q?iKFeAKBNDgUAQEBAQEBAWUnhFwBAQUaTRIQAgEIEQQBASEBBgcyFAkIAgQBDQU?= =?us-ascii?q?bBIgRDr0mAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhHaFJQWIIotBhUEBh?= =?us-ascii?q?hKCe4JzgmGCAo01kB0BHjaCCxyBTG6GYysYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,392,1464652800"; d="scan'208,217";a="125625146" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 02:30:48 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6K2UmAf020859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 02:30:48 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 21:30:47 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Tue, 19 Jul 2016 21:30:47 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tD/+pFIAA== Date: Wed, 20 Jul 2016 02:30:47 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.66.187] Content-Type: multipart/alternative; boundary="_000_D3B4DE197903Asadaraciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 02:30:54 -0000 --_000_D3B4DE197903Asadaraciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a serv= ice function/node. For example, if the attacker bypasses a node and if POT determines it did n= ot bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determ= ine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reco= nstructed ! We could emphasize this in our next draft , but it would be beyond scope of= POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We=92ll provide more details on 2. Per my earlier p= oint =96 1. is an interesting discussion, given that we don=92t claim to pr= ovide integrity protection for the packet payload. Or in other terms =96 to= be exact: What POT provides is a proof that the POT-header/meta-data trans= ited all the required nodes. There is no association (and thus proof) provi= ded for the additional data carried along with the POT-header =96 neither h= eader nor payload. As a consequence, attacks which change the packet payloa= d won=92t be detected/mitigated. We=92ll explicitly state this in the secur= ity considerations in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar =96 but that way we=92d restrict the applicability to dep= loyments where the packet payload isn=92t changed across the path (which mi= ght not apply to certain deployment =96 e.g. WAN optimization / compression= schemes). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of =93proof-of-transit=94 is to prove the path packet has= taken exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with =93reconstructed=94 path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rou= ghly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of =93proof-of-transit=94 is to prove the path pac= ket has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with =93reconstructed=94 path. Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rough= ly 1 million packets per second. That would mean the verifier has to store = a million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a =91mix and match=92 attack, by taking the corr= ect POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn=92t it be poss= ible to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that=92s reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let=92s say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can =91launder=92 packet B by replacing the (incorrect) POT of= packet B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node=92s POT values (from older pack= et traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier=92s share of RND-3 is never on wire , so attacker cannot just obse= rve the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the =93Reply Attacks=94 , we recommend that the RND-2 (= generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND n= umber=94) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_D3B4DE197903Asadaraciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


The POT replacement attack (1.) is = not an attack on the integrity. It is an attack on the path verification.

This simple attack can cause the ve= rifier to accept a packet that did not go through the firewall SF (even tho= ugh it should). I believe this is exactly the problem you were aiming to address in this draft.

[SD] The attack is valid only if the attacker can get away bypassing a= service function/node. 
For example, if the attacker bypasses a node and if POT determines it = did not bypass is a valid attack on the system.

In the current state, there is no way an attacker can get away as we d= etermine the exact path the packet travelled (aim of the draft) . 
I reiterate that the verifier needs to handle what to do with the path= reconstructed !
We could emphasize this in our next draft , but it would be beyond sco= pe of POT to determine what to do with the path constructed. 
IMO, It would be highly application specific. 

 
Regards,
Sashank


 

Thanks,

Tal.

 

From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We=92ll pro= vide more details on 2. Per my earlier point =96 1. is an interesting discu= ssion, given that we don=92t claim to provide integrity protection for the packet payload. Or in other terms =96 to be e= xact: What POT provides is a proof that the POT-header/meta-data transited = all the required nodes. There is no association (and thus proof) provided f= or the additional data carried along with the POT-header =96 neither header nor payload. As a consequence, atta= cks which change the packet payload won=92t be detected/mitigated. We=92ll = explicitly state this in the security considerations in the next rev of the= document.

What we could consider is linking t= he RND number to CRC across the packet payload or similar =96 but that way = we=92d restrict the applicability to deployments where the packet payload isn=92t changed across the path (which might not = apply to certain deployment =96 e.g. WAN optimization / compression schemes= ).

Do you think it is worthwhile to pr= ovide a solution for a deployment which is expected to not alter the packet= payload?

 

Thanks,

Frank

 

From: Tal Mizrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,

 

To summarize my take on this thread= :

The proposed mechanism has two sign= ificant vulnerabilities that (in my understanding) are currently not addres= sed:

   =     A man-in-the-middle can replace the POT of packet A= with the POT of packet B.

   =     It is possible to replay POTs within a certain time= window, whose length is determined by the timestamp resolution.=

 

Sashank, thanks for agreeing to loo= k into it further. I am looking forward to your insights on this.

 

Regards,

Tal.

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (indicating t= he path through 1,3,5,6) to packet B, will the verifier accept packet B and= believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is programmed to just v= alidate the POT meta data against {1,3,5,6} then yes it accepts it. 

If the verifier is programmed to consult a p= olicy database to cross check if the reconstructed path {1,3,5,6} is as per= the policies then no , it drops it . 

 

But I see your point , that the parameters u= sed in POT data donot consider the path or node-ids etc . We shall discuss = this internally and get back.

 

Also, We shall get back with more concrete n= umbers of the timestamp resolution and cache sizes (or other better approac= hes). 

 

Thank you so much for all the inputs. <= o:p>

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate the quick and d= etailed responses.

 

>>>Lets take correct path taken by Packet A  = ;to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g. the fire= wall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only constructs the pa= th the packet took accurately, it is upto

>the application to determine whether it = violates any policies (I.e missing any function) 

>The bottom line is , an attacker taking = a different path cannot get away with it !

>The whole intent of =93proof-of-transit= =94 is to prove the path packet has taken exactly. <= /p>

>POT does not define whether it good/bad = path. It is upto high level applications on what

>do with =93reconstructed=94 path. <= o:p>

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of= packet A (indicating the path through 1,3,5,6) to packet B, will the verif= ier accept packet B and believe that its path was indeed (1,3,5,6)?

 

 

>>Hmmm=85 Let=92s say we are talking about = traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Se= cond level precision is only an example, we could use as much precision as = we want to reduce the number of values to be cached !

 

My point is that assuming reasonabl= e resources are used, the mechanism is vulnerable to a replay attack.<= /o:p>

In order to prove me wrong, can you= present concrete numbers of the timestamp resolution and the cache size?

Otherwise, you may consider using a= sequence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

 

>[SD] Ok. This is an interesting attack.  <= span style=3D"color:black">

> 

>Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values from Path1 and reattach them to Path2 ,

>the reconstruction for PacketB would result in (1= ,3,5,6) instead of (1,2,3,6). =

>This could be compared with topology/policy db informa= tion for any policy

>violations. POT does not enforce a particular path to = be taken.

 

So packet B skipped node 5 (e.g. the firewall SF)= , but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only constructs the path t= he packet took accurately, it is upto the application to determine whether = it violates any policies (I.e missing any function) 

The bottom line is , an attacker taking a di= fferent path cannot get away with it ! The whole intent of =93proof-of-tran= sit=94 is to prove the path packet has taken exactly. 

POT does not define whether it good/bad path= . It is upto high level applications on what do with =93reconstructed=94 pa= th. 

 

 

Hmmm=85 Let=92s say we are talking about traffic = at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrives, the verifi= er would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second= level precision is only an example, we could use as much precision as we w= ant to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A and B:<= span style=3D"color:black">

- Packet A that went through the correct path and= has a correct POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 Now the attacker performs a =91mix and match=92 atta= ck, by taking the correct POT from packet A and attaching it to packet B.

The attacker also terminates packet A.

There is no replay here, because the verifier rec= eives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the verifier, even= though it did not go through the correct path.

 

Is there a way to mitigate this attack?

 

[SD] Ok. This is an interesting attack.  

 

Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/policy db information= for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular path taken by th= e packets. 

 

Do you mean that there is a one-second-vulnerabil= ity for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could cache the RND-2 numbe= rs used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as = such, if the verifier caches those values. 

 

Effective replay prevention is typically performe= d using a sequence number, with a sliding window to allow out-of-order packets. Wouldn=92t it be possible to incorpo= rate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high level sequence numb= er (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that=92s reason we recommend using  ( Timestamp(/ seq= uence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. More inline with = [SD] .. 

 

 

Right, I am referring to the former. The integrity check i= s not the issue.

Let=92s say we have:

- Packet A that went through the correct path and has a co= rrect POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 

The attacker can =91launder=92 packet B by replacing the (= incorrect) POT of packet B with the correct POT of packet A (and drop packe= t A).

Thus, packet B is verified correctly, even though it did n= ot go through the correct path.

 

[SD] This is valid scenario and we have certain in-built m= itigation techniques and recommendations for the same. 

There are two scenarios here 

 

Partial Replay of POT data (Replaying intermediate CMLs= )

 

Attacker cannot reuse few intermediate node=92s POT values= (from older packet traces) as it would disrupt the POLY-3 construction. <= o:p>

On the other hand if the attacker tries to replay entire s= equence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and partic= ipates in the reconstruction of RND-3.

Verifier=92s share of RND-3 is never on wire , so attacker= cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying complete RND-2)

 

Another trick, attacker could do is by completely reusing = RND-2 (but not intermediate CML values)<= o:p>

In order to prevent the =93Reply Attacks=94 , we recommend= that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND number=94)

So in case a passive attacker tries to replay one of the c= orrect but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than current timestamp= we drop/raise a flag ! =

 

There is still a small window , where the attacker could r= eplay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is 32 bits , we cou= ld get one seconds level precision in the time window . So it is highly impossible for the attacker to replay wi= thin such a small time at such a high packet rates. 

 

Also , the verifier could cache, if needed, certain number= of previously used RND-2 to mitigate replay attacks. =

 

Hope this clarifies. 

 

 --_000_D3B4DE197903Asadaraciscocom_-- From nobody Tue Jul 19 21:31: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 8C49112DA15; Tue, 19 Jul 2016 21:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-MSkuplxsCB; Tue, 19 Jul 2016 21:31:09 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08EA812DA0C; Tue, 19 Jul 2016 21:31:08 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6K4UvO1018857; Tue, 19 Jul 2016 21:31:06 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 2494s9877f-20 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jul 2016 21:31:06 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jul 2016 07:30:28 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Wed, 20 Jul 2016 07:30:28 +0300 From: Tal Mizrahi To: "Sashank Dara (sadara)" , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tD/+pFIAIAAkjGA Date: Wed, 20 Jul 2016 04:30:28 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_c44cec107c6741c5a51872ecad5b1429ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_04:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200050 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 04:31:13 -0000 --_000_c44cec107c6741c5a51872ecad5b1429ILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sashank, >[SD] The attack is valid only if the attacker can get away bypassing a ser= vice function/node. >For example, if the attacker bypasses a node and if POT determines it did = not bypass is a valid attack on the system. I would phrase it this way: *Given* a packet that did not go through its de= sired path, the attacker can easily make you think that it *did* go through= the desired path. Sounds like a very significant vulnerability. If a packet did not go through the firewall (for one reason or another), th= e attacker will make you think that it did go through the firewall. Cheers, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Wednesday, July 20, 2016 4:31 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: Re: Question regarding Proof of Transit draft The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a serv= ice function/node. For example, if the attacker bypasses a node and if POT determines it did n= ot bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determ= ine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reco= nstructed ! We could emphasize this in our next draft , but it would be beyond scope of= POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_c44cec107c6741c5a51872ecad5b1429ILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sashank,

 <= /p>

>[SD] The attack is vali= d only if the attacker can get away bypassing a service function/node. = ;

>For example, if the att= acker bypasses a node and if POT determines it did not bypass is a valid at= tack on the system.

 <= /p>

I would phrase it this wa= y: *Given* a packet that did not go through its desired path, the at= tacker can easily make you think that it *did* go through the desired path.

Sounds like a very signif= icant vulnerability.

 <= /p>

If a packet did not go th= rough the firewall (for one reason or another), the attacker will make you = think that it did go through the firewall.

 <= /p>

Cheers,=

Tal.

 <= /p>

 <= /p>

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com]
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-o= f-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

The POT replacement attack (1.) is not = an attack on the integrity. It is an attack on the path verification.

This simple attack can cause the verifi= er to accept a packet that did not go through the firewall SF (even though it should). I believe this is exactly the problem you were= aiming to address in this draft.

 

[SD] The attack is valid on= ly if the attacker can get away bypassing a service function/node. 

For example, if the attacke= r bypasses a node and if POT determines it did not bypass is a valid attack= on the system.

 

In the current state, there= is no way an attacker can get away as we determine the exact path the pack= et travelled (aim of the draft) . 

I reiterate that the verifi= er needs to handle what to do with the path reconstructed !

We could emphasize this in = our next draft , but it would be beyond scope of POT to determine what to d= o with the path constructed. 

IMO, It would be highly app= lication specific. 

 

 

Regards,<= /p>

Sashank

 

 

 

Thanks,

Tal.=

 

From: Frank Brockners (fbrockne) [mailto:fbrockn= e@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We’ll pro= vide more details on 2. Per my earlier point – 1. is an interesting discussion, given that we don’t claim to provide integrity protectio= n for the packet payload. Or in other terms – to be exact: What POT p= rovides is a proof that the POT-header/meta-data transited all the required= nodes. There is no association (and thus proof) provided for the additional data carried along with the POT-header –= neither header nor payload. As a consequence, attacks which change the pac= ket payload won’t be detected/mitigated. We’ll explicitly state= this in the security considerations in the next rev of the document.

What we could consider is linking the R= ND number to CRC across the packet payload or similar – but that way we’d restrict the applicability to deployments where the pa= cket payload isn’t changed across the path (which might not apply to = certain deployment – e.g. WAN optimization / compression schemes).

Do you think it is worthwhile to provid= e a solution for a deployment which is expected to not alter the packet payload?

 

Thanks,

Frank

 

From: Tal Mizrahi [mailto:talmi@marvell.com= ]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,<= o:p>

 

To summarize my take on this thread:

The proposed mechanism has two signific= ant vulnerabilities that (in my understanding) are currently not addressed:

1.    &nbs= p;  A man-in-the-middle can replace the POT o= f packet A with the POT of packet B.

2.    &nbs= p;  It is possible to replay POTs within a ce= rtain time window, whose length is determined by the timestamp resolution.<= /span>

 

Sashank, thanks for agreeing to look in= to it further. I am looking forward to your insights on this.

 

Regards,

Tal.=

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01=

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 =

I want to ask a simple question:

If the attacker attaches the POT of packet A (in= dicating the path through 1,3,5,6) to packet B, will the verifier accept pa= cket B and believe that its path was indeed (1,3,5,6)?

 =

[SD] If the verifier is programmed to jus= t validate the POT meta data against {1,3,5,6} then yes it accepts it. 

If the verifier is programmed to consult = a policy database to cross check if the reconstructed path {1,3,5,6} is as per the policies then no , it drops it . 

 =

But I see your point , that the parameter= s used in POT data donot consider the path or node-ids etc . We shall discuss this internally and get back.

 =

Also, We shall get back with more concret= e numbers of the timestamp resolution and cache sizes (or other better approaches). 

 =

Thank you so much for all the inputs.&nbs= p;

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate the quick and detai= led responses.

 

>>>Lets take correct path taken = by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g= . the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only constructs the= path the packet took accurately, it is upto

>the application to determine whether = it violates any policies (I.e missing any function) 

>The bottom line is , an attacker taki= ng a different path cannot get away with it !

>The whole intent of “proof-of-t= ransit” is to prove the path packet has taken exactly. 

>POT does not define whether it good/b= ad path. It is upto high level applications on what

>do with “reconstructed” p= ath. 

 

 

 

I want to ask a simple question:=

If the attacker attaches the POT of pac= ket A (indicating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was indeed (1,3,5,6= )?

 

 

>>Hmmm… Let’s say we = are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, w= e could use as much precision as we want to reduce the number of values to be cached !

 

My point is that assuming reasonable re= sources are used, the mechanism is vulnerable to a replay attack.

In order to prove me wrong, can you pre= sent concrete numbers of the timestamp resolution and the cache size?

Otherwise, you may consider using a seq= uence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.=

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 

 

>[SD] Ok. This is an interesting attac= k.  

> 

>Lets take correct path taken by Packe= t A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Pack= et B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values fro= m Path1 and reattach them to Path2 ,

>the reconstruction for PacketB w= ould result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/= policy db information for any policy

>violations. POT does not enforce a pa= rticular path to be taken.

 

So packet B skipped node 5 (e.g. the fi= rewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only constructs the pat= h the packet took accurately, it is upto the application to determine whether it violates any policies (I.e missing any function) = ;

The bottom line is , an attacker taking a= different path cannot get away with it ! The whole intent of “proof-of-transit” is to prove the path packet has taken ex= actly. 

POT does not define whether it good/bad p= ath. It is upto high level applications on what do with “reconstructe= d” path. 

 =

 

Hmmm… Let’s say we are talk= ing about traffic at 10 Gbps, which is roughly 1 million packets per second= . That would mean the verifier has to store a million values of RND-2.

Moreover, every time a packet arrives, = the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we co= uld use as much precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 =

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 =

[SD] Ok. This is an interesting attack. &= nbsp;

 =

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B= i.e. Path2 -  (1,2,3,6).

 =

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/poli= cy db information for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular= path taken by the packets. 

 =

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 =

[SD] Not really , the verifier could cach= e the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such= , if the verifier caches those values. 

 =

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high le= vel sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that’s reason we recommend using &n= bsp;( Timestamp(/ sequence number) + RND )

 

 =

 =

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_c44cec107c6741c5a51872ecad5b1429ILEXCH02marvellcom_-- From nobody Tue Jul 19 23:24: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 A6FB412DABC; Tue, 19 Jul 2016 23:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 jQremSyCE_vd; Tue, 19 Jul 2016 23:24:02 -0700 (PDT) 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 45B8012D8A1; Tue, 19 Jul 2016 23:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=95519; q=dns/txt; s=iport; t=1468995842; x=1470205442; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nCg96E6wFRehS9ege5WK7q+iNWSeeWj5mPdS8+Yn5ds=; b=YW2EXyas52m2Md324nTa3E9A7dy4IK0LETKbYFKf7BDf5iOA8W+ySEpj Tu3n9FTNNclYbM5fmMa96DduXH1u3Ai2N3A/4hGglaUoVtvQqhAYDqA19 tbPQu+70VvyV5xzgsU0Q9jkg+FJsHXJUwBVFM22/EbeA8ZgYSmX5Js/i1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBXGI9X/5JdJa1dgnFOVnwGuGiBe?= =?us-ascii?q?iKFeAKBMzgUAQEBAQEBAWUnhFwBAQUaTRIQAgEIEQQBASEBBgcyFAkIAgQBDQU?= =?us-ascii?q?bBIgRDr00AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhHaFJQWIIotChUIBh?= =?us-ascii?q?hKCe4JzgmGCAo02kB8BHjaCCxyBTG6GLisYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,392,1464652800"; d="scan'208,217";a="299795457" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 06:24:00 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6K6O0rr014259 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 06:24:00 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 01:23:59 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 01:23:59 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Frank Brockners (fbrockne)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tD/+pFIAIAAkjGA//+u9wA= Date: Wed, 20 Jul 2016 06:23:59 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.66.187] Content-Type: multipart/alternative; boundary="_000_D3B50FF97908Bsadaraciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 06:24:05 -0000 --_000_D3B50FF97908Bsadaraciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >[SD] The attack is valid only if the attacker can get away bypassing a ser= vice function/node. >For example, if the attacker bypasses a node and if POT determines it did = not bypass is a valid attack on the system. I would phrase it this way: *Given* a packet that did not go through its de= sired path, the attacker can easily make you think that it *did* go through= the desired path. Sounds like a very significant vulnerability. If a packet did not go through the firewall (for one reason or another), th= e attacker will make you think that it did go through the firewall. [SD] At a high level , looks like it is , Because each node did not really= digitially sign the packet that it infact went through it . We shall investigate what light weight mitigation techniques could be incor= porated as we wanted to avoid heavy encryptions doing this inband at each n= ode. Thanks again for point this . Regards, Sashank Cheers, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Wednesday, July 20, 2016 4:31 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: Re: Question regarding Proof of Transit draft The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a serv= ice function/node. For example, if the attacker bypasses a node and if POT determines it did n= ot bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determ= ine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reco= nstructed ! We could emphasize this in our next draft , but it would be beyond scope of= POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We=92ll provide more details on 2. Per my earlier p= oint =96 1. is an interesting discussion, given that we don=92t claim to pr= ovide integrity protection for the packet payload. Or in other terms =96 to= be exact: What POT provides is a proof that the POT-header/meta-data trans= ited all the required nodes. There is no association (and thus proof) provi= ded for the additional data carried along with the POT-header =96 neither h= eader nor payload. As a consequence, attacks which change the packet payloa= d won=92t be detected/mitigated. We=92ll explicitly state this in the secur= ity considerations in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar =96 but that way we=92d restrict the applicability to dep= loyments where the packet payload isn=92t changed across the path (which mi= ght not apply to certain deployment =96 e.g. WAN optimization / compression= schemes). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of =93proof-of-transit=94 is to prove the path packet has= taken exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with =93reconstructed=94 path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rou= ghly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of =93proof-of-transit=94 is to prove the path pac= ket has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with =93reconstructed=94 path. Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rough= ly 1 million packets per second. That would mean the verifier has to store = a million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a =91mix and match=92 attack, by taking the corr= ect POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn=92t it be poss= ible to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that=92s reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let=92s say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can =91launder=92 packet B by replacing the (incorrect) POT of= packet B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node=92s POT values (from older pack= et traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier=92s share of RND-3 is never on wire , so attacker cannot just obse= rve the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the =93Reply Attacks=94 , we recommend that the RND-2 (= generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND n= umber=94) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_D3B50FF97908Bsadaraciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B4EB3843F0D0849A96165E45D444CE3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

 

>[SD] The attack is valid only if the att= acker can get away bypassing a service function/node. 

>For example, if the attacker bypasses a = node and if POT determines it did not bypass is a valid attack on the syste= m.

 

I would phrase it this way: *Giv= en* a packet that did not go through its desired path, the attacker can= easily make you think that it *did* go through the desired path.

Sounds like a very significant vuln= erability.

 

If a packet did not go through the = firewall (for one reason or another), the attacker will make you think that= it did go through the firewall.


[SD]  At a high level , looks like it is , Because each node did = not really digitially sign the packet that it infact went through it . = ;
We shall investigate what light weight mitigation techniques could be = incorporated as we wanted to avoid heavy encryptions doing this inband at e= ach node. 
 

Thanks again for point this .

Regards,
Sashank


 

Cheers,

Tal.

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com]
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

The POT replacement attack (1.) is not an attack = on the integrity. It is an attack on the path verification.

This simple attack can cause the verifier to acce= pt a packet that did not go through the firewall SF (even though it should). I believe this is exactly the problem= you were aiming to address in this draft.

 

[SD] The attack is valid only if the attacke= r can get away bypassing a service function/node. 

For example, if the attacker bypasses a node= and if POT determines it did not bypass is a valid attack on the system.

 

In the current state, there is no way an att= acker can get away as we determine the exact path the packet travelled (aim= of the draft) . 

I reiterate that the verifier needs to handl= e what to do with the path reconstructed !

We could emphasize this in our next draft , = but it would be beyond scope of POT to determine what to do with the path c= onstructed. 

IMO, It would be highly application specific= . 

 

 

Regards,

Sashank

 

 

 

Thanks,

Tal.

 

From: Frank Brockners (fbrockne) [mailto:fbrockn= e@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We=92ll provide more deta= ils on 2. Per my earlier point =96 1. is an interesting discussion, given that we don=92t claim to provide integrity p= rotection for the packet payload. Or in other terms =96 to be exact: What P= OT provides is a proof that the POT-header/meta-data transited all the requ= ired nodes. There is no association (and thus proof) provided for the additional data carried along with the P= OT-header =96 neither header nor payload. As a consequence, attacks which c= hange the packet payload won=92t be detected/mitigated. We=92ll explicitly = state this in the security considerations in the next rev of the document. <= /o:p>

What we could consider is linking the RND number = to CRC across the packet payload or similar =96 but that way we=92d restrict the applicability to deployments where th= e packet payload isn=92t changed across the path (which might not apply to = certain deployment =96 e.g. WAN optimization / compression schemes).

Do you think it is worthwhile to provide a soluti= on for a deployment which is expected to not alter the packet payload?

 

Thanks,

Frank

 

From: Tal Mizrahi [mailto:talmi@marvell.com= ]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,=

 

To summarize my take on this thread:

The proposed mechanism has two significant vulner= abilities that (in my understanding) are currently not addressed:

       A man-in-the-middle can replace the POT of packet A= with the POT of packet B.

       It is possible to replay POTs within a certain time= window, whose length is determined by the timestamp resolution.

 

Sashank, thanks for agreeing to look into it furt= her. I am looking forward to your insights on this.

 

Regards,<= /o:p>

Tal.

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01=

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (indicating t= he path through 1,3,5,6) to packet B, will the verifier accept packet B and= believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is programmed to just validate the PO= T meta data against {1,3,5,6} then yes it accepts it. <= /p>

If the verifier is programmed to consult a policy database= to cross check if the reconstructed path {1,3,5,6} is as per the policies then no , it drops it . 

 

But I see your point , that the parameters used in POT dat= a donot consider the path or node-ids etc . We shall discuss this internally and get back.

 

Also, We shall get back with more concrete numbers of the = timestamp resolution and cache sizes (or other better approaches). 

 

Thank you so much for all the inputs. 

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,<= o:p>

 

I really appreciate the quick and detailed respon= ses.

 

>>>Lets take correct path taken by Packet A  = ;to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g. the fire= wall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only constructs the path the packet = took accurately, it is upto

>the application to determine whether it violates any p= olicies (I.e missing any function) =

>The bottom line is , an attacker taking a different pa= th cannot get away with it !

>The whole intent of =93proof-of-transit=94 is to prove= the path packet has taken exactly. 

>POT does not define whether it good/bad path. It is up= to high level applications on what

>do with =93reconstructed=94 path. 

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (ind= icating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was indeed = (1,3,5,6)?

 

 

>>Hmmm=85 Let=92s say we are talking about = traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

&g= t;[SD] Second level precision is only an example, we could use as much= precision as we want to reduce the number of values to be cached !=

 

My point is that assuming reasonable resources ar= e used, the mechanism is vulnerable to a replay attack.

In order to prove me wrong, can you present concr= ete numbers of the timestamp resolution and the cache size?

Otherwise, you may consider using a sequence numb= er + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

 

>[SD] Ok. This is an interesting attack.  <= span style=3D"color:black">

> 

>Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values from Path1 and reattach them to Path2 ,

>the reconstruction for PacketB would result in (1= ,3,5,6) instead of (1,2,3,6). =

>This could be compared with topology/policy db informa= tion for any policy

>violations. POT does not enforce a particular path to = be taken.

 

So packet B skipped node 5 (e.g. the firewall SF)= , but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only constructs the path the packet took= accurately, it is upto the application to determine whether it violates any policies (I.e missing any function)&n= bsp;

The bottom line is , an attacker taking a different path c= annot get away with it ! The whole intent of =93proof-of-transit=94 is to prove the path packet has taken exactly.&n= bsp;

POT does not define whether it good/bad path. It is upto h= igh level applications on what do with =93reconstructed=94 path. 

 

 

Hmmm=85 Let=92s say we are talking about traffic = at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrives, the verifi= er would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[S= D] Second level precision is only an example, we could use as much pre= cision as we want to reduce the number of values to be cached !

 

&n= bsp;

Sashank <= /span>

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A and B:<= span style=3D"color:black">

- Packet A that went through the correct path and= has a correct POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 Now the attacker performs a =91mix and match=92 atta= ck, by taking the correct POT from packet A and attaching it to packet B.

The attacker also terminates packet A.

There is no replay here, because the verifier rec= eives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the verifier, even= though it did not go through the correct path.

 

Is there a way to mitigate this attack?

 

[SD] Ok. This is an interesting attack.  

 

Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/policy db information= for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular path taken by th= e packets. 

 

Do you mean that there is a one-second-vulnerabil= ity for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could cache the RND-2 numbe= rs used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as = such, if the verifier caches those values. 

 

Effective replay prevention is typically performe= d using a sequence number, with a sliding window to allow out-of-order packets. Wouldn=92t it be possible to incorpo= rate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high level sequence numb= er (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that=92s reason we recommend using  ( Timestamp(/ seq= uence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. More inline with = [SD] .. 

 

 

Right, I am referring to the former. The integrity check i= s not the issue.

Let=92s say we have:

- Packet A that went through the correct path and has a co= rrect POT.

- Packet B that did not go through the correct path and do= es not have a correct POT.

 

The attacker can =91launder=92 packet B by replacing the (= incorrect) POT of packet B with the correct POT of packet A (and drop packe= t A).

Thus, packet B is verified correctly, even though it did n= ot go through the correct path.

 

[SD] This is valid scenario and we have certain in-built m= itigation techniques and recommendations for the same. 

There are two scenarios here 

 

Partial Replay of POT data (Replaying intermediate CMLs= )

 

Attacker cannot reuse few intermediate node=92s POT values= (from older packet traces) as it would disrupt the POLY-3 construction. <= o:p>

On the other hand if the attacker tries to replay entire s= equence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and partic= ipates in the reconstruction of RND-3.

Verifier=92s share of RND-3 is never on wire , so attacker= cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying complete RND-2)

 

Another trick, attacker could do is by completely reusing = RND-2 (but not intermediate CML values)<= o:p>

In order to prevent the =93Reply Attacks=94 , we recommend= that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND number=94)

So in case a passive attacker tries to replay one of the c= orrect but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than current timestamp= we drop/raise a flag ! =

 

There is still a small window , where the attacker could r= eplay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is 32 bits , we cou= ld get one seconds level precision in the time window . So it is highly impossible for the attacker to replay wi= thin such a small time at such a high packet rates. 

 

Also , the verifier could cache, if needed, certain number= of previously used RND-2 to mitigate replay attacks. =

 

Hope this clarifies. 

 

 --_000_D3B50FF97908Bsadaraciscocom_-- From nobody Wed Jul 20 00:16: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 BF63412D9B9; Wed, 20 Jul 2016 00:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 FdLAv6Eugj4a; Wed, 20 Jul 2016 00:16:06 -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 265A412D0DE; Wed, 20 Jul 2016 00:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85553; q=dns/txt; s=iport; t=1468998966; x=1470208566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+YJuwJKXDbOy3GWoBZ9TK/MAh9CcKdo/UQkt7pDJp4Y=; b=B4HxsCblmKnb6HN0VBQEyWHGEAHG3iH95iNZh8VB1oJLGp0LctGUaSod CemLPQrqI+TmisGum+3D0yW8TgDt5CAM15gnx4oCjJBPAkyHQM6DNaXxd pD5tLoFuhtSBIbhzxxgymRxPHcn5oprmvtu5n4ld21AlvVZWGqLyCpp6/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQDcI49X/51dJa1dgnFOVnwGuGiBe?= =?us-ascii?q?iKFeAKBMzgUAQEBAQEBAWUnhFwBAQUaEzoSEAIBCBEEAQEhAQYHMhQJCAIEAQ0?= =?us-ascii?q?FCBMEiBEOvTIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2EdoUlBYgii0KFQ?= =?us-ascii?q?gGGEoJ7gnOCWoIJjTaQHwEeNoILHIFMboYuKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208,217";a="127817655" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 07:16:03 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u6K7G3mW022109 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 07:16:03 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; Wed, 20 Jul 2016 02:16:02 -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; Wed, 20 Jul 2016 02:16:02 -0500 From: "Frank Brockners (fbrockne)" To: Tal Mizrahi , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tCABdCDgA== Date: Wed, 20 Jul 2016 07:16:02 +0000 Message-ID: <99c4c8222952442f9a8c99713cbbbffe@XCH-RCD-008.cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: de-DE, 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.244.97] Content-Type: multipart/alternative; boundary="_000_99c4c8222952442f9a8c99713cbbbffeXCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 07:16:11 -0000 --_000_99c4c8222952442f9a8c99713cbbbffeXCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal, well... if you could protect the integrity of the data stream between sourc= e and destination, you would not be able to swap the content of a packet - = which is what your attack is all about. Rather than continue arguing the po= int, let's acknowledge that it is a valid attack and let's look for a solut= ion :-). We'll need to couple POT to integrity protection of the packet. Hence, I'd like to come back to my question asked below: Do you (and the entire SFC team here) think it is worthwhile to provide a s= olution for a deployment which is expected to *not* alter the packet payloa= d? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 18:15 To: Frank Brockners (fbrockne) ; Sashank Dara (sadara) = ; draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Frank, The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_99c4c8222952442f9a8c99713cbbbffeXCHRCD008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal,

 = ;

well... if you could protect the integrity of the data stream between = source and destination, you would not be able to swap the content of a packet – which is what your attack is all abou= t. Rather than continue arguing the point, let’s acknowledge that it = is a valid attack and let’s look for a solution :-). We’ll need= to couple POT to integrity protection of the packet.

 

Hence, I’d like to come back to my question asked below:  <= o:p>

Do you (and the entire= SFC team here) think it is worthwhile to provide a solution for a deployme= nt which is expected to *not* alter the packet payload?

 

Thanks, Frank

 

From: = Tal Mizrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 18:15
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Sashank D= ara (sadara) <sadara@cisco.com>; draft-brockners-proof-of-transit@too= ls.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Frank,

 

The POT replacement at= tack (1.) is not an attack on the integrity. It is an attack on the path ve= rification.

This simple attack can= cause the verifier to accept a packet that did not go through the firewall= SF (even though it should). I believe this is exactly the problem you were aiming to address in this draft.

 

Thanks,

Tal.=

 

From: Fr= ank Brockners (fbrockne) [mailto:fbro= ckne@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary= . We’ll provide more details on 2. Per my earlier point – 1. is= an interesting discussion, given that we don’t claim to provide integrity protection for the packet payload. Or in other terms – to = be exact: What POT provides is a proof that the POT-header/meta-data transi= ted all the required nodes. There is no association (and thus proof) provid= ed for the additional data carried along with the POT-header – neither header nor payload. As a consequence, = attacks which change the packet payload won’t be detected/mitigated. = We’ll explicitly state this in the security considerations in the nex= t rev of the document.

What we could consider= is linking the RND number to CRC across the packet payload or similar R= 11; but that way we’d restrict the applicability to deployments where the packet payload isn’t changed across the path (which might = not apply to certain deployment – e.g. WAN optimization / compression= schemes).

Do you think it is wor= thwhile to provide a solution for a deployment which is expected to not alt= er the packet payload?

 

Thanks,

Frank

 

 

Hi,<= /p>

 

To summarize my take o= n this thread:

The proposed mechanism= has two significant vulnerabilities that (in my understanding) are current= ly not addressed:

1.       A man-in-the-middle can replace the PO= T of packet A with the POT of packet B.

2.       It is possible to replay POTs within a= certain time window, whose length is determined by the timestamp resolutio= n.

 

Sashank, thanks for ag= reeing to look into it further. I am looking forward to your insights on th= is.

 

Regards,

Tal.=

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 =

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier accept= packet B and believe that its path was indeed (1,3,5,6)?

 =

[SD] If the verifier is = programmed to just validate the POT meta data against {1,3,5,6} then yes it= accepts it. 

If the verifier is progr= ammed to consult a policy database to cross check if the reconstructed path= {1,3,5,6} is as per the policies then no , it drops it . 

 =

But I see your point , t= hat the parameters used in POT data donot consider the path or node-ids etc= . We shall discuss this internally and get back.

 =

Also, We shall get back = with more concrete numbers of the timestamp resolution and cache sizes (or = other better approaches). 

 =

Thank you so much for al= l the inputs. 

 

 

 

From: Ta= l Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate th= e quick and detailed responses.

 

>>>Lets take correct path tak= en by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (= e.g. the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier on= ly constructs the path the packet took accurately, it is upto

>the application to d= etermine whether it violates any policies (I.e missing any function) <= o:p>

>The bottom line is ,= an attacker taking a different path cannot get away with it !

>The whole intent of = “proof-of-transit” is to prove the path packet has taken exactl= y. 

>POT does not define = whether it good/bad path. It is upto high level applications on what

>do with “recon= structed” path. 

 

 

 

I want to ask a simple= question:

If the attacker attach= es the POT of packet A (indicating the path through 1,3,5,6) to packet B, w= ill the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 

 

>>Hmmm… Let’s say = we are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could u= se as much precision as we want to reduce the number of values to be cached !

 

My point is that assum= ing reasonable resources are used, the mechanism is vulnerable to a replay = attack.

In order to prove me w= rong, can you present concrete numbers of the timestamp resolution and the = cache size?

Otherwise, you may con= sider using a sequence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.=

 

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 

 

>[SD] Ok. This is an interesting at= tack.  

> 

>Lets take correct path taken by Pa= cket A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be P= acket B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values = from Path1 and reattach them to Path2 ,

>the reconstruction for Packet= B would result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topolo= gy/policy db information for any policy

>violations. POT does not enforce a= particular path to be taken.

 

So packet B skipped node 5 (e.g. the= firewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only c= onstructs the path the packet took accurately, it is upto the application t= o determine whether it violates any policies (I.e missing any function) 

The bottom line is , an = attacker taking a different path cannot get away with it ! The whole intent= of “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whet= her it good/bad path. It is upto high level applications on what do with &#= 8220;reconstructed” path. 

 =

 

Hmmm… Let’s say we are t= alking about traffic at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrive= s, the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.=

Am I missing something here?<= span lang=3D"EN-US" style=3D"font-size:10.5pt;color:black">

 

[SD] Second level precision is only an example, we could use a= s much precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A a= nd B:

- Packet A that went through the cor= rect path and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 Now the attacker performs a ‘mix = and match’ attack, by taking the correct POT from packet A and attach= ing it to packet B.<= /o:p>

The attacker also terminates packet = A.

There is no replay here, because the= verifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the v= erifier, even though it did not go through the correct path.<= /p>

 

Is there a way to mitigate this atta= ck?

 

[SD] Ok. This is an interesting attack= .  

 

Lets take correct path taken by Packet= A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packe= t B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/p= olicy db information for any policy violations. POT does not enforce a particular path to be taken.

 It just reconstructs the particu= lar path taken by the packets. 

 

Do you mean that there is a one-seco= nd-vulnerability for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could c= ache the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerabil= ity as such, if the verifier caches those values. 

 

Effective replay prevention is typic= ally performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to inc= orporate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high= level sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential anal= ysis of CML values (across packets) becomes very easy  and predictable= .

that’s reason we recommend using=  ( Timestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our wor= k. More inline with [SD] .. 

 

 

Right, I am referring to the former. The inte= grity check is not the issue.

Let’s say we have:

- Packet A that went through the correct path= and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 

The attacker can ‘launder’ packet= B by replacing the (incorrect) POT of packet B with the correct POT of pac= ket A (and drop packet A).

Thus, packet B is verified correctly, even th= ough it did not go through the correct path.

 

[SD] This is valid scenario and we hav= e certain in-built mitigation techniques and recommendations for the same. =

There are two scenarios here 

 

Partial Replay of POT data (Replayi= ng intermediate CMLs)=

 

Attacker cannot reuse few intermediate= node’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker trie= s to replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and = participates in the reconstruction of RND-3.

Verifier’s share of RND-3 is nev= er on wire , so attacker cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying= complete RND-2)=

 

Another trick, attacker could do is by= completely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply A= ttacks” , we recommend that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D “Time Stamp + RND number”)=

So in case a passive attacker tries to= replay one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved fr= om RND-2.

If the retrieved timestamp is older th= an current timestamp we drop/raise a flag ! 

 

There is still a small window , where = the attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearl= y impossible for the attacker to replay.

For example , if the Time Stamp chosen= is 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay= within such a small time at such a high packet rates. 

 

Also , the verifier could cache, if ne= eded, certain number of previously used RND-2 to mitigate replay attacks. 

 

Hope this clarifies. 

 

--_000_99c4c8222952442f9a8c99713cbbbffeXCHRCD008ciscocom_-- From nobody Wed Jul 20 00:18: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 340BE12DAD3; Wed, 20 Jul 2016 00:18:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wnizUK4qnAa; Wed, 20 Jul 2016 00:18:17 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F415112D5A3; Wed, 20 Jul 2016 00:18:15 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6K7I993010023; Wed, 20 Jul 2016 08:18:09 +0100 Received: from 950129200 (jplon-nat14.juniper.net [193.110.55.14]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u6K7I6BQ009948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 08:18:06 +0100 From: "Adrian Farrel" To: "'Tal Mizrahi'" , "'Sashank Dara \(sadara\)'" , "'Frank Brockners \(fbrockne\)'" , References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> In-Reply-To: Date: Wed, 20 Jul 2016 08:18:08 +0100 Message-ID: <023a01d1e256$df024db0$9d06e910$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0241_01D1E25F.40DDE730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGnwjP8403RB3RZITNexDlhPioHQgHOVwxCAZGjq+QCnnHCCQL1sC20AqPwfdABqYRZ+QGZXaZXAkfPlN0CfN4jWgIBLcy+AVdrFS0Bh6eIiZ+xJuIg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22462.005 X-TM-AS-Result: No--32.241-10.0-31-10 X-imss-scan-details: No--32.241-10.0-31-10 X-TMASE-MatchedRID: jFqw+1pFnMyscfIVXlfrb1VN8laWo90MnuwCcgqnTfAgUEQTkIWiYgli aG5U71Ci+h4WVqRDM2Stwp9aPllPBuE5IDxKpHS7wVaayvK71l9B+8LAeeOOMH1ZAf3L+lJd753 F/IrerKEd5bUwpqpsr9Xz4rXOsFj9o28kkGKrXVqzwJcJKPFV6w48ME9K+hF0q8z7POX8FJN88o MWq8CcbopzPHGRYWxAqNKsX8Rc5Jct0WlW1s7EaVeollpgzyxA4+ZcrqvCDkEcXmBZ3mI5ST5Re TebdoC/XF6q4U3K29LA3E/7HJRrJ/nVY0DWsTq3ZWiHWRWeiRsnF9tfS9Su0JlLjDiSpE8+9tSE +/rqNhjFd3GuoNVLfW9ZGG7u+faGZ73RnaBbLFpIRA38P/dwbmKaLwu81+avuu0N7j6PSiNugYk 8OnNISUwhG6kZw/fc8GIW4FpPo/OKkK3fTpnxAylrosmS0SOAoddeo3DnwAuBTeBKqBRm8r1A/V 6RVDjDpRye3XXGd7IrSkqxa82HLHsQZsIG1c2H1yMJs9mBCcWl9VzHf0qr7peZYtcskV9PRE9xQ BYdJhOj5dd1UyGsE7k3b0GdOaeHfL+CSMa2ZdXarFB+yK/aw7tq3FNsoMQgasEfs27jsmEeoQAG Xdw2QiT0w1zt2plxNwPV2Kp9lA6+9Go4BgFPZo1nuRzhSr7jLi2dwKiMR9xo5YsPsbyLXQqQQQL Mh66ndYxO9VuCM39vjiZqcnX6cga9D+nuvxP8tNMyJ72jQd1lrsuS5tC+PxsizOQuDf4x+mDWSr 86jwHMZPgkP0CcqtkRIHRUA4VL/dCbyVkjT66eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDOG2o4D tJIL5vLE5hS3p8WRjjVhf+j/wpKdDgyPBo713kguuQorcgMOiCHLfKhbQuZKNobWmYHQ/bIfn3R K6FR7HHcBSm4mdV+3BndfXUhXQ== Archived-At: Cc: opsawg@ietf.org, nvo3@ietf.org, sfc@ietf.org Subject: Re: [sfc] [OPSAWG] Question regarding Proof of Transit draft 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, 20 Jul 2016 07:18:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0241_01D1E25F.40DDE730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What is worrying me in this conversations is the discrepancy between the stated aim in draft-brockners-proof-of-transit and the function provided by the draft. I'm not (at the moment ;-) picking hols in what the S**3 scheme achieves, but I am questioning whether it provides enough to be useful in the context stated. So draft-brockners-proof-of-transit says... > This document defines mechanisms to > securely prove that traffic transited the defined path. and > In certain cases regulatory > obligations or a compliance policy require operators to prove that > all packets that are supposed to follow a specific path are indeed > being forwarded across and exact set of pre-determined nodes. Shamir as applied in this document does not meet those criteria. It only shows that all members of a defined set of nodes were traversed at some point along the path. It neither guarantees ordering, nor does it protect against the insertion of additional nodes on the path. Other parts of the document are more clear about exactly this point. it is not clear to me, therefore, whether the intention is misstated in the text I quoted, or whether the proposed solution (while good at what it does) is inadequate for the purpose. BTW, think it is not clear in the text that the order of the polynomial must count the verifying node. I.e., the verifying node must also insert a point on the curve. This is needed because otherwise the full set of points is included in a message on the wire and the polynomial becomes vulnerable. Thanks, Adrian From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: 20 July 2016 05:30 To: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org Subject: Re: [OPSAWG] Question regarding Proof of Transit draft Hi Sashank, >[SD] The attack is valid only if the attacker can get away bypassing a service function/node. >For example, if the attacker bypasses a node and if POT determines it did not bypass is a valid attack on the system. I would phrase it this way: *Given* a packet that did not go through its desired path, the attacker can easily make you think that it *did* go through the desired path. Sounds like a very significant vulnerability. If a packet did not go through the firewall (for one reason or another), the attacker will make you think that it did go through the firewall. Cheers, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Wednesday, July 20, 2016 4:31 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: Re: Question regarding Proof of Transit draft The POT replacement attack (1.) is not an attack on the integrity. It is an attack on the path verification. This simple attack can cause the verifier to accept a packet that did not go through the firewall SF (even though it should). I believe this is exactly the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a service function/node. For example, if the attacker bypasses a node and if POT determines it did not bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reconstructed ! We could emphasize this in our next draft , but it would be beyond scope of POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier point - 1. is an interesting discussion, given that we don't claim to provide integrity protection for the packet payload. Or in other terms - to be exact: What POT provides is a proof that the POT-header/meta-data transited all the required nodes. There is no association (and thus proof) provided for the additional data carried along with the POT-header - neither header nor payload. As a consequence, attacks which change the packet payload won't be detected/mitigated. We'll explicitly state this in the security considerations in the next rev of the document. What we could consider is linking the RND number to CRC across the packet payload or similar - but that way we'd restrict the applicability to deployments where the packet payload isn't changed across the path (which might not apply to certain deployment - e.g. WAN optimization / compression schemes). Do you think it is worthwhile to provide a solution for a deployment which is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) ; Frank Brockners (fbrockne) ; draft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my understanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT of packet B. 2. It is possible to replay POTs within a certain time window, whose length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data against {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check if the reconstructed path {1,3,5,6} is as per the policies then no , it drops it . But I see your point , that the parameters used in POT data donot consider the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolution and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6). >>>This could be compared with topology/policy db information for any policy >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier believes it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it is upto >the application to determine whether it violates any policies (I.e missing any function) >The bottom line is , an attacker taking a different path cannot get away with it ! >The whole intent of "proof-of-transit" is to prove the path packet has taken exactly. >POT does not define whether it good/bad path. It is upto high level applications on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was indeed (1,3,5,6)? >>Hmmm. Let's say we are talking about traffic at 10 Gbps, which is roughly >>1 million packets per second. That would mean the verifier has to store a million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare its >>RND-2 value with the 1 million stored values, in order to verify there is no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much precision as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is vulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timestamp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g., as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believes it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it is upto the application to determine whether it violates any policies (I.e missing any function) The bottom line is , an attacker taking a different path cannot get away with it ! The whole intent of "proof-of-transit" is to prove the path packet has taken exactly. POT does not define whether it good/bad path. It is upto high level applications on what do with "reconstructed" path. Hmmm. Let's say we are talking about traffic at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precision as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a correct POT. Now the attacker performs a 'mix and match' attack, by taking the correct POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L Thus, packet B appears okay to the verifier, even though it did not go through the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6). This could be compared with topology/policy db information for any policy violations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn't it be possible to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis of CML values (across packets) becomes very easy and predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a correct POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of packet B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the correct path. [SD] This is valid scenario and we have certain in-built mitigation techniques and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observe the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not intermediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (generated per packet) be a combination (I.e. RND2 = "Time Stamp + RND number") So in case a passive attacker tries to replay one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a flag ! There is still a small window , where the attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously used RND-2 to mitigate replay attacks. Hope this clarifies. ------=_NextPart_000_0241_01D1E25F.40DDE730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is worrying me in this = conversations is the discrepancy between the stated aim in = draft-brockners-proof-of-transit and the function provided by the draft. = I'm not (at the moment ;-) picking hols in what the S**3 scheme = achieves, but I am questioning whether it provides enough to be useful = in the context stated.

 

So = draft-brockners-proof-of-transit says...

 

> This document defines = mechanisms to

> securely prove that = traffic transited the defined path.

 

and

 

>  In certain cases = regulatory

>  obligations or a compliance = policy require operators to prove that

>  all packets that are supposed = to follow a specific path are indeed

>  being forwarded across and = exact set of pre-determined nodes.

 

Shamir as applied in this = document does not meet those criteria. It only shows that all members of = a defined set of nodes were traversed at some point along the path. It = neither guarantees ordering, nor does it protect against the insertion = of additional nodes on the path.

 

Other parts of the document = are more clear about exactly this point. it is not clear to me, = therefore, whether the intention is misstated in the text I quoted, or = whether the proposed solution (while good at what it does) is inadequate = for the purpose.

 

BTW,  think it is not clear in the = text that the order of the polynomial must count the verifying node. = I.e., the verifying node must also insert a point on the curve. This is = needed because otherwise the full set of points is included in a message = on the wire and the polynomial becomes = vulnerable.

 

Thanks,

Adrian

 

From: OPSAWG = [mailto:opsawg-bounces@ietf.org] On Behalf Of Tal = Mizrahi
Sent: 20 July 2016 05:30
To: Sashank Dara = (sadara); Frank Brockners (fbrockne); = draft-brockners-proof-of-transit@tools.ietf.org
Cc: = opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org
Subject: Re: = [OPSAWG] Question regarding Proof of Transit = draft

 

Hi Sashank,

 

>[SD] The attack is valid only if the = attacker can get away bypassing a service = function/node. 

>For example, if the attacker bypasses a = node and if POT determines it did not bypass is a valid attack on the = system.

 

I would phrase it this way: *Given* a = packet that did not go through its desired path, the attacker can easily = make you think that it *did* go through the desired = path.

Sounds like a very significant = vulnerability.

 

If a packet did not go through the firewall = (for one reason or another), the attacker will make you think that it = did go through the firewall.

 

Cheers,

Tal.

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal = Mizrahi; Frank Brockners (fbrockne); = draft-brockners-proof-of-transit@tools.ietf.org
Cc: = sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: Re: = Question regarding Proof of Transit = draft

 

<= p class=3DMsoNormal> 

 

The POT replacement attack (1.) is not an = attack on the integrity. It is an attack on the path = verification.

This simple attack can cause the verifier to = accept a packet that did not go through the firewall SF (even though it = should). I believe this is exactly the problem you were aiming to = address in this draft.

 

[SD] The attack is valid only if the attacker = can get away bypassing a service = function/node. 

For example, if the attacker bypasses a node = and if POT determines it did not bypass is a valid attack on the = system.

 

In the current state, there is no way an = attacker can get away as we determine the exact path the packet = travelled (aim of the draft) . 

I reiterate that the verifier needs to handle = what to do with the path reconstructed = !

We could emphasize this in our next draft , but = it would be beyond scope of POT to determine what to do with the path = constructed. 

IMO, It would be highly application = specific. 

 

 

Regards,

Sashank

 

 

 

Thanks,

Tal.

 

From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] =
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal = Mizrahi; Sashank Dara (sadara); draft-bro= ckners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: = Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We’ll provide = more details on 2. Per my earlier point – 1. is an interesting = discussion, given that we don’t claim to provide integrity = protection for the packet payload. Or in other terms – to be = exact: What POT provides is a proof that the POT-header/meta-data = transited all the required nodes. There is no association (and thus = proof) provided for the additional data carried along with the = POT-header – neither header nor payload. As a consequence, attacks = which change the packet payload won’t be detected/mitigated. = We’ll explicitly state this in the security considerations in the = next rev of the document.

What we could consider is linking the RND = number to CRC across the packet payload or similar – but that way = we’d restrict the applicability to deployments where the packet = payload isn’t changed across the path (which might not apply to = certain deployment – e.g. WAN optimization / compression schemes). =

Do you think it is worthwhile to provide a = solution for a deployment which is expected to not alter the packet = payload?

 

Thanks,

Frank

 

=

From: Tal Mizrahi [mailto:talmi@marvell.com] =
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank = Dara (sadara) <sadara@cisco.com>; Frank = Brockners (fbrockne) <fbrockne@cisco.com>; draft-bro= ckners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: = Question regarding Proof of Transit draft

 

Hi,

 

To summarize my take on this = thread:

The proposed mechanism has two significant = vulnerabilities that (in my understanding) are currently not = addressed:

1.       = A man-in-the-middle can replace the POT of = packet A with the POT of packet B.

2.       = It is possible to replay POTs within a = certain time window, whose length is determined by the timestamp = resolution.

 

Sashank, thanks for agreeing to look into it = further. I am looking forward to your insights on this.

 

Regards,

Tal.

 

Link to the draft: = https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal = Mizrahi; Frank Brockners (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: = Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier = accept packet B and believe that its path was indeed = (1,3,5,6)?

 

[SD] If the verifier is programmed to just = validate the POT meta data against {1,3,5,6} then yes it accepts = it. 

If the verifier is programmed to consult a = policy database to cross check if the reconstructed path {1,3,5,6} is as = per the policies then no , it drops it . 

 

But I see your point , that the parameters used = in POT data donot consider the path or node-ids etc . We shall discuss = this internally and get back.

 

Also, We shall get back with more concrete = numbers of the timestamp resolution and cache sizes (or other better = approaches). 

 

Thank you so much for all the = inputs. 

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, = 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners = (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: = Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate the quick and detailed = responses.

 

>>>Lets take correct path taken by = Packet A  to be Path1 - ( 1,3,5,6) = nodes. 
>>>Lets assume incorrect path to be Packet B = i.e. Path2 - =  (1,2,3,6).
>>> 
>>>If the attacker = could take values from Path1 and reattach them to Path2 , =
>>>the reconstruction for PacketB would result in = (1,3,5,6) instead of (1,2,3,6). 
>>>This could be = compared with topology/policy db information for any policy =
>>>violations. POT does not enforce a particular path to be = taken.

>>So packet B skipped node 5 (e.g. the = firewall SF), but the verifier believes it went through the correct = path.
>>Would you agree?

>[SD] The verifier only constructs the path = the packet took accurately, it is upto

>the application to determine whether it = violates any policies (I.e missing any function) 

>The bottom line is , an attacker taking a = different path cannot get away with it !

>The whole intent of = “proof-of-transit” is to prove the path packet has taken = exactly. 

>POT does not define whether it good/bad = path. It is upto high level applications on what

>do with “reconstructed” = path. 

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier = accept packet B and believe that its path was indeed (1,3,5,6)? =

 

 

>>Hmmm… Let’s say we are = talking about traffic at 10 Gbps, which is roughly
>>1 million = packets per second. That would mean the verifier has to store a million = values of RND-2.
>>Moreover, every time a packet arrives, the = verifier would have to compare its
>>RND-2 value with the 1 = million stored values, in order to verify there is no = replay.
>>That does not sound feasible.
>>Am I missing = something here?

>[SD] Second level precision is only an example, we = could use as much precision as we want to reduce the number of values to = be cached !

 

My point is that assuming reasonable = resources are used, the mechanism is vulnerable to a replay = attack.

In order to prove me wrong, can you present = concrete numbers of the timestamp resolution and the cache = size?

Otherwise, you may consider using a sequence = number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal = Mizrahi; Frank Brockners (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: = Question regarding Proof of Transit draft

 

 

 

 

>[SD] Ok. This is an interesting attack. =  

> 

>Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Packet B = i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values from = Path1 and reattach them to Path2 ,

>the reconstruction for PacketB would = result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/policy = db information for any policy

>violations. POT does not enforce a = particular path to be taken.

 

So packet B skipped node 5 (e.g. the firewall = SF), but the verifier believes it went through the correct = path.

Would you agree?

 

[SD] The verifier only constructs the path the = packet took accurately, it is upto the application to determine whether = it violates any policies (I.e missing any function) 

The bottom line is , an attacker taking a = different path cannot get away with it ! The whole intent of = “proof-of-transit” is to prove the path packet has taken = exactly. 

POT does not define whether it good/bad path. = It is upto high level applications on what do with = “reconstructed” path. 

 

 

Hmmm… Let’s say we are talking = about traffic at 10 Gbps, which is roughly 1 million packets per second. = That would mean the verifier has to store a million values of = RND-2.

Moreover, every time a packet arrives, the = verifier would have to compare its RND-2 value with the 1 million stored = values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we could = use as much precision as we want to reduce the number of values to be = cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal = Mizrahi; Frank Brockners (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: = Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A and = B:

- Packet A that went through the correct path = and has a correct POT.

- Packet B that did not go through the = correct path and does not have a correct POT.

 Now the attacker performs a ‘mix = and match’ attack, by taking the correct POT from packet A and = attaching it to packet B.

The attacker also terminates packet = A.

There is no replay here, because the verifier = receives the correct POT only once. The problem is that the correct POT = happens to arrive with packet B. L

Thus, packet B appears okay to the verifier, = even though it did not go through the correct path.

 

Is there a way to mitigate this = attack?

 

[SD] Ok. This is an interesting attack. =  

 

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B i.e. = Path2 -  (1,2,3,6).

 

If the attacker could take values from = Path1 and reattach them to Path2 , = the reconstruction for PacketB would result in (1,3,5,6) = instead of (1,2,3,6). 

This could be compared with topology/policy db = information for any policy violations. POT does not enforce a particular = path to be taken.

 It just reconstructs the particular path = taken by the packets. 

 

Do you mean that there is a = one-second-vulnerability for replay attacks?

One second is practically = forever.

 

[SD] Not really , the verifier could cache the = RND-2 numbers used in the time slice of one second and flush off after = every second. There is no one-second-vulnerability as such, if the = verifier caches those values. 

 

Effective replay prevention is typically = performed using a sequence number, with a sliding window to allow = out-of-order packets. Wouldn’t it be possible to incorporate such = a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high level = sequence number (at seconds level)! The challenge with using complete = RND-2 as sequence number is that the differential analysis of CML values = (across packets) becomes very easy  and predictable.

that’s reason we recommend using  ( = Timestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com] =
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal = Mizrahi; Frank Brockners (fbrockne); draft-bro= ckners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: = Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. More = inline with [SD] .. 

 

 

Right, I am referring to the former. The = integrity check is not the issue.

Let’s say we have:

- Packet A that went through the correct path = and has a correct POT.

- Packet B that did not go through the = correct path and does not have a correct POT.

 

The attacker can ‘launder’ packet = B by replacing the (incorrect) POT of packet B with the correct POT of = packet A (and drop packet A).

Thus, packet B is verified correctly, even = though it did not go through the correct path.

=

 

[SD] This is valid scenario and we have certain = in-built mitigation techniques and recommendations for the = same. 

There are two scenarios here 

 

Partial Replay of POT data (Replaying = intermediate CMLs)

 

Attacker cannot reuse few intermediate = node’s POT values (from older packet traces) as it would disrupt = the POLY-3 construction. 

On the other hand if the attacker tries to = replay entire sequence of CML values, he cannot still , because notice = that verifier also has a secret share of RND-1 and participates in the = reconstruction of RND-3.

Verifier’s share of RND-3 is never on = wire , so attacker cannot just observe the packet traces to reuse and = replay it. 

 

Total Replay of POT data (Replaying complete = RND-2)

 

Another trick, attacker could do is by = completely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply = Attacks” , we recommend that the RND-2 (generated per packet) be a = combination (I.e. RND2 =3D “Time Stamp + RND = number”)

So in case a passive attacker tries to replay = one of the correct but older RND-2, the verifier first could check the = current timestamp against the timestamp retrieved from = RND-2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 

There is still a small window , where the = attacker could replay it within the valid time slice itself but by = carefully choosing the time slice we can make it nearly impossible for = the attacker to replay.

For example , if the Time Stamp chosen is 32 = bits , we could get one seconds level precision in the time window . So = it is highly impossible for the attacker to replay within such a small = time at such a high packet rates. 

 

Also , the verifier could cache, if needed, = certain number of previously used RND-2 to mitigate replay = attacks. 

 

Hope this clarifies. 

 

=
------=_NextPart_000_0241_01D1E25F.40DDE730-- From nobody Wed Jul 20 00:57: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 CD09312B037; Wed, 20 Jul 2016 00:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMHl-Kmmn75J; Wed, 20 Jul 2016 00:57:25 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC63712B004; Wed, 20 Jul 2016 00:57:25 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6K7sgaC027175; Wed, 20 Jul 2016 00:57:24 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 24a2c38mtk-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Jul 2016 00:57:23 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jul 2016 10:57:17 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Wed, 20 Jul 2016 10:57:17 +0300 From: Tal Mizrahi To: "Frank Brockners (fbrockne)" , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tCABdCDgIALm9VQ Date: Wed, 20 Jul 2016 07:57:16 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <99c4c8222952442f9a8c99713cbbbffe@XCH-RCD-008.cisco.com> In-Reply-To: <99c4c8222952442f9a8c99713cbbbffe@XCH-RCD-008.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: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_a5651eb92ae74a7dae50a22eb8919b7cILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_06:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200093 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 07:57:29 -0000 --_000_a5651eb92ae74a7dae50a22eb8919b7cILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank, >Hence, I'd like to come back to my question asked below: >Do you (and the entire SFC team here) think it is worthwhile to provide >a solution for a deployment which is expected to *not* alter the packet pa= yload? In a nutshell, YES. I don't think integrity protection is a requirement here. Path validation is the requirement that you guys have raised, and I believe= it is an important requirement. Integrity protection is a way to satisfy the requirement. Cheers, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Wednesday, July 20, 2016 9:16 AM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, well... if you could protect the integrity of the data stream between sourc= e and destination, you would not be able to swap the content of a packet - = which is what your attack is all about. Rather than continue arguing the po= int, let's acknowledge that it is a valid attack and let's look for a solut= ion :-). We'll need to couple POT to integrity protection of the packet. Hence, I'd like to come back to my question asked below: Do you (and the entire SFC team here) think it is worthwhile to provide a s= olution for a deployment which is expected to *not* alter the packet payloa= d? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 18:15 To: Frank Brockners (fbrockne) >; Sashank Dara (sadara) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Frank, The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_a5651eb92ae74a7dae50a22eb8919b7cILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Frank,

 <= /p>

>Hence, I’d like= to come back to my question asked below:  

>Do you (and the entir= e SFC team here) think it is worthwhile to provide

>a solution for a depl= oyment which is expected to *not* alter the packet payload?

 <= /p>

In a nutshell, YES.<= /o:p>

I don’t think integ= rity protection is a requirement here.

Path validation is the re= quirement that you guys have raised, and I believe it is an important requi= rement.

Integrity protection is a= way to satisfy the requirement.

 <= /p>

Cheers,=

Tal.

 <= /p>

 <= /p>

From: Frank Br= ockners (fbrockne) [mailto:fbrockne@cisco.com]
Sent: Wednesday, July 20, 2016 9:16 AM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-tra= nsit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,<= /o:p>

 

well... if you could prot= ect the integrity of the data stream between source and destination, you wo= uld not be able to swap the content of a packet – which is what your attack is all about. Rather than continue arguing the point, = let’s acknowledge that it is a valid attack and let’s look for = a solution :-). We’ll need to couple POT to integrity protection of t= he packet.

 <= /p>

Hence, I’d like to = come back to my question asked below:  

Do you (and the entire SF= C team here) think it is worthwhile to provide a solution for a deployment = which is expected to *not* alter the packet payload?

 <= /p>

Thanks, Frank<= /span>

 <= /p>

From: Tal Mi= zrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 18:15
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Sashank Dara (sadara) <sadara@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Frank,

 <= /p>

The POT replacement attac= k (1.) is not an attack on the integrity. It is an attack on the path verif= ication.

This simple attack can ca= use the verifier to accept a packet that did not go through the firewall SF= (even though it should). I believe this is exactly the problem you were aiming to address in this draft.

 <= /p>

Thanks,=

Tal.

 <= /p>

From: Frank Br= ockners (fbrockne) [mailto:fbrockne@c= isco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,<= /o:p>

 

thanks for the summary. W= e’ll provide more details on 2. Per my earlier point – 1. is an= interesting discussion, given that we don’t claim to provide integri= ty protection for the packet payload. Or in other terms – to be exact: = What POT provides is a proof that the POT-header/meta-data transited all th= e required nodes. There is no association (and thus proof) provided for the= additional data carried along with the POT-header – neither header nor payload. As a consequence, attacks w= hich change the packet payload won’t be detected/mitigated. We’= ll explicitly state this in the security considerations in the next rev of = the document.

What we could consider is= linking the RND number to CRC across the packet payload or similar –= but that way we’d restrict the applicability to deployments where the packet payload isn’t changed across the path (which might not ap= ply to certain deployment – e.g. WAN optimization / compression schem= es).

Do you think it is worthw= hile to provide a solution for a deployment which is expected to not alter = the packet payload?

 <= /p>

Thanks,=

Frank

 <= /p>

From: Tal Mi= zrahi [mailto:talmi@marvell.com]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,

 <= /p>

To summarize my take on t= his thread:

The proposed mechanism ha= s two significant vulnerabilities that (in my understanding) are currently = not addressed:

1. &n= bsp;     A man-in-the-middle can replace the POT o= f packet A with the POT of packet B.

2. &n= bsp;     It is possible to replay POTs within a ce= rtain time window, whose length is determined by the timestamp resolution.<= o:p>

 <= /p>

Sashank, thanks for agree= ing to look into it further. I am looking forward to your insights on this.=

 <= /p>

Regards,

Tal.

 <= /p>

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01

 <= /p>

 <= /p>

 

From: Sashank = Dara (sadara) [mailto:sadara@cisco.com<= /a>]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A (in= dicating the path through 1,3,5,6) to packet B, will the verifier accept pa= cket B and believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is pro= grammed to just validate the POT meta data against {1,3,5,6} then yes it ac= cepts it. 

If the verifier is programm= ed to consult a policy database to cross check if the reconstructed path {1= ,3,5,6} is as per the policies then no , it drops it . 

 

But I see your point , that= the parameters used in POT data donot consider the path or node-ids etc . = We shall discuss this internally and get back.

 

Also, We shall get back wit= h more concrete numbers of the timestamp resolution and cache sizes (or oth= er better approaches). 

 

Thank you so much for all t= he inputs. 

 

 

 

From: Tal Mizr= ahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,<= /span>

 <= /p>

I really appreciate the q= uick and detailed responses.

 <= /p>

>>>Lets take correct path taken = by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (e.g= . the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only = constructs the path the packet took accurately, it is upto

>the application to dete= rmine whether it violates any policies (I.e missing any function) 

>The bottom line is , an= attacker taking a different path cannot get away with it !

>The whole intent of = 220;proof-of-transit” is to prove the path packet has taken exactly.&= nbsp;

>POT does not define whe= ther it good/bad path. It is upto high level applications on what

>do with “reconstr= ucted” path. 

 <= /p>

 <= /p>

 <= /p>

I want to ask a simple qu= estion:

If the attacker attaches = the POT of packet A (indicating the path through 1,3,5,6) to packet B, will= the verifier accept packet B and believe that its path was indeed (1,3,5,6)?

 <= /p>

 <= /p>

>>Hmmm… Let’s say we = are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example, we could use = as much precision as we want to reduce the number of values to be cached !

 <= /p>

My point is that assuming= reasonable resources are used, the mechanism is vulnerable to a replay att= ack.

In order to prove me wron= g, can you present concrete numbers of the timestamp resolution and the cac= he size?

Otherwise, you may consid= er using a sequence number + sliding window (e.g., as in IPsec).

 <= /p>

 <= /p>

Thanks,=

Tal.

 <= /p>

 <= /p>

 <= /p>

 

 

 

 

>[SD] Ok. This is an interesting attac= k.  

> 

>Lets take correct path taken by Packe= t A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be Pack= et B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values fro= m Path1 and reattach them to Path2 ,

>the reconstruction for PacketB w= ould result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topology/= policy db information for any policy

>violations. POT does not enforce a pa= rticular path to be taken.

 

So packet B skipped node 5 (e.g. the fi= rewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only cons= tructs the path the packet took accurately, it is upto the application to d= etermine whether it violates any policies (I.e missing any function) 

The bottom line is , an att= acker taking a different path cannot get away with it ! The whole intent of= “proof-of-transit” is to prove the path packet has taken exactly. 

POT does not define whether= it good/bad path. It is upto high level applications on what do with ̶= 0;reconstructed” path. 

 

 

Hmmm… Let’s say we are talk= ing about traffic at 10 Gbps, which is roughly 1 million packets per second= . That would mean the verifier has to store a million values of RND-2.

Moreover, every time a packet arrives, = the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.

Am I missing something here?

 

[SD] Second level precision is only an example, we could use as m= uch precision as we want to reduce the number of values to be cached !

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 =

 

We have two consecutive packets, A and = B:

- Packet A that went through the correc= t path and has a correct POT.=

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 Now the attacker performs a ‘mix and= match’ attack, by taking the correct POT from packet A and attaching= it to packet B.

The attacker also terminates packet A.<= /span>

There is no replay here, because the ve= rifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the veri= fier, even though it did not go through the correct path.

 

Is there a way to mitigate this attack?=

 =

[SD] Ok. This is an interesting attack. &= nbsp;

 =

Lets take correct path taken by Packet A =  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packet B= i.e. Path2 -  (1,2,3,6).

 =

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/poli= cy db information for any policy violations. POT does not enforce a particular path to be taken.<= o:p>

 It just reconstructs the particular= path taken by the packets. 

 =

Do you mean that there is a one-second-= vulnerability for replay attacks?

One second is practically forever.

 =

[SD] Not really , the verifier could cach= e the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerability as such= , if the verifier caches those values. 

 =

Effective replay prevention is typicall= y performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to incorporat= e such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high le= vel sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential analysis = of CML values (across packets) becomes very easy  and predictable.

that’s reason we recommend using &n= bsp;( Timestamp(/ sequence number) + RND )

 

 =

 =

 

From: Sashank Dara (sadara) [mailto:sadara@cisco.com= ]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our work. = More inline with [SD] .. 

 =

 =

Right, I am referring to the former. The integri= ty check is not the issue.

Let’s say we have:

- Packet A that went through the correct path an= d has a correct POT.

- Packet B that did not go through the correct p= ath and does not have a correct POT.

 

The attacker can ‘launder’ packet B = by replacing the (incorrect) POT of packet B with the correct POT of packet= A (and drop packet A).

Thus, packet B is verified correctly, even thoug= h it did not go through the correct path.

 =

[SD] This is valid scenario and we have c= ertain in-built mitigation techniques and recommendations for the same. 

There are two scenarios here =

 =

Partial Replay of POT data (Replaying = intermediate CMLs)=

 =

Attacker cannot reuse few intermediate no= de’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker tries t= o replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and particip= ates in the reconstruction of RND-3.

Verifier’s share of RND-3 is never = on wire , so attacker cannot just observe the packet traces to reuse and replay it. <= /p>

 =

Total Replay of POT data (Replaying co= mplete RND-2)

 =

Another trick, attacker could do is by co= mpletely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply Atta= cks” , we recommend that the RND-2 (generated per packet) be a combin= ation (I.e. RND2 =3D “Time Stamp + RND number”)

So in case a passive attacker tries to re= play one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved from RND= -2.

If the retrieved timestamp is older than = current timestamp we drop/raise a flag ! 

 =

There is still a small window , where the= attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearly impossible = for the attacker to replay.

For example , if the Time Stamp chosen is= 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay within= such a small time at such a high packet rates. 

 =

Also , the verifier could cache, if neede= d, certain number of previously used RND-2 to mitigate replay attacks. 

 =

Hope this clarifies. 

 =

--_000_a5651eb92ae74a7dae50a22eb8919b7cILEXCH02marvellcom_-- From nobody Wed Jul 20 01:51: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 A9F9912D0B3; Wed, 20 Jul 2016 01:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 Z9kGBjnBqAga; Wed, 20 Jul 2016 01:51:25 -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 9AC7512B037; Wed, 20 Jul 2016 01:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=113484; q=dns/txt; s=iport; t=1469004684; x=1470214284; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l/y7QEksu2ihLw7Z24rMk1gD2sRIl0bRrHG+Giw0LrM=; b=ZDHRugNlgHtpuUOKzPACCHzEs/5EpfLGjwR0AXRdS0PbD3d0qzIjP/IB T7Lh8crTm6LEKwHU/BzP6Pbf6tDMUoTj76J2K755YI7Us7/B/jYs/fa1U fvcXRFJsJ+fZW7twTVqHkeC/NkFjyo07Fqexzbp5psvpwYMKrqr0tNUrN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAZOo9X/4wNJK1dgnFOVnwGuGmBe?= =?us-ascii?q?iKFeAKBNTgUAQEBAQEBAWUnhFwBAQQBGgESOhIFCwIBCBEEAQEhAQYHMhQJCAI?= =?us-ascii?q?EAQ0FCBMEiAkIDr1DAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhHaFJQWII?= =?us-ascii?q?otChUIBhhKCe4JzglqCCY02kB8BHjaCCxyBTG6GLisYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208,217";a="126052198" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 08:51:21 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6K8pLxB023251 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 08:51:21 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; Wed, 20 Jul 2016 03:51:20 -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; Wed, 20 Jul 2016 03:51:20 -0500 From: "Frank Brockners (fbrockne)" To: "adrian@olddog.co.uk" , "'Tal Mizrahi'" , "Sashank Dara (sadara)" , "draft-brockners-proof-of-transit@tools.ietf.org" Thread-Topic: [OPSAWG] Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tD/+pFIAIAAkjGA//9h6wCAADtH4A== Date: Wed, 20 Jul 2016 08:51:20 +0000 Message-ID: <91f263bf66d642549f7cd807cfff0cdd@XCH-RCD-008.cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <023a01d1e256$df024db0$9d06e910$@olddog.co.uk> In-Reply-To: <023a01d1e256$df024db0$9d06e910$@olddog.co.uk> Accept-Language: de-DE, 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.244.97] Content-Type: multipart/alternative; boundary="_000_91f263bf66d642549f7cd807cfff0cddXCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [OPSAWG] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 08:51:31 -0000 --_000_91f263bf66d642549f7cd807cfff0cddXCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, Thanks - very helpful comments. Point well taken on the fact that POT using= SSS is to verify that a specific set of nodes has been traversed - not all= nodes, nor in a specific order. We'll definitively provide clearer and cle= aner language in the next revision. We'll also extend the draft with another approach (based on nested crypto) = which would be order preserving, at the expense to be computationally more= intense. Also per your note, we'll also expand on the role of the verifier in the ne= xt revision. Frank From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Mittwoch, 20. Juli 2016 09:18 To: 'Tal Mizrahi' ; Sashank Dara (sadara) ; Frank Brockners (fbrockne) ; draft-brockners-proo= f-of-transit@tools.ietf.org Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org Subject: RE: [OPSAWG] Question regarding Proof of Transit draft What is worrying me in this conversations is the discrepancy between the st= ated aim in draft-brockners-proof-of-transit and the function provided by t= he draft. I'm not (at the moment ;-) picking hols in what the S**3 scheme a= chieves, but I am questioning whether it provides enough to be useful in th= e context stated. So draft-brockners-proof-of-transit says... > This document defines mechanisms to > securely prove that traffic transited the defined path. and > In certain cases regulatory > obligations or a compliance policy require operators to prove that > all packets that are supposed to follow a specific path are indeed > being forwarded across and exact set of pre-determined nodes. Shamir as applied in this document does not meet those criteria. It only sh= ows that all members of a defined set of nodes were traversed at some point= along the path. It neither guarantees ordering, nor does it protect agains= t the insertion of additional nodes on the path. Other parts of the document are more clear about exactly this point. it is = not clear to me, therefore, whether the intention is misstated in the text = I quoted, or whether the proposed solution (while good at what it does) is = inadequate for the purpose. BTW, think it is not clear in the text that the order of the polynomial mu= st count the verifying node. I.e., the verifying node must also insert a po= int on the curve. This is needed because otherwise the full set of points i= s included in a message on the wire and the polynomial becomes vulnerable. Thanks, Adrian From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: 20 July 2016 05:30 To: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proo= f-of-transit@tools.ietf.org Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org Subject: Re: [OPSAWG] Question regarding Proof of Transit draft Hi Sashank, >[SD] The attack is valid only if the attacker can get away bypassing a ser= vice function/node. >For example, if the attacker bypasses a node and if POT determines it did = not bypass is a valid attack on the system. I would phrase it this way: *Given* a packet that did not go through its de= sired path, the attacker can easily make you think that it *did* go through= the desired path. Sounds like a very significant vulnerability. If a packet did not go through the firewall (for one reason or another), th= e attacker will make you think that it did go through the firewall. Cheers, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Wednesday, July 20, 2016 4:31 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: Re: Question regarding Proof of Transit draft The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. [SD] The attack is valid only if the attacker can get away bypassing a serv= ice function/node. For example, if the attacker bypasses a node and if POT determines it did n= ot bypass is a valid attack on the system. In the current state, there is no way an attacker can get away as we determ= ine the exact path the packet travelled (aim of the draft) . I reiterate that the verifier needs to handle what to do with the path reco= nstructed ! We could emphasize this in our next draft , but it would be beyond scope of= POT to determine what to do with the path constructed. IMO, It would be highly application specific. Regards, Sashank Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We'll provide more details on 2. Per my earlier poi= nt - 1. is an interesting discussion, given that we don't claim to provide = integrity protection for the packet payload. Or in other terms - to be exac= t: What POT provides is a proof that the POT-header/meta-data transited all= the required nodes. There is no association (and thus proof) provided for = the additional data carried along with the POT-header - neither header nor = payload. As a consequence, attacks which change the packet payload won't be= detected/mitigated. We'll explicitly state this in the security considerat= ions in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar - but that way we'd restrict the applicability to deploym= ents where the packet payload isn't changed across the path (which might no= t apply to certain deployment - e.g. WAN optimization / compression schemes= ). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of "proof-of-transit" is to prove the path packet has tak= en exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with "reconstructed" path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm... Let's say we are talking about traffic at 10 Gbps, which is rough= ly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of "proof-of-transit" is to prove the path packet = has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with "reconstructed" path. Hmmm... Let's say we are talking about traffic at 10 Gbps, which is roughly= 1 million packets per second. That would mean the verifier has to store a = million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a 'mix and match' attack, by taking the correct = POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn't it be possib= le to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that's reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let's say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can 'launder' packet B by replacing the (incorrect) POT of pac= ket B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node's POT values (from older packet= traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier's share of RND-3 is never on wire , so attacker cannot just observ= e the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the "Reply Attacks" , we recommend that the RND-2 (gene= rated per packet) be a combination (I.e. RND2 =3D "Time Stamp + RND number"= ) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. --_000_91f263bf66d642549f7cd807cfff0cddXCHRCD008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adrian,

 = ;

Thanks – very helpful comments. Point well taken on the fact tha= t POT using SSS is to verify that a specific set of nodes has been traversed – not all nodes, nor in a specific order. We̵= 7;ll definitively provide clearer and cleaner language in the next revision= .

We’ll also extend the draft with another approach (based on nest= ed crypto) which would be order preserving, at the expense to be  computationally more intense.

Also per your note, we’ll also expand on the role of the verifie= r in the next revision.

 

Frank

 

From: = Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Mittwoch, 20. Juli 2016 09:18
To: 'Tal Mizrahi' <talmi@marvell.com>; Sashank Dara (sadara) &= lt;sadara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com&= gt;; draft-brockners-proof-of-transit@tools.ietf.org
Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org
Subject: RE: [OPSAWG] Question regarding Proof of Transit draft=

 

What is worrying me in= this conversations is the discrepancy between the stated aim in draft-broc= kners-proof-of-transit and the function provided by the draft. I'm not (at the moment ;-) picking hols in what the S**3 sch= eme achieves, but I am questioning whether it provides enough to be useful = in the context stated.

 

So draft-brockners-pro= of-of-transit says...

 

> This document def= ines mechanisms to

> securely prove th= at traffic transited the defined path.

 

and

 

>  In certain = cases regulatory

>  obligations= or a compliance policy require operators to prove that

>  all packets= that are supposed to follow a specific path are indeed

>  being forwa= rded across and exact set of pre-determined nodes.

 

Shamir as applied in t= his document does not meet those criteria. It only shows that all members o= f a defined set of nodes were traversed at some point along the path. It neither guarantees ordering, nor does it protect = against the insertion of additional nodes on the path.

 

Other parts of the doc= ument are more clear about exactly this point. it is not clear to me, there= fore, whether the intention is misstated in the text I quoted, or whether the proposed solution (while good at what it doe= s) is inadequate for the purpose.

 

BTW,  think it is= not clear in the text that the order of the polynomial must count the veri= fying node. I.e., the verifying node must also insert a point on the curve. This is needed because otherwise the full set of poi= nts is included in a message on the wire and the polynomial becomes vulnera= ble.

 

Thanks,

Adrian

 

From: OP= SAWG [mailto:opsawg-bounces@ietf= .org] On Behalf Of Tal Mizrahi
Sent: 20 July 2016 05:30
To: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org
Cc: opsawg@ietf.org; nvo3@ietf.org; sfc@ietf.org
Subject: Re: [OPSAWG] Question regarding Proof of Transit draft=

 

Hi Sashank,=

 

>[SD] The attack is v= alid only if the attacker can get away bypassing a service function/node.&n= bsp;

>For example, if the = attacker bypasses a node and if POT determines it did not bypass is a valid= attack on the system.

 

I would phrase it this= way: *Given* a packet that did not go through its desired path, the= attacker can easily make you think that it *did* go through the desired path.

Sounds like a very sig= nificant vulnerability.

 

If a packet did not go= through the firewall (for one reason or another), the attacker will make y= ou think that it did go through the firewall.

 

Cheers,

Tal.=

 

 

From: Sa= shank Dara (sadara) [mailto:sadara@cisc= o.com]
Sent: Wednesday, July 20, 2016 4:31 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 =

 =

The POT replacement attack (1.) is n= ot an attack on the integrity. It is an attack on the path verification.

This simple attack can cause the ver= ifier to accept a packet that did not go through the firewall SF (even though it should). I believe this is exactly the problem= you were aiming to address in this draft.

 =

[SD] The attack is valid= only if the attacker can get away bypassing a service function/node. =

For example, if the atta= cker bypasses a node and if POT determines it did not bypass is a valid att= ack on the system.

 =

In the current state, th= ere is no way an attacker can get away as we determine the exact path the p= acket travelled (aim of the draft) . 

I reiterate that the ver= ifier needs to handle what to do with the path reconstructed !

We could emphasize this = in our next draft , but it would be beyond scope of POT to determine what t= o do with the path constructed. 

IMO, It would be highly = application specific. 

 =

 =

Regards,

Sashank

 =

 =

 

Thanks,

Tal.

 

From: Frank Brockners (fbrockne) [mailto:f= brockne@cisco.com]
Sent: Tuesday, July 19, 2016 6:00 PM
To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi Tal,

 

thanks for the summary. We’ll = provide more details on 2. Per my earlier point – 1. is an interesting discussion, given that we don’t claim to provide inte= grity protection for the packet payload. Or in other terms – to be ex= act: What POT provides is a proof that the POT-header/meta-data transited a= ll the required nodes. There is no association (and thus proof) provided for the additional data carried along with the P= OT-header – neither header nor payload. As a consequence, attacks whi= ch change the packet payload won’t be detected/mitigated. We’ll= explicitly state this in the security considerations in the next rev of the document.

What we could consider is linking th= e RND number to CRC across the packet payload or similar – but that way we’d restrict the applicability to deployments = where the packet payload isn’t changed across the path (which might n= ot apply to certain deployment – e.g. WAN optimization / compression = schemes).

Do you think it is worthwhile to pro= vide a solution for a deployment which is expected to not alter the packet payload?

 

Thanks,

Frank

 

From: Tal Mizrahi [mailto:talmi@marvell.com= ]
Sent: Dienstag, 19. Juli 2016 17:44
To: Sashank Dara (sadara) <sa= dara@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; draft-br= ockners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Hi,

 

To summarize my take on this thread:=

The proposed mechanism has two signi= ficant vulnerabilities that (in my understanding) are currently not addressed:

1.   &nbs= p;   A man-in-the-middle can replace the PO= T of packet A with the POT of packet B.<= o:p>

2.   &nbs= p;   It is possible to replay POTs within a= certain time window, whose length is determined by the timestamp resolutio= n.

 

Sashank, thanks for agreeing to look= into it further. I am looking forward to your insights on this.

 

Regards,

Tal.

 

Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-transit-01=

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 12:20 PM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of packet A = (indicating the path through 1,3,5,6) to packet B, will the verifier accept= packet B and believe that its path was indeed (1,3,5,6)?

 

[SD] If the verifier is programmed to = just validate the POT meta data against {1,3,5,6} then yes it accepts it. 

If the verifier is programmed to consu= lt a policy database to cross check if the reconstructed path {1,3,5,6} is as per the policies then no , it drops it . =

 

But I see your point , that the parame= ters used in POT data donot consider the path or node-ids etc . We shall discuss this internally and get back.

 

Also, We shall get back with more conc= rete numbers of the timestamp resolution and cache sizes (or other better approaches). 

 

Thank you so much for all the inputs.&= nbsp;

 

 

 

From: Tal Mizrahi
Sent: Tuesday, July 19, 2016 10:28 AM
To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft

 

Dear Sashank,

 

I really appreciate the quick and de= tailed responses.

 

>>>Lets take correct path tak= en by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 - &= nbsp;(1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattac= h them to Path2 ,
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy
>>>violations. POT does not enforce a particular path to be taken.=

>>So packet B skipped node 5 (= e.g. the firewall SF), but the verifier believes it went through the correct path.
>>Would you agree?

>[SD] The verifier only constructs = the path the packet took accurately, it is upto

>the application to determine wheth= er it violates any policies (I.e missing any function) 

>The bottom line is , an attacker t= aking a different path cannot get away with it !

>The whole intent of “proof-o= f-transit” is to prove the path packet has taken exactly. 

>POT does not define whether it goo= d/bad path. It is upto high level applications on what

>do with “reconstructed”= ; path. <= /span>

 

 

 

I want to ask a simple question:

If the attacker attaches the POT of = packet A (indicating the path through 1,3,5,6) to packet B, will the verifier accept packet B and believe that its path was = indeed (1,3,5,6)?

 

 

>>Hmmm… Let’s say = we are talking about traffic at 10 Gbps, which is roughly
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?

>[SD] Second level precision is only an example= , we could use as much precision as we want to reduce the number of values to be cached !

 

My point is that assuming reasonable= resources are used, the mechanism is vulnerable to a replay attack.

In order to prove me wrong, can you = present concrete numbers of the timestamp resolution and the cache size?=

Otherwise, you may consider using a = sequence number + sliding window (e.g., as in IPsec).

 

 

Thanks,

Tal.

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 9:56 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

 

 

 

>[SD] Ok. This is an interesting at= tack.  

> 

>Lets take correct path taken by Pa= cket A  to be Path1 - ( 1,3,5,6) nodes. 

>Lets assume incorrect path to be P= acket B i.e. Path2 -  (1,2,3,6).

> 

>If the attacker could take values = from Path1 and reattach them to Path2 ,

>the reconstruction for Packet= B would result in (1,3,5,6) instead of (1,2,3,6). 

>This could be compared with topolo= gy/policy db information for any policy

>violations. POT does not enforce a= particular path to be taken.

 

So packet B skipped node 5 (e.g. the= firewall SF), but the verifier believes it went through the correct path.

Would you agree?

 

[SD] The verifier only constructs the = path the packet took accurately, it is upto the application to determine whether it violates any policies (I.e missing any function)&n= bsp;

The bottom line is , an attacker takin= g a different path cannot get away with it ! The whole intent of “proof-of-transit” is to prove the path packet has t= aken exactly. <= /o:p>

POT does not define whether it good/ba= d path. It is upto high level applications on what do with “reconstructed” path. 

 

 

Hmmm… Let’s say we are t= alking about traffic at 10 Gbps, which is roughly 1 million packets per second. That would mean the verifier has to store a million values of = RND-2.<= /p>

Moreover, every time a packet arrive= s, the verifier would have to compare its RND-2 value with the 1 million stored values, in order to verify there is no replay.

That does not sound feasible.=

Am I missing something here?<= span lang=3D"EN-US" style=3D"color:black">

 

[SD] Second level precision is only an example, we= could use as much precision as we want to reduce the number of values to be cached !=

 

 

Sashank 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 8:33 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Inline .. 

 

 

We have two consecutive packets, A a= nd B:

- Packet A that went through the cor= rect path and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 Now the attacker performs a ‘mix = and match’ attack, by taking the correct POT from packet A and attach= ing it to packet B.<= /o:p>

The attacker also terminates packet = A.

There is no replay here, because the= verifier receives the correct POT only once. The problem is that the correct POT happens to arrive with packet B. L

Thus, packet B appears okay to the v= erifier, even though it did not go through the correct path.<= /p>

 

Is there a way to mitigate this atta= ck?

 

[SD] Ok. This is an interesting attack= .  

 

Lets take correct path taken by Packet= A  to be Path1 - ( 1,3,5,6) nodes. 

Lets assume incorrect path to be Packe= t B i.e. Path2 -  (1,2,3,6).

 

If the attacker could take values from Path1 and reattach them to Path2 , the reconstructi= on for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =

This could be compared with topology/p= olicy db information for any policy violations. POT does not enforce a particular path to be taken.

 It just reconstructs the particu= lar path taken by the packets. 

 

Do you mean that there is a one-seco= nd-vulnerability for replay attacks?

One second is practically forever.

 

[SD] Not really , the verifier could c= ache the RND-2 numbers used in the time slice of one second and flush off after every second. There is no one-second-vulnerabil= ity as such, if the verifier caches those values. 

 

Effective replay prevention is typic= ally performed using a sequence number, with a sliding window to allow out-of-order packets. Wouldn’t it be possible to inc= orporate such a sequence number into your mechanism?

 

[SD] Time stamp is essentially at high= level sequence number (at seconds level)! The challenge with using complete RND-2 as sequence number is that the differential anal= ysis of CML values (across packets) becomes very easy  and predictable= .

that’s reason we recommend using=  ( Timestamp(/ sequence number) + RND )

 

 

 

 

From: Sashank Dara (sadara) [mailto:sadara@c= isco.com]
Sent: Tuesday, July 19, 2016 1:11 AM
To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft

 

Dear Tal,

Thank you for your interest in our wor= k. More inline with [SD] .. 

 

 

Right, I am referring to the former. The inte= grity check is not the issue.

Let’s say we have:

- Packet A that went through the correct path= and has a correct POT.

- Packet B that did not go through the correc= t path and does not have a correct POT.

 

The attacker can ‘launder’ packet= B by replacing the (incorrect) POT of packet B with the correct POT of pac= ket A (and drop packet A).

Thus, packet B is verified correctly, even th= ough it did not go through the correct path.

 

[SD] This is valid scenario and we hav= e certain in-built mitigation techniques and recommendations for the same. =

There are two scenarios here 

 

Partial Replay of POT data (Replayi= ng intermediate CMLs)=

 

Attacker cannot reuse few intermediate= node’s POT values (from older packet traces) as it would disrupt the POLY-3 construction. 

On the other hand if the attacker trie= s to replay entire sequence of CML values, he cannot still , because notice that verifier also has a secret share of RND-1 and = participates in the reconstruction of RND-3.

Verifier’s share of RND-3 is nev= er on wire , so attacker cannot just observe the packet traces to reuse and replay it. 

 

Total Replay of POT data (Replaying= complete RND-2)=

 

Another trick, attacker could do is by= completely reusing RND-2 (but not intermediate CML values)

In order to prevent the “Reply A= ttacks” , we recommend that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D “Time Stamp + RND number”)=

So in case a passive attacker tries to= replay one of the correct but older RND-2, the verifier first could check the current timestamp against the timestamp retrieved fr= om RND-2.

If the retrieved timestamp is older th= an current timestamp we drop/raise a flag ! 

 

There is still a small window , where = the attacker could replay it within the valid time slice itself but by carefully choosing the time slice we can make it nearl= y impossible for the attacker to replay.

For example , if the Time Stamp chosen= is 32 bits , we could get one seconds level precision in the time window . So it is highly impossible for the attacker to replay= within such a small time at such a high packet rates. 

 

Also , the verifier could cache, if ne= eded, certain number of previously used RND-2 to mitigate replay attacks. 

 

Hope this clarifies. 

 

--_000_91f263bf66d642549f7cd807cfff0cddXCHRCD008ciscocom_-- From nobody Wed Jul 20 02:33: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 AF4DB12D158; Wed, 20 Jul 2016 02:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 V3S6pxFNVG8P; Wed, 20 Jul 2016 02:33:50 -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 561A0128E18; Wed, 20 Jul 2016 02:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10384; q=dns/txt; s=iport; t=1469007230; x=1470216830; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=74pm+5UAmFrpITJN0mgC/xESTibWDLfiEurYewAL6h4=; b=ilzRODtLoFfoKFik9jvwI7EA5fzs0edzc1iPKG4ZCge4iOcpoH1XUPl0 4PJ+k/MtAIDz39ZfoSOrMTiu1UEO7Od3x1T66tw+X6YvC2/dV9B3YZd3K XmYeHe+kAPW9ClbasJhW0R0cBrjpnOdM5ukok5F5U0XDp9g6e/mCtIUed 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgDhRI9X/4gNJK1dgz9WfAa4aoF6I?= =?us-ascii?q?oV4AhyBEjgUAQEBAQEBAWUnhFwBAQQBIxEzEgULAgEZBAEBAQICIwMCAgIwFAE?= =?us-ascii?q?ICAIEDgUbiA0IDq9YjXIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhSmBeIcsg?= =?us-ascii?q?morgi8FmSYBhhKIT485kB8BHjaCCxyBTG6GLisYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="300034161" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 09:33:49 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6K9Xmvs028246 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 09:33:49 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 05:33:47 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 05:33:46 -0400 From: "Carlos Pignataro (cpignata)" To: Tal Mizrahi Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnQWhCKL97OnUKNXabFF15a7g== Date: Wed, 20 Jul 2016 09:33:46 +0000 Message-ID: <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.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.61.88.191] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: [sfc] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 09:33:53 -0000 VGFsLA0KDQo+IE9uIEp1bCAyMCwgMjAxNiwgYXQgNjozMCBBTSwgVGFsIE1penJhaGkgPHRhbG1p QG1hcnZlbGwuY29tPiB3cm90ZToNCj4gDQo+IEhpIFNhc2hhbmssDQo+IA0KPj4gW1NEXSBUaGUg YXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhlIGF0dGFja2VyIGNhbiBnZXQgYXdheSBieXBhc3Np bmcgYSBzZXJ2aWNlIGZ1bmN0aW9uL25vZGUuDQo+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFj a2VyIGJ5cGFzc2VzIGEgbm9kZSBhbmQgaWYgUE9UIGRldGVybWluZXMgaXQgZGlkIG5vdCBieXBh c3MgaXMgYSB2YWxpZCBhdHRhY2sgb24gdGhlIHN5c3RlbS4NCj4gDQo+IEkgd291bGQgcGhyYXNl IGl0IHRoaXMgd2F5OiAqR2l2ZW4qIGEgcGFja2V0IHRoYXQgZGlkIG5vdCBnbyB0aHJvdWdoIGl0 cyBkZXNpcmVkIHBhdGgsIHRoZSBhdHRhY2tlciBjYW4gZWFzaWx5IG1ha2UgeW91IHRoaW5rIHRo YXQgaXQgKmRpZCogZ28gdGhyb3VnaCB0aGUgZGVzaXJlZCBwYXRoLg0KPiBTb3VuZHMgbGlrZSBh IHZlcnkgc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0eS4NCj4gDQo+IElmIGEgcGFja2V0IGRpZCBu b3QgZ28gdGhyb3VnaCB0aGUgZmlyZXdhbGwgKGZvciBvbmUgcmVhc29uIG9yIGFub3RoZXIpLCB0 aGUgYXR0YWNrZXIgd2lsbCBtYWtlIHlvdSB0aGluayB0aGF0IGl0IGRpZCBnbyB0aHJvdWdoIHRo ZSBmaXJld2FsbC4NCj4gDQoNCkxldOKAmXMgc3RlcCBiYWNrIGEgbGl0dGxlIOKAlCB0aGUg4oCc dnVsbmVyYWJpbGl0eeKAnSB5b3UgYXJlIGRlc2NyaWJpbmcgY29tZXMgd2l0aCB0aGUgYXNzdW1w dGlvbiB0aGF0IGEgTUlJVCBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IGEgcGFja2V0LCBleHRyYWN0 IGEgVExWIGZyb20gdGhlIE1EIFR5cGUgMiwgZHJvcCB0aGUgcGFja2V0OyB0aGVuIGludGVyY2Vw dCBhbm90aGVyIHBhY2tldCAod2l0aCB0aGUga25vd2xlZGdlIHRoYXQgaXQgdG9vayBhIGRpZmZl cmVudCBwYXRoLCBzbyBtYXliZSB0aGUgYXR0YWNrZXIgaXMgdXNpbmcgaW5iYW5kIE9BTSBhcyB3 ZWxsIDotKSwgYW5kIGluc2VydCAob3IgbW9kaWZ5KSBhIFRMViB3aXRoaW4gdGhlIGNvbnRlbnQg b2YgdGhlIE1EIFR5cGUgMiB3aXRoaW4gdGhlIGNvbnRlbnQgb2YgTlNILCB3aXRoaW4gYSBzcGVj aWZpYyBwYWNrZXQuDQoNClRoaXMgc291bmRzIHF1aXRlIHNvcGhpc3RpY2F0ZWQuDQoNCkRvIHlv dSB0aGluayB0aGF0IGlmIGFuIE1JSVQgY2FuIGhhdmUgdGhhdCBzdXJmYWNlIG9mIGF0dGFjayBh bmQgc29waGlzdGljYXRpb24sIHRoZXkgY2FuIG1lc3MgdXAgd2l0aCBvdGhlciBldmVuIG1vcmUg Y3JpdGljYWwgdGhpbmdzPyBDaGFuZ2luZyBhIFRlbmFudCBJRCwgbWVzc2luZyB1cCB3aXRoIFBv bGljeSBHcm91cHMsIGV0Yz8gDQoNCk15IHBvaW50IGlzIHRoYXQgd2hhdCB5b3Ugc2VlbSB0byBi ZSBkZXNjcmliaW5nIGlzIGEgZ2VuZXJpYyB0aHJlYXQgdXNlIGNhc2UgYW5kIG5vdCBhIHNwZWNp ZmljIHZ1bG5lcmFiaWxpdHkuIEVuZ2luZWVyaW5nIGlzIGFib3V0IHRyYWRlLW9mZnMgKGkuZS4s IHNvbHV0aW9ucyB0aGF0IGhhdmUgcHJhY3RpY2FsIHBlcmZvcm1hbmNlKSBhbmQgYWJvdXQgcGxh Y2luZyB0aGUgc29sdXRpb24gaW4gdGhlIG1vc3QgZWZmZWN0aXZlIHBsYWNlLg0KDQpJ4oCZbSBu b3QgZGVmbGVjdGluZyBidXQgYXQgdGhlIHNhbWUgdGltZSwgbGV04oCZcyB1bmRlcnN0YW5kIHRo ZSBhc3N1bXB0aW9ucyB5b3UgYXJlIG1ha2luZyBmb3IgdGhpcyBwb3RlbnRpYWwgYXR0YWNrIHlv dSBkZXNjcmliZSwgYXMgcGFydCBvZiB0aGUgdGhyZWF0IGFuYWx5c2lzLg0KDQpUaGFua3MsDQoN CuKAlCBDYXJsb3MuDQoNCj4gQ2hlZXJzLA0KPiBUYWwuDQo+IA0KPiANCj4gRnJvbTogU2FzaGFu ayBEYXJhIChzYWRhcmEpIFttYWlsdG86c2FkYXJhQGNpc2NvLmNvbV0NCj4gU2VudDogV2VkbmVz ZGF5LCBKdWx5IDIwLCAyMDE2IDQ6MzEgQU0NCj4gVG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9j a25lcnMgKGZicm9ja25lKTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMu aWV0Zi5vcmcNCj4gQ2M6IHNmY0BpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnOyBudm8zQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBk cmFmdA0KPiANCj4gDQo+IA0KPiBUaGUgUE9UIHJlcGxhY2VtZW50IGF0dGFjayAoMS4pIGlzIG5v dCBhbiBhdHRhY2sgb24gdGhlIGludGVncml0eS4gSXQgaXMgYW4gYXR0YWNrIG9uIHRoZSBwYXRo IHZlcmlmaWNhdGlvbi4NCj4gVGhpcyBzaW1wbGUgYXR0YWNrIGNhbiBjYXVzZSB0aGUgdmVyaWZp ZXIgdG8gYWNjZXB0IGEgcGFja2V0IHRoYXQgZGlkIG5vdCBnbyB0aHJvdWdoIHRoZSBmaXJld2Fs bCBTRiAoZXZlbiB0aG91Z2ggaXQgc2hvdWxkKS4gSSBiZWxpZXZlIHRoaXMgaXMgZXhhY3RseSB0 aGUgcHJvYmxlbSB5b3Ugd2VyZSBhaW1pbmcgdG8gYWRkcmVzcyBpbiB0aGlzIGRyYWZ0Lg0KPiAN Cj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhlIGF0dGFja2VyIGNhbiBnZXQg YXdheSBieXBhc3NpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uL25vZGUuDQo+IEZvciBleGFtcGxlLCBp ZiB0aGUgYXR0YWNrZXIgYnlwYXNzZXMgYSBub2RlIGFuZCBpZiBQT1QgZGV0ZXJtaW5lcyBpdCBk aWQgbm90IGJ5cGFzcyBpcyBhIHZhbGlkIGF0dGFjayBvbiB0aGUgc3lzdGVtLg0KPiANCj4gSW4g dGhlIGN1cnJlbnQgc3RhdGUsIHRoZXJlIGlzIG5vIHdheSBhbiBhdHRhY2tlciBjYW4gZ2V0IGF3 YXkgYXMgd2UgZGV0ZXJtaW5lIHRoZSBleGFjdCBwYXRoIHRoZSBwYWNrZXQgdHJhdmVsbGVkIChh aW0gb2YgdGhlIGRyYWZ0KSAuDQo+IEkgcmVpdGVyYXRlIHRoYXQgdGhlIHZlcmlmaWVyIG5lZWRz IHRvIGhhbmRsZSB3aGF0IHRvIGRvIHdpdGggdGhlIHBhdGggcmVjb25zdHJ1Y3RlZCAhDQo+IFdl IGNvdWxkIGVtcGhhc2l6ZSB0aGlzIGluIG91ciBuZXh0IGRyYWZ0ICwgYnV0IGl0IHdvdWxkIGJl IGJleW9uZCBzY29wZSBvZiBQT1QgdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8gd2l0aCB0aGUgcGF0 aCBjb25zdHJ1Y3RlZC4NCj4gSU1PLCBJdCB3b3VsZCBiZSBoaWdobHkgYXBwbGljYXRpb24gc3Bl Y2lmaWMuDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gU2FzaGFuaw0KPiANCj4gDQo+IA0KPiBUaGFu a3MsDQo+IFRhbC4NCj4gDQo+IEZyb206IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIFttYWls dG86ZmJyb2NrbmVAY2lzY28uY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDY6 MDAgUE0NCj4gVG86IFRhbCBNaXpyYWhpOyBTYXNoYW5rIERhcmEgKHNhZGFyYSk7IGRyYWZ0LWJy b2NrbmVycy1wcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9j a25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZz4NCj4gQ2M6IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0 Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPiBTdWJqZWN0OiBS RTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4gDQo+IEhpIFRh bCwNCj4gDQo+IHRoYW5rcyBmb3IgdGhlIHN1bW1hcnkuIFdlJ2xsIHByb3ZpZGUgbW9yZSBkZXRh aWxzIG9uIDIuIFBlciBteSBlYXJsaWVyIHBvaW50IC0gMS4gaXMgYW4gaW50ZXJlc3RpbmcgZGlz Y3Vzc2lvbiwgZ2l2ZW4gdGhhdCB3ZSBkb24ndCBjbGFpbSB0byBwcm92aWRlIGludGVncml0eSBw cm90ZWN0aW9uIGZvciB0aGUgcGFja2V0IHBheWxvYWQuIE9yIGluIG90aGVyIHRlcm1zIC0gdG8g YmUgZXhhY3Q6IFdoYXQgUE9UIHByb3ZpZGVzIGlzIGEgcHJvb2YgdGhhdCB0aGUgUE9ULWhlYWRl ci9tZXRhLWRhdGEgdHJhbnNpdGVkIGFsbCB0aGUgcmVxdWlyZWQgbm9kZXMuIFRoZXJlIGlzIG5v IGFzc29jaWF0aW9uIChhbmQgdGh1cyBwcm9vZikgcHJvdmlkZWQgZm9yIHRoZSBhZGRpdGlvbmFs IGRhdGEgY2FycmllZCBhbG9uZyB3aXRoIHRoZSBQT1QtaGVhZGVyIC0gbmVpdGhlciBoZWFkZXIg bm9yIHBheWxvYWQuIEFzIGEgY29uc2VxdWVuY2UsIGF0dGFja3Mgd2hpY2ggY2hhbmdlIHRoZSBw YWNrZXQgcGF5bG9hZCB3b24ndCBiZSBkZXRlY3RlZC9taXRpZ2F0ZWQuIFdlJ2xsIGV4cGxpY2l0 bHkgc3RhdGUgdGhpcyBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdGhlIG5leHQg cmV2IG9mIHRoZSBkb2N1bWVudC4NCj4gV2hhdCB3ZSBjb3VsZCBjb25zaWRlciBpcyBsaW5raW5n IHRoZSBSTkQgbnVtYmVyIHRvIENSQyBhY3Jvc3MgdGhlIHBhY2tldCBwYXlsb2FkIG9yIHNpbWls YXIgLSBidXQgdGhhdCB3YXkgd2UnZCByZXN0cmljdCB0aGUgYXBwbGljYWJpbGl0eSB0byBkZXBs b3ltZW50cyB3aGVyZSB0aGUgcGFja2V0IHBheWxvYWQgaXNuJ3QgY2hhbmdlZCBhY3Jvc3MgdGhl IHBhdGggKHdoaWNoIG1pZ2h0IG5vdCBhcHBseSB0byBjZXJ0YWluIGRlcGxveW1lbnQgLSBlLmcu IFdBTiBvcHRpbWl6YXRpb24gLyBjb21wcmVzc2lvbiBzY2hlbWVzKS4NCj4gRG8geW91IHRoaW5r IGl0IGlzIHdvcnRod2hpbGUgdG8gcHJvdmlkZSBhIHNvbHV0aW9uIGZvciBhIGRlcGxveW1lbnQg d2hpY2ggaXMgZXhwZWN0ZWQgdG8gbm90IGFsdGVyIHRoZSBwYWNrZXQgcGF5bG9hZD8NCj4gDQo+ IFRoYW5rcywNCj4gRnJhbmsNCj4gDQo+IEZyb206IFRhbCBNaXpyYWhpIFttYWlsdG86dGFsbWlA bWFydmVsbC5jb21dDQo+IFNlbnQ6IERpZW5zdGFnLCAxOS4gSnVsaSAyMDE2IDE3OjQ0DQo+IFRv OiBTYXNoYW5rIERhcmEgKHNhZGFyYSkgPHNhZGFyYUBjaXNjby5jb208bWFpbHRvOnNhZGFyYUBj aXNjby5jb20+PjsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25lQGNpc2NvLmNv bTxtYWlsdG86ZmJyb2NrbmVAY2lzY28uY29tPj47IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi10 cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJh bnNpdEB0b29scy5pZXRmLm9yZz4NCj4gQ2M6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBudm8zQGlldGYu b3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJk aW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4gDQo+IEhpLA0KPiANCj4gVG8gc3VtbWFyaXpl IG15IHRha2Ugb24gdGhpcyB0aHJlYWQ6DQo+IFRoZSBwcm9wb3NlZCBtZWNoYW5pc20gaGFzIHR3 byBzaWduaWZpY2FudCB2dWxuZXJhYmlsaXRpZXMgdGhhdCAoaW4gbXkgdW5kZXJzdGFuZGluZykg YXJlIGN1cnJlbnRseSBub3QgYWRkcmVzc2VkOg0KPiANCj4gMS4gICAgICAgQSBtYW4taW4tdGhl LW1pZGRsZSBjYW4gcmVwbGFjZSB0aGUgUE9UIG9mIHBhY2tldCBBIHdpdGggdGhlIFBPVCBvZiBw YWNrZXQgQi4NCj4gDQo+IDIuICAgICAgIEl0IGlzIHBvc3NpYmxlIHRvIHJlcGxheSBQT1RzIHdp dGhpbiBhIGNlcnRhaW4gdGltZSB3aW5kb3csIHdob3NlIGxlbmd0aCBpcyBkZXRlcm1pbmVkIGJ5 IHRoZSB0aW1lc3RhbXAgcmVzb2x1dGlvbi4NCj4gDQo+IFNhc2hhbmssIHRoYW5rcyBmb3IgYWdy ZWVpbmcgdG8gbG9vayBpbnRvIGl0IGZ1cnRoZXIuIEkgYW0gbG9va2luZyBmb3J3YXJkIHRvIHlv dXIgaW5zaWdodHMgb24gdGhpcy4NCj4gDQo+IFJlZ2FyZHMsDQo+IFRhbC4NCj4gDQo+IExpbmsg dG8gdGhlIGRyYWZ0OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJz LXByb29mLW9mLXRyYW5zaXQtMDENCj4gDQo+IA0KPiANCj4gRnJvbTogU2FzaGFuayBEYXJhIChz YWRhcmEpIFttYWlsdG86c2FkYXJhQGNpc2NvLmNvbV0NCj4gU2VudDogVHVlc2RheSwgSnVseSAx OSwgMjAxNiAxMjoyMCBQTQ0KPiBUbzogVGFsIE1penJhaGk7IEZyYW5rIEJyb2NrbmVycyAoZmJy b2NrbmUpOyBkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+OyBz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFF1ZXN0aW9u IHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQo+IA0KPiANCj4gDQo+IEkgd2FudCB0 byBhc2sgYSBzaW1wbGUgcXVlc3Rpb246DQo+IElmIHRoZSBhdHRhY2tlciBhdHRhY2hlcyB0aGUg UE9UIG9mIHBhY2tldCBBIChpbmRpY2F0aW5nIHRoZSBwYXRoIHRocm91Z2ggMSwzLDUsNikgdG8g cGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2VwdCBwYWNrZXQgQiBhbmQgYmVsaWV2ZSB0 aGF0IGl0cyBwYXRoIHdhcyBpbmRlZWQgKDEsMyw1LDYpPw0KPiANCj4gW1NEXSBJZiB0aGUgdmVy aWZpZXIgaXMgcHJvZ3JhbW1lZCB0byBqdXN0IHZhbGlkYXRlIHRoZSBQT1QgbWV0YSBkYXRhIGFn YWluc3QgezEsMyw1LDZ9IHRoZW4geWVzIGl0IGFjY2VwdHMgaXQuDQo+IElmIHRoZSB2ZXJpZmll ciBpcyBwcm9ncmFtbWVkIHRvIGNvbnN1bHQgYSBwb2xpY3kgZGF0YWJhc2UgdG8gY3Jvc3MgY2hl Y2sgaWYgdGhlIHJlY29uc3RydWN0ZWQgcGF0aCB7MSwzLDUsNn0gaXMgYXMgcGVyIHRoZSBwb2xp Y2llcyB0aGVuIG5vICwgaXQgZHJvcHMgaXQgLg0KPiANCj4gQnV0IEkgc2VlIHlvdXIgcG9pbnQg LCB0aGF0IHRoZSBwYXJhbWV0ZXJzIHVzZWQgaW4gUE9UIGRhdGEgZG9ub3QgY29uc2lkZXIgdGhl IHBhdGggb3Igbm9kZS1pZHMgZXRjIC4gV2Ugc2hhbGwgZGlzY3VzcyB0aGlzIGludGVybmFsbHkg YW5kIGdldCBiYWNrLg0KPiANCj4gQWxzbywgV2Ugc2hhbGwgZ2V0IGJhY2sgd2l0aCBtb3JlIGNv bmNyZXRlIG51bWJlcnMgb2YgdGhlIHRpbWVzdGFtcCByZXNvbHV0aW9uIGFuZCBjYWNoZSBzaXpl cyAob3Igb3RoZXIgYmV0dGVyIGFwcHJvYWNoZXMpLg0KPiANCj4gVGhhbmsgeW91IHNvIG11Y2gg Zm9yIGFsbCB0aGUgaW5wdXRzLg0KPiANCj4gDQo+IA0KPiBGcm9tOiBUYWwgTWl6cmFoaQ0KPiBT ZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDEwOjI4IEFNDQo+IFRvOiAnU2FzaGFuayBEYXJh IChzYWRhcmEpJzsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSk7IGRyYWZ0LWJyb2NrbmVycy1w cm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJv b2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KPiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5z aXQgZHJhZnQNCj4gDQo+IERlYXIgU2FzaGFuaywNCj4gDQo+IEkgcmVhbGx5IGFwcHJlY2lhdGUg dGhlIHF1aWNrIGFuZCBkZXRhaWxlZCByZXNwb25zZXMuDQo+IA0KPj4+PiBMZXRzIHRha2UgY29y cmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tldCBBICB0byBiZSBQYXRoMSAtICggMSwzLDUsNikgbm9k ZXMNCg0K From nobody Wed Jul 20 02:43: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 B957112D134; Wed, 20 Jul 2016 02:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 yr0A7cTc3FWy; Wed, 20 Jul 2016 02:42:59 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0424F12D096; Wed, 20 Jul 2016 02:42:58 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6K9ddiU023071; Wed, 20 Jul 2016 02:42:57 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 24a2qw8yyp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Jul 2016 02:42:57 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jul 2016 12:42:54 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Wed, 20 Jul 2016 12:42:54 +0300 From: Tal Mizrahi To: "Carlos Pignataro (cpignata)" Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnUR6x6RUowp0WBJweV5BhC9aAhDzig Date: Wed, 20 Jul 2016 09:42:53 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> In-Reply-To: <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@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: [199.203.130.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_06:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200112 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [sfc] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 09:43:02 -0000 SGkgQ2FybG9zLA0KDQoNCj5MZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRsZSDigJQgdGhlIOKAnHZ1 bG5lcmFiaWxpdHnigJ0geW91IGFyZSBkZXNjcmliaW5nIGNvbWVzIHdpdGggdGhlDQo+YXNzdW1w dGlvbiB0aGF0IGEgTUlJVCBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IGEgcGFja2V0LCBleHRyYWN0 IGEgVExWIGZyb20NCj50aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNrZXQ7IHRoZW4gaW50ZXJj ZXB0IGFub3RoZXIgcGFja2V0ICh3aXRoIHRoZQ0KPmtub3dsZWRnZSB0aGF0IGl0IHRvb2sgYSBk aWZmZXJlbnQgcGF0aCwgc28gbWF5YmUgdGhlIGF0dGFja2VyIGlzIHVzaW5nIGluYmFuZA0KPk9B TSBhcyB3ZWxsIDotKSwgYW5kIGluc2VydCAob3IgbW9kaWZ5KSBhIFRMViB3aXRoaW4gdGhlIGNv bnRlbnQgb2YgdGhlIE1EDQo+VHlwZSAyIHdpdGhpbiB0aGUgY29udGVudCBvZiBOU0gsIHdpdGhp biBhIHNwZWNpZmljIHBhY2tldC4NCj4NCj5UaGlzIHNvdW5kcyBxdWl0ZSBzb3BoaXN0aWNhdGVk Lg0KDQpJIGFtIG5vdCBzdXJlIEkgYWdyZWUgdGhpcyBpcyBhICdzb3BoaXN0aWNhdGVkJyBhdHRh Y2suDQpUaGUgYXR0YWNrIGRvZXMgbm90IHJlcXVpcmUgYW55IGNyeXB0b2dyYXBoaWMgb3IgYWxn b3JpdGhtaWMgZnVuY3Rpb25hbGl0eSwgYW5kIHRvIHRoYXQgZW5kIGl0IGlzIHZlcnkgbGlnaHR3 ZWlnaHQgaW4gdGVybXMgb2YgcHJvY2Vzc2luZyByZXNvdXJjZXMuDQoNCklmIHRoaXMga2luZCBv ZiBhdHRhY2sgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgaGVyZSwgdGhlbiBJIHdvdWxkIGFyZ3Vl IHRoYXQgeW91IGRvbid0IG5lZWQgYSBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBhdCBhbGwuIEFs bCB5b3UgbmVlZCBpcyBhIFRMViB0aGF0IHNwZWNpZmllcyB0aGUgbGlzdCBvZiBub2Rlcy4gSG93 ZXZlciwgSSBiZWxpZXZlIHRoYXQgeW91IGRpZCB3YW50IHRvIHRyeSB0byBtaXRpZ2F0ZSBNSVRN IGF0dGFja2Vycy4gQ29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLg0KDQpJIGZ1bGx5IGFncmVlIHRo YXQgdGhlIHRocmVhdCBtb2RlbCBuZWVkcyB0byBiZSB3ZWxsLWRlZmluZWQuIEkgaG9wZSB5b3Ug d2lsbCBlbGFib3JhdGUgbW9yZSBvbiB0aGUgdGhyZWF0IG1vZGVsIGluIHRoZSBuZXh0IHZlcnNp b24gb2YgdGhlIGRyYWZ0Lg0KDQpDaGVlcnMsDQpUYWwuDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+RnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3Bp Z25hdGFAY2lzY28uY29tXQ0KPlNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMCwgMjAxNiAxMTozNCBB TQ0KPlRvOiBUYWwgTWl6cmFoaQ0KPkNjOiBTYXNoYW5rIERhcmEgKHNhZGFyYSk7IEZyYW5rIEJy b2NrbmVycyAoZmJyb2NrbmUpOyBkcmFmdC1icm9ja25lcnMtcHJvb2YtDQo+b2YtdHJhbnNpdEB0 b29scy5pZXRmLm9yZzsgc2ZjQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc7IG52bzNAaWV0Zi5v cmcNCj5TdWJqZWN0OiBNRCBUeXBlIGF0dGFjayAoV2FzOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJv b2Ygb2YgVHJhbnNpdCBkcmFmdCkNCj4NCj5UYWwsDQo+DQo+PiBPbiBKdWwgMjAsIDIwMTYsIGF0 IDY6MzAgQU0sIFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+Pg0KPj4g SGkgU2FzaGFuaywNCj4+DQo+Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhl IGF0dGFja2VyIGNhbiBnZXQgYXdheSBieXBhc3NpbmcgYQ0KPnNlcnZpY2UgZnVuY3Rpb24vbm9k ZS4NCj4+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9kZSBhbmQg aWYgUE9UIGRldGVybWluZXMgaXQgZGlkDQo+bm90IGJ5cGFzcyBpcyBhIHZhbGlkIGF0dGFjayBv biB0aGUgc3lzdGVtLg0KPj4NCj4+IEkgd291bGQgcGhyYXNlIGl0IHRoaXMgd2F5OiAqR2l2ZW4q IGEgcGFja2V0IHRoYXQgZGlkIG5vdCBnbyB0aHJvdWdoIGl0cw0KPmRlc2lyZWQgcGF0aCwgdGhl IGF0dGFja2VyIGNhbiBlYXNpbHkgbWFrZSB5b3UgdGhpbmsgdGhhdCBpdCAqZGlkKiBnbyB0aHJv dWdoDQo+dGhlIGRlc2lyZWQgcGF0aC4NCj4+IFNvdW5kcyBsaWtlIGEgdmVyeSBzaWduaWZpY2Fu dCB2dWxuZXJhYmlsaXR5Lg0KPj4NCj4+IElmIGEgcGFja2V0IGRpZCBub3QgZ28gdGhyb3VnaCB0 aGUgZmlyZXdhbGwgKGZvciBvbmUgcmVhc29uIG9yIGFub3RoZXIpLCB0aGUNCj5hdHRhY2tlciB3 aWxsIG1ha2UgeW91IHRoaW5rIHRoYXQgaXQgZGlkIGdvIHRocm91Z2ggdGhlIGZpcmV3YWxsLg0K Pj4NCj4NCj5MZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRsZSDigJQgdGhlIOKAnHZ1bG5lcmFiaWxp dHnigJ0geW91IGFyZSBkZXNjcmliaW5nIGNvbWVzIHdpdGggdGhlDQo+YXNzdW1wdGlvbiB0aGF0 IGEgTUlJVCBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IGEgcGFja2V0LCBleHRyYWN0IGEgVExWIGZy b20NCj50aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNrZXQ7IHRoZW4gaW50ZXJjZXB0IGFub3Ro ZXIgcGFja2V0ICh3aXRoIHRoZQ0KPmtub3dsZWRnZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQg cGF0aCwgc28gbWF5YmUgdGhlIGF0dGFja2VyIGlzIHVzaW5nIGluYmFuZA0KPk9BTSBhcyB3ZWxs IDotKSwgYW5kIGluc2VydCAob3IgbW9kaWZ5KSBhIFRMViB3aXRoaW4gdGhlIGNvbnRlbnQgb2Yg dGhlIE1EDQo+VHlwZSAyIHdpdGhpbiB0aGUgY29udGVudCBvZiBOU0gsIHdpdGhpbiBhIHNwZWNp ZmljIHBhY2tldC4NCj4NCj5UaGlzIHNvdW5kcyBxdWl0ZSBzb3BoaXN0aWNhdGVkLg0KPg0KPkRv IHlvdSB0aGluayB0aGF0IGlmIGFuIE1JSVQgY2FuIGhhdmUgdGhhdCBzdXJmYWNlIG9mIGF0dGFj ayBhbmQNCj5zb3BoaXN0aWNhdGlvbiwgdGhleSBjYW4gbWVzcyB1cCB3aXRoIG90aGVyIGV2ZW4g bW9yZSBjcml0aWNhbCB0aGluZ3M/DQo+Q2hhbmdpbmcgYSBUZW5hbnQgSUQsIG1lc3NpbmcgdXAg d2l0aCBQb2xpY3kgR3JvdXBzLCBldGM/DQo+DQo+TXkgcG9pbnQgaXMgdGhhdCB3aGF0IHlvdSBz ZWVtIHRvIGJlIGRlc2NyaWJpbmcgaXMgYSBnZW5lcmljIHRocmVhdCB1c2UgY2FzZQ0KPmFuZCBu b3QgYSBzcGVjaWZpYyB2dWxuZXJhYmlsaXR5LiBFbmdpbmVlcmluZyBpcyBhYm91dCB0cmFkZS1v ZmZzIChpLmUuLCBzb2x1dGlvbnMNCj50aGF0IGhhdmUgcHJhY3RpY2FsIHBlcmZvcm1hbmNlKSBh bmQgYWJvdXQgcGxhY2luZyB0aGUgc29sdXRpb24gaW4gdGhlIG1vc3QNCj5lZmZlY3RpdmUgcGxh Y2UuDQo+DQo+SeKAmW0gbm90IGRlZmxlY3RpbmcgYnV0IGF0IHRoZSBzYW1lIHRpbWUsIGxldOKA mXMgdW5kZXJzdGFuZCB0aGUgYXNzdW1wdGlvbnMgeW91DQo+YXJlIG1ha2luZyBmb3IgdGhpcyBw b3RlbnRpYWwgYXR0YWNrIHlvdSBkZXNjcmliZSwgYXMgcGFydCBvZiB0aGUgdGhyZWF0DQo+YW5h bHlzaXMuDQo+DQo+VGhhbmtzLA0KPg0KPuKAlCBDYXJsb3MuDQo+DQo+PiBDaGVlcnMsDQo+PiBU YWwuDQo+Pg0KPj4NCj4+IEZyb206IFNhc2hhbmsgRGFyYSAoc2FkYXJhKSBbbWFpbHRvOnNhZGFy YUBjaXNjby5jb21dDQo+PiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjAsIDIwMTYgNDozMSBBTQ0K Pj4gVG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsgZHJhZnQtYnJv Y2tuZXJzLXByb29mLW9mLQ0KPnRyYW5zaXRAdG9vbHMuaWV0Zi5vcmcNCj4+IENjOiBzZmNAaWV0 Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFF1 ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQo+Pg0KPj4NCj4+DQo+PiBU aGUgUE9UIHJlcGxhY2VtZW50IGF0dGFjayAoMS4pIGlzIG5vdCBhbiBhdHRhY2sgb24gdGhlIGlu dGVncml0eS4gSXQgaXMgYW4NCj5hdHRhY2sgb24gdGhlIHBhdGggdmVyaWZpY2F0aW9uLg0KPj4g VGhpcyBzaW1wbGUgYXR0YWNrIGNhbiBjYXVzZSB0aGUgdmVyaWZpZXIgdG8gYWNjZXB0IGEgcGFj a2V0IHRoYXQgZGlkIG5vdCBnbw0KPnRocm91Z2ggdGhlIGZpcmV3YWxsIFNGIChldmVuIHRob3Vn aCBpdCBzaG91bGQpLiBJIGJlbGlldmUgdGhpcyBpcyBleGFjdGx5IHRoZQ0KPnByb2JsZW0geW91 IHdlcmUgYWltaW5nIHRvIGFkZHJlc3MgaW4gdGhpcyBkcmFmdC4NCj4+DQo+PiBbU0RdIFRoZSBh dHRhY2sgaXMgdmFsaWQgb25seSBpZiB0aGUgYXR0YWNrZXIgY2FuIGdldCBhd2F5IGJ5cGFzc2lu ZyBhIHNlcnZpY2UNCj5mdW5jdGlvbi9ub2RlLg0KPj4gRm9yIGV4YW1wbGUsIGlmIHRoZSBhdHRh Y2tlciBieXBhc3NlcyBhIG5vZGUgYW5kIGlmIFBPVCBkZXRlcm1pbmVzIGl0IGRpZA0KPm5vdCBi eXBhc3MgaXMgYSB2YWxpZCBhdHRhY2sgb24gdGhlIHN5c3RlbS4NCj4+DQo+PiBJbiB0aGUgY3Vy cmVudCBzdGF0ZSwgdGhlcmUgaXMgbm8gd2F5IGFuIGF0dGFja2VyIGNhbiBnZXQgYXdheSBhcyB3 ZQ0KPmRldGVybWluZSB0aGUgZXhhY3QgcGF0aCB0aGUgcGFja2V0IHRyYXZlbGxlZCAoYWltIG9m IHRoZSBkcmFmdCkgLg0KPj4gSSByZWl0ZXJhdGUgdGhhdCB0aGUgdmVyaWZpZXIgbmVlZHMgdG8g aGFuZGxlIHdoYXQgdG8gZG8gd2l0aCB0aGUgcGF0aA0KPnJlY29uc3RydWN0ZWQgIQ0KPj4gV2Ug Y291bGQgZW1waGFzaXplIHRoaXMgaW4gb3VyIG5leHQgZHJhZnQgLCBidXQgaXQgd291bGQgYmUg YmV5b25kIHNjb3BlIG9mDQo+UE9UIHRvIGRldGVybWluZSB3aGF0IHRvIGRvIHdpdGggdGhlIHBh dGggY29uc3RydWN0ZWQuDQo+PiBJTU8sIEl0IHdvdWxkIGJlIGhpZ2hseSBhcHBsaWNhdGlvbiBz cGVjaWZpYy4NCj4+DQo+Pg0KPj4gUmVnYXJkcywNCj4+IFNhc2hhbmsNCj4+DQo+Pg0KPj4NCj4+ IFRoYW5rcywNCj4+IFRhbC4NCj4+DQo+PiBGcm9tOiBGcmFuayBCcm9ja25lcnMgKGZicm9ja25l KSBbbWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbV0NCj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTks IDIwMTYgNjowMCBQTQ0KPj4gVG86IFRhbCBNaXpyYWhpOyBTYXNoYW5rIERhcmEgKHNhZGFyYSk7 IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi0NCj50cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+dHJhbnNpdEB0b29scy5pZXRmLm9yZz4NCj4+ IENjOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+b3BzYXdnQGlldGYub3Jn PG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+Ow0KPm52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0 Zi5vcmc+DQo+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5z aXQgZHJhZnQNCj4+DQo+PiBIaSBUYWwsDQo+Pg0KPj4gdGhhbmtzIGZvciB0aGUgc3VtbWFyeS4g V2UnbGwgcHJvdmlkZSBtb3JlIGRldGFpbHMgb24gMi4gUGVyIG15IGVhcmxpZXINCj5wb2ludCAt IDEuIGlzIGFuIGludGVyZXN0aW5nIGRpc2N1c3Npb24sIGdpdmVuIHRoYXQgd2UgZG9uJ3QgY2xh aW0gdG8gcHJvdmlkZQ0KPmludGVncml0eSBwcm90ZWN0aW9uIGZvciB0aGUgcGFja2V0IHBheWxv YWQuIE9yIGluIG90aGVyIHRlcm1zIC0gdG8gYmUgZXhhY3Q6DQo+V2hhdCBQT1QgcHJvdmlkZXMg aXMgYSBwcm9vZiB0aGF0IHRoZSBQT1QtaGVhZGVyL21ldGEtZGF0YSB0cmFuc2l0ZWQgYWxsIHRo ZQ0KPnJlcXVpcmVkIG5vZGVzLiBUaGVyZSBpcyBubyBhc3NvY2lhdGlvbiAoYW5kIHRodXMgcHJv b2YpIHByb3ZpZGVkIGZvciB0aGUNCj5hZGRpdGlvbmFsIGRhdGEgY2FycmllZCBhbG9uZyB3aXRo IHRoZSBQT1QtaGVhZGVyIC0gbmVpdGhlciBoZWFkZXIgbm9yDQo+cGF5bG9hZC4gQXMgYSBjb25z ZXF1ZW5jZSwgYXR0YWNrcyB3aGljaCBjaGFuZ2UgdGhlIHBhY2tldCBwYXlsb2FkIHdvbid0DQo+ YmUgZGV0ZWN0ZWQvbWl0aWdhdGVkLiBXZSdsbCBleHBsaWNpdGx5IHN0YXRlIHRoaXMgaW4gdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQo+aW4gdGhlIG5leHQgcmV2IG9mIHRoZSBkb2N1bWVu dC4NCj4+IFdoYXQgd2UgY291bGQgY29uc2lkZXIgaXMgbGlua2luZyB0aGUgUk5EIG51bWJlciB0 byBDUkMgYWNyb3NzIHRoZSBwYWNrZXQNCj5wYXlsb2FkIG9yIHNpbWlsYXIgLSBidXQgdGhhdCB3 YXkgd2UnZCByZXN0cmljdCB0aGUgYXBwbGljYWJpbGl0eSB0byBkZXBsb3ltZW50cw0KPndoZXJl IHRoZSBwYWNrZXQgcGF5bG9hZCBpc24ndCBjaGFuZ2VkIGFjcm9zcyB0aGUgcGF0aCAod2hpY2gg bWlnaHQgbm90DQo+YXBwbHkgdG8gY2VydGFpbiBkZXBsb3ltZW50IC0gZS5nLiBXQU4gb3B0aW1p emF0aW9uIC8gY29tcHJlc3Npb24gc2NoZW1lcykuDQo+PiBEbyB5b3UgdGhpbmsgaXQgaXMgd29y dGh3aGlsZSB0byBwcm92aWRlIGEgc29sdXRpb24gZm9yIGEgZGVwbG95bWVudCB3aGljaCBpcw0K PmV4cGVjdGVkIHRvIG5vdCBhbHRlciB0aGUgcGFja2V0IHBheWxvYWQ/DQo+Pg0KPj4gVGhhbmtz LA0KPj4gRnJhbmsNCj4+DQo+PiBGcm9tOiBUYWwgTWl6cmFoaSBbbWFpbHRvOnRhbG1pQG1hcnZl bGwuY29tXQ0KPj4gU2VudDogRGllbnN0YWcsIDE5LiBKdWxpIDIwMTYgMTc6NDQNCj4+IFRvOiBT YXNoYW5rIERhcmEgKHNhZGFyYSkNCj48c2FkYXJhQGNpc2NvLmNvbTxtYWlsdG86c2FkYXJhQGNp c2NvLmNvbT4+OyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKQ0KPjxmYnJvY2tuZUBjaXNjby5j b208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+OyBkcmFmdC1icm9ja25lcnMtDQo+cHJvb2Yt b2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9m LQ0KPnRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+DQo+PiBDYzogc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Ow0KPm9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsN Cj5udm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPj4gU3ViamVjdDogUkU6IFF1 ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQo+Pg0KPj4gSGksDQo+Pg0K Pj4gVG8gc3VtbWFyaXplIG15IHRha2Ugb24gdGhpcyB0aHJlYWQ6DQo+PiBUaGUgcHJvcG9zZWQg bWVjaGFuaXNtIGhhcyB0d28gc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0aWVzIHRoYXQgKGluIG15 DQo+dW5kZXJzdGFuZGluZykgYXJlIGN1cnJlbnRseSBub3QgYWRkcmVzc2VkOg0KPj4NCj4+IDEu ICAgICAgIEEgbWFuLWluLXRoZS1taWRkbGUgY2FuIHJlcGxhY2UgdGhlIFBPVCBvZiBwYWNrZXQg QSB3aXRoIHRoZSBQT1Qgb2YNCj5wYWNrZXQgQi4NCj4+DQo+PiAyLiAgICAgICBJdCBpcyBwb3Nz aWJsZSB0byByZXBsYXkgUE9UcyB3aXRoaW4gYSBjZXJ0YWluIHRpbWUgd2luZG93LCB3aG9zZQ0K Pmxlbmd0aCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSB0aW1lc3RhbXAgcmVzb2x1dGlvbi4NCj4+DQo+ PiBTYXNoYW5rLCB0aGFua3MgZm9yIGFncmVlaW5nIHRvIGxvb2sgaW50byBpdCBmdXJ0aGVyLiBJ IGFtIGxvb2tpbmcgZm9yd2FyZCB0bw0KPnlvdXIgaW5zaWdodHMgb24gdGhpcy4NCj4+DQo+PiBS ZWdhcmRzLA0KPj4gVGFsLg0KPj4NCj4+IExpbmsgdG8gdGhlIGRyYWZ0OiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPnRyYW5zaXQtMDENCj4+ DQo+Pg0KPj4NCj4+IEZyb206IFNhc2hhbmsgRGFyYSAoc2FkYXJhKSBbbWFpbHRvOnNhZGFyYUBj aXNjby5jb21dDQo+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDEyOjIwIFBNDQo+PiBU bzogVGFsIE1penJhaGk7IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpOyBkcmFmdC1icm9ja25l cnMtcHJvb2Ytb2YtDQo+dHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tu ZXJzLXByb29mLW9mLQ0KPnRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+OyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJv b2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4NCj4+DQo+Pg0KPj4gSSB3YW50IHRvIGFzayBhIHNpbXBs ZSBxdWVzdGlvbjoNCj4+IElmIHRoZSBhdHRhY2tlciBhdHRhY2hlcyB0aGUgUE9UIG9mIHBhY2tl dCBBIChpbmRpY2F0aW5nIHRoZSBwYXRoIHRocm91Z2gNCj4xLDMsNSw2KSB0byBwYWNrZXQgQiwg d2lsbCB0aGUgdmVyaWZpZXIgYWNjZXB0IHBhY2tldCBCIGFuZCBiZWxpZXZlIHRoYXQgaXRzIHBh dGgNCj53YXMgaW5kZWVkICgxLDMsNSw2KT8NCj4+DQo+PiBbU0RdIElmIHRoZSB2ZXJpZmllciBp cyBwcm9ncmFtbWVkIHRvIGp1c3QgdmFsaWRhdGUgdGhlIFBPVCBtZXRhIGRhdGEgYWdhaW5zdA0K PnsxLDMsNSw2fSB0aGVuIHllcyBpdCBhY2NlcHRzIGl0Lg0KPj4gSWYgdGhlIHZlcmlmaWVyIGlz IHByb2dyYW1tZWQgdG8gY29uc3VsdCBhIHBvbGljeSBkYXRhYmFzZSB0byBjcm9zcyBjaGVjayBp Zg0KPnRoZSByZWNvbnN0cnVjdGVkIHBhdGggezEsMyw1LDZ9IGlzIGFzIHBlciB0aGUgcG9saWNp ZXMgdGhlbiBubyAsIGl0IGRyb3BzIGl0IC4NCj4+DQo+PiBCdXQgSSBzZWUgeW91ciBwb2ludCAs IHRoYXQgdGhlIHBhcmFtZXRlcnMgdXNlZCBpbiBQT1QgZGF0YSBkb25vdCBjb25zaWRlcg0KPnRo ZSBwYXRoIG9yIG5vZGUtaWRzIGV0YyAuIFdlIHNoYWxsIGRpc2N1c3MgdGhpcyBpbnRlcm5hbGx5 IGFuZCBnZXQgYmFjay4NCj4+DQo+PiBBbHNvLCBXZSBzaGFsbCBnZXQgYmFjayB3aXRoIG1vcmUg Y29uY3JldGUgbnVtYmVycyBvZiB0aGUgdGltZXN0YW1wDQo+cmVzb2x1dGlvbiBhbmQgY2FjaGUg c2l6ZXMgKG9yIG90aGVyIGJldHRlciBhcHByb2FjaGVzKS4NCj4+DQo+PiBUaGFuayB5b3Ugc28g bXVjaCBmb3IgYWxsIHRoZSBpbnB1dHMuDQo+Pg0KPj4NCj4+DQo+PiBGcm9tOiBUYWwgTWl6cmFo aQ0KPj4gU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiAxMDoyOCBBTQ0KPj4gVG86ICdTYXNo YW5rIERhcmEgKHNhZGFyYSknOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsgZHJhZnQtYnJv Y2tuZXJzLQ0KPnByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWJy b2NrbmVycy1wcm9vZi1vZi0NCj50cmFuc2l0QHRvb2xzLmlldGYub3JnPjsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5n IFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+DQo+PiBEZWFyIFNhc2hhbmssDQo+Pg0KPj4gSSBy ZWFsbHkgYXBwcmVjaWF0ZSB0aGUgcXVpY2sgYW5kIGRldGFpbGVkIHJlc3BvbnNlcy4NCj4+DQo+ Pj4+PiBMZXRzIHRha2UgY29ycmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tldCBBICB0byBiZSBQYXRo MSAtICggMSwzLDUsNikgbm9kZXMNCg0K From nobody Wed Jul 20 02:51: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 8826912DB0A; Wed, 20 Jul 2016 02:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 CQPp-a4ZnOyR; Wed, 20 Jul 2016 02:51:10 -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 AB71412DA1E; Wed, 20 Jul 2016 02:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14188; q=dns/txt; s=iport; t=1469008269; x=1470217869; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xYJVKkwt7sFtJXeuOXLrgHxyCErHHGKdK3pG/4PU5CQ=; b=NEGfR7F3tC2x/M3CIGeUYqcKmo0sIt8nAujKIYfLHv7VE2mQ2KIPzM4s XG07Rc+zw0yuntpuE9Hlntpr8InjPXCJhGYt7vjLqKEh1LWFOKkLH5201 jbqQjGHtDhJcSEH6uqeeG1+zVf0Lm2nuqSdGpH6HZZFmUC14Yql4o5ybK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgBKSI9X/4MNJK1dgz9WfAa4a4F6I?= =?us-ascii?q?oV4AhyBEjgUAQEBAQEBAWUnhFwBAQQBIxEzEgUHBAIBCBEEAQEBAgIjAwICAjA?= =?us-ascii?q?UAQgIAgQOBRuIDQgOr1WNdAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQGFKYF4C?= =?us-ascii?q?IJNhFeCaiuCLwWZJgGGEohPjzmQHwEeNoILHIFMboYuKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="126081728" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 09:51:08 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6K9p8AI013616 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 09:51:08 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 05:51:05 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 05:51:05 -0400 From: "Carlos Pignataro (cpignata)" To: Tal Mizrahi Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnQwDyp0062d0e9x6ZtxvV7RaAhVGaAgAACSQA= Date: Wed, 20 Jul 2016 09:51:05 +0000 Message-ID: <16454292-3ADD-402A-AED6-CB785C5C833B@cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@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.61.88.191] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [sfc] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 09:51:12 -0000 SGksIFRhbCwNCg0KPiBPbiBKdWwgMjAsIDIwMTYsIGF0IDExOjQyIEFNLCBUYWwgTWl6cmFoaSA8 dGFsbWlAbWFydmVsbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgQ2FybG9zLA0KPiANCj4gDQo+PiBM ZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRsZSDigJQgdGhlIOKAnHZ1bG5lcmFiaWxpdHnigJ0geW91 IGFyZSBkZXNjcmliaW5nIGNvbWVzIHdpdGggdGhlDQo+PiBhc3N1bXB0aW9uIHRoYXQgYSBNSUlU IGF0dGFja2VyIGNhbiBpbnRlcmNlcHQgYSBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbQ0KPj4g dGhlIE1EIFR5cGUgMiwgZHJvcCB0aGUgcGFja2V0OyB0aGVuIGludGVyY2VwdCBhbm90aGVyIHBh Y2tldCAod2l0aCB0aGUNCj4+IGtub3dsZWRnZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQgcGF0 aCwgc28gbWF5YmUgdGhlIGF0dGFja2VyIGlzIHVzaW5nIGluYmFuZA0KPj4gT0FNIGFzIHdlbGwg Oi0pLCBhbmQgaW5zZXJ0IChvciBtb2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBvZiB0 aGUgTUQNCj4+IFR5cGUgMiB3aXRoaW4gdGhlIGNvbnRlbnQgb2YgTlNILCB3aXRoaW4gYSBzcGVj aWZpYyBwYWNrZXQuDQo+PiANCj4+IFRoaXMgc291bmRzIHF1aXRlIHNvcGhpc3RpY2F0ZWQuDQo+ IA0KPiBJIGFtIG5vdCBzdXJlIEkgYWdyZWUgdGhpcyBpcyBhICdzb3BoaXN0aWNhdGVkJyBhdHRh Y2suDQo+IFRoZSBhdHRhY2sgZG9lcyBub3QgcmVxdWlyZSBhbnkgY3J5cHRvZ3JhcGhpYyBvciBh bGdvcml0aG1pYyBmdW5jdGlvbmFsaXR5LCBhbmQgdG8gdGhhdCBlbmQgaXQgaXMgdmVyeSBsaWdo dHdlaWdodCBpbiB0ZXJtcyBvZiBwcm9jZXNzaW5nIHJlc291cmNlcy4NCg0KU29ycnkgaWYgSSB3 YXMgbm90IGNsZWFyIOKAlCBJIGRvIG5vdCBtZWFuIHRlY2hub2xvZ2ljYWwgc29waGlzdGljYXRp b24gb3IgbWFzc2l2ZSBwcm9jZXNzaW5nIHJlc291cmNlcyByZXF1aXJlZC4gSSBtZWFuIGFjY2Vz cyBhbmQgb3BlcmF0aW9uYWwgb25lLg0KDQo+IA0KPiBJZiB0aGlzIGtpbmQgb2YgYXR0YWNrIGlz IG5vdCB3aXRoaW4gdGhlIHNjb3BlIGhlcmUsIHRoZW4gSSB3b3VsZCBhcmd1ZSB0aGF0IHlvdSBk b24ndCBuZWVkIGEgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gYXQgYWxsLiBBbGwgeW91IG5lZWQg aXMgYSBUTFYgdGhhdCBzcGVjaWZpZXMgdGhlIGxpc3Qgb2Ygbm9kZXMuIEhvd2V2ZXIsIEkgYmVs aWV2ZSB0aGF0IHlvdSBkaWQgd2FudCB0byB0cnkgdG8gbWl0aWdhdGUgTUlUTSBhdHRhY2tlcnMu IENvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy4NCj4gDQoNCllvdSBzZWVtIHRvIGhhdmUgbWlzc2Vk IHF1b3RpbmcgdGhlIGltcG9ydGFudCBwYXJ0IG9mIG15IHJlc3BvbnNlOiAiTXkgcG9pbnQgaXMg dGhhdCB3aGF0IHlvdSBzZWVtIHRvIGJlIGRlc2NyaWJpbmcgaXMgYSBnZW5lcmljIHRocmVhdCB1 c2UgY2FzZSBhbmQgbm90IGEgc3BlY2lmaWMgdnVsbmVyYWJpbGl0eS7igJ0NCg0KU2VsZWN0aXZl bHkgZHJvcHBpbmcgcGFydCBvZiB0aGUgcmVzcG9uc2UgcmVtb3ZlcyBpbXBvcnRhbnQgY29udGV4 dC4NCg0KPiBJIGZ1bGx5IGFncmVlIHRoYXQgdGhlIHRocmVhdCBtb2RlbCBuZWVkcyB0byBiZSB3 ZWxsLWRlZmluZWQuDQoNClRoZSB0aHJlYXQgbW9kZWwgZm9yIFNGQyBNRCwgeWVzLiBBY2Nlc3Mg dG8gdGhlIFBPVCBjb21lcyB3aXRoIGFzc3VtcHRpb25zLg0KDQpUaGFua3MsDQoNCuKAlCBDYXJs b3MuDQoNCj4gSSBob3BlIHlvdSB3aWxsIGVsYWJvcmF0ZSBtb3JlIG9uIHRoZSB0aHJlYXQgbW9k ZWwgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo+IA0KPiBDaGVlcnMsDQo+IFRh bC4NCj4gDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCj4+IFNl bnQ6IFdlZG5lc2RheSwgSnVseSAyMCwgMjAxNiAxMTozNCBBTQ0KPj4gVG86IFRhbCBNaXpyYWhp DQo+PiBDYzogU2FzaGFuayBEYXJhIChzYWRhcmEpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25l KTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLQ0KPj4gb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzsg c2ZjQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6 IE1EIFR5cGUgYXR0YWNrIChXYXM6IFF1ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0 IGRyYWZ0KQ0KPj4gDQo+PiBUYWwsDQo+PiANCj4+PiBPbiBKdWwgMjAsIDIwMTYsIGF0IDY6MzAg QU0sIFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkg U2FzaGFuaywNCj4+PiANCj4+Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhl IGF0dGFja2VyIGNhbiBnZXQgYXdheSBieXBhc3NpbmcgYQ0KPj4gc2VydmljZSBmdW5jdGlvbi9u b2RlLg0KPj4+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9kZSBh bmQgaWYgUE9UIGRldGVybWluZXMgaXQgZGlkDQo+PiBub3QgYnlwYXNzIGlzIGEgdmFsaWQgYXR0 YWNrIG9uIHRoZSBzeXN0ZW0uDQo+Pj4gDQo+Pj4gSSB3b3VsZCBwaHJhc2UgaXQgdGhpcyB3YXk6 ICpHaXZlbiogYSBwYWNrZXQgdGhhdCBkaWQgbm90IGdvIHRocm91Z2ggaXRzDQo+PiBkZXNpcmVk IHBhdGgsIHRoZSBhdHRhY2tlciBjYW4gZWFzaWx5IG1ha2UgeW91IHRoaW5rIHRoYXQgaXQgKmRp ZCogZ28gdGhyb3VnaA0KPj4gdGhlIGRlc2lyZWQgcGF0aC4NCj4+PiBTb3VuZHMgbGlrZSBhIHZl cnkgc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0eS4NCj4+PiANCj4+PiBJZiBhIHBhY2tldCBkaWQg bm90IGdvIHRocm91Z2ggdGhlIGZpcmV3YWxsIChmb3Igb25lIHJlYXNvbiBvciBhbm90aGVyKSwg dGhlDQo+PiBhdHRhY2tlciB3aWxsIG1ha2UgeW91IHRoaW5rIHRoYXQgaXQgZGlkIGdvIHRocm91 Z2ggdGhlIGZpcmV3YWxsLg0KPj4+IA0KPj4gDQo+PiBMZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRs ZSDigJQgdGhlIOKAnHZ1bG5lcmFiaWxpdHnigJ0geW91IGFyZSBkZXNjcmliaW5nIGNvbWVzIHdp dGggdGhlDQo+PiBhc3N1bXB0aW9uIHRoYXQgYSBNSUlUIGF0dGFja2VyIGNhbiBpbnRlcmNlcHQg YSBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbQ0KPj4gdGhlIE1EIFR5cGUgMiwgZHJvcCB0aGUg cGFja2V0OyB0aGVuIGludGVyY2VwdCBhbm90aGVyIHBhY2tldCAod2l0aCB0aGUNCj4+IGtub3ds ZWRnZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQgcGF0aCwgc28gbWF5YmUgdGhlIGF0dGFja2Vy IGlzIHVzaW5nIGluYmFuZA0KPj4gT0FNIGFzIHdlbGwgOi0pLCBhbmQgaW5zZXJ0IChvciBtb2Rp ZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBvZiB0aGUgTUQNCj4+IFR5cGUgMiB3aXRoaW4g dGhlIGNvbnRlbnQgb2YgTlNILCB3aXRoaW4gYSBzcGVjaWZpYyBwYWNrZXQuDQo+PiANCj4+IFRo aXMgc291bmRzIHF1aXRlIHNvcGhpc3RpY2F0ZWQuDQo+PiANCj4+IERvIHlvdSB0aGluayB0aGF0 IGlmIGFuIE1JSVQgY2FuIGhhdmUgdGhhdCBzdXJmYWNlIG9mIGF0dGFjayBhbmQNCj4+IHNvcGhp c3RpY2F0aW9uLCB0aGV5IGNhbiBtZXNzIHVwIHdpdGggb3RoZXIgZXZlbiBtb3JlIGNyaXRpY2Fs IHRoaW5ncz8NCj4+IENoYW5naW5nIGEgVGVuYW50IElELCBtZXNzaW5nIHVwIHdpdGggUG9saWN5 IEdyb3VwcywgZXRjPw0KPj4gDQo+PiBNeSBwb2ludCBpcyB0aGF0IHdoYXQgeW91IHNlZW0gdG8g YmUgZGVzY3JpYmluZyBpcyBhIGdlbmVyaWMgdGhyZWF0IHVzZSBjYXNlDQo+PiBhbmQgbm90IGEg c3BlY2lmaWMgdnVsbmVyYWJpbGl0eS4gRW5naW5lZXJpbmcgaXMgYWJvdXQgdHJhZGUtb2ZmcyAo aS5lLiwgc29sdXRpb25zDQo+PiB0aGF0IGhhdmUgcHJhY3RpY2FsIHBlcmZvcm1hbmNlKSBhbmQg YWJvdXQgcGxhY2luZyB0aGUgc29sdXRpb24gaW4gdGhlIG1vc3QNCj4+IGVmZmVjdGl2ZSBwbGFj ZS4NCj4+IA0KPj4gSeKAmW0gbm90IGRlZmxlY3RpbmcgYnV0IGF0IHRoZSBzYW1lIHRpbWUsIGxl dOKAmXMgdW5kZXJzdGFuZCB0aGUgYXNzdW1wdGlvbnMgeW91DQo+PiBhcmUgbWFraW5nIGZvciB0 aGlzIHBvdGVudGlhbCBhdHRhY2sgeW91IGRlc2NyaWJlLCBhcyBwYXJ0IG9mIHRoZSB0aHJlYXQN Cj4+IGFuYWx5c2lzLg0KPj4gDQo+PiBUaGFua3MsDQo+PiANCj4+IOKAlCBDYXJsb3MuDQo+PiAN Cj4+PiBDaGVlcnMsDQo+Pj4gVGFsLg0KPj4+IA0KPj4+IA0KPj4+IEZyb206IFNhc2hhbmsgRGFy YSAoc2FkYXJhKSBbbWFpbHRvOnNhZGFyYUBjaXNjby5jb21dDQo+Pj4gU2VudDogV2VkbmVzZGF5 LCBKdWx5IDIwLCAyMDE2IDQ6MzEgQU0NCj4+PiBUbzogVGFsIE1penJhaGk7IEZyYW5rIEJyb2Nr bmVycyAoZmJyb2NrbmUpOyBkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+PiB0cmFuc2l0QHRv b2xzLmlldGYub3JnDQo+Pj4gQ2M6IHNmY0BpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnOyBudm8z QGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFF1ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBU cmFuc2l0IGRyYWZ0DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gVGhlIFBPVCByZXBsYWNlbWVudCBh dHRhY2sgKDEuKSBpcyBub3QgYW4gYXR0YWNrIG9uIHRoZSBpbnRlZ3JpdHkuIEl0IGlzIGFuDQo+ PiBhdHRhY2sgb24gdGhlIHBhdGggdmVyaWZpY2F0aW9uLg0KPj4+IFRoaXMgc2ltcGxlIGF0dGFj ayBjYW4gY2F1c2UgdGhlIHZlcmlmaWVyIHRvIGFjY2VwdCBhIHBhY2tldCB0aGF0IGRpZCBub3Qg Z28NCj4+IHRocm91Z2ggdGhlIGZpcmV3YWxsIFNGIChldmVuIHRob3VnaCBpdCBzaG91bGQpLiBJ IGJlbGlldmUgdGhpcyBpcyBleGFjdGx5IHRoZQ0KPj4gcHJvYmxlbSB5b3Ugd2VyZSBhaW1pbmcg dG8gYWRkcmVzcyBpbiB0aGlzIGRyYWZ0Lg0KPj4+IA0KPj4+IFtTRF0gVGhlIGF0dGFjayBpcyB2 YWxpZCBvbmx5IGlmIHRoZSBhdHRhY2tlciBjYW4gZ2V0IGF3YXkgYnlwYXNzaW5nIGEgc2Vydmlj ZQ0KPj4gZnVuY3Rpb24vbm9kZS4NCj4+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5 cGFzc2VzIGEgbm9kZSBhbmQgaWYgUE9UIGRldGVybWluZXMgaXQgZGlkDQo+PiBub3QgYnlwYXNz IGlzIGEgdmFsaWQgYXR0YWNrIG9uIHRoZSBzeXN0ZW0uDQo+Pj4gDQo+Pj4gSW4gdGhlIGN1cnJl bnQgc3RhdGUsIHRoZXJlIGlzIG5vIHdheSBhbiBhdHRhY2tlciBjYW4gZ2V0IGF3YXkgYXMgd2UN Cj4+IGRldGVybWluZSB0aGUgZXhhY3QgcGF0aCB0aGUgcGFja2V0IHRyYXZlbGxlZCAoYWltIG9m IHRoZSBkcmFmdCkgLg0KPj4+IEkgcmVpdGVyYXRlIHRoYXQgdGhlIHZlcmlmaWVyIG5lZWRzIHRv IGhhbmRsZSB3aGF0IHRvIGRvIHdpdGggdGhlIHBhdGgNCj4+IHJlY29uc3RydWN0ZWQgIQ0KPj4+ IFdlIGNvdWxkIGVtcGhhc2l6ZSB0aGlzIGluIG91ciBuZXh0IGRyYWZ0ICwgYnV0IGl0IHdvdWxk IGJlIGJleW9uZCBzY29wZSBvZg0KPj4gUE9UIHRvIGRldGVybWluZSB3aGF0IHRvIGRvIHdpdGgg dGhlIHBhdGggY29uc3RydWN0ZWQuDQo+Pj4gSU1PLCBJdCB3b3VsZCBiZSBoaWdobHkgYXBwbGlj YXRpb24gc3BlY2lmaWMuDQo+Pj4gDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiBTYXNoYW5rDQo+ Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IFRhbC4NCj4+PiANCj4+PiBGcm9tOiBG cmFuayBCcm9ja25lcnMgKGZicm9ja25lKSBbbWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbV0NCj4+ PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDY6MDAgUE0NCj4+PiBUbzogVGFsIE1penJh aGk7IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4g dHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0K Pj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZz4NCj4+PiBDYzogc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Ow0KPj4gb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+ Ow0KPj4gbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBS RTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+PiANCj4+PiBI aSBUYWwsDQo+Pj4gDQo+Pj4gdGhhbmtzIGZvciB0aGUgc3VtbWFyeS4gV2UnbGwgcHJvdmlkZSBt b3JlIGRldGFpbHMgb24gMi4gUGVyIG15IGVhcmxpZXINCj4+IHBvaW50IC0gMS4gaXMgYW4gaW50 ZXJlc3RpbmcgZGlzY3Vzc2lvbiwgZ2l2ZW4gdGhhdCB3ZSBkb24ndCBjbGFpbSB0byBwcm92aWRl DQo+PiBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3IgdGhlIHBhY2tldCBwYXlsb2FkLiBPciBpbiBv dGhlciB0ZXJtcyAtIHRvIGJlIGV4YWN0Og0KPj4gV2hhdCBQT1QgcHJvdmlkZXMgaXMgYSBwcm9v ZiB0aGF0IHRoZSBQT1QtaGVhZGVyL21ldGEtZGF0YSB0cmFuc2l0ZWQgYWxsIHRoZQ0KPj4gcmVx dWlyZWQgbm9kZXMuIFRoZXJlIGlzIG5vIGFzc29jaWF0aW9uIChhbmQgdGh1cyBwcm9vZikgcHJv dmlkZWQgZm9yIHRoZQ0KPj4gYWRkaXRpb25hbCBkYXRhIGNhcnJpZWQgYWxvbmcgd2l0aCB0aGUg UE9ULWhlYWRlciAtIG5laXRoZXIgaGVhZGVyIG5vcg0KPj4gcGF5bG9hZC4gQXMgYSBjb25zZXF1 ZW5jZSwgYXR0YWNrcyB3aGljaCBjaGFuZ2UgdGhlIHBhY2tldCBwYXlsb2FkIHdvbid0DQo+PiBi ZSBkZXRlY3RlZC9taXRpZ2F0ZWQuIFdlJ2xsIGV4cGxpY2l0bHkgc3RhdGUgdGhpcyBpbiB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4+IGluIHRoZSBuZXh0IHJldiBvZiB0aGUgZG9jdW1l bnQuDQo+Pj4gV2hhdCB3ZSBjb3VsZCBjb25zaWRlciBpcyBsaW5raW5nIHRoZSBSTkQgbnVtYmVy IHRvIENSQyBhY3Jvc3MgdGhlIHBhY2tldA0KPj4gcGF5bG9hZCBvciBzaW1pbGFyIC0gYnV0IHRo YXQgd2F5IHdlJ2QgcmVzdHJpY3QgdGhlIGFwcGxpY2FiaWxpdHkgdG8gZGVwbG95bWVudHMNCj4+ IHdoZXJlIHRoZSBwYWNrZXQgcGF5bG9hZCBpc24ndCBjaGFuZ2VkIGFjcm9zcyB0aGUgcGF0aCAo d2hpY2ggbWlnaHQgbm90DQo+PiBhcHBseSB0byBjZXJ0YWluIGRlcGxveW1lbnQgLSBlLmcuIFdB TiBvcHRpbWl6YXRpb24gLyBjb21wcmVzc2lvbiBzY2hlbWVzKS4NCj4+PiBEbyB5b3UgdGhpbmsg aXQgaXMgd29ydGh3aGlsZSB0byBwcm92aWRlIGEgc29sdXRpb24gZm9yIGEgZGVwbG95bWVudCB3 aGljaCBpcw0KPj4gZXhwZWN0ZWQgdG8gbm90IGFsdGVyIHRoZSBwYWNrZXQgcGF5bG9hZD8NCj4+ PiANCj4+PiBUaGFua3MsDQo+Pj4gRnJhbmsNCj4+PiANCj4+PiBGcm9tOiBUYWwgTWl6cmFoaSBb bWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tXQ0KPj4+IFNlbnQ6IERpZW5zdGFnLCAxOS4gSnVsaSAy MDE2IDE3OjQ0DQo+Pj4gVG86IFNhc2hhbmsgRGFyYSAoc2FkYXJhKQ0KPj4gPHNhZGFyYUBjaXNj by5jb208bWFpbHRvOnNhZGFyYUBjaXNjby5jb20+PjsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tu ZSkNCj4+IDxmYnJvY2tuZUBjaXNjby5jb208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+OyBk cmFmdC1icm9ja25lcnMtDQo+PiBwcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPg0K Pj4+IENjOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+PiBvcHNhd2dAaWV0 Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47DQo+PiBudm8zQGlldGYub3JnPG1haWx0bzpu dm8zQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJFOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Yg b2YgVHJhbnNpdCBkcmFmdA0KPj4+IA0KPj4+IEhpLA0KPj4+IA0KPj4+IFRvIHN1bW1hcml6ZSBt eSB0YWtlIG9uIHRoaXMgdGhyZWFkOg0KPj4+IFRoZSBwcm9wb3NlZCBtZWNoYW5pc20gaGFzIHR3 byBzaWduaWZpY2FudCB2dWxuZXJhYmlsaXRpZXMgdGhhdCAoaW4gbXkNCj4+IHVuZGVyc3RhbmRp bmcpIGFyZSBjdXJyZW50bHkgbm90IGFkZHJlc3NlZDoNCj4+PiANCj4+PiAxLiAgICAgICBBIG1h bi1pbi10aGUtbWlkZGxlIGNhbiByZXBsYWNlIHRoZSBQT1Qgb2YgcGFja2V0IEEgd2l0aCB0aGUg UE9UIG9mDQo+PiBwYWNrZXQgQi4NCj4+PiANCj4+PiAyLiAgICAgICBJdCBpcyBwb3NzaWJsZSB0 byByZXBsYXkgUE9UcyB3aXRoaW4gYSBjZXJ0YWluIHRpbWUgd2luZG93LCB3aG9zZQ0KPj4gbGVu Z3RoIGlzIGRldGVybWluZWQgYnkgdGhlIHRpbWVzdGFtcCByZXNvbHV0aW9uLg0KPj4+IA0KPj4+ IFNhc2hhbmssIHRoYW5rcyBmb3IgYWdyZWVpbmcgdG8gbG9vayBpbnRvIGl0IGZ1cnRoZXIuIEkg YW0gbG9va2luZyBmb3J3YXJkIHRvDQo+PiB5b3VyIGluc2lnaHRzIG9uIHRoaXMuDQo+Pj4gDQo+ Pj4gUmVnYXJkcywNCj4+PiBUYWwuDQo+Pj4gDQo+Pj4gTGluayB0byB0aGUgZHJhZnQ6IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+PiB0cmFu c2l0LTAxDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gRnJvbTogU2FzaGFuayBEYXJhIChzYWRhcmEp IFttYWlsdG86c2FkYXJhQGNpc2NvLmNvbV0NCj4+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAy MDE2IDEyOjIwIFBNDQo+Pj4gVG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9j a25lKTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4gdHJhbnNpdEB0b29scy5pZXRmLm9y ZzxtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4gdHJhbnNpdEB0b29scy5pZXRm Lm9yZz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJl OiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4+IA0KPj4+IA0K Pj4+IA0KPj4+IEkgd2FudCB0byBhc2sgYSBzaW1wbGUgcXVlc3Rpb246DQo+Pj4gSWYgdGhlIGF0 dGFja2VyIGF0dGFjaGVzIHRoZSBQT1Qgb2YgcGFja2V0IEEgKGluZGljYXRpbmcgdGhlIHBhdGgg dGhyb3VnaA0KPj4gMSwzLDUsNikgdG8gcGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2Vw dCBwYWNrZXQgQiBhbmQgYmVsaWV2ZSB0aGF0IGl0cyBwYXRoDQo+PiB3YXMgaW5kZWVkICgxLDMs NSw2KT8NCj4+PiANCj4+PiBbU0RdIElmIHRoZSB2ZXJpZmllciBpcyBwcm9ncmFtbWVkIHRvIGp1 c3QgdmFsaWRhdGUgdGhlIFBPVCBtZXRhIGRhdGEgYWdhaW5zdA0KPj4gezEsMyw1LDZ9IHRoZW4g eWVzIGl0IGFjY2VwdHMgaXQuDQo+Pj4gSWYgdGhlIHZlcmlmaWVyIGlzIHByb2dyYW1tZWQgdG8g Y29uc3VsdCBhIHBvbGljeSBkYXRhYmFzZSB0byBjcm9zcyBjaGVjayBpZg0KPj4gdGhlIHJlY29u c3RydWN0ZWQgcGF0aCB7MSwzLDUsNn0gaXMgYXMgcGVyIHRoZSBwb2xpY2llcyB0aGVuIG5vICwg aXQgZHJvcHMgaXQgLg0KPj4+IA0KPj4+IEJ1dCBJIHNlZSB5b3VyIHBvaW50ICwgdGhhdCB0aGUg cGFyYW1ldGVycyB1c2VkIGluIFBPVCBkYXRhIGRvbm90IGNvbnNpZGVyDQo+PiB0aGUgcGF0aCBv ciBub2RlLWlkcyBldGMgLiBXZSBzaGFsbCBkaXNjdXNzIHRoaXMgaW50ZXJuYWxseSBhbmQgZ2V0 IGJhY2suDQo+Pj4gDQo+Pj4gQWxzbywgV2Ugc2hhbGwgZ2V0IGJhY2sgd2l0aCBtb3JlIGNvbmNy ZXRlIG51bWJlcnMgb2YgdGhlIHRpbWVzdGFtcA0KPj4gcmVzb2x1dGlvbiBhbmQgY2FjaGUgc2l6 ZXMgKG9yIG90aGVyIGJldHRlciBhcHByb2FjaGVzKS4NCj4+PiANCj4+PiBUaGFuayB5b3Ugc28g bXVjaCBmb3IgYWxsIHRoZSBpbnB1dHMuDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gRnJvbTogVGFs IE1penJhaGkNCj4+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDEwOjI4IEFNDQo+Pj4g VG86ICdTYXNoYW5rIERhcmEgKHNhZGFyYSknOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsg ZHJhZnQtYnJvY2tuZXJzLQ0KPj4gcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZz47 IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJFOiBRdWVz dGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4+IA0KPj4+IERlYXIgU2Fz aGFuaywNCj4+PiANCj4+PiBJIHJlYWxseSBhcHByZWNpYXRlIHRoZSBxdWljayBhbmQgZGV0YWls ZWQgcmVzcG9uc2VzLg0KPj4+IA0KPj4+Pj4+IExldHMgdGFrZSBjb3JyZWN0IHBhdGggdGFrZW4g YnkgUGFja2V0IEEgIHRvIGJlIFBhdGgxIC0gKCAxLDMsNSw2KSBub2Rlcw0KPiANCg0K From nobody Wed Jul 20 03:10: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 3298612DB18; Wed, 20 Jul 2016 03:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OObqAU8NdCy7; Wed, 20 Jul 2016 03:09:53 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E25712DACD; Wed, 20 Jul 2016 03:09:53 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u6KA0JIj028380; Wed, 20 Jul 2016 03:09:52 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 24a2c397fv-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Jul 2016 03:09:52 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jul 2016 13:09:48 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Wed, 20 Jul 2016 13:09:48 +0300 From: Tal Mizrahi To: "Carlos Pignataro (cpignata)" Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnUR6x6RUowp0WBJweV5BhC9aAhDzig///SIICAADQk4A== Date: Wed, 20 Jul 2016 10:09:47 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> <16454292-3ADD-402A-AED6-CB785C5C833B@cisco.com> In-Reply-To: <16454292-3ADD-402A-AED6-CB785C5C833B@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: [199.203.130.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_06:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200117 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [sfc] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 10:09:56 -0000 SGkgQ2FybG9zLA0KDQpJdCBhbGwgZ29lcyBiYWNrIHRvIHRoZSB0aHJlYXQgbW9kZWw7IHdoaWNo IHRocmVhdHMgeW91IHdhbnQgdG8gYWRkcmVzcywgYW5kIHdoaWNoIG9uZXMgeW91IGRvbid0Lg0K DQpUaGUgd2F5IEkgc2VlIGl0LCByb3VnaGx5IHNwZWFraW5nIHRoZXJlIGFyZSAzIGNsYXNzZXMg b2YgdGhyZWF0cyAodGhlcmUgYWUgcHJvYmFibHkgb3RoZXIgdGhyZWF0cywgYnV0IHRoZXNlIGFy ZSB0aGUgYmFzaWMgb25lcyk6DQotIE1pc3JvdXRlIC8gbWlzY29uZmlndXJhdGlvbiAobm90IGEg c2VjdXJpdHkgYXR0YWNrKS4NCi0gQXR0YWNrZXIgd2l0aCBubyBvbi1wYXRoIGFjY2Vzcy4NCi0g TWFuLWluLXRoZS1taWRkbGUgKGF0dGFja2VyICp3aXRoKiBvbi1wYXRoIGFjY2VzcykuDQoNCkl0 IGxvb2tzIGxpa2UgdGhlIHRoaXJkIHRocmVhdCAobWFuLWluLXRoZS1taWRkbGUpIGlzIGN1cnJl bnRseSBub3QgYWRkcmVzc2VkIGJ5IFBPVC4NCkkgY2VydGFpbmx5IGFncmVlIHRoYXQgdGhpcyB0 aHJlYXQgaXMgdGhlIG1vcmUgZGlmZmljdWx0IHRvIGltcGxlbWVudCBvZiB0aGUgdGhyZWUuDQoN Ckl0IHdvdWxkIHNpZ25pZmljYW50bHkgY2xhcmlmeSB0aGUgcGljdHVyZSBpZiB5b3Ugc3BlY2lm aWVkIGluIHRoZSBkcmFmdCB3aGljaCBvZiB0aGUgdGhyZWUgY2xhc3NlcyB5b3UgaW50ZW5kIHRv IGFkZHJlc3MuDQoNClRoYW5rcywNClRhbC4NCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBj aXNjby5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBKdWx5IDIwLCAyMDE2IDExOjUxIEFNDQo+VG86 IFRhbCBNaXpyYWhpDQo+Q2M6IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgRnJhbmsgQnJvY2tuZXJz IChmYnJvY2tuZSk7IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi0NCj5vZi10cmFuc2l0QHRvb2xzLmll dGYub3JnOyBzZmNAaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZw0KPlN1 YmplY3Q6IFJlOiBNRCBUeXBlIGF0dGFjayAoV2FzOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Yg b2YgVHJhbnNpdCBkcmFmdCkNCj4NCj5IaSwgVGFsLA0KPg0KPj4gT24gSnVsIDIwLCAyMDE2LCBh dCAxMTo0MiBBTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29tPiB3cm90ZToNCj4+DQo+ PiBIaSBDYXJsb3MsDQo+Pg0KPj4NCj4+PiBMZXTigJlzIHN0ZXAgYmFjayBhIGxpdHRsZSDigJQg dGhlIOKAnHZ1bG5lcmFiaWxpdHnigJ0geW91IGFyZSBkZXNjcmliaW5nDQo+Pj4gY29tZXMgd2l0 aCB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgTUlJVCBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IGENCj4+ PiBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbSB0aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNr ZXQ7IHRoZW4NCj4+PiBpbnRlcmNlcHQgYW5vdGhlciBwYWNrZXQgKHdpdGggdGhlIGtub3dsZWRn ZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQNCj4+PiBwYXRoLCBzbyBtYXliZSB0aGUgYXR0YWNr ZXIgaXMgdXNpbmcgaW5iYW5kIE9BTSBhcyB3ZWxsIDotKSwgYW5kDQo+Pj4gaW5zZXJ0IChvciBt b2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBvZiB0aGUgTUQgVHlwZSAyIHdpdGhpbiB0 aGUNCj5jb250ZW50IG9mIE5TSCwgd2l0aGluIGEgc3BlY2lmaWMgcGFja2V0Lg0KPj4+DQo+Pj4g VGhpcyBzb3VuZHMgcXVpdGUgc29waGlzdGljYXRlZC4NCj4+DQo+PiBJIGFtIG5vdCBzdXJlIEkg YWdyZWUgdGhpcyBpcyBhICdzb3BoaXN0aWNhdGVkJyBhdHRhY2suDQo+PiBUaGUgYXR0YWNrIGRv ZXMgbm90IHJlcXVpcmUgYW55IGNyeXB0b2dyYXBoaWMgb3IgYWxnb3JpdGhtaWMgZnVuY3Rpb25h bGl0eSwNCj5hbmQgdG8gdGhhdCBlbmQgaXQgaXMgdmVyeSBsaWdodHdlaWdodCBpbiB0ZXJtcyBv ZiBwcm9jZXNzaW5nIHJlc291cmNlcy4NCj4NCj5Tb3JyeSBpZiBJIHdhcyBub3QgY2xlYXIg4oCU IEkgZG8gbm90IG1lYW4gdGVjaG5vbG9naWNhbCBzb3BoaXN0aWNhdGlvbiBvcg0KPm1hc3NpdmUg cHJvY2Vzc2luZyByZXNvdXJjZXMgcmVxdWlyZWQuIEkgbWVhbiBhY2Nlc3MgYW5kIG9wZXJhdGlv bmFsIG9uZS4NCj4NCj4+DQo+PiBJZiB0aGlzIGtpbmQgb2YgYXR0YWNrIGlzIG5vdCB3aXRoaW4g dGhlIHNjb3BlIGhlcmUsIHRoZW4gSSB3b3VsZCBhcmd1ZSB0aGF0DQo+eW91IGRvbid0IG5lZWQg YSBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBhdCBhbGwuIEFsbCB5b3UgbmVlZCBpcyBhIFRMViB0 aGF0DQo+c3BlY2lmaWVzIHRoZSBsaXN0IG9mIG5vZGVzLiBIb3dldmVyLCBJIGJlbGlldmUgdGhh dCB5b3UgZGlkIHdhbnQgdG8gdHJ5IHRvDQo+bWl0aWdhdGUgTUlUTSBhdHRhY2tlcnMuIENvcnJl Y3QgbWUgaWYgSSBhbSB3cm9uZy4NCj4+DQo+DQo+WW91IHNlZW0gdG8gaGF2ZSBtaXNzZWQgcXVv dGluZyB0aGUgaW1wb3J0YW50IHBhcnQgb2YgbXkgcmVzcG9uc2U6ICJNeQ0KPnBvaW50IGlzIHRo YXQgd2hhdCB5b3Ugc2VlbSB0byBiZSBkZXNjcmliaW5nIGlzIGEgZ2VuZXJpYyB0aHJlYXQgdXNl IGNhc2UgYW5kDQo+bm90IGEgc3BlY2lmaWMgdnVsbmVyYWJpbGl0eS7igJ0NCj4NCj5TZWxlY3Rp dmVseSBkcm9wcGluZyBwYXJ0IG9mIHRoZSByZXNwb25zZSByZW1vdmVzIGltcG9ydGFudCBjb250 ZXh0Lg0KPg0KPj4gSSBmdWxseSBhZ3JlZSB0aGF0IHRoZSB0aHJlYXQgbW9kZWwgbmVlZHMgdG8g YmUgd2VsbC1kZWZpbmVkLg0KPg0KPlRoZSB0aHJlYXQgbW9kZWwgZm9yIFNGQyBNRCwgeWVzLiBB Y2Nlc3MgdG8gdGhlIFBPVCBjb21lcyB3aXRoDQo+YXNzdW1wdGlvbnMuDQo+DQo+VGhhbmtzLA0K Pg0KPuKAlCBDYXJsb3MuDQo+DQo+PiBJIGhvcGUgeW91IHdpbGwgZWxhYm9yYXRlIG1vcmUgb24g dGhlIHRocmVhdCBtb2RlbCBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mDQo+dGhlIGRyYWZ0Lg0KPj4N Cj4+IENoZWVycywNCj4+IFRhbC4NCj4+DQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4gRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25h dGFAY2lzY28uY29tXQ0KPj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMCwgMjAxNiAxMTozNCBB TQ0KPj4+IFRvOiBUYWwgTWl6cmFoaQ0KPj4+IENjOiBTYXNoYW5rIERhcmEgKHNhZGFyYSk7IEZy YW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpOw0KPj4+IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi0gb2Yt dHJhbnNpdEB0b29scy5pZXRmLm9yZzsgc2ZjQGlldGYub3JnOw0KPj4+IG9wc2F3Z0BpZXRmLm9y ZzsgbnZvM0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IE1EIFR5cGUgYXR0YWNrIChXYXM6IFF1ZXN0 aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0DQo+Pj4gZHJhZnQpDQo+Pj4NCj4+PiBUYWws DQo+Pj4NCj4+Pj4gT24gSnVsIDIwLCAyMDE2LCBhdCA2OjMwIEFNLCBUYWwgTWl6cmFoaSA8dGFs bWlAbWFydmVsbC5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+PiBIaSBTYXNoYW5rLA0KPj4+Pg0KPj4+ Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhlIGF0dGFja2VyIGNhbiBnZXQg YXdheQ0KPj4+Pj4gYnlwYXNzaW5nIGENCj4+PiBzZXJ2aWNlIGZ1bmN0aW9uL25vZGUuDQo+Pj4+ PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9kZSBhbmQgaWYgUE9U IGRldGVybWluZXMNCj4+Pj4+IGl0IGRpZA0KPj4+IG5vdCBieXBhc3MgaXMgYSB2YWxpZCBhdHRh Y2sgb24gdGhlIHN5c3RlbS4NCj4+Pj4NCj4+Pj4gSSB3b3VsZCBwaHJhc2UgaXQgdGhpcyB3YXk6 ICpHaXZlbiogYSBwYWNrZXQgdGhhdCBkaWQgbm90IGdvIHRocm91Z2gNCj4+Pj4gaXRzDQo+Pj4g ZGVzaXJlZCBwYXRoLCB0aGUgYXR0YWNrZXIgY2FuIGVhc2lseSBtYWtlIHlvdSB0aGluayB0aGF0 IGl0ICpkaWQqIGdvDQo+Pj4gdGhyb3VnaCB0aGUgZGVzaXJlZCBwYXRoLg0KPj4+PiBTb3VuZHMg bGlrZSBhIHZlcnkgc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0eS4NCj4+Pj4NCj4+Pj4gSWYgYSBw YWNrZXQgZGlkIG5vdCBnbyB0aHJvdWdoIHRoZSBmaXJld2FsbCAoZm9yIG9uZSByZWFzb24gb3IN Cj4+Pj4gYW5vdGhlciksIHRoZQ0KPj4+IGF0dGFja2VyIHdpbGwgbWFrZSB5b3UgdGhpbmsgdGhh dCBpdCBkaWQgZ28gdGhyb3VnaCB0aGUgZmlyZXdhbGwuDQo+Pj4+DQo+Pj4NCj4+PiBMZXTigJlz IHN0ZXAgYmFjayBhIGxpdHRsZSDigJQgdGhlIOKAnHZ1bG5lcmFiaWxpdHnigJ0geW91IGFyZSBk ZXNjcmliaW5nDQo+Pj4gY29tZXMgd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgTUlJVCBhdHRh Y2tlciBjYW4gaW50ZXJjZXB0IGENCj4+PiBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbSB0aGUg TUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNrZXQ7IHRoZW4NCj4+PiBpbnRlcmNlcHQgYW5vdGhlciBw YWNrZXQgKHdpdGggdGhlIGtub3dsZWRnZSB0aGF0IGl0IHRvb2sgYSBkaWZmZXJlbnQNCj4+PiBw YXRoLCBzbyBtYXliZSB0aGUgYXR0YWNrZXIgaXMgdXNpbmcgaW5iYW5kIE9BTSBhcyB3ZWxsIDot KSwgYW5kDQo+Pj4gaW5zZXJ0IChvciBtb2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBv ZiB0aGUgTUQgVHlwZSAyIHdpdGhpbiB0aGUNCj5jb250ZW50IG9mIE5TSCwgd2l0aGluIGEgc3Bl Y2lmaWMgcGFja2V0Lg0KPj4+DQo+Pj4gVGhpcyBzb3VuZHMgcXVpdGUgc29waGlzdGljYXRlZC4N Cj4+Pg0KPj4+IERvIHlvdSB0aGluayB0aGF0IGlmIGFuIE1JSVQgY2FuIGhhdmUgdGhhdCBzdXJm YWNlIG9mIGF0dGFjayBhbmQNCj4+PiBzb3BoaXN0aWNhdGlvbiwgdGhleSBjYW4gbWVzcyB1cCB3 aXRoIG90aGVyIGV2ZW4gbW9yZSBjcml0aWNhbCB0aGluZ3M/DQo+Pj4gQ2hhbmdpbmcgYSBUZW5h bnQgSUQsIG1lc3NpbmcgdXAgd2l0aCBQb2xpY3kgR3JvdXBzLCBldGM/DQo+Pj4NCj4+PiBNeSBw b2ludCBpcyB0aGF0IHdoYXQgeW91IHNlZW0gdG8gYmUgZGVzY3JpYmluZyBpcyBhIGdlbmVyaWMg dGhyZWF0DQo+Pj4gdXNlIGNhc2UgYW5kIG5vdCBhIHNwZWNpZmljIHZ1bG5lcmFiaWxpdHkuIEVu Z2luZWVyaW5nIGlzIGFib3V0DQo+Pj4gdHJhZGUtb2ZmcyAoaS5lLiwgc29sdXRpb25zIHRoYXQg aGF2ZSBwcmFjdGljYWwgcGVyZm9ybWFuY2UpIGFuZA0KPj4+IGFib3V0IHBsYWNpbmcgdGhlIHNv bHV0aW9uIGluIHRoZSBtb3N0IGVmZmVjdGl2ZSBwbGFjZS4NCj4+Pg0KPj4+IEnigJltIG5vdCBk ZWZsZWN0aW5nIGJ1dCBhdCB0aGUgc2FtZSB0aW1lLCBsZXTigJlzIHVuZGVyc3RhbmQgdGhlDQo+ Pj4gYXNzdW1wdGlvbnMgeW91IGFyZSBtYWtpbmcgZm9yIHRoaXMgcG90ZW50aWFsIGF0dGFjayB5 b3UgZGVzY3JpYmUsIGFzDQo+Pj4gcGFydCBvZiB0aGUgdGhyZWF0IGFuYWx5c2lzLg0KPj4+DQo+ Pj4gVGhhbmtzLA0KPj4+DQo+Pj4g4oCUIENhcmxvcy4NCj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+ IFRhbC4NCj4+Pj4NCj4+Pj4NCj4+Pj4gRnJvbTogU2FzaGFuayBEYXJhIChzYWRhcmEpIFttYWls dG86c2FkYXJhQGNpc2NvLmNvbV0NCj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDIwLCAyMDE2 IDQ6MzEgQU0NCj4+Pj4gVG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25l KTsNCj4+Pj4gZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+IHRyYW5zaXRAdG9vbHMuaWV0 Zi5vcmcNCj4+Pj4gQ2M6IHNmY0BpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnOyBudm8zQGlldGYu b3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNp dCBkcmFmdA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGUgUE9UIHJlcGxhY2VtZW50IGF0dGFj ayAoMS4pIGlzIG5vdCBhbiBhdHRhY2sgb24gdGhlIGludGVncml0eS4NCj4+Pj4gSXQgaXMgYW4N Cj4+PiBhdHRhY2sgb24gdGhlIHBhdGggdmVyaWZpY2F0aW9uLg0KPj4+PiBUaGlzIHNpbXBsZSBh dHRhY2sgY2FuIGNhdXNlIHRoZSB2ZXJpZmllciB0byBhY2NlcHQgYSBwYWNrZXQgdGhhdA0KPj4+ PiBkaWQgbm90IGdvDQo+Pj4gdGhyb3VnaCB0aGUgZmlyZXdhbGwgU0YgKGV2ZW4gdGhvdWdoIGl0 IHNob3VsZCkuIEkgYmVsaWV2ZSB0aGlzIGlzDQo+Pj4gZXhhY3RseSB0aGUgcHJvYmxlbSB5b3Ug d2VyZSBhaW1pbmcgdG8gYWRkcmVzcyBpbiB0aGlzIGRyYWZ0Lg0KPj4+Pg0KPj4+PiBbU0RdIFRo ZSBhdHRhY2sgaXMgdmFsaWQgb25seSBpZiB0aGUgYXR0YWNrZXIgY2FuIGdldCBhd2F5IGJ5cGFz c2luZw0KPj4+PiBhIHNlcnZpY2UNCj4+PiBmdW5jdGlvbi9ub2RlLg0KPj4+PiBGb3IgZXhhbXBs ZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9kZSBhbmQgaWYgUE9UIGRldGVybWluZXMN Cj4+Pj4gaXQgZGlkDQo+Pj4gbm90IGJ5cGFzcyBpcyBhIHZhbGlkIGF0dGFjayBvbiB0aGUgc3lz dGVtLg0KPj4+Pg0KPj4+PiBJbiB0aGUgY3VycmVudCBzdGF0ZSwgdGhlcmUgaXMgbm8gd2F5IGFu IGF0dGFja2VyIGNhbiBnZXQgYXdheSBhcyB3ZQ0KPj4+IGRldGVybWluZSB0aGUgZXhhY3QgcGF0 aCB0aGUgcGFja2V0IHRyYXZlbGxlZCAoYWltIG9mIHRoZSBkcmFmdCkgLg0KPj4+PiBJIHJlaXRl cmF0ZSB0aGF0IHRoZSB2ZXJpZmllciBuZWVkcyB0byBoYW5kbGUgd2hhdCB0byBkbyB3aXRoIHRo ZQ0KPj4+PiBwYXRoDQo+Pj4gcmVjb25zdHJ1Y3RlZCAhDQo+Pj4+IFdlIGNvdWxkIGVtcGhhc2l6 ZSB0aGlzIGluIG91ciBuZXh0IGRyYWZ0ICwgYnV0IGl0IHdvdWxkIGJlIGJleW9uZA0KPj4+PiBz Y29wZSBvZg0KPj4+IFBPVCB0byBkZXRlcm1pbmUgd2hhdCB0byBkbyB3aXRoIHRoZSBwYXRoIGNv bnN0cnVjdGVkLg0KPj4+PiBJTU8sIEl0IHdvdWxkIGJlIGhpZ2hseSBhcHBsaWNhdGlvbiBzcGVj aWZpYy4NCj4+Pj4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gU2FzaGFuaw0KPj4+Pg0KPj4+ Pg0KPj4+Pg0KPj4+PiBUaGFua3MsDQo+Pj4+IFRhbC4NCj4+Pj4NCj4+Pj4gRnJvbTogRnJhbmsg QnJvY2tuZXJzIChmYnJvY2tuZSkgW21haWx0bzpmYnJvY2tuZUBjaXNjby5jb21dDQo+Pj4+IFNl bnQ6IFR1ZXNkYXksIEp1bHkgMTksIDIwMTYgNjowMCBQTQ0KPj4+PiBUbzogVGFsIE1penJhaGk7 IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+IHRy YW5zaXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi0NCj4+ PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPg0KPj4+PiBDYzogc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Ow0KPj4+IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3Jn PjsNCj4+PiBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPj4+PiBTdWJqZWN0 OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+Pj4NCj4+ Pj4gSGkgVGFsLA0KPj4+Pg0KPj4+PiB0aGFua3MgZm9yIHRoZSBzdW1tYXJ5LiBXZSdsbCBwcm92 aWRlIG1vcmUgZGV0YWlscyBvbiAyLiBQZXIgbXkNCj4+Pj4gZWFybGllcg0KPj4+IHBvaW50IC0g MS4gaXMgYW4gaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiwgZ2l2ZW4gdGhhdCB3ZSBkb24ndCBjbGFp bSB0bw0KPj4+IHByb3ZpZGUgaW50ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHRoZSBwYWNrZXQgcGF5 bG9hZC4gT3IgaW4gb3RoZXIgdGVybXMgLSB0bw0KPmJlIGV4YWN0Og0KPj4+IFdoYXQgUE9UIHBy b3ZpZGVzIGlzIGEgcHJvb2YgdGhhdCB0aGUgUE9ULWhlYWRlci9tZXRhLWRhdGEgdHJhbnNpdGVk DQo+Pj4gYWxsIHRoZSByZXF1aXJlZCBub2Rlcy4gVGhlcmUgaXMgbm8gYXNzb2NpYXRpb24gKGFu ZCB0aHVzIHByb29mKQ0KPj4+IHByb3ZpZGVkIGZvciB0aGUgYWRkaXRpb25hbCBkYXRhIGNhcnJp ZWQgYWxvbmcgd2l0aCB0aGUgUE9ULWhlYWRlciAtDQo+Pj4gbmVpdGhlciBoZWFkZXIgbm9yIHBh eWxvYWQuIEFzIGEgY29uc2VxdWVuY2UsIGF0dGFja3Mgd2hpY2ggY2hhbmdlDQo+Pj4gdGhlIHBh Y2tldCBwYXlsb2FkIHdvbid0IGJlIGRldGVjdGVkL21pdGlnYXRlZC4gV2UnbGwgZXhwbGljaXRs eQ0KPj4+IHN0YXRlIHRoaXMgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIHRoZSBu ZXh0IHJldiBvZiB0aGUgZG9jdW1lbnQuDQo+Pj4+IFdoYXQgd2UgY291bGQgY29uc2lkZXIgaXMg bGlua2luZyB0aGUgUk5EIG51bWJlciB0byBDUkMgYWNyb3NzIHRoZQ0KPj4+PiBwYWNrZXQNCj4+ PiBwYXlsb2FkIG9yIHNpbWlsYXIgLSBidXQgdGhhdCB3YXkgd2UnZCByZXN0cmljdCB0aGUgYXBw bGljYWJpbGl0eSB0bw0KPj4+IGRlcGxveW1lbnRzIHdoZXJlIHRoZSBwYWNrZXQgcGF5bG9hZCBp c24ndCBjaGFuZ2VkIGFjcm9zcyB0aGUgcGF0aA0KPj4+ICh3aGljaCBtaWdodCBub3QgYXBwbHkg dG8gY2VydGFpbiBkZXBsb3ltZW50IC0gZS5nLiBXQU4gb3B0aW1pemF0aW9uIC8NCj5jb21wcmVz c2lvbiBzY2hlbWVzKS4NCj4+Pj4gRG8geW91IHRoaW5rIGl0IGlzIHdvcnRod2hpbGUgdG8gcHJv dmlkZSBhIHNvbHV0aW9uIGZvciBhIGRlcGxveW1lbnQNCj4+Pj4gd2hpY2ggaXMNCj4+PiBleHBl Y3RlZCB0byBub3QgYWx0ZXIgdGhlIHBhY2tldCBwYXlsb2FkPw0KPj4+Pg0KPj4+PiBUaGFua3Ms DQo+Pj4+IEZyYW5rDQo+Pj4+DQo+Pj4+IEZyb206IFRhbCBNaXpyYWhpIFttYWlsdG86dGFsbWlA bWFydmVsbC5jb21dDQo+Pj4+IFNlbnQ6IERpZW5zdGFnLCAxOS4gSnVsaSAyMDE2IDE3OjQ0DQo+ Pj4+IFRvOiBTYXNoYW5rIERhcmEgKHNhZGFyYSkNCj4+PiA8c2FkYXJhQGNpc2NvLmNvbTxtYWls dG86c2FkYXJhQGNpc2NvLmNvbT4+OyBGcmFuayBCcm9ja25lcnMNCj4+PiAoZmJyb2NrbmUpIDxm YnJvY2tuZUBjaXNjby5jb208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+Ow0KPj4+IGRyYWZ0 LWJyb2NrbmVycy0NCj4+PiBwcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtDQo+Pj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZz4NCj4+ Pj4gQ2M6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsNCj4+PiBvcHNhd2dAaWV0 Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47DQo+Pj4gbnZvM0BpZXRmLm9yZzxtYWlsdG86 bnZvM0BpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUkU6IFF1ZXN0aW9uIHJlZ2FyZGluZyBQcm9v ZiBvZiBUcmFuc2l0IGRyYWZ0DQo+Pj4+DQo+Pj4+IEhpLA0KPj4+Pg0KPj4+PiBUbyBzdW1tYXJp emUgbXkgdGFrZSBvbiB0aGlzIHRocmVhZDoNCj4+Pj4gVGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBo YXMgdHdvIHNpZ25pZmljYW50IHZ1bG5lcmFiaWxpdGllcyB0aGF0IChpbg0KPj4+PiBteQ0KPj4+ IHVuZGVyc3RhbmRpbmcpIGFyZSBjdXJyZW50bHkgbm90IGFkZHJlc3NlZDoNCj4+Pj4NCj4+Pj4g MS4gICAgICAgQSBtYW4taW4tdGhlLW1pZGRsZSBjYW4gcmVwbGFjZSB0aGUgUE9UIG9mIHBhY2tl dCBBIHdpdGggdGhlIFBPVA0KPm9mDQo+Pj4gcGFja2V0IEIuDQo+Pj4+DQo+Pj4+IDIuICAgICAg IEl0IGlzIHBvc3NpYmxlIHRvIHJlcGxheSBQT1RzIHdpdGhpbiBhIGNlcnRhaW4gdGltZSB3aW5k b3csIHdob3NlDQo+Pj4gbGVuZ3RoIGlzIGRldGVybWluZWQgYnkgdGhlIHRpbWVzdGFtcCByZXNv bHV0aW9uLg0KPj4+Pg0KPj4+PiBTYXNoYW5rLCB0aGFua3MgZm9yIGFncmVlaW5nIHRvIGxvb2sg aW50byBpdCBmdXJ0aGVyLiBJIGFtIGxvb2tpbmcNCj4+Pj4gZm9yd2FyZCB0bw0KPj4+IHlvdXIg aW5zaWdodHMgb24gdGhpcy4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gVGFsLg0KPj4+Pg0K Pj4+PiBMaW5rIHRvIHRoZSBkcmFmdDoNCj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi0NCj4+PiB0cmFuc2l0LTAxDQo+Pj4+DQo+Pj4+DQo+ Pj4+DQo+Pj4+IEZyb206IFNhc2hhbmsgRGFyYSAoc2FkYXJhKSBbbWFpbHRvOnNhZGFyYUBjaXNj by5jb21dDQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTksIDIwMTYgMTI6MjAgUE0NCj4+Pj4g VG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsNCj4+Pj4gZHJhZnQt YnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+IHRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWJyb2NrbmVycy1wcm9vZi1vZi0NCj4+PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPjsgc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlv biByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+ PiBJIHdhbnQgdG8gYXNrIGEgc2ltcGxlIHF1ZXN0aW9uOg0KPj4+PiBJZiB0aGUgYXR0YWNrZXIg YXR0YWNoZXMgdGhlIFBPVCBvZiBwYWNrZXQgQSAoaW5kaWNhdGluZyB0aGUgcGF0aA0KPj4+PiB0 aHJvdWdoDQo+Pj4gMSwzLDUsNikgdG8gcGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2Vw dCBwYWNrZXQgQiBhbmQgYmVsaWV2ZQ0KPj4+IHRoYXQgaXRzIHBhdGggd2FzIGluZGVlZCAoMSwz LDUsNik/DQo+Pj4+DQo+Pj4+IFtTRF0gSWYgdGhlIHZlcmlmaWVyIGlzIHByb2dyYW1tZWQgdG8g anVzdCB2YWxpZGF0ZSB0aGUgUE9UIG1ldGENCj4+Pj4gZGF0YSBhZ2FpbnN0DQo+Pj4gezEsMyw1 LDZ9IHRoZW4geWVzIGl0IGFjY2VwdHMgaXQuDQo+Pj4+IElmIHRoZSB2ZXJpZmllciBpcyBwcm9n cmFtbWVkIHRvIGNvbnN1bHQgYSBwb2xpY3kgZGF0YWJhc2UgdG8gY3Jvc3MNCj4+Pj4gY2hlY2sg aWYNCj4+PiB0aGUgcmVjb25zdHJ1Y3RlZCBwYXRoIHsxLDMsNSw2fSBpcyBhcyBwZXIgdGhlIHBv bGljaWVzIHRoZW4gbm8gLCBpdCBkcm9wcyBpdCAuDQo+Pj4+DQo+Pj4+IEJ1dCBJIHNlZSB5b3Vy IHBvaW50ICwgdGhhdCB0aGUgcGFyYW1ldGVycyB1c2VkIGluIFBPVCBkYXRhIGRvbm90DQo+Pj4+ IGNvbnNpZGVyDQo+Pj4gdGhlIHBhdGggb3Igbm9kZS1pZHMgZXRjIC4gV2Ugc2hhbGwgZGlzY3Vz cyB0aGlzIGludGVybmFsbHkgYW5kIGdldCBiYWNrLg0KPj4+Pg0KPj4+PiBBbHNvLCBXZSBzaGFs bCBnZXQgYmFjayB3aXRoIG1vcmUgY29uY3JldGUgbnVtYmVycyBvZiB0aGUgdGltZXN0YW1wDQo+ Pj4gcmVzb2x1dGlvbiBhbmQgY2FjaGUgc2l6ZXMgKG9yIG90aGVyIGJldHRlciBhcHByb2FjaGVz KS4NCj4+Pj4NCj4+Pj4gVGhhbmsgeW91IHNvIG11Y2ggZm9yIGFsbCB0aGUgaW5wdXRzLg0KPj4+ Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBGcm9tOiBUYWwgTWl6cmFoaQ0KPj4+PiBTZW50OiBUdWVzZGF5 LCBKdWx5IDE5LCAyMDE2IDEwOjI4IEFNDQo+Pj4+IFRvOiAnU2FzaGFuayBEYXJhIChzYWRhcmEp JzsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSk7DQo+Pj4+IGRyYWZ0LWJyb2NrbmVycy0NCj4+ PiBwcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25lcnMt cHJvb2Ytb2YtDQo+Pj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZz47IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KPj4+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFBy b29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+Pj4NCj4+Pj4gRGVhciBTYXNoYW5rLA0KPj4+Pg0KPj4+ PiBJIHJlYWxseSBhcHByZWNpYXRlIHRoZSBxdWljayBhbmQgZGV0YWlsZWQgcmVzcG9uc2VzLg0K Pj4+Pg0KPj4+Pj4+PiBMZXRzIHRha2UgY29ycmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tldCBBICB0 byBiZSBQYXRoMSAtICgNCj4+Pj4+Pj4gMSwzLDUsNikgbm9kZXMNCj4+DQoNCg== From nobody Wed Jul 20 03:21: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 0208812DB02; Wed, 20 Jul 2016 03:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 QD9fRM5kfOOa; Wed, 20 Jul 2016 03:21:44 -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 B548012DAF0; Wed, 20 Jul 2016 03:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17070; q=dns/txt; s=iport; t=1469010103; x=1470219703; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=441RmilXsuPXSCFK2XQZ2W+iGTvJ8mtmCetovA0urc8=; b=BTgxaKcTyxXq4XKTwQ0lSBFVzYLiMMLPfpAtGM/WPOXmbGmjsAWyserh Yf4wO3tT/nLrSuF0A5I2Oc86kZRzuwiRzPG0B+/gGhqCi1COBFg8LjIEQ u62hgrZ7aolIakp3CLHHKpDjRIgYxDgOpUfV1Ib4GMOQj1gds6ALjSffc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgBvT49X/40NJK1dgz9WfAa4YIF6I?= =?us-ascii?q?oV4AhyBEzgUAQEBAQEBAWUnhFwBAQQBIxEzEgUHBAIBCBEEAQEBAgIjAwICAjA?= =?us-ascii?q?UAQgIAgQOBRuIDQgOr0mNcwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQGFKYF4C?= =?us-ascii?q?IJNhEAXgmorgi8Fk2SFQgGGEohPjzmQHwEeNoILHIFMboYuKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="298163879" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 10:21:42 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6KALgnO030733 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 10:21:42 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 06:21:41 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 06:21:41 -0400 From: "Carlos Pignataro (cpignata)" To: Tal Mizrahi Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnQwDyp0062d0e9x6ZtxvV7RaAhVGaAgAACSQCAAAU7gIAAA1IA Date: Wed, 20 Jul 2016 10:21:41 +0000 Message-ID: <615BB1D0-7B58-4566-9DB9-9363C9C116DD@cisco.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> <16454292-3ADD-402A-AED6-CB785C5C833B@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.61.88.191] Content-Type: text/plain; charset="utf-8" Content-ID: <026CB4CFB290784AB5ED43EDAEB00E12@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [sfc] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 10:21:47 -0000 SGkgVGFsLA0KDQo+IE9uIEp1bCAyMCwgMjAxNiwgYXQgMTI6MDkgUE0sIFRhbCBNaXpyYWhpIDx0 YWxtaUBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBDYXJsb3MsDQo+IA0KPiBJdCBhbGwg Z29lcyBiYWNrIHRvIHRoZSB0aHJlYXQgbW9kZWw7IHdoaWNoIHRocmVhdHMgeW91IHdhbnQgdG8g YWRkcmVzcywgYW5kIHdoaWNoIG9uZXMgeW91IGRvbid0Lg0KPiANCj4gVGhlIHdheSBJIHNlZSBp dCwgcm91Z2hseSBzcGVha2luZyB0aGVyZSBhcmUgMyBjbGFzc2VzIG9mIHRocmVhdHMgKHRoZXJl IGFlIHByb2JhYmx5IG90aGVyIHRocmVhdHMsIGJ1dCB0aGVzZSBhcmUgdGhlIGJhc2ljIG9uZXMp Og0KPiAtIE1pc3JvdXRlIC8gbWlzY29uZmlndXJhdGlvbiAobm90IGEgc2VjdXJpdHkgYXR0YWNr KS4NCj4gLSBBdHRhY2tlciB3aXRoIG5vIG9uLXBhdGggYWNjZXNzLg0KPiAtIE1hbi1pbi10aGUt bWlkZGxlIChhdHRhY2tlciAqd2l0aCogb24tcGF0aCBhY2Nlc3MpLg0KPiANCj4gSXQgbG9va3Mg bGlrZSB0aGUgdGhpcmQgdGhyZWF0IChtYW4taW4tdGhlLW1pZGRsZSkgaXMgY3VycmVudGx5IG5v dCBhZGRyZXNzZWQgYnkgUE9ULg0KPiBJIGNlcnRhaW5seSBhZ3JlZSB0aGF0IHRoaXMgdGhyZWF0 IGlzIHRoZSBtb3JlIGRpZmZpY3VsdCB0byBpbXBsZW1lbnQgb2YgdGhlIHRocmVlLg0KPiANCj4g SXQgd291bGQgc2lnbmlmaWNhbnRseSBjbGFyaWZ5IHRoZSBwaWN0dXJlIGlmIHlvdSBzcGVjaWZp ZWQgaW4gdGhlIGRyYWZ0IHdoaWNoIG9mIHRoZSB0aHJlZSBjbGFzc2VzIHlvdSBpbnRlbmQgdG8g YWRkcmVzcy4NCj4gDQoNClRoYXTigJlzIGEgZ29vZCBwb2ludCwgaW5kZWVkLiBUaGUgTUlJTSBp cyBvbmUgd2Ugc2hvdWxkIGV4cGFuZCB1cG9uLg0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoN Cj4gVGhhbmtzLA0KPiBUYWwuDQo+IA0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiBGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBj aXNjby5jb21dDQo+PiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjAsIDIwMTYgMTE6NTEgQU0NCj4+ IFRvOiBUYWwgTWl6cmFoaQ0KPj4gQ2M6IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgRnJhbmsgQnJv Y2tuZXJzIChmYnJvY2tuZSk7IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi0NCj4+IG9mLXRyYW5zaXRA dG9vbHMuaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnOyBudm8zQGlldGYu b3JnDQo+PiBTdWJqZWN0OiBSZTogTUQgVHlwZSBhdHRhY2sgKFdhczogUXVlc3Rpb24gcmVnYXJk aW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQpDQo+PiANCj4+IEhpLCBUYWwsDQo+PiANCj4+PiBP biBKdWwgMjAsIDIwMTYsIGF0IDExOjQyIEFNLCBUYWwgTWl6cmFoaSA8dGFsbWlAbWFydmVsbC5j b20+IHdyb3RlOg0KPj4+IA0KPj4+IEhpIENhcmxvcywNCj4+PiANCj4+PiANCj4+Pj4gTGV04oCZ cyBzdGVwIGJhY2sgYSBsaXR0bGUg4oCUIHRoZSDigJx2dWxuZXJhYmlsaXR54oCdIHlvdSBhcmUg ZGVzY3JpYmluZw0KPj4+PiBjb21lcyB3aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgYSBNSUlUIGF0 dGFja2VyIGNhbiBpbnRlcmNlcHQgYQ0KPj4+PiBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbSB0 aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNrZXQ7IHRoZW4NCj4+Pj4gaW50ZXJjZXB0IGFub3Ro ZXIgcGFja2V0ICh3aXRoIHRoZSBrbm93bGVkZ2UgdGhhdCBpdCB0b29rIGEgZGlmZmVyZW50DQo+ Pj4+IHBhdGgsIHNvIG1heWJlIHRoZSBhdHRhY2tlciBpcyB1c2luZyBpbmJhbmQgT0FNIGFzIHdl bGwgOi0pLCBhbmQNCj4+Pj4gaW5zZXJ0IChvciBtb2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29u dGVudCBvZiB0aGUgTUQgVHlwZSAyIHdpdGhpbiB0aGUNCj4+IGNvbnRlbnQgb2YgTlNILCB3aXRo aW4gYSBzcGVjaWZpYyBwYWNrZXQuDQo+Pj4+IA0KPj4+PiBUaGlzIHNvdW5kcyBxdWl0ZSBzb3Bo aXN0aWNhdGVkLg0KPj4+IA0KPj4+IEkgYW0gbm90IHN1cmUgSSBhZ3JlZSB0aGlzIGlzIGEgJ3Nv cGhpc3RpY2F0ZWQnIGF0dGFjay4NCj4+PiBUaGUgYXR0YWNrIGRvZXMgbm90IHJlcXVpcmUgYW55 IGNyeXB0b2dyYXBoaWMgb3IgYWxnb3JpdGhtaWMgZnVuY3Rpb25hbGl0eSwNCj4+IGFuZCB0byB0 aGF0IGVuZCBpdCBpcyB2ZXJ5IGxpZ2h0d2VpZ2h0IGluIHRlcm1zIG9mIHByb2Nlc3NpbmcgcmVz b3VyY2VzLg0KPj4gDQo+PiBTb3JyeSBpZiBJIHdhcyBub3QgY2xlYXIg4oCUIEkgZG8gbm90IG1l YW4gdGVjaG5vbG9naWNhbCBzb3BoaXN0aWNhdGlvbiBvcg0KPj4gbWFzc2l2ZSBwcm9jZXNzaW5n IHJlc291cmNlcyByZXF1aXJlZC4gSSBtZWFuIGFjY2VzcyBhbmQgb3BlcmF0aW9uYWwgb25lLg0K Pj4gDQo+Pj4gDQo+Pj4gSWYgdGhpcyBraW5kIG9mIGF0dGFjayBpcyBub3Qgd2l0aGluIHRoZSBz Y29wZSBoZXJlLCB0aGVuIEkgd291bGQgYXJndWUgdGhhdA0KPj4geW91IGRvbid0IG5lZWQgYSBj cnlwdG9ncmFwaGljIG1lY2hhbmlzbSBhdCBhbGwuIEFsbCB5b3UgbmVlZCBpcyBhIFRMViB0aGF0 DQo+PiBzcGVjaWZpZXMgdGhlIGxpc3Qgb2Ygbm9kZXMuIEhvd2V2ZXIsIEkgYmVsaWV2ZSB0aGF0 IHlvdSBkaWQgd2FudCB0byB0cnkgdG8NCj4+IG1pdGlnYXRlIE1JVE0gYXR0YWNrZXJzLiBDb3Jy ZWN0IG1lIGlmIEkgYW0gd3JvbmcuDQo+Pj4gDQo+PiANCj4+IFlvdSBzZWVtIHRvIGhhdmUgbWlz c2VkIHF1b3RpbmcgdGhlIGltcG9ydGFudCBwYXJ0IG9mIG15IHJlc3BvbnNlOiAiTXkNCj4+IHBv aW50IGlzIHRoYXQgd2hhdCB5b3Ugc2VlbSB0byBiZSBkZXNjcmliaW5nIGlzIGEgZ2VuZXJpYyB0 aHJlYXQgdXNlIGNhc2UgYW5kDQo+PiBub3QgYSBzcGVjaWZpYyB2dWxuZXJhYmlsaXR5LuKAnQ0K Pj4gDQo+PiBTZWxlY3RpdmVseSBkcm9wcGluZyBwYXJ0IG9mIHRoZSByZXNwb25zZSByZW1vdmVz IGltcG9ydGFudCBjb250ZXh0Lg0KPj4gDQo+Pj4gSSBmdWxseSBhZ3JlZSB0aGF0IHRoZSB0aHJl YXQgbW9kZWwgbmVlZHMgdG8gYmUgd2VsbC1kZWZpbmVkLg0KPj4gDQo+PiBUaGUgdGhyZWF0IG1v ZGVsIGZvciBTRkMgTUQsIHllcy4gQWNjZXNzIHRvIHRoZSBQT1QgY29tZXMgd2l0aA0KPj4gYXNz dW1wdGlvbnMuDQo+PiANCj4+IFRoYW5rcywNCj4+IA0KPj4g4oCUIENhcmxvcy4NCj4+IA0KPj4+ IEkgaG9wZSB5b3Ugd2lsbCBlbGFib3JhdGUgbW9yZSBvbiB0aGUgdGhyZWF0IG1vZGVsIGluIHRo ZSBuZXh0IHZlcnNpb24gb2YNCj4+IHRoZSBkcmFmdC4NCj4+PiANCj4+PiBDaGVlcnMsDQo+Pj4g VGFsLg0KPj4+IA0KPj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBG cm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBjaXNjby5j b21dDQo+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMCwgMjAxNiAxMTozNCBBTQ0KPj4+PiBU bzogVGFsIE1penJhaGkNCj4+Pj4gQ2M6IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgRnJhbmsgQnJv Y2tuZXJzIChmYnJvY2tuZSk7DQo+Pj4+IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi0gb2YtdHJhbnNp dEB0b29scy5pZXRmLm9yZzsgc2ZjQGlldGYub3JnOw0KPj4+PiBvcHNhd2dAaWV0Zi5vcmc7IG52 bzNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogTUQgVHlwZSBhdHRhY2sgKFdhczogUXVlc3Rpb24g cmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQNCj4+Pj4gZHJhZnQpDQo+Pj4+IA0KPj4+PiBUYWws DQo+Pj4+IA0KPj4+Pj4gT24gSnVsIDIwLCAyMDE2LCBhdCA2OjMwIEFNLCBUYWwgTWl6cmFoaSA8 dGFsbWlAbWFydmVsbC5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBIaSBTYXNoYW5rLA0KPj4+ Pj4gDQo+Pj4+Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9ubHkgaWYgdGhlIGF0dGFja2Vy IGNhbiBnZXQgYXdheQ0KPj4+Pj4+IGJ5cGFzc2luZyBhDQo+Pj4+IHNlcnZpY2UgZnVuY3Rpb24v bm9kZS4NCj4+Pj4+PiBGb3IgZXhhbXBsZSwgaWYgdGhlIGF0dGFja2VyIGJ5cGFzc2VzIGEgbm9k ZSBhbmQgaWYgUE9UIGRldGVybWluZXMNCj4+Pj4+PiBpdCBkaWQNCj4+Pj4gbm90IGJ5cGFzcyBp cyBhIHZhbGlkIGF0dGFjayBvbiB0aGUgc3lzdGVtLg0KPj4+Pj4gDQo+Pj4+PiBJIHdvdWxkIHBo cmFzZSBpdCB0aGlzIHdheTogKkdpdmVuKiBhIHBhY2tldCB0aGF0IGRpZCBub3QgZ28gdGhyb3Vn aA0KPj4+Pj4gaXRzDQo+Pj4+IGRlc2lyZWQgcGF0aCwgdGhlIGF0dGFja2VyIGNhbiBlYXNpbHkg bWFrZSB5b3UgdGhpbmsgdGhhdCBpdCAqZGlkKiBnbw0KPj4+PiB0aHJvdWdoIHRoZSBkZXNpcmVk IHBhdGguDQo+Pj4+PiBTb3VuZHMgbGlrZSBhIHZlcnkgc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0 eS4NCj4+Pj4+IA0KPj4+Pj4gSWYgYSBwYWNrZXQgZGlkIG5vdCBnbyB0aHJvdWdoIHRoZSBmaXJl d2FsbCAoZm9yIG9uZSByZWFzb24gb3INCj4+Pj4+IGFub3RoZXIpLCB0aGUNCj4+Pj4gYXR0YWNr ZXIgd2lsbCBtYWtlIHlvdSB0aGluayB0aGF0IGl0IGRpZCBnbyB0aHJvdWdoIHRoZSBmaXJld2Fs bC4NCj4+Pj4+IA0KPj4+PiANCj4+Pj4gTGV04oCZcyBzdGVwIGJhY2sgYSBsaXR0bGUg4oCUIHRo ZSDigJx2dWxuZXJhYmlsaXR54oCdIHlvdSBhcmUgZGVzY3JpYmluZw0KPj4+PiBjb21lcyB3aXRo IHRoZSBhc3N1bXB0aW9uIHRoYXQgYSBNSUlUIGF0dGFja2VyIGNhbiBpbnRlcmNlcHQgYQ0KPj4+ PiBwYWNrZXQsIGV4dHJhY3QgYSBUTFYgZnJvbSB0aGUgTUQgVHlwZSAyLCBkcm9wIHRoZSBwYWNr ZXQ7IHRoZW4NCj4+Pj4gaW50ZXJjZXB0IGFub3RoZXIgcGFja2V0ICh3aXRoIHRoZSBrbm93bGVk Z2UgdGhhdCBpdCB0b29rIGEgZGlmZmVyZW50DQo+Pj4+IHBhdGgsIHNvIG1heWJlIHRoZSBhdHRh Y2tlciBpcyB1c2luZyBpbmJhbmQgT0FNIGFzIHdlbGwgOi0pLCBhbmQNCj4+Pj4gaW5zZXJ0IChv ciBtb2RpZnkpIGEgVExWIHdpdGhpbiB0aGUgY29udGVudCBvZiB0aGUgTUQgVHlwZSAyIHdpdGhp biB0aGUNCj4+IGNvbnRlbnQgb2YgTlNILCB3aXRoaW4gYSBzcGVjaWZpYyBwYWNrZXQuDQo+Pj4+ IA0KPj4+PiBUaGlzIHNvdW5kcyBxdWl0ZSBzb3BoaXN0aWNhdGVkLg0KPj4+PiANCj4+Pj4gRG8g eW91IHRoaW5rIHRoYXQgaWYgYW4gTUlJVCBjYW4gaGF2ZSB0aGF0IHN1cmZhY2Ugb2YgYXR0YWNr IGFuZA0KPj4+PiBzb3BoaXN0aWNhdGlvbiwgdGhleSBjYW4gbWVzcyB1cCB3aXRoIG90aGVyIGV2 ZW4gbW9yZSBjcml0aWNhbCB0aGluZ3M/DQo+Pj4+IENoYW5naW5nIGEgVGVuYW50IElELCBtZXNz aW5nIHVwIHdpdGggUG9saWN5IEdyb3VwcywgZXRjPw0KPj4+PiANCj4+Pj4gTXkgcG9pbnQgaXMg dGhhdCB3aGF0IHlvdSBzZWVtIHRvIGJlIGRlc2NyaWJpbmcgaXMgYSBnZW5lcmljIHRocmVhdA0K Pj4+PiB1c2UgY2FzZSBhbmQgbm90IGEgc3BlY2lmaWMgdnVsbmVyYWJpbGl0eS4gRW5naW5lZXJp bmcgaXMgYWJvdXQNCj4+Pj4gdHJhZGUtb2ZmcyAoaS5lLiwgc29sdXRpb25zIHRoYXQgaGF2ZSBw cmFjdGljYWwgcGVyZm9ybWFuY2UpIGFuZA0KPj4+PiBhYm91dCBwbGFjaW5nIHRoZSBzb2x1dGlv biBpbiB0aGUgbW9zdCBlZmZlY3RpdmUgcGxhY2UuDQo+Pj4+IA0KPj4+PiBJ4oCZbSBub3QgZGVm bGVjdGluZyBidXQgYXQgdGhlIHNhbWUgdGltZSwgbGV04oCZcyB1bmRlcnN0YW5kIHRoZQ0KPj4+ PiBhc3N1bXB0aW9ucyB5b3UgYXJlIG1ha2luZyBmb3IgdGhpcyBwb3RlbnRpYWwgYXR0YWNrIHlv dSBkZXNjcmliZSwgYXMNCj4+Pj4gcGFydCBvZiB0aGUgdGhyZWF0IGFuYWx5c2lzLg0KPj4+PiAN Cj4+Pj4gVGhhbmtzLA0KPj4+PiANCj4+Pj4g4oCUIENhcmxvcy4NCj4+Pj4gDQo+Pj4+PiBDaGVl cnMsDQo+Pj4+PiBUYWwuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gRnJvbTogU2FzaGFuayBEYXJh IChzYWRhcmEpIFttYWlsdG86c2FkYXJhQGNpc2NvLmNvbV0NCj4+Pj4+IFNlbnQ6IFdlZG5lc2Rh eSwgSnVseSAyMCwgMjAxNiA0OjMxIEFNDQo+Pj4+PiBUbzogVGFsIE1penJhaGk7IEZyYW5rIEJy b2NrbmVycyAoZmJyb2NrbmUpOw0KPj4+Pj4gZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+ PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnDQo+Pj4+PiBDYzogc2ZjQGlldGYub3JnOyBvcHNhd2dA aWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdh cmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+ Pj4gVGhlIFBPVCByZXBsYWNlbWVudCBhdHRhY2sgKDEuKSBpcyBub3QgYW4gYXR0YWNrIG9uIHRo ZSBpbnRlZ3JpdHkuDQo+Pj4+PiBJdCBpcyBhbg0KPj4+PiBhdHRhY2sgb24gdGhlIHBhdGggdmVy aWZpY2F0aW9uLg0KPj4+Pj4gVGhpcyBzaW1wbGUgYXR0YWNrIGNhbiBjYXVzZSB0aGUgdmVyaWZp ZXIgdG8gYWNjZXB0IGEgcGFja2V0IHRoYXQNCj4+Pj4+IGRpZCBub3QgZ28NCj4+Pj4gdGhyb3Vn aCB0aGUgZmlyZXdhbGwgU0YgKGV2ZW4gdGhvdWdoIGl0IHNob3VsZCkuIEkgYmVsaWV2ZSB0aGlz IGlzDQo+Pj4+IGV4YWN0bHkgdGhlIHByb2JsZW0geW91IHdlcmUgYWltaW5nIHRvIGFkZHJlc3Mg aW4gdGhpcyBkcmFmdC4NCj4+Pj4+IA0KPj4+Pj4gW1NEXSBUaGUgYXR0YWNrIGlzIHZhbGlkIG9u bHkgaWYgdGhlIGF0dGFja2VyIGNhbiBnZXQgYXdheSBieXBhc3NpbmcNCj4+Pj4+IGEgc2Vydmlj ZQ0KPj4+PiBmdW5jdGlvbi9ub2RlLg0KPj4+Pj4gRm9yIGV4YW1wbGUsIGlmIHRoZSBhdHRhY2tl ciBieXBhc3NlcyBhIG5vZGUgYW5kIGlmIFBPVCBkZXRlcm1pbmVzDQo+Pj4+PiBpdCBkaWQNCj4+ Pj4gbm90IGJ5cGFzcyBpcyBhIHZhbGlkIGF0dGFjayBvbiB0aGUgc3lzdGVtLg0KPj4+Pj4gDQo+ Pj4+PiBJbiB0aGUgY3VycmVudCBzdGF0ZSwgdGhlcmUgaXMgbm8gd2F5IGFuIGF0dGFja2VyIGNh biBnZXQgYXdheSBhcyB3ZQ0KPj4+PiBkZXRlcm1pbmUgdGhlIGV4YWN0IHBhdGggdGhlIHBhY2tl dCB0cmF2ZWxsZWQgKGFpbSBvZiB0aGUgZHJhZnQpIC4NCj4+Pj4+IEkgcmVpdGVyYXRlIHRoYXQg dGhlIHZlcmlmaWVyIG5lZWRzIHRvIGhhbmRsZSB3aGF0IHRvIGRvIHdpdGggdGhlDQo+Pj4+PiBw YXRoDQo+Pj4+IHJlY29uc3RydWN0ZWQgIQ0KPj4+Pj4gV2UgY291bGQgZW1waGFzaXplIHRoaXMg aW4gb3VyIG5leHQgZHJhZnQgLCBidXQgaXQgd291bGQgYmUgYmV5b25kDQo+Pj4+PiBzY29wZSBv Zg0KPj4+PiBQT1QgdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8gd2l0aCB0aGUgcGF0aCBjb25zdHJ1 Y3RlZC4NCj4+Pj4+IElNTywgSXQgd291bGQgYmUgaGlnaGx5IGFwcGxpY2F0aW9uIHNwZWNpZmlj Lg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiBTYXNoYW5rDQo+Pj4+PiAN Cj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiBUYWwuDQo+Pj4+PiANCj4+Pj4+ IEZyb206IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIFttYWlsdG86ZmJyb2NrbmVAY2lzY28u Y29tXQ0KPj4+Pj4gU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiA2OjAwIFBNDQo+Pj4+PiBU bzogVGFsIE1penJhaGk7IFNhc2hhbmsgRGFyYSAoc2FkYXJhKTsgZHJhZnQtYnJvY2tuZXJzLXBy b29mLW9mLQ0KPj4+PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25l cnMtcHJvb2Ytb2YtDQo+Pj4+IHRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+DQo+Pj4+PiBDYzogc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Ow0KPj4+PiBvcHNhd2dAaWV0Zi5vcmc8bWFp bHRvOm9wc2F3Z0BpZXRmLm9yZz47DQo+Pj4+IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0 Zi5vcmc+DQo+Pj4+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRy YW5zaXQgZHJhZnQNCj4+Pj4+IA0KPj4+Pj4gSGkgVGFsLA0KPj4+Pj4gDQo+Pj4+PiB0aGFua3Mg Zm9yIHRoZSBzdW1tYXJ5LiBXZSdsbCBwcm92aWRlIG1vcmUgZGV0YWlscyBvbiAyLiBQZXIgbXkN Cj4+Pj4+IGVhcmxpZXINCj4+Pj4gcG9pbnQgLSAxLiBpcyBhbiBpbnRlcmVzdGluZyBkaXNjdXNz aW9uLCBnaXZlbiB0aGF0IHdlIGRvbid0IGNsYWltIHRvDQo+Pj4+IHByb3ZpZGUgaW50ZWdyaXR5 IHByb3RlY3Rpb24gZm9yIHRoZSBwYWNrZXQgcGF5bG9hZC4gT3IgaW4gb3RoZXIgdGVybXMgLSB0 bw0KPj4gYmUgZXhhY3Q6DQo+Pj4+IFdoYXQgUE9UIHByb3ZpZGVzIGlzIGEgcHJvb2YgdGhhdCB0 aGUgUE9ULWhlYWRlci9tZXRhLWRhdGEgdHJhbnNpdGVkDQo+Pj4+IGFsbCB0aGUgcmVxdWlyZWQg bm9kZXMuIFRoZXJlIGlzIG5vIGFzc29jaWF0aW9uIChhbmQgdGh1cyBwcm9vZikNCj4+Pj4gcHJv dmlkZWQgZm9yIHRoZSBhZGRpdGlvbmFsIGRhdGEgY2FycmllZCBhbG9uZyB3aXRoIHRoZSBQT1Qt aGVhZGVyIC0NCj4+Pj4gbmVpdGhlciBoZWFkZXIgbm9yIHBheWxvYWQuIEFzIGEgY29uc2VxdWVu Y2UsIGF0dGFja3Mgd2hpY2ggY2hhbmdlDQo+Pj4+IHRoZSBwYWNrZXQgcGF5bG9hZCB3b24ndCBi ZSBkZXRlY3RlZC9taXRpZ2F0ZWQuIFdlJ2xsIGV4cGxpY2l0bHkNCj4+Pj4gc3RhdGUgdGhpcyBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdGhlIG5leHQgcmV2IG9mIHRoZSBkb2N1 bWVudC4NCj4+Pj4+IFdoYXQgd2UgY291bGQgY29uc2lkZXIgaXMgbGlua2luZyB0aGUgUk5EIG51 bWJlciB0byBDUkMgYWNyb3NzIHRoZQ0KPj4+Pj4gcGFja2V0DQo+Pj4+IHBheWxvYWQgb3Igc2lt aWxhciAtIGJ1dCB0aGF0IHdheSB3ZSdkIHJlc3RyaWN0IHRoZSBhcHBsaWNhYmlsaXR5IHRvDQo+ Pj4+IGRlcGxveW1lbnRzIHdoZXJlIHRoZSBwYWNrZXQgcGF5bG9hZCBpc24ndCBjaGFuZ2VkIGFj cm9zcyB0aGUgcGF0aA0KPj4+PiAod2hpY2ggbWlnaHQgbm90IGFwcGx5IHRvIGNlcnRhaW4gZGVw bG95bWVudCAtIGUuZy4gV0FOIG9wdGltaXphdGlvbiAvDQo+PiBjb21wcmVzc2lvbiBzY2hlbWVz KS4NCj4+Pj4+IERvIHlvdSB0aGluayBpdCBpcyB3b3J0aHdoaWxlIHRvIHByb3ZpZGUgYSBzb2x1 dGlvbiBmb3IgYSBkZXBsb3ltZW50DQo+Pj4+PiB3aGljaCBpcw0KPj4+PiBleHBlY3RlZCB0byBu b3QgYWx0ZXIgdGhlIHBhY2tldCBwYXlsb2FkPw0KPj4+Pj4gDQo+Pj4+PiBUaGFua3MsDQo+Pj4+ PiBGcmFuaw0KPj4+Pj4gDQo+Pj4+PiBGcm9tOiBUYWwgTWl6cmFoaSBbbWFpbHRvOnRhbG1pQG1h cnZlbGwuY29tXQ0KPj4+Pj4gU2VudDogRGllbnN0YWcsIDE5LiBKdWxpIDIwMTYgMTc6NDQNCj4+ Pj4+IFRvOiBTYXNoYW5rIERhcmEgKHNhZGFyYSkNCj4+Pj4gPHNhZGFyYUBjaXNjby5jb208bWFp bHRvOnNhZGFyYUBjaXNjby5jb20+PjsgRnJhbmsgQnJvY2tuZXJzDQo+Pj4+IChmYnJvY2tuZSkg PGZicm9ja25lQGNpc2NvLmNvbTxtYWlsdG86ZmJyb2NrbmVAY2lzY28uY29tPj47DQo+Pj4+IGRy YWZ0LWJyb2NrbmVycy0NCj4+Pj4gcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+PiB0cmFuc2l0QHRvb2xzLmlldGYub3Jn Pg0KPj4+Pj4gQ2M6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsNCj4+Pj4gb3Bz YXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+Ow0KPj4+PiBudm8zQGlldGYub3Jn PG1haWx0bzpudm8zQGlldGYub3JnPg0KPj4+Pj4gU3ViamVjdDogUkU6IFF1ZXN0aW9uIHJlZ2Fy ZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQo+Pj4+PiANCj4+Pj4+IEhpLA0KPj4+Pj4gDQo+ Pj4+PiBUbyBzdW1tYXJpemUgbXkgdGFrZSBvbiB0aGlzIHRocmVhZDoNCj4+Pj4+IFRoZSBwcm9w b3NlZCBtZWNoYW5pc20gaGFzIHR3byBzaWduaWZpY2FudCB2dWxuZXJhYmlsaXRpZXMgdGhhdCAo aW4NCj4+Pj4+IG15DQo+Pj4+IHVuZGVyc3RhbmRpbmcpIGFyZSBjdXJyZW50bHkgbm90IGFkZHJl c3NlZDoNCj4+Pj4+IA0KPj4+Pj4gMS4gICAgICAgQSBtYW4taW4tdGhlLW1pZGRsZSBjYW4gcmVw bGFjZSB0aGUgUE9UIG9mIHBhY2tldCBBIHdpdGggdGhlIFBPVA0KPj4gb2YNCj4+Pj4gcGFja2V0 IEIuDQo+Pj4+PiANCj4+Pj4+IDIuICAgICAgIEl0IGlzIHBvc3NpYmxlIHRvIHJlcGxheSBQT1Rz IHdpdGhpbiBhIGNlcnRhaW4gdGltZSB3aW5kb3csIHdob3NlDQo+Pj4+IGxlbmd0aCBpcyBkZXRl cm1pbmVkIGJ5IHRoZSB0aW1lc3RhbXAgcmVzb2x1dGlvbi4NCj4+Pj4+IA0KPj4+Pj4gU2FzaGFu aywgdGhhbmtzIGZvciBhZ3JlZWluZyB0byBsb29rIGludG8gaXQgZnVydGhlci4gSSBhbSBsb29r aW5nDQo+Pj4+PiBmb3J3YXJkIHRvDQo+Pj4+IHlvdXIgaW5zaWdodHMgb24gdGhpcy4NCj4+Pj4+ IA0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+IFRhbC4NCj4+Pj4+IA0KPj4+Pj4gTGluayB0byB0aGUg ZHJhZnQ6DQo+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJz LXByb29mLW9mLQ0KPj4+PiB0cmFuc2l0LTAxDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+ PiBGcm9tOiBTYXNoYW5rIERhcmEgKHNhZGFyYSkgW21haWx0bzpzYWRhcmFAY2lzY28uY29tXQ0K Pj4+Pj4gU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiAxMjoyMCBQTQ0KPj4+Pj4gVG86IFRh bCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsNCj4+Pj4+IGRyYWZ0LWJyb2Nr bmVycy1wcm9vZi1vZi0NCj4+Pj4gdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQt YnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+PiB0cmFuc2l0QHRvb2xzLmlldGYub3JnPjsgc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+PiBTdWJqZWN0OiBSZTogUXVlc3Rpb24g cmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAN Cj4+Pj4+IEkgd2FudCB0byBhc2sgYSBzaW1wbGUgcXVlc3Rpb246DQo+Pj4+PiBJZiB0aGUgYXR0 YWNrZXIgYXR0YWNoZXMgdGhlIFBPVCBvZiBwYWNrZXQgQSAoaW5kaWNhdGluZyB0aGUgcGF0aA0K Pj4+Pj4gdGhyb3VnaA0KPj4+PiAxLDMsNSw2KSB0byBwYWNrZXQgQiwgd2lsbCB0aGUgdmVyaWZp ZXIgYWNjZXB0IHBhY2tldCBCIGFuZCBiZWxpZXZlDQo+Pj4+IHRoYXQgaXRzIHBhdGggd2FzIGlu ZGVlZCAoMSwzLDUsNik/DQo+Pj4+PiANCj4+Pj4+IFtTRF0gSWYgdGhlIHZlcmlmaWVyIGlzIHBy b2dyYW1tZWQgdG8ganVzdCB2YWxpZGF0ZSB0aGUgUE9UIG1ldGENCj4+Pj4+IGRhdGEgYWdhaW5z dA0KPj4+PiB7MSwzLDUsNn0gdGhlbiB5ZXMgaXQgYWNjZXB0cyBpdC4NCj4+Pj4+IElmIHRoZSB2 ZXJpZmllciBpcyBwcm9ncmFtbWVkIHRvIGNvbnN1bHQgYSBwb2xpY3kgZGF0YWJhc2UgdG8gY3Jv c3MNCj4+Pj4+IGNoZWNrIGlmDQo+Pj4+IHRoZSByZWNvbnN0cnVjdGVkIHBhdGggezEsMyw1LDZ9 IGlzIGFzIHBlciB0aGUgcG9saWNpZXMgdGhlbiBubyAsIGl0IGRyb3BzIGl0IC4NCj4+Pj4+IA0K Pj4+Pj4gQnV0IEkgc2VlIHlvdXIgcG9pbnQgLCB0aGF0IHRoZSBwYXJhbWV0ZXJzIHVzZWQgaW4g UE9UIGRhdGEgZG9ub3QNCj4+Pj4+IGNvbnNpZGVyDQo+Pj4+IHRoZSBwYXRoIG9yIG5vZGUtaWRz IGV0YyAuIFdlIHNoYWxsIGRpc2N1c3MgdGhpcyBpbnRlcm5hbGx5IGFuZCBnZXQgYmFjay4NCj4+ Pj4+IA0KPj4+Pj4gQWxzbywgV2Ugc2hhbGwgZ2V0IGJhY2sgd2l0aCBtb3JlIGNvbmNyZXRlIG51 bWJlcnMgb2YgdGhlIHRpbWVzdGFtcA0KPj4+PiByZXNvbHV0aW9uIGFuZCBjYWNoZSBzaXplcyAo b3Igb3RoZXIgYmV0dGVyIGFwcHJvYWNoZXMpLg0KPj4+Pj4gDQo+Pj4+PiBUaGFuayB5b3Ugc28g bXVjaCBmb3IgYWxsIHRoZSBpbnB1dHMuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBG cm9tOiBUYWwgTWl6cmFoaQ0KPj4+Pj4gU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiAxMDoy OCBBTQ0KPj4+Pj4gVG86ICdTYXNoYW5rIERhcmEgKHNhZGFyYSknOyBGcmFuayBCcm9ja25lcnMg KGZicm9ja25lKTsNCj4+Pj4+IGRyYWZ0LWJyb2NrbmVycy0NCj4+Pj4gcHJvb2Ytb2YtdHJhbnNp dEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLQ0KPj4+PiB0 cmFuc2l0QHRvb2xzLmlldGYub3JnPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+Pj4+PiBTdWJqZWN0OiBSRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQg ZHJhZnQNCj4+Pj4+IA0KPj4+Pj4gRGVhciBTYXNoYW5rLA0KPj4+Pj4gDQo+Pj4+PiBJIHJlYWxs eSBhcHByZWNpYXRlIHRoZSBxdWljayBhbmQgZGV0YWlsZWQgcmVzcG9uc2VzLg0KPj4+Pj4gDQo+ Pj4+Pj4+PiBMZXRzIHRha2UgY29ycmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tldCBBICB0byBiZSBQ YXRoMSAtICgNCj4+Pj4+Pj4+IDEsMyw1LDYpIG5vZGVzDQo+Pj4gDQo+IA0KDQo= From nobody Wed Jul 20 04:06: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 5FFD912D537; Wed, 20 Jul 2016 04:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 4LAWZA0pNVD6; Wed, 20 Jul 2016 04:06:43 -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 B3E3212DB7C; Wed, 20 Jul 2016 04:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12647; q=dns/txt; s=iport; t=1469012769; x=1470222369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FiKND2rxt+SLcN8J83DAM+qsRLyNgeaNXIuwQlaMsko=; b=DWa5pzC7ejkHsWsYzOuPxhqLD5aGO0+0IJmPsZPAOpzy10B8uO80x9Rr spt3eEBVwDQ0wuIRKmw2YsDkGvYjcgvvKeckOiY8hvhqmIiaBiSCH/+a7 jg9q9zWlvCeTYatRfFNZuBG2jIBtfjkMecUXtOqOwZD92XarSCvSwfW2B I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgBDWo9X/40NJK1dgz9WfAa4UYF6I?= =?us-ascii?q?oV4AoEvOBQBAQEBAQEBZSeEXAEBBWcSDAQCAQgRBAEBAScHMhQJCAIEAQ0FG4g?= =?us-ascii?q?VDr1DAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhECFWwEEmSYBhhKIT485k?= =?us-ascii?q?B8BHjaCCxyBTG6GLisYAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="300091954" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 11:06:08 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6KB68Sb031600 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 11:06:08 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 06:06:07 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 06:06:07 -0500 From: "Sashank Dara (sadara)" To: Tal Mizrahi , "Carlos Pignataro (cpignata)" Thread-Topic: MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4mnR49sgJZJZWUWTXAMFLb5ExaAhZSqAgAACSoCAAAU6gIAAa+mA Date: Wed, 20 Jul 2016 11:06:07 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> <16454292-3ADD-402A-AED6-CB785C5C833B@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/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [72.163.210.134] Content-Type: text/plain; charset="Windows-1252" Content-ID: <371D2F1F0FD9B14C82534A1F21DAD3F1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "draft-brockners-proof-of-transit@tools.ietf.org" , "Frank Brockners \(fbrockne\)" Subject: Re: [sfc] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 11:06:46 -0000 On 20/07/16, 3:39 PM, "Tal Mizrahi" wrote: >Hi Carlos, > >It all goes back to the threat model; which threats you want to address, >and which ones you don't. > >The way I see it, roughly speaking there are 3 classes of threats (there >ae probably other threats, but these are the basic ones): >- Misroute / misconfiguration (not a security attack). >- Attacker with no on-path access. >- Man-in-the-middle (attacker *with* on-path access). > >It looks like the third threat (man-in-the-middle) is currently not >addressed by POT. >I certainly agree that this threat is the more difficult to implement of >the three. Thanks for such classification, we shall work on better threat modelling and clarity in our next version. Now , Can we put some concrete high level protocol names here that could use POT and prone to MITM ? Helps us understand the validity of the =B3mix-and-match=B2 attack you described in a more concrete context. > >It would significantly clarify the picture if you specified in the draft >which of the three classes you intend to address. > >Thanks, >Tal. > > >>-----Original Message----- >>From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>Sent: Wednesday, July 20, 2016 11:51 AM >>To: Tal Mizrahi >>Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); >>draft-brockners-proof- >>of-transit@tools.ietf.org; sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org >>Subject: Re: MD Type attack (Was: Question regarding Proof of Transit >>draft) >> >>Hi, Tal, >> >>> On Jul 20, 2016, at 11:42 AM, Tal Mizrahi wrote: >>> >>> Hi Carlos, >>> >>> >>>> Let=B9s step back a little =8B the =B3vulnerability=B2 you are describ= ing >>>> comes with the assumption that a MIIT attacker can intercept a >>>> packet, extract a TLV from the MD Type 2, drop the packet; then >>>> intercept another packet (with the knowledge that it took a different >>>> path, so maybe the attacker is using inband OAM as well :-), and >>>> insert (or modify) a TLV within the content of the MD Type 2 within >>>>the >>content of NSH, within a specific packet. >>>> >>>> This sounds quite sophisticated. >>> >>> I am not sure I agree this is a 'sophisticated' attack. >>> The attack does not require any cryptographic or algorithmic >>>functionality, >>and to that end it is very lightweight in terms of processing resources. >> >>Sorry if I was not clear =8B I do not mean technological sophistication o= r >>massive processing resources required. I mean access and operational one. >> >>> >>> If this kind of attack is not within the scope here, then I would >>>argue that >>you don't need a cryptographic mechanism at all. All you need is a TLV >>that >>specifies the list of nodes. However, I believe that you did want to try >>to >>mitigate MITM attackers. Correct me if I am wrong. >>> >> >>You seem to have missed quoting the important part of my response: "My >>point is that what you seem to be describing is a generic threat use >>case and >>not a specific vulnerability.=B2 >> >>Selectively dropping part of the response removes important context. >> >>> I fully agree that the threat model needs to be well-defined. >> >>The threat model for SFC MD, yes. Access to the POT comes with >>assumptions. >> >>Thanks, >> >>=8B Carlos. >> >>> I hope you will elaborate more on the threat model in the next version >>>of >>the draft. >>> >>> Cheers, >>> Tal. >>> >>> >>>> -----Original Message----- >>>> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>> Sent: Wednesday, July 20, 2016 11:34 AM >>>> To: Tal Mizrahi >>>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); >>>> draft-brockners-proof- of-transit@tools.ietf.org; sfc@ietf.org; >>>> opsawg@ietf.org; nvo3@ietf.org >>>> Subject: MD Type attack (Was: Question regarding Proof of Transit >>>> draft) >>>> >>>> Tal, >>>> >>>>> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi wrote: >>>>> >>>>> Hi Sashank, >>>>> >>>>>> [SD] The attack is valid only if the attacker can get away >>>>>> bypassing a >>>> service function/node. >>>>>> For example, if the attacker bypasses a node and if POT determines >>>>>> it did >>>> not bypass is a valid attack on the system. >>>>> >>>>> I would phrase it this way: *Given* a packet that did not go through >>>>> its >>>> desired path, the attacker can easily make you think that it *did* go >>>> through the desired path. >>>>> Sounds like a very significant vulnerability. >>>>> >>>>> If a packet did not go through the firewall (for one reason or >>>>> another), the >>>> attacker will make you think that it did go through the firewall. >>>>> >>>> >>>> Let=B9s step back a little =8B the =B3vulnerability=B2 you are describ= ing >>>> comes with the assumption that a MIIT attacker can intercept a >>>> packet, extract a TLV from the MD Type 2, drop the packet; then >>>> intercept another packet (with the knowledge that it took a different >>>> path, so maybe the attacker is using inband OAM as well :-), and >>>> insert (or modify) a TLV within the content of the MD Type 2 within >>>>the >>content of NSH, within a specific packet. >>>> >>>> This sounds quite sophisticated. >>>> >>>> Do you think that if an MIIT can have that surface of attack and >>>> sophistication, they can mess up with other even more critical things? >>>> Changing a Tenant ID, messing up with Policy Groups, etc? >>>> >>>> My point is that what you seem to be describing is a generic threat >>>> use case and not a specific vulnerability. Engineering is about >>>> trade-offs (i.e., solutions that have practical performance) and >>>> about placing the solution in the most effective place. >>>> >>>> I=B9m not deflecting but at the same time, let=B9s understand the >>>> assumptions you are making for this potential attack you describe, as >>>> part of the threat analysis. >>>> >>>> Thanks, >>>> >>>> =8B Carlos. >>>> >>>>> Cheers, >>>>> Tal. >>>>> >>>>> >>>>> From: Sashank Dara (sadara) [mailto:sadara@cisco.com] >>>>> Sent: Wednesday, July 20, 2016 4:31 AM >>>>> To: Tal Mizrahi; Frank Brockners (fbrockne); >>>>> draft-brockners-proof-of- >>>> transit@tools.ietf.org >>>>> Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org >>>>> Subject: Re: Question regarding Proof of Transit draft >>>>> >>>>> >>>>> >>>>> The POT replacement attack (1.) is not an attack on the integrity. >>>>> It is an >>>> attack on the path verification. >>>>> This simple attack can cause the verifier to accept a packet that >>>>> did not go >>>> through the firewall SF (even though it should). I believe this is >>>> exactly the problem you were aiming to address in this draft. >>>>> >>>>> [SD] The attack is valid only if the attacker can get away bypassing >>>>> a service >>>> function/node. >>>>> For example, if the attacker bypasses a node and if POT determines >>>>> it did >>>> not bypass is a valid attack on the system. >>>>> >>>>> In the current state, there is no way an attacker can get away as we >>>> determine the exact path the packet travelled (aim of the draft) . >>>>> I reiterate that the verifier needs to handle what to do with the >>>>> path >>>> reconstructed ! >>>>> We could emphasize this in our next draft , but it would be beyond >>>>> scope of >>>> POT to determine what to do with the path constructed. >>>>> IMO, It would be highly application specific. >>>>> >>>>> >>>>> Regards, >>>>> Sashank >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Tal. >>>>> >>>>> From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] >>>>> Sent: Tuesday, July 19, 2016 6:00 PM >>>>> To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of- >>>> transit@tools.ietf.org>>> transit@tools.ietf.org> >>>>> Cc: sfc@ietf.org; >>>> opsawg@ietf.org; >>>> nvo3@ietf.org >>>>> Subject: RE: Question regarding Proof of Transit draft >>>>> >>>>> Hi Tal, >>>>> >>>>> thanks for the summary. We'll provide more details on 2. Per my >>>>> earlier >>>> point - 1. is an interesting discussion, given that we don't claim to >>>> provide integrity protection for the packet payload. Or in other >>>>terms - to >>be exact: >>>> What POT provides is a proof that the POT-header/meta-data transited >>>> all the required nodes. There is no association (and thus proof) >>>> provided for the additional data carried along with the POT-header - >>>> neither header nor payload. As a consequence, attacks which change >>>> the packet payload won't be detected/mitigated. We'll explicitly >>>> state this in the security considerations in the next rev of the >>>>document. >>>>> What we could consider is linking the RND number to CRC across the >>>>> packet >>>> payload or similar - but that way we'd restrict the applicability to >>>> deployments where the packet payload isn't changed across the path >>>> (which might not apply to certain deployment - e.g. WAN optimization / >>compression schemes). >>>>> Do you think it is worthwhile to provide a solution for a deployment >>>>> which is >>>> expected to not alter the packet payload? >>>>> >>>>> Thanks, >>>>> Frank >>>>> >>>>> From: Tal Mizrahi [mailto:talmi@marvell.com] >>>>> Sent: Dienstag, 19. Juli 2016 17:44 >>>>> To: Sashank Dara (sadara) >>>> >; Frank Brockners >>>> (fbrockne) >; >>>> draft-brockners- >>>> proof-of-transit@tools.ietf.org>>> transit@tools.ietf.org> >>>>> Cc: sfc@ietf.org; >>>> opsawg@ietf.org; >>>> nvo3@ietf.org >>>>> Subject: RE: Question regarding Proof of Transit draft >>>>> >>>>> Hi, >>>>> >>>>> To summarize my take on this thread: >>>>> The proposed mechanism has two significant vulnerabilities that (in >>>>> my >>>> understanding) are currently not addressed: >>>>> >>>>> 1. A man-in-the-middle can replace the POT of packet A with >>>>>the POT >>of >>>> packet B. >>>>> >>>>> 2. It is possible to replay POTs within a certain time window, >>>>>whose >>>> length is determined by the timestamp resolution. >>>>> >>>>> Sashank, thanks for agreeing to look into it further. I am looking >>>>> forward to >>>> your insights on this. >>>>> >>>>> Regards, >>>>> Tal. >>>>> >>>>> Link to the draft: >>>>> https://tools.ietf.org/html/draft-brockners-proof-of- >>>> transit-01 >>>>> >>>>> >>>>> >>>>> From: Sashank Dara (sadara) [mailto:sadara@cisco.com] >>>>> Sent: Tuesday, July 19, 2016 12:20 PM >>>>> To: Tal Mizrahi; Frank Brockners (fbrockne); >>>>> draft-brockners-proof-of- >>>> transit@tools.ietf.org>>> transit@tools.ietf.org>; sfc@ietf.org >>>>> Subject: Re: Question regarding Proof of Transit draft >>>>> >>>>> >>>>> >>>>> I want to ask a simple question: >>>>> If the attacker attaches the POT of packet A (indicating the path >>>>> through >>>> 1,3,5,6) to packet B, will the verifier accept packet B and believe >>>> that its path was indeed (1,3,5,6)? >>>>> >>>>> [SD] If the verifier is programmed to just validate the POT meta >>>>> data against >>>> {1,3,5,6} then yes it accepts it. >>>>> If the verifier is programmed to consult a policy database to cross >>>>> check if >>>> the reconstructed path {1,3,5,6} is as per the policies then no , it >>>>drops it . >>>>> >>>>> But I see your point , that the parameters used in POT data donot >>>>> consider >>>> the path or node-ids etc . We shall discuss this internally and get >>>>back. >>>>> >>>>> Also, We shall get back with more concrete numbers of the timestamp >>>> resolution and cache sizes (or other better approaches). >>>>> >>>>> Thank you so much for all the inputs. >>>>> >>>>> >>>>> >>>>> From: Tal Mizrahi >>>>> Sent: Tuesday, July 19, 2016 10:28 AM >>>>> To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); >>>>> draft-brockners- >>>> proof-of-transit@tools.ietf.org>>> transit@tools.ietf.org>; sfc@ietf.org >>>>> Subject: RE: Question regarding Proof of Transit draft >>>>> >>>>> Dear Sashank, >>>>> >>>>> I really appreciate the quick and detailed responses. >>>>> >>>>>>>> Lets take correct path taken by Packet A to be Path1 - ( >>>>>>>> 1,3,5,6) nodes >>> > From nobody Wed Jul 20 06:03: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 29B9212D5F0; Wed, 20 Jul 2016 06:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 q0TwMzntd8qO; Wed, 20 Jul 2016 06:03:20 -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 7838812D1B8; Wed, 20 Jul 2016 06:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25767; q=dns/txt; s=iport; t=1469019799; x=1470229399; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rm+9hHQJbvc/a4l7CFbN/cCYRGNO4dMskW2P5H+HnqQ=; b=DldcYxEjh3YGetQlpXnZIX1fw3qjKruRQlKbxZ9KV3rTYxt45cmpkDDL SL+JGV3v/lcJ+EpC0VCKs3tv43AIeYTRXrrPbNUzegSgA83MXGtbOgVQi hBcBMXEMtN951d3nawNqSGjJU4H7wDcFa+qIVlKw1/wOA9yzqdmRQtJDq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgDrdY9X/5pdJa1dgnFOVm4OBrZCg?= =?us-ascii?q?g+BeiKFeAKBLzgUAQEBAQEBAWUnhFwBAQUtOhIQAgEIEQMBAiEHBzIUCQgCBAE?= =?us-ascii?q?NBYgwDr1AAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhBIRASoSGIUjBZNkh?= =?us-ascii?q?UIBhhKIT4FshFmIdJAfAR42g3Nuhjs2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,394,1464652800"; d="scan'208,217";a="127956444" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 13:03:18 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6KD3IRo014535 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 13:03:18 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 08:03:17 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 08:03:17 -0500 From: "Saumya Dikshit (sadikshi)" To: "Saumya Dikshit (sadikshi)" , "Nagendra Kumar Nainar (naikumar)" , Gregory Mirsky , "BIER (bier@ietf.org)" , "sfc@ietf.org" , "nvo3@ietf.org" , "rtg-ooam-dt@ietf.org" , "rtgwg@ietf.org" Thread-Topic: [nvo3] [Bier] Comments to OOAM Requirements draft from Ron Bonica Thread-Index: AQHR4ocViWBwwTTmV0mY2c9hkRwUbA== Date: Wed, 20 Jul 2016 13:03:17 +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/14.6.5.160527 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.202.40] Content-Type: multipart/alternative; boundary="_000_D3B540DB6B713sadikshiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rbonica@juniper.net" Subject: Re: [sfc] [nvo3] [Bier] Comments to OOAM Requirements draft from Ron Bonica X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 13:03:26 -0000 --_000_D3B540DB6B713sadikshiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Greg, Authors of ooam-dt set of drafts Other than current requirements, it will be great to explicitly support the= OAM PDU semantics. * apply OAM function_set to group of VNI or band of VNI=92s and this in= formation carried in same OAM PDU. Although the response can be discrete on= a per VNI basis based on how and where the response is triggered from. If = It=92s proxy from remote NVE, then the response can be a replication to the= request. This is will reduce the number of probes which need to be send to= perform the OAM functions. * It will be great to designate VNI=92s as L2 or L3 and apply function_= Set to them. This is implicitly derived in data-path, but for OAM PDUs, it = will help to make it explicit either via using some flags or some other sem= antics. Hence we can carry bunch of L2 and L3 vnis with corresponding funct= ion-set In case these are valid requirements, which I feel they are. Can they find = a place in existing document. I can also come out with a peripheral draft defining these. Thanks Saumya. From: nvo3 > on behalf = of sadikshi > Date: Monday, July 4, 2016 at 8:09 PM To: "Nagendra Kumar Nainar (naikumar)" >, Gregory Mirsky >, "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org<= mailto:rtgwg@ietf.org>" > Cc: "rbonica@juniper.net" > Subject: Re: [nvo3] [Bier] Comments to OOAM Requirements draft from Ron Bon= ica Hi Nagendra, Thanks for the response. I missed this one in the below email: >>>>> REQ#14: Overlay OAM MUST have the ability to discover and exercise equal cost multipath (ECMP) paths in its transport network. This will require the underlay nodes/router/switches to support OAM semanti= cs, which may not be possible in case of brownfield deployments (deploying NVO tunnels over existing IP-c= ore network). Regards, Saumya. From: "Nagendra Kumar Nainar (naikumar)" > Date: Monday, July 4, 2016 at 4:39 PM To: sadikshi >, Gregory Mirsk= y >, "BIER = (bier@ietf.org)" = >, "sfc@ietf.org" >,= "nvo3@ietf.org" = >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: Re: [Bier] [nvo3] Comments to OOAM Requirements draft from Ron Bon= ica HI Saumya, Please see inline.. Hi Greg, I have following queries on Overlay OAM Requirements: >>>>> REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic, i.e. in-band with the monitored traffic, i.e. follow exactly the same path as data plane traffic, in forward direction, i.e. from ingress toward egress end point(s) of the OAM test session. =93Exactly same path=94, should be made explicit if it=92s referring to the= underlay transport path. Yes, that is the intention. We will clarify it. "OAM packets SHOULD be fate sharing with data traffic=94 will not apply to = "REQ#3: centralized controller=94. I think =93SHOULD=94 should be treated as a =93MUST=94 if the reference is = within the document :) >>>>> REQ#11: Overlay OAM MUST support fault localization of Loss of Continuity check. Does the =93localization=94 maps to overlay node/link context ? Can we have= a =93MAY=94 requirement for mapping it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement to narrow down to underlay for a speedier fault management. MAY statement sounds reasonable. REQ#22 =97 REQ#25 refer to =93per-segment=94. A =93segment=94 maps to a NVO-tunnel? Yes, a segment referes to NVO tunnel between NVEs. Multiple such= segments may comprise an end-to-end tunnel. Shouldn=92t there be on a per-VNI basis as well. I think the granularity should definitely at per-VNI level. >>>>> REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such OAM methods MAY combine in-band monitoring or measurement in forward direction and out-of-band notification in the reverse direction, i.e. from egress to ingress end point of the OAM test session. In case of optical deployments like, fiber management (both request and res= ponse) can be out-of-band, hence may need a mention here. I see. We will check this. Thanks for your comments. Regards, Nagendra Thanks Saumya From: nvo3 > on behalf = of Gregory Mirsky > Date: Tuesday, April 5, 2016 at 1:39 AM To: "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: [nvo3] Comments to OOAM Requirements draft from Ron Bonica Dear All, Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> = tag. The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Net= works: Gap Analysis. Regards, Greg --_000_D3B540DB6B713sadikshiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Greg, Authors of ooam-dt set of drafts

Other than current requirements, it will be great to explicitly suppor= t the OAM PDU semantics. 
  • apply OAM function_set to group of VNI or band of VNI=92s and this info= rmation carried in same OAM PDU. Although the response can be discrete on a= per VNI basis based on how and where the response is triggered from. If It= =92s proxy from remote NVE, then the response can be a replication to the request. This is will reduce the numb= er of probes which need to be send to perform the OAM functions.
  • It= will be great to designate VNI=92s as L2 or L3 and apply function_Set to t= hem. This is implicitly derived in data-path, but for OAM PDUs, it will hel= p to make it explicit either via using some flags or some other semantics. = Hence we can carry bunch of L2 and L3 vnis with corresponding function-set
In case these are valid requirements, which I feel they are. Can they = find a place in existing document.
I can also come out with a peripheral draft defining these. 

Thanks
Saumya.

From: nvo3 <nvo3-bounces@ietf.org> on behalf of sadikshi &l= t;sadikshi@cisco.com>
Date: Monday, July 4, 2016 at 8:09 = PM
To: "Nagendra Kumar Nainar (na= ikumar)" <naikumar@cisco.com<= /a>>, Gregory Mirsky <= gregory.mirsky@ericsson.com>, "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@= ietf.org" <nvo3@ietf.org&g= t;, "rtg-ooam-dt@ietf.org&= quot; <rtg-ooam-dt@ietf.org>, = "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [nvo3] [Bier] Comments= to OOAM Requirements draft from Ron Bonica

Hi Nagendra,

Thanks for the response. I missed this one in the below email:

>>>>> REQ#14: Overlay OAM MUS=
T have the ability to discover and exercise
            equal cost multipath (ECMP) paths in its transport network.=

This will require the underlay nodes/router/switches to support OAM se= mantics, which may not be possible 
in case of brownfield deployments (deploying NVO tunnels over existing= IP-core network). 


Regards,
Saumya.


From: "Nagendra Kumar Nainar (= naikumar)" <naikumar@cisco.co= m>
Date: Monday, July 4, 2016 at 4:39 = PM
To: sadikshi <sadikshi@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>= , "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@= ietf.org" <nvo3@ietf.org&g= t;, "rtg-ooam-dt@ietf.org&= quot; <rtg-ooam-dt@ietf.org>, = "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [Bier] [nvo3] Comments= to OOAM Requirements draft from Ron Bonica

HI Saumya,

Please see inline..

Hi Greg,

I have following queries on  Overlay OAM Requirements:

>>>>> REQ#6:  Overlay OAM pac=
kets SHOULD be fate sharing with data traffic,
            i.e. in-band with the monitored traffic, i.e. follow exactly
            the same path as data plane traffic, in forward direction,
            i.e. from ingress toward egress end point(s) of the OAM test
            session.

=93Exactly same path=94, should be made explicit if it=92s referring to the= underlay transport path.

<Nagendra> Yes, that is the intention. We will clarify it.

"OAM packets SHOULD be fate sharing wit= h data traffic= =94 will not apply to "REQ#3:  centralized controller= =94.
I think =93SHOULD=94 should be treated as a =93MU= ST=94 if the reference is within the document :)
 


>>>>> REQ#11: Overlay OAM MUS=
T support fault localization of Loss of
            Continuity check.
Does the =93localization=94 maps to overlay node/link context ? Can we have= a =93MAY=94 requirement for mapping
it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement
to narrow down to underlay for a speedier fault management.

<Nagendra> MAY statement sounds reasonable.

REQ#22 =97 REQ#25 refer to =93per-segment=94. 
A =93segment=94 maps to a NVO-tunnel? 

<Nagendra> Yes, a segment referes to NVO tunnel between NVEs. Mu= ltiple such segments may comprise an end-to-end tunnel.

 Shouldn=92t there be on a  per-VNI basis as well.

<Nagendra>I think  the granularity should definitely at per= -VNI level. 

>>>>> REQ#7:  Overlay OAM MUS=
T support bi-directional OAM methods.  Such
            OAM methods MAY combine in-band monitoring or measurement in
            forward direction and out-of-band notification in the
            reverse direction, i.e. from egress to ingress end point of
            the OAM test session.

In case of optical deployments like, fiber management (both request an= d response) can be out-of-band, hence may
need a mention here. 
<Nagendra> I see. We will check this.

Thanks for your comments.

Regards,
Nagendra


Thanks
Saumya

From: nvo3 <nvo3-bounces@ietf.org> on behalf of Gregory Mir= sky <gregory.mirsky@erics= son.com>
Date: Tuesday, April 5, 2016 at 1:3= 9 AM
To: "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org<= /a>" <sfc@ietf.org>, "<= a href=3D"mailto:nvo3@ietf.org">nvo3@ietf.org" <nvo3@ietf.org>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: [nvo3] Comments to OOAM Re= quirements draft from Ron Bonica

Dear All,

Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> tag= . The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Networks: Gap Analysis.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_D3B540DB6B713sadikshiciscocom_-- From nobody Wed Jul 20 11:21: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 1101A12D9E4; Wed, 20 Jul 2016 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.485 X-Spam-Level: X-Spam-Status: No, score=-5.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 ZBvLKGxRoHyh; Wed, 20 Jul 2016 11:21:00 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5442112B05C; Wed, 20 Jul 2016 11:20:59 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u6KII1KA018304; Wed, 20 Jul 2016 14:18:01 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Sashank Dara (sadara)" , Tal Mizrahi , "Carlos Pignataro (cpignata)" Thread-Topic: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) Thread-Index: AQHR4rN0FItGrjjQCU+KuYNgvl1r4g== Date: Wed, 20 Jul 2016 18:20:55 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <1BB247D3-A500-4D99-A970-2A2A42BFA1B5@cisco.com> <16454292-3ADD-402A-AED6-CB785C5C833B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [172.25.177.156] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3551869245_103035243" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200203 Archived-At: Cc: "Frank Brockners \(fbrockne\)" , "opsawg@ietf.org" , "nvo3@ietf.org" , "draft-brockners-proof-of-transit@tools.ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2016 18:21:03 -0000 --B_3551869245_103035243 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I suggest that while MITM is not the most common threat (there are more attackers that are without on-path access) - it is still common and dangerous *enough* to justify mitigating it, if at all possible. At the very worst, clearly specify why you do not address this threat (but again, I=E2=80=99d rather that you addressed it), and its potential consequences. --=20 Regards, Uri Blumenthal On 7/20/16, 7:06 , "OPSAWG on behalf of Sashank Dara (sadara)" wrote: > >On 20/07/16, 3:39 PM, "Tal Mizrahi" wrote: > >>Hi Carlos, >> >>It all goes back to the threat model; which threats you want to address, >>and which ones you don't. >> >>The way I see it, roughly speaking there are 3 classes of threats (there >>ae probably other threats, but these are the basic ones): >>- Misroute / misconfiguration (not a security attack). >>- Attacker with no on-path access. >>- Man-in-the-middle (attacker *with* on-path access). >> >>It looks like the third threat (man-in-the-middle) is currently not >>addressed by POT. >>I certainly agree that this threat is the more difficult to implement of >>the three. > >Thanks for such classification, we shall work on better threat modelling >and clarity in our next version. > >Now , Can we put some concrete high level protocol names here that could >use POT and prone to MITM ? >Helps us understand the validity of the =C2=B3mix-and-match=C2=B2 attack you >described in a more concrete context. > > > >> >>It would significantly clarify the picture if you specified in the draft >>which of the three classes you intend to address. >> >>Thanks, >>Tal. >> >> >>>-----Original Message----- >>>From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>Sent: Wednesday, July 20, 2016 11:51 AM >>>To: Tal Mizrahi >>>Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); >>>draft-brockners-proof- >>>of-transit@tools.ietf.org; sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org >>>Subject: Re: MD Type attack (Was: Question regarding Proof of Transit >>>draft) >>> >>>Hi, Tal, >>> >>>> On Jul 20, 2016, at 11:42 AM, Tal Mizrahi wrote: >>>> >>>> Hi Carlos, >>>> >>>> >>>>> Let=C2=B9s step back a little =E2=80=B9 the =C2=B3vulnerability=C2=B2 you are describin= g >>>>> comes with the assumption that a MIIT attacker can intercept a >>>>> packet, extract a TLV from the MD Type 2, drop the packet; then >>>>> intercept another packet (with the knowledge that it took a different >>>>> path, so maybe the attacker is using inband OAM as well :-), and >>>>> insert (or modify) a TLV within the content of the MD Type 2 within >>>>>the >>>content of NSH, within a specific packet. >>>>> >>>>> This sounds quite sophisticated. >>>> >>>> I am not sure I agree this is a 'sophisticated' attack. >>>> The attack does not require any cryptographic or algorithmic >>>>functionality, >>>and to that end it is very lightweight in terms of processing resources. >>> >>>Sorry if I was not clear =E2=80=B9 I do not mean technological sophistication = or >>>massive processing resources required. I mean access and operational >>>one. >>> >>>> >>>> If this kind of attack is not within the scope here, then I would >>>>argue that >>>you don't need a cryptographic mechanism at all. All you need is a TLV >>>that >>>specifies the list of nodes. However, I believe that you did want to try >>>to >>>mitigate MITM attackers. Correct me if I am wrong. >>>> >>> >>>You seem to have missed quoting the important part of my response: "My >>>point is that what you seem to be describing is a generic threat use >>>case and >>>not a specific vulnerability.=C2=B2 >>> >>>Selectively dropping part of the response removes important context. >>> >>>> I fully agree that the threat model needs to be well-defined. >>> >>>The threat model for SFC MD, yes. Access to the POT comes with >>>assumptions. >>> >>>Thanks, >>> >>>=E2=80=B9 Carlos. >>> >>>> I hope you will elaborate more on the threat model in the next version >>>>of >>>the draft. >>>> >>>> Cheers, >>>> Tal. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>>> Sent: Wednesday, July 20, 2016 11:34 AM >>>>> To: Tal Mizrahi >>>>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); >>>>> draft-brockners-proof- of-transit@tools.ietf.org; sfc@ietf.org; >>>>> opsawg@ietf.org; nvo3@ietf.org >>>>> Subject: MD Type attack (Was: Question regarding Proof of Transit >>>>> draft) >>>>> >>>>> Tal, >>>>> >>>>>> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi wrote: >>>>>> >>>>>> Hi Sashank, >>>>>> >>>>>>> [SD] The attack is valid only if the attacker can get away >>>>>>> bypassing a >>>>> service function/node. >>>>>>> For example, if the attacker bypasses a node and if POT determines >>>>>>> it did >>>>> not bypass is a valid attack on the system. >>>>>> >>>>>> I would phrase it this way: *Given* a packet that did not go through >>>>>> its >>>>> desired path, the attacker can easily make you think that it *did* go >>>>> through the desired path. >>>>>> Sounds like a very significant vulnerability. >>>>>> >>>>>> If a packet did not go through the firewall (for one reason or >>>>>> another), the >>>>> attacker will make you think that it did go through the firewall. >>>>>> >>>>> >>>>> Let=C2=B9s step back a little =E2=80=B9 the =C2=B3vulnerability=C2=B2 you are describin= g >>>>> comes with the assumption that a MIIT attacker can intercept a >>>>> packet, extract a TLV from the MD Type 2, drop the packet; then >>>>> intercept another packet (with the knowledge that it took a different >>>>> path, so maybe the attacker is using inband OAM as well :-), and >>>>> insert (or modify) a TLV within the content of the MD Type 2 within >>>>>the >>>content of NSH, within a specific packet. >>>>> >>>>> This sounds quite sophisticated. >>>>> >>>>> Do you think that if an MIIT can have that surface of attack and >>>>> sophistication, they can mess up with other even more critical >>>>>things? >>>>> Changing a Tenant ID, messing up with Policy Groups, etc? >>>>> >>>>> My point is that what you seem to be describing is a generic threat >>>>> use case and not a specific vulnerability. Engineering is about >>>>> trade-offs (i.e., solutions that have practical performance) and >>>>> about placing the solution in the most effective place. >>>>> >>>>> I=C2=B9m not deflecting but at the same time, let=C2=B9s understand the >>>>> assumptions you are making for this potential attack you describe, as >>>>> part of the threat analysis. >>>>> >>>>> Thanks, >>>>> >>>>> =E2=80=B9 Carlos. >>>>> >>>>>> Cheers, >>>>>> Tal. >>>>>> >>>>>> >>>>>> From: Sashank Dara (sadara) [mailto:sadara@cisco.com] >>>>>> Sent: Wednesday, July 20, 2016 4:31 AM >>>>>> To: Tal Mizrahi; Frank Brockners (fbrockne); >>>>>> draft-brockners-proof-of- >>>>> transit@tools.ietf.org >>>>>> Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org >>>>>> Subject: Re: Question regarding Proof of Transit draft >>>>>> >>>>>> >>>>>> >>>>>> The POT replacement attack (1.) is not an attack on the integrity. >>>>>> It is an >>>>> attack on the path verification. >>>>>> This simple attack can cause the verifier to accept a packet that >>>>>> did not go >>>>> through the firewall SF (even though it should). I believe this is >>>>> exactly the problem you were aiming to address in this draft. >>>>>> >>>>>> [SD] The attack is valid only if the attacker can get away bypassing >>>>>> a service >>>>> function/node. >>>>>> For example, if the attacker bypasses a node and if POT determines >>>>>> it did >>>>> not bypass is a valid attack on the system. >>>>>> >>>>>> In the current state, there is no way an attacker can get away as we >>>>> determine the exact path the packet travelled (aim of the draft) . >>>>>> I reiterate that the verifier needs to handle what to do with the >>>>>> path >>>>> reconstructed ! >>>>>> We could emphasize this in our next draft , but it would be beyond >>>>>> scope of >>>>> POT to determine what to do with the path constructed. >>>>>> IMO, It would be highly application specific. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Sashank >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Tal. >>>>>> >>>>>> From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] >>>>>> Sent: Tuesday, July 19, 2016 6:00 PM >>>>>> To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of- >>>>> transit@tools.ietf.org>>>> transit@tools.ietf.org> >>>>>> Cc: sfc@ietf.org; >>>>> opsawg@ietf.org; >>>>> nvo3@ietf.org >>>>>> Subject: RE: Question regarding Proof of Transit draft >>>>>> >>>>>> Hi Tal, >>>>>> >>>>>> thanks for the summary. We'll provide more details on 2. Per my >>>>>> earlier >>>>> point - 1. is an interesting discussion, given that we don't claim to >>>>> provide integrity protection for the packet payload. Or in other >>>>>terms - to >>>be exact: >>>>> What POT provides is a proof that the POT-header/meta-data transited >>>>> all the required nodes. There is no association (and thus proof) >>>>> provided for the additional data carried along with the POT-header - >>>>> neither header nor payload. As a consequence, attacks which change >>>>> the packet payload won't be detected/mitigated. We'll explicitly >>>>> state this in the security considerations in the next rev of the >>>>>document. >>>>>> What we could consider is linking the RND number to CRC across the >>>>>> packet >>>>> payload or similar - but that way we'd restrict the applicability to >>>>> deployments where the packet payload isn't changed across the path >>>>> (which might not apply to certain deployment - e.g. WAN optimization >>>>>/ >>>compression schemes). >>>>>> Do you think it is worthwhile to provide a solution for a deployment >>>>>> which is >>>>> expected to not alter the packet payload? >>>>>> >>>>>> Thanks, >>>>>> Frank >>>>>> >>>>>> From: Tal Mizrahi [mailto:talmi@marvell.com] >>>>>> Sent: Dienstag, 19. Juli 2016 17:44 >>>>>> To: Sashank Dara (sadara) >>>>> >; Frank Brockners >>>>> (fbrockne) >; >>>>> draft-brockners- >>>>> proof-of-transit@tools.ietf.org>>>> transit@tools.ietf.org> >>>>>> Cc: sfc@ietf.org; >>>>> opsawg@ietf.org; >>>>> nvo3@ietf.org >>>>>> Subject: RE: Question regarding Proof of Transit draft >>>>>> >>>>>> Hi, >>>>>> >>>>>> To summarize my take on this thread: >>>>>> The proposed mechanism has two significant vulnerabilities that (in >>>>>> my >>>>> understanding) are currently not addressed: >>>>>> >>>>>> 1. A man-in-the-middle can replace the POT of packet A with >>>>>>the POT >>>of >>>>> packet B. >>>>>> >>>>>> 2. It is possible to replay POTs within a certain time window, >>>>>>whose >>>>> length is determined by the timestamp resolution. >>>>>> >>>>>> Sashank, thanks for agreeing to look into it further. I am looking >>>>>> forward to >>>>> your insights on this. >>>>>> >>>>>> Regards, >>>>>> Tal. >>>>>> >>>>>> Link to the draft: >>>>>> https://tools.ietf.org/html/draft-brockners-proof-of- >>>>> transit-01 >>>>>> >>>>>> >>>>>> >>>>>> From: Sashank Dara (sadara) [mailto:sadara@cisco.com] >>>>>> Sent: Tuesday, July 19, 2016 12:20 PM >>>>>> To: Tal Mizrahi; Frank Brockners (fbrockne); >>>>>> draft-brockners-proof-of- >>>>> transit@tools.ietf.org>>>> transit@tools.ietf.org>; sfc@ietf.org >>>>>> Subject: Re: Question regarding Proof of Transit draft >>>>>> >>>>>> >>>>>> >>>>>> I want to ask a simple question: >>>>>> If the attacker attaches the POT of packet A (indicating the path >>>>>> through >>>>> 1,3,5,6) to packet B, will the verifier accept packet B and believe >>>>> that its path was indeed (1,3,5,6)? >>>>>> >>>>>> [SD] If the verifier is programmed to just validate the POT meta >>>>>> data against >>>>> {1,3,5,6} then yes it accepts it. >>>>>> If the verifier is programmed to consult a policy database to cross >>>>>> check if >>>>> the reconstructed path {1,3,5,6} is as per the policies then no , it >>>>>drops it . >>>>>> >>>>>> But I see your point , that the parameters used in POT data donot >>>>>> consider >>>>> the path or node-ids etc . We shall discuss this internally and get >>>>>back. >>>>>> >>>>>> Also, We shall get back with more concrete numbers of the timestamp >>>>> resolution and cache sizes (or other better approaches). >>>>>> >>>>>> Thank you so much for all the inputs. >>>>>> >>>>>> >>>>>> >>>>>> From: Tal Mizrahi >>>>>> Sent: Tuesday, July 19, 2016 10:28 AM >>>>>> To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); >>>>>> draft-brockners- >>>>> proof-of-transit@tools.ietf.org>>>> transit@tools.ietf.org>; sfc@ietf.org >>>>>> Subject: RE: Question regarding Proof of Transit draft >>>>>> >>>>>> Dear Sashank, >>>>>> >>>>>> I really appreciate the quick and detailed responses. >>>>>> >>>>>>>>> Lets take correct path taken by Packet A to be Path1 - ( >>>>>>>>> 1,3,5,6) nodes >>>> >> > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > --B_3551869245_103035243 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUZwYJKoZIhvcNAQcCoIIUWDCCFFQCAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCjM7 SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQxMgQw0OpuSmBy+rEjTOg0 XyEhxzRyfnRb7PxT5IjprhB9pl2EW8R7cjrenZBjo5dYzhHMMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDcyMDE4MjA0NVowDQYJKoZIhvcNAQEBBQAE ggEAEcv12OH2/nVhA6/aELEJfnQ5SpUNCaFOJk3eaB1qvuxElJu3ttRcY0gfw1toHBfX1nQn jmH/vkZH6aTFnvFYmm/A58FSOjBizB3GAP5VHs0+a42f76PPurymZsWn7m0bBWlQ00VhlWKG n2ywjlAXmUFzqalQGtNnKhdvCq7PF57xAlkkx5bmRAHc7jqxkaDp3IpvpgRpBwPpbfPuDvKM e3iwVq/1NogDNxkZs8YykJBHNPEQerBiQgv7KKtGZqSOb9Lzl2SE22SOTblrLNUXSyi6f1gg 1SFoQywLqx36bicZWwP+bkfU2jus1YR+HpE/NoT+z2LJGK6f9f4yMQNsXQ== --B_3551869245_103035243-- From nobody Wed Jul 20 16:08: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 22EE912B00D for ; Wed, 20 Jul 2016 16:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.308 X-Spam-Level: X-Spam-Status: No, score=-8.308 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.287, 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 lvCCqbEsYbo8 for ; Wed, 20 Jul 2016 16:08:23 -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 5032312B030 for ; Wed, 20 Jul 2016 16:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1469056104; x=1500592104; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ULdbBrLzJCsSUFvFLMrRLI+hIfchOR91jj+sOvlQmUA=; b=vKPxRqxYl+1AkcZAZdA7IJky5Og8AnXOyHVYtu5WW6Hkqytj/4Vy8p/6 r/T9Vr4EiUVFH9RxKBT3sWDfx8zFVNAWXPjGkRRk4BDBcSabGkkSTZ6ut jENv7rZed9LdTBU5HQxqHW3FHESlj0GHXtmMU65OE8J9eo9a+ylCRQUP8 g=; X-IronPort-AV: E=McAfee;i="5700,7163,8232"; a="230957542" X-IronPort-AV: E=Sophos;i="5.28,396,1464652800"; d="scan'208";a="230957542" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 20 Jul 2016 23:08:21 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 20 Jul 2016 16:08:20 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1178.000; Wed, 20 Jul 2016 16:08:20 -0700 From: Sumandra Majee To: Dave Dolson , "Joel M. Halpern" , Linda Dunbar , "Elzur, Uri" , Sunil Vallamkonda , "Bottorff, Paul" , "sfc@ietf.org" Thread-Topic: [sfc] Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-01.txt Thread-Index: AQHR4tub/VGI1ZXndEifWhsqDD5cLA== Date: Wed, 20 Jul 2016 23:08:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Examples of Metadata that need to be passed among SFs : regarding draft-vallamkonda-sfc-metadata-model-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, 20 Jul 2016 23:08:26 -0000 I agree that iff two parties need to communicate they better speak the same language.=20 However I don=B9t see a reason to develop another framework for what is essentially a data definition facility and there has been many in the past. For example radius supports vendor specific AVP and all major vendors support definition file format, I think most of those were written pretty early and supported a few data types like int32, ipaddr, string, octet etc.=20 However today one can potentially use JSON(may not work well with binary stream, but there is BJSON), XML, even old SUN XDR. I have missed a whole lot other that I know and many more that I will never know. Looking from developer point of view my personal preference would be to choose a schema that has existing tools, libraries, bindings to all popular language etc. and all of them are available for free. JSON/BJSON/XML etc. etc. all fits that criterion. Regards. On 7/11/16, 10:24 AM, "sfc on behalf of Dave Dolson" wrote: >Clearly metadata passed between two SFs needs to be understood by both. >I think Joel is correct that standardization covers this case -- at >least for AVPs in MD-Type 2. > >But I don't believe standardization covers the MD-Type-1 format, >since there doesn't seem to be an allocation that fits all. >Control-plane indication of "what are in slots 1..4?" seems necessary. > > >And another issue is that such metadata may need to pass through an >intermediary SF that does NOT know the standardization, and may NOT >know the semantics of the metadata. > >We are also attempting to provide sufficient description of the metadata >that an intermediary can avoid breaking things. >When an intermediary injects packets into a chain it is particularly >important for it to be aware of the semantics -- perhaps including >the case when packets cannot be injected. > > > >-Dave > > > >-----Original Message----- >From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Sent: Monday, July 11, 2016 1:10 PM >To: Linda Dunbar; Elzur, Uri; Sunil Vallamkonda; Dave Dolson; Bottorff, >Paul; sfc@ietf.org >Subject: Re: Examples of Metadata that need to be passed among SFs : >regarding draft-vallamkonda-sfc-metadata-model-01.txt > >I find it very hard to understand the advantage of the proposed >framework. I am usually of the opinion that indirection is helpful in >solving protocol identification problems. In this case however, I can >not see any value in having control specify to an SF "You will find >field X under TLV code A" using a quasi-standard X. For things with >standard type code, there is clearly no need for such. For things with >vendor defined type codes, the label X is no more useful than the vendor >defined type code. After all, if the meaning of X were standard, then >there would presuambly be a standard type code assigned to it. We have >lots of space. > >Yours, >Joel > >On 7/11/16 12:49 PM, Linda Dunbar wrote: >>=20 >>_https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-model/_h >>as >> the examples of metadata that may need to be passed among SFs along a >> SFP, e.g. >> >> /SF1 may at real-time attach DoS information for the next SF in >> downstream. SF1 provides the hint and it is up to the downstream SFs to >> process it or ignore it. However if a downstream SF chooses to >> processes, it needs standardized metadata data model to understand the >> hint encoded by SF1 in packets./ >> >> To minimize the extra bytes added to packets in NSH, it is necessary to >> have compact encoding of the metadata carried by data packets. Achieving >> this goal will need control plane to inform the encoding mechanisms to >> SFs via out of band control channels. >> >> What do people think about the proposed framework for metadata exchanged >> among SFs on a SFP? >> >> >> Linda >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Elzur, Uri >> Sent: Friday, April 01, 2016 5:56 PM >> To: Sunil Vallamkonda; Joel M. Halpern; Dave Dolson; Bottorff, Paul; >> sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> Sunil >> >> To advance your point, it may be of advantage, IMHO, if you provide a >> concrete example of what metadata can be shared, and requires >> interoperability among vendors, in a specific example e.g. FW LB NAT (or >> choose your favorite). Notice some proposed directions in your draft. >> >> The thread reads very theoretical and suggests limited value for inter >> vendor interaction. Seems like you wish to counter it. A specific >> example may help bring the conversation down to ground level. >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sunil Vallamkonda >> Sent: Wednesday, March 30, 2016 11:04 AM >> To: Joel M. Halpern >; >> Dave Dolson >; >> Bottorff, Paul >; >> sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> Joel, >> >> Good point, we are not trying to enumerate all the possible algorithmic >> behaviors. >> Yes, the proposal addresses both vendor and standardized metadata, where >> latter could be a flavor of former. >> In below MD-2, ignoring all metadata is a simple implementation, though >> with limited capabilities. However in all elements the sender and >> receiver need to co-ordinate metadata in a dynamic and scalable way to >> take intelligent actions. >> >> Re: #1: Is there a definite limitation in framework for metadata to be >> same for all packets ? It should not limit or mandate either way. >> Re: #2: If there is no need for receiver to understand the semantics >> across vendors and products and releases, I do not believe it would be >> a scalable solution. The code semantics and actions need to be aware by >> elements for metadata, without which we might well use only 'reserved' >> part of header or just treat MD-2 as a 'reserved' header itself, IMHO. >> >> Again to clarify, the intent and focus is have the ability to understand >> and extend metadata semantics for deployment. The goal is not to >> enumerate every possible situation but to provide semantics to customize >> and support algorithmic and other situations as individual case may be. >> >> >> Thanks, >> Sunil >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 30, 2016 10:56 AM >> To: Dave Dolson >; >> Sunil Vallamkonda >; Bottorff, >> Paul >; >> sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> In terms of copied information, control tells the SF what to copy. It >> does not matter what the granularity is. >> >> Given that "flow" does not have a consistent meaning (sometimes it means >> 5-tuple, sometimes it means other things) trying to define control >> instructions at other granularities than packet gets us into algorithmic >> behaviors. And I do not think we want to try to enumerate all of the >> "supported" algorithmic behaviors. >> >> Similarly, if the information is not the same as that from the prompting >> packet, we are again finding ourselves getting into algorithmic >> instructions (maybe you complement this field, or add 100 to that field, >> or bounce the third field off the roof.) >> >> If we neeed algorithmic behavior, it seems to me that the SF has to know >> what it is doing. It can not rely on control to tell it. Yes, this >> places some limits on generality of inserting metadata in produced >> packets. I would be interested in improvement, but I have not seen one. >> >> Yours, >> Joel >> >> On 3/30/16 1:47 PM, Dave Dolson wrote: >>> Joel, >>> I'd like to examine this point of yours: >>>> 2) Metadata to be copied from a prompting packet. This would seem to >>>> be provided by control as a list of type codes, with no need to >>>> understand semantics. >>> >>> Yes, I think control should provide information about different type >>>codes. >>> But we believe there *is* some requirement to understand certain >>>semantics. >>> E.g., >>> - is the metadata about the packet, about the flow or about the source >>>or destination end-point? >>> - is the metadata important enough to add to new packets, or is it >>>optional? >>> - is the metadata direction-specific, or can the value be cloned from >>>a request to a response? >>> >>> If we don't address different types of semantics, I think we need to >>> agree there is only one type that works in all cases, or that certain >>> types should not be used in an opaque manner, or that certain types >>>should not be used with service functions that need to inject packets. >>> >>> >>> Personally, I think that per-packet opaque metadata is problematic and >>>probably to be avoided. >>> E.g., a metadata that is checksum of the packet. >>> If this is opaque to a function, the function may modify the packet or >>> clone the metadata from one packet to another without being able to >>>update it. >>> >>> -Dave >>> >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Wednesday, March 30, 2016 1:27 PM >>> To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; sfc@ietf.org >>> >>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> I think you are mixing two concepts. >>> There is vendor metadata and standardized metadata. >>> >>> I do not think anything in the framework I have seen will make vendor >>> metadata interoperate without coordination between vendors. >>> >>> And as far as I can tell, there is nothing needed from the framework >>> to make standard metadata interoperate. >>> >>> That leaves the corner case of experimental or developmental metadata. >>> Experiments almost always need coordiantion. >>> >>> If we are talking about MD-2, it seems to me that SF and SFF will >>> simply ignore any metadata that they do not understand. In the common >>> case, SFF will ignore all metadata entirely. >>> >>> You have raised the question of what metadata shoudl go on packets >>> originated by service functions. This seems to be a complex question, >>> that is not helped by the framework. As far as I can tell, I can see >>> the following cases: >>> 1) Metadata about the SF originating the packet. This is common >>> across all packets, and can be provided to the SF by control means in >>> an opaque blob. >>> 2) Metadata to be copied from a prompting packet. This would seem to >>> be provided by control as a list of type codes, with no need to >>> understand semantics. >>> 3) Metadata derived algorithmically from information available to the >>> service function. This is hard. I do not see how the framework helps >>> here at all. Is it needed? >>> >>> Yours, >>> Joel >>> >>> On 3/30/16 1:06 PM, Sunil Vallamkonda wrote: >>>> When metadata is exchanged between SFFs, SFs, SFCs, it begs to the >>>>questions of interpretations. Without a framework for opaque metadata, >>>>the ambiguity between vendor products in service chain makes it >>>>incompatible unless the resolution is hardcoded across of releases and >>>>platforms, and vendor specific >> information encoded. The flexibility and ability for metadata to be >> interoperable and scale are benefits that are much needed for rapid >> deployments and adoption. >>>> >>>> >>>> Thanks, >>>> Sunil >>>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Wednesday, March 30, 2016 9:46 AM >>>> To: Bottorff, Paul >>>>; Dave Dolson >>>> >; Sunil >>>>Vallamkonda >> >; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> I don't see why we would specify which metadata is of interest to a >>>>specific SF. It is up to the SF what it is interested in, not up to >>>>service chaining to control that. >>>> As for preserving forwarding addresses, while I see value in doing so >>>>for some transports, I don't see how SFC can mandate that since it is >>>>a transport dependent behavior. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 3/30/16 12:31 PM, Bottorff, Paul wrote: >>>>> Hi Dave and Joel: >>>>> >>>>> IMHO the most important thing to standardize is how an SFs couple to >>>>>a chain. We are already implying that it would be desirable for SFs >>>>>to pass both chain forwarding addresses and meta-data from ingress to >>>>>egress (proxy forwarding always comes with a cost), however this >>>>>alone does not provide enough >> guidance for SF network interfacing. We also have issues like how >> forwarding reversals are indicated at L4-Higher SFs and what meta-data >> is opaque and what is for SF consumption. >>>>> >>>>> Cheers, >>>>> >>>>> Paul >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>>>> Sent: Tuesday, March 29, 2016 7:30 PM >>>>> To: Joel Halpern Direct >>>>>; Sunil >>>>> Vallamkonda >; Joel M. Halpern >> >; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> Joel, >>>>> Consider a Service Function that needs to inject a packet, such as >>>>> articulated in https://tools.ietf.org/html/draft-penno-sfc-packet-02 >>>>> The question arises, what metadata should be put in the NSH header >>>>>of an injected packet? >>>>> >>>>> Without some kind of rigorous description of a type of metadata, I >>>>>don't know how to program the Service Function to do it properly. >>>>> >>>>> The alternative is to hard-code each service function with the >>>>>supported types of metadata. >>>>> This wouldn't allow a function to handle metadata it wasn't >>>>>programmed for. >>>>> >>>>> >>>>> So unless there is some easier way of understanding this, there >>>>>seems to be a gap in specifying Service Function behaviour. >>>>> This is one thing we're trying to figure out. >>>>> >>>>> >>>>> -Dave >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >>>>> Direct >>>>> Sent: Tuesday, March 29, 2016 7:37 PM >>>>> To: Sunil Vallamkonda; Joel M. Halpern; sfc@ietf.org >>>>> >>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> It may help to see some use cases. >>>>> >>>>> But it sounds, at best, like a specific control plane solution to >>>>>some set of problems. >>>>> Specific control plane solutions, as distinct from descriptions of >>>>>requirements, are out of scope for the working group. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 3/29/16 7:32 PM, Sunil Vallamkonda wrote: >>>>>> The focus is ability for vendor compatibility and extensibility in >>>>>>SF eco-system without hardcoding and human guessing. >>>>>> The categorization and rest may or may not be a fallout of this. >>>>>>Without such a framework, it makes interpretations harder across >>>>>>implementations. This would be normal case rather than exception, >>>>>>IMHO. The goal is not to standardize any vendor data, but provide a >>>>>>framework to promote vendor >> compatibility and extensibility across systems. As a clarification we >> can walk through use cases to understand the benefits. >>>>>> >>>>>> >>>>>> Thank you, >>>>>> Sunil. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>> Sent: Tuesday, March 29, 2016 4:20 PM >>>>>> To: Sunil Vallamkonda >; >>>>>>sfc@ietf.org >>>>>> Subject: Re: [sfc] SFC Metadata: Comments regarding >>>>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>>>> >>>>>> I am sorry. I don't see the value in this. >>>>>> >>>>>> Trying to categorize metadata does not seem to help anything. >>>>>> Trying to standardize a descriptive langauge for metadata seems to >>>>>>imply something that can consume such a language. I can not imagine >>>>>>anything that can usefully consume this. >>>>>> >>>>>> I can understand how a human being would use a registry (which we >>>>>>have to have) to know what T codes are defined, and where to find >>>>>>descriptions of their meaning. >>>>>> But that meaning description is going to be in English. A file >>>>>>that tells me that value 17 is the Dragaeran Corporate type code for >>>>>>Houses does not tell me anything. >>>>>> >>>>>> The only corner case for the YANG is if my system has some >>>>>>understanding of the semantics of various pieces of metadata, but >>>>>>wants to know what code is associated with a particular usage. >>>>>> The problem is that we have mutliple different protocols that may >>>>>>want to provide that information, so all that SFC can define is that >>>>>>the control system must include a way to provide that information. >>>>>> >>>>>> Given that much of the metadata is not vendor specific, the >>>>>>structure seems very odd. >>>>>> ANd it seems likely that any vendor specific metadata will need the >>>>>>semantics to already be known, since we can not standardize that. >>>>>> >>>>>> Yours in puzzlement, >>>>>> Joel >>>>>> >>>>>> On 3/29/16 6:33 PM, Sunil Vallamkonda wrote: >>>>>>> Metadata is a vital element of SFC and thus NFV. >>>>>>> >>>>>>> Additionally, interoperability and vendor support challenges need >>>>>>> to be addressed in a scalable and adaptable way for rapid >>>>>>>deployment. >>>>>>> >>>>>>> In January we uploaded draft-vallamkonda-sfc-metadata-model-00, >>>>>>> which proposes terminology for talking about metadata in an >>>>>>>extensible fashion. >>>>>>> >>>>>>> If there are no objections, we'd like to start pushing this >>>>>>> terminology into drafts about NSH and the control-plane. >>>>>>> >>>>>>> Please let us know what you think. >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> Sunil. >>>>>>> >>>>>>> =3D=3D >>>>>>> >>>>>>> A new version of I-D, draft-vallamkonda-sfc-metadata-model-00.txt >>>>>>> >>>>>>> has been successfully submitted by Sunil Vallamkonda and posted to >>>>>>> the IETF repository. >>>>>>> >>>>>>> Name: draft-vallamkonda-sfc-metadata-model >>>>>>> >>>>>>> Revision: 00 >>>>>>> >>>>>>> Title: Information Model for SFC Metadata >>>>>>> >>>>>>> Document date: 2016-01-28 >>>>>>> >>>>>>> Group: Individual Submission >>>>>>> >>>>>>> Pages: 9 >>>>>>> >>>>>>> URL: >>>>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadat >>>>>>> a- >>>>>>> m >>>>>>> o >>>>>>> del-00.txt >>>>>>> >>>>>>> Status: >>>>>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-mo >>>>>>> de >>>>>>> l >>>>>>> / >>>>>>> >>>>>>> Htmlized: >>>>>>> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-0 >>>>>>> 0 >>>>>>> >>>>>>> Abstract: >>>>>>> >>>>>>> Various types of metadata are applicable to Service >>>>>>> Function Chaining >>>>>>> >>>>>>> (SFC). A Service Function (SF) needs information about >>>>>>> all metadata >>>>>>> >>>>>>> passing through it. The metadata could be used to convey >>>>>>> >>>>>>> preprocessing information about the packet by other nodes >>>>>>> and an SF >>>>>>> >>>>>>> can attach post processing information as deemed necessary. >>>>>>> >>>>>>> The purpose of this document is to rigorously define the >>>>>>> classes of >>>>>>> >>>>>>> metadata and provide a vocabulary and information model >>>>>>>for metadata. >>>>>>> >>>>>>> Each item of metadata refers to a subject, examples of >>>>>>> which are IP >>>>>>> >>>>>>> endpoint, flow or individual packet. >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission until the htmlized version and diff are available at >>>>>>> tools.ietf.org. >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Jul 21 00:01: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 8FD3C12D968; Thu, 21 Jul 2016 00:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4ISwzvf3fe1; Thu, 21 Jul 2016 00:01:11 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2741312D10D; Thu, 21 Jul 2016 00:01:11 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-33-579067e0f0be Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 9E.18.09012.0E760975; Thu, 21 Jul 2016 08:12:48 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 03:01:10 -0400 From: Gregory Mirsky To: "sfc@ietf.org" Thread-Topic: Identifying OAM in NSH Thread-Index: AdHjGxqUb41VTqTfTwmZE/bgRl5mHQ== Date: Thu, 21 Jul 2016 07:01:09 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221ADA9CBeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXSPt+6D9AnhBs1/TC3+te5ltXjyYCu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgylvY9YS9Y5Ftx/s819gbGdU5djJwcEgImEv3zPjFC 2GISF+6tZ+ti5OIQEjjKKLHy9zF2kISQwHJGiZPtGSA2m4CRxIuNPWBxEQFFiXMvJ7CA2MwC hhJbFywEs4UF5CW2TvnFCFGjInFw83sWCFtPYu/mW2C9LAKqEk/WPAFaxsHBK+ArMflyBUiY EeiG76fWMEGMFJe49WQ+E8RtAhJL9pxnhrBFJV4+/scKYStJzHl9jRmiPl9i1/svYON5BQQl Ts58wjKBUXgWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFylBYX5OSm GxlsYgRGxjEJNt0djPenex5iFOBgVOLhVdjTHy7EmlhWXJl7iFGCg1lJhLc0d0K4EG9KYmVV alF+fFFpTmrxIUZpDhYlcV6xR4rhQgLpiSWp2ampBalFMFkmDk6pBsaF+ttj9CN918831FDS jKy4ldg4KS1/jeDEpQd0ZpvXT5u+ouWuirm7/ONXJYHFG58y3/lrskn0wNZjk94k338Z7fh2 q3u8yc7jKscPJjQvnP/xrdChHiFzy3dK8eoZFxQXrIk6JyW3rTL4dr/sE6E36/5r+t24x/6R NadK7JKltt2T5VXumUeVWIozEg21mIuKEwFt7VCTiAIAAA== Archived-At: Cc: "rtg-ooam-dt@ietf.org" Subject: [sfc] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 07:01:13 -0000 --_000_7347100B5761DC41A166AC17F22DF11221ADA9CBeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, we had very good discussion on OAM this week. We've touched on Active, Pass= ive and Something-in-between OAM. But can NSH indicate which OAM type, if a= ny, associated with a packet? I think that the current version of draft-iet= f-sfc-nsh does not allow that and may be ambiguous in some cases. I propose= change to interpretation and applicability description of the O(AM) flag a= nd allocation of the new protocol type to be used in the Next Protocol fiel= d. RFC 7799 defines Active OAM as following: An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream. Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network's metric and should not leave giv= en domain. And, I believe, such packets should be identified by the protoco= l type of their own. OAM which behaves as much as Passive OAM or Something-= in-between, e.g. OAM appended to data packet either at the domain's edge or= on-the-fly, identified by the protocol type of the data packet carried in = NSH. Below are changes I'd like to propose: Section 3.2 O-bit: OLD O bit: when set to 0x1 indicates that this packet is an Operations, Administration and Maintenance (OAM) message. The receiving SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information). OAM message specifics and handling details are outside the scope of this document. END NEW O bit: when set to 0x1 indicates that data packet identified by the Next Protocol type has OAM metadata appended. Definition of the format(s) used by OAM metadata is outside the scope of this document. END At the end of Section 3.2: OLD This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6-0xFD: Unassigned 0xFE-0xFF: Experimental END NEW This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6: Active OAM 0x7-0xFD: Unassigned 0xFE-0xFF: Experimental END And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols. Greatly appreciate your consideration and comments. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221ADA9CBeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

we had very good discussion on OAM this week. WeR= 17;ve touched on Active, Passive and Something-in-between OAM. But can NSH = indicate which OAM type, if any, associated with a packet? I think that the= current version of draft-ietf-sfc-nsh does not allow that and may be ambiguous in some cases. I propose change to int= erpretation and applicability description of the O(AM) flag and allocation = of the new protocol type to be used in the Next Protocol field.<= /p>

 

RFC 7799 defines Active OAM as following:=

An Active Metric or Metho= d depends on a dedicated measurement packet stream and observations of the = stream.

Thus, regardless of encapsulation used by OAM, it is= the packet constructed solely for monitoring, measuring network’s me= tric and should not leave given domain. And, I believe, such packets should= be identified by the protocol type of their own. OAM which behaves as much as Passive OAM or Something-in-between, e.g= . OAM appended to data packet either at the domain’s edge or on-the-f= ly, identified by the protocol type of the data packet carried in NSH.=

Below are changes I’d like to propose:

Section 3.2 O-bit:

OLD

   O bit: when set to 0x1 indicates that t= his packet is an Operations,

   Administration and Maintenance (OAM) me= ssage.  The receiving SFF and

   SFs nodes MUST examine the payload and = take appropriate action (e.g.

   return status information).  OAM m= essage specifics and handling

   details are outside the scope of this d= ocument.

END

NEW

O bit: when set to 0x1 indicates that data packet id= entified by the Next

Protocol type has OAM metadata appended. Definition = of the format(s)

used by OAM metadata is outside the scope of this do= cument.

END

 

At the end of Section 3.2:

OLD

   This draft defines the following Next P= rotocol values:

 

   0x1 : IPv4

   0x2 : IPv6

   0x3 : Ethernet

   0x4: NSH

   0x5: MPLS

   0x6-0xFD: Unassigned

   0xFE-0xFF: Experimental

END

NEW

   This draft defines the following Next P= rotocol values:

 

   0x1 : IPv4

   0x2 : IPv6

   0x3 : Ethernet

   0x4: NSH

   0x5: MPLS

   0x6: Active OAM

   0x7-0xFD: Unassigned

   0xFE-0xFF: Experimental

END

 

And, consequently, section 13.2.5 in IANA Considerat= ions section will request allocation of value 0x6 to be assigned to Active = OAM protocols.

 

Greatly appreciate your consideration and comments.<= o:p>

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

 

--_000_7347100B5761DC41A166AC17F22DF11221ADA9CBeusaamb103erics_-- From nobody Thu Jul 21 00:15: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 7AE0512DA85; Thu, 21 Jul 2016 00:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQRohjq0DfU0; Thu, 21 Jul 2016 00:15:19 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE6C12DA5A; Thu, 21 Jul 2016 00:15:18 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-55-57906b2fa7a5 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 02.19.09012.F2B60975; Thu, 21 Jul 2016 08:26:55 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 03:15:17 -0400 From: Gregory Mirsky To: "sfc@ietf.org" Thread-Topic: Support the Alternate Marking Method in SFC Thread-Index: AdHjHeOt5MYCs4pEQT6YbhUG1CftWw== Date: Thu, 21 Jul 2016 07:15:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221ADA9FC@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/mixed; boundary="_004_7347100B5761DC41A166AC17F22DF11221ADA9FCeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyuXRPrK5+9oRwg6d7bCz+te5ltXjyYCu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgybry/wVLw+4pwxaML7xkbGGf1CXcxcnJICJhIfG16 wAphi0lcuLeerYuRi0NI4CijROv0r6wQznJGic2rp7GBVLEJGEm82NjDDmKLCChKnHs5gQXE ZhYwlNi6YCGYLQw0te/0DqgaS4mt2+ayQNh6Eo+XXgKzWQRUJWYvmsgEYvMK+Er83dIOVs8I dMX3U2uYIGaKS9x6Mp8J4joRiYcXT7NB2KISLx//g7paSWLO62vMEPWZEs8fHWCEmCkocXLm E5YJjMKzkIyahaRsFpIyiHi+xNRZTawQto7Egt2f2CBsbYllC18zw9hnDjxmwhR3kWg9PQuq XlXi94nFQDVcQPZ6RonOozehihQlpnQ/ZF/AyLOKkaO0uCAnN93IYBMjMDaPSbDp7mC8P93z EKMAB6MSD6/Cnv5wIdbEsuLK3EOMKkCtjzasvsAoxZKXn5eqJMKrWzQhXIg3JbGyKrUoP76o NCe1+BCjNAeLkjiv2CPFcCGB9MSS1OzU1ILUIpgsEwenVAOjzbPkU291GJ0MVnS8OsF+wCA/ dc7zvjq1jTMsdnL8YvoyJaQz6U+XuWYsz7w73K6blka0/pU/frVq+997VZs9k5Mnn787u7W3 T+QPR/JmqbPJTidkD1vt6b8WwRiyLCp4Ce8ih/7uO3Vqf1eyGLA/MHiRFfD8aPKivN3Cp6sz jqiJPcue9rlciaU4I9FQi7moOBEAY5Wa1tUCAAA= Archived-At: Cc: "rtg-ooam-dt@ietf.org" Subject: [sfc] Support the Alternate Marking Method in 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, 21 Jul 2016 07:15:21 -0000 --_004_7347100B5761DC41A166AC17F22DF11221ADA9FCeusaamb103erics_ Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221ADA9FCeusaamb103erics_" --_000_7347100B5761DC41A166AC17F22DF11221ADA9FCeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, in the OOAM-DT presentation I could only briefly note advantages of using t= he Alternate Marking method (AMM) at the particular network layer. Attached are slides that give more details about principles the AMM works a= nd how BIER in MPLS encapsulation supports use of AMM in BIER domain. As the OOAM-DT concluded in the draft-ooamdt-rtgwg-oam-gap-analysis Performance measurement includes measuring of packet loss, delay, delay variation and could be performed by the marking method, for example as proposed in [I-D.ietf-ippm-alt-mark]. = To make use of the marking method behave as passive OAM, as defined in [RFC7799], the overlay network encapsulation should allocate the field, preferably two bits long, whose value does not affect how a packet is treated by the overlay network. I propose to allocate, out of Reserved flags, the new 2 bits-long field to = be used for Marking method with the following format: 0 0 1 +-+-+-+-+ | S | D | +-+-+-+-+ where: o S- Single mark method; o D - Double mark method. Appreciate your consideration and comments. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221ADA9FCeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

in the OOAM-DT presentation I could only briefly not= e advantages of using the Alternate Marking method (AMM) at the particular = network layer.

Attached are slides that give more details about pri= nciples the AMM works and how BIER in MPLS encapsulation supports use of AM= M in BIER domain.

As the OOAM-DT concluded in the draft-ooamdt-rtgwg-oam-gap-analysis

      Performance measureme= nt includes measuring of packet loss, delay,

      delay variation and c= ould be performed by the marking method, for

      example as proposed i= n [I-D.ietf-ippm-alt-mark].  To mak= e use of

      the marking method be= have as passive OAM, as defined in [RFC7799],

      the overlay network e= ncapsulation should allocate the field,

      preferably two bits l= ong, whose value does not affect how a

      packet is treated by = the overlay network.

I propose to allocate, out of Reserved flags, the ne= w 2 bits-long field to be used for Marking method with the following format= :

    0

    0   1<= /span>

   +-+-+-+-+

   | S | D |

   +-+-+-+-+

   where:

 


   o  S- Single mark method=
;


 


   o  D - Double mark metho=
d.


 


Appreciate your consideration and comments.


 


        &nbs=
p;       Regards,


        &nbs=
p;            &=
nbsp;          Greg=



 
--_000_7347100B5761DC41A166AC17F22DF11221ADA9FCeusaamb103erics_-- --_004_7347100B5761DC41A166AC17F22DF11221ADA9FCeusaamb103erics_ Content-Type: application/vnd.ms-powerpoint; name="BIER-PMMM-95.ppt" Content-Description: BIER-PMMM-95.ppt Content-Disposition: attachment; filename="BIER-PMMM-95.ppt"; size=229376; creation-date="Tue, 29 Mar 2016 21:55:13 GMT"; modification-date="Tue, 15 Mar 2016 17:55:00 GMT" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAEAAAAvQEAAAAAAAAA EAAA/v///wAAAAD+////AAAAALkBAAC6AQAAuwEAALwBAAD///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8P AOgDshIAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAgAAAAAAAAABAAAAAAAAAQ8A CQTMBAAAAAAKBAQAAAAgAAAADwDXD5YAAAAAANMPBAAAAAoAAAAAALoPNgAAAGcAcgBlAGcAbwBy AHkALgBtAGkAcgBzAGsAeQBAAGUAcgBpAGMAcwBzAG8AbgAuAGMAbwBtABAAug9EAAAAbQBhAGkA bAB0AG8AOgBnAHIAZQBnAG8AcgB5AC4AbQBpAHIAcwBrAHkAQABlAHIAaQBjAHMAcwBvAG4ALgBj AG8AbQAPANcPfgAAAAAA0w8EAAAADAAAAAAAug8qAAAAdgBlAHIAbwAuAHoAaABlAG4AZwBAAGgA dQBhAHcAZQBpAC4AYwBvAG0AEAC6DzgAAABtAGEAaQBsAHQAbwA6AHYAZQByAG8ALgB6AGgAZQBu AGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA8A1w96AAAAAADTDwQAAAAOAAAAAAC6DygAAABtAGEA YwBoAC4AYwBoAGUAbgBAAGgAdQBhAHcAZQBpAC4AYwBvAG0AEAC6DzYAAABtAGEAaQBsAHQAbwA6 AG0AYQBjAGgALgBjAGgAZQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQAPANcPsgAAAAAA0w8EAAAA EAAAAAAAug9EAAAAZwBpAHUAcwBlAHAAcABlAC4AZgBpAG8AYwBjAG8AbABhAEAAdABlAGwAZQBj AG8AbQBpAHQAYQBsAGkAYQAuAGkAdAAQALoPUgAAAG0AYQBpAGwAdABvADoAZwBpAHUAcwBlAHAA cABlAC4AZgBpAG8AYwBjAG8AbABhAEAAdABlAGwAZQBjAG8AbQBpAHQAYQBsAGkAYQAuAGkAdAAP ANcPlgAAAAAA0w8EAAAAGgAAAAAAug82AAAAZwByAGUAZwBvAHIAeQAuAG0AaQByAHMAawB5AEAA ZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AEAC6D0QAAABtAGEAaQBsAHQAbwA6AGcAcgBlAGcAbwBy AHkALgBtAGkAcgBzAGsAeQBAAGUAcgBpAGMAcwBzAG8AbgAuAGMAbwBtAA8A1w9+AAAAAADTDwQA AAAcAAAAAAC6DyoAAAB2AGUAcgBvAC4AegBoAGUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQAQ ALoPOAAAAG0AYQBpAGwAdABvADoAdgBlAHIAbwAuAHoAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4A YwBvAG0ADwDXD3oAAAAAANMPBAAAAB4AAAAAALoPKAAAAG0AYQBjAGgALgBjAGgAZQBuAEAAaAB1 AGEAdwBlAGkALgBjAG8AbQAQALoPNgAAAG0AYQBpAGwAdABvADoAbQBhAGMAaAAuAGMAaABlAG4A QABoAHUAYQB3AGUAaQAuAGMAbwBtAA8A1w+yAAAAAADTDwQAAAAgAAAAAAC6D0QAAABnAGkAdQBz AGUAcABwAGUALgBmAGkAbwBjAGMAbwBsAGEAQAB0AGUAbABlAGMAbwBtAGkAdABhAGwAaQBhAC4A aQB0ABAAug9SAAAAbQBhAGkAbAB0AG8AOgBnAGkAdQBzAGUAcABwAGUALgBmAGkAbwBjAGMAbwBs AGEAQAB0AGUAbABlAGMAbwBtAGkAdABhAGwAaQBhAC4AaQB0AA8A8gOsAQAALwDIDwwAAAAwANIP BAAAAAEAAAAPANUH5AAAAAAAtw9EAAAAQQByAGkAYQBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAQALcPRAAAAEMAYQBsAGkAYgByAGkA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYiIAC3 D0QAAACLW1NPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAhgAGAgAApA8IAAAAgABAAAAAAAAAAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8K AAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAA AgAAAP//7wAAAAAAAAAAAP//EgAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANg AwAAAAAABQAAgASABAAAAAAPAAsEEAEAAA8AAPAIAQAAAAAG8LAAAAABUAAAFQAAAHMAAAAUAAAA AQAAAAcAAAAOAAAABQAAAA8AAAAGAAAAEAAAABcAAAARAAAAFwAAABMAAAAfAAAAFAAAAAUAAAAN AAAACAAAABIAAAAFAAAADAAAAAEAAAALAAAAAQAAAAoAAAABAAAACQAAAAEAAAAIAAAAAQAAAAcA AAABAAAABgAAAAEAAAAFAAAAAQAAAAQAAAABAAAAAwAAAAEAAAACAAAAAQAAAIMAC/AwAAAAgQEE AAAIgwEAAAAIhsEAAAAAvwEQABAAwAEBAAAIxcEAAAAA/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAI AQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAMAAAAAAAAAAAAAAAAAAIAAAAAADwDQB+gBAAAf ABQEHAAAAAAAFQQUAAAAupOw9gDKmjutB5THAMqaOwEBAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQA AABkAAAAZAAAANU+kABwuDQAwJw0AAgAAAAInTQAFLA0AAAAAAAAAAAAAAGQAA8A+gNnAAAAAAD+ AwMAAAAAAQAAAP0DNAAAAEMAAABkAAAAQwAAAGQAAAC8uDQAmJw0AAgAAAAUsDQAKLA0AAMAAADM /f//mv///wEANABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAA8AiBMJAQAADwCKEykA AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMgAAAIsTCQAAAAAAJQQBAAAAAQ8AihPQAAAAAAC6DxAA AABfAF8AXwBQAFAAVAAxADAAAACLE7AAAAAPANYHmAAAAAAAtw9EAAAAi1tTTwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYABgIQALcP RAAAAEEAcgBpAGEAbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQAAAANBAgAAAAAwAAAAMAAAD8A2Q8MAAAAAADaDwQAAAANAAIATwDZDwwA AAAAANoPBAAAAA0AAgAPAPAPqAAAAAAA8wMUAAAABAAAAAQAAAAAAAAAAAEAAAAAAAAAAPMDFAAA AAUAAAAEAAAAAAAAAAIBAAAAAAAAAADzAxQAAAAGAAAABAAAAAAAAAADAQAAAAAAAAAA8wMUAAAA BwAAAAQAAAAAAAAABwEAAAAAAAAAAPMDFAAAAAgAAAAEAAAAAAAAAAgBAAAAAAAAAADzAxQAAAAJ AAAABAAAAAAAAAAGAQAAAAAAAC8A8A8cAAAAAADzAxQAAAAKAAAABAAAAAAAAAAAAQAAAAAAAAAA KATCBwAAUEsDBBQABgAIAAAAIQBWrgfD9wAAAKkBAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCi BAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB8kM1OwzAQhO9IvIPlK4odOCCEmvTAzxGQKA+wOJvEqv/k3VbN2+OkRUKocLLWuzPzaVbr g3dij5lsDI28VrUUGEzsbBga+bF5ru6kIIbQgYsBGzkhyXV7ebHaTAlJFHWgRo7M6V5rMiN6IBUT hrLpY/bAZcyDTmC2MKC+qetbbWJgDFzx7CHb1SP2sHMsng7l+0iS0ZEUD8fDOauRkJKzBriQ6n3o fqVUpwRVlMsNjTbRVcGQ+mzCvPk74KR7LdVk26F4g8wv4AuGZvh0+M6TQ1L/m5yhjH1vDXbR7Hxp QKWMVN4F2Dv1w/qbXC9Ft18AAAD//wMAUEsDBBQABgAIAAAAIQDt5AxLuwAAACYBAAALAAgCX3Jl bHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAhI/NCsIwEITvgu8Q9m5TPYhI015E8Kr1AdZ0+4NpEpJV7NubYwuCx9lh vtkpqs9oxJtCHJxVsM1yEGS1awbbKbjX580BRGS0DRpnScFEEapyvSquZJBTKPaDjyJRbFTQM/uj lFH3NGLMnCebnNaFETnJ0EmP+okdyV2e72WYM6BcMMWlURAuzRZEPfnU/J/t2nbQdHL6NZLlHxWS 8WHoxpNJK0SNoSNWMDtm6VuQZSEX68ovAAAA//8DAFBLAwQUAAYACAAAACEA2P2Nj6wAAAC2AAAA DwAAAHRhYmxlU3R5bGVzLnhtbAzMSQ6CMBhA4b2Jd2j+fS1DUSQUwiArd+oBKpQh6UBooxLj3WX5 8pIvzT9KopdY7GQ0A//gARK6Nd2kBwaPe4NjQNZx3XFptGCwCgt5tt+lPHFPeXOrFFfr0KZom3AG o3NzQohtR6G4PZhZ6O31ZlHcbbkMpFv4e9OVJIHnHYnikwbUiZ7BN6qCIKK0wKfL5YhpSANcejTG cVTW1bmp/SosfkCyPwAAAP//AwBQSwECLQAUAAYACAAAACEAVq4Hw/cAAACpAQAAEwAAAAAAAAAA AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQDt5AxLuwAAACYBAAAL AAAAAAAAAAAAAAAAADADAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDY/Y2PrAAAALYAAAAP AAAAAAAAAAAAAAAAABwGAAB0YWJsZVN0eWxlcy54bWxQSwUGAAAAAAMAAwC3AAAA9QYAAAAAAADq AwAAAAAPAPgDdYMAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAACADQAYADwByAAAAD///8A AAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAGAA8AcgAAAA////AAAAAACWlpYAAAAAAPvfUwD/ mWYAzDMAAJlmAABgAPAHIAAAAP///wAAAAAAgICAAAAAAACZzP8AzMz/ADMzzACvZ/8AYADwByAA AADe9vEAAAAAAJaWlgAAAAAA////AI3G/wAAZswAAKgAAGAA8AcgAAAA///ZAAAAAAB3d3cAAAAA AP//9wAzzMwA/1BQAP+ZAABgAPAHIAAAAACAgAD///8AAFpYAP//mQAAZGIAbW/HAAD//wAA/wAA YADwByAAAACAAAAA////AFwfAADf0pMAzDMAAL55YAD//5kA06IZAGAA8AcgAAAAAACZAP///wAA M2YAzP//ADNmzAAAsAAAZsz/AP/nAQBgAPAHIAAAAAAAAAD///8AM2aZAOPr8QAAM5kARopLAGbM /wDw5QAAYADwByAAAABoa10A////AHd3dwDR0csAkJCCAICeqAD/zGYA6dy5AGAA8AcgAAAAZmaZ AP///wA+PlwA////AGBZewBmZv8Amcz/AP//mQBgAPAHIAAAAFI+JgD///8ALSAVAN/AjQCMe3AA j18vAMy0AACMnqAAAACjDz4AAAABAP/9PwAAACIgAABkAAAAAP8BAGQAAAAAAAAAAABAAgAAAAAC AAAA///vAAAAAAAAAAAA//8sAAAAAAMAABAAow98AAAABQD//T8AAQAiIAAAZAAAAAD/AABkABQA AADYAAAAQAIAAAAAAgAAAP//7wAAAAAAAAAAAP//IAAAAAABAACABQAAEyDUASABAAACABwAgAUA ACIg0AJAAgAAAgAYAIAFAAATIPADYAMAAAIAFACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8A AAAiIAAAZAAAAAD/AABkAB4AAAAAAAAAQAIAAAAAAgAAAP//7wAAAAEA//8BAP//DAAAAAABAAAA BQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABAAKMPbgAAAAUA //0/AAAAIiAAAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAAAAAAD//xIAAAAA AQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IA AAAFAAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkA AAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUA AAAAAAAAAAACABwAAQAAAAAAAAACABgAAgAAAAAAAAACABQAAwAAAAAAAAACABIABAAAAAAAAAAC ABIAgACjDz4AAAAFAAAAAAAAAAAAAgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMAAAAAAAAA AgAQAAQAAAAAAAAAAgAQAAAAIwTSBgAAUEsDBBQABgAIAAAAIQCR783y+wAAALsBAAATAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbHyQyU7DMBCG70i8g+Urip1yQAgl6YHlxnIoDzByJomFN3ncqn17JmmR KlQ4jWb9/vmb9d47scNMNoZWrlQtBQYTexvGVn5uXqp7KahA6MHFgK08IMl1d33VbA4JSfB2oFZO paQHrclM6IFUTBi4M8TsoXCaR53AfMGI+rau77SJoWAoVZlvyK55wgG2rojnPZePSjI6kuLxODiz WgkpOWugsFK9C/0vSnUiKN5cZmiyiW5YhtQXCXPnb8Bp752tybZH8QG5vIFnGbrPpMlx8RWosHPn yUr9f/aC7jgM1mAfzdazJyplJI7LC96pM9DPL3qxvvsGAAD//wMAUEsDBBQABgAIAAAAIQCO6ir6 vgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYjQgxfRD1iSbRtsk5CN on9vjhYEj8Mwb2bq9jVP4kmRrXcKqqIEQU57Y92g4HY9bfYgOKEzOHlHCt7E0DbrVX2hCVMO8WgD i0xxrGBMKRykZD3SjFz4QC47vY8zpizjIAPqOw4kt2W5k/GbAc2CKTqjIHamAnF9h9z8n+373mo6 ev2YyaUfFZIna+iMnChmLMaBkgIT+dtYiKrI+0E2tVz8bT4AAAD//wMAUEsDBBQABgAIAAAAIQC2 5YlroQMAACkjAAAhAAAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7JrNctowEMfv nek7eHTNULD5sGEwmSSdnHJgmuQBhJHBjSx7JCUNPfUd+gZ9jd76KH2SrmQBNtity6STMvhmkLSS f17v/ndhfP4cU+uJcBElzEf2uw6yCAuSecQWPrq/u255yBISszmmCSM+WhGBzidv34zTkXy+lStK hAUmmBhhHy2lTEfttgiWJMbiXZISBmNhwmMs4SNftOccfwLTMW07nc6gHeOIIbOe11mfhGEUkPdJ 8BgTJjMjnFAs4fhiGaVibS2tYy3lRIAZvbpwpIm6vUhSou9wMsYj+kTtdMotTBfAKZAcWVxSHyle +IZd8gd9HSZMXugpMywIspaYLeB+p48skGqCMiXS4JKE5moaSOsJa0Ptybi9M3oRyt/MM6NzEn6A k4nPPur1OmaPhEbz64hSvVw9D3JFebaTfHaQ2Ss/S0FkllylJMQBPOmz+GOLSjUTjwjeGSA4GwjE zkAgjO3sVPqWDDtlCC6d08J4wSNMkRUsMRdE+4AmWgBXOgd8ochQgTMMuw1DcKYDGCpwhmGvYXgY QwXOMOw3DA9jqMAZhgPFMMb8BsJ334W0iMqSzE5iUWuPJI+UBreDXl5FykBzt9CGts56DbROaeZV pAw0bwvN7rr2oHG1dT7ey7UKlaE2zFHzHM9rqFVSU6hA8RW1czqaJfPVnpDOIl635wwV0IjNQYj7 qLX+ItPZIJxeVmVDeIXtDlXas8crkHFay/no55dvmQbO6e+uCt86NueVta6H8vrbXp8gP2tff7Mq /c1aFfqbtWrq74y+C/T7efqO13fVF8dA/+sefUe9m/+AfkFnnsWVkHcFegbZtntd5XRbH3ccLxd7 j83HnXo15l/7eF3KuxLeUAaiWjttIskxUS7xZeUyr+jLuyI/o+x0+q56/Mfoyz++7weMV4ZcXgU4 fbun48OfXbl2VfCCee8/5FheGDhD19ZqreFY7NJVJrDyWiGTZLVe+sYfdYuzvHroet6gZopqOGqO m3oiV0Gko0QuCd/UE6C+p1mtZnQ4hZa7jwhr3d8amb2dsu7iZ9ksL3Rhzh2e3UIPfd1P2Cs8bGRp jb7t9he7+7bO1+YUqhufRZ8HwtUvK8dVGRQ7USBRT5ZPuahfO8mmUDpZPhVyvNhfOmUHKlfSdrGV dMqAKlSwLpKbEA0pq0Leuj3dbto2a042BlXoVki5ulhtgnSFIB303WIj6mQ9aKM08+JSNbLNf1wm vwAAAP//AwBQSwECLQAUAAYACAAAACEAke/N8vsAAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCO6ir6vgAAADgBAAALAAAAAAAAAAAAAAAA ACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQC25YlroQMAACkjAAAhAAAAAAAAAAAAAAAA ABMCAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwUGAAAAAAMAAwDJAAAA8wUA AAAADwAMBLAiAAAPAALwqCIAABAACPAIAAAABgAAAAYEAAAPAAPwTCIAAA8ABPAoAAAAAQAJ8BAA AAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPAGAQAAEgAK8AgAAAACBAAAAAoA ANMAC/BmAAAAfwABAO8BgAAATFwDhwABAAAAvwAAAAYAgQEEAAAIvwEBABEAwAEBAAAI/wEBABkA AQICAAAIPwIAAAMAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ 8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAAAQCQAA8ADfBYAAAAAACfDwQAAAAAAAAA AACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACq Dw4AAAAhAAAABwAAAAAACQQJBA8ABPBKAQAAEgAK8AgAAAADBAAAAAoAAMMAC/BgAAAAfwABAO8B gABA5VwDvwAAAAYAgQEEAAAIvwEBABEAwAEBAAAI/wEBABkAAQICAAAIPwIAAAMAPwMAAAgAgMMY AAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAzAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQAAAA AADDCwgAAAABAAAAAgCQAA8ADfCiAAAAAACfDwQAAAABAAAAAACoD1IAAABDbGljayB0byBlZGl0 IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxldmVs DUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoPDgAA AFMAAAAHAAAAAAAJBAkEDwAE8FcKAAASAArwCAAAAAQEAAAACgAAwwAL8GAAAAB/AAEA7wGAAOD3 uAO/AAAABgCBAQQAAAi/AQEAEQDAAQEAAAj/AQEAGQABAgIAAAg/AgAAAwA/AwAACACAwxgAAAC/ AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADQAAAATACLxFQkAAKnDDwkAAFBLAwQUAAYACAAAACEA 8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpuger RxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO 3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1 Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1 JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD/ /wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPR vXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8 WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZt tzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au /+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhAC1Up5moBAAADgwAABAAAABk cnMvc2hhcGV4bWwueG1srFbbbuM2EH0v0H8Q+Foolmz5ilUWvm4XcAMjzmKfaYmK1VCkSlG2k6L/ 3kNSjp3sFfH6wabM0XDOmZkzfPf+UHBvx1SVSxGT8CogHhOJTHNxH5NPdwt/QLxKU5FSLgWLySOr yPvr3397V46q0sPLohqVMdlqXY5arSrZsoJWV7JkAnuZVAXVeFT3rVKxiglNNQ4qeKsdBL1WQXNB ruFK7NblSplVcrNbKS9PEUvQxtmCFjj1liWI4Z4zLyKtxsy9QRHGUiYPVRML/ZlYUkX3APgiDE/I DwpIQpwpp1ucxsZKyf2W0bQyf+Pclo3vGKpApCaWcuvpxxJRphpcPSEAyjMCDIeYtJvXnC3ePyGt gNjb7P+SKV6ltZZggo4OmSouhWL8yCzzcH7U7YNp4j3GpNeOuu121wRER+ygvcTEF3Y6PWOQwCLq 99rdwEbsAjGWpar0ByYvDsozjmKikEkLlO6WlTacno4wxwm5yDm/lAGLkYtL3ZwCcoFyYbnLMoBA 9Je6P2biF7iycSGntcpj8u8wGM4H80HkR+3e3I+C2cwfL6aR31uE/e6sM5tOZ+F/JgthNNrmacrE Oelh9EUPFXmiZCUzfZXIooXayhPWaroIrRwGx1ZGO0qep8adCcnqAZty5e0oR5UnCSTAtdILy9bL SGxVoERfoQrbUTBpD/1Fb9D3o0XU9Yf9YOAH4XAy7AXRMJotXqJa5oIdk/R2VN4+JsMuOsci+g48 ffgKNDoqcs2Ux/MiJoPAfFwLGmGZi9QWgaY5d+szJkz0X2divOgG/agz8Pv9bsePOvPAnwwWU388 DXu9/nwyncxf5Xdua/ZZJN9Ohk3JsQHMg6yBbr1N916amwbvdIdtaGiaK6hL3+H1KL/HdEm0Ip6S +nOut+stNZIZOFLN2DiVyebeyeaZc8fD6dwzmhpoJ6agKKgdNBX+MlPKqbQ+TGT6aCLe4BfS62bX 2+cFhibgbqV6It5eUYyO6p+aKkY8/lFgYgzDKIKwavtgdRjgz3c25zuiLqYSLQLqqEjgNSaYJm45 1XgyGi2LkuqlWJeJMTRYjKjeHT5TVTb6qgH9Rlp2rcErmXW2litHg3HCK73WjxiuF1Jife14aBmn o5Rlt+DZTMQwQtXbbcx/YcdlRhPkf6xyyoFsS1XFQGfTG0n1Ixsk2fm3WPjxVPx9RGPp+RWQzJwu qFraHGBxaxc40v7mAvJpI2+qHHAQ2R3drAHcFgFSp7SzZnQpJurB5jmTQo9tY2xoZcrGcNNs4xVz BcElZVWLBO5durnJvQFWlckq0U5Vw2dRMejPLCYse217nO54/7Q7zqzSnvs8s2t2NzVk/O5g5WpT r5+elwvAeH64wSWxUbQNOtAuXZ6wRHhNaTCRrqiipjwe6iIv5N8YW8DMgTkmTPif1u4qZQvH2zim 7XcdE4FDzK1U5Q8oISHXdkW8B6bMHdZeeBLTkI2haRc4F+Y2yvMn9qd9NKRzSGyzt1JSZmZty9QO encXcYG70f+94fYN9WdH0bJc1EvRcFWbGdmsbeZ/VPFQNXpm80chfEbdKPmpdjlx7jKB73J0VEUr lNf/AwAA//8DAFBLAwQUAAYACAAAACEAxhtBLtgAAAD8AAAADwAAAGRycy9kb3ducmV2LnhtbESP TUsDMRBA74L/IYzgRWzWClW2TUsRq4I92Fpoj+Nm9gM3kyVJu9t/7+BBj8Mb3sybLQbXqhOF2Hg2 cDfKQBEX3jZcGdh9rm4fQcWEbLH1TAbOFGExv7yYYW59zxs6bVOlRMIxRwN1Sl2udSxqchhHviMW VvrgMMkYKm0D9iJ3rR5n2UQ7bFgu1NjRU03F9/boDCxfCB/4/mbdv+9Ctd4/H1btx8GY66thOQWV aEj/y0c/KdH/wV/Vm5WWbCy/l6/nr9DYDcZEwYDkSaxA0PMfAAAA//8DAFBLAQItABQABgAIAAAA IQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0A FAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0A FAAGAAgAAAAhAC1Up5moBAAADgwAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQ SwECLQAUAAYACAAAACEAxhtBLtgAAAD8AAAADwAAAAAAAAAAAAAAAAD/BgAAZHJzL2Rvd25yZXYu eG1sUEsFBgAAAAAEAAQA9QAAAAQIAAAAAAAAEPAIAAAAXg8gAWAGihAPABHwUgAAAAAAwwsIAAAA AgAAAAcBkAAPAIgTOgAAAA8AihMyAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMUAAAAAACs DwwAAAAAAAAAAAAAAAAAAAAPAA3wUAAAAAAAnw8EAAAABAAAAAAAoQ8WAAAAAQAAAAAAAAAKAAcA AQAAAAAAAgAOAAAAqg8KAAAAAQAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8H4KAAAS AArwCAAAAAUEAAAACgAAwwAL8GAAAAB/AAEA7wGAACD3uAO/AAAABgCBAQQAAAi/AQEAEQDAAQEA AAj/AQEAGQABAgIAAAg/AgAAAwA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAg ADUAAAATACLxKwkAAKnDJQkAAFBLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50 X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm //EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIe aEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3G lEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991 VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAA AI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++ pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6 JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s 3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP// AwBQSwMEFAAGAAgAAAAhAEe0Gnu8BAAALwwAABAAAABkcnMvc2hhcGV4bWwueG1srFbbbuM2EH0v 0H8g9FoolmT5ilUWtmNvC7hBEGexz7RExWokUqXo2EnRf+8ZUr4k3e4ukvpBJsXR8MwZzhl++Liv SvYodFMomXjhReAxIVOVFfI+8T7fLfyhxxrDZcZLJUXiPYnG+3j5808f6nFTM3wsm3GdeBtj6nGn 06QbUfHmQtVCYi1XuuIGU33fqbVohDTcYKOq7ERB0O9UvJDeJVzJx1V9o2mUXj/eaFZkwBJEI49J XmHXW5ECw30pWM/rtGbuCw4YS5U+NC0W/iNYMs13CPAFDCbVJ41IQuypZhvsJiZaq91G8Kyh19i3 Y/EdoEogJSz1hpmnGihzo0HWc+L9ueXaCEyKbJ943fZTZw8fp2gbRM3Wu99Vhs/51iiwwcf7XFfv DYf8qDxntH8YxaDbY0+J14/iXhRZEvlY7A1LYRANR70+GaSwiAf9qBdYyA4Jeap1Yz4J9W5UjBwl nkY6baT8cdkYIva0BW0n1aIoy/dSAL98XMr3ujkBckBLSW9EniMIoH+ve4sSmfgfXFlcyOlWF4n3 1ygYzYfzYezHUX/ux8HVlT9ZzGK/vwgHvavu1Wx2Ff5NWQjj8abIMiHPSQ/jfxVSVaRaNSo3F6mq OjhcRSo6bSmhnsPgUM+oSVUWGbkjSFYUxKzU7JGXOOZpCh1w9fTCsvMSiT0VIOZVVDjMwTQa+Yv+ cODHi7jnjwbB0A/C0XTUD+JRfLV4GdWykOKQpLdHxXaJN+qhcmxE3wjP7L8SGh9XBQSBlUWVeMOA flRhfEzqMpeZHRtelG58xgSh/zoTk0UvGMTdoT8Y9Lp+3J0H/nS4mPmTWdjvD+bT2XT+Kr9ze2aP Svl2MmxKDgVAE7VFdKtNtmNZQQXe7Y0iCGlWaKjLwMXLeHmPFpOSSGplvhRms9pw0s3AkUq943RM 1vdRK0JH546H075nNLWhnZiCoriiwitqVU6qzX6qsidCvMY/tNc1sLc3DXROhLtR+tljO83RPxoS f+Gx8jeJtjEK4xjCauwk7g0iTPT5yvp8RW6rmUKJgDouU3hNPHMYzgxmpNGqqrlZylWdkiHFQqJ6 t//Cdd3qq0Ho18qyaw1eyayztVw5GshJ2ZiVeUKHfScl1tdjGVJnO2Wc3mYiv8VLapBhjAKwlrgP SNs+c57iKEx0wUsEueG6EWC2LZO0+Z4N8u3827BKB8CN28Bou8ON5c0Jt04QRMX10qYDg1s7wJb2 v5BQUov8LHwGbHd8vULo9kTQKTDOXvClnOoHm/RcSTOxVbLmDZ0hYqddxid0KcG15WYrU2zgcl/S QSBUTZ3epMZJbHhUGNBybjEV+WvbQ6vH96fVSW5l99znmV27ut5C0+/2VrvW29XzcbhAGMfJNa6N rbyt0ePs0GUKQ+r7VJl87B5g9mFbFZX6Ax0MEZeIOPGE9D+v3M3KHhy2dkzb5zbxJLagW6ouHnCE pFrZkccehKY7rb37pFSbrSFVDpxLup2WxbP41U6J8hJq267daKVyGhM61/PdtcTBdm++1ef+oxEc Lw6Wie1StkxtqV22Y5v37514CBw/s/mlkr7grqv8ULloR7y5ZO5HyUDW8UQuKDF41uODYloRvfwH AAD//wMAUEsDBBQABgAIAAAAIQASWR3Y2gAAAPwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9PSwMx EEfvgt8hTKEXsVkraLs2LbVYK9iD/QP2ON1MN4ubyZLE7vbbGzzocXjD+/Ems87W4kw+VI4V3A0y EMSF0xWXCva75e0IRIjIGmvHpOBCAWbT66sJ5tq1vKHzNpYiSTjkqMDE2ORShsKQxTBwDXFiJ+ct xnT6UmqPbZLbWg6z7EFarDgtGGxoYaj42n5bBfNXwke+v1m373tfrj9fDsv646BUv9fNn0BE6uL/ s+ma1ej5D/6q3nRqyYZjEKfV5egrvcEQyStIeSk2QZDTHwAAAP//AwBQSwECLQAUAAYACAAAACEA 8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA BgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQBHtBp7vAQAAC8MAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsB Ai0AFAAGAAgAAAAhABJZHdjaAAAA/AAAAA8AAAAAAAAAAAAAAAAAEwcAAGRycy9kb3ducmV2Lnht bFBLBQYAAAAABAAEAPUAAAAaCAAAAAAAABDwCAAAAF4PsAfQDooQDwAR8FIAAAAAAMMLCAAAAAMA AAAJApAADwCIEzoAAAAPAIoTMgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAAAArA8M AAAAAAAAAAAAAAAAAAAADwAN8GEAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAAElFVEYtOTUAAKEPGAAA AAgAAAAAAAAICgABAAcACAAAAAAAAgAOAAAAqg8KAAAACAAAAAEAAAAAAAAApg8MAAAA8AAAANQB 0ALwAxAFDwAE8M8KAAASAArwCAAAAAYEAAAACgAAwwAL8GAAAAB/AAEA7wGAAED4uAO/AAAABgCB AQQAAAi/AQEAEQDAAQEAAAj/AQEAGQABAgIAAAg/AgAAAwA/AwAACACAwxgAAAC/AwAAAgBSAGUA YwB0AGEAbgBnAGwAZQAgADYAAAATACLxdQkAAKnDbwkAAFBLAwQUAAYACAAAACEA8PeKu/0AAADi AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3Y NgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuL er0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6 QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0 kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQA BgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+F XksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSR DNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqj M5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C /Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhAApyQyUIBQAAPQ8AABAAAABkcnMvc2hhcGV4 bWwueG1s7FbBbts4EL0vsP8g6LpQLdmSZRtVClu2uwW8QVCn6JmWqFgbidRSdOKk6L/vG1KOnWy3 Leoem4NDSqPhvMeZN/P6zb6unDuu2lKKxA1e+a7DRSbzUtwk7ofrpTdynVYzkbNKCp64D7x131z8 /tvrZtI2Dj4W7aRJ3K3WzaTXa7Mtr1n7SjZc4F0hVc00tuqm1yjecqGZxkF11ev7/rBXs1K4F3Al 7tbNlaJVdnl3pZwyRyz+AMEIVuPU9zxDDDcVd4ZurzOzXzCEsZLZbdvFwr4nllyxewB8FoYj5FsF JAHOlOkWp/GpUvJ+y1ne0mOc2zPxHUIViJRiabaOfmgQZVvll7safD0m7j87pjRXLqDsEzfsvraf wM0RcAvgzub+L5nDA9tpCULYZF+o+lxE5EcWhYPzh1E0AOOu84B1P4z6/YgiYhO+104Gg34wGAzJ IINFGA/7kW9CtpGQZaNa/ZbLs6NyyFHiKtyoQcruVq0mbo9H0HFCLsuqOpcCg7ES57o5BmQDrYTh rigAAtGf6/5wEz/BlYkLd7pTZeJ+GvvjxWgxCr2wP1x4oT+fe9NlGnrDZRBH88E8TefBZ7qFIJxs yzzn4pT0IPxPLdVlpmQrC/0qk3UPyVVmvNdVE0o68A8ljbKUVZmTOwrJ6AJPK+XcsQppnmWQAltS zyx7zyMxWYEUfYEq6If+rD/2lsNR7IXLMPLGsT/y/GA8Gw/9cBzOl89RrUrBD5f046ic+8QdR6gc g+gr8PT+C9DYpC4hCE5V1ok78unPliAJzELkJgk0Kyu7PmGCov8yE9Nl5MfhYOTFcTTwwsHC92aj ZepN02A4jBezdLZ4cb8Lk7NPYvnjZJgrORQAbeQO6Nbb/N7JSyrwQTTuQ0vzUkFdYovXYdUNukym oYtK6o+l3q63jKTTt6RS+zimyeam34nQk3PLw/HcE5o6aEemoCjIHRQVHlG3smqt9zOZP1DEG/yH 9toe9uN9A80TcLdSPbrOvWJoIS2JP3ed6p1A5xgHYQhh1WYTRnEfG3X6ZnP6RuzqVKJEQB0TGbwm rj4sU40dabSsG6ZXYt1kZEhYSFSv9x+Zajp91YB+KQ27xuCFzFpbw5WlgZxUrV7rBzTZMykxvu6q gDqbvXFlYsh58R6PqD0GIdLf2GEgEKZ/FixDIkxVySpA3DLVcvDaFUnWfssGt239G1CVPd6uO1iG p5+BjXDVTK3MZWDx3ixwpPlfCuioifwJvIPIrtlmDeAmGygDtLXmbCVm6tZceCGFnpoK2bCW8oe4 6V7jE5pJMLVc7UQG9/beK0oCAtY22VWmrbwGT+oCUk4tZrx4aXto8/j++HZaGMk99Xli173d7KDn 13ujW5vd+vFpuQSMp80lpsZO2jYoRbO094Ql9XyqSjYpqtwMfZ/C4cKfx9HSm8cpJC2aQtwxmnjz aJTG8SDyl+niM6qpG7hKcI2Ri1wo3Mrtri5r+Td6H/iqwFficuF9WNuZzCSds7G3ZH53iSsQII24 qrxF+gm5NivXueWKBmIzNWVU1Z0h1RycCxptq/KR/2m2dGEVdLp7d6WkLGhNgdlpwQ40FrR98rUO +T8thB+Uz/C4W4mO5x012m5tsuZb1QJpZCc2f9TC48z2o+8qNZBN0H5VArHwUytBXzhUF9S0TFnQ AVzkV0wxEs9fGY6C+r6ecV6GHzm3OoXfZnIYHsw8cfEvAAAA//8DAFBLAwQUAAYACAAAACEA/iPo 69gAAAD8AAAADwAAAGRycy9kb3ducmV2LnhtbESPwUrDQBBA70L/YRnBi9iNFqzEbksVq4It2Fqw xzE7TUKzs2F3bdK/d/Cgx5k3vOFNZr1r1JFCrD0buB5moIgLb2suDWw/Fld3oGJCtth4JgMnijCb Ds4mmFvf8ZqOm1QqkXDM0UCVUptrHYuKHMahb4mF7X1wmGQMpbYBO5G7Rt9k2a12WLN8qLClx4qK w+bbGZg/E455dLns3rahXH4+7RbN+86Yi/N+fg8qUZ/+j3V4sKvwB39Vr1ZaspHE7F9OX6G2a4yJ ggHZSKxA0NMfAAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAA AAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAA AAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAApyQyUIBQAAPQ8AABAAAAAA AAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA/iPo69gAAAD8AAAA DwAAAAAAAAAAAAAAAABfBwAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAGQIAAAAAAAA EPAIAAAAXg8gEGAVihAPABHwUgAAAAAAwwsIAAAABAAAAAgCkAAPAIgTOgAAAA8AihMyAAAAAAC6 Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMUAAAAAACsDwwAAAAAAAAAAAAAAAAAAAAPAA3waAAAAAAA nw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGAAAAAIAAAAAAAAICgACAAcAAgAAAAAAAgAOAAAA2A8E AAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8DwAAAASAArw CAAAAAEEAAAADAAAYwAL8CQAAACBAQAAAAiDAQUAAAi/ARAAEAD/AQAACAAEAwkAAAA/AwEAAQAQ APAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE2kAAAAPAIoTKQAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAyAAAAixMJAAAAAAAkBAEAAAACDwCKEzAAAAAAALoPEAAAAF8A XwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAEwPNAVAdSfoAAA4EQQ4AAFBLAwQUAAYACAAA ACEA6d4Pv/8AAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctOwzAQRfdI/IPlLUqcskAI JemCx47HonzAyJkkFsnYsqdV+/dM0lRCqCAWbCzZM/eeO+NyvR8HtcOYnKdKr/JCKyTrG0ddpd83 T9mtVomBGhg8YaUPmPS6vrwoN4eASYmaUqV75nBnTLI9jpByH5Ck0vo4Ass1diaA/YAOzXVR3Bjr iZE448lD1+UDtrAdWD3u5fmYJOKQtLo/Nk6sSkMIg7PAktTsqPlGyRZCLsq5J/UupCuJoc1ZwlT5 GbDoXmU10TWo3iDyC4wSw7AMiV/PZyAZLea/O56J7NvWWWy83Y6yjnw2XsxOwf8UYPU/6BPTzH9b fwIAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SPz2rDMAyH 74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAWmqoGw+JD P8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDSSkXbNGIk f6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9kKhlqtQe 0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3RoZW1lL3Ro ZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl44M3zt8U 1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh 7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEA8y2epskIAAC2NwAA FgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1uPo8YSfo90/gPiPRkuBsNovRFX5SFRop09Os89 NrbJYmwBe/v3qeqbaeNp8A5KcrS2pTFuF9XVVfVVVVczb37+cqiMT0XTlsd6Zdo/WaZR1Ovjpqx3 K/O/7/MfA9NoO1JvSHWsi5X5tWjNn9/+54c35LHbF4fCgPvr9pGszH3XnR4fHto1DJP2p+OpqOG3 7bE5kA6+NruHTUM+A99D9eBYlv9wIGVtGjU5ANu02JKPVWekRVvuavOtYJ9VMEfdtTiwrponZF5c vcew6V2bDzbSts3uOaka4xOpVqZFX+bD2zcP5JETVN2QLqcvTscJNh+cMX6UoOqGdIGFb8mPEpD1 GtYznDuOMytzOW2PiF0OebvwCkOFvsffHcisrI0xpUTscjGgV3TWI2KX3oA+jbI0yxV5KBGj9wf0 TuqkQaTQU6J9VdYfBtSWFcKLU0uS7bH65Sp5GCaJJRR/pgLrSx/CKbbHutN4lIk0B/LnscmBEL9U pCtro/t6Am9dg9dGTUkqlIo8FqQ3zobWbW9IkoIQCs9DWc8/wZknTHdeJl30QV3z79ttuS7oWrdl VT11X6vi15Yutz1W5SaHQbyP4rqQmDrt4ZIbRKHbNYTeYzTH7n9lt3/akxOoiqFz13LWu9Y4HVuA Jp34Km+cFNTdMQx76JBMry3pfjtu2LDbh7ZkQ4G+o0FDTOQig6mTucvXTWYzqV5Um7o0m4pGvUhZ mlwy2HC4NBiU2gQQGAQDtu1DZEXZjXZNqmKDemdhT5gFpxbXs5io3ZNNwW2E6x7ayKZGEr5CIzj4 zhUbBVR0rdZ6s4XI9hWzTTFSf7rFC9MJ673GSiJWCctQ5VzCsar74Kxq4/PKDD3HM401Oa3MLUQn uDycwOptvTMNUu0gpa+7hrn9KJip4s/WDMXCwPt6iLMtMT5YsBIHTk3bpaTdM9egP3EXqGqcicnv eKDWuRbAPP0bpHADcIZ/TArQo2raYrst1l3f2L0R1B37ykPp8WNXNE/7zWfjufrYvCNgfnRVWM+m bLuVSSMCfmlWJmqb/qQGZx4Yr9RMOBupTnvCwy1CVCCZkVNXlTLQbz3xYG1XZaeLu30pFPIzLaXv xt/ZUjCfFHXhbtACayjAG2IgXlfmsen2R4hCp325zhsoe2jsAG8xILpgujZgG0A/m+ITfjLMMR7I rSp3++5duTOaEvJRt2+K4g8IS9T7RpjZPHcxloIR9aieuO2Jif1cfCqq9xgDfcztprEHV6fRhIcB Snfpf+p3jqDnHRY5fbwpMUTmXoaBv7vyYWCGRalxmBY0Qv9SRKottfJh99PbRe7tLwR/OJdZC4EK mKyXCkIO+28U4cZUyyLWYMWOJ4QDKw5XDIOyIDqRbm/gH8h/ZbOuzvXt++M7iK0G7AqRGbgNePWP rPAwMECywWconNggcyZkxVTLq1vUmkjWs5RRZxPIeS+UjZJNsfeNypbFmTqdgsU5lc01rOiajb2o arDsJURhaCs2MtQwtBnR7xYcn/8EQ/O+QkudqfjSNQRKzyeKAw5+dRDtuhYU9z7Dyrz3GXAD/bo+ AzjUb+RkPO/slQltJYg5X+AKGlEmjDk45uAYXEG3Cep21iJamfxCjMDvbETSuGLEFTQLMbIQI54Y gX0Cb8aIER+SJvZPoHeHH6YhFgqbCb5knt+HIBmOjMDGoZXEv6k9F/r4FpsS1r/jKqfZsl8O53Ga eze05/I8DH3Bm1sNmbLLv789l6dZEqvya9tz2TKIvITrhrsNyi97b0qDNUlcSCOcWpIIHxooE1Uj yc9UENOlD+E9d9jsasP918Hmlq42NmJztStMW989RFw40oDe+Sdhk0SZcyG/FjZxGIfZcipsMLcm AmTjsIlyfymFucNGexi0eDVs4DTDz0X3dIbDoJuyTf8gimFFC5sgTXzpGT1sscthtsmSPMpVN531 MOjKYZMWNss8dqfDBs4O/RtgY1kRbKk4Ju+w0cLGezVs0PSpOKmbATZL+uLW44esPUQo2YO6nerW Wthg9JWONAE2yD8Ta+thi12+/gyVyq+eiWph46SYb6Zmmzz3oHXPqcezDVawd9jA0wa8FGVNg+st AV8DGy/yAq70WR496D1SwJ9NuPboAbqSPDAfgQ3E04XvKG6khY2f+nmiwkxbpEVRYiXC8SbAJo3w rchDscVupYhQYB9FcRCr8mhh4zv+Il4o/LWPHqAuOfU4bCwrz2+EDd3005YAbQ7QlgBtDtCWAG0O sKVD04BfiK38/3dLYPkibLzEPmtxBtjQnqpwQQ1s0jx1QrFNHoGNsunldjnvVSgiFDeNs2XoCxkY vRY2iRXBS3FTbZF2K2wyB1Cm8tfCJkr81FNbGhrYKAFoHDapGzm2SGXTirTvFjbBi7CxLNeVXacZ YIMnDjKLaGCDm3YZI0dggxJeFF3abGNZ8fncYwJsEDSJ6tazwiZK4yBTs6UWNqDBcyhj8mtgg7qR mhyHDdSjS8vmMeIOG+3eJnwRNuiSPTen7si3LkoERyeXxplhb5O5WdxrMfSyARVBmRuhLWWckG0W fhAtYiV79PgPWwIIm4tsMC9soii9gKUWNm6+TBciE88OGyuDI8c7bIoJexubPRzEs4nik8refIZ0 4wd+7KXcLJp0k9qpnQjfHkk3oRVagRqutekmsMIsEhu2CekGduBRrFZFs+Im8eEtIjyTR4ubpRvk oSq/Jt3keZLIgmE83WRhmsiGwz3daNON/fL/I7gQ+OXh2hy48ZX8ReM8h4WC14v81csHw3zjW164 FBibkG9ABF/mxim4CeLgIh/MipsYQkkstu0TcOMlXjK9Ba2ca43jBhUvk/cdN3rcvPygAPzPiGV7 Mj+8uk7zHDdzROzW5Zs8sQKRl0byTZAs46UoLSbgJsi93FH9tIfLYZ0Wu1EeiTNDxn9W3CSAmljF vTbfBLbnOep2S5NvkiSGxxG5BcdxEySQjAX594QbeBRCfcCGPqwGo/Qxt7d/AQAA//8DAFBLAwQU AAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54 bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6HYb6ZabuXnckT YzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIOJ0qTnNCKVPmA rjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFBc9mFBSiixszg I5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAOneD7//AAAAHAIAABMAAAAAAAAAAAAA AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEApdan58AAAAA2AQAACwAA AAAAAAAAAAAAAAAwAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAa3mWFoMAAACKAAAAHAAA AAAAAAAAAAAAAAAZAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQItABQABgAIAAAA IQDzLZ6myQgAALY3AAAWAAAAAAAAAAAAAAAAANYCAAB0aGVtZS90aGVtZS90aGVtZTEueG1sUEsB Ai0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAA0wsAAHRoZW1lL3RoZW1lL19y ZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAFAF0BAADODAAAAAAAAA8EOgEAADw/ eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxh OmNsck1hcCB4bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvZHJhd2lu Z21sLzIwMDYvbWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFj Y2VudDE9ImFjY2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2Vu dDQ9ImFjY2VudDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJo bGluayIgZm9sSGxpbms9ImZvbEhsaW5rIi8+sAAeBOAFAABQSwMEFAAGAAgAAAAhAE2O8/z9AAAA uwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsQwDEX3SPxDlC1q0mGBEGo7Cx4rBCyGD7AS t43IS3E6mv49aWeQAA2sLD+uz7Wb7cFZtsdEJviWb0TNGXoVtPFDy993T9UtZ5TBa7DBY8tnJL7t Li+a3RyRWFF7avmYc7yTktSIDkiEiL50+pAc5JKmQUZQHzCgvK7rG6mCz+hzlZcdvGsesIfJZvZ4 KOWjk4SWOLs/Di6slkOM1ijIxance/2LUp0IoijXGRpNpKtig8uzhKXzN+Ckey2vSUYje4OUX8AV G1InkmRL8RnmMOUfyUb8v/aM79D3RqEOanLlJyImpBLXE5wV30Bft8j19d0nAAAA//8DAFBLAwQU AAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2I IHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFM DG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSz qUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBL AwQUAAYACAAAACEA8AjbFK0CAAC2BwAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQx LnhtbLRVTW8aMRC9V+p/sHxPFjZAyAqIWtr0kg9USO+u12SteG3LNlv49x3bayIIlZZWveyHPfNm 5r0Ze3K7rQVqmLFcySnuX/YwYpKqksuXKX5e3V2MMbKOyJIIJdkU75jFt7OPHya6sKK8Jzu1cQgw pC3IFFfO6SLLLK1YTeyl0kzC3lqZmjj4NS9ZacgvwK5Flvd6o6wmXOLW33TxV+s1p+yLopuaSRdB DBPEQf624tomNN0FTRtmASZ4H6bkdhqqBWLcijvBPslytcUo2JsGdvp4BhTQpSiRJDUs/ABTTolA wR4BY2jFti6YWb0yjHkH2XwzeqkXJng/NguDeOnRWhSctRutWfiVYAYf2ZH7S0IixXZt6tmEFMAO 2k4xiLjzT3AiBSSBaFykb6u0ejphS6uvJ6yzFAAy2AcF/XWs6H05eSrniJT+vrzoQwDjXtFXi6SC gj0PsU762CRUX7yPoysUNXFeD4yU4aBclKj1iqaBpuRtA9Up/z1Bo1F+M+hFmvLrwehqfMhV3hte h33P2HA87A/zYQiSkCBIhNaF235W5c4z/RPeIKhvmilmxBcfYYV1S7cTLOgBrJECSoIHGAviB43J i+clDFrt5oIRGMRWOzebC05fkVOIldyhB2IdMyhQAGMJkBMQx0FvtJBMlgtiyPcjZM8qKSAy5J3y DSV4Zv+s49V7HX03LQShrFKihFRyXyEMQhLsryT1xB0pCmMBPZv6obuyg+E1HCyh/08JO+r1b8Z+ /38JC/2GRCP2Cv6j0J7uoLM9EDqKGRSFRwoZ2Dqjt5aMKjimBGuY6AAfpD4DflVx0x39Ko5KZ77u 1Ma4qnPyg3Ph+fokOpynZ49YmLR4A8CnvzPCyAjzQPRTEyqG2xIGex6WNNyP7TH4ZuIx0n07+w0A AP//AwBQSwECLQAUAAYACAAAACEATY7z/P0AAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAAC4B AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDwCNsUrQIAALYHAAAhAAAAAAAAAAAAAAAAABUC AABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAAQUAAAAA oAAeBJwFAABQSwMEFAAGAAgAAAAhAE2O8/z9AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1s fJDLTsQwDEX3SPxDlC1q0mGBEGo7Cx4rBCyGD7ASt43IS3E6mv49aWeQAA2sLD+uz7Wb7cFZtsdE JviWb0TNGXoVtPFDy993T9UtZ5TBa7DBY8tnJL7tLi+a3RyRWFF7avmYc7yTktSIDkiEiL50+pAc 5JKmQUZQHzCgvK7rG6mCz+hzlZcdvGsesIfJZvZ4KOWjk4SWOLs/Di6slkOM1ijIxance/2LUp0I oijXGRpNpKtig8uzhKXzN+Ckey2vSUYje4OUX8AVG1InkmRL8RnmMOUfyUb8v/aM79D3RqEOanLl JyImpBLXE5wV30Bft8j19d0nAAAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9y ZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6n UbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciF D+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbP lLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEAoEAd0mkCAADWBgAAIQAA AGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbKxVTW8bIRC9V+p/QNyTzUdVVSvbkeo2 veTDqp3epyz2orCAgGztf98H7CZK6kq22gvLwsxj3psZmFxtO8166YOyZsrPT884k0bYRpnNlD+s rk8+cRYimYa0NXLKdzLwq9n7dxNXB93c0M4+RQYME2qa8jZGV1dVEK3sKJxaJw321tZ3FPHrN1Xj 6RewO11dnJ19rDpShg/+/hB/u14rIb9Y8dRJEwuIl5oi4g+tcmFEc4egOS8DYLL365DizoEthImr LWfZzvdYOeczUBdL3TBDHRZWKmrJIBD7AWMlSLOV3MZsFtzKS5kcTP/Nu6Vb+Ox91y88U01CG1B4 NWwMZvnXwAyT6o37ZkSierv23WxCNVRh2ylH8nZphBPVCIKJsiheVkV7v8dWtF/3WFfjAYjg+VDk 3RVGf9K5GOkUUc6fWRVTguuNFY+BGQueiX6hJ+76ESxxTvCuZSUFMek72JXNrMdoH6BpFituP9tm l4j/xDcvUq1DXMadllkQhE01wDFAfk2pwqU5eViiwrs415LQAYN4cTbXSjyyaJlsVGS3FKL0LAeD fgDkBOpEJGeAlKZZkKfvb5ATP6pxMoIeI8S0SPh3IS9HIV/VFFtoErK1ukEoF/9D3CQVZ9YrNEGp do66RNGMmTlG8XSNAEVSCjpFt09/pIvpXj8L/Y/5SEWe0xFe5aNonoXHMB6ZSR1RAkspLPpay17q A+BzRo6AX7XKH45+WRQ9WK9r++Rje3DwH46FV+u96Lh3ju6E3BDlpsQ03a35MtT+ltx9nxnjNUH/ zfOSw/uR+gqmLyYJY3yPZr8BAAD//wMAUEsBAi0AFAAGAAgAAAAhAE2O8/z9AAAAuwEAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4 AQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAoEAd0mkCAADW BgAAIQAAAAAAAAAAAAAAAAAVAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsF BgAAAAADAAMAyQAAAL0EAAAAAJAAHgR1CAAAUEsDBBQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAA W0NvbnRlbnRfVHlwZXNdLnhtbHyQy07EMAxF90j8Q5QtatJhgRBqOwseKwQshg+wEreNyEtxOpr+ PWlnkAANrCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTxQ8vfd0/VLWeUwWuwwWPLZyS+7S4vmt0ckVhR e2r5mHO8k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu6xupgs/oc5WXHbxrHrCHyWb2eCjlo5OElji7 Pw4urJZDjNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPLs4Sl8zfgpHstr0lGI3uDlF/AFRtSJ5JkS/EZ 5jDlH8lG/L/2jO/Q90ahDmpy5SciJqQS1xOcFd9AX7fI9fXdJwAAAP//AwBQSwMEFAAGAAgAAAAh AHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2 wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox 5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+z fddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgA AAAhAKFeA4dCBQAAsRAAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWysWF1v 2zYUfR+w/0DodWgd+TtGnaLN1m2Amxq1iz3TEhVroUiNpFwnv37nUpQlZe1guHlxJPLykPfec++h 8ubtsZDsIIzNtVpG8euriAmV6DRX98voy/bDq3nErOMq5VIrsYwehY3e3vz805tyYWW64o+6cgwY yi74Mto7Vy4GA5vsRcHta10KhblMm4I7vJr7QWr4V2AXcjC8upoOCp6rKKw356zXWZYn4ledVIVQ rgYxQnKH89t9XtoGrTwHrTTCAsav7h/JPZbwtsyT7TFi3swcMBBHN/A82ciUKV5gYJ0nrjKCfc3d nt3yks7hbWy5NUKQtTr8bspNuTZ+6d1hbVieElSAiAZhIpj5VwUzPAyeLb9vkPjimJni5g1fICLs uIyQuEf6xSK+EEfHknowaUeT/adv2Cb7375hPWg2wAlOmyLnZe3Rf90ZNu5scycFi09e1aYcS1c6 ebBMafhJ7tfuJXeHBox8Jvhyz+rwO4IKdvWkj0djb31Mm4OeIhHProfDOXgLz8dzsOzqWVQm4/l0 jEFGsZlMp7PR3G/SIGGTGrpcuON7nT5SSHf4i8xxlew1mLqjFXwhrdu4R4k84/kgY5yIcXmPUpJg AV+kIvuMIfu0jMB3bLlrPD/ZI8l9HISYLxAI/GCp5FSJQr36skElFu5WCg744JK7uZV58sCcZiLN HfvIrROG+cChbnEyQnd+Dw8pVLrmhtOhusiUC77AzvC98dmHgfLx/aSPmqQ3ZbCWPBF7LVMcYkgh QrE0Cb6IAqjACOUCLjeEuYwI03g4m03qpDXV0ePBOI6JLGcTAT3TocVo8xSxr4aD0fafihsRMfmn ssvoOh6PkW/nX8aT2RAvpjuz686oqrjV0jeFhmEuCmS7deAbsVUXJXcrtSkTMiSClMa67fEvbkr0 KIvzOPh2pzd7XgpvwA8r60JyT7Y+1zWfCeRbHC64WflNc5WiQdIjme6qO6iAZ36H2SNQO8Qt1ICH PcghlUMN5SMAJ87BG7Z5AB6BBLxRi+fDey4eFXsdBOARSMAbt3jxaBZTozjvgFTKJ0BCCYCTDuAc PegyQEIJgNMWED0NB7zohIQSAGcdwNnYZ+4ClwklAM5bQELzffWsJPdiSCgB8LoDOJ3MLkwKoXie d9ntO2sLj1iCnJ89z0GMZ3w/9XEGqm/5boMe3rDOuNpa8JV6bx78ykwr9863/h231AZwq1Dt9B59 HBefdaWSUzlJqmVy25bJOnHswKkFIDAtvToW70X23JY0pWEiMFqLdxl6fh+3Yxdmd9WtNNujL+dd tXk6PX6AK6eXU8U7vqubSSNrdQWEzHWE5aEq8kL/ndeB7ekXYlhzDjpIVPa/1TJSaCt00TT5Ay5V Sm/8U8QehPFixxLqsMGK+h8WK7pWyvxJ/OFfKeoypzuqn1sbrTP/3BVNzzFFv0p/yKUMRexHrJZ5 SoM+cnSFFYhPnRR3rOUHIe1aiSwTiWuiUq1UiFpFMOHZ88BfaDJo4zL6pVCvpKP2gXsafzYheD2R 2GcTiQ0Np43zZZI9biR7SzLY1esR7fCjek2ygkQiz3susyDd/iaA68Rl0j0Z4YZWX9Ham21Pu+dX uNHVm5xxh/OR77aFIFpBqYiWZ4he3BMVuvh5bl0senFPRH9c9KiNBMq8jOhdd/FeQPN6eC8geT28 F1C8Ht4LCF4P7wX0rof3/3IXxM0T39P08g8Lahr+u8L2Piy+9/HgvyHqD2E80nezbzHSfOTlp4M/ C/5RgE8WdFoMlVBInJJMWxPCaP7VcPMvAAAA//8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAAALsB AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDw ONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAKFe A4dCBQAAsRAAACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQx LnhtbFBLBQYAAAAAAwADAMkAAACWBwAAAACAAB4EIQcAAFBLAwQUAAYACAAAACEATY7z/P0AAAC7 AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOULWrSYYEQajsLHisELIYPsBK3 jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL33dP1S1nlMFrsMFjy2ckvu0u L5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusbqYLP6HOVlx28ax6wh8lm9ngo 5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OEpfM34KR7La9JRiN7g5RfwBUb UieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3yPX13ScAAAD//wMAUEsDBBQA BgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYgg eBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwM bbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOp QNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsD BBQABgAIAAAAIQDa39dV7gMAAMsNAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEu eG1szFfLkps4FN1P1fyDin1iA8Z2U22napzHptPpGjsfIIPcMBESJdSOna+fI4HcwDgx7s5iNhiL o8N9nXvF7btDwcmeqSqXYuH5b8ceYSKRaS4eF97Xzcc3c49UmoqUcinYwjuyynu3/POP2zKueHpH j/JJE3CIKqYLL9O6jEejKslYQau3smQCz3ZSFVTjr3ocpYp+B3fBR8F4PB0VNBdes18N2S93uzxh 72XyVDChaxLFONWwv8rysnJs5RC2UrEKNHZ31yR9LOGt3P6zOXjEwtQeC763hOfJmqdE0AILKyk0 GMj3XGdkRUtjh8VU5UYxZtBi/0mV6/JB2a33+wdF8tRQNRTeqHnQwOxfARhuRr3tj46JxoedKpa3 NEZEyGHhIXFHc8UmGrODJkm9mDyvJtmXM9gk+3AGPXIvgAWnlyLnZe3Rf90JnDubXHNG/JNXNZRi 651MvlVESPhp3K/dS+73jsz4bOjLjNTh14aqwdUPbTwcvrIxdYaeIjGJZqgtG45gFo6jXkzC8Xge +qFHTGR8fxo0iLbHNXMZ68NfMj2aiG7xi8RRkWQShbqt48wrvdZHjjTTmO+5D4MI5Y9QEkcR0Dhl u7+xVP1YeDAJNm2d4yc8coz7Fg8iTGPEARds5dQIkYk3X9cQYqFXnFHQNz7p5YrnyTeiJWFprsln WmmmiI0bZAvLDLu277CUTKQPVFFjVJvZpILGeDPi63zGbZ3tn+ccQeyq4IHThGWSpzAieF0F5Cnq 1xXJ8OSH0SwyCTViOJf9yPd9IOrsR/Mo9FEKtfu1oKzbdR26SLjsW2m1U9WkvJfp0FRfTdkC4DZo 6rVdFfM21gGADc9gJ22sAwA7OYM11XaywQGAjS5hHQDY6SWsAwA7u4R1AGDnl7AOAOzNJWwNOKch 7CRgOInllZoyPdVKqupoqtaNFQ8u7pW2cK+Q8ZolUqSEsz3jA+ittq6g32S5Gs5uBXEF+0f5pDD9 hho/MYV5DX2+O8uOMfdbu9nEdbONSXW7ldmAYOy7UfWiYWYmCFo4RkFG+c7DGQANzibSDjXTcuzN 2la8ab5m6VfTzZ+EkV/r/Hnkd8bbZHrjj6evbnCkoOrOHjFykeK0Y26NadunexwKbTZbPc3v9Ckz Ew0WSjTtraFyM3oQX6ef9npkw3fjT8xbySC+Tm/s9dGGzw9n/nQo4c0veq3jmwdz0+oHGdjh6/Xj hi8I5jDvJXy9nu34ZhM7tq63r9fXGz5DNjghHX97vd/xTaPZy/Lx/5gPULY7TdgDhtW6+0TAivmi sF8BXH2m5Ze9lQw+oXCaW9mlEh9NZp4D+gwxVO4jbPkvAAAA//8DAFBLAQItABQABgAIAAAAIQBN jvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG AAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG AAgAAAAhANrf11XuAwAAyw0AACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAABCBgAAAABwAB4EdQQAAFBLAwQUAAYACAAAACEA TY7z/P0AAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOULWrSYYEQajsL HisELIYPsBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL33dP1S1nlMFr sMFjy2ckvu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusbqYLP6HOVlx28 ax6wh8lm9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OEpfM34KR7La9J RiN7g5RfwBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3yPX13ScAAAD/ /wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2 btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4E J3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z 0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kA AAD//wMAUEsDBBQABgAIAAAAIQD/7vRhQgEAAHACAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDEueG1sjFLLTsMwELwj8Q+W79QtB4SiJpV4XoBWavmAxXGaCL+0dkPy92zcBATqoRdr PZ4Z73i9XHVGs1ZhaJzN+WI250xZ6crG7nP+vnu6uuUsRLAlaGdVznsV+Kq4vFj6LOjyBXp3iIw8 bMgg53WMPhMiyFoZCDPnlaWzyqGBSFvcixLhi7yNFtfz+Y0w0Fg+6vEcvauqRqoHJw9G2Xg0QaUh Uv+hbnyY3Pw5bh5VIJuk/ttS7D2l/dBgPzlLNGwJWPCCksutLpkFQ8BdYgxg8DtUaqhs+4x+6zeY uG/tBllTDtpRw8V4MNLS1hKNCvFPvp+cIOsqNMUSMnoC1uWcJtUPK4kgU11k8gjKX1TW6xNcWT+e YIvpAurg51Kqp1hUDrFT5xpfwa9bygcZzTkqvE+Qp8keM8hfyuAx/ZTiGwAA//8DAFBLAQItABQA BgAIAAAAIQBNjvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxz UEsBAi0AFAAGAAgAAAAhAP/u9GFCAQAAcAIAACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAACWAwAAAABgAB4EDwUAAFBLAwQU AAYACAAAACEATY7z/P0AAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOU LWrSYYEQajsLHisELIYPsBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL 33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusb qYLP6HOVlx28ax6wh8lm9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OE pfM34KR7La9JRiN7g5RfwBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3 yPX13ScAAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EK wjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlv rOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+ YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi 7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQC4Uh7Y3AEAAMIDAAAhAAAAZHJzL3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDEueG1sjFPLbtswELwX6D8QvCeycygKwlKAOG0vSWzUzgdsqbUlhCIJ cqNKf98lJSVtmkMufCxnhzvD5eZ66IzoMcTW2VKuL1dSoNWubu25lI/H7xdfpYgEtgbjLJZyxCiv q8+fNl5FU9/B6J5JMIeNCkrZEHlVFFE32EG8dB4tn51c6IB4G85FHeA3c3emuFqtvhQdtFbO+eEj +e50ajXeOv3coaWJJKAB4vpj0/q4sPmPsPmAkWly9r8l0ehZLbVkcGfNKEWGhp6Da1mxen0wtbDQ ceCYUCLD0kn0x4CYVrb/EfzB70NOeOj3QbR1IpgTZTEfzLC8tQzjRfEm/bwwgRpOoas2oNgLMZSS n2xMIyeBwoGEnoL6Naqb3TtY3Xx7B10sF3AFL5cmVZOi/+VcLXImH9YvqiYocOqd009RWMc6k/xJ nn7oF7KkOdH7Rvxl/IybDrMfCz6yp9ksGm5cPSbhv3jOQVAm0oFGg9kQLhsUk/PA9htIfY324vHA fd3R1iBw38/mUbU1rX4S5ATWLYl7iIRB5C7gX8CUG3aH+HFmSrT1HgL8fMOc9IHim7nopUJeJgvz NPUHL1MT5RYw4R78rs918s/hW7c55PmvzG69QhLH8veqPwAAAP//AwBQSwECLQAUAAYACAAAACEA TY7z/P0AAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA BgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQC4Uh7Y3AEAAMIDAAAhAAAAAAAAAAAAAAAAABUCAABkcnMvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAMAQAAAAAUAAeBKQHAABQSwMEFAAGAAgAAAAh AE2O8/z9AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsQwDEX3SPxDlC1q0mGBEGo7 Cx4rBCyGD7ASt43IS3E6mv49aWeQAA2sLD+uz7Wb7cFZtsdEJviWb0TNGXoVtPFDy993T9UtZ5TB a7DBY8tnJL7tLi+a3RyRWFF7avmYc7yTktSIDkiEiL50+pAc5JKmQUZQHzCgvK7rG6mCz+hzlZcd vGsesIfJZvZ4KOWjk4SWOLs/Di6slkOM1ijIxance/2LUp0IoijXGRpNpKtig8uzhKXzN+Ckey2v SUYje4OUX8AVG1InkmRL8RnmMOUfyUb8v/aM79D3RqEOanLlJyImpBLXE5wV30Bft8j19d0nAAAA //8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q 9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80e BCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/ GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5 AAAA//8DAFBLAwQUAAYACAAAACEA8BdhJXEEAABAFwAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQxLnhtbOxY25LaOBB936r9B5XfEzCYy7gGUrXsZl8mM1ML+QBhi7E3tuSVBQP79dvd ssBcnPKQVCVVywsI+ei4L+qjRvcftnnGNkKXqZITz3/f9ZiQkYpT+TLxPi8+vht7rDRcxjxTUky8 nSi9D9Nff7kvwjKLH/hOrQ0DDlmGfOIlxhRhp1NGich5+V4VQsKzldI5N/BTv3RizV+BO886vW53 2Ml5Kr1qvW6zXq1WaSR+V9E6F9JYEi0ybsD+MkmL0rEVbdgKLUqgodXHJpldAd6aV7XYLl7V0/Jv jxFYb2Da96bgfzTPYiZ5DhMzlRdcp6WS9KQsFloIxMjNn7qYF8+aFjxunjVLYySoFnqd6kEFo58S YDDonCx/cUw83K50Pr3nIUSDbSceJG2Hn7CIh2JrWGQno8NslDxdwEbJHxfQHfcCsGD/Ush3YT06 d6fn3FmkJhPM33tloRyWPqjoS8mkAj/Rfete9LhxZOgz0hcJq0KPVBXOPqR4OHwJMaVgme1vKt6h 40v4pkkeZqWZm10GKYDxJvMpATyMxeovG9raNHhbh4OTPART4AOSlXGsAyHffZ5DHeRmlgkOdVKF 2kxnWRp9YUYxEaeGfeKlEZoZikKJBtwDu4FUVpRCxs9cczDiiBmjwUN4M7jo/IGhDXhz2Pv7sGPO nzMeiURlMVjQ+x4ZwHh6sF1hL7mENSQCo3WyJYPBCAqc9qU/6A98v48mHXZn0A26/hjEBffosH83 GpLNEAZLRO7bLeEi4jLMuIwSBWqxtJT17FXJZjnXD1QXqYyhwHGIb1+uH0HFyBC7F1j578TrBWjp 0rlZ2xs07MHuqQidV61Yu+esSIV2gJn9A+udH5AFbVj98TkrUlWswYHV74/8IYJb0RLyOATIVdEO arTj3phsuJYWuSra4YG21xuDCd9gLXJVtKMa7Sjo0z681lrkqmjHB1rkbJ+yC7FFror2rkY7HIy+ KWXIRVpSrwlSNHwJ7Lq9dNHbr1c4FBwSuPJI4a5RscCp2ExJA7V6JGSkGnDUuoPijUcJVnfCs1Ul Y1Zi8FilMOGgfp5gQpplrOePgvFo8BUZ698NfCgORLTRMZKheqLOTqqDOlnKGgCGTkzqSoYltMc6 AGCdRNSwpCR7rAMA1tV9HYu7co91AMC6Ym7EOgBgXYU2Yh0AsK7sGrEOAFhXS41YBwCsLRDXCVB8 SST3vv0cFUTNAHy4oqXz9w1tyVxESsYsExuRXSjQU3qqizfQL5JUt2evTv7WivNRrbVJWhsf2Ips T5+uLrJDb/Jdu7OB07XFaXdGFl8varY/tt0ZCtw/a66h7aw0jqJNrXJrjRsGg24PzIVOrKlX80eg fLdebeLdejXol2+92sTr/x97taHTtEu9GrVG18vauZSRTl4tZU392kHKbv0axvy4/7n1aw13Ol/9 x3PaUN36NbxCs/8GT2PzI/s1ulWyd7MwxAtcun7N9CdePG2ohYR7a2imZjRVwE01/jMA6AGCHO7m e/ofAAAA//8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAA AAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAPAXYSVxBAAAQBcAACEAAAAAAAAAAAAA AAAAFQIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAADF BgAAAABAAB4ESgYAAFBLAwQUAAYACAAAACEATY7z/P0AAAC7AQAAEwAAAFtDb250ZW50X1R5cGVz XS54bWx8kMtOxDAMRfdI/EOULWrSYYEQajsLHisELIYPsBK3jchLcTqa/j1pZ5AADawsP67PtZvt wVm2x0Qm+JZvRM0ZehW08UPL33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISI vnT6kBzkkqZBRlAfMKC8rusbqYLP6HOVlx28ax6wh8lm9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7 /YtSnQiiKNcZGk2kq2KDy7OEpfM34KR7La9JRiN7g5RfwBUbUieSZEvxGeYw5R/JRvy/9ozv0PdG oQ5qcuUnIiakEtcTnBXfQF+3yPX13ScAAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAAL AAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjm zUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK 1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJo DV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQDkFXWcFwMAAHEN AAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1s7FfLctowFN13pv+g8T4xD4cQ D5CZ0qabPJhCPkCxRexGljyS4kC/vkeyRQghBSZdsgFZPjq699yH5MHlouCkYkrnUgyD9mkrIEwk Ms3F4zC4n12d9AOiDRUp5VKwYbBkOrgcff0yKGPN02u6lM+GgEPomA6DzJgyDkOdZKyg+lSWTODd XKqCGjyqxzBV9AXcBQ87rVYvLGgugma92me9nM/zhH2XyXPBhKlJFOPUwH6d5aX2bOU+bKViGjRu 9VuTzLKEt+ZF3j38DojDqQoz7WAE15MpT4mgBSZmL5KMpTCgca90OVOMWZCofqpyWk6UW3FbTRTJ U8vQrAzC5kUDc48CMAzCjeWPnonGi7kqRgMaQwmyGAYI2NL+YhGN2cKQpJ5MXmeT7G4LNsl+bEGH fgNYsNoUsS5rj9670/HuzHLDGWmvvKqhFEuvZfKkiZDw07pfu5fcVp7M+mzpy4w0sluqBle/dHp4 vIamTiyz+CbTpXX8Af9uksZcm6lZcuYEgdk0Bjl+ID+nNquZOLmfIqsLM+aMIusb8cxozPPkiRhJ WJobckO1YYoY55e2lAOoYxCchpKJdEIV/bXBbP2jMXaG0d5CDGsJPxay64VssolMOE1YJnkKIzqf k1X/QTVQPg+QgUgPH4MPtLVybWRZdHaOenWp1u61Wnbs9PUJF7W6fcwHxKZddNY5u+h1XQA9kxOg DrPXZGvU7N684m1XNjRO2dzKa+3v9OtNoe0aAMPOFmy0jvUAYLtbsK11rAcAG73Htt/Y4AHAnu3C egCwvV1YDwD2fBfWA4Dt78J6ALAXu7A1wGrdlJMNjKsmrCRgWJXNJ6vLZpArLv2muuoK2tzSJe4B BT1liRQp4axifA96V2UH0M+yXO3P7griAPYr+axMtrfxUV2Re4fjKp9vZccp8l/7WvSvvuY0wXnq D4MDj4uNvubi544K22ncYP3M2NbXelH/2NhwIhwbW3xsbKuL0LGxNRc291df6DG01353Z+fqhpZ3 leu1+NDBNXHspkp82tjrH6CvEMvhP5VGfwEAAP//AwBQSwECLQAUAAYACAAAACEATY7z/P0AAAC7 AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBw 8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDk FXWcFwMAAHENAAAhAAAAAAAAAAAAAAAAABUCAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 MS54bWxQSwUGAAAAAAMAAwDJAAAAawUAAAAAMAAeBGYGAABQSwMEFAAGAAgAAAAhAE2O8/z9AAAA uwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsQwDEX3SPxDlC1q0mGBEGo7Cx4rBCyGD7AS t43IS3E6mv49aWeQAA2sLD+uz7Wb7cFZtsdEJviWb0TNGXoVtPFDy993T9UtZ5TBa7DBY8tnJL7t Li+a3RyRWFF7avmYc7yTktSIDkiEiL50+pAc5JKmQUZQHzCgvK7rG6mCz+hzlZcdvGsesIfJZvZ4 KOWjk4SWOLs/Di6slkOM1ijIxance/2LUp0IoijXGRpNpKtig8uzhKXzN+Ckey2vSUYje4OUX8AV G1InkmRL8RnmMOUfyUb8v/aM79D3RqEOanLlJyImpBLXE5wV30Bft8j19d0nAAAA//8DAFBLAwQU AAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2I IHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0BkfvSMFM DG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSz qUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8DAFBL AwQUAAYACAAAACEAA7J4UzMDAAALCQAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQx LnhtbJyW227iMBCG71fad7By35KEQyAqVNru6aLbooU+gHEMRHWcyHZZ2Kfff5yEQ5dKiBswzsw3 5yF399tCsY00Ni/1OIhuw4BJLcos16tx8DL/fjMMmHVcZ1yVWo6DnbTB/eTzp7sqtSp75LvyzTEw tE35OFg7V6WdjhVrWXB7W1ZS49myNAV3+GlWnczwP2AXqhOH4aBT8FwHjb65RL9cLnMhv5birZDa 1RAjFXfw367zyra06hJaZaQFxmufuuR2FaK1UvyUPAuYFzQbXEXBBLGLmcqY5gUuZlKQcUaC0vin tpobKUlOb36YalZNjVd62kwNyzOCNMpBp3nQiPmfGmI4dN6pr1oST7dLU0zueIpssO04QNF29Akl nsqtY6K+FIdbsX4+IyvW385Id1oD8GBvFPWu6oj+Dyduw5nnTkkW7aOqRTlUH0vxapkuESeFX4cn njYtjGImfLVmdeodoRq5+qHPRytvfU5bR/eZSOK4G3V9Onq9cDAK3yUlSZK4h0tGqYm6gzhM+t5I S4KRGl2lbvulzHaU0gW+UTmuxbpElzrS4KmybuZ2CnXGeaMieMS4WmGMFLqAp5lc/saV/TsOYBI2 F77wgiMDXKnGbKOJcp8SkWyeIiX4AERxmkepb15mmMfCPSjJYaiJzk0eVC5emSuZzHLHfnHrpGE+ hZhe+Eh05214pNTZlBtO7h2TqSo8hWVkoY3eJ4Qq83H5ke96FObUe1PFhVyXCsPAYgoS09LW+apO oOwHGBv0dNs4VzVEPAoHCZrDF6+dktOG6IdhNEyaytRDdklDLGrmuYYouHn0A5rrDJuGjlTTxdsT 1qn35KhNsBJ9RakV6oYiWRxj6q0a1esnEEM+LuBFw2MeQRpe98AbRRiUS3mDYx5BGl7vwIu6SURi lzlIpuuuQ5REaYD9I+AwHlIcVwCJ0gAHB2AcD+HgVUCiNMDkCJj0upfX5CRkojTA4QFItMuLcgIk SgMcHQEH/eTKohDl/HIiPKq230Le7vXLiibS7yp7sqw+Wkh+Luu/WRzp/9hvGmV+8ep5433BKwjW 4IO/qvDSQY0G0YMIMdqXmMk/AAAA//8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAA OAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAAOyeFMzAwAA CwkAACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBL BQYAAAAAAwADAMkAAACHBQAAAAAgAB4EggUAAFBLAwQUAAYACAAAACEATY7z/P0AAAC7AQAAEwAA AFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOULWrSYYEQajsLHisELIYPsBK3jchLcTqa /j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFY UXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusbqYLP6HOVlx28ax6wh8lm9ngo5aOThJY4 uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OEpfM34KR7La9JRiN7g5RfwBUbUieSZEvx GeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3yPX13ScAAAD//wMAUEsDBBQABgAIAAAA IQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZ tsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1Vca MeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/ s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAI AAAAIQCLO1bETwIAAJ8GAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1srJXL btswEEX3BfoPBPeJbKcoCsF2gLpNN3kYtfMBE3JssaFIgqRV6+87pCQHSV3ARrrRg5q5nHs4pKbX +1qzBn1Q1sz4+HLEGRphpTLbGX9c31x84SxEMBK0NTjjLQZ+Pf/4YerKoOUttHYXGWmYUMKMVzG6 siiCqLCGcGkdGvq2sb6GSK9+W0gPv0m71sVkNPpc1KAM7/P9Kfl2s1ECv1mxq9HETsSjhkj1h0q5 MKi5U9Scx0AyOft1SbF15NY+/eIsB/mGXsd8Tr7FSktmoKaBtYoaGdFhC2siKeWA4NYeMYWa5od3 K7f0Oe++WXqmZNLp83nRf+jD8quhMHoo3qRvByUo9xtfz6dQEgy2n3FaszZdKQlK3EcmukHxMiqq hyOxovp+JLoYJqAKDpPScrvO0d92JoOdDsf44KoLBUq9teI5MGPJZ7Lf2RP3zSCWPCd5V7GOfExk +7juY+YxxAdimmHF/Vcr22T8ie55EEod4iq2GjMQKhtKEqcL4deQGhvNxeOKGruOC41Ajd/Di/OF VuKZRctQqsjuIET0LBdD24Akp0Qn0uL0kmjkEjz8fKOc/EFJM1PRQ4X02CH8N8irAWTfTWypQWBl taQiJu/DqiQ1xUD+PxClBWC60Qd07ySc2jYDDq8IdxQzSroMU2YbZyzqCoWlPaqxQX2CfCZ9hvy6 Uv509au0jmeo39idj9XJxX86V15tjqrTSXJ2b+cW784+ekznZD7etL8D99DkDqHfAu2oRR5y9CNI O4VCX0KSxvBjmf8BAAD//wMAUEsBAi0AFAAGAAgAAAAhAE2O8/z9AAAAuwEAABMAAAAAAAAAAAAA AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAA AAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAiztWxE8CAACfBgAAIQAA AAAAAAAAAAAAAAAVAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAAD AAMAyQAAAKMEAAAAABAAHgQbBgAAUEsDBBQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbHyQy07EMAxF90j8Q5QtatJhgRBqOwseKwQshg+wEreNyEtxOpr+PWlnkAAN rCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTxQ8vfd0/VLWeUwWuwwWPLZyS+7S4vmt0ckVhRe2r5mHO8 k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu6xupgs/oc5WXHbxrHrCHyWb2eCjlo5OElji7Pw4urJZD jNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPLs4Sl8zfgpHstr0lGI3uDlF/AFRtSJ5JkS/EZ5jDlH8lG /L/2jO/Q90ahDmpy5SciJqQS1xOcFd9AX7fI9fXdJwAAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+ AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2 783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDI FMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUev nxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAKgZ IVjoAgAAtwgAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWyslttuozAQhu9X 2newuG8JhABFSSpt93DTQ7RpH8AFJ0E1xrIdNnn7nbFNSLtdqUK9ScDMfPb8v8cwvz40nHRM6boV iyC6nASEibKtarFdBE+PPy/ygGhDRUV5K9giODIdXC+/fpnLQvPqlh7bvSHAELqgi2BnjCzCUJc7 1lB92Uom4NmmVQ01cKu2YaXoH2A3PIwnkzRsaC0Cn68+kt9uNnXJvrflvmHCOIhinBpYv97VUvc0 +RGaVEwDxma/XpI5SqjW1IazgNgw1cFAFCyh8nLNKyJoAwOPGEHWvK6YfaTlo2IMg0T3S8m1XCmb cd+tFKkrJPjMIPQPfJi9FRAGF+Gb9G1PosVho5rlnBYgBDksAvDriL+QRAt2MKR0g+UwWu4e3okt dz/eiQ77CWAFp0nBaukq+recuC/HCRGdqnKhFFJv2/JFE9FCnVi+K6+873oY1ox4uSNO9dIoS/Oh 7rmVpE/RVtZ+rScx0nyWT5wicTSdJPHstS5ZlsUJBqA6UZJNJi7ivGqHloU5fGurI6r6DP/WFVpw bdbmyJlVGzShBawcfsBbTrFjmLh4WkPHNOaGMwod5Z0xyxtely/EtIRVtSF3VBumiLG7RyNyDosw 4LxHMlGtqKK/35BRPFrAzCBHv0K4dP7836Vp79J6/+zmjD/DKL1/dkbBzoZt13v7ccOiaRal3rFp nqdwJrx2LAW7rKXWsWwWY7QTwTWCLd7tn16Pdx1Dm3jHI9g4pKHq1nZOLSrofntJ+Rbcgp0HXQyA /T2cdtblim3ABDelB3hWPLCSWYZLJyOASPHA6QC8ihK7UUcAkeKByQA8KT2CiBhPnJ0R8zi31owg IsYT04EYxznYO05GxHhidkbMkulYYxDjiflARNxYZxDjiVdnxHSW2R4YoSNi7InQH0yI/4RzCRr7 M48m26TuvQiX+Pa0rz6u7qh86Kwm8LkAB+KNHZLwgYANB6FDCDL6D47lXwAAAP//AwBQSwECLQAU AAYACAAAACEATY7z/P0AAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQCoGSFY6AIAALcIAAAhAAAAAAAAAAAAAAAAABUCAABkcnMvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAPAUAAAAAAAAcBAQAAAABAAAA IAC6DxwAAABEAGUAZgBhAHUAbAB0ACAARABlAHMAaQBnAG4ADwDwA9ZIAAABAPEDCAAAAAAAAIAC AHgADwAMBLY1AAAPAALwrjUAANAACPAIAAAABwAAAAcgAAAPAAPwUjUAAA8ABPAoAAAAAQAJ8BAA AAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAIAAABQAAAA8ABPCeCAAAEgAK8AgAAAACIAAAAAoA AIMAC/BaAAAAfwABAO8BgACg4moFvwAAAAYAvwEBABEA/wERABkAPwMAAAgAgMMqAAAAvwMAAAIA SABlAGEAZABlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAxAAAAEwAi8WIHAACpw1wHAABQ SwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfv gu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ3 1vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7Ene VNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA /tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9ts e6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxz pJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniO BtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3P OWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9U DLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQAw6zmZ 9gIAAB4HAAAQAAAAZHJzL3NoYXBleG1sLnhtbKRUUU/bMBB+n7T/YPl1gjaIDYhIESABkypUUfgB l8RpsjrnzHa7tr9+d3YCZQ8DQR/Ss332fffd3Xd+sWm1WCvrGoOZTA7HUigsTNngIpNPjzcHp1I4 D1iCNqgyuVVOXky+fjnvUtcJuowu7TJZe9+lo5EratWCOzSdQjqrjG3B09IuRp1VTqEHT4FaPToa j3+MWmhQTugpXM+7mWWruF/PrGjKTB5JgdBSyDsFpbJipqFQtdFsJ3LUO8d7QGCmpli6HhG8B1Fp 4Q+l+QqMQHNrKZ8QYBTgDMiQgHHQrhZ+2xGuurTEzS6Tv1dgvbKMia5Ev2AMV11IDtJNZdvPIpyc Q2qqSmwySbXa8pfiQqo2XhS0eXR2kpyO6aigs+PvJ0R0ABajs2dnnb9V5tNIBD+USasKT0WEFNZT 55mDlxCBkJh9l/rNlSm37JnTP1U5ds/Ha0VtS/FrY3dS6J/oMnmWHB9T6j4sQvJS2P2T/NWJ19dG PzOonZ/7rVafxcUZ6rVOqOgC9ILGSgd+SlU90BZ3TMJVCX40Dxj6qaLuzuSlbUBT7WqwTlFyfXEL 95YPkR7fD/z34aPdp8Xhhon9MOfhEUqiBTsNDUjGQzAoZPhvsKQxD+aQvCBkj5DPKfFQIKqQ9dFb wRSv7JIHTlQG/WXgKwenqKTMTX9MV2rABY3rbIUFPZ9E+nDeFYzJdcWs8GIN9Gwy5l/f9HrP40pV //oObnT/5fSy8v/x60/z1bW2j5swe/lqvns2byiN58U9iWZw8ZDH6Rjq1A8KawoNL5YzsMDtsVy1 TWt+NZFUyjmTCg+e5lFqQuOIPDIdvqtMIgVhlbbNkloIzTxYUiyVZU3nXhMFkKr1jl0RbiKrs252 6i4smXTdsMaTO5qZNaZim/Fp5C+am0brCDzuOKObkjcDXyz+iliJZfCbKKJUnH0vVVUkGAMXqyn2 XK34md4OlX+r44k12PP51uKBgqiF7xqXF86jZAWtGjSK5Nt1k78AAAD//wMAUEsDBBQABgAIAAAA IQAG/8rP1wAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9NS8NAFEX3gv9heII7O2n9wMZOSxWk grhoLXT7zLwmwcybZGaaJv/ehwtdXu7lXM5iNbhG9RRi7dnAdJKBIi68rbk0sP98vXkEFROyxcYz GRgpwmp5ebHA3Pozb6nfpVIJhGOOBqqU2lzrWFTkME58Syzd0QeHSWIotQ14Frhr9CzLHrTDmuWh wpZeKiq+dycnJ1N96t+H9W13d/+xH7v5XJchGXN9NayfQCUa0v/4edN2h8Nf+Yt6swZmoI6b8SvU dosxUTAgbmIqlqCXPwAAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAA AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAAL AAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAw6zmZ9gIAAB4HAAAQ AAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAAb/ys/XAAAA +QAAAA8AAAAAAAAAAAAAAAAATQUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAABRBgAA AAAAABDwCAAAAAAAAABQByABDwAR8FIAAAAAAMMLCAAAAAAAAAAKApAADwCIEzoAAAAPAIoTMgAA AAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAAAArA8MAAAAAAAAAAAAAAAAAAAADwAN8FAA AAAAAJ8PBAAAAAQAAAAAAKEPFgAAAAEAAAAAAAAACgAHAAEAAAAAAAIADAAAAKoPCgAAAAEAAAAB AAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAPCQAAEgAK8AgAAAADIAAAAAoAAIMAC/BWAAAA fwABAO8BgABAi2YFvwAAAAYAvwEBABEA/wERABkAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAg AFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAATACLxvwcAAKnDuQcAAFBLAwQUAAYACAAAACEA 8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpuger RxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO 3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1 Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1 JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD/ /wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPR vXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8 WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZt tzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au /+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhAIMZMwpVAwAAPAoAABAAAABk cnMvc2hhcGV4bWwueG1s7FVNbxoxEL1X6n+wfK0oLKEJWWWJyFdbCUUoJD/A7HrDFq+9sg2FVP3v fWMvIemhjZoew2GZXY89b96bGZ+cbmrF1tK6yuiMJx97nEmdm6LS9xm/u73qDDlzXuhCKKNlxrfS 8dPR+3cnTeoahs3apU3GF943abfr8oWshftoGqmxVhpbC49Xe99trHRSe+ERqFbdfq932K1FpfkI R+n1rJlasvLr9dSyqsj4AWda1Ah5IbxkUyVyuTCqkJb1ebd1jbsEoExMvnQtHvESPIUV35HkMyhM m88W2SQUoBvA7HBpwKKgzYL5bQNUheeAudk7Rw/s2ifjQlIi3ZS2fi220YlITVkyRDwYDgeHCfjZ ZrxHUEUqN57lWOofHyXDHkTMsTb4dASaQy4RA3k21vnP0rwaD6ODMm5l7iGhSMV64jzRtg8ROIwc NKnfnJliS55z/EPjWDv/rhWKFvEXxj5wpr5ql/HjZDBA6j68hOQ5s09X5s9WvDo36pFB5fzMb5V8 LS7KUK1VAumZUPdoKhv4KWR5g0/uARVDqgQ/dIMO9VSiujM+tpVQ0G4hrJNIrhU3d3/zAenx/MB/ Gz7abVoUbtev/8x5OARJ1MJOCB0ZN8FAyPBf6QJNHsxd8gzIbsV8hsSDQNhmffSWYqLP7JJ6iJVG +3Hgay6chKTETbuMLQuh79Gu05XOcXwS6dOzJidMrsmnuWdrgWOTHv3aoldPPM5k+bvvzg3796vj 0v/Br12dr86Vvd2E3puvZg+P5hXSeHy5xsgMLl7MY3fsdGobhWaKSEtVhIn34+Lo6tMgGVx2+sll vzM4GI474/HhReesPx4Oe/3L84vz8U8UeBhAi5IG421Vy0CGhS7LVV3V5lsVJQFjGZe6czfDCN+V HZtHncJzlXENiDThbbVEAWozCxZnS2npPqBKZbnATGwdmzzs1DTZVfUgv4RXkkxVdD/AXZupNaYk m7JTmp7aXFVKxbTjF2dUVdDHwDZdHBKcRhH9Jo5gSPvUS5Ylxs2OydVEt0yv6JjWDnXzt37BwBRP fD7UuiNFnKQvajaQTaipx9964b/2gh8xukLQgniiMYhmqYupsILG51uFo6Fedmu8rsL3nAclGjz3 dzhM14x+AQAA//8DAFBLAwQUAAYACAAAACEADCX4PNUAAAD5AAAADwAAAGRycy9kb3ducmV2Lnht bESPzU7DMBCE70i8g7VI3KhTChUNdauChEBCHFr6AEu8TSLidWK7+Xl7VhzgOJrRN/rW29E1qqcQ a88G5rMMFHHhbc2lgePny80DqJiQLTaeycBEEbaby4s15tYPvKf+kEolEI45GqhSanOtY1GRwzjz LbF0Jx8cJomh1DbgIHDX6NssW2qHNctDhS09V1R8H85OTub63L+Pu0V3d/9xnLrVSpchGXN9Ne4e QSUa0/+YuyE8Lf/KX9SbNbAAdXqdvkJt9xgTBQPiJqZiCXrzAwAA//8DAFBLAQItABQABgAIAAAA IQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0A FAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0A FAAGAAgAAAAhAIMZMwpVAwAAPAoAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQ SwECLQAUAAYACAAAACEADCX4PNUAAAD5AAAADwAAAAAAAAAAAAAAAACsBQAAZHJzL2Rvd25yZXYu eG1sUEsFBgAAAAAEAAQA9QAAAK4GAAAAAAAAEPAIAAAAAACPCd8QIAEPABHwUgAAAAAAwwsIAAAA AQAAAAcAkAAPAIgTOgAAAA8AihMyAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMUAAAAAACs DwwAAAAAAAAAAAAAAAAAAAAPAA3waAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGAAAAAIA AAAAAAAICgACAAcAAgAAAAAAAgAMAAAA+A8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAApg8M AAAA8AAAANQB0ALwAxAFDwAE8DYIAAASAArwCAAAAAQgAAAACgAAkwAL8GoAAAB/AIEB7wGHAAEA AAC/AAAABgC/AQEAEQDLAZwxAAD/ARkAGQA/AwAACACAwzQAAAC/AwAAAgBTAGwAaQBkAGUAIABJ AG0AYQBnAGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAEwAi8YQHAACpw34HAABQSwME FAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q 5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUK PtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt 1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqw XM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5 lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDB asMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZN C4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCp Yx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgs zzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQDjTwI5HwMA AJEHAAAQAAAAZHJzL3NoYXBleG1sLnhtbKRV227bMAx9H7B/EPQ6dEnabGuNukNboFuBYAia7gNk WU68yJQgKVnSr9+RZLdd9jI0T6ZMUjw8vOjy667TbKucbw2VfPJxzJkiaeqWliX/+Xh3cs6ZD4Jq oQ2pku+V51+v3r+7tIW3DM7kC1vyVQi2GI28XKlO+I/GKoKuMa4TAUe3HFmnvKIgAgJ1enQ6Hn8e daIlfoWraLuwcxcl+WM7d6ytSz7ljESHkAvd1ordd2Kp2FwLqVZG18qxMz7qPbKzAKKZkWvfwxL/ A6t24jdy/QsRI/PNIakJEJgHE3rpdiVoqa69VTL9QvRRAjxgJ0CPiOyKhb0Fcq/r+27Jkc6u5KcR LhyyVRIGR5+SF8Wucd2x4K8uRWGahiHiZDI9G49R0X3JP59/OocICKJQu8Ak9NNPX1AG6CUMzqan F/EQQWYk0dQ6H74pczQqFi8quQN1KLgoxHbmQw41hIi/ydy1Wh9LQUpS07HXsN+g8PQLOInQvEEb RnQDLbfasa3QJa/Qk+uet1dWYFFTqngury3C7sbU++hf4Ys2z+Pz9j7F3ILUlXFPnOl78iW/mEyn KGhIh1RfztxrTfWXJuhbgwzgIUjinpLL4HKTaB8WYa/VsSBTMYZN8eZUE+lgrBNulvBCeEiC3uYE WqqxXnIueoldpjmrVfMoqsVTzwvSdCFbKzGjG7dO5o2hcJ1cKuEVmMSOohd1nHpsiPmG4tjnZtC0 sDJ1hZVzGXIfTDA+zwP02uJGNYe2cS6HWfNWvlhcN+HQ9pVdr602aL7HXaK22iyensU7pPJ8+IGF nUyCqPK0iQKMPMwd/qI7+6WjqJ4LJ/CbrTdd25lfbSYWeZdc0cnPBZ4AcDjBsuCsSspssik5IUh8 IVy7xsIjs0gSZ2vl4nuSXKTAMu0NrUz+FF8G3T6p7+kYiddtfF8QgczcGdMk2XfhViuBqwbiIzt5 TeQs4owdTGd6hdTzfIbd5N/pxBZsGmyjgZjNjHriNnHIezm1QlrmDd6dkn/o6ESHPCBKHCiUyArp DxTS9/FfqM4FSNth2Ap4Eby9+gMAAP//AwBQSwMEFAAGAAgAAAAhACpQt/nQAAAA7AAAAA8AAABk cnMvZG93bnJldi54bWxEj81KAzEUhfdC3yHcgjubsai006ZFqqKIFDoVobvr5HYSOrkZktiZvr1Z CC4P549vuR5cK84UovWs4HZSgCCuvbbcKPjcv9zMQMSErLH1TAouFGG9Gl0tsdS+5x2dq9SIPMKx RAUmpa6UMtaGHMaJ74izd/TBYcoyNFIH7PO4a+W0KB6kQ8v5wWBHG0P1qfpxCt43H6dD/3S/9Wm7 n1szff6qYqHU9Xh4XIBINKT/8F/7TSu4A3F8vXwHq3cYEwUFGSfDZTCQq18AAAD//wMAUEsBAi0A FAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54 bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJl bHNQSwECLQAUAAYACAAAACEA408COR8DAACRBwAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBl eG1sLnhtbFBLAQItABQABgAIAAAAIQAqULf50AAAAOwAAAAPAAAAAAAAAAAAAAAAAHYFAABkcnMv ZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAcwYAAAAAAAAQ8AgAAACwAdACEA4gCg8AEfAQAAAA AADDCwgAAAACAAAABQCQAA8ABPAOCQAAEgAK8AgAAAAFIAAAAAoAAIMAC/BYAAAAfwABAO8BgADg 5GoFvwAAAAYAvwEBABEA/wERABkAPwMAAAgAgMMoAAAAvwMAAAIATgBvAHQAZQBzACAAUABsAGEA YwBlAGgAbwBsAGQAZQByACAANAAAABMAIvHIBwAAqcPCBwAAUEsDBBQABgAIAAAAIQDw94q7/QAA AOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEim bdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMaya y4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu 8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wy hjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwME FAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNO b4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHh xJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdg qqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X /kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAVdEM7F4DAACPEwAAEAAAAGRycy9zaGFw ZXhtbC54bWzsWFFv2jAQfp+0/2D5dWohEFoWNVRtpXaTUIVK+1w5jgMZju3ZDgN+/c52aIHtYWqn SkihknvOnX133/k7Ey4uVxVHS6ZNKUWKo9MuRkxQmZdiluKnx9uTIUbGEpETLgVL8ZoZfDn6/OlC JUYhWCxMolI8t1YlnY6hc1YRcyoVE6ArpK6IhamedZRmhglLLDiqeKfX7Z51KlIKPIKtxHKqJtpJ 9H450ajMUzzASJAKXN5LywyacELZXPKcaRTjTmMblhGIZSzpwjQBkX8JKNfkF2S5FwsS8k5DOpFz 0PHRbAMTEJdzqubIrhWElcl8DdhsUvyzJtoyjSHsVYr7zdqwADZ5Tc74JEmyKnT13lBHFySRRYHA 49lwMOxC4dYpjvvwBzKETxK2soiCfhAPz9xDRJ1FFMXO2iUYInGmSht7x+S7o0JuoxRrRi0UliRk OTY2uNq68MAGJFRiV9cAo7N0cELlw4l6ewHhKIP/udQbjPh3YVL8NYpjyN36STw478FE72qyPY3l N5KnuIGQGzu1a87eG5evx5Yvb87OVwpAqogeuxCd8OAFvvQxo1LkQDL/iPAZMJpjlLPikWRTOKge Cpe+DdaMjMW1XnjzQgp75ZdkxDAAD5gqXtVzImbAlkktqN/ehcLFVFEnGEUn1KIlgW2jrvs0x2vX 4poVh7b9HVPY49XiqrCHttstwa7RZvUN148rD21WTzcv4i2k8jK5h7blTSzJwlkkCSDyMNHNsXS0 JkkYANtFXZWV/FEGWCHrFDNx8jQNVI+gb2GUeWUwqVMswIXrkrpcQF8QcuoljBZMu57ql1ACbaUx VNSvF6478nLDvvmpg52XrseCByEnWsrCy6ayN5wR2KrrOcWFC1jI25LzkEN4YiQvc/fQQ+c6MQOA QlXsKrQ0qNWuFSsKYOoWlnosGthqt00j+4Pge14BHTjFXypxwm3TYciBgpGgoOZAQU1zJHTA247Q M3xgCP/92MhO8fzs2hOcAhihNjAql9Z/ppBvB3/wKIJO3vIoq1seAV2Og0eBOR/Cme0lsn/39FrO QHtqOXNcd88HXTNR/zw6c18c9jnTbznTcua4vq994D0TDXtD/1q7T5q4JU1LmuMiTXi3+cv7DPw4 tP0BBESjRr8BAAD//wMAUEsDBBQABgAIAAAAIQApTSCH1QAAAPkAAAAPAAAAZHJzL2Rvd25yZXYu eG1sRI/BTsMwEETvSPyDtUjcqFOgiIa6VYSEACEOTfsBS7xNIuJ1artp8vesOMBxNKM3eqvN6Do1 UIitZwPzWQaKuPK25drAfvdy8wgqJmSLnWcyMFGEzfryYoW59Wfe0lCmWgmEY44GmpT6XOtYNeQw znxPLN3BB4dJYqi1DXgWuOv0bZY9aIcty0ODPT03VH2XJycnc30aPsbi7ni/+NxPx+VS1yEZc301 Fk+gEo3pf1z0u9K+/5W/qDdrYAHq8Dp9hdZuMSYKBsRNTMUS9PoHAAD//wMAUEsBAi0AFAAGAAgA AAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC LQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwEC LQAUAAYACAAAACEAVdEM7F4DAACPEwAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnht bFBLAQItABQABgAIAAAAIQApTSCH1QAAAPkAAAAPAAAAAAAAAAAAAAAAALUFAABkcnMvZG93bnJl di54bWxQSwUGAAAAAAQABAD1AAAAtwYAAAAAAAAQ8AgAAACwCrABMA/QFA8AEfAQAAAAAADDCwgA AAADAAAABgKQAA8ADfCeAAAAAACfDwQAAAACAAAAAACoD1IAAABDbGljayB0byBlZGl0IE1hc3Rl ciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxldmVsDUZpZnRo IGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoPCgAAAFMAAAAB AAAAAAAPAATwuQgAABIACvAIAAAABiAAAAAKAACTAAvwYAAAAH8AAQDvAYAAYONqBYcAAgAAAL8A AAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDKgAAAL8DAAACAEYAbwBvAHQAZQByACAAUABsAGEAYwBl AGgAbwBsAGQAZQByACAANQAAABMAIvF3BwAAqcNxBwAAUEsDBBQABgAIAAAAIQDw94q7/QAAAOIB AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2 CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6 vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pA EmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSR JQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAG AAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4Ve Swe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM 3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMz kI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8 TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAA0H/AAsDAAA3BwAAEAAAAGRycy9zaGFwZXht bC54bWykVW1v2jAQ/j5p/8Hy16mFdLSlUUPVVqKbhCpU6A+4OA5kOOfMdhjw63e2Q6H7sFYtH+AS P7577rkXrm82tWJraWylMePJaZ8ziUIXFS4y/jwfnww5sw6wAKVRZnwrLb8Zff1y3aS2YXQZbdpk fOlck/Z6VixlDfZUNxLprNSmBkePZtFrjLQSHTgKVKveWb9/0auhQj4iV7ieNVPjLfG4nhpWFRm/ 4AyhppBjrZ00bKpAyKVWBdnnvNeB4z0gMhMtVrZjBO9hVBj4Q2m+IsNQPxjKJ/EBeoHOnhkSMR+0 WTK3bYhX6Qxps8v47xYMMeREe5PxQXc14snHITkbkoR0U5r6s0xH15DqsmQUkWq2zfjwYnh+lnz3 0SGVG8cEHZ1dXSbDPgEEIQbnlyR7oBc5eGRjrHuQ+tN8mHeUcSOFo5JCCuuJdV7EQ4igaNSgSd3m Thdbj8zpl2oee+njlaMmpvhLbXacqZ9oM36VDAaUugsPIXnOzPFJ/urEqXutgpqAgvxkPI9iKutm bqvkZyn6ZNVaJdQFDNSC5k0FqQpZPtEr30qJL1DA0aBgaLSS2j7jt6YCRWVcgrGS8gxlhFTYtzCk f/QfStGFj3aXlg+3H+UPyx+cUBI1mEnQkIynYFDI8FthQfMfzH3yjJjNIZ9R4qFWVCzjIlrCBO/M yk8iKzW626BXDlZSdb023TFdWQIuaI6nLQpyn0T5cNYIz8k2YiocWwO5Tfr+0/W/OkLcyfJf7B5G 9w+nt6X7D647zdt7ZeabMIZ5O9u9mGNK4+XhkbZpgDjI46Ds69TNjF82NMdYTMGAb49VW1e1/lVF USnnjEs8eZ7FHRQah+VR6fDdZhwpiF/fplpRC6GeBYuzlTR+2fteYwJo3XXARoSb6Ne2qnbyR3j0 oqvKL3+Co54arUtve34K/TfqcaVUJB7fWK2qwr8Mevl/BUmqxDK4TdyuVJxjlCxL2h17LdoJdlq1 3k1nh8q/1fGkGhxhvtV4IiFO8rvG5aB53F5hbe3XFe1z24z+AgAA//8DAFBLAwQUAAYACAAAACEA W6ahINcAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPwU7DMBBE70j8g7VI3KhDJCII3VYUCQLH tqgttyXeJqGxndimSf++Fgc4jmb0Rm86H3Urjux8Yw3C7SQBwaa0qjEVwsf65eYehA9kFLXWMMKJ PcxnlxdTypUdzJKPq1CJCDE+J4Q6hC6X0pc1a/IT27GJ3d46TSFGV0nlaIhw3co0STKpqTHxoaaO n2suD6sfjfA5rN/d5nvn+rtFmRX98PpwSFPE66vx6RFE4DH8jxdF12+3f+Uv6k0hZCD2xenLNWpJ PrBDiG7RNFqCnJ0BAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAA AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAA AAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAA0H/AAsDAAA3BwAAEAAA AAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQBbpqEg1wAAAPkA AAAPAAAAAAAAAAAAAAAAAGIFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAZgYAAAAA AAAQ8AgAAABfFQAAUAd/Fg8AEfBSAAAAAADDCwgAAAAEAAAACQKQAA8AiBM6AAAADwCKEzIAAAAA ALoPDgAAAF8AXwBfAFAAUABUADkAAACLExQAAAAAAKwPDAAAAAAAAAAAAAAAAAAAAA8ADfBQAAAA AACfDwQAAAAEAAAAAAChDxYAAAABAAAAAAAAAAoABwABAAAAAAACAAwAAACqDwoAAAABAAAAAQAA AAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwSAkAABIACvAIAAAAByAAAAAKAACTAAvwbAAAAH8A AQDvAYAAQOVqBYcAAgAAAL8AAAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDNgAAAL8DAAACAFMAbABp AGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANgAAABMAIvHiBwAA qcPcBwAAUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSR zUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4p uC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzG XgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZude w4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/ uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVs cy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2 tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0p oDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfX eKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAA ACEAYVjYDnUDAABkCgAAEAAAAGRycy9zaGFwZXhtbC54bWzsVcuO2zYU3RfoPxDcFo4tx68RRg48 AzstYAyMePIBVxI1Vk2RKkm79hT99x6ScjzpohlkuowX8pV4H+ee++Dth1Mj2VEYW2uV8eTdgDOh Cl3W6injnx9XvRln1pEqSWolMn4Wln+Y//zTbZvalsFY2bTN+M65Nu33bbETDdl3uhUKZ5U2DTm8 mqd+a4QVypFDoEb2h4PBpN9QrfgcrtRx226Ml4qH48awusz4lDNFDUJuZV0K9nBocmHYRlIhdlqW kCe835lEawKktS72tsNFr8FVGvoTyX4FiSn90SCrxAfoB1AXfArwfNB2x9y5BTorS0ADSc8Z/+NA xgnDgf+U8XFnHU3g5pqlDdlSeqpM81aw81tKdVUxRHw/m40myXvOzhmfTWbjIWRkQKk4OVZAYXgz TWYD1LiAxmg8RRUCyIjEa7bGuo9CvxkV844ybkThUGFK6bi2zrN5DRGojUy0qTvd6fLsNXP8owVi a31/CdHTiL/T5pkz+ZuyGb9JRiOk7sJLSJ4z8/Ik/+rEyXstMw4LUgX8ZDyPZErrtu4sxVsh+mTl USboBUbyCeNnAlWlqD7hk2+oxBco6GFuVOi4Cv2f8YWpSaKMOzJWIM9QRkoL+y0d8B/9h1J04aPc peXDXSb7u+kPTpBEQ2YdOITwKQgIGf5rVWIdBPGSPAOyR8q3SDzUCtQbF7UFrdWd2fuRZJVWbhH4 yskKVNdz0x3DZEfqCQO9OagC7pNIn9q2hcdk22JTOHYkuE0G/tf1v3yhcSeqf+te1GB/PV1U7j/0 utP8cC/N4ymMYX7YPn8RV0jjy8sDlmtQcZTHQbnUqZsZv3UorWQZduNfN8PRcnU/nfUWk/thb7Qc L3uL1eimN5pMxstpMpwuk8Xf6PVuRWGBKiwp78KgKvtDUzf69zoWBHxlXKje523cYqHpWB6rFJ6H jCsA9DeBqfdoP6W3QeJsL4y/N3yfsoKwMzvFtgiWyt8Asn4Wv4ZXXzBZ+3sE6kpvjNaVlz0wqfxT 6VUtZUw6frEa+99/9MfhghFgNJbQneKKxsFLLVFV2DsXHg9r1fF88G46OXTNt6YFm5Ne6PzSqJ6g uAVeNWog26P2E/5jEv7XSXBz5u8SDCCeGAtPs1Dlhgz55fmjwzFQr7sz3tbhV85DJVo8r5c5RNvO /wEAAP//AwBQSwMEFAAGAAgAAAAhADv2jOXYAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8FO wkAURfcm/sPkmbiTqU0ErAxEMILGFWCM7p6dR1vovCkzI23/3okLXN7cm3NzJrPO1OJEzleWFdwO EhDEudUVFwret883YxA+IGusLZOCnjzMppcXE8y0bXlNp00oRISwz1BBGUKTSenzkgz6gW2IY7ez zmCI0RVSO2wj3NQyTZKhNFhxfCixoUVJ+WHzYxR8tdtX97H/dMe7eT5cHdvl/SFNlbq+6h4fQATq wv94+fTWj/bn8g/1ohWMQOxW/ber9Bp9IKcgukXTaAly+gsAAP//AwBQSwECLQAUAAYACAAAACEA 8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA BgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQBhWNgOdQMAAGQKAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsB Ai0AFAAGAAgAAAAhADv2jOXYAAAA+QAAAA8AAAAAAAAAAAAAAAAAzAUAAGRycy9kb3ducmV2Lnht bFBLBQYAAAAABAAEAPUAAADRBgAAAAAAABDwCAAAAF8VjwnfEH8WDwAR8FIAAAAAAMMLCAAAAAUA AAAIApAADwCIEzoAAAAPAIoTMgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAAAArA8M AAAAAAAAAAAAAAAAAAAADwAN8GgAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxgAAAACAAAA AAAACAoAAgAHAAIAAAAAAAIADAAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYPDAAA APAAAADUAdAC8AMQBQ8ABPA8AAAAEgAK8AgAAAABIAAAAAwAAGMAC/AkAAAAgQEAAAAIgwEFAAAI vwEQABAA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAO7s4QAfSX0AT4G9AMBQTQAA AP8AgACAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA 6y4IAAAAjtPOAYAfDZ4AAA4EDgwAAFBLAwQUAAYACAAAACEA6d4Pv/8AAAAcAgAAEwAAAFtDb250 ZW50X1R5cGVzXS54bWyskctOwzAQRfdI/IPlLUqcskAIJemCx47HonzAyJkkFsnYsqdV+/dM0lRC qCAWbCzZM/eeO+NyvR8HtcOYnKdKr/JCKyTrG0ddpd83T9mtVomBGhg8YaUPmPS6vrwoN4eASYma UqV75nBnTLI9jpByH5Ck0vo4Ass1diaA/YAOzXVR3BjriZE448lD1+UDtrAdWD3u5fmYJOKQtLo/ Nk6sSkMIg7PAktTsqPlGyRZCLsq5J/UupCuJoc1ZwlT5GbDoXmU10TWo3iDyC4wSw7AMiV/PZyAZ Lea/O56J7NvWWWy83Y6yjnw2XsxOwf8UYPU/6BPTzH9bfwIAAP//AwBQSwMEFAAGAAgAAAAhAKXW p+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9o IhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727Vf vFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ /7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAA ACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9 oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgc xSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9 AQAA//8DAFBLAwQUAAYACAAAACEAuX/uc5YGAACwGwAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54 bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7phlwG77TBs K9ACu3SfJluHrQP6FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tfrXmIJD4PaBK2 vXvD/pUND0mFkwAznpC2NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8JQnMjbmIsYJX Ea4EAh8B3ZitrNZq6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww2GBS1wg5k10m 0CFmbQ/4BPxoSB4pDzEsFUy0vZr5eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sjgmm932hd2yno GwBTi7her9ft1Qt6BoB9HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqdZiuTxRI1IPvY WMBv1NYb26sO3oAsvrmAb3S2u911B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1EvIGPOdivhGwDf qGXwOQqioYguzWLME7Us1mL8kIs+ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bIlwtDmheSvqCp ansfphgyYk7vzcvv37x8jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH829eP/2i Gi/L+F9/+OSXnz+vBkIGzSV69eWz3148e/XVp79/97QCvi3wqAwf0phIdIccoQMeg27GMK7kZCTO t2IYYVpesZ2EEidYc6mg31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2K4od4B7nrMNF pRVuaV4lMw+nSVjNXEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4hJAKez2g1LHr HvUFl3ys0AOKOphWmmRIR040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUIPyTMMeNNPFU4 riI5xDErG/w2VlGVkIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC0UkVzduY8zJy h0+6EY7TKuyAJlEZ+4GcQIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA9MxUVPjyJuFO /A5mbIyJKTVQ151yHdPksnafuXZvC1qZPLsnKvYy3Mk63eUioP/+Mr2Dp8k+gcxY3Ksuq/Rllfb+ 81V6WT5ffG2el2Oo1Lp3sk23acHjpR34mDI2UDNGbkvThEvYhII+DOp15vRJihNZGsGjzmRg4OBC gc0aJLj6iKpoEOEUGvi6p4mEMiMdSpRyCQdHM1xJW+PhEKDssbOpDyS2ckis9nhgh9f0cH7uKMgY qUJzuM0ZrWkCZ2W2di0jCrq9DbO6FurM3OpGNFMUHW6FytrE5oAOJi9Ug8HCmtDdIOiJwMrrcP7X rOHggxkJtN2tj3K3GC9cpItkhAOS+UjrveijunFSHisLimg9bDDoQ+QpVitxa2my78DtLE4qs2ss YZd77128lEfw3EtA7WQ6sqScnCxBR22v1VxtesjHadsbw5kZHuMUvC51Q4lZCBdPvhI27E9NZpPl c2+2csXcJKjDNYi1+4LCTh1IhVQ7WEY2NMxUFgIs0Zys/KtNMOtFKVBRjc4mxdoGBMM/JgXY0XUt GY+Jr8rOLo1o29nXrJTyqSJiEAVHaMSm4gCD+3Wogj4BlXD1YSqCfoF7Om1tM+UW5yzpyrdjBmfH MUsjnJVbnaJ5Jlu4KUiFDOatJB7oVim7Ue78qpiUvyBVymH8P1NF7ydwDbEWaA/4cE0sMNKZ0va4 UBGHKpRG1O8LaBxM7YBogbtemIaggstq81+QQ/3f5pylYdIaTpPqgIZIUNiPVCQI2YeyZKLvFGL1 bO+yJFlGyERUSVyZWrFH5JCwoa6B63pv91AEoW6qSVYGDO5k/LnvWQaNQt3klPPNqWTF3mtz4O/u fGwyg1JuHTYNTW7/QsSiPZjvqna9WZ7vvWVF9MS8zWrkWQHMSltBK0v7txThnFutrVgLGq82c+HA i4saw2DREKVwmYT0H9j/qPCZ/fKhN9QhP4DaiuBDhiYGYQNRfcU2HkgXSDs4gsbJDtpg0qSsabPW SVst36wvuNMt+J4wtpbsLP4+p7GL5sxl5+TiRRo7s7Bjazu21NTg2ZMpCkPj/CBjHGM+mZW/avHR Q3D0Dnw/mDIlTTDBNyuBoYcemDyA5LcczdKtvwAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQDp3g+//wAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAAMAEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAGQIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAuX/uc5YGAACwGwAAFgAA AAAAAAAAAAAAAADWAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAAKAJAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAmwoAAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAi IGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0i aHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJn MT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBh Y2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2Nl bnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJm b2xIbGluayIvPgAAJwRABQAAUEsDBBQABgAIAAAAIQCR783y+wAAALsBAAATAAAAW0NvbnRlbnRf VHlwZXNdLnhtbHyQyU7DMBCG70i8g+Urip1yQAgl6YHlxnIoDzByJomFN3ncqn17JmmRKlQ4jWb9 /vmb9d47scNMNoZWrlQtBQYTexvGVn5uXqp7KahA6MHFgK08IMl1d33VbA4JSfB2oFZOpaQHrclM 6IFUTBi4M8TsoXCaR53AfMGI+rau77SJoWAoVZlvyK55wgG2rojnPZePSjI6kuLxODizWgkpOWug sFK9C/0vSnUiKN5cZmiyiW5YhtQXCXPnb8Bp752tybZH8QG5vIFnGbrPpMlx8RWosHPnyUr9f/aC 7jgM1mAfzdazJyplJI7LC96pM9DPL3qxvvsGAAD//wMAUEsDBBQABgAIAAAAIQCO6ir6vgAAADgB AAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYjQgxfRD1iSbRtsk5CNon9vjhYE j8Mwb2bq9jVP4kmRrXcKqqIEQU57Y92g4HY9bfYgOKEzOHlHCt7E0DbrVX2hCVMO8WgDi0xxrGBM KRykZD3SjFz4QC47vY8zpizjIAPqOw4kt2W5k/GbAc2CKTqjIHamAnF9h9z8n+373mo6ev2YyaUf FZIna+iMnChmLMaBkgIT+dtYiKrI+0E2tVz8bT4AAAD//wMAUEsDBBQABgAIAAAAIQDZA31IDwIA AMUMAAAhAAAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7JfPbqMwEMbvK/UdLF9X LYH8oyikarvqqYdo230AB4aAamxku9lkn35niFEge+khl1XCydaMP49/tvyZxcOulmwLxlZapTy8 G3EGKtN5pTYp//X+chtzZp1QuZBaQcr3YPnD8ubboknc7s3tJViGEsomIuWlc00SBDYroRb2Tjeg MFZoUwuHXbMJciN+o3Qtg2g0mgW1qBT3481XxuuiqDL4obPPGpQ7iBiQwmH5tqwa26k1X1FrDFiU aUcPSlrS8ionoV1hQN21zvdtb7kQidzKsFkZJuQGqUnOjJMpJ3biVT2Zj7ZdaOUe24S1sMBZKdQG 1776VJmjBBKyTfYEhW+tMse2AoXGI/w4ThucZDwW7jS3l+ejORQ/sTb7B/cTKXP2AYb2ltrtaC2r /KWSsu3QXsGzNIeZ3S7s5u1nEWDF3L6BQmR4Cr7X6lY6yhQJiJMAiEMgsyeBzHrtQ4Xt8jxJEsJm RFBrYV5TPpnO2+KviM+AmLh6xOMj4vtwMqHzcUV8BsTE1SOeHBGH43k4uzI+001BYD3jaY9xHMXx lfGZGBNYz3h2ZBxFMR7j/l2Bd/i7WL+hyXTXyD8eGHLWGsfREocWGHKa6H+zK6LiAc17gOaT8dCv LhYQUfGA4iMgojN0m4sFRFQ8oPseoNl0PrSKiwVEVPB1OHh0N4l2JZjuQY7B7v9j+RcAAP//AwBQ SwECLQAUAAYACAAAACEAke/N8vsAAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbFBLAQItABQABgAIAAAAIQCO6ir6vgAAADgBAAALAAAAAAAAAAAAAAAAACwBAABfcmVs cy8ucmVsc1BLAQItABQABgAIAAAAIQDZA31IDwIAAMUMAAAhAAAAAAAAAAAAAAAAABMCAABkcnMv c2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwUGAAAAAAMAAwDJAAAAYQQAAAAADwDuAzQH AAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwA0AA8ADAQ7BgAADwAC8DMGAADgAAjwCAAA AAQAAAAECAAADwAD8BsGAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAA AAgAAAUAAAAPAATwbwEAABIACvAIAAAAAggAACACAAADAQvweAAAAAQAAAAAAH8AAQDvAYAA4Pq4 A4EAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8BAAARAAED AgQAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAAPgWw AdAU3AgPABHwHAAAAAAAwwsIAAAA/////w8AkAAAAB8EBAAAAAIAAAAPAA3wowAAAAAAnw8EAAAA BgAAAAAAqA9RAAAAUGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgd2l0aCB0aGUgbWFya2luZyBtZXRo b2QgaW4gQklFUgtkcmFmdC1taXJza3ktYmllci1wbW1tLTAxAAChDyAAAABSAAAAAAAAAAoABwA4 AAAAAAACACgAGgAAAAAAAgAYAAAAqg8OAAAAUgAAAAcAAAAAAAkECQQPAATwRgMAABIACvAIAAAA AwgAACACAAADAQvweAAAAAQAAAAAAH8AAQDvAYAAIPq4A4EAMGUBAIIAmLIAAIMAMGUBAIQAmLIA AIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAP8BAAARAAEDAwQAAD8DAAAIAIDDGAAAAL8DAAACAFIA ZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAwAlgAyATkA8PABHwHAAAAAAAwwsIAAAA//// /xAAkAAAAB8EBAAAAAMAAAAPAA3wegIAAAAAnw8EAAAABQAAAAAAqA/CAAAAR3JlZyBNaXJza3kg Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tDVZlcm8gWmhlbmcgdmVyby56aGVuZ0BodWF3ZWku Y29tIA1NYWNoIENoZW4gbWFjaC5jaGVuQGh1YXdlaS5jb20gDUdpdXNlcHBlIEZpb2Njb2xhIGdp dXNlcHBlLmZpb2Njb2xhQHRlbGVjb21pdGFsaWEuaXQgDQ1JRVRGLTk1ICBBcHJpbCAyMDE2LCBC dWVub3MgQWlyZXMAAKEPJgAAAMMAAAAAAAAICgAAAAcAoQAAAAAAAgASACIAAAAABCIAAAQCABAA AACqD5oAAAAMAAAABwAAAAAACQQJBBsAAAAHAAAAAAAJBAkEDAAAAAcAAAAAAAkECQQVAAAABwAA AAAACQQJBAwAAAAHAAAAAAAJBAkEFAAAAAcAAAAAAAkECQQUAAAABwAAAAAACQQJBCIAAAAHAAAA AAAJBAkEAwAAAAcAAAAAAAkECQQhAAAABwAAAAAACQQECAEAAAAHAAAAAAAJBAkEDwDyDxgAAAAA APMPEAAAAAAAAAAaAAAABAAAAAiYNAAAAN8PCAAAAAwAAAAnAAAADwDyDxgAAAAAAPMPEAAAAAAA AAAcAAAABAAAAAiYNAAAAN8PCAAAADMAAABIAAAADwDyDxgAAAAAAPMPEAAAAAAAAAAeAAAABAAA AAiYNAAAAN8PCAAAAFQAAABoAAAADwDyDxgAAAAAAPMPEAAAAAAAAAAgAAAABAAAAAiYNAAAAN8P CAAAAHwAAACeAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwHgEAAKIMCvAIAAAABAgAAAAKAADD AAvwcgAAAH8AAQDvAYAAAPm4A78AAAAGAIEBBAAACL8BAAAQAMABAQAACP8BEAAYAAECAgAACD8C AAADAD8DAAAIAIDDKgAAAL8DAAACAEYAbwBvAHQAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQBy ACAAMQAAAAAAEPAIAAAAXg+wB9AOihAPABHwCQAAAAAAIAQBAAAACQ8ADfBrAAAAAACfDwQAAAAB AAAAAACoDwcAAABJRVRGLTk1AAChDxwAAAAIAAAAAAABKAoAAAABAAAABwAIAAAAAAACAA4AAACq Dw4AAAAIAAAABwAAAAAACQQJBAAApg8OAAAA+AAAAAAA1AHQAvADEAUQAPAHIAAAAP///wAAAAAA gICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQ AFQAMQAwAAAAixNpAAAAAADrLggAAAATA80BAB5S+gAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAD/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8A AisAAAAAAAAiBAgAAAABAAAAAQAAAA8A7gMHFwAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAA AAcANAAPAAwEDhYAAA8AAvAGFgAA8AAI8AgAAAAFAAAABQwAAA8AA/DuFQAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAMAAAFAAAADwAE8PoAAAASAArwCAAAAAIMAAAg AgAAAwEL8HAAAAAEAAAAAAB/AAEA7wGAAED7uAOBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAA AACHAAEAAACIAAAAAAC/AAAABgD/ARAAEQABAwIEAAA/AwAACACAwxAAAAC/AwAAAgBUAGkAdABs AGUAIAAxAAAAAAAQ8AgAAACtACABYBV9Aw8AEfAcAAAAAADDCwgAAAD/////DQCQAAAAHwQEAAAA AgAAAA8ADfA2AAAAAACfDwQAAAAAAAAAAACoDwwAAABXaGF0IGFuZCB3aHkAAKoPDgAAAA0AAAAH AAAAAAAJBAkEDwAE8PwKAAASAArwCAAAAAMMAAAgAgAAEwEL8JIAAAAEAAAAAAB/AAEA7wGAAID6 uAOBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ ARAAEQABAwMEAAA/AwAACACAwywAAAC/AwAAAgBDAG8AbgB0AGUAbgB0ACAAUABsAGEAYwBlAGgA bwBsAGQAZQByACAAMgAAAAAAEPAIAAAAYAPAAAAVMA8PABHwHAAAAAAAwwsIAAAA/////xMAkAAA AB8EBAAAAAMAAAAPAA3wFgoAAAAAnw8EAAAAAQAAAAAAoA/ACQAAIAAgACAAIAAgACAAMAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ADEAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAMgAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgADMADQAgACAAIAAgACAAIAAwACAAMQAgACAAMgAgADMAIAAgADQAIAA1ACAA IAA2ACAANwAgACAAOAAgADkAIAAwACAAMQAgADIAIAAzACAANAAgACAANQAgADYAIAA3ACAAIAA4 ACAAOQAgADAAIAAxACAAMgAgACAAMwAgADQAIAAgADUAIAA2ACAANwAgACAAOAAgADkAIAAwACAA MQANACAAIAAgACAAIAArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAt ACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0A KwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsADQAgACAAIAAgACAAfAAgADAAIAAxACAAMAAg ADEAIAB8ACAAIAAgAFYAZQByACAAIAAgAHwAIAAgACAATABlAG4AIAAgACAAIAB8ACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAARQBuAHQAcgBvAHAAeQAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAB8AA0A IAAgACAAIAAgACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAt ACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0A KwAtACsALQArAC0AKwAtACsALQArAC0AKwANACAAIAAgACAAIAB8ACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEIA aQB0AFMAdAByAGkAbgBnACAAIAAoAGYAaQByAHMAdAAgADMAMgAgAGIAaQB0AHMAKQAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA fgANACAAIAAgACAAIAArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAt ACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0A KwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsAIAAgACAAQgBJAEUAUgAgAEgAZQBhAGQAZQBy AA0AIAAgACAAIAAgAH4AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAfgANACAAIAAg ACAAIAArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0A KwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQAr AC0AKwAtACsALQArAC0AKwAtACsADQAgACAAIAAgACAAfgAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAQgBpAHQAUwB0 AHIAaQBuAGcAIAAgACgAbABhAHMAdAAgADMAMgAgAGIAaQB0AHMAKQAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAB8AA0AIAAg ACAAIAAgACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsA LQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAt ACsALQArAC0AKwAtACsALQArAC0AKwANACAAIAAgACAAIAB8AE8AQQBNAHwAIAAgACAAIAAgACAA IABSAGUAcwBlAHIAdgBlAGQAIAAgACAAIAAgACAAIAB8ACAAIABQAHIAbwB0AG8AIAAgAHwAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAQgBGAEkAUgAtAGkAZAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAB8AA0AIAAgACAAIAAgACsALQArAC0AKwAt ACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0A KwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQArAC0AKwAtACsALQAr AC0AKwANAA0AKwAtACsALQArACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABPAEEA TQAgAGYAaQBlAGwAZAAgAA0AIAB8AFMAfABEAHwAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgAFMAIAATICAAcwBpAG4AZwBsAGUAIABtAGEAcgBrACAAbQBlAHQAaABvAGQADQAgACsA LQArAC0AKwAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEQAIAATICAAZABvAHUAYgBs AGUAIABtAGEAcgBrACAAbQBlAHQAaABvAGQAAAChDxYAAADhBAAAAAABAAAAAADhBAAAAAACABAA AACqDw4AAADhBAAABwAAAAAACQQJBAAApg8GAAAACAAAAAAADwAE8B4BAACiDArwCAAAAAQMAAAA CgAAwwAL8HIAAAB/AAEA7wGAAGD5uAO/AAAABgCBAQQAAAi/AQAAEADAAQEAAAj/ARAAGAABAgIA AAg/AgAAAwA/AwAACACAwyoAAAC/AwAAAgBGAG8AbwB0AGUAcgAgAFAAbABhAGMAZQBoAG8AbABk AGUAcgAgADMAAAAAABDwCAAAAF4PsAfQDooQDwAR8AkAAAAAACAEAQAAAAkPAA3wawAAAAAAnw8E AAAAAQAAAAAAqA8HAAAASUVURi05NQAAoQ8cAAAACAAAAAAAASgKAAAAAQAAAAcACAAAAAAAAgAO AAAAqg8OAAAACAAAAAcAAAAAAAkECQQAAKYPDgAAAPgAAAAAANQB0ALwAxAFDwAE8IoIAAAyAArw CAAAAAUMAAAACgAAowAL8EoAAAB/AAAABACAAAD8uAOHAAEAAAC/AAAABgC/AQAAEADAAYmkpwDL AThjAAD/AQgACACAww4AAAC/AwAAAgBPAHYAYQBsACAAMQAAACMAIvFqBwAA/wEAAEAAqcNeBwAA UEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH 74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0 N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ 3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUx QP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7Pb bHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVs c6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4 jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZN zzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAP VAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAqExb j/kCAAAbCAAAEAAAAGRycy9zaGFwZXhtbC54bWysVV9P2zAQf5+072D5dYKkHesgIiCYxPZQQUXh A1wcp83qnC3b7Vo+/c52aKGb0LTy0l5857vf/Xx/zi/XnWIraV2rseSD45wziULXLc5K/vhwc3TK mfOANSiNsuQb6fjlxccP56ZwhtFldIUp+dx7U2SZE3PZgTvWRiLpGm078PRpZ5mx0kn04ClQp7Jh no+yDlrkF+QKV1MzsUESt6uJZW1d8iFnCB2FvFuBYgOe9epgGWUkSxKyl9dddAPFurFdjw7+BV1t 4RelvAcMCt00bF3yz6eDPCdqNiU/GY6+EvgABwq59kyQfpCPRqfBQJDF2Vk+SgZZAhIsjXX+u9QH g2LBUcmlUq1xksiDAlZj5wMRuyjhGPVNq9ShJCSCE6305H6jZHCu8F4SM/H5/5tgembibhiTiJUj vynL6LVLDkJQsQySag61TMdf6BUi9ZTr9kbMPAIKyBpK+t2w9QBCVf+JLVHexwuhZdNI4d8teP4W MSn4NmLMXOP7Be9a1PZvABS9Sp95ihc7sC8MU/j1ta43AU5F/9TKh9YIoJhrW3Lhbeo55fw0lOGh nikJaphDvUQnlGYHdlxymgAk3EdBraiO6aDFmko5iqBmNGRDJqyWzQNU0ycaF4OTkzA6rE/2EsZ4 bRc0VDhriOKreKkC6namaHxir6Yrc8AZTa3JEgUFSMWqcGpEQOWMmAif+iZMr23jvLS4ls2+7ba/ jNhprxr/hl2vrZbUvw/rSGy1nD5txRtKY/txS3skmnio0uCCgti4T8OcniQsAmomrCdggY7ZYtm1 nf7ZJlopZ5p/ePQ4pc1E/A3i4K0S1/F3WXKkIGFx2XZBGwT1NEqcLaQNay4McCaAFldvaES8STXf gWqf5I/4GUhXbVh7ZI56YrVughzwKQy/acimfkgnTqu2DpM38vV6cux655VV6uJnLpZj7LlaBje9 HF+e+Y2RDQgC9KnDI+X7LQR7CglJIdyeQri+d3fspr0Rm/i5d2mjOnPxGwAA//8DAFBLAwQUAAYA CAAAACEAt/9xQ9YAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPwU7DMBBE70j8g7VI3KhDDlCF bquqopQLiBrEeRtvE6uxndpuk/49Fgc4jmb0Rm+2GG0nzhyi8Q7hflKAYFd7bVyD8PW5vpuCiImc ps47RrhwhMX8+mpGlfaD2/JZpUZkiIsVIbQp9ZWUsW7ZUpz4nl3u9j5YSjmGRupAQ4bbTpZF8SAt GZcfWup51XJ9UCeLsDPvx82pG8qPOH1Zruo3pZpHhXh7My6fQCQe0//4ufheHw9/5S/qVSOUIPab yy4YvaWYOCBkt2yaLUHOfwAAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8B AAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCoTFuP+QIAABsI AAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhALf/cUPW AAAA+QAAAA8AAAAAAAAAAAAAAAAAUAUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAABT BgAAAAAAABDwCAAAAIAK8ACQA/AMDwAR8EIAAAAPAIgTOgAAAA8AihMyAAAAAAC6Dw4AAABfAF8A XwBQAFAAVAA5AAAAixMUAAAAAACsDwwAAAAAAAAAAAAAAAAAAAAPAA3wVAAAAAAAnw8EAAAABAAA AAAAoQ8aAAAAAQAAAAAAAAgKAAEABwABAAAAAAAEAP////4AAKoPCgAAAAEAAAABAAAAAAAAAKYP DAAAAPAAAADUAdAC8AMQBRAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAP AIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAACx2 0QEQQqAfAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAA AP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAACIECAAAAAEAAAACAAAADwDu A55lAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwA0AA8ADASlZAAADwAC8J1kAAAAAQjw CAAAABYAAAAWEAAADwAD8P1jAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAABAAAAUAAAAPAATwAAEAABIACvAIAAAAAhAAACACAAADAQvwcAAAAAQAAAAAAH8AAQDvAYAA wHBmBYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8BEAAR AAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwAZQAgADEAAAAAABDwCAAAAK0AIAFgFX0D DwAR8BwAAAAAAMMLCAAAAP////8NAJAAAAAfBAQAAAACAAAADwAN8DwAAAAAAJ8PBAAAAAAAAAAA AKgPEgAAAFNpbmdsZSBNYXJrIE1ldGhvZAAAqg8OAAAAEwAAAAcAAAAAAAkECQQPAATwcQQAABIA CvAIAAAAAxAAACACAAATAQvwkgAAAAQAAAAAAH8AAQDvAYAAwPy4A4EAMGUBAIIAmLIAAIMAMGUB AIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAL8BAQABAP8BEAARAAEDAwQAAD8DAAAIAIDD LAAAAL8DAAACAEMAbwBuAHQAZQBuAHQAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAyAAAAAAAQ 8AgAAAAwAzUBdRUgDQ8AEfCOAAAAAADDCwgAAAD/////EwCQAA8AiBNqAAAADwCKE2IAAAAAALoP DgAAAF8AXwBfAFAAUABUADkAAACLE0QAAAAAAKwPPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwQEAAAAAwAAAA8ADfAZAwAA AACfDwQAAAABAAAAAACoD08CAABCYXRjaGluZyBwYWNrZXRzIGJhc2VkIG9uIHRpbWUgaW50ZXJ2 YWwgdG8gbWVhc3VyZSBwYWNrZXQgbG9zcyBieSBzd2l0Y2hpbmcgdmFsdWUgb2YgdGhlIFMgZmxh Zy4gRCBmbGFnIE1VU1QgYmUgc2V0IHRvIDAgb24gdHJhbnNtaXQgYW5kIGlnbm9yZWQgb24gcmVj ZWlwdC4NRmlyc3QvTGFzdCBQYWNrZXQgRGVsYXkgY2FsY3VsYXRpb246DWNhcHR1cmUgdGltZXN0 YW1wIG9mIHdoZW4gUyBmbGFnIHZhbHVlIGZsaXBzLiBNZXRob2QgaXMgc2Vuc2l0aXZlIHRvIHBh Y2tldCBsb3NzIGFuZCBwYWNrZXQgcmUtb3JkZXJpbmcNQXZlcmFnZSBQYWNrZXQgRGVsYXkgY2Fs Y3VsYXRpb246DWNvbGxlY3QgdGltZXN0YW1wcyBmb3IgZWFjaCBwYWNrZXQgcmVjZWl2ZWQgd2l0 aGluIGEgc2luZ2xlIGJsb2NrLiAgQXZlcmFnZSBvZiB0aGUgdGltZXN0YW1wIGlzIHRoZSBzdW0g b2YgYWxsIHRoZSB0aW1lc3RhbXBzIGRpdmlkZWQgYnkgdGhlIHRvdGFsIG51bWJlciBvZiBwYWNr ZXRzIHJlY2VpdmVkLiBIZW5jZSBtaW5pbWFsbHkgaW1wYWN0ZWQgIGJ5IGEgcGFja2V0IGxvc3Mg YW5kIG5vIGltcGFjdCBpZiBwYWNrZXRzIGdldCByZS1vcmRlcmVkLg0AAKEPbAAAAMIAAAAAAAAA AABoAAAAAQAAAAAAIgAAAAAAAAAAAAQBAAABAAAAAADCAAAAAAACABQAaAAAAAAAAgAUACIAAAAA BAIAAAQUANUAAAAACAIAAAgUABMAAAAADAIAAAwUABwAAAAAEAIAABAUAAAAqg86AAAAAQIAAAcA AAAAAAkECQQgAAAAAQAAAAAAEwAAAAEAAAAAABoAAAABAAAAAAACAAAABwAAAAAACQQJBA8ABPAe AQAAogwK8AgAAAAEEAAAAAoAAMMAC/ByAAAAfwABAO8BgAAA/7gDvwAAAAYAgQEEAAAIvwEAABAA wAEBAAAI/wEQABgAAQICAAAIPwIAAAMAPwMAAAgAgMMqAAAAvwMAAAIARgBvAG8AdABlAHIAIABQ AGwAYQBjAGUAaABvAGwAZABlAHIAIAA0AAAAAAAQ8AgAAABeD7AH0A6KEA8AEfAJAAAAAAAgBAEA AAAJDwAN8GsAAAAAAJ8PBAAAAAEAAAAAAKgPBwAAAElFVEYtOTUAAKEPHAAAAAgAAAAAAAEoCgAA AAEAAAAHAAgAAAAAAAIADgAAAKoPDgAAAAgAAAAHAAAAAAAJBAkEAACmDw4AAAD4AAAAAADUAdAC 8AMQBQ8ABPCwBgAAAgIK8AgAAAAFEAAAAAsAAIMAC/BmAAAAvwEAABAAwAEAIGAAywE4YwAA0QEF AAAA/wEIAAgAAwMAAAAAgMM2AAAAvwMAAAIAUwB0AHIAYQBpAGcAaAB0ACAAQQByAHIAbwB3ACAA QwBvAG4AbgBlAGMAdABvAHIAIAAyAAAAIwAi8RoGAAD/AQAAQACpww4GAABQSwMEFAAGAAgAAAAh AP4l66UAAQAA6gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D4WpaqgdjTOke rB7VmPUBCExbYjsQBuvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst37dPxZ0UlA06 MwYELfdActNcXtTbfQQS7EbScsg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6VTZgBsxFXjJk U7fQmc8xi8cdX68kCUaS4mEVLl1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8wdH3wk+T vAPxalJ+NhNjKJdo2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8SleHn2q+ AQAA//8DAFBLAwQUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxzpJA9awMxDIb3 Qv+D0d7zJUMpJb5shawhha7G1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZNCwYpcJxo cPB+ent6AaPFU/QzEzq4osK+e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOeJflSRxls9uHs B7Tbtn228psB3YppDtGBHOIWzOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJgcRBFv5aCS1PL gb3v3fzTG5gIQ2H5qI6V/Cep9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhAF1jeM6sAQAArgQA ABQAAABkcnMvY29ubmVjdG9yeG1sLnhtbLxTX0vDMBB/F/wOIe/armonxUxkqC8i4p8PcLbpFkgv IQld9+29NN3AgSAqvvWay/3+Xa6uh06zXjqvDAo+O805k1ibRuFK8LfXu5NLznwAbEAblIJvpefX i+OjK1t5y+gy+soKvg7BVlnm67XswJ8aK5HOWuM6CFS6VWad9BIDBALqdFbkeZl1oJAvaBT2ywFf 7JOLRf3YPzmmGsHPOEPoCPUlOFCrdWA3zpkNWxpEWQfjWMGz6co0YCyRBtBHdjDYjwBQDa3rJurw HeqNgw35ccAaKtO2bBB8XpIY8m0reJlflufzi0gKKjkEVsfz+bw4jw01deTxLEscYpN1PtxL82s+ LA4S3E9G7R2akb9QQf/gQwLeAcbfGn9rA9sIXlxEdXGeN1o1d0rrsXCr96V2rAdNsvMiL3faP7UF UPoWGxa2loKGmO9kkcYxwpQarVvYaplYP0syfly9H+dH+0XRJHfGrZV7rlDXtKizPQtCi7At6foz 4Mmv+Fy+Ap7wIrRsW1r3/wTfI47KDf4deKfQuLQtn9WHYWd5m/BS+il1esreLj4AAAD//wMAUEsD BBQABgAIAAAAIQAyCDSPxgAAANoAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9PawIxFMTvBb9DeEIv olkVSl2N4h9KFamg9tDjY/PcLG5elk3qrv30TUHocZiZ3zCzRWtLcaPaF44VDAcJCOLM6YJzBZ/n t/4rCB+QNZaOScGdPCzmnacZpto1fKTbKeQiQtinqMCEUKVS+syQRT9wFXH0Lq62GKKsc6lrbCLc lnKUJC/SYsFxwWBFa0PZ9fRtFUyG29Vu/fHVOx7Mz2602STv++aq1HO3XU5BBGrDf/jR3moFY/i7 Em+AnP8CAAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAA AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAA AAAAAAAxAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAXWN4zqwBAACuBAAAFAAAAAAAAAAA AAAAAAAuAgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAMgg0j8YAAADaAAAA DwAAAAAAAAAAAAAAAAAMBAAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAP8EAAAAAAAA EPAIAAAA+g7gAQAV+g4PAATwjwgAABIACvAIAAAABhAAAAAKAACzAAvwWgAAAH8AAAAEAIAAYP+4 A4cAAQAAAL8AAAAGAIEBBAAACL8BEAAQAMABiaSnAMsBOGMAAP8BCAAIAIDDGAAAAL8DAAACAFIA ZQBjAHQAYQBuAGcAbABlACAANAAAACMAIvFfBwAA/wEAAEAAqcNTBwAAUEsDBBQABgAIAAAAIQDw 94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tH FV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7e kYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVL HX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUk XjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP// AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9 cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xY fYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23 Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/ 6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEA9AoxH+4CAADRBwAAEAAAAGRy cy9zaGFwZXhtbC54bWysVdtuGjEQfa/Uf7D8WiULEZB0lU2UVEr7gCIEyQcMXi9s8dor21DI1/fY XsilVVSVvMCsZzxz5szFl9fbRrGNtK42uuD90x5nUgtT1npR8MeHu5MLzpwnXZIyWhZ8Jx2/vvr8 6bLNXctwWbu8LfjS+zbPMieWsiF3alqpoauMbcjj0y6y1kontSePQI3Kznq9UdZQrfkVXOnNrJ3Y IIn7zcSyuiz4kDNNDUJOpQCAhZJswLPOJphHWcMcQvbSh4u+KN9Wtukg0r9ALC39Qt5v0FFuqopt C34+AmjwswO2wXAwGvYCHMrl1jPxQi9gMILl+TDos4QjGLbW+e/SHI2JBUcFt+AF7FFOm7HzKdQ+ RGQk8YBC+Z2SwVDpqUQqsWj/zQiKg2TPYuRYb/lNWbYhVXASAiXuJ9WSSpmOhyAjcgUuDjciMxFQ QFbVSn0Ytg5A6MU/sSWeunghtKwqEPlhwXvvEZOCHyLGzI3+uOBNrY39GwCFqnSZp3ipQVJjtLnf 3ppyF+DM8Y8BPLZHSIulsQUX3qYhUc7PQrRjPSMJDNKxXqITpNmQHRccMw1hGgW1QR/joNYlWjmK pBZYjSETVsrqgeazp4J/7Q8GYRlYn+wljfWtXWGFclaB4pt4aU5Ocqaw9HSnxpUllhnWzGStBQKk ZlV61oqAyrViInyam36Ym/3gvLS4ldVb270Z7j9rbyr/jl2nna8xvw/bSOx8PXs6iHdI4/Bxj+0f TTzN07ahHGxM0/ZFScL6xjDpckKWcMxW66ZuzM860YqcCy71yeMM7wn4618E9uaJ6/i7LrhGkPDc 2HqFva/NLEqcraQNjxPWL2eC8Nx0hq2IN9HzDan6Sf6In4F0VYfHCubaTKwxVZADPqXDrzZ32Ddp HtKJM6ouw2Hk6/XmeJ6dV1ZpivdcrMe642od3HRyrDzzu1ZWJADoS6NPlO+eDXqjkJQUwr1RCNfN 7jO7cXu2cYj3s4sn0LVXvwEAAP//AwBQSwMEFAAGAAgAAAAhAFJ1ZDXWAAAA+QAAAA8AAABkcnMv ZG93bnJldi54bWxEj8tOwzAURPdI/IN1kdhROyCqKtStEGpUJOgifa0v8W0SGj+wTZr267HYdDma 0Rmd6XzQHevJh9YaCdlIACNTWdWaWsJ2UzxMgIWIRmFnDUk4U4D57PZmirmyJ1NSv441SxATcpTQ xOhyzkPVkMYwso5M6g7Wa4wp+porj6cE1x1/FGLMNbYmPTTo6K2h6rj+1RI+Hb9kT4v+Y5J9X1a7 ohR66Y5S3t8Nry/AIg3xOl6IffFzLf9R70rCM7DD8vzlW1ViiOQlJLdkmiyBz/4AAAD//wMAUEsB Ai0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz XS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMv LnJlbHNQSwECLQAUAAYACAAAACEA9AoxH+4CAADRBwAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3No YXBleG1sLnhtbFBLAQItABQABgAIAAAAIQBSdWQ11gAAAPkAAAAPAAAAAAAAAAAAAAAAAEUFAABk cnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAASAYAAAAAAAAQ8AgAAABsDeABwAPmDg8AEfBC AAAADwCIEzoAAAAPAIoTMgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAAAArA8MAAAA AAAAAAAAAAAAAAAADwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAAAAAICgABAAcAAQAA AAAABAD////+AACqDwoAAAABAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwmAgAABIA CvAIAAAABxAAAAAKAACjAAvwVAAAAH8AAAAEAIAAgP24A4cAAQAAAL8AAAAGAL8BAAAQAMABiaSn AMsBOGMAAP8BCAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAOAAAACMAIvFuBwAA /wEAAEAAqcNiBwAAUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tp FDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcv nY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W 4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98 J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsA AABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvq F/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhL SZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz3 3r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQU AAYACAAAACEAaT7L0vwCAAAdCAAAEAAAAGRycy9zaGFwZXhtbC54bWysVdtOGzEQfa/Uf7D8WkE2 lABZsSCoRPuAUJTAB0y83mQbr72ynTTh63tsbwKkFaoaXpJZz3jmzPFcLq/XjWIraV1tdMH7xxln UgtT1npW8KfHu6MLzpwnXZIyWhZ8Ix2/vvr86bLNXctwWbu8Lfjc+zbv9ZyYy4bcsWmlhq4ytiGP TzvrtVY6qT15BGpU7yTLznoN1ZpfwZVeTdqRDZJ4WI0sq8uCDznT1CDkWAoAmCnJLnivswnmUdYw h9B77cNFX5SvK9t0EOlfIJaWfiHvPXSUm6pi64KfnGTDiwwEbQo+OD07/zrIAh7K5dozAYPhMDsL egEDCNn5IOh7CUgwbK3z36U5GBQLjgpuQQzoo5xW986nUNsQ4Vibu1qpQxlI7CZO8eh+o2RwrvRY gpZYAP/NLh46EBuTiLUjvynLVqQKTkKgXPpJNadSpuMBeI20g9bdjUhyBBSQVUj6w7B1AEJd/4kt Ud7FC6FlVeFNPix49h4xKfguYszc6I8L3tTa2L8BUHiVLvMUL7ZfVxht7te3ptwEOFP8o5kPrRHS Ym5swYW3qd+U85NQhod6RhLoyUO9RCdIsyF7X3C0P4RxFNQKdYyDWpco5SiSmmHMhkxYKatHmk6e MTf6p6dhblif7CXd61u7wDjmrALFN/HSlJzkTGGA6k6NK3MMRoys0VILBEjFqvSkFQGVa8VI+NQ3 /dA328Z5bXErq33brRnuv2hvKv+OXaedLtG/j+tI7HQ5ed6Jd0hj9/GATRJNPE3T4KIcbIzTJMeT hFWAZtLliCzhmC2WTd2Yn3WiFTkXXOqjpwl2E/jrx6k8TVzH32XBNYKE1WXrBXaINpMocbaQNiw6 7B8MasLq6gxbEW+i5htS9bP8ET8D6aoOiw/m2oysMVWQAz6lw28asqkf0okzqi7D5I18vZ0cL73z xip18ZaL5b3uuFoGN50cX575TSsrEgD0pdFHyncbiPYUkpJCuD2FcF3vvrAbp2cbm3jbu1inrr36 DQAA//8DAFBLAwQUAAYACAAAACEAsbpOF9cAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPT08C MRTE7yZ8h+aReJOuxiiuFIJG/BcvuxC8PreP3cL2dWkrLN/exoMeJzP5zcxk1ttWHMgH41jB5SgD QVw5bbhWsFouLsYgQkTW2DomBScKMJsOziaYa3fkgg5lrEWCcMhRQRNjl0sZqoYshpHriJO3cd5i TNLXUns8Jrht5VWW3UiLhlNDgx09NlTtym+bZjz0+w/3VpTXK/f8aeh9XN5uK6XOh/38HkSkPv6H n7L1Yr/7M39Rr1rBHYjNy+nLG11giOQVpG/pacKDnP4AAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3 irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA CAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA CAAAACEAaT7L0vwCAAAdCAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQIt ABQABgAIAAAAIQCxuk4X1wAAAPkAAAAPAAAAAAAAAAAAAAAAAFMFAABkcnMvZG93bnJldi54bWxQ SwUGAAAAAAQABAD1AAAAVwYAAAAAAAAQ8AgAAAB0DXAF4AfuDg8AEfBCAAAADwCIEzoAAAAPAIoT MgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAAAArA8MAAAAAAAAAAAAAAAAAAAADwAN 8FQAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAAAAAICgABAAcAAQAAAAAABAD////+AACqDwoA AAABAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwlQgAABIACvAIAAAACBAAAAAKAACj AAvwVAAAAH8AAAAEAIAAQHJmBYcAAQAAAL8AAAAGAL8BAAAQAMABiaSnAMsBOGMAAP8BCAAIAIDD GAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAOQAAACMAIvFrBwAA/wEAAEAAqcNfBwAAUEsD BBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74Lv EOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1 Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTV rdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7a sFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj +ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQ wWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbW TQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlg qWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4 LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAQdq/gfkC AAAeCAAAEAAAAGRycy9zaGFwZXhtbC54bWysVdtuGjEQfa/Uf7D8WqVAArmssomSSmkfUIQg+YDB 64UtXntlGwr5+h7bCyS0iqqSF5j1jGfOHM/l+nZdK7aS1lVG57z3tcuZ1MIUlZ7l/Pnp4eSSM+dJ F6SMljnfSMdvbz5/um4y1zBc1i5rcj73vsk6HSfmsib31TRSQ1caW5PHp511Giud1J48AtWqc9rt nndqqjS/gSu9mjQjGyTxuBpZVhXAAiiaasQcSwEEMyXZFe+0RsE+yhr2EDqvnbjojLJ1aesWI/0L xsLSLyR+AI8yU5ZsnfOz/ulVtwtYm5wP+ucXZ4NuwEOZXHsmYHDV6/eDXsDgHJYXg6DvJCDBsLHO f5fmaFAsOMq5BTHgjzJaDZ1PobYhwrE2D5VSxzKQ2E2c4tX9RsngXOmxBC2xAv6bXbw0eDuNScTi kd+UZStSOSchUC+9pJpTIdPxALxG2kHr7kYkOQIKyEok/WHYWgChsP/Elihv44XQsizxJh8WvPse MSn4LmLM3OiPC15X2ti/AVB4lTbzFC+2X1sYTebX96bYBDhT/KObj60R0mJubM6Ft6nflPOTUIbH ekYS6MljvUQnSLMmO8w52h/COApqhTrGQaULlHIUSc0wZ0MmrJDlE00nL/u5YX2ylzTU93aBGchZ CYrv4qUpOcmZwgTVrRqu5xiMGFmjpRYIkIpV6UkjAirXiJHwqW96oW+2jfPa4l6Wh7ZbM9zfa+9K /45dq50u0b9P60jsdDl52YkPSGP38YhVEk08TdPgogxsjNMkx5OEXYBm0sWILOGYLZZ1VZufVaIV Oedc6pPnCZYT+Otdhqk7TVzH32XONYKE3WWrBXaINpMocbaQNmw6LCAMasLuag0bEW+i5mtS1Yv8 ET8D6aoKmw/m2oysMWWQAz6lw28asqkf0okzqirC5I18vZ0c+955Y5W6eMvFcqhbrpbBTSvHl2d+ 08iSBAB9qfWJ8u0GogOFpKQQ7kAhXNu7e3bj9GxiE297F+vUNTe/AQAA//8DAFBLAwQUAAYACAAA ACEA4dY/XNcAAAD6AAAADwAAAGRycy9kb3ducmV2LnhtbESPTU8CMRCG7yb8h2ZIvEkXY5QsFKJG /CBediF6HbfDbmHbLm2F5d878aDHmefNM/POFr1txZFCNN4pGI8yEOQqr42rFWzWy6sJiJjQaWy9 IwVnirCYDy5mmGt/cgUdy1QLlriYo4ImpS6XMlYNWYwj35FjtvXBYuIx1FIHPLHctvI6y26lReP4 QoMdPTZU7ctvy2889Id3/1aUNxv//GloNSnvdpVSl8P+fgoiUZ/+w0/Zx/Kw/4O/qlfNEq6yfTl/ BaMLjImCAt5wVUYg5z8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAA CwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAQdq/gfkCAAAeCAAA EAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQDh1j9c1wAA APoAAAAPAAAAAAAAAAAAAAAAAFAFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAVAYA AAAAAAAQ8AgAAAB0DXAIsAruDg8AEfBCAAAADwCIEzoAAAAPAIoTMgAAAAAAug8OAAAAXwBfAF8A UABQAFQAOQAAAIsTFAAAAAAArA8MAAAAAAAAAAAAAAAAAAAADwAN8FQAAAAAAJ8PBAAAAAQAAAAA AKEPGgAAAAEAAAAAAAAICgABAAcAAQAAAAAABAD////+AACqDwoAAAABAAAAAQAAAAAAAACmDwwA AADwAAAA1AHQAvADEAUPAATwmAgAABIACvAIAAAACRAAAAAKAACzAAvwXAAAAH8AAAAEAIAAAHNm BYcAAQAAAL8AAAAGAIEBBAAACL8BEAAQAMABiaSnAMsBOGMAAP8BCAAIAIDDGgAAAL8DAAACAFIA ZQBjAHQAYQBuAGcAbABlACAAMQAwAAAAIwAi8WYHAAD/AQAAQACpw1oHAABQSwMEFAAGAAgAAAAh APD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboH q0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugM jt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0 dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+Wmi NSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA //8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D 0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODr fFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSm bbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2 rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQCzpbIq9QIAANQHAAAQAAAA ZHJzL3NoYXBleG1sLnhtbKxV224aMRB9r9R/sPxapUDKJV1lEyWV0j6gCEHyAYPXC1u89so2FPL1 PbYXktAqqkpeYNYz4zlz5uLL622t2EZaVxmd897nLmdSC1NUepHzx4e7swvOnCddkDJa5nwnHb++ +vjhsslcw+CsXdbkfOl9k3U6TixlTe6zaaSGrjS2Jo9Pu+g0VjqpPXkEqlXnvNsddmqqNL/CVXoz ayY2SOJ+M7GsKoClx5mmGjGnUgDBQknW6/JOaxUcoqzhAKHz8hYXb6NsW9q6BUn/ArKw9AuZH+Gj zJQl2+a8P+oOvgxA0S7ng/5wFGSEpkxuPRMwGA2RF/QCBkNIo0HQdxKQYNhY579LczIoFi7KuQUz IJAy2oydT6H2ISIliQjUyu+UDIZKTyVyiXX7b0pQHyR7HiPHkstvyrINqZyTEKhyL6mWVMh0PAAZ kStwcfCIzERAAVlZKfVu2FoAoR3/xJZ4auOF0LIsQeS7Be++RUwKfogYMzf6/YLXlTb2bwAUqtJm nuKlBkmN0WR+e2uKXYAzxz9m8NQeIS2WxuZceJuGRDk/C9FOvRlJYJBOvSVegjRrsuOcY2YhTKOg NuhjHFS6QCtHkdQC2zFkwgpZPtB89pTzr71+Pwy79cle0ljf2hU2F2clKL6JTnNykjOFvadbNVyW WGfYM5O1FgiQmlXpWSMCKteIifBpbnphbvaD89LiVpbHtnsz+D9rb0r/hl2rna8xvw/bSOx8PXs6 iHdI4/Bxjwcgmniap21DGdiYpvWLkoQNjmHSxYQs4Zit1nVVm59VohU551zqs8cZnhTw17sI7M0T 1/F3nXONIOHFsdUKm1+bWZQ4W0kb3iesV2xXwovTGjYieqLna1LVk/wRPwPpqgrvFcy1mVhjyiAH fEqHX23usG/SPKQTZ1RVhMPI1+vN8Tw7r6zSFO+5WI91y9U6XNPKsfLM7xpZkgCgT7U+U759NuhI ISkphDtSCNfO7jO7cXs2cYj3s4s30DVXvwEAAP//AwBQSwMEFAAGAAgAAAAhAChJ3hXWAAAA+gAA AA8AAABkcnMvZG93bnJldi54bWxEj09rwkAQR+8Fv8MyQm91NxaKpK5SxGCh7SG29TxmxyQ1+6e7 2xj99F28eBze8H68+XLQHevJh9YaCdlEACNTWdWaWsLXZ/EwAxYiGoWdNSThTAGWi9HdHHNlT6ak fhtrliQm5CihidHlnIeqIY1hYh2ZxA7Wa4zp9DVXHk9Jrjs+FeKJa2xNWmjQ0aqh6rj90xLeHb9k j+v+bZb9XD6+i1LojTtKeT8eXp6BRRri7XktdsXvDV5Vryq1ZMAOm/Pet6rEEMlLSHEpNSHgi38A AAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAu AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAs6WyKvUCAADUBwAAEAAAAAAAAAAAAAAAAAAp AgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQAoSd4V1gAAAPoAAAAPAAAAAAAAAAAA AAAAAEwFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAATwYAAAAAAAAQ8AgAAAB0DZQL dA3uDg8AEfBCAAAADwCIEzoAAAAPAIoTMgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAA AAAArA8MAAAAAAAAAAAAAAAAAAAADwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAAAAAI CgABAAcAAQAAAAAABAD////+AACqDwoAAAABAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUP AATwmggAABIACvAIAAAAChAAAAAKAACzAAvwXAAAAH8AAAAEAIAAwHNmBYcAAQAAAL8AAAAGAIEB BAAACL8BEAAQAMABiaSnAMsBOGMAAP8BCAAIAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABl ACAAMQAxAAAAIwAi8WgHAAD/AQAAQACpw1wHAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMA AABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh3 3950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qi ux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQ Dwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgo a8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAA ACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sK W0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDf vb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D 6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XH rBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQBb6YCk9wIAANQHAAAQAAAAZHJzL3NoYXBleG1sLnht bKxV224aMRB9r9R/sPxapVwSSLLKJkoqpX1AEYLkAwavF7Z47ZVtKOTre2wvJKFVVJW8wKxnxnPm zMVXN5tasbW0rjI6572vXc6kFqao9DznT4/3JxecOU+6IGW0zPlWOn5z/fnTVZO5hsFZu6zJ+cL7 Jut0nFjImtxX00gNXWlsTR6fdt5prHRSe/IIVKtOv9sddmqqNL/GVXo9bcY2SOJhPbasKoClz5mm GjEnUgDBXEnW6/FOaxUcoqzhAKHz+hYXb6NsU9q6BUn/ArKw9AuZH+CjzJQl2+R8MOhf9oennG0h nw3PTwfdgIcyufFMwOB8iLxAoYDBENL5IOg7CUgwbKzz36U5GhQLF+XcghkQSBmtR86nULsQkZJE BGrlt0oGQ6UnErnEuv03JagPku3HyLHk8puybE0q5yQEqtxLqgUVMh0PQEbkClzsPSIzEVBAVlZK fRi2FkBoxz+xJZ7aeCG0LEsQ+WHBu+8Rk4LvI8bMjf644HWljf0bAIWqtJmneKlBUmM0md/cmWIb 4Mzwjxk8tkdIi4WxORfepiFRzk9DtGNvRhIYpGNviZcgzZrsKOeYWQiTKKg1+hgHlS7QylEkNcd2 DJmwQpaPNJs+5/yyd3YWht36ZC9ppO/sEpuLsxIU30anGTnJmcLe060aLgusM+yZ8UoLBEjNqvS0 EQGVa8RY+DQ3vTA3u8F5bXEny0PbnRn8X7S3pX/HrtXOVpjfx00kdraaPu/Fe6Sx/3jAAxBNPM3S tqEMbEzS+kVJwgbHMOliTJZwzJaruqrNzyrRipxzLvXJ0xRPCvjrXQT2Zonr+LvKuUaQ8OLYaonN r800SpwtpQ3vE9YrtivhxWkNGxE90fM1qepZ/oifgXRVhfcK5tqMrTFlkAM+pcOvNvfYN2ke0okz qirCYeTr7eZ4mZ03VmmKd1ysRrrlahWuaeVYeea3jSxJANCXWp8o3z4bdKCQlBTCHSiEa2f3hd24 PZs4xLvZxRvomuvfAAAA//8DAFBLAwQUAAYACAAAACEAMGx/UdYAAAD6AAAADwAAAGRycy9kb3du cmV2LnhtbESPS2vCQBRG9wX/w3CF7upMLBRJHaUUg0LrIvaxvs1ck9TMw5lpjP56h25cXs7lfJz5 ctAd68mH1hoJ2UQAI1NZ1ZpawudH8TADFiIahZ01JOFMAZaL0d0cc2VPpqR+F2uWJCbkKKGJ0eWc h6ohjWFiHZnE9tZrjOn0NVceT0muOz4V4olrbE1aaNDRa0PVYfenJbw7fskeV/3bLPu9bL+KUui1 O0h5Px5enoFFGuLteSW+i+MN/qs2KrVMge3X5x/fqhJDJC8hxaXUhIAvrgAAAP//AwBQSwECLQAU AAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQBb6YCk9wIAANQHAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4 bWwueG1sUEsBAi0AFAAGAAgAAAAhADBsf1HWAAAA+gAAAA8AAAAAAAAAAAAAAAAATgUAAGRycy9k b3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAABRBgAAAAAAABDwCAAAAHQNmw17D+4ODwAR8EIAAAAP AIgTOgAAAA8AihMyAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMUAAAAAACsDwwAAAAAAAAA AAAAAAAAAAAPAA3wVAAAAAAAnw8EAAAABAAAAAAAoQ8aAAAAAQAAAAAAAAgKAAEABwABAAAAAAAE AP////4AAKoPCgAAAAEAAAABAAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCXCAAAEgAK8AgA AAALEAAAAAoAALMAC/BcAAAAfwAAAAQAgACAdGYFhwABAAAAvwAAAAYAgQEEAAAIvwEQABAAwAGJ pKcAywE4YwAA/wEIAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAxADIAAAAjACLx ZQcAAP8BAABAAKnDWQcAAFBLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5 cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//Ej qVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIu fSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl 7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZ Rn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8B AAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBY Rm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpS ohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfG ctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQ SwMEFAAGAAgAAAAhAB9fZj70AgAA1AcAABAAAABkcnMvc2hhcGV4bWwueG1srFXBThsxEL1X6j9Y vlawCZBAVywIKtEeEIoS+ICJ15ts47VXtpMmfH2f7U2AtEJVwyWZ9cz4vXn2jC+v141iK2ldbXTB +8c9zqQWpqz1rOBPj3dHF5w5T7okZbQs+EY6fn31+dNlm7uWIVm7vC343Ps2zzIn5rIhd2xaqeGr jG3I49POstZKJ7UnD6BGZSe93jBrqNb8Clvp1aQd2WCJh9XIsroEl1PONDXAHEsBBjMlWf+EZ11U SIi2RgKM7PUuLu5G+bqyTUeS/oVkaekXKt/jR7mpKrYu+HAwOAVxzjYFH5xdDM9gA5pyufZMIOB8 CDf8AgFDWOeD4M8SkRDYWue/S3MwKRY2KriFMhCQclrdO5+gthBRkiQEzspvlAyBSo8laonn9t+S 4HxQ7ElEjkcuvynLVqQKTkLglPvJNadSpuUBxIhaQYtdRlQmEgrMqlqpD+PWEQjX8U9uSacOL0DL qoKQHwbee0+YBL5DjJUb/XHgTa2N/RsBhVPpKk946YKki9Hmfn1ryk2gM8U/evDQO0JazI0tuPA2 NYlyfhLQDt0ZRaCRDt0lboIyG7L3BUfPwhhHQ61wj7FQ6xJXOZqkZpiOoRJWyuqRppPngn/tn4UB wKxP8ZLu9a1dYHJxVkHim5g0JSc5U5h7unMjZY5xhjkzWmoBgHRZlZ60IrByrRgJn/qmH/pm2ziv I25ltR+7DUP+i/em8u/Edd7pEv37uI7CTpeT5515hzJ2Hw94AGKIp2maNpRDjXEavziSMMHRTLoc kSUss8WyqRvzs06youaCS330NMGTAv36F0G9adI6/i4LrgESXhxbLzD5tZlEi7OFtOF9itNXEF6c LrAVMRN3viFVP8sf8TOIrurwXgFBm5E1pgp24Kd0+NXmDvMm9UNacUbVZViMer2dHC+98yYqdfFW i+W97rRahm06O54885tWViRA6Eujj5Tvng3ac0hKDuH2HMJ1vfuibpyebWzibe/iDXTt1W8AAAD/ /wMAUEsDBBQABgAIAAAAIQA4jx9t1gAAAPoAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9La8JAFEb3 Bf/DcIXu6kwUiqSOUorBQusi9rG+zVyT1MzDmWmM/nqHblxezuV8nMVq0B3ryYfWGgnZRAAjU1nV mlrC50fxMAcWIhqFnTUk4UwBVsvR3QJzZU+mpH4Xa5YkJuQooYnR5ZyHqiGNYWIdmcT21muM6fQ1 Vx5PSa47PhXikWtsTVpo0NFLQ9Vh96clvDt+yWbr/m2e/V62X0Up9MYdpLwfD89PwCIN8fa8Ft/F 8Qb/Va8qtcyA7TfnH9+qEkMkLyHFpdSEgC+vAAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAA AOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh ADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh AB9fZj70AgAA1AcAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYA CAAAACEAOI8fbdYAAAD6AAAADwAAAAAAAAAAAAAAAABLBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAA AAAEAAQA9QAAAE4GAAAAAAAAEPAIAAAAgA0gEAAS+g4PABHwQgAAAA8AiBM6AAAADwCKEzIAAAAA ALoPDgAAAF8AXwBfAFAAUABUADkAAACLExQAAAAAAKwPDAAAAAAAAAAAAAAAAAAAAA8ADfBUAAAA AACfDwQAAAAEAAAAAAChDxoAAAABAAAAAAAACAoAAQAHAAEAAAAAAAQA/////gAAqg8KAAAAAQAA AAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8J8IAAASAArwCAAAAAwQAAAACgAAowAL8FYA AAB/AAAABACAAEB1ZgWHAAEAAAC/AAAABgC/AQAAEADAAYmkpwDLAThjAAD/AQgACACAwxoAAAC/ AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADEAMwAAACMAIvFzBwAA/wEAAEAAqcNnBwAAUEsDBBQA BgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYq baoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7W T8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTe JXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzO Fxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu 9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrD MAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuK omXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMe dEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w 09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAZXXIuwEDAAAp CAAAEAAAAGRycy9zaGFwZXhtbC54bWysVdtuGjEQfa/Uf7D8WiVAAiRdZRMlldI+oAhB8gGD1wtb vPbKNhTy9T22F5LQKqpKXmDWM545czyXq5tNrdhaWlcZnfPeaZczqYUpKj3P+dPj/cklZ86TLkgZ LXO+lY7fXH/+dNVkrmG4rF3W5HzhfZN1Ok4sZE3u1DRSQ1caW5PHp513Giud1J48AtWqc9btDjs1 VZpfw5VeT5uxDZJ4WI8tqwpg6XOmqUbMiRRAMFeS9c55p7UKF6KscQFC57UXF71Rtilt3YKkfwFZ WPqFzA/wUWbKkm1yfjEE7C4o2uZ80B9enA+6AQ9lcuOZ2BtwJmAwhOXFIOg7CUgwbKzz36U5GhQL jnJuwQwIpIzWI+dTqF2IcKzNfaXUsQwkdhOneHa/VTI4V3oiQUssgf9mF08N3s5iErF65Ddl2ZpU zkkIFEwvqRZUyHQ8iE+Qct3fiCRHQAFZiaQ/DFsLIFT2n9gSjDZeCC3LEm/yYcG77xGTgu8jxsyN /rjgdaWN/RsAhVdpM0/xYvu1hdFkfnNnim2AM8M/2vnYGiEtFsbmXHib+k05Pw1leKxnJIGePNZL dII0a7KjnGM8QJhEQa1RxziodIFSjiKpOQZtyIQVsnyk2fQ55197/X6YK9Yne0kjfWeXGIKclaD4 Nl6akZOcKYxQ3apxZYHJiJE1XmmBAKlYlZ42IqByjRgLn/qmF/omzivMo9cWd7I8tN2Z4f6L9rb0 79i12tkK/fu4icTOVtPnvXiPNPYfD9gl0cTTLA0uysDGJE1yPElYBmgmXYzJEo7ZclVXtflZJVqR c86lPnmaYjuBv95lYG+WuI6/q5xrBAnLy1ZLLBFtplHibCltWHUY5RjUhOXVGjYi3kTN16SqZ/kj fgbSVRVWH8y1GVtjyigXlfUY86lDlQ5407hNnZFOnFFVEWZwZO7tDHnpojdWqZ93rKxGumVtFdy0 cqwB5reNLEkA2pdanyjf7iI6UEhKCuEOFMK1XfzCc5yjTWznXRdjsbrm+jcAAAD//wMAUEsDBBQA BgAIAAAAIQDBWryt1wAAAPoAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9NTwIxEIbvJvyHZki8SVdD lCwUokb8ipddCVyH7bBb2bZLW2H590486PHN8+aZeWeL3rbiSCEa7xRcjzIQ5CqvjasVrD6XVxMQ MaHT2HpHCs4UYTEfXMww1/7kCjqWqRYscTFHBU1KXS5lrBqyGEe+I8ds54PFxDHUUgc8sdy28ibL bqVF4/hCgx09NlTty2/Lbzz0hw//VpTjlX/eGHqflHdflVKXw/5+CiJRn/7LT9l6edj/wV/Vq2bJ GMTu5bwNRhcYEwUFPI6nMgI5/wEAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAA AAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAA AI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBldci7AQMA ACkIAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAMFa vK3XAAAA+gAAAA8AAAAAAAAAAAAAAAAAWAUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUA AABcBgAAAAAAABDwCAAAAHQNwBKgFO4ODwAR8EIAAAAPAIgTOgAAAA8AihMyAAAAAAC6Dw4AAABf AF8AXwBQAFAAVAA5AAAAixMUAAAAAACsDwwAAAAAAAAAAAAAAAAAAAAPAA3wVAAAAAAAnw8EAAAA BAAAAAAAoQ8aAAAAAQAAAAAAAAgKAAEABwABAAAAAAAEAP////4AAKoPCgAAAAEAAAABAAAAAAAA AKYPDAAAAPAAAADUAdAC8AMQBQ8ABPDbAAAAogwK8AgAAAANEAAAAAoAAIMAC/BEAAAAfwAAAO8B gAAAdmYFvwACAAYAvwEAABAA/wEAABgAPwMAAAgAgMMUAAAAvwMAAAIAVABlAHgAdABCAG8AeAAg ADUAAAAAABDwCAAAAMkNwBKgFLEODwAN8GcAAAAAAJ8PBAAAAAEAAAAAAKgPAwAAAFM9MAAAoQ8c AAAABAAAAAAAASgKAAAAAQAAAAcABAAAAAAAAgASAAAAqg8OAAAABAAAAAcAAAAAAAkECQQAAKYP DgAAAPgAAAAAANQB0ALwAxAFDwAE8N0AAACiDArwCAAAAA4QAAAACgAAgwAL8EYAAAB/AAAA7wGA AKD+uAO/AAIABgC/AQAAEAD/AQAAGAA/AwAACACAwxYAAAC/AwAAAgBUAGUAeAB0AEIAbwB4ACAA MQA1AAAAAAAQ8AgAAADJDSAQABKxDg8ADfBnAAAAAACfDwQAAAABAAAAAACoDwMAAABTPTEAAKEP HAAAAAQAAAAAAAEoCgAAAAEAAAAHAAQAAAAAAAIAEgAAAKoPDgAAAAQAAAAHAAAAAAAJBAkEAACm Dw4AAAD4AAAAAADUAdAC8AMQBQ8ABPDdAAAAogwK8AgAAAAPEAAAAAoAAIMAC/BGAAAAfwAAAO8B gAAgdGYFvwACAAYAvwEAABAA/wEAABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdABCAG8AeAAg ADEANgAAAAAAEPAIAAAAtA2bDXsPnQ4PAA3wZwAAAAAAnw8EAAAAAQAAAAAAqA8DAAAAUz0xAACh DxwAAAAEAAAAAAABKAoAAAABAAAABwAEAAAAAAACABIAAACqDw4AAAAEAAAABwAAAAAACQQJBAAA pg8OAAAA+AAAAAAA1AHQAvADEAUPAATw3QAAAKIMCvAIAAAAEBAAAAAKAACDAAvwRgAAAH8AAADv AYAAoHVmBb8AAgAGAL8BAAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAQgBvAHgA IAAxADcAAAAAABDwCAAAAMkNlAt0DbEODwAN8GcAAAAAAJ8PBAAAAAEAAAAAAKgPAwAAAFM9MQAA oQ8cAAAABAAAAAAAASgKAAAAAQAAAAcABAAAAAAAAgASAAAAqg8OAAAABAAAAAcAAAAAAAkECQQA AKYPDgAAAPgAAAAAANQB0ALwAxAFDwAE8N0AAACiDArwCAAAABEQAAAACgAAgwAL8EYAAAB/AAAA 7wGAAIB3ZgW/AAIABgC/AQAAEAD/AQAAGAA/AwAACACAwxYAAAC/AwAAAgBUAGUAeAB0AEIAbwB4 ACAAMQA4AAAAAAAQ8AgAAAC9DaAIgAqlDg8ADfBnAAAAAACfDwQAAAABAAAAAACoDwMAAABTPTAA AKEPHAAAAAQAAAAAAAEoCgAAAAEAAAAHAAQAAAAAAAIAEgAAAKoPDgAAAAQAAAAHAAAAAAAJBAkE AACmDw4AAAD4AAAAAADUAdAC8AMQBQ8ABPDdAAAAogwK8AgAAAASEAAAAAoAAIMAC/BGAAAAfwAA AO8BgADAdmYFvwACAAYAvwEAABAA/wEAABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdABCAG8A eAAgADEAOQAAAAAAEPAIAAAAxg24BZgHrg4PAA3wZwAAAAAAnw8EAAAAAQAAAAAAqA8DAAAAUz0w AAChDxwAAAAEAAAAAAABKAoAAAABAAAABwAEAAAAAAACABIAAACqDw4AAAAEAAAABwAAAAAACQQJ BAAApg8OAAAA+AAAAAAA1AHQAvADEAUPAATw3QAAAKIMCvAIAAAAExAAAAAKAACDAAvwRgAAAH8A AADvAYAA4HRmBb8AAgAGAL8BAAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAQgBv AHgAIAAyADAAAAAAABDwCAAAALQN4AHAA50ODwAN8GcAAAAAAJ8PBAAAAAEAAAAAAKgPAwAAAFM9 MQAAoQ8cAAAABAAAAAAAASgKAAAAAQAAAAcABAAAAAAAAgASAAAAqg8OAAAABAAAAAcAAAAAAAkE CQQAAKYPDgAAAPgAAAAAANQB0ALwAxAFDwAE8I8GAABCAQrwCAAAABQQAACACwAAgwAL8FoAAAB/ AQAAAQC/AQAAEADAAf/AAADLAdFWAAD/ARgAGAADAwAAAACAwyoAAAC/AwAAAgBTAHQAcgBhAGkA ZwBoAHQAIABDAG8AbgBuAGUAYwB0AG8AcgAgADcAAAAjACLxBQYAAP8BAABAAKnD+QUAAFBLAwQU AAYACAAAACEA/iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPh alqqB2NM6R6sHtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3f t0/FnRSUDTozBgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpV NmAGzEVeMmRTt9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L 5HzB0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9 wXxKV4efar4BAAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOk kD1rAzEMhvdC/4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwO Nk0LBilwnGhw8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l +VJHGWz24ewHtNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBx EEW/loJLU8uBve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEA8VUi e6ABAACMBAAAFAAAAGRycy9jb25uZWN0b3J4bWwueG1svJNNTwMhEIbvJv4Hwt3urtpaN1IPTerF GOPXHXehJWEHAmS7/fcOUOtHNDHWyAkywzwv7wwXl0OnSS+cVwYYrUYlJQIa0ypYMvr4sDiaUuID h5ZrA4LRjfD0cnZ4cGFrbwleBl9bRlch2LoofLMSHfcjYwVgTBrX8YBHtyysE15A4AFBnS6Oy3JS dFwBnWEp6OcD3NtbFw/NTX/riGoZRTbwDqn3wXG1XAUyNwCiCcaRM1psk7dX0xHwKm6KTyV9Ks3r QbpuK5r/RHTr+Bqd+KCXSK3sE3qFynltpCQDo2cn59VpieZtGB1X02qCe9TBazEE0mAChhqMVeVk Ms2xIsuJSdb5cCXM/tJiIUa1ApHE8f7ah2jHGyLiNOztwZrRY1zjhPFGq3ahtI7FvVs+z7UjPdeM Lhbzcvfad2koSENqU+4MDlPYaJHF3Qm0NA3W73ukWvQ8dyjNpNhJ4k2DY1jF7iQVSItYifL/DFxm W+Jn+A685UW0kBJH+j/hO2J6uYG/g3cKjPvq9WF4tVxmXu5+7jp+V29nLwAAAP//AwBQSwMEFAAG AAgAAAAhAIoJN1u9AAAA2gAAAA8AAABkcnMvZG93bnJldi54bWxET82KwjAQvgu+QxjBm6Z6EOka RQTRgyCrfYBpM9sUm0lJYq1vbw7CHj++/81usK3oyYfGsYLFPANBXDndcK2guB9naxAhImtsHZOC NwXYbcejDebavfiX+lusRQrhkKMCE2OXSxkqQxbD3HXEiftz3mJM0NdSe3ylcNvKZZatpMWGU4PB jg6GqsftaRU8utP1ostYDM/VuSh905vlXio1nQz7HxCRhvgv/rrPWkHamq6kGyC3HwAAAP//AwBQ SwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABfcmVs cy8ucmVsc1BLAQItABQABgAIAAAAIQDxVSJ7oAEAAIwEAAAUAAAAAAAAAAAAAAAAAC4CAABkcnMv Y29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQCKCTdbvQAAANoAAAAPAAAAAAAAAAAAAAAA AAAEAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAA6gQAAAAAAAAQ8AgAAADADDASMBJg Dw8ABPCYBgAAQgEK8AgAAAAVEAAAgAsAAIMAC/BcAAAAfwEAAAEAvwEAABAAwAH/wAAAywHRVgAA /wEYABgAAwMAAAAAgMMsAAAAvwMAAAIAUwB0AHIAYQBpAGcAaAB0ACAAQwBvAG4AbgBlAGMAdABv AHIAIAAyADQAAAAjACLxDAYAAP8BAABAAKnDAAYAAFBLAwQUAAYACAAAACEA/iXrpQABAADqAQAA EwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPhalqqB2NM6R6sHtWY9QEITFtiOxAG 6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3ft0/FnRSUDTozBgQt90By01xe1Nt9 BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJ RpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZ AMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9wXxKV4efar4BAAD//wMAUEsDBBQA BgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOkkD1rAzEMhvdC/4PR3vMlQyklvmyF rCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwONk0LBilwnGhw8H56e3oBo8VT9DMT Oriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l+VJHGWz24ewHtNu2fbbymwHdimkO 0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBxEEW/loJLU8uBve/d/NMbmAhDYfmo jpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEAU4CFn6MBAACOBAAAFAAAAGRycy9jb25u ZWN0b3J4bWwueG1svJNfT8MgFMXfTfwOhHct3dycjcyHJfPFGOO/d2xhI6EXAqR2395LqYsaTYwa +1QC3N+551zOL/rWkE76oC1wWh4zSiTUttGw4fThfn20oCREAY0wFiSnOxnoxfLw4NxVwRG8DKFy nG5jdFVRhHorWxGOrZOAe8r6VkRc+k3hvAwSoogIak0xYWxetEIDXWIp6FY93Lkbnxb1dXfjiW44 ncwoAdEi9i56oTfbSFYWQNbRejI5ocV4fLw8LAEv40/xoWgYiouqV74dZYvvyG68eEYv3ikmymj3 iG6hdlFZpUjP6cmczaZTdGvH6aw8m5yW06RPVLKPpMYD6GyNeyWbzxeMpb0iy0mHnA/xUtrfS0uF ODUa5CBOdFchZtQrIuEM/NqDZ4wHv9mACdboZq2NScWD3zytjCedMJyu1yu27/bNMezdwBBTTgbH Ke6MzOJuJVo6jNbPM9INep4TGqZS7iWJusZBLMcEDCAtYRXK/zMwy7ak5/AVeOQltFQKZ/o/4Xvi 0LmFv4O3Gqz/rPvYv1quMi+nn1PH5xrc8gUAAP//AwBQSwMEFAAGAAgAAAAhALLU8S3BAAAA2wAA AA8AAABkcnMvZG93bnJldi54bWxEj9GKwjAURN8F/yFcYd80tbAi1SgiiD4sLKv9gGtzbYrNTUli 7f79RhD2cZiZM8x6O9hW9ORD41jBfJaBIK6cbrhWUF4O0yWIEJE1to5JwS8F2G7GozUW2j35h/pz rEWCcChQgYmxK6QMlSGLYeY64uTdnLcYk/S11B6fCW5bmWfZQlpsOC0Y7GhvqLqfH1bBvTt+f+lr LIfH4lRefdObfCeV+pgMuxWISEP8D7/bJ60g/4TXl/QD5OYPAAD//wMAUEsBAi0AFAAGAAgAAAAh AP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAxAQAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAU4CFn6MBAACOBAAAFAAAAAAAAAAAAAAAAAAuAgAAZHJzL2Nvbm5lY3RvcnhtbC54 bWxQSwECLQAUAAYACAAAACEAstTxLcEAAADbAAAADwAAAAAAAAAAAAAAAAADBAAAZHJzL2Rvd25y ZXYueG1sUEsFBgAAAAAEAAQA+QAAAPEEAAAAAAAAEPAIAAAAxwxVC1ULZw8PAATwkgYAAEIBCvAI AAAAFhAAAIALAACDAAvwXAAAAH8BAAABAL8BAAAQAMAB/8AAAMsB0VYAAP8BGAAYAAMDAAAAAIDD LAAAAL8DAAACAFMAdAByAGEAaQBnAGgAdAAgAEMAbwBuAG4AZQBjAHQAbwByACAAMgA1AAAAIwAi 8QYGAAD/AQAAQACpw/oFAABQSwMEFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAABbQ29udGVudF9U eXBlc10ueG1slJHNTsQgEMfvJr4D4WpaqgdjTOkerB7VmPUBCExbYjsQBuvu2zvd7l6Ma+IR5v/x G6g3u2kUMyTyAbW8LispAG1wHnst37dPxZ0UlA06MwYELfdActNcXtTbfQQS7EbScsg53itFdoDJ UBkiIE+6kCaT+Zh6FY39MD2om6q6VTZgBsxFXjJkU7fQmc8xi8cdX68kCUaS4mEVLl1amhhHb01m UjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8wdH3wk+TvAPxalJ+NhNjKJdo2QDB5pBYV/6dtKBOVISu 8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8SleHn2q+AQAA//8DAFBLAwQUAAYACAAAACEAlgUzWNQA AACXAQAACwAAAF9yZWxzLy5yZWxzpJA9awMxDIb3Qv+D0d7zJUMpJb5shawhha7G1n2Qs2Qkc03+ fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZNCwYpcJxocPB+ent6AaPFU/QzEzq4osK+e3zYHXH2pR7p OGU1lULqYCwlv1qrYcTkteGMVJOeJflSRxls9uHsB7Tbtn228psB3YppDtGBHOIWzOmaq/kPO01B WLkvTeBkue+ncI9qI3/SEZdK8TJgcRBFv5aCS1PLgb3v3fzTG5gIQ2H5qI6V/Cep9u8GdvXO7gYA AP//AwBQSwMEFAAGAAgAAAAhAJJ/MtGdAQAAjgQAABQAAABkcnMvY29ubmVjdG9yeG1sLnhtbLyT 30vDMBDH3wX/h5B313a4Osq6PRTqi8hw6ntsky6QXkISuu6/99LO+QNBccM+5bjLfb6573Wx6ltF Om6d1JDTZBJTwqHStYQmp0+P5dWcEucZ1Exp4Dndc0dXy8uLhcmcIXgZXGZyuvXeZFHkqi1vmZto wwFzQtuWeQxtExnLHQfPPIJaFU3jOI1aJoEusRV0RQ8bs7YhqO67tSWyzuk0pQRYi9iNt0w2W08K DcArry2Zzmh0KD9cHkLAy3iIvjR1Q3OW9cK2B9nsN7Jry3Y4i0+KiVDSPOO0UDvLtBCkxyC9Sa9j HN8+p7NknqR4Rh0s470nFRZgqsJcEqfpfMxFo5xQZKzzt1yfLi00yqmSwAdxrLtzPozjHRFwCk6e wQ7twW82YJxWsi6lUqG5s81LoSzpmMppWRbx8bUfylCQgsGm0RlcJ79XfBT3wHGkw2r93SNZB1NG dWEr+VESqypcxCS4M6hAWsAKlH82cPwz+MALaC4E7vR/wo/E4eUazgdvJWj73et9/zZyMfJG90fX 8Xd1ZvkKAAD//wMAUEsDBBQABgAIAAAAIQBCBm9awQAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1s RI9Bi8IwFITvgv8hPMGbpttDWapRZGHRgyC6/QHP5m1TbF5KEmv3328EweMwM98w6+1oOzGQD61j BR/LDARx7XTLjYLq53vxCSJEZI2dY1LwRwG2m+lkjaV2Dz7TcImNSBAOJSowMfallKE2ZDEsXU+c vF/nLcYkfSO1x0eC207mWVZIiy2nBYM9fRmqb5e7VXDr96ejvsZqvBeH6urbweQ7qdR8Nu5WICKN 8R1+tQ9aQV7A80v6AXLzDwAA//8DAFBLAQItABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAA AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEA AAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAJJ/MtGdAQAAjgQA ABQAAAAAAAAAAAAAAAAALgIAAGRycy9jb25uZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAEIG b1rBAAAA2wAAAA8AAAAAAAAAAAAAAAAA/QMAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkA AADrBAAAAAAAABDwCAAAAMAMIAQgBGAPTwAF8IAAAAABABLwGAAAAAEAAAAAAAAAAAAAAAUQAAD/ /////////wEAEvAYAAAAAgAAAAAAAAAAAAAAFBAAAP//////////AQAS8BgAAAADAAAAAAAAAAAA AAAVEAAA//////////8BABLwGAAAAAQAAAAAAAAAAAAAABYQAAD//////////xAA8AcgAAAA//// AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAC120QGg88QDAAAAKwQAAAAAAAAAHwBE8T0AAAAA ACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJ AAAADwACKwAAAAAAACIECAAAAAEAAAACAAAADwDuA5NjAAACAO8DGAAAABAAAAAAAAAAAAAAAAAA AIAAAQAABwA0AA8ADASaYgAADwAC8JJiAAAQAQjwCAAAABYAAAAWFAAADwAD8PJhAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABQAAAUAAAAPAATwAAEAABIACvAIAAAA AhQAACACAAADAQvwcAAAAAQAAAAAAH8AAQDvAYAAQHtmBYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIA AIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8BEAARAAEDAgQAAD8DAAAIAIDDEAAAAL8DAAACAFQA aQB0AGwAZQAgADEAAAAAABDwCAAAAK0AIAFgFX0DDwAR8BwAAAAAAMMLCAAAAP////8NAJAAAAAf BAQAAAACAAAADwAN8DwAAAAAAJ8PBAAAAAAAAAAAAKgPEgAAAERvdWJsZSBNYXJrIE1ldGhvZAAA qg8OAAAAEwAAAAcAAAAAAAkECQQPAATwRwIAABIACvAIAAAAAxQAACACAAATAQvwkgAAAAQAAAAA AH8AAQDvAYAAYPy4A4EAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8A AAAGAL8BAQABAP8BEAARAAEDAwQAAD8DAAAIAIDDLAAAAL8DAAACAEMAbwBuAHQAZQBuAHQAIABQ AGwAYQBjAGUAaABvAGwAZABlAHIAIAAyAAAAAAAQ8AgAAABgAyABYBWQDw8AEfAcAAAAAADDCwgA AAD/////EwCQAAAAHwQEAAAAAwAAAA8ADfBhAQAAAACfDwQAAAABAAAAAACoDxsBAABVc2UgUyBm bGFnIHRvIGNyZWF0ZSBiYXRjaCBvZiBwYWNrZXRzIGFzIGluIFNpbmdsZSBNYXJrIG1ldGhvZA1V c2UgRCBmbGFnIHRvIGNyZWF0ZSBuZXcgc2V0IG9mIG1hcmtlZCBwYWNrZXRzIHRoYXQgYXJlIGZ1 bGx5IGlkZW50aWZpZWQgb3ZlciB0aGUgQklFUiBuZXR3b3JrDUNvbGxlY3QgYW5kIGNvbXBhcmUg dGltZXN0YW1wcyBvbiBELW1hcmtlZCBwYWNrZXRzIHRvIGNhbGN1bGF0ZSBwYWNrZXQgZGVsYXkg YXMgd2VsbCBhcyB0aGUgbWluaW11bSBhbmQgbWF4aW11bSBkZWxheSB2YWx1ZXMuAAChDxQAAAAc AQAAAAAAAAAAHAEAAAAAAgASAAAAqg8OAAAAHAEAAAcAAAAAAAkECQQPAATwHgEAAKIMCvAIAAAA BBQAAAAKAADDAAvwcgAAAH8AAQDvAYAAIHFmBb8AAAAGAIEBBAAACL8BAAAQAMABAQAACP8BEAAY AAECAgAACD8CAAADAD8DAAAIAIDDKgAAAL8DAAACAEYAbwBvAHQAZQByACAAUABsAGEAYwBlAGgA bwBsAGQAZQByACAAMwAAAAAAEPAIAAAAXg+wB9AOihAPABHwCQAAAAAAIAQBAAAACQ8ADfBrAAAA AACfDwQAAAABAAAAAACoDwcAAABJRVRGLTk1AAChDxwAAAAIAAAAAAABKAoAAAABAAAABwAIAAAA AAACAA4AAACqDw4AAAAIAAAABwAAAAAACQQJBAAApg8OAAAA+AAAAAAA1AHQAvADEAUPAATwsAYA AAICCvAIAAAABRQAAAALAACDAAvwZgAAAL8BAAAQAMABACBgAMsBOGMAANEBBQAAAP8BCAAIAAMD AAAAAIDDNgAAAL8DAAACAFMAdAByAGEAaQBnAGgAdAAgAEEAcgByAG8AdwAgAEMAbwBuAG4AZQBj AHQAbwByACAANAAAACMAIvEaBgAA/wEAAEAAqcMOBgAAUEsDBBQABgAIAAAAIQD+JeulAAEAAOoB AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7 EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U 230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+v JAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiX aNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwME FAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+ bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0 MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2K aQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh +aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQABgAIAAAAIQBT6jb/rAEAAK4EAAAUAAAAZHJzL2Nv bm5lY3RvcnhtbC54bWy8U19LwzAQfxf8DiHvrt3YOilmIsP5IiL++QBnm26B9BKS0HXf3kvTDRQE UfGt11zu9+9ydd23mnXSeWVQ8Okk50xiZWqFW8FfXzYXl5z5AFiDNigFP0jPr1fnZ1e29JbRZfSl FXwXgi2zzFc72YKfGCuRzhrjWghUum1mnfQSAwQCanU2y/Mia0EhX9Eo7NY9PttHF4vqoXt0TNWC LzhDaAn1OThQ211gN86ZPVsbRFkF49icZ+OVccBQIg2gj+zTYD8AQNk3rh2pw3eo1w725Mcn1lCa pmG94MuCxJBvB8GL/LKYLxeRFJSyD6yK58vlbB4bKurI41mWOMQm63y4k+bXfFgcJLgfjTo5NCV/ oYTu3ocEfASMvzX+1ga2F3y2iOriPG+0qjdK66Fw27e1dqwDTbLzWV4ctX9oC6D0LdYsHCwFDTHf 0SKNQ4QpNVq3cNAysX6SZPywej/Oj/aLoknuDFsrT1yhqmhRpycWhBZhG9L1Z8CjX/G5fAU84kVo 2TS07v8JfkIclBv8O/BWoXFpWz6qD/3R8ibhpfRT6vSUvV29AwAA//8DAFBLAwQUAAYACAAAACEA 0q0JYMYAAADaAAAADwAAAGRycy9kb3ducmV2LnhtbESPT2sCMRTE7wW/Q3hCL6JZBUtdjeIfShWp oPbQ42Pz3CxuXpZN6q799E1B6HGYmd8ws0VrS3Gj2heOFQwHCQjizOmCcwWf57f+KwgfkDWWjknB nTws5p2nGabaNXyk2ynkIkLYp6jAhFClUvrMkEU/cBVx9C6uthiirHOpa2wi3JZylCQv0mLBccFg RWtD2fX0bRVMhtvVbv3x1TsezM9utNkk7/vmqtRzt11OQQRqw3/40d5qBWP4uxJvgJz/AgAA//8D AFBLAQItABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFPqNv+sAQAArgQAABQAAAAAAAAAAAAAAAAALgIAAGRy cy9jb25uZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhANKtCWDGAAAA2gAAAA8AAAAAAAAAAAAA AAAADAQAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAAD/BAAAAAAAABDwCAAAAPoO4AEA FfoODwAE8I4IAAASAArwCAAAAAYUAAAACgAAswAL8FoAAAB/AAAABACAAKB4ZgWHAAEAAAC/AAAA BgCBAQQAAAi/ARAAEADAAYmkpwDLAThjAAD/AQgACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBn AGwAZQAgADUAAAAjACLxXgcAAP8BAABAAKnDUgcAAFBLAwQUAAYACAAAACEA8PeKu/0AAADiAQAA EwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZ WHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0L xCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJp ZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUP GChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAI AAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksH uwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJ YN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CP bgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr 9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhACFct3/tAgAA0QcAABAAAABkcnMvc2hhcGV4bWwu eG1srFXbbhoxEH2v1H+w/FolQAQkXWUTJZXSPqAIQfIBg9cLW7z2yjYU8vU9thdIaBVVJS8w6xnP nDlz8fXtplZsLa2rjM5577zLmdTCFJWe5/z56eHsijPnSRekjJY530rHb28+f7puMtcwXNYua3K+ 8L7JOh0nFrImd24aqaErja3J49POO42VTmpPHoFq1bnodoedmirNb+BKr6fN2AZJPK7HllVFzoec aaoRciIFAMyVZAPeaW2CeZQ1zCF0Xvtw0Rdlm9LWLUT6F4iFpV/I+wgdZaYs2Sbnl0OABj/bnA/6 g/5w0A1wKJMbz8QrvYDBEJaXEW4n4QiGjXX+uzQnY2LBUc4teAF7lNF65Hwg4RAiMpJ4QKH8Vslg qPREIpVYtP9mBMVBshcxcqy3/KYsW5PKOQmBEveSakGFTMcDkBG5AsD9jQg3AgrIykqpD8PWAgi9 +Ce2xFMbL4SWZQkiPyx49z1iUvB9xJi50R8XvK60sX8DoFCVNvMULzVIaowm85t7U2wDnBn+MYCn 9ghpsTA258LbNCTK+WmIdqpnJIEuP9VLdII0a7KjnGOmIUyioNboYxxUukArR5HUHKsxZMIKWT7R bPqS86+9fj8sA+uTvaSRvrdLrFDOSlB8Fy/NyEnOFJaebtW4ssAyw5oZr7RAgNSsSk8bEVC5RoyF T3PTC3OzG5zXFveyPLbdmeH+QXtX+nfsWu1shfl92kRiZ6vpy158QBr7j0ds/2jiaZa2DWVgY5K2 L0oS1jeGSRdjsoRjtlzVVW1+VolW5Jxzqc+ep3hPwF/vKrA3S1zH31XONYKE58ZWS+x9baZR4mwp bXicsH45E4TnpjVsRLyJnq9JVS/yR/wMpKsqPFYw12ZsjSmDHPApHX61ecC+SfOQTpxRVREOI19v N8dhdt5YpSnecbEa6ZarVXDTyrHyzG8bWZIAoC+1PlO+fTboSCEpKYQ7UgjXzu6B3bTs4xDvZhdP oGtufgMAAP//AwBQSwMEFAAGAAgAAAAhAEpQxXHWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxE j0trwkAUhfeC/2G4Qnc6EwsiqaOUYrDQdhH7WN9mrklq5uHMNEZ/fYduXB7O4Tt8q82gO9aTD601 ErKZAEamsqo1tYSP92K6BBYiGoWdNSThQgE26/FohbmyZ1NSv481SxATcpTQxOhyzkPVkMYws45M 6g7Wa4wp+porj+cE1x2fC7HgGluTHhp09NRQddz/agmvjl+z+23/ssx+rm+fRSn0zh2lvJsMjw/A Ig3xNt6Kr+J0K/9Rz0rCAthhd/n2rSoxRPISklsyTZbA138AAAD//wMAUEsBAi0AFAAGAAgAAAAh APD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAIVy3f+0CAADRBwAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBL AQItABQABgAIAAAAIQBKUMVx1gAAAPkAAAAPAAAAAAAAAAAAAAAAAEQFAABkcnMvZG93bnJldi54 bWxQSwUGAAAAAAQABAD1AAAARwYAAAAAAAAQ8AgAAABsDeABwAPmDg8AEfBCAAAADwCIEzoAAAAP AIoTMgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAAAArA8MAAAAAAAAAAAAAAAAAAAA DwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAAAAAICgABAAcAAQAAAAAABAD////+AACq DwoAAAABAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwmAgAABIACvAIAAAABxQAAAAK AACjAAvwVAAAAH8AAAAEAIAA4HpmBYcAAQAAAL8AAAAGAL8BAAAQAMABiaSnAMsBOGMAAP8BCAAI AIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANgAAACMAIvFuBwAA/wEAAEAAqcNiBwAA UEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH 74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0 N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ 3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUx QP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7Pb bHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVs c6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4 jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZN zzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAP VAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAfh1t q/wCAAAdCAAAEAAAAGRycy9zaGFwZXhtbC54bWysVdtuGjEQfa/Uf7D8WiUsachllU2UVEr7gCIE yQcMXi9s8dor21DI1/fYXkhCq6gqeYFZz3jmzPFcrm7WjWIraV1tdMH7xxlnUgtT1npW8KfH+6ML zpwnXZIyWhZ8Ix2/uf786arNXctwWbu8Lfjc+zbv9ZyYy4bcsWmlhq4ytiGPTzvrtVY6qT15BGpU 7yTLznoN1Zpfw5VeTdqRDZJ4WI0sq8uCn3OmqUHIsRQAMFOSnfFeZxPMo6xhDqH32oeLvihfV7bp INK/QCwt/ULee+goN1XF1gU/OckuLzIQtCn44PTs/OsgC3gol2vPBAwuL7OzoBcwgJCdD4K+l4AE w9Y6/12ag0Gx4KjgFsSAPsppNXQ+hdqGCMfa3NdKHcpAYjdxikf3GyWDc6XHErTEAvhvdvHQgdiY RKwd+U1ZtiJVcBIC5dJPqjmVMh0PwGukHbTubkSSI6CArELSH4atAxDq+k9sifIuXggtqwpv8mHB s/eIScF3EWPmRn9c8KbWxv4NgMKrdJmneLH9usJoc7++M+UmwJniH818aI2QFnNjCy68Tf2mnJ+E MjzUM5JATx7qJTpBmg3ZYcHR/hDGUVAr1DEOal2ilKNIaoYxGzJhpaweaTp5xtzon56GuWF9spc0 1Hd2gXHMWQWKb+OlKTnJmcIA1Z0aV+YYjBhZo6UWCJCKVelJKwIq14qR8Klv+qFvto3z2uJOVvu2 WzPcf9HeVv4du047XaJ/H9eR2Oly8rwT75HG7uMBmySaeJqmwUU52BinSY4nCasAzaTLEVnCMVss m7oxP+tEK3IuuNRHTxPsJvDXj1N5mriOv8uCawQJq8vWC+wQbSZR4mwhbVh02D8Y1ITV1Rm2It5E zTek6mf5I34G0lUdFh/MtRlZY6ogB3xKh980ZFM/pBNnVF2GyRv5ejs5XnrnjVXq4i0Xy6HuuFoG N50cX575TSsrEgD0pdFHyncbiPYUkpJCuD2FcF3vvrAbp2cbm3jbu1inrr3+DQAA//8DAFBLAwQU AAYACAAAACEAgO56ptcAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPT08CMRTE7yZ8h+aReJOu xghZKESN+C9ediVwfWwfu5Vtu7QVlm/viwc9Tmbym5nZoretOFKIxjsF16MMBLnKa+NqBavP5dUE REzoNLbekYIzRVjMBxczzLU/uYKOZaoFQ1zMUUGTUpdLGauGLMaR78ixt/PBYmIZaqkDnhhuW3mT ZXfSonHc0GBHjw1V+/Lb8oyH/vDh34ryduWfN4beJ+X4q1LqctjfT0Ek6tN/+ClbLw/7P/MX9aoV jEHsXs7bYHSBMVFQwN/4KeNBzn8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIA AACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAfh1tq/wC AAAdCAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQCA 7nqm1wAAAPkAAAAPAAAAAAAAAAAAAAAAAFMFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1 AAAAVwYAAAAAAAAQ8AgAAAB0DXAF4AfuDg8AEfBCAAAADwCIEzoAAAAPAIoTMgAAAAAAug8OAAAA XwBfAF8AUABQAFQAOQAAAIsTFAAAAAAArA8MAAAAAAAAAAAAAAAAAAAADwAN8FQAAAAAAJ8PBAAA AAQAAAAAAKEPGgAAAAEAAAAAAAAICgABAAcAAQAAAAAABAD////+AACqDwoAAAABAAAAAQAAAAAA AACmDwwAAADwAAAA1AHQAvADEAUPAATwlQgAABIACvAIAAAACBQAAAAKAACjAAvwVAAAAH8AAAAE AIAAwHxmBYcAAQAAAL8AAAAGAL8BAAAQAMABiaSnAMsBOGMAAP8BCAAIAIDDGAAAAL8DAAACAFIA ZQBjAHQAYQBuAGcAbABlACAANwAAACMAIvFrBwAA/wEAAEAAqcNfBwAAUEsDBBQABgAIAAAAIQDw 94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tH FV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7e kYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVL HX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUk XjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP// AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9 cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xY fYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23 Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/ 6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEA8iRHt/kCAAAdCAAAEAAAAGRy cy9zaGFwZXhtbC54bWysVdtuGjEQfa/Uf7D8WqVAArmssomSSmkfUIQg+YDB64UtXntlGwr5+h7b CyS0iqqSF5j1jGfOHM/l+nZdK7aS1lVG57z3tcuZ1MIUlZ7l/Pnp4eSSM+dJF6SMljnfSMdvbz5/ um4y1zBc1i5rcj73vsk6HSfmsib31TRSQ1caW5PHp511Giud1J48AtWqc9rtnndqqjS/gSu9mjQj GyTxuBpZVhU5R2BNNUKOpQCAmZLsgndam2AeZQ1zCJ3XPlz0Rdm6tHULkf4FYmHpF/I+QEeZKUu2 zvlZ//Sq2wVBm5wP+ucXZ4NuwEOZXHsmYHDV6/eDXsDgHJYXg6DvJCDBsLHOf5fmaFAsOMq5BTGg jzJaDZ1PobYhwrE2D5VSxzKQ2E2c4tH9RsngXOmxBC2xAP6bXTw0eDuNScTakd+UZStSOSchUC69 pJpTIdPxALxG2kHr7kYkOQIKyEok/WHYWgChrv/Elihv44XQsizxJh8WvPseMSn4LmLM3OiPC15X 2ti/AVB4lTbzFC+2X1sYTebX96bYBDhT/KOZj60R0mJubM6Ft6nflPOTUIbHekYS6MljvUQnSLMm O8w52h/COApqhTrGQaULlHIUSc0wZkMmrJDlE00nL/u5YX2ylzTU93aBccxZCYrv4qUpOcmZwgDV rRqu5xiMGFmjpRYIkIpV6UkjAirXiJHwqW96oW+2jfPa4l6Wh7ZbM9zfa+9K/45dq50u0b9P60js dDl52YkPSGP38YhNEk08TdPgogxsjNMkx5OEVYBm0sWILOGYLZZ1VZufVaIVOedc6pPnCXYT+Otd hqk7TVzH32XONYKE1WWrBXaINpMocbaQNiw67B8MasLqag0bEW+i5mtS1Yv8ET8D6aoKiw/m2oys MWWQAz6lw28asqkf0okzqirC5I18vZ0c+955Y5W6eMvFcqhbrpbBTSvHl2d+08iSBAB9qfWJ8u0G ogOFpKQQ7kAhXNu7e3bj9GxiE297F+vUNTe/AQAA//8DAFBLAwQUAAYACAAAACEAuVkuK9cAAAD5 AAAADwAAAGRycy9kb3ducmV2LnhtbESPT08CMRTE7yZ8h+aReJMuxihZKESN+Id42YXo9bl97Ba2 7dJWWL69Lx70OJnJb2Zmi9624kghGu8UjEcZCHKV18bVCjbr5dUEREzoNLbekYIzRVjMBxczzLU/ uYKOZaoFQ1zMUUGTUpdLGauGLMaR78ixt/XBYmIZaqkDnhhuW3mdZbfSonHc0GBHjw1V+/Lb8oyH /vDu34ryZuOfPw2tJuXdrlLqctjfT0Ek6tN/+Cn7WB72f+Yv6lUr4OHbl/NXMLrAmCgo4G/8lPEg 5z8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtD b250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAA AAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA8iRHt/kCAAAdCAAAEAAAAAAAAAAAAAAA AAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQC5WS4r1wAAAPkAAAAPAAAAAAAA AAAAAAAAAFAFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAVAYAAAAAAAAQ8AgAAAB0 DXAIsAruDg8AEfBCAAAADwCIEzoAAAAPAIoTMgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsT FAAAAAAArA8MAAAAAAAAAAAAAAAAAAAADwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAA AAAICgABAAcAAQAAAAAABAD////+AACqDwoAAAABAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvAD EAUPAATwlAgAABIACvAIAAAACRQAAAAKAACzAAvwWgAAAH8AAAAEAIAAgH1mBYcAAQAAAL8AAAAG AIEBBAAACL8BEAAQAMABiaSnAMsBOGMAAP8BCAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcA bABlACAAOAAAACMAIvFkBwAA/wEAAEAAqcNYBwAAUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlY d9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvE IrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlk EA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8Y KGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgA AAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7 CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg 372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9u A+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1 x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEArKy3rPMCAADSBwAAEAAAAGRycy9zaGFwZXhtbC54 bWysVdtuGjEQfa/Uf7D8WqVAyiVdZRMlldI+oAhB8gGD1wtbvPbKNhTy9T22F5LQKqpKXmDWczyX MxdfXm9rxTbSusronPc+dzmTWpii0oucPz7cnV1w5jzpgpTRMuc76fj11ccPl03mGobL2mVNzpfe N1mn48RS1uQ+m0Zq6Epja/L4tItOY6WT2pOHo1p1zrvdYaemSvMrmNKbWTOxQRL3m4llVZHzr5xp quFyKgUCWCjJLninxQR4lDXgEDovbbhoi7Jtaes2RPqXEAtLv5D3UXSUmbJk25z3R93BlwEI2uV8 0B+OggzXlMmtZwKA0RBZQS8AGEIaDYK+kwIJwMY6/12ak4NiwVDOLYgBfZTRZux8crV3ESlJRKBS fqdkACo9lcglVu2/KUF1kOx59BwLLr8pyzakck5CoMa9pFpSIdPxAGRErsDF4UZkJgYUIisrpd4t tjaA0Ix/xpZ4av0F17IsQeS7Oe++RUxyfvAYMzf6/ZzXlTb2bwEoVKXNPPlLDZIao8n89tYUuxDO HP+YwFN7hLRYGptz4W0aEuX8LHg71TKSwCCdaiUaQZo12XHOMbMQplFQG/QxDipdoJWjSGqB3Rgy YYUsH2g+e8J66vX7YditT3hJY31rV9ihnJWg+CZempOTnClsPd2qcWWJbYY9M1lrAQepWZWeNSJE 5RoxET7NTS/MzX5wXiJuZXmM3cNw/1l7U/o3cK12vsb8PmwjsfP17Okg3iGNw8c91n+EeJqnbUMZ 2Jim9YuShP2NYdLFhCzhmK3WdVWbn1WiFTnnXOqzxxkeFPDXuwjszRPX8Xedcw0n4b2x1QqLX5tZ lDhbSRteJ6xXbFfCe9MCGxFvoudrUtWT/BE/A+mqCq8V4NpMrDFlkEN8Sodfbe6wb9I8pBNnVFWE w8jX683xPDuvUGmK91ysx7rlah3MtHKsPPO7RpYkENCnWp8p3z4bdKSQlBTCHSmEa2f3md24PZs4 xPvZxRvomqvfAAAA//8DAFBLAwQUAAYACAAAACEAc+eR/NYAAAD5AAAADwAAAGRycy9kb3ducmV2 LnhtbESPTU/CQBRF9yb+h8kzcScz1cRAYSDG0GCiLgrK+tF5tIXOhzNjKfx6J25Y3tybc3Nmi0F3 rCcfWmskZCMBjExlVWtqCV+b4mEMLEQ0CjtrSMKZAizmtzczzJU9mZL6daxZgpiQo4QmRpdzHqqG NIaRdWRSt7deY0zR11x5PCW47vijEM9cY2vSQ4OOXhuqjutfLeHD8Uv2tOzfx9nh8vldlEKv3FHK +7vhZQos0hCv46XYFj/X8h/1piRMgO1X551vVYkhkpeQ3JJpsgQ+/wMAAP//AwBQSwECLQAUAAYA CAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBL AQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BL AQItABQABgAIAAAAIQCsrLes8wIAANIHAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwu eG1sUEsBAi0AFAAGAAgAAAAhAHPnkfzWAAAA+QAAAA8AAAAAAAAAAAAAAAAASgUAAGRycy9kb3du cmV2LnhtbFBLBQYAAAAABAAEAPUAAABNBgAAAAAAABDwCAAAAHQNlAt0De4ODwAR8EIAAAAPAIgT OgAAAA8AihMyAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMUAAAAAACsDwwAAAAAAAAAAAAA AAAAAAAPAA3wVAAAAAAAnw8EAAAABAAAAAAAoQ8aAAAAAQAAAAAAAAgKAAEABwABAAAAAAAEAP// //4AAKoPCgAAAAEAAAABAAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCVCAAAEgAK8AgAAAAK FAAAAAoAALMAC/BaAAAAfwAAAAQAgABAfmYFhwABAAAAvwAAAAYAgQEEAAAIvwEQABAAwAGJpKcA ywE4YwAA/wEIAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA5AAAAIwAi8WUHAAD/ AQAAQACpw1kHAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10u eG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kU M0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+d jxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi 2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wn qHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAA AF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX +j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJ n1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3Pfe vqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQA BgAIAAAAIQCnMshG9QIAANMHAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxV224aMRB9r9R/sPxapVwS SLLKJkoqpX1AEYLkAwavF7Z47ZVtKOTre2wvJKFVVJW8wKxnPHPmzMVXN5tasbW0rjI6572vXc6k Fqao9DznT4/3JxecOU+6IGW0zPlWOn5z/fnTVZO5huGydlmT84X3TdbpOLGQNbmvppEautLYmjw+ 7bzTWOmk9uQRqFadfrc77NRUaX4NV3o9bcY2SOJhPbasKoAFUDTViDmRAgjmSrJL3mmNgn2UNewh dF47cdEZZZvS1i1G+heMhaVfSPwAHmWmLNkm54NB/7I/POVsC/lseH466AY8lMmNZwIG50OkBdgC BkNI54Og7yQgwbCxzn+X5mhQLDjKuQUx4I8yWo+cT6F2ISIliQiUym+VDIZKTyRyiWX7b0pQHiTb j5FjxeU3ZdmaVM5JCBS5l1QLKmQ6HoCMyBW42N+IzERAAVlZKfVh2FoAoRv/xJZ4auOF0LIsQeSH Be++R0wKvo8YMzf644LXlTb2bwAUqtJmnuKlBkmN0WR+c2eKbYAzwz9G8NgeIS0WxuZceJuGRDk/ DdGO9YwkMEjHeolOkGZNdpRzzCyESRTUGn2Mg0oXaOUokppjOYZMWCHLR5pNn3N+2Ts7C8NufbKX NNJ3donFxVkJim/jpRk5yZnC2tOtGlcW2GbYM+OVFgiQmlXpaSMCKteIsfBpbnphbnaD89riTpaH tjsz3H/R3pb+HbtWO1thfh83kdjZavq8F++Rxv7jAfs/mniapW1DGdiYpPWLkoQFjmHSxZgs4Zgt V3VVm59VohU551zqk6cpXhTw17sI7M0S1/F3lXONIOHBsdUSi1+baZQ4W0obniesV2xXwoPTGjYi 3kTP16SqZ/kjfgbSVRWeK5hrM7bGlEEO+JQOv9rcY9+keUgnzqiqCIeRr7eb42V23lilKd5xsRrp lqtVcNPKsfLMbxtZkgCgL7U+Ub59NuhAISkphDtQCNfO7gu7cXs2cYh3s4s30DXXvwEAAP//AwBQ SwMEFAAGAAgAAAAhACCqvinVAAAA+gAAAA8AAABkcnMvZG93bnJldi54bWxEj01Lw0AQQO+C/yGM 4M3uRkFK7LaINFRQD6na8zQ7TWKzH+6uadpf79BLjzNveMObLUbTZwOF2DmrIJ9IyMjWTne2UfD1 Wd5NIYsJrcbeWVJwpAiL+fXVDAvtDraiYZ2ajCU2FqigTckXQsS6JYNx4jxZZjsXDCYeQyN0wAPL TS/upXwUBjvLH1r09NJSvV//GQXvXpzyh+XwNs1/Th/fZSXNyu+Vur0Zn58gSzSmy/FSbsrfCzyr XjW3cMpuddyGTlcYEwUFvOFURiDm/wAAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAA EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h 0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCnMshG 9QIAANMHAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAh ACCqvinVAAAA+gAAAA8AAAAAAAAAAAAAAAAATAUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAE APUAAABOBgAAAAAAABDwCAAAAHQNmw17D+4ODwAR8EIAAAAPAIgTOgAAAA8AihMyAAAAAAC6Dw4A AABfAF8AXwBQAFAAVAA5AAAAixMUAAAAAACsDwwAAAAAAAAAAAAAAAAAAAAPAA3wVAAAAAAAnw8E AAAABAAAAAAAoQ8aAAAAAQAAAAAAAAgKAAEABwABAAAAAAAEAP////4AAKoPCgAAAAEAAAABAAAA AAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCWCAAAEgAK8AgAAAALFAAAAAoAALMAC/BcAAAAfwAA AAQAgAAAf2YFhwABAAAAvwAAAAYAgQEEAAAIvwEQABAAwAGJpKcAywE4YwAA/wEIAAgAgMMaAAAA vwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAxADAAAAAjACLxZAcAAP8BAABAAKnDWAcAAFBLAwQU AAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDm Km2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+ 1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U 3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBc zhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mU Lvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFq wzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0L iqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKlj HnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzP MNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhAEzYUNfzAgAA 1AcAABAAAABkcnMvc2hhcGV4bWwueG1srFXBbhoxEL1X6j9YvlbpQhpIusomSiqlPaAIQfIBg9cL W7z2yjYU8vV9theS0CqqSi4w65nxe/PsGV9ebxrF1tK62uiC9z/3OJNamLLW84I/PtydXHDmPOmS lNGy4Fvp+PXVxw+Xbe5ahmTt8rbgC+/bPMucWMiG3GfTSg1fZWxDHp92nrVWOqk9eQA1Kjvt9YZZ Q7XmV9hKr6ft2AZL3K/HltUluPQ509QAcyIFGMyVZP0ez7qokBBtjQQY2ctdXNyN8k1lm44k/QvJ 0tIvVH7Aj3JTVWxT8OFg8AXEOdsWfHB2MTyDDWjK5cYzgYDzIdzwCwQMYZ0Pgj9LREJga53/Ls3R pFjYqOAWykBAymk9cj5B7SCiJEkInJXfKhkClZ5I1BLP7b8lwfmg2NOIHI9cflOWrUkVnITAKfeT a0GlTMsDiBG1ghb7jKhMJBSYVbVS78atIxCu45/ckk4dXoCWVQUh3w2895YwCXyPGCs3+v3Am1ob +zcCCqfSVZ7w0gVJF6PN/ebWlNtAZ4Z/9OCxd4S0WBhbcOFtahLl/DSgHbszikAjHbtL3ARlNmRH BUfPwphEQ61xj7FQ6xJXOZqk5piOoRJWyuqBZtOngn/tn4UBwKxP8ZJG+tYuMbk4qyDxTUyakZOc Kcw93bmRssA4w5wZr7QAQLqsSk9bEVi5VoyFT33TD32za5yXEbeyOozdhSH/2XtT+TfiOu9shf59 2ERhZ6vp0968Qxn7j3s8ADHE0yxNG8qhxiSNXxxJmOBoJl2OyRKW2XLV1I35WSdZUXPBpT55nOJJ gX79i6DeLGkdf1cF1wAJL46tl5j82kyjxdlS2vA+xekrCC9OF9iKmIk735Cqn+SP+BlEV3V4r4Cg zdgaUwU78FM6/Gpzh3mT+iGtOKPqMixGvV5PjufeeRWVuninxWqkO61WYZvOjifP/LaVFQkQ+tTo E+W7Z4MOHJKSQ7gDh3Bd7z6rG6dnG5t417t4A1179RsAAP//AwBQSwMEFAAGAAgAAAAhAChJ3hXW AAAA+gAAAA8AAABkcnMvZG93bnJldi54bWxEj09rwkAQR+8Fv8MyQm91NxaKpK5SxGCh7SG29Txm xyQ1+6e72xj99F28eBze8H68+XLQHevJh9YaCdlEACNTWdWaWsLXZ/EwAxYiGoWdNSThTAGWi9Hd HHNlT6akfhtrliQm5CihidHlnIeqIY1hYh2ZxA7Wa4zp9DVXHk9Jrjs+FeKJa2xNWmjQ0aqh6rj9 0xLeHb9kj+v+bZb9XD6+i1LojTtKeT8eXp6BRRri7XktdsXvDV5Vryq1ZMAOm/Pet6rEEMlLSHEp NSHgi38AAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAA AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAA AAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEATNhQ1/MCAADUBwAAEAAAAAAAAAAA AAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQAoSd4V1gAAAPoAAAAPAAAA AAAAAAAAAAAAAEoFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAATQYAAAAAAAAQ8AgA AACADSAQABL6Dg8AEfBCAAAADwCIEzoAAAAPAIoTMgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAA AIsTFAAAAAAArA8MAAAAAAAAAAAAAAAAAAAADwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEA AAAAAAAICgABAAcAAQAAAAAABAD////+AACqDwoAAAABAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQ AvADEAUPAATwnwgAABIACvAIAAAADBQAAAAKAACjAAvwVgAAAH8AAAAEAIAAAIBmBYcAAQAAAL8A AAAGAL8BAAAQAMABiaSnAMsBOGMAAP8BCAAIAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABl ACAAMQAxAAAAIwAi8XMHAAD/AQAAQACpw2cHAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMA AABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh3 3950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qi ux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQ Dwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgo a8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAA ACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sK W0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDf vb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D 6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XH rBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQCZuI0eAQMAACkIAAAQAAAAZHJzL3NoYXBleG1sLnht bKxV224aMRB9r9R/sPxapQtpIOkqmyiplPYBRQiSDxi8XtjitVe2oZCv77G9kIRWUVXyArOe8cyZ 47lcXm8axdbSutrogvc/9ziTWpiy1vOCPz7cnVxw5jzpkpTRsuBb6fj11ccPl23uWobL2uVtwRfe t3mWObGQDbnPppUausrYhjw+7TxrrXRSe/II1KjstNcbZg3Vml/BlV5P27ENkrhfjy2rS2A55UxT g5gTKYBgriTr93nWWYULUda4ACF76cVFb5RvKtt0IOlfQJaWfiHzA3yUm6pim4KfDwG7B4q2BR+c Dc+/DHoBD+Vy45nYG3AmYDCE5fkg6LMEJBi21vnv0hwNigVHBbdgBgRSTuuR8ynULkQ41uauVupY BhK7iVM8u98qGZwrPZGgJZbAf7OLpwZvpzGJWD3ym7JsTargJAQKpp9UCyplOh7EJ0i57m9EkiOg gKxC0u+GrQMQKvtPbAlGFy+EllWFN3m34L23iEnB9xFj5ka/X/Cm1sb+DYDCq3SZp3ix/brCaHO/ uTXlNsCZ4R/tfGyNkBYLYwsuvE39ppyfhjI81jOSQE8e6yU6QZoN2VHBMR4gTKKg1qhjHNS6RClH kdQcgzZkwkpZPdBs+lTwr/2zszBXrE/2kkb61i4xBDmrQPFNvDQjJzlTGKG6U+PKApMRI2u80gIB UrEqPW1FQOVaMRY+9U0/9E2cV5hHLy1uZXVouzPD/WftTeXfsOu0sxX692ETiZ2tpk978Q5p7D/u sUuiiadZGlyUg41JmuR4krAM0Ey6HJMlHLPlqqkb87NOtCLngkt98jjFdgJ//YvA3ixxHX9XBdcI EpaXrZdYItpMo8TZUtqw6jDKMagJy6szbEW8iZpvSNVP8kf8DKSrOqw+mGsztsZUUS5r6zHmU4cq HfCmcZs6I504o+oyzODI3OsZ8txFr6xSP+9YWY10x9oquOnkWAPMb1tZkQC0T40+Ub7bRXSgkJQU wh0ohOu6+JnnOEfb2M67LsZide3VbwAAAP//AwBQSwMEFAAGAAgAAAAhAPEQ/iTXAAAA+gAAAA8A AABkcnMvZG93bnJldi54bWxEj01PAjEQhu8m/IdmSLxJV2KULBSiRvyKl10JXIftsFvZtktbYfn3 Tjzo8c3z5pl5Z4vetuJIIRrvFFyPMhDkKq+NqxWsPpdXExAxodPYekcKzhRhMR9czDDX/uQKOpap FixxMUcFTUpdLmWsGrIYR74jx2zng8XEMdRSBzyx3LZynGW30qJxfKHBjh4bqvblt+U3HvrDh38r ypuVf94Yep+Ud1+VUpfD/n4KIlGf/stP2Xp52P/BX9WrZskYxO7lvA1GFxgTBQU8jqcyAjn/AQAA //8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEA AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAJm4jR4BAwAAKQgAABAAAAAAAAAAAAAAAAAAKQIA AGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA8RD+JNcAAAD6AAAADwAAAAAAAAAAAAAA AABYBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAFwGAAAAAAAAEPAIAAAAdA3AEqAU 7g4PABHwQgAAAA8AiBM6AAAADwCKEzIAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExQAAAAA AKwPDAAAAAAAAAAAAAAAAAAAAA8ADfBUAAAAAACfDwQAAAAEAAAAAAChDxoAAAABAAAAAAAACAoA AQAHAAEAAAAAAAQA/////gAAqg8KAAAAAQAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE 8OIAAACiDArwCAAAAA0UAAAACgAAgwAL8EYAAAB/AAAA7wGAAKB+ZgW/AAIABgC/AQAAEAD/AQAA GAA/AwAACACAwxYAAAC/AwAAAgBUAGUAeAB0AEIAbwB4ACAAMQAyAAAAAAAQ8AgAAADvDcASoBSL Dg8ADfBsAAAAAACfDwQAAAABAAAAAACoDwgAAABTPTAsIEQ9MAAAoQ8cAAAACQAAAAAAASgKAAAA AQAAAAcACQAAAAAAAgAKAAAAqg8OAAAACQAAAAcAAAAAAAkECQQAAKYPDgAAAPgAAAAAANQB0ALw AxAFDwAE8JQGAABCAQrwCAAAAA4UAACACwAAgwAL8FwAAAB/AQAAAQC/AQAAEADAAf/AAADLAdFW AAD/ARgAGAADAwAAAACAwywAAAC/AwAAAgBTAHQAcgBhAGkAZwBoAHQAIABDAG8AbgBuAGUAYwB0 AG8AcgAgADEAOQAAACMAIvEIBgAA/wEAAEAAqcP8BQAAUEsDBBQABgAIAAAAIQD+JeulAAEAAOoB AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7 EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U 230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+v JAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiX aNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwME FAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+ bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0 MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2K aQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh +aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQABgAIAAAAIQBA4c/2owEAAI4EAAAUAAAAZHJzL2Nv bm5lY3RvcnhtbC54bWy8k19PwyAUxd9N/A6Edy3d3JyNzIcl88UY4793bGEjoRcCpHbf3kupixpN jBr7VALc37nnXM4v+taQTvqgLXBaHjNKJNS20bDh9OF+fbSgJEQBjTAWJKc7GejF8vDg3FXBEbwM oXKcbmN0VVGEeitbEY6tk4B7yvpWRFz6TeG8DBKiiAhqTTFhbF60QgNdYinoVj3cuRufFvV1d+OJ bjidoBoQLWLvohd6s41kZQFkHa0n5RktxuPj5WEJeBl/ig9Fw1BcVL3y7ShbfEd248UzevFOMVFG u0d0C7WLyipFek5P5mw2naJbO05n5dnktJwmfaKSfSQ1HsBeatwr2Xy+YCztFVlOOuR8iJfS/l5a KsSp0SAHcaK7CjGjXhEJZ+DXHjxjPPjNBkywRjdrbUwqHvzmaWU86YThdL1esX23b45h7waGmHIy OE5xZ2QWdyvR0mG0fp6RbtDznNAwlXIvSdQ1DmI5JmAAaQmrUP6fgVm2JT2Hr8AjL6GlUjjT/wnf E4fOLfwdvNVg/Wfdx/7VcpV5Of2cOj7X4JYvAAAA//8DAFBLAwQUAAYACAAAACEAoqNStb0AAADb AAAADwAAAGRycy9kb3ducmV2LnhtbERPzYrCMBC+C75DGMGbpvYgUo0iC4sehEXtA4zN2BSbSUli rW+/OQgeP77/zW6wrejJh8axgsU8A0FcOd1wraC8/s5WIEJE1tg6JgVvCrDbjkcbLLR78Zn6S6xF CuFQoAITY1dIGSpDFsPcdcSJuztvMSboa6k9vlK4bWWeZUtpseHUYLCjH0PV4/K0Ch7d4e+kb7Ec nstjefNNb/K9VGo6GfZrEJGG+BV/3EetIE/r05f0A+T2HwAA//8DAFBLAQItABQABgAIAAAAIQD+ JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG AAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG AAgAAAAhAEDhz/ajAQAAjgQAABQAAAAAAAAAAAAAAAAALgIAAGRycy9jb25uZWN0b3J4bWwueG1s UEsBAi0AFAAGAAgAAAAhAKKjUrW9AAAA2wAAAA8AAAAAAAAAAAAAAAAAAwQAAGRycy9kb3ducmV2 LnhtbFBLBQYAAAAABAAEAPkAAADtBAAAAAAAABDwCAAAAMcMVQtVC2cPDwAE8JgGAABCAQrwCAAA AA8UAACACwAAgwAL8FwAAAB/AQAAAQC/AQAAEADAAf/AAADLAdFWAAD/ARgAGAADAwAAAACAwywA AAC/AwAAAgBTAHQAcgBhAGkAZwBoAHQAIABDAG8AbgBuAGUAYwB0AG8AcgAgADIAMAAAACMAIvEM BgAA/wEAAEAAqcMABgAAUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/8Ruo N7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZ IiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1 o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSErvMW yjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAA lwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1M oaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe6Thl NZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5 L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4GAAD/ /wMAUEsDBBQABgAIAAAAIQBDV6HzowEAAI4EAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWy8k19P wyAUxd9N/A6Ed9duc3U2sj0smS/GGP+9YwsbCb0QIF337b2UuqjRxDhjn0q43N/hnMvVsms0aYXz ygCj41FOiYDK1Ao2jD49rs/mlPjAoebagGB0LzxdLk5PrmzpLcHD4EvL6DYEW2aZr7ai4X5krADc k8Y1PODSbTLrhBcQeEBQo7NJnhdZwxXQBbaCdtXBg71zcVHdtneOqJrRyZgS4A1iH4LjarMNZGUA RBWMI5OcZkP5cLhfAh7Gn+xTU98352UnXTPI5j+RXTu+Qy8+KCZSK/uMbqF2XhopScfoxXlxUeRo 357R2WQ6vZzPoz5eii6QCgtwq8K9cV4Uc6yLGpOcWGSdD9fCHC8tNmJUKxC9ON7e+JBQb4iI03C0 BzuMB79Zj/FGq3qttI7Nvdu8rLQjLdeMrter/HDbd2V4dw19TCkZHKew1yKJuxdoaT9av89I1eh5 SqifSnGQxKsKB3E8JKABaRErUf6fgfNkS3wO34EHXkQLKXGm/xN+IPY3N/B38EaBcV/dPnRvlsvE S+mn1PG5ert4BQAA//8DAFBLAwQUAAYACAAAACEAze/3LsEAAADbAAAADwAAAGRycy9kb3ducmV2 LnhtbESPQYvCMBSE74L/ITxhb5rag0jXKCKIHoRF7Q94Nm+bYvNSkljrvzfCwh6HmfmGWW0G24qe fGgcK5jPMhDEldMN1wrK6366BBEissbWMSl4UYDNejxaYaHdk8/UX2ItEoRDgQpMjF0hZagMWQwz 1xEn79d5izFJX0vt8ZngtpV5li2kxYbTgsGOdoaq++VhFdy7w89J32I5PBbH8uab3uRbqdTXZNh+ g4g0xP/wX/uoFeRz+HxJP0Cu3wAAAP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAA AAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAA AJcBAAALAAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBDV6HzowEA AI4EAAAUAAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAA IQDN7/cuwQAAANsAAAAPAAAAAAAAAAAAAAAAAAMEAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQA BAD5AAAA8QQAAAAAAAAQ8AgAAADhDGASYBKBDw8ABPCSBgAAQgEK8AgAAAAQFAAAgAsAAIMAC/Bc AAAAfwEAAAEAvwEAABAAwAH/wAAAywHRVgAA/wEYABgAAwMAAAAAgMMsAAAAvwMAAAIAUwB0AHIA YQBpAGcAaAB0ACAAQwBvAG4AbgBlAGMAdABvAHIAIAAyADEAAAAjACLxBgYAAP8BAABAAKnD+gUA AFBLAwQUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQ x+8mvgPhalqqB2NM6R6sHtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykA bXAeey3ft0/FnRSUDTozBgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0w PaibqrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhX jCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE 83/zW7a9wXxKV4efar4BAAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMv LnJlbHOkkD1rAzEMhvdC/4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9p NguKTkwONk0LBilwnGhw8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS1 4YxUk54l+VJHGWz24ewHtNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IR l0rxMmBxEEW/loJLU8uBve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAA ACEA7DtxeJ0BAACOBAAAFAAAAGRycy9jb25uZWN0b3J4bWwueG1svJNNT8MwDIbvSPyHKHfoB1BG tW6HSuWCEOLrHtpki5Q6URKV7t/jpGMChARiE7dasf289uvOl2OvyMCtkxoqmp2mlHBodSdhVdGn x+ZkRonzDDqmNPCKbrijy8Xx0dyUzhAsBleaiq69N2WSuHbNe+ZOteGAb0LbnnkM7SoxljsOnnkE 9SrJ07RIeiaBLrAVDPUID+bOhqC9He4skV1F85wSYD1iH7xlcrX2pNYAvPXakjyjyTZ9WxxDwGL8 SL40dbE5K0dh+61s9hvZnWWvuItPiolQ0jzjtlA7K7UQZMSguCzOU1zfpqIX2VV+mZ0Ffazkoyct JuBTi29ZWhQzzAsaJzkhyVjnr7neX1poVFElgUdxbLhxfkK9IwJOwd47eA325PlFxDitZNdIpUJz Z1cvtbJkYKqiTVOnu2k/pOHsCqJNkzN4Tn6j+CTunuNK42n93SPZBVMmdeEq+U4Sa1s8xHg9UQXS Alag/IOB05/BW15AcyHwpv8TviPGyTUcDt5L0Pa76f34vnIx8Sb3J9fxd3Vm8QYAAP//AwBQSwME FAAGAAgAAAAhAD09aVnBAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj0GLwjAUhO8L/ofwBG9r ag+yVKOIIHoQRLc/4Nk8m2LzUpJY6783wsIeh5n5hlmuB9uKnnxoHCuYTTMQxJXTDdcKyt/d9w+I EJE1to5JwYsCrFejryUW2j35TP0l1iJBOBSowMTYFVKGypDFMHUdcfJuzluMSfpaao/PBLetzLNs Li02nBYMdrQ1VN0vD6vg3u1PR32N5fCYH8qrb3qTb6RSk/GwWYCINMT/8F/7oBXkOXy+pB8gV28A AAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAx AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA7DtxeJ0BAACOBAAAFAAAAAAAAAAAAAAAAAAu AgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAPT1pWcEAAADbAAAADwAAAAAA AAAAAAAAAAD9AwAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAOsEAAAAAAAAEPAIAAAA xwwgBCAEZw8PAATw4gAAAKIMCvAIAAAAERQAAAAKAACDAAvwRgAAAH8AAADvAYAAYH9mBb8AAgAG AL8BAAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAQgBvAHgAIAAyADIAAAAAABDw CAAAAAIOIBAAEp0ODwAN8GwAAAAAAJ8PBAAAAAEAAAAAAKgPCAAAAFM9MSwgRD0wAAChDxwAAAAJ AAAAAAABKAoAAAABAAAABwAJAAAAAAACAAoAAACqDw4AAAAJAAAABwAAAAAACQQJBAAApg8OAAAA +AAAAAAA1AHQAvADEAUPAATw4gAAAKIMCvAIAAAAEhQAAAAKAACDAAvwRgAAAH8AAADvAYAAYIBm Bb8AAgAGAL8BAAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAQgBvAHgAIAAyADMA AAAAABDwCAAAAAIOmw17D50ODwAN8GwAAAAAAJ8PBAAAAAEAAAAAAKgPCAAAAFM9MSwgRD0xAACh DxwAAAAJAAAAAAABKAoAAAABAAAABwAJAAAAAAACAAoAAACqDw4AAAAJAAAABwAAAAAACQQJBAAA pg8OAAAA+AAAAAAA1AHQAvADEAUPAATw4gAAAKIMCvAIAAAAExQAAAAKAACDAAvwRgAAAH8AAADv AYAAgGpTBb8AAgAGAL8BAAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAQgBvAHgA IAAyADQAAAAAABDwCAAAAAIOlAt0DZ0ODwAN8GwAAAAAAJ8PBAAAAAEAAAAAAKgPCAAAAFM9MSwg RD0wAAChDxwAAAAJAAAAAAABKAoAAAABAAAABwAJAAAAAAACAAoAAACqDw4AAAAJAAAABwAAAAAA CQQJBAAApg8OAAAA+AAAAAAA1AHQAvADEAUPAATw4gAAAKIMCvAIAAAAFBQAAAAKAACDAAvwRgAA AH8AAADvAYAAwIBmBb8AAgAGAL8BAAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQA QgBvAHgAIAAyADUAAAAAABDwCAAAAAIOoAiACp0ODwAN8GwAAAAAAJ8PBAAAAAEAAAAAAKgPCAAA AFM9MCwgRD0wAAChDxwAAAAJAAAAAAABKAoAAAABAAAABwAJAAAAAAACAAoAAACqDw4AAAAJAAAA BwAAAAAACQQJBAAApg8OAAAA+AAAAAAA1AHQAvADEAUPAATw4gAAAKIMCvAIAAAAFRQAAAAKAACD AAvwRgAAAH8AAADvAYAAIHdmBb8AAgAGAL8BAAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQA ZQB4AHQAQgBvAHgAIAAyADYAAAAAABDwCAAAAAIOuAWYB50ODwAN8GwAAAAAAJ8PBAAAAAEAAAAA AKgPCAAAAFM9MCwgRD0xAAChDxwAAAAJAAAAAAABKAoAAAABAAAABwAJAAAAAAACAAoAAACqDw4A AAAJAAAABwAAAAAACQQJBAAApg8OAAAA+AAAAAAA1AHQAvADEAUPAATw4gAAAKIMCvAIAAAAFhQA AAAKAACDAAvwRgAAAH8AAADvAYAAwPa4A78AAgAGAL8BAAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8D AAACAFQAZQB4AHQAQgBvAHgAIAAyADcAAAAAABDwCAAAAPAN4AHAA4sODwAN8GwAAAAAAJ8PBAAA AAEAAAAAAKgPCAAAAFM9MSwgRD0wAAChDxwAAAAJAAAAAAABKAoAAAABAAAABwAJAAAAAAACAAoA AACqDw4AAAAJAAAABwAAAAAACQQJBAAApg8OAAAA+AAAAAAA1AHQAvADEAVPAAXwgAAAAAEAEvAY AAAAAQAAAAAAAAAAAAAABRQAAP//////////AQAS8BgAAAACAAAAAAAAAAAAAAAOFAAA//////// //8BABLwGAAAAAMAAAAAAAAAAAAAAA8UAAD//////////wEAEvAYAAAABAAAAAAAAAAAAAAAEBQA AP//////////EADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAA DwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAMXfRAbCGF9sA AAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAA/////xIA AAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAAIgQIAAAAAQAAAAIAAAAPAO4DJ5UAAAIA 7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAAAAAAHADQADwAMBIeUAAAPAALwf5QAADABCPAIAAAAHgAA AB4YAAAPAAPwH5MAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAGAAA BQAAAA8ABPAEAQAAEgAK8AgAAAACGAAAIAIAAAMBC/BwAAAABAAAAAAAfwABAO8BgACA97gDgQAw ZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEQABEAAQMCBAAA PwMAAAgAgMMQAAAAvwMAAAIAVABpAHQAbABlACAAMQAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAA AAAAwwsIAAAA/////w0AkAAAAB8EBAAAAAIAAAAPAA3wQAAAAAAAnw8EAAAAAAAAAAAAqA8WAAAA U2FtcGxlIEJJRVIgc3ViLWRvbWFpbgAAqg8OAAAAFwAAAAcAAAAAAAkECQQPAATwmAEAABIACvAI AAAAAxgAACACAAATAQvwkgAAAAQAAAAAAH8AAQDvAYAA4HdmBYEAMGUBAIIAmLIAAIMAMGUBAIQA mLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAL8BAQABAP8BEAARAAEDAwQAAD8DAAAIAIDDLAAA AL8DAAACAEMAbwBuAHQAZQBuAHQAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAyAAAAAAAQ8AgA AADwAyABYBWgBQ8AEfAcAAAAAADDCwgAAAD/////EwCQAAAAHwQEAAAAAwAAAA8ADfCyAAAAAACf DwQAAAABAAAAAACoD1wAAABCRlIgQSBhcHBsaWVzIERvdWJsZSBNYXJrIG1ldGhvZA1CRlJzIEIs IEUsIGFuZCBIIHJlY29yZCB0aW1lc3RhbXBzIG9mIEQtdGFnZ2VkIEJJRVIgcGFja2V0cwAAoQ8W AAAAXQAAAAAAAQAAAAAAXQAAAAAAAgASAAAAqg8OAAAAXQAAAAcAAAAAAAkECQQAAKYPBgAAAAgA AAAAAA8ABPAeAQAAogwK8AgAAAAEGAAAAAoAAMMAC/ByAAAAfwABAO8BgABAm1UMvwAAAAYAgQEE AAAIvwEAABAAwAEBAAAI/wEQABgAAQICAAAIPwIAAAMAPwMAAAgAgMMqAAAAvwMAAAIARgBvAG8A dABlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAABeD7AH0A6KEA8AEfAJ AAAAAAAgBAEAAAAJDwAN8GsAAAAAAJ8PBAAAAAEAAAAAAKgPBwAAAElFVEYtOTUAAKEPHAAAAAgA AAAAAAEoCgAAAAEAAAAHAAgAAAAAAAIADgAAAKoPDgAAAAgAAAAHAAAAAAAJBAkEAACmDw4AAAD4 AAAAAADUAdAC8AMQBQ8ABPCYCAAAEgAK8AgAAAAFGAAAAAoAAKMAC/BUAAAAfwAAAAQAgADgkVUM hwABAAAAvwAAAAYAvwEAABAAwAGJpKcAywE4YwAA/wEIAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABh AG4AZwBsAGUAIAA1AAAAIwAi8XAHAAD/AQAAQACpw2QHAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA 4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt 2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrL i3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z +kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKG NJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQU AAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05v hV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHE kQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2Cq ozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+ QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQBCKhaW/wIAABsIAAAQAAAAZHJzL3NoYXBl eG1sLnhtbKxV224aMRB9r9R/sPxapVwCKV1lEyWV0j6gCEHyAYPXC1u89so2FPL1PbYXktAqqkry QGY945kzx3O5vN7Wim2kdZXROe997nImtTBFpRc5f3y4Oxtx5jzpgpTRMuc76fj11ccPl03mGobL 2mVNzpfeN1mn48RS1uQ+m0Zq6Epja/L4tItOY6WT2pNHoFp1+t3uRaemSvMruNKbWTOxQRL3m4ll VZHzC8401Qg5lQIAFkqyIe+0NsE8yhrmEDovfbjoi7JtaesWIv0LxMLSL+R9hI4yU5Zsm/NBb9Qb fBlytst5fzi66J6PAh7K5NYzAYPhsD8YgkABg2FvcA45QEtAgmFjnf8uzcmgWHCUcwtiQB9ltBk7 n0LtQ4Rjbe4qpU5lILGbOMWj+52SwbnSUwlaYgH8N7t4aPDWj0nE2pHflGUbUjknIVAuvaRaUiHT 8bCLv5bWw41IcgQUkJVI+t2wtQBCXf+JLVHexguhZVniTd4tePctYlLwQ8SYudHvF7yutLF/A6Dw Km3mKV5sv7Ywmsxvb02xC3Dm+I9mPrVGSIulsTkX3qZ+U87PQhme6hlJoCdP9RKdIM2a7DjnaH8I 0yioDeoYB5UuUMpRJLXAmFWcFbJ8oPnsKedfe4MBSppZn6wljfWtXWEYc1aC4Jt4ZU5OcqYwPnWr xpUlxiIG1mStBdynUlV61oiAyTViInzqml7omn3bvLS4leWx7d4M95+1N6V/w67Vztfo3odtpHW+ nj0dxDukcfi4xx6JJp7maWxRBjamaY7jQcIiQCvpYkKWcMxW67qqzc8qkYqccy712eMMmwn89UaB vXliOv6uc64RJCwuW62wQbSZRYmzlbRhzWH7YEwTFldr2Ih4ExVfk6qe5I/4GUhXVVh7MNdmYo0p gxzwKR1+04hN3ZBOnFFVEeZu5Ov13HjunFdWqYf3XKzHuuVqHdy0cnx55neNLEkA0Kdanymf+kHS kUJSUgh3pBCu7dxnduPsbGIL7zsXy9Q1V78BAAD//wMAUEsDBBQABgAIAAAAIQDwAAzB1gAAAPkA AAAPAAAAZHJzL2Rvd25yZXYueG1sRI/NTsMwEITvSH0Haytxow4IhSrUrQCJ8iMuCZW4LvE2MY3X qW1a9+2xOMBxNKNvZharZAdxIB+MYwWXswIEceu04U7B5v3xYg4iRGSNg2NScKIAq+XkbIGVdkeu 6dDETmQIhwoV9DGOlZSh7climLmROHtb5y3GLH0ntcdjhttBXhVFKS0azg09jvTQU7trvm2ecZ/2 b+6lbq43bv1h6HXe3Hy1Sp1P090tiEgp/ofLWtIu/Zm/qGetoASxfTp9eqNrDJG8gvwtP814kMsf AAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29u dGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAA LgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEIqFpb/AgAAGwgAABAAAAAAAAAAAAAAAAAA KQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA8AAMwdYAAAD5AAAADwAAAAAAAAAA AAAAAABWBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAFkGAAAAAAAAEPAIAAAAXQZK CqYLoQcPABHwQgAAAA8AiBM6AAAADwCKEzIAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExQA AAAAAKwPDAAAAAAAAAAAAAAAAAAAAA8ADfBSAAAAAACfDwQAAAAEAAAAAAChDxgAAAABAAAAAAAA AAoABwABAAAAAAAEAP////4AAKoPCgAAAAEAAAABAAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8A BPCVCAAAEgAK8AgAAAAGGAAAAAoAAKMAC/BUAAAAfwAAAAQAgADggWYFhwABAAAAvwAAAAYAvwEA ABAAwAGJpKcAywE4YwAA/wEIAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA2AAAA IwAi8W0HAAD/AQAAQACpw2EHAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVu dF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n 5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91Ky HmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxit xpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvf dVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIA AACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3f vqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy +iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzN LNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD/ /wMAUEsDBBQABgAIAAAAIQAB5FoN/AIAABsIAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxV224aMRB9 r9R/sPxapUACSVhlEyWV0j6gCEHyAYPXC1u89so2FPL1PbYXktAqqkpeYNYznjlzPJerm02t2Fpa Vxmd897XLmdSC1NUep7zp8f7k0vOnCddkDJa5nwrHb+5/vzpqslcw3BZu6zJ+cL7Jut0nFjImtxX 00gNXWlsTR6fdt5prHRSe/IIVKvOabd73qmp0vwarvR62oxtkMTDemxZVeT8gjNNNUJOpACAuZLs nHdam2AeZQ1zCJ3XPlz0RdmmtHULkf4FYmHpF/I+QEeZKUu2yXm/N+x1uyBom/Oz4bA7vBgEPJTJ jWcCBoPBaX8AvYDBoNc/gxygJSDBsLHOf5fmaFAsOMq5BTGgjzJaj5xPoXYhwrE295VSxzKQ2E2c 4tH9VsngXOmJBC2xAP6bXTw0eDuNScTakd+UZWtSOSchUC69pFpQIdPxAC+wo3V/I5IcAQVkJZL+ MGwtgFDXf2JLlLfxQmhZlniTDwvefY+YFHwfMWZu9McFrytt7N8AKLxKm3mKF9uvLYwm85s7U2wD nBn+0czH1ghpsTA258Lb1G/K+Wkow2M9Iwn05LFeohOkWZMd5RztD2ESBbVGHeOg0gVKOYqk5hiz irNClo80mz7nfNjr98NUsT5ZSxrpO7vEMOasBMG38cqMnORMYXzqVo0rC4xFDKzxSgu4T6Wq9LQR AZNrxFj41DVhbu3b5rXFnSwPbffd1YgX7W3p37FrtbMVuvdxE2mdrabPe/Eeaew/HrBHoomnWRpb lIGNSZrjeJCwCNBKuhiTJRyz5aquavOzSqQi55xLffI0xWYCf73LwN4sMR1/VznXCBIWl62W2CDa TKPE2VLasOawfTCmCYurNWxEvImKr0lVz/JH/AykqyqsPZhrM7bGlEEO+JQOv2nEpm5IJ86oqghz N/L1dm68dM4bq9TDOy5WI91ytQpuWjm+PPPbRpYkAOhLrU+Ub/cPHSgkJYVwBwrh2s59YTfOzia2 8K5zsUxdc/0bAAD//wMAUEsDBBQABgAIAAAAIQD442z91gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYu eG1sRI9PTwIxFMTvJnyH5pl4k67GAFkpREz8g+GyK4nX5/axW9m+rm2F8u1tOOhxMpPfzMyXyfbi QD4YxwpuxgUI4sZpw62C7fvT9QxEiMgae8ek4EQBlovRxRxL7Y5c0aGOrcgQDiUq6GIcSilD05HF MHYDcfZ2zluMWfpWao/HDLe9vC2KibRoODd0ONBjR82+/rF5xip9b9y6qu+27vnD0Nusnn41Sl1d pod7EJFS/A9PKkn79GeeUa9awRTE7uX06Y2uMETyCvK3/DTjQS5+AQAA//8DAFBLAQItABQABgAI AAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAAHkWg38AgAAGwgAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54 bWxQSwECLQAUAAYACAAAACEA+ONs/dYAAAD5AAAADwAAAAAAAAAAAAAAAABTBQAAZHJzL2Rvd25y ZXYueG1sUEsFBgAAAAAEAAQA9QAAAFYGAAAAAAAAEPAIAAAA0glQCqwLFgsPABHwQgAAAA8AiBM6 AAAADwCKEzIAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExQAAAAAAKwPDAAAAAAAAAAAAAAA AAAAAA8ADfBSAAAAAACfDwQAAAAEAAAAAAChDxgAAAABAAAAAAAAAAoABwABAAAAAAAEAP////4A AKoPCgAAAAEAAAABAAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCVCAAAEgAK8AgAAAAHGAAA AAoAAKMAC/BUAAAAfwAAAAQAgACggmYFhwABAAAAvwAAAAYAvwEAABAAwAGJpKcAywE4YwAA/wEI AAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA3AAAAIwAi8W0HAAD/AQAAQACpw2EH AABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQw EMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ 5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb 7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18 lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/ s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5y ZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZ sniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo 1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlS MA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQBF yEeN/QIAABsIAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxV224aMRB9r9R/sPxapVwCDV1lEyWV0j5E EYLkAwavF7Z47ZVtKOTre2wvkNAqqkryQGY945kzx3O5vN7Uiq2ldZXROe997nImtTBFpec5f3q8 Oxtx5jzpgpTRMudb6fj11ccPl03mGobL2mVNzhfeN1mn48RC1uQ+m0Zq6Epja/L4tPNOY6WT2pNH oFp1+t3ul05NleZXcKXX02ZsgyQe1mPLqiLnCKypRsiJFAAwV5Jd8E5rE8yjrGEOofPSh4u+KNuU tm4h0r9ALCz9Qt5H6CgzZck2OR/0Rr3BxZCzbc6H/fPRxbAb8FAmN54JGAyH/QHOmAgGvcF50ncS kGDYWOe/S3MyKBYc5dyCGNBHGa3vnQ8sHEKEY23uKqVOZSCxmzjFo/utksG50hMJWmIB/De7eGjw 1o9JxNqR35Rla1I5JyFQLr2kWlAh0/Gwi79AO3Ld34hfEVBAViLpd8PWAgh1/Se2BKONF0LLssSb vFvw7lvEpOD7iDFzo98veF1pY/8GQOFV2sxTvNh+bWE0md/cmmIb4MzwH818ao2QFgtjcy68Tf2m nJ+GMjzVM5JAw5zqJTpBmjXZ+5yj/SFMoqDWqGMcVLpAKUeR1BxjVnFWyPKRZtPnnH/tDQYoaWZ9 spZ0r2/tEsOYsxIE38QrM3KSM4XxqVs1riwwFjGwxist4D6VqtLTRgRMrhFj4VPX9ELX7NrmpcWt LI9td2a4f9DelP4Nu1Y7W6F7HzeR1tlq+rwX75DG/uMBeySaeJqlsUUZ2JikOY4HCYsAraSLMVnC MVuu6qo2P6tEKnLOudRnT1NsJvDXGwX2Zonp+LvKuUaQsLhstcQG0WYaJc6W0oY1h+2DMU1YXK1h I+JNVHxNqnqWP+JnIF1VYe3BXJuxNaYMcsCndPhNIzZ1QzpxRlVFmLuRr9dz49A5r6xSD++4WN3r lqtVcNPK8eWZ3zayJAFAn2p9pny7f+hIISkphDtSCNd27oHdtDViC+86F8vUNVe/AQAA//8DAFBL AwQUAAYACAAAACEAwVQ4cNUAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPT08CMRTE7yZ8h+aR eJOuxiBZKURI/Bsvu5J4fWwfu4Vtu7YVyrf3xYMeJzP5zcx8mW0vjhSi8U7B9aQAQa7x2rhWwebj 8WoGIiZ0GnvvSMGZIiwXo4s5ltqfXEXHOrWCIS6WqKBLaSiljE1HFuPED+TY2/lgMbEMrdQBTwy3 vbwpiqm0aBw3dDjQuqPmUH9bnrHKX+/+tapvN/7p09DbrL7bN0pdjvPDPYhEOf2Hp5WkQ/4zf1Ev WgEP3z2ft8HoCmOioIC/8VPGg1z8AAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAAT AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HS AAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEXIR439 AgAAGwgAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA wVQ4cNUAAAD5AAAADwAAAAAAAAAAAAAAAABUBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA 9QAAAFYGAAAAAAAAEPAIAAAA5AxKCqYLKA4PABHwQgAAAA8AiBM6AAAADwCKEzIAAAAAALoPDgAA AF8AXwBfAFAAUABUADkAAACLExQAAAAAAKwPDAAAAAAAAAAAAAAAAAAAAA8ADfBSAAAAAACfDwQA AAAEAAAAAAChDxgAAAABAAAAAAAAAAoABwABAAAAAAAEAP////4AAKoPCgAAAAEAAAABAAAAAAAA AKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCTCAAAEgAK8AgAAAAIGAAAAAoAAKMAC/BUAAAAfwAAAAQA gABAgmYFhwABAAAAvwAAAAYAvwEAABAAwAGJpKcAywE4YwAA/wEIAAgAgMMYAAAAvwMAAAIAUgBl AGMAdABhAG4AZwBsAGUAIAA4AAAAIwAi8WsHAAD/AQAAQACpw18HAABQSwMEFAAGAAgAAAAhAPD3 irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cV XR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6R gh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsd fo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSRe MaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8D AFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x 2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9 gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6 /2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/p lRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQDzlOz3+gIAABsIAAAQAAAAZHJz L3NoYXBleG1sLnhtbKxV224aMRB9r9R/sPxapdwjssomSiqlfYgiBMkHDF4vbPHaK9tQyNf32F5I QquoKnmBWc945szxXC6vt7ViG2ldZXTOe1+7nEktTFHpRc6fHu/Oxpw5T7ogZbTM+U46fn31+dNl k7mG4bJ2WZPzpfdN1uk4sZQ1ua+mkRq60tiaPD7totNY6aT25BGoVp1+t3veqanS/Aqu9GbWTGyQ xMNmYllV5PyCM001Qk6lAICFkmzMO61NMI+yhjmEzmsfLvqibFvauoVI/wKxsPQLeR+ho8yUJdvm fHQxHJx3QdAu54P+YDyCjNCUya1nIhiM+sMR9AIGo95wADlAS0CCYWOd/y7NyaBYcJRzC2JAH2W0 uXc+hdqHCMfa3FVKncpAYjdxikf3OyWDc6WnErTEAvhvdvHQ4K0fk4i1I78pyzakck5CoFx6SbWk QqZjkJ5oB62HG5HkCCggK5H0h2FrAYS6/hNboryNF0LLssSbfFjw7nvEpOCHiDFzoz8ueF1pY/8G QOFV2sxTvNh+bWE0md/emmIX4Mzxj2Y+tUZIi6WxORfepn5Tzs9CGZ7qGUmgJ0/1Ep0gzZrsfc7R /hCmUVAb1DEOKl2glKNIaoExqzgrZPlI89kz5lxvOAxTxfpkLele39oVhjFnJQi+iVfm5CRnCuNT t2pcWWIsYmBN1lrAfSpVpWeNCJhcIybCp67pha7ZT6PXFreyPLbdm+H+i/am9O/Ytdr5Gt37uI20 ztez54N4hzQOHw/YI9HE0zyNLcrAxjTNcTxIWARoJV1MyBKO2WpdV7X5WSVSkXPOpT57mmEzgb/e OLA3T0zH33XONYKExWWrFTaINrMocbaSNqw5bB+MacLiag0bEW+i4mtS1bP8ET8D6aoKaw/m2kys MWWQAz6lw28asakb0okzqirC3I18vZ0bL53zxir18J6L9b1uuVoHN60cX575XSNLEgD0pdZnyrf7 h44UkpJCuCOFcG3nvrAbZ2cTW3jfuVimrrn6DQAA//8DAFBLAwQUAAYACAAAACEAybdYTNYAAAD5 AAAADwAAAGRycy9kb3ducmV2LnhtbESPzU7DMBCE70h9B2srcaNOESol1K0Aib+KS0Ilrku8TdzG drBN6749Kw5wHM3om5nFKtteHChE452C6aQAQa7x2rhWweb98WIOIiZ0GnvvSMGJIqyWo7MFltof XUWHOrWCIS6WqKBLaSiljE1HFuPED+TY2/pgMbEMrdQBjwy3vbwsipm0aBw3dDjQQ0fNvv62POM+ f73516q+2vinD0PreX29a5Q6H+e7WxCJcvoPzypJ+/xn/qJetIIbENvn02cwusKYKCjgb/yU8SCX PwAAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAA AC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDzlOz3+gIAABsIAAAQAAAAAAAAAAAAAAAA ACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAMm3WEzWAAAA+QAAAA8AAAAAAAAA AAAAAAAAUQUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAABUBgAAAAAAABDwCAAAAPgH oA78DzwJDwAR8EIAAAAPAIgTOgAAAA8AihMyAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMU AAAAAACsDwwAAAAAAAAAAAAAAAAAAAAPAA3wUgAAAAAAnw8EAAAABAAAAAAAoQ8YAAAAAQAAAAAA AAAKAAcAAQAAAAAABAD////+AACqDwoAAAABAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUP AATwlAgAABIACvAIAAAACRgAAAAKAACjAAvwVAAAAH8AAAAEAIAAAIZmBYcAAQAAAL8AAAAGAL8B AAAQAMABiaSnAMsBOGMAAP8BCAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAOQAA ACMAIvFsBwAA/wEAAEAAqcNgBwAAUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goe Z+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdS sh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMY rcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL 33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HS AAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt 376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalH MvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28 zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA //8DAFBLAwQUAAYACAAAACEAiuQai/wCAAAcCAAAEAAAAGRycy9zaGFwZXhtbC54bWysVdtuGjEQ fa/Uf7D8WqVAgCissomSSmkfUIQg+YDB64UtXntlGwr5+h7bC0loFVUleSCznvHMmeO5XN1sa8U2 0rrK6Jz3vnY5k1qYotKLnD893p9dcuY86YKU0TLnO+n4zfXnT1dN5hqGy9plTc6X3jdZp+PEUtbk vppGauhKY2vy+LSLTmOlk9qTR6Badc673YtOTZXm13ClN7NmYoMkHjYTy6oCWABFU42YUymAYKEk G/FOaxTso6xhD6Hz2omLzijblrZuMdK/YCws/ULiR/AoM2XJtjkfjgb9iy5g7XI+uOj3R71+wEOZ 3HomgsHwfDCEXsBg2Bv0IQdoCUgwbKzz36U5GRQLjnJuQQz4o4w2Y+dTqH2IcKzNfaXUqQwkdhOn eHW/UzI4V3oqQUusgP9mFy8N3s5jErF45Ddl2YZUzkkI1EsvqZZUyHQ87OKvpfVwI5IcAQVkJZL+ MGwtgFDYf2JLlLfxQmhZlniTDwvefY+YFPwQMWZu9McFrytt7N8AKLxKm3mKF9uvLYwm89s7U+wC nDn+o5tPrRHSYmlszoW3qd+U87NQhqd6RhLoyVO9RCdIsyY7zjnaH8I0CmqDOsZBpQuUchRJLTBn FWeFLB9pPnvO+ag3GISpYn2yljTWd3aFCchZCYJv45U5OcmZwvzUrRpXlhiLGFiTtRZwn0pV6Vkj AibXiInwqWt6oWv2bfPa4k6Wx7Z7M9x/0d6W/h27Vjtfo3sft5HW+Xr2fBDvkcbh4wGLJJp4mqex RRnYmKY5jgcJmwCtpIsJWcIxW63rqjY/q0Qqcs651GdPM6wm8Ne7DOzNE9Pxd51zjSBhc9lqhQ2i zSxKnK2kDXsO6wdjmrC5WsNGxJuo+JpU9Sx/xM9AuqrC3oO5NhNrTBnkgE/p8JtGbOqGdOKMqoow dyNfb+fGS+e8sUo9vOdiPdYtV+vgppXjyzO/a2RJAoC+1PpM+dQPko4UkpJCuCOFcG3nvrAbZ2cT W3jfuVimrrn+DQAA//8DAFBLAwQUAAYACAAAACEA4jm6AtUAAAD6AAAADwAAAGRycy9kb3ducmV2 LnhtbESPTU8CMRCG7yb8h2ZIvElXY5CsFCIkfsbLriReh+2wW9i2a1uh/HsnHvQ487x5Zt75Mtte HClE452C60kBglzjtXGtgs3H49UMREzoNPbekYIzRVguRhdzLLU/uYqOdWoFS1wsUUGX0lBKGZuO LMaJH8gx2/lgMfEYWqkDnlhue3lTFFNp0Ti+0OFA646aQ/1t+Y1V/nr3r1V9u/FPn4beZvXdvlHq cpwf7kEkyuk/PK0kHfIf/FW9aJZwld3zeRuMrjAmCgp4w1UZgVz8AAAA//8DAFBLAQItABQABgAI AAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAIrkGov8AgAAHAgAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54 bWxQSwECLQAUAAYACAAAACEA4jm6AtUAAAD6AAAADwAAAAAAAAAAAAAAAABTBQAAZHJzL2Rvd25y ZXYueG1sUEsFBgAAAAAEAAQA9QAAAFUGAAAAAAAAEPAIAAAAZwugDvwPqwwPABHwQgAAAA8AiBM6 AAAADwCKEzIAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExQAAAAAAKwPDAAAAAAAAAAAAAAA AAAAAA8ADfBSAAAAAACfDwQAAAAEAAAAAAChDxgAAAABAAAAAAAAAAoABwABAAAAAAAEAP////4A AKoPCgAAAAEAAAABAAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCYCAAAEgAK8AgAAAAKGAAA AAoAAKMAC/BWAAAAfwAAAAQAgADAhmYFhwABAAAAvwAAAAYAvwEAABAAwAGJpKcAywE4YwAA/wEI AAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAxADAAAAAjACLxbgcAAP8BAABAAKnD YgcAAFBLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1K xDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbgu KxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G 1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsOD DXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI 83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMv LnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcw qZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0 nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13ii uVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAh AHPUHgr9AgAAHQgAABAAAABkcnMvc2hhcGV4bWwueG1srFXbbhoxEH2v1H+w/FqlsATSdJVNlFRK +xBFCJIPGLxe2OK1V7ahkK/vsb2QhFZRVfICs57xzJnjuVxcbRrF1tK62uiCZ5/7nEktTFnrecEf H25PzjlznnRJymhZ8K10/Ory44eLNnctw2Xt8rbgC+/bvNdzYiEbcp9NKzV0lbENeXzaea+10knt ySNQo3qDfv+s11Ct+SVc6fW0Hdsgifv12LK6BJaMM00NYk6kAIK5kizr815nFS5EWeMChN5LLy56 o3xT2aYDSf8CsrT0C5kf4KPcVBXbFHxwdval3wdF24KfDk7PR5ARmnK58UzAYDQaDEfQCxiMsuEp 5AAtAQmGrXX+uzRHg2LBUcEtmAGBlNP6zvkUahciHGtzWyt1LAOJ3cQpnt1vlQzOlZ5I0BJL4L/Z xVMHYmMSsXrkN2XZmlTBSQgUTJZUCyplOgbpiXbQur8RSY6AArIKSb8btg5AqOw/sSXKu3ghtKwq vMm7Be+/RUwKvo8YMzf6/YI3tTb2bwAUXqXLPMWL7dcVRpv7zY0ptwHODP9o52NrhLRYGFtw4W3q N+X8NJThsZ6RBHryWC/RCdJsyN4VHO0PYRIFtUYd46DWJUo5iqTmGLSKs1JWDzSbPhX8azYchqli fbKWdKdv7BIjkLMKBF/HKzNykjOFAao7Na4sMBcxsMYrLeA+larS01YETK4VY+FT12Sha3bT6KXF jawObXdmuP+sva78G3addrZC9z5sIq2z1fRpL94ijf3HPTZJNPE0S2OLcrAxSXMcDxJWAVpJl2Oy hGO2XDV1Y37WiVTkXHCpTx6n2E3gLzsP7M0S0/F3VXCNIGF12XqJFaLNNEqcLaUNiw77B2OasLo6 w1bEm6j4hlT9JH/Ez0C6qsPig7k2Y2tMFeSAT+nwm0Zs6oZ04oyqyzB3I1+v58Zz57yySj2842J1 pzuuVsFNJ8eXZ37byooEAH1q9Iny3f6hA4WkpBDuQCFc17nP7MbZ2cYW3nUulqlrL38DAAD//wMA UEsDBBQABgAIAAAAIQDq2to+1gAAAPoAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9NTwIxEIbvJvyH Zki8SRdjkKwUIiR+hsuuJF7H7bBb2bZrW6H8eyce9PjmefPMvItVtr04UojGOwXTSQGCXOO1ca2C 3dvD1RxETOg09t6RgjNFWC1HFwsstT+5io51agVLXCxRQZfSUEoZm44sxokfyDHb+2AxcQyt1AFP LLe9vC6KmbRoHF/ocKBNR82h/rb8xjp/bf1LVd/s/OO7odd5ffvZKHU5zvd3IBLl9F+eVZIO+Q/+ qp41S6Yg9k/nj2B0hTFRUMDjeCojkMsfAAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIB AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHd X2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAHPU Hgr9AgAAHQgAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAA ACEA6traPtYAAAD6AAAADwAAAAAAAAAAAAAAAABUBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAE AAQA9QAAAFcGAAAAAAAAEPAIAAAA+AeQBuwHPAkPABHwQgAAAA8AiBM6AAAADwCKEzIAAAAAALoP DgAAAF8AXwBfAFAAUABUADkAAACLExQAAAAAAKwPDAAAAAAAAAAAAAAAAAAAAA8ADfBSAAAAAACf DwQAAAAEAAAAAAChDxgAAAABAAAAAAAAAAoABwABAAAAAAAEAP////4AAKoPCgAAAAEAAAABAAAA AAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCZCAAAEgAK8AgAAAALGAAAAAoAAKMAC/BWAAAAfwAA AAQAgACAh2YFhwABAAAAvwAAAAYAvwEAABAAwAGJpKcAywE4YwAA/wEIAAgAgMMaAAAAvwMAAAIA UgBlAGMAdABhAG4AZwBsAGUAIAAxADEAAAAjACLxbwcAAP8BAABAAKnDYwcAAFBLAwQUAAYACAAA ACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFp ugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO 6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhL BjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5 aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwD AAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+D vYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng 4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB 9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdA v/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhAHVsF5/+AgAAHQgAABAA AABkcnMvc2hhcGV4bWwueG1srFXbbhoxEH2v1H+w/FolsAnQZJVNlFRK+4AiBMkHDF4vbOO1V7ah kK/vsb2QS6uoKnmBWc945szxXC6uNo1ia2ldbXTBs+M+Z1ILU9Z6UfCH+9ujM86cJ12SMloWfCsd v7r8/OmizV3LcFm7vC340vs27/WcWMqG3LFppYauMrYhj0+76LVWOqk9eQRqVO+k3x/1Gqo1v4Qr vZ61ExskcbeeWFaXwHLCmaYGMadSAMFCSZZlvNdZhQtR1rgAoffSi4veKN9UtulA0r+ALC39QuZv 8FFuqoptCn4yGn3t90HRtuCD0enpeXYa8FAuN54JGAyHJ4Mh9AIGw2xwCjlAS0CCYWud/y7NwaBY cFRwC2ZAIOW0HjufQu1ChGNtbmulDmUgsZs4xbP7rZLBudJTCVpiCfw3u3jqQGxMIlaP/KYsW5Mq OAmBgsmSakmlTMdDvMCO1v2NSHIEFJBVSPrDsHUAQmX/iS1R3sULoWVV4U0+LHj/PWJS8H3EmLnR Hxe8qbWxfwOg8Cpd5ilebL+uMNrcb25MuQ1w5vhHOx9aI6TF0tiCC29TvynnZ6EMD/WMJNCTh3qJ TpBmQ3ZccLQ/hGkU1Bp1jINalyjlKJJaYNAqzkpZ3dN89lTw82wwCFPF+mQtaaxv7CNGIGcVCL6O V+bkJGcKA1R3alxZYi5iYE1WWsB9KlWlZ60ImFwrJsKnrslC1+za5qXFjaze2u7McP9Ze135d+w6 7XyF7r3fRFrnq9nTXrxFGvuPO2ySaOJpnsYW5WBjmuY4HiSsArSSLidkCcfscdXUjflZJ1KRc8Gl PnqYYTeBv+wssDdPTMffVcE1goTVZetHrBBtZlHi7FHasOiwfzCmCaurM2xFvImKb0jVT/JH/Ayk qzosPphrM7HGVEEO+JQOv2nEpm5IJ86ougxzN/L1em48d84rq9TDOy5WY91xtQpuOjm+PPPbVlYk AOhLo4+U7/YPvVFISgrh3iiE6zr3md04O9vYwrvOxTJ17eVvAAAA//8DAFBLAwQUAAYACAAAACEA 8v97etYAAAD6AAAADwAAAGRycy9kb3ducmV2LnhtbESPTU8CMRCG7yb8h2ZMvElXYoCsFCImfhEu u5J4HbfDbmXbrm2F8u+deNDjm+fNM/MuVtn24kghGu8U3IwLEOQar41rFezeHq/nIGJCp7H3jhSc KcJqObpYYKn9yVV0rFMrWOJiiQq6lIZSyth0ZDGO/UCO2d4Hi4ljaKUOeGK57eWkKKbSonF8ocOB HjpqDvW35TfW+WvrX6v6duef3g1t5vXss1Hq6jLf34FIlNN/eVpJOuQ/+Kt60SyZgNg/nz+C0RXG REEBj+OpjEAufwAAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAA AAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQB1bBef/gIAAB0IAAAQAAAA AAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAPL/e3rWAAAA+gAA AA8AAAAAAAAAAAAAAAAAVQUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAABYBgAAAAAA ABDwCAAAAGcLkAbsB6sMDwAR8EIAAAAPAIgTOgAAAA8AihMyAAAAAAC6Dw4AAABfAF8AXwBQAFAA VAA5AAAAixMUAAAAAACsDwwAAAAAAAAAAAAAAAAAAAAPAA3wUgAAAAAAnw8EAAAABAAAAAAAoQ8Y AAAAAQAAAAAAAAAKAAcAAQAAAAAABAD////+AACqDwoAAAABAAAAAQAAAAAAAACmDwwAAADwAAAA 1AHQAvADEAUPAATwmQgAABIACvAIAAAADBgAAAAKAACjAAvwVgAAAH8AAAAEAIAAQIhmBYcAAQAA AL8AAAAGAL8BAAAQAMABiaSnAMsBOGMAAP8BCAAIAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcA bABlACAAMQAyAAAAIwAi8W8HAAD/AQAAQACpw2MHAABQSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEA ABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJ mVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9 C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kAS aWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJEl Dxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYA CAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5L B7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzc SWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQ j24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxM q/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQD1Fpmp/gIAAB0IAAAQAAAAZHJzL3NoYXBleG1s LnhtbKxV224aMRB9r9R/sPxapVwCuayyiZJKaR9QhCD5gMHrhS1ee2UbCvn6HtsLSWgVVSV5ILOe 8cyZ47lc3WxqxdbSusronPe+djmTWpii0vOcPz3en1xw5jzpgpTRMudb6fjN9edPV03mGobL2mVN zhfeN1mn48RC1uS+mkZq6Epja/L4tPNOY6WT2pNHoFp1+t3uWaemSvNruNLraTO2QRIP67FlVQEs p5xpqhFzIgUQzJVkvT7vtFbhQpQ1LkDovPbiojfKNqWtW5D0LyALS7+Q+QE+ykxZsk2AdN4764Ki bc5PLy+7l+fDgIcyufFMwGA47A+G0AsYDHuDU8gBWgISDBvr/HdpjgbFgqOcWzADAimj9cj5FGoX Ihxrc18pdSwDid3EKZ7db5UMzpWeSNASS+C/2cVTg7d+TCJWj/ymLFuTyjkJgYLpJdWCCpmOh138 tbTub0SSI6CArETSH4atBRAq+09sifI2XggtyxJv8mHBu+8Rk4LvI8bMjf644HWljf0bAIVXaTNP 8WL7tYXRZH5zZ4ptgDPDf7TzsTVCWiyMzbnwNvWbcn4ayvBYz0gCPXmsl+gEadZkRzlH+0OYREGt Ucc4qHSBUo4iqTkGreKskOUjzabPOb/sDQZhqlifrCWN9J1dYt5wVoLg23hlRk5ypjBAdavGlQXm IgbWeKUF3KdSVXraiIDJNWIsfOqaXuiaXdu8triT5aHtzgz3X7S3pX/HrtXOVujex02kdbaaPu/F e6Sx/3jAJokmnmZpbFEGNiZpjuNBwipAK+liTJZwzJaruqrNzyqRipxzLvXJ0xS7Cfz1LgJ7s8R0 /F3lXCNIWF22WmKFaDONEmdLacOiw/7BmCasrtawEfEmKr4mVT3LH/EzkK6qsPhgrs3YGlMGOeBT OvymEZu6IZ04o6oizN3I19u58dI5b6xSD++4WI10y9UquGnl+PLMbxtZkgCgL7U+UT71g6QDhaSk EO5AIVzbuS/sxtnZxBbedS6WqWuufwMAAP//AwBQSwMEFAAGAAgAAAAhAPocG0bWAAAA+gAAAA8A AABkcnMvZG93bnJldi54bWxEj8tOwzAQRfdI/QdrKrGjDg+1VahbARKvqpuESmyHeJqYxnawTev+ PSMWsLw6V2fmLlbZ9uJAIRrvFFxOChDkGq+NaxVs3x4v5iBiQqex944UnCjCajk6W2Cp/dFVdKhT K1jiYokKupSGUsrYdGQxTvxAjtnOB4uJY2ilDnhkue3lVVFMpUXj+EKHAz101Ozrb8tv3OevjX+t 6putf3o3tJ7Xs89GqfNxvrsFkSin//K0krTPf/BX9aJZcg1i93z6CEZXGBMFBTyOpzICufwBAAD/ /wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA9RaZqf4CAAAdCAAAEAAAAAAAAAAAAAAAAAApAgAA ZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQD6HBtG1gAAAPoAAAAPAAAAAAAAAAAAAAAA AFUFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAWAYAAAAAAAAQ8AgAAADSCWADvAQW Cw8AEfBCAAAADwCIEzoAAAAPAIoTMgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAAAA rA8MAAAAAAAAAAAAAAAAAAAADwAN8FIAAAAAAJ8PBAAAAAQAAAAAAKEPGAAAAAEAAAAAAAAACgAH AAEAAAAAAAQA/////gAAqg8KAAAAAQAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8K0G AABCAQrwCAAAAA0YAABACwAAgwAL8FwAAAB/AQAAAQC/AQAAEADAAXAwoADLAThjAAD/ARgAGAAD AwAAAACAwywAAAC/AwAAAgBTAHQAcgBhAGkAZwBoAHQAIABDAG8AbgBuAGUAYwB0AG8AcgAgADEA MwAAACMAIvEhBgAA/wEAAEAAqcMVBgAAUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5e jGviEeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLI Od4rRXaAyVAZIiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5d WpoYR29NZlI1o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+ nbSgTlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAh AJYFM1jUAAAAlwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9 kLNkJHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt8 2B1x9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszp mqv5DztNQVi5L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbv Bnb1zu4GAAD//wMAUEsDBBQABgAIAAAAIQD8kO8htwEAAPoEAAAUAAAAZHJzL2Nvbm5lY3Rvcnht bC54bWy8k19P6yAUwN9v4ncgvGvZ1s67Zp0xS9QHY5br9QNgCxsJPRAgtfv2HmDO7MWYzPjUUA78 fucPy5ux12QQzisDDZ1cMUoEtKZTsG3oy/+7y7+U+MCh49qAaOheeHqzuviztLW3BA+Dr21DdyHY uih8uxM991fGCsA9aVzPAy7dtrBOeAGBBwT1upgyNi96roCu8CoY1iM8242Li/Zp2DiiOtQpKQHe I/Y5OK62u0DWBkC0wTgymdHiEH48zGsfcHHw4t/x6hx/w2RPlDJ8QvE7okXkFMnrCIrKG5f/n8j7 lASvR+n6szWkVvYhCqyWvDZSkmizmJaswjbtGzorF9X8uop+vBZjIC0GXJfTRdxvMWC+YNU81anI SjHQOh/uhTlfL17UUK1AJEE+PPoQS/KJiDh9fjveGjqtSsYSxhutujuldbzcu+3rWjsycI2Zsxm7 ZalbuPMZhkIaUgtzd3B0w16LLPdPYFnTGJ8zLmlMklB8AeKoxNsWhz5PULRAWoySqP9j4ENZvgIf eBEtpMT385vwIzFlbuDn4L0C4/JQnGYfxo+Sy8zL3c9dx6fs7eodAAD//wMAUEsDBBQABgAIAAAA IQAeQtyewgAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRE9NawIxEL0X/A9hhF6KZitFdDWKtBYE T1URj+Nm3CxuJttNuq7+eiMIvc3jfc503tpSNFT7wrGC934CgjhzuuBcwW773RuB8AFZY+mYFFzJ w3zWeZliqt2Ff6jZhFzEEPYpKjAhVKmUPjNk0fddRRy5k6sthgjrXOoaLzHclnKQJENpseDYYLCi T0PZefNnFZS3dqh/9dis9l+3Zr88H98O+Vqp1267mIAI1IZ/8dO90nH+Bzx+iQfI2R0AAP//AwBQ SwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABfcmVs cy8ucmVsc1BLAQItABQABgAIAAAAIQD8kO8htwEAAPoEAAAUAAAAAAAAAAAAAAAAAC4CAABkcnMv Y29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQAeQtyewgAAANsAAAAPAAAAAAAAAAAAAAAA ABcEAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAABgUAAAAAAAAQ8AgAAACaCLwEkAZN Cg8ABPCtBgAAQgEK8AgAAAAOGAAAQAsAAIMAC/BcAAAAfwEAAAEAvwEAABAAwAFwMKAAywE4YwAA /wEYABgAAwMAAAAAgMMsAAAAvwMAAAIAUwB0AHIAYQBpAGcAaAB0ACAAQwBvAG4AbgBlAGMAdABv AHIAIAAxADUAAAAjACLxIQYAAP8BAABAAKnDFQYAAFBLAwQUAAYACAAAACEA/iXrpQABAADqAQAA EwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPhalqqB2NM6R6sHtWY9QEITFtiOxAG 6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3ft0/FnRSUDTozBgQt90By01xe1Nt9 BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJ RpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZ AMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9wXxKV4efar4BAAD//wMAUEsDBBQA BgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOkkD1rAzEMhvdC/4PR3vMlQyklvmyF rCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwONk0LBilwnGhw8H56e3oBo8VT9DMT Oriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l+VJHGWz24ewHtNu2fbbymwHdimkO 0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBxEEW/loJLU8uBve/d/NMbmAhDYfmo jpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEA7prcLrcBAAD5BAAAFAAAAGRycy9jb25u ZWN0b3J4bWwueG1svJPdbtsgFIDvJ+0dEPeriRN7rRWnmiJ1vZimqF0fgNqQIOEDAuQ6b98DuNly M1VK1ctjH/i+88P6dho0GYXzykBLF1eMEgGd6RXsW/r05+7bNSU+cOi5NiBaehSe3m6+flnbxluC h8E3tqWHEGxTFL47iIH7K2MF4D9p3MADhm5fWCe8gMADggZdlIzVxcAV0A1eBeN2gke7czHofo87 R1SPOjUlwAfEPgbH1f4QyNYAiC4YRxYVLeb002He+IDB7MXf49U7/oLFniklOLJVP6FExBRJ68SJ xjuXv5+5+1QDbybphostpFb2Pgps1rwxUhK0WZaLm1WFUzq2tLxeYbiMfrwRUyAdJtzUJSsrSjpM qKtyVZfJPyvFROt8+CnM5XrxopZqBSIJ8vGXD7ElfxERpy+fxguWWq0YSxhvtOrvlNbxcu/2z1vt yMh1S7+zJfvB5mr/SUMhDWmEeTq4ueGoRZZ7ENjWtMWXbEtakyQUH4A4KfGuw53PGxQtkBazJOp/ GHhuy//AMy+ihZT4fD4TfiKmyg18HHxQYFxeivPqw/TWcpl5efp56viUvd28AgAA//8DAFBLAwQU AAYACAAAACEAgdzncsIAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbERPTWvCQBC9F/wPywheim70 EGp0FbEKgqfaIh7H7JgNZmfT7Bqjv75bKPQ2j/c582VnK9FS40vHCsajBARx7nTJhYKvz+3wDYQP yBorx6TgQR6Wi97LHDPt7vxB7SEUIoawz1CBCaHOpPS5IYt+5GriyF1cYzFE2BRSN3iP4baSkyRJ pcWSY4PBmtaG8uvhZhVUzy7V33pqdsf3Z3vcXM+vp2Kv1KDfrWYgAnXhX/zn3uk4P4XfX+IBcvED AAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAx AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA7prcLrcBAAD5BAAAFAAAAAAAAAAAAAAAAAAu AgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAgdzncsIAAADbAAAADwAAAAAA AAAAAAAAAAAXBAAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAAYFAAAAAAAAEPAIAAAA /wbsB0oKmggPAATwpwYAAEIBCvAIAAAADxgAAAALAACDAAvwXAAAAH8BAAABAL8BAAAQAMABcDCg AMsBOGMAAP8BGAAYAAMDAAAAAIDDLAAAAL8DAAACAFMAdAByAGEAaQBnAGgAdAAgAEMAbwBuAG4A ZQBjAHQAbwByACAAMQA3AAAAIwAi8RsGAAD/AQAAQACpww8GAABQSwMEFAAGAAgAAAAhAP4l66UA AQAA6gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D4WpaqgdjTOkerB7VmPUB CExbYjsQBuvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst37dPxZ0UlA06MwYELfdA ctNcXtTbfQQS7EbScsg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6VTZgBsxFXjJkU7fQmc8x i8cdX68kCUaS4mEVLl1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8wdH3wk+TvAPxalJ+ NhNjKJdo2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8SleHn2q+AQAA//8D AFBLAwQUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxzpJA9awMxDIb3Qv+D0d7z JUMpJb5shawhha7G1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZNCwYpcJxocPB+ent6 AaPFU/QzEzq4osK+e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOeJflSRxls9uHsB7Tbtn22 8psB3YppDtGBHOIWzOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJgcRBFv5aCS1PLgb3v3fzT G5gIQ2H5qI6V/Cep9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhAFCBl7WvAQAA8AQAABQAAABk cnMvY29ubmVjdG9yeG1sLnhtbLyTS07DMBBA90jcwfIekrS0hagpQpVgg1DF5wBD4rSWnLFlWyG9 PWO7FLpBSK1YxZ+J3xvPeH47dIr1wjqpseLFZc6ZwFo3EtcVf3u9v7jmzHnABpRGUfGtcPx2cX42 N6UzjH5GV5qKb7w3ZZa5eiM6cJfaCKS9VtsOPE3tOjNWOIEePIE6lY3yfJp1IJEv6CjslwO+mJUN k/qpX1kmG9IhOEJH2BdvQa43ni01oqi9tqyY8WwXvv8ZSoENzXZi8BexxsIHZXvgFOkzTp+BLAIn i157UFBe2bR+IO9iElAOre2OtVjModRty8hhPCpuriZUnC2NJ0UxoTHRKd/Bs5oCbmZxjdUUMBtP p3ncz5JICDTW+Qehj5Zi4aCKK4mCSgcl9I/Oh4v4RoRldXwNPio+mlxRIuE8p5Vs7qVScWLX70tl WQ+Kss3H+d1Xtj/CSEhhLFyqCTWs3yqR5J4FXWts3mN6JDZHFAp9L/ZKUNfU6qlvggXRQlRL+icD 767lN/COF9CibenV/Cd8T4yZazwdvJOobWqKw+z98HXlbeKl6qeq0wN2ZvEJAAD//wMAUEsDBBQA BgAIAAAAIQBMVMf4xAAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Pa8JAEMXvBb/DMoK3ulGk tamriCBIC8U/9T5mp0k0Oxuya5J++86h4G2G9+a93yxWvatUS00oPRuYjBNQxJm3JecGvk/b5zmo EJEtVp7JwC8FWC0HTwtMre/4QO0x5kpCOKRooIixTrUOWUEOw9jXxKL9+MZhlLXJtW2wk3BX6WmS vGiHJUtDgTVtCspux7sz8KHPbdi3cTe7zvdf3dvsNZt8XowZDfv1O6hIfXyY/693VvAFVn6RAfTy DwAA//8DAFBLAQItABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29u dGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAA MQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFCBl7WvAQAA8AQAABQAAAAAAAAAAAAAAAAA LgIAAGRycy9jb25uZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAExUx/jEAAAA2wAAAA8AAAAA AAAAAAAAAAAADwQAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAAAABQAAAAAAABDwCAAA AKQI7AdQCnQKDwAE8LQGAABCAQrwCAAAABAYAADACwAAgwAL8FwAAAB/AQAAAQC/AQAAEADAAXAw oADLAThjAAD/ARgAGAADAwAAAACAwywAAAC/AwAAAgBTAHQAcgBhAGkAZwBoAHQAIABDAG8AbgBu AGUAYwB0AG8AcgAgADEAOQAAACMAIvEoBgAA/wEAAEAAqcMcBgAAUEsDBBQABgAIAAAAIQD+Jeul AAEAAOoBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1 AQhMW2I7EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33 QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnP MYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpS fjYTYyiXaNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP// AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He 8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7 egGjxVP0MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9 tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G97938 0xuYCENh+aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQABgAIAAAAIQD5b77jvwEAAAQFAAAUAAAA ZHJzL2Nvbm5lY3RvcnhtbC54bWy8k1tv2yAUgN8n9T8g3lcTO5fGilNNkbo9TFO0rn1nNiRI+IAA uc6/3wG8tHmpJqXak8E+5vvOhc392GsyCOeVgYbObhklAlrTKTg09OnXw+c7Snzg0HFtQDT0JDy9 39582tjaW4I/g69tQ48h2LoofHsUPfe3xgrAb9K4ngfcukNhnfACAg8I6nVRMrYseq6AbvEoGHYj PNq9i5v2x7B3RHUNLdEGeI/Yx+C4OhwD2RkA0QbjyGxNiyn8/DOvfcDN5MX/xatz/AWTvVBK8DXF x4g1iZgiaZ050Xjv8vsLd59y4PUoXX+1hdTKfosCJK6e42q74bWRkqDXfFVV63JByQkLdTevylkV TXktxkDaKF6y9XKFAS1GLBflfFmmVLJdjLTOh6/CXG8aD2qoViCSIR+++xCr84qIOH19Y14w18Wc sYTxRqvuQWkdD/fu8HunHRm4buiKVewLm7J9E4ZCGlI3c6NwiMNJiyz3U2Bd00BfMzhpYpJQvAvi rMTbFsc/D1O0QFqMkqj/YeCpLO+BJ15ECynxJv1P+JmYMjfwcfBegXF5KC6zD+PfksvMy93PXcdb 7e32DwAAAP//AwBQSwMEFAAGAAgAAAAhAJmTo8TBAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxE T8uKwjAU3Qv+Q7jCbEQTXYhUo6ggMzAg+ICZ5aW5ptXmpjZR69+bxcAsD+c9X7auEg9qQulZw2io QBDn3pRsNZyO28EURIjIBivPpOFFAZaLbmeOmfFP3tPjEK1IIRwy1FDEWGdShrwgh2Hoa+LEnX3j MCbYWGkafKZwV8mxUhPpsOTUUGBNm4Ly6+HuNOxW/e/dRf6ef07rq+p/3uydlNX6o9euZiAitfFf /Of+MhrGaX36kn6AXLwBAAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAA CwAAAAAAAAAAAAAAAAAxAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA+W++478BAAAEBQAA FAAAAAAAAAAAAAAAAAAuAgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAmZOj xMEAAADbAAAADwAAAAAAAAAAAAAAAAAfBAAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAA AA0FAAAAAAAAEPAIAAAA/wamC6AOmggPAATwtAYAAEIBCvAIAAAAERgAAEALAACDAAvwXAAAAH8B AAABAL8BAAAQAMABcDCgAMsBOGMAAP8BGAAYAAMDAAAAAIDDLAAAAL8DAAACAFMAdAByAGEAaQBn AGgAdAAgAEMAbwBuAG4AZQBjAHQAbwByACAAMgAxAAAAIwAi8SgGAAD/AQAAQACpwxwGAABQSwME FAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D 4WpaqgdjTOkerB7VmPUBCExbYjsQBuvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst 37dPxZ0UlA06MwYELfdActNcXtTbfQQS7EbScsg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6 VTZgBsxFXjJkU7fQmc8xi8cdX68kCUaS4mEVLl1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8N y+R8wdH3wk+TvAPxalJ+NhNjKJdo2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2 vcF8SleHn2q+AQAA//8DAFBLAwQUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxz pJA9awMxDIb3Qv+D0d7zJUMpJb5shawhha7G1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5M DjZNCwYpcJxocPB+ent6AaPFU/QzEzq4osK+e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOe JflSRxls9uHsB7Tbtn228psB3YppDtGBHOIWzOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJg cRBFv5aCS1PLgb3v3fzTG5gIQ2H5qI6V/Cep9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhAB3J ntG7AQAA+gQAABQAAABkcnMvY29ubmVjdG9yeG1sLnhtbLyT3W7bIBSA7yftHRD3qx0njl0rTjVF 6nZRTdG6PgCzIUHCBwTIdd6+B/DS5qaalKpXFubA950fNnfToMjIrZMaWrq4ySnh0OlewqGlT3/u v9WUOM+gZ0oDb+mJO3q3/fplYxpnCB4G15iWHr03TZa57sgH5m604YB7QtuBeVzaQ2Ysdxw88wga VFbk+TobmAS6xatg3E3waPY2LLpf494S2be0KCgBNiD20VsmD0dPdhqAd15bUixoNoefD7PGeVzM Xux/vHrLnjHZC6UIv6X4mbAmAZNFrTMnGO9t+n/h7mIOrJmEHa62EEqan0Fgu2GNFoKgzaoqq2qJ TTm1dLm6LddVGfxYwydPuqC7qMt6jYXrMKKq1kVdxwSSU4g01vkfXF/vFy5qqZLAoyEbH5wPNXlF BJy6vh3POArlKs8jxmkl+3upVLjc2cPfnbJkZAqzzZf593zO9k0YCimIPUztwdH1J8WT3G+OdY1j fM24xDmJQuEF8LMS6zoc+jRCwQJpIUqg/oeB57K8B555Ac2FwPfzmfAzMWau4ePggwRt01BcZu+n fyUXiZe6n7qOb9mZ7QsAAAD//wMAUEsDBBQABgAIAAAAIQAwiyvMxQAAANsAAAAPAAAAZHJzL2Rv d25yZXYueG1sRI9Pa8JAFMTvBb/D8gQvohtzkJq6SvEPCD1VRTy+Zl+zwezbmF1j6qfvFoQeh5n5 DTNfdrYSLTW+dKxgMk5AEOdOl1woOB62o1cQPiBrrByTgh/ysFz0XuaYaXfnT2r3oRARwj5DBSaE OpPS54Ys+rGriaP37RqLIcqmkLrBe4TbSqZJMpUWS44LBmtaGcov+5tVUD26qb7qmdmd1o/2tLl8 Dc/Fh1KDfvf+BiJQF/7Dz/ZOK0hT+PsSf4Bc/AIAAP//AwBQSwECLQAUAAYACAAAACEA/iXrpQAB AADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAA IQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAA IQAdyZ7RuwEAAPoEAAAUAAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQIt ABQABgAIAAAAIQAwiyvMxQAAANsAAAAPAAAAAAAAAAAAAAAAABsEAABkcnMvZG93bnJldi54bWxQ SwUGAAAAAAQABAD5AAAADQUAAAAAAAAQ8AgAAACaCLULoA6DCg8ABPC1BgAAQgEK8AgAAAASGAAA wAsAAIMAC/BcAAAAfwEAAAEAvwEAABAAwAFwMKAAywE4YwAA/wEYABgAAwMAAAAAgMMsAAAAvwMA AAIAUwB0AHIAYQBpAGcAaAB0ACAAQwBvAG4AbgBlAGMAdABvAHIAIAAyADMAAAAjACLxKQYAAP8B AABAAKnDHQYAAFBLAwQUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54 bWyUkc1OxCAQx+8mvgPhalqqB2NM6R6sHtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQz JPIBtbwuKykAbXAeey3ft0/FnRSUDTozBgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQ JpP5mHoVjf0wPaibqrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIc G0p2HjQ0+EhXjCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1 ek9w50pc+MIE83/zW7a9wXxKV4efar4BAAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAAL AAAAX3JlbHMvLnJlbHOkkD1rAzEMhvdC/4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1 lF70PC/a7S9pNguKTkwONk0LBilwnGhw8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupg LCW/WqthxOS14YxUk54l+VJHGWz24ewHtNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS5 76dwj2ojf9IRl0rxMmBxEEW/loJLU8uBve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBL AwQUAAYACAAAACEAje1Ubb0BAAAFBQAAFAAAAGRycy9jb25uZWN0b3J4bWwueG1svJNdS8MwFIbv Bf9DyL2267oPyzqRgXohMvy6j22yBdKTkISu+/eepN1QEBEmXjUnPcnznvecLK67RpGWWyc1lHR0 mVLCodK1hE1JX19uL+aUOM+gZkoDL+meO3q9PD9bmMIZgofBFaakW+9NkSSu2vKGuUttOOA/oW3D PIZ2kxjLHQfPPIIalWRpOk0aJoEu8SpoVx08m7UNQfXYri2RdUmznBJgDWKfvWVys/VkpQF45bUl 2ZgmQ/rxMCs41BgNwthvhNWW7bDaL5oifUbx05U0cpKo6wgKktcW+bj/RbyLRbCiE7Y5WYVQ0txj VygJq7ewWi5YoYUgqCuf5eN8gg3b4zrL5yNcoyL0oPOkwoQRmhw2SYUZ0zy7Gs9DQtKrC5nGOn/H 9elKw0UlVRJ4VMjaB+d71AERcOr0xuxwKiZ5mkaM00rWt1KpcLmzm/eVsqRlqqSzdJzeRDuw2k9p GCmIXesbhVPs94r34p44+hon+pTBCcb36sJj4EdJrKpw/kdDBxQgLWAFyv8z8GDLT+CBF9BcCHxK /wk/EmPlGv4O3kjQ9jvbfXewXPS8vvt91/H1OrP8AAAA//8DAFBLAwQUAAYACAAAACEA5qilx8QA AADbAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWsCMRSE7wX/Q3iCF9GkUoqsRtFCsVAQqoIeH5tn dnXzst1E3f57IxQ8DjPzDTOdt64SV2pC6VnD61CBIM69Kdlq2G0/B2MQISIbrDyThj8KMJ91XqaY GX/jH7puohUJwiFDDUWMdSZlyAtyGIa+Jk7e0TcOY5KNlabBW4K7So6UepcOS04LBdb0UVB+3lyc hvWi/70+ycNxv1ueVX/1ay+krNa9bruYgIjUxmf4v/1lNIze4PEl/QA5uwMAAP//AwBQSwECLQAU AAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQCN7VRtvQEAAAUFAAAUAAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVj dG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQDmqKXHxAAAANsAAAAPAAAAAAAAAAAAAAAAAB0EAABk cnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAADgUAAAAAAAAQ8AgAAAB0CqwLoA4JDA8ABPCu BgAAQgEK8AgAAAATGAAAAAsAAIMAC/BcAAAAfwEAAAEAvwEAABAAwAFwMKAAywE4YwAA/wEYABgA AwMAAAAAgMMsAAAAvwMAAAIAUwB0AHIAYQBpAGcAaAB0ACAAQwBvAG4AbgBlAGMAdABvAHIAIAAy ADUAAAAjACLxIgYAAP8BAABAAKnDFgYAAFBLAwQUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPhalqqB2NM6R6sHtWY9QEITFtiOxAG6+7bO93u Xoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3ft0/FnRSUDTozBgQt90By01xe1Nt9BBLsRtJy yDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJRpLiYRUu XVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX /p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9wXxKV4efar4BAAD//wMAUEsDBBQABgAIAAAA IQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOkkD1rAzEMhvdC/4PR3vMlQyklvmyFrCGFrsbW fZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwONk0LBilwnGhw8H56e3oBo8VT9DMTOriiwr57 fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l+VJHGWz24ewHtNu2fbbymwHdimkO0YEc4hbM 6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBxEEW/loJLU8uBve/d/NMbmAhDYfmojpX8J6n2 7wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEAcRnParYBAADxBAAAFAAAAGRycy9jb25uZWN0b3J4 bWwueG1svJPNbusgEIX3V+o7IPatsRsnjRWnqiK1m6qK+vMA1MYJEh4QINd5+zuAm9tsqiul6srC DJzvzBxWt2OvyCCskxpqml8xSgQ0upWwq+nb6/3lDSXOc2i50iBqehCO3q4v/qxM5QzBw+AqU9O9 96bKMtfsRc/dlTYCcK/Ttucel3aXGSucAM89CvUqKxibZz2XQNd4FQybEV7M1oZF8zRsLZFtTYs5 JcB7lH3xlsvd3pONBhCN15YUJc2m8uNhXglocTWB8f8Bay3/QLcnTFE9Lyh+R+xKEMoi2FEpMG9t +n9C76ILXo2d7c/FWK94pbuOBIZlMWMlTudQ01mRL8tFtI+GR08aLFjMimXYb7BgvsjL/DpSJ5Bw kbHOPwh9NhQJF9VUSRA4O17x4dH50Ih/EuG3On8IH5iAcsZYlHFayfZeKhUud3b3vlGWDFyhc3bN 7tjk9ksZAimIg0szwcT6gxIJ7llgW2N6zwlJDEcECsEXRyTeNJj1lJtAgWqhqkP8HxOe2vKd8KQX pEXX4bP5TfGjYnSu4efEewnaplCcuvfjZ8u7pJemn6aOD9iZ9V8AAAD//wMAUEsDBBQABgAIAAAA IQCc6zysxAAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Ba8JAFITvBf/D8oTemo0imqauIoIg CpKm7f01+5qkZt+G7DZJ/31XEHocZuYbZr0dTSN66lxtWcEsikEQF1bXXCp4fzs8JSCcR9bYWCYF v+Rgu5k8rDHVduBX6nNfigBhl6KCyvs2ldIVFRl0kW2Jg/dlO4M+yK6UusMhwE0j53G8lAZrDgsV trSvqLjmP0bBSX70Luv9cfGdZJfhebEqZudPpR6n4+4FhKfR/4fv7aNWMF/C7Uv4AXLzBwAA//8D AFBLAQItABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAHEZz2q2AQAA8QQAABQAAAAAAAAAAAAAAAAALgIAAGRy cy9jb25uZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAJzrPKzEAAAA2wAAAA8AAAAAAAAAAAAA AAAAFgQAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAAAHBQAAAAAAABDwCAAAAGIKvASQ BgkMDwAE8KcGAABCAQrwCAAAABQYAAAACwAAgwAL8FwAAAB/AQAAAQC/AQAAEADAAXAwoADLAThj AAD/ARgAGAADAwAAAACAwywAAAC/AwAAAgBTAHQAcgBhAGkAZwBoAHQAIABDAG8AbgBuAGUAYwB0 AG8AcgAgADIANwAAACMAIvEbBgAA/wEAAEAAqcMPBgAAUEsDBBQABgAIAAAAIQD+JeulAAEAAOoB AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7 EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U 230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+v JAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiX aNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwME FAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+ bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0 MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2K aQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh +aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQABgAIAAAAIQAN9QexswEAAPAEAAAUAAAAZHJzL2Nv bm5lY3RvcnhtbC54bWy8k91KwzAUgO8F3yHkXtt1m7qybshAb0SGPw9wbNMtkJ6EJNTu7T1J5nA3 Imx419Oe5PvOT+fLoVOsF9ZJjRUfXeecCax1I3FT8fe3h6s7zpwHbEBpFBXfCceXi8uLuSmdYXQY XWkqvvXelFnm6q3owF1rI5C+tdp24Cm0m8xY4QR68ATqVFbk+U3WgUS+oKuwXw34atY2BPVzv7ZM NhUvCI7QEfbVW5CbrWcrjShqry0rbnm2Tz8chlJgQ9FeDP4i1lj4pGqPnCKd4LIZqCmBk0WvAygo r216fyTvYhFQDq3tTrVYzKHUbcvIYVyMZpMpDWdX8clsNJnlebCiegfPakqY3RR5MeWspoTp3Sg8 B7skEhKNdf5R6JOlWLio4kqioNFBCf2T8wn1jQiv1ekz+KQFmE6o0HCf00o2D1KpGNjNx0pZ1oOq +G0+zu9jN6jaH2kUKYyDSzOhhfU7JZLci6C2xuU9ZUfickShsPfioAR1Taue9iZYEC1ktaR/NvC+ Lb+B97yAFm1Lf81/wg/EWLnG88E7idqmpTiu3g/fLW8TL00/TZ1+YGcWXwAAAP//AwBQSwMEFAAG AAgAAAAhAII4DUXAAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxET8uKwjAU3Qv+Q7iCO00V8VGN IoIgMzA4PvbX5tpWm5vSxLb+/WQhzPJw3qtNawpRU+VyywpGwwgEcWJ1zqmCy3k/mINwHlljYZkU vMnBZt3trDDWtuFfqk8+FSGEXYwKMu/LWEqXZGTQDW1JHLi7rQz6AKtU6gqbEG4KOY6iqTSYc2jI sKRdRsnz9DIKvuS1dsfaHyaP+fGnWUxmyej7plS/126XIDy1/l/8cR+0gnEYG76EHyDXfwAAAP// AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABf cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAN9QexswEAAPAEAAAUAAAAAAAAAAAAAAAAAC4CAABk cnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQCCOA1FwAAAANsAAAAPAAAAAAAAAAAA AAAAABMEAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAAAAUAAAAAAAAQ8AgAAAAYDOwH SgqGDQ8ABPCtBgAAQgEK8AgAAAAVGAAAgAsAAIMAC/BcAAAAfwEAAAEAvwEAABAAwAFwMKAAywE4 YwAA/wEYABgAAwMAAAAAgMMsAAAAvwMAAAIAUwB0AHIAYQBpAGcAaAB0ACAAQwBvAG4AbgBlAGMA dABvAHIAIAAyADkAAAAjACLxIQYAAP8BAABAAKnDFQYAAFBLAwQUAAYACAAAACEA/iXrpQABAADq AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPhalqqB2NM6R6sHtWY9QEITFti OxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3ft0/FnRSUDTozBgQt90By01xe 1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpVNmAGzEVeMmRTt9CZzzGLxx1f ryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mo l2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9wXxKV4efar4BAAD//wMAUEsD BBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOkkD1rAzEMhvdC/4PR3vMlQykl vmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwONk0LBilwnGhw8H56e3oBo8VT 9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l+VJHGWz24ewHtNu2fbbymwHd imkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBxEEW/loJLU8uBve/d/NMbmAhD YfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEAQFEw97cBAAD8BAAAFAAAAGRycy9j b25uZWN0b3J4bWwueG1svJNNb+MgEEDvlfY/IO6tSeI2rhWnqiJ1L9Uq2u72Tm1IkPCAALnOv+8A brq5rCql6s2Ygffmg9Xd2GsyCOeVgYbOrhglAlrTKdg19O+fh8uKEh84dFwbEA09CE/v1j8uVrb2 luBh8LVt6D4EWxeFb/ei5/7KWAG4J43recCl2xXWCS8g8ICgXhdzxm6Kniuga7wKhs0IT3br4qL9 NWwdUV1DF2gDvEfsU3Bc7faBbAyAaINxZH5Liyn8eJjXAjpcTWL8M2Kd46+Y7YlTos+QrroRqxJB RRI7kqLz1uX/J/Y+ZcHrUbr+bA2plX2OAusVr42UBG3KZbkor9HtgN/V7YxVVfTD1MdA2qiLtZ3F gBYjblhZLZYpgewUI63z4acw5/vFixqqFYhkyIdHH2JNPhARp8/vx2tD59clYwnjjVbdg9I6Xu7d 7mWjHRm4buiSLdg9m7L9JwyFNKQe5vbg8IaDFlnut8C6pkE+Z17SnCSh+AbEUYm3LY59HqFogbQY JVH/y8BTWf4HnngRLaTEF/Sd8CMxZW7g6+C9AuPyUJxmH8b3ksvMy93PXce37O36DQAA//8DAFBL AwQUAAYACAAAACEAKsyG/cIAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbERPy2rCQBTdF/yH4Qrd FJ20BdHoKOIDhK6qElxeM9dMMHMnzYwx9es7i4LLw3nPFp2tREuNLx0reB8mIIhzp0suFBwP28EY hA/IGivHpOCXPCzmvZcZptrd+ZvafShEDGGfogITQp1K6XNDFv3Q1cSRu7jGYoiwKaRu8B7DbSU/ kmQkLZYcGwzWtDKUX/c3q6B6dCP9oydml60fbba5nt9OxZdSr/1uOQURqAtP8b97pxV8xvXxS/wB cv4HAAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtD b250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAA AAAxAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAQFEw97cBAAD8BAAAFAAAAAAAAAAAAAAA AAAuAgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAKsyG/cIAAADbAAAADwAA AAAAAAAAAAAAAAAXBAAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAAYFAAAAAAAAEPAI AAAACQysC6AOhg0PAATwogYAAEIBCvAIAAAAFhgAAIALAACDAAvwXAAAAH8BAAABAL8BAAAQAMAB cDCgAMsBOGMAAP8BGAAYAAMDAAAAAIDDLAAAAL8DAAACAFMAdAByAGEAaQBnAGgAdAAgAEMAbwBu AG4AZQBjAHQAbwByACAAMwAxAAAAIwAi8RYGAAD/AQAAQACpwwoGAABQSwMEFAAGAAgAAAAhAP4l 66UAAQAA6gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D4WpaqgdjTOkerB7V mPUBCExbYjsQBuvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst37dPxZ0UlA06MwYE LfdActNcXtTbfQQS7EbScsg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6VTZgBsxFXjJkU7fQ mc8xi8cdX68kCUaS4mEVLl1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8wdH3wk+TvAPx alJ+NhNjKJdo2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8SleHn2q+AQAA //8DAFBLAwQUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxzpJA9awMxDIb3Qv+D 0d7zJUMpJb5shawhha7G1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZNCwYpcJxocPB+ ent6AaPFU/QzEzq4osK+e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOeJflSRxls9uHsB7Tb tn228psB3YppDtGBHOIWzOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJgcRBFv5aCS1PLgb3v 3fzTG5gIQ2H5qI6V/Cep9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhADAbssioAQAAkgQAABQA AABkcnMvY29ubmVjdG9yeG1sLnhtbLyT0UorMRCG7wXfIeReN3Z7al1MRQp6cxDRo/dxN2kD2UlI wrp9eyfJKqeCICreZchkvn/+mZxfjL0hg/RBW+D05JhRIqG1nYYNpw//ro6WlIQooBPGguR0JwO9 WB0enLsmOIKPITSO022Mrqmq0G5lL8KxdRLwTlnfi4ih31TOyyAhioig3lQzxhZVLzTQFZaCYT3C vbv1KWhvhltPdMdpPaMERI/Y++iF3mwjWVsA2UbrSX1Cqyl9epxDwMd4qN4VDbm4aEbl+0m2+Izs zotn9GJPMVFGu0d0C7WLxipFxqSVsTlD+3aczuuaneIZdYhGjpG0mHB2xhbpvsWEBZsv62W6r4qk lOh8iNfSfl9eKsSp0SCzQDH8DbGgXhEJZ+DbPjxzOvuTmk71gjW6u9LG5MBvntbGk0EYTk9ZzS6z G9jtf2kYGcijKtPBlYo7I4u4O4m25vX6+px0h76XKeXNlG+SRNviMuYNyiqQlrAK5f8YeLIlfYmP wBMvoaVSuNe/CX8j5s4t/By812B9WYr97uP4arkqvDL9MnX8ssGtXgAAAP//AwBQSwMEFAAGAAgA AAAhALVSvRHGAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj09rwkAUxO+FfoflFbyIbrQgNWYj pX9A6Ekt4vGZfWaD2bcxu8bUT98tCD0OM/MbJlv2thYdtb5yrGAyTkAQF05XXCr43n6OXkD4gKyx dkwKfsjDMn98yDDV7spr6jahFBHCPkUFJoQmldIXhiz6sWuIo3d0rcUQZVtK3eI1wm0tp0kykxYr jgsGG3ozVJw2F6ugvvUzfdZzs9q937rdx+kw3JdfSg2e+tcFiEB9+A/f2yut4HkKf1/iD5D5LwAA AP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEB AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAwG7LIqAEAAJIEAAAUAAAAAAAAAAAAAAAAAC4C AABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQC1Ur0RxgAAANsAAAAPAAAAAAAA AAAAAAAAAAgEAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAA+wQAAAAAAAAQ8AgAAACo CuAHUAolDA8ABPDbAAAAogwK8AgAAAAXGAAAAAoAAIMAC/BGAAAAfwAAAO8BgADgjWYFvwACAAYA vwEAABAA/wEAABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdABCAG8AeAAgADMANQAAAAAAEPAI AAAA+QlgA6kE4QoPAA3wZQAAAAAAnw8EAAAAAQAAAAAAqA8BAAAAQQAAoQ8cAAAAAgAAAAAAASgK AAAAAQAAAAcAAgAAAAAAAgASAAAAqg8OAAAAAgAAAAcAAAAAAAkECQQAAKYPDgAAAPgAAAAAANQB 0ALwAxAFDwAE8NsAAACiDArwCAAAABgYAAAACgAAgwAL8EYAAAB/AAAA7wGAAICKZgW/AAIABgC/ AQAAEAD/AQAAGAA/AwAACACAwxYAAAC/AwAAAgBUAGUAeAB0AEIAbwB4ACAAMwA3AAAAAAAQ8AgA AAAmCJAG2QcOCQ8ADfBlAAAAAACfDwQAAAABAAAAAACoDwEAAABCAAChDxwAAAACAAAAAAABKAoA AAABAAAABwACAAAAAAACABIAAACqDw4AAAACAAAABwAAAAAACQQJBAAApg8OAAAA+AAAAAAA1AHQ AvADEAUPAATw2wAAAKIMCvAIAAAAGRgAAAAKAACDAAvwRgAAAH8AAADvAYAAAIxmBb8AAgAGAL8B AAAQAP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAQgBvAHgAIAAzADgAAAAAABDwCAAA AJULlwbgB30MDwAN8GUAAAAAAJ8PBAAAAAEAAAAAAKgPAQAAAEMAAKEPHAAAAAIAAAAAAAEoCgAA AAEAAAAHAAIAAAAAAAIAEgAAAKoPDgAAAAIAAAAHAAAAAAAJBAkEAACmDw4AAAD4AAAAAADUAdAC 8AMQBQ8ABPDbAAAAogwK8AgAAAAaGAAAAAoAAIMAC/BGAAAAfwAAAO8BgADAjGYFvwACAAYAvwEA ABAA/wEAABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdABCAG8AeAAgADMAOQAAAAAAEPAIAAAA iwZKCpMLcwcPAA3wZQAAAAAAnw8EAAAAAQAAAAAAqA8BAAAARAAAoQ8cAAAAAgAAAAAAASgKAAAA AQAAAAcAAgAAAAAAAgASAAAAqg8OAAAAAgAAAAcAAAAAAAkECQQAAKYPDgAAAPgAAAAAANQB0ALw AxAFDwAE8NsAAACiDArwCAAAABsYAAAACgAAgwAL8EYAAAB/AAAA7wGAAECOZgW/AAIABgC/AQAA EAD/AQAAGAA/AwAACACAwxYAAAC/AwAAAgBUAGUAeAB0AEIAbwB4ACAANAAwAAAAAAAQ8AgAAAAA ClkKowvoCg8ADfBlAAAAAACfDwQAAAABAAAAAACoDwEAAABFAAChDxwAAAACAAAAAAABKAoAAAAB AAAABwACAAAAAAACABIAAACqDw4AAAACAAAABwAAAAAACQQJBAAApg8OAAAA+AAAAAAA1AHQAvAD EAUPAATw2wAAAKIMCvAIAAAAHBgAAAAKAACDAAvwRgAAAH8AAADvAYAAYIxmBb8AAgAGAL8BAAAQ AP8BAAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAQgBvAHgAIAA0ADEAAAAAABDwCAAAABIN SgqTC/oNDwAN8GUAAAAAAJ8PBAAAAAEAAAAAAKgPAQAAAEYAAKEPHAAAAAIAAAAAAAEoCgAAAAEA AAAHAAIAAAAAAAIAEgAAAKoPDgAAAAIAAAAHAAAAAAAJBAkEAACmDw4AAAD4AAAAAADUAdAC8AMQ BQ8ABPDbAAAAogwK8AgAAAAdGAAAAAoAAIMAC/BGAAAAfwAAAO8BgACgi2YFvwACAAYAvwEAABAA /wEAABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdABCAG8AeAAgADQAMgAAAAAAEPAIAAAAJgir DvQPDgkPAA3wZQAAAAAAnw8EAAAAAQAAAAAAqA8BAAAARwAAoQ8cAAAAAgAAAAAAASgKAAAAAQAA AAcAAgAAAAAAAgASAAAAqg8OAAAAAgAAAAcAAAAAAAkECQQAAKYPDgAAAPgAAAAAANQB0ALwAxAF DwAE8NsAAACiDArwCAAAAB4YAAAACgAAgwAL8EYAAAB/AAAA7wGAAICNZgW/AAIABgC/AQAAEAD/ AQAAGAA/AwAACACAwxYAAAC/AwAAAgBUAGUAeAB0AEIAbwB4ACAANAAzAAAAAAAQ8AgAAACVC6AO 6Q99DA8ADfBlAAAAAACfDwQAAAABAAAAAACoDwEAAABIAAChDxwAAAACAAAAAAABKAoAAAABAAAA BwACAAAAAAACABIAAACqDw4AAAACAAAABwAAAAAACQQJBAAApg8OAAAA+AAAAAAA1AHQAvADEAWv AAXwQAEAAAEAEvAYAAAAAQAAAAoYAAAAAAAADRgAAAEAAAD/////AQAS8BgAAAACAAAABRgAAAAA AAAOGAAAAQAAAP////8BABLwGAAAAAMAAAAAAAAABhgAAA8YAAD/////AQAAAAEAEvAYAAAABAAA AAgYAAAAAAAAEBgAAAEAAAD/////AQAS8BgAAAAFAAAACBgAAAAAAAARGAAAAQAAAP////8BABLw GAAAAAYAAAAAAAAABhgAABIYAAD/////AwAAAAEAEvAYAAAABwAAAAAAAAALGAAAExgAAP////8B AAAAAQAS8BgAAAAIAAAAAAAAAAcYAAAUGAAA/////wEAAAABABLwGAAAAAkAAAAAAAAACRgAABUY AAD/////AQAAAAEAEvAYAAAACgAAAAAAAAAAAAAAFhgAAP//////////EADwByAAAAD///8AAAAA AICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAA UABUADEAMAAAAIsTEAAAAAAA6y4IAAAAZ3fRAWArwOgAACIECAAAAAEAAAACAAAADwDuAyYNAAAC AO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwA0AA8ADASGDAAADwAC8H4MAABAAQjwCAAAAAQA AAAEHAAADwAD8GYMAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABwA AAUAAAAPAATw+AAAABIACvAIAAAAAhwAACACAAADAQvwcAAAAAQAAAAAAH8AAQDvAYAA4IpmBYEA MGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8BEAARAAEDAgQA AD8DAAAIAIDDEAAAAL8DAAACAFQAaQB0AGwAZQAgADEAAAAAABDwCAAAAK0AIAFgFX0DDwAR8BwA AAAAAMMLCAAAAP////8NAJAAAAAfBAQAAAACAAAADwAN8DQAAAAAAJ8PBAAAAAAAAAAAAKgPCgAA AE5leHQgU3RlcHMAAKoPDgAAAAsAAAAHAAAAAAAJBAkEDwAE8AgKAAASAArwCAAAAAMcAAAgAgAA EwEL8JIAAAAEAAAAAAB/AAEA7wGAACCNZgWBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACH AAAAAACIAAAAAAC/AAAABgC/AQEAAQD/ARAAEQABAwMEAAA/AwAACACAwywAAAC/AwAAAgBDAG8A bgB0AGUAbgB0ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAABMAIvHfBwAAqcPZBwAAUEsD BBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74Lv EOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1 Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTV rdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7a sFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj +ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQ wWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbW TQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlg qWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4 LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAf693L3ID AACpFAAAEAAAAGRycy9zaGFwZXhtbC54bWzsWN2O0zgUvkfad7B8uxraKeVnqkkRU2l2kapRRQdx iU4TZ5qtYwfbKe1c8Sw8Gk/Cd5z0h0pI7CIkYJML5zjn2D7nOz+2c/l8U2qxVs4X1iTy/GFfCmVS mxXmLpGvb6/PnknhA5mMtDUqkVvl5fPxHw8uq5GvBAYbP6oSuQyhGvV6Pl2qkvxDWykDXm5dSQFd d9ernPLKBApYqNS9Qb//pFdSYeQYU5n1vJo5ptKb9cyJIkvkIykMlVhyYk3ASDHTlKql1ZlyYiB7 rXQzkKDN1KYr36pE36JS5ug97PxCG2HsXw4GnfMCvajPTjUDzXjRagn9NokcDi6GF0+eDi4et7KN AAYdzPEwK2oaNlc2244vabTAGyY20P13PeGzACOtu5fivSOo7N/V5JQU+qXxibw4Hw7hzBA7w8dP B+i4Y87imGPqcmI1my3IpJg1kWFHTgJ6GJ3asqIwNfMqZUG2pXI+3G7ekKsEkxikNuHGzpdUqShA 66kPjOSxbOw2MPAk2od52Gr1vZBgGazyvbPESeCfktwUQQgn92E7eq8iCHoNlPChMBliMpFnOwnS d0ggLUWm8ltazO9bFzDsoRmjaGqu3CqOzxHUL+KQBXl2GhLDHNhLMncIzVltUizSj1hqRp7V81U6 S4NYEzusz08MQCB5JHGl8lNZ5NxeFHMcJF7k4VR2NyXkWu6inmh3u4koL+r5/Z68hin7zmRJTqRo Evnpw0fWi0aBFk0U0AjgvIoZwQHB6USjpgHiq7osSvtP0eAMABKpzNnrOQoQwBw8Yz8sGvBjWyfS oCZxfXLFCoXC2HmkpFgpB2dAPuXEaKU4bPHJcFHSxb36O3YZfl1waYu8mbM2j3RWuLCNlC/DRCuK M7LG2nBr7HWhdRPbzRdvdZHxR2bHUqgAWeOnsGkqChjHUirPVRp26NRT0wJZ8zQtHUNDhG2lchTA RP5ZmjMdGmgVnTAUNYzUnzBS3waJa2APY/E2Pu0LtNiTnK8ICbTwDruKLepSK/r1OHH2adilVpda SJavpVaXT91W1W1VJzvSv92qsDsJIbpU+i1SSZlsRo5wGPxpz3282//aR70DyD/sFIdD81fvRuA1 t6I0uP/7vegG5b+7DP3klyG+/3yxv9DokEJdnfphV9IDyLs6hZ9ouz9mIH01/gwAAP//AwBQSwME FAAGAAgAAAAhAPpBx3rYAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0tLw0AUhfeC/2G4gpti J1p8xd4WESQiiOnDhbtr5jYJzTycmSbpv3dwocvDOXyHb74cdSd69qG1BuFymoFgU1nVmhphu3m+ uAMRIhlFnTWMcOQAy8XpyZxyZQez4n4da5EgJuSE0MTocilD1bCmMLWOTep21muKKfpaKk9DgutO XmXZjdTUmvTQkOOnhqv9+qARJttic7jdl8Wb/559vL674bqflIjnZ+PjA4jIY/wfD668/3R/5S/q RSHMQOyK45dv1YpCZI+Q3JJpsgS5+AEAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAA EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h 0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQB/r3cv cgMAAKkUAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAh APpBx3rYAAAA+QAAAA8AAAAAAAAAAAAAAAAAyQUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAE APUAAADOBgAAAAAAABDwCAAAAPADIAFgFRMPDwAR8IIAAAAAAMMLCAAAAP////8TAJAADwCIE14A AAAPAIoTVgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTOAAAAAAArA8wAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfBAQAAAADAAAADwAN8NUA AAAAAJ8PBAAAAAEAAAAAAKgPQwAAAFdlbGNvbWUgcXVlc3Rpb25zLCBjb21tZW50cw1BZGRyZXNz IGNvbW1lbnRzDUFkb3B0IGJ5IFdHDQ1UaGFuayB5b3UAAKEPRgAAADoAAAAAAAAAAAAKAAAAAAAB CAAAAAABADkAAAAAAAIAHAABAAAAAAQCAAAEHAAJAAAAAAgCAAAIHAABAAAAAAwCAAAMHAAAAKoP KAAAADkAAAABAAAAAAABAAAAAQAAAAAACQAAAAEAAAAAAAEAAAABAAAAAAAPAATwHgEAAKIMCvAI AAAABBwAAAAKAADDAAvwcgAAAH8AAQDvAYAAYI9mBb8AAAAGAIEBBAAACL8BAAAQAMABAQAACP8B EAAYAAECAgAACD8CAAADAD8DAAAIAIDDKgAAAL8DAAACAEYAbwBvAHQAZQByACAAUABsAGEAYwBl AGgAbwBsAGQAZQByACAAMwAAAAAAEPAIAAAAXg+wB9AOihAPABHwCQAAAAAAIAQBAAAACQ8ADfBr AAAAAACfDwQAAAABAAAAAACoDwcAAABJRVRGLTk1AAChDxwAAAAIAAAAAAABKAoAAAABAAAABwAI AAAAAAACAA4AAACqDw4AAAAIAAAABwAAAAAACQQJBAAApg8OAAAA+AAAAAAA1AHQAvADEAUQAPAH IAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAA8dtEBgAZvQwAAIgQIAAAAAQAAAAIA AAAPAPADWQQAAAEA8QMIAAAABwEAAAcAeAAPAAwE2QMAAA8AAvDRAwAAIAEI8AgAAAAEAAAABCQA AA8AA/C5AwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAkAAAFAAAA DwAE8AoBAAASAArwCAAAAAIkAAAgAgAAkwEL8MoAAAAEAAAAAAB/AIUB7wGBADBlAQCCAJiyAACD ADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgCAAQAAAACBAf///wCCAQAAAQC/AQAA EADAAQAAAADBAQAAAQDEAQAAAADMAQAACADWAQEAAAD/ARkAGQABAwQgAAAEAwEAAAA/AwAACACA wzQAAAC/AwAAAgBTAGwAaQBkAGUAIABJAG0AYQBnAGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIA IAAxAAAAAAAQ8AgAAACwAdACEA4gCg8AEfAQAAAAAADDCwgAAAAAAAAACwCQAA8ABPBIAQAAEgAK 8AgAAAADJAAAIAIAALMBC/DKAAAABAAAAAAAfwABAO8BgAAA4GoFgQAwZQEAggCYsgAAgwAwZQEA hACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAgAEAAAAAgQH///8AggEAAAEAvwEAABAAwAEA AAAAwQEAAAEAxAEAAAAAywE1JQAAzAEAAAgA1gEBAAAA/wERABkAAQMFIAAABAMBAAAAPwMAAAgA gMMoAAAAvwMAAAIATgBvAHQAZQBzACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAAAAAEPAI AAAAsAqwATAP0BQPABHwEAAAAAAAwwsIAAAAAQAAAAwAkAAPAA3wNgAAAAAAnw8EAAAAAgAAAAAA qg8OAAAAAQAAAAcAAAAAAAkECQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAfAQAAogwK8AgAAAAE JAAAAAoAAJMAC/BsAAAAfwABAO8BgAAA5moFhwACAAAAvwAAAAYAvwEAABAA/wEQABgAPwMAAAgA gMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABl AHIAIAAzAAAAAAAQ8AgAAABfFY8J3xB/Fg8AEfAJAAAAAAAgBAEAAAAIDwAN8HIAAAAAAJ8PBAAA AAIAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAAKAoAAgAAAAcAAgAAAAAAYQAAAAAAAAAAANgP BAAAAAAAAAAAAKoPDgAAAAIAAAAHAAAAAAAJBAkEAACmDwwAAADwAAAA1AHQAvADEAUQAPAHIAAA AP///wAAAAAA7uzhAB9JfQBPgb0AwFBNAAAA/wCAAIAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAA XwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAABPetEBwOZrmwAAchcsAAAAAQCgAAAAAAA3 lgAAuhIAABXfAABR5gAAYP0AAAZjAQChxgEA0FsCAP5oAgAAAPUPHAAAAAAAAAD3GwADAAAAAF9t AgABAAAACgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAQAA AOCFn/L5T2gQq5EIACsns9kwAAAAyOIAAAsAAAABAAAAYAAAAAIAAABoAAAABAAAALQAAAAIAAAA xAAAAAkAAADcAAAAEgAAAOgAAAAKAAAADAEAAAwAAAAYAQAADQAAACQBAAAPAAAAMAEAABEAAAA4 AQAAAgAAAOQEAAAeAAAARAAAAE1QTFMtVFAgQ1YgQWR2ZXJ0aXNlbWVudCBpbiBQVyBWQ0NWIGRy YWZ0LW1pcnNreS1tcGxzLXRwLWN2LWFkdi0wMAAAHgAAAAgAAABlZ3JlbWlyAB4AAAAQAAAAR3Jl Z29yeSBNaXJza3kAAB4AAAAEAAAANTkAAB4AAAAcAAAATWljcm9zb2Z0IE9mZmljZSBQb3dlclBv aW50AEAAAACwHSpdfwgAAEAAAADQBF6qFAPNAUAAAADwd6XL437RAQMAAACCAQAARwAAAIjhAAD/ ////AwAAAAgAiRBnDAAAAQAJAAADvHAAAAAAoXAAAAAABQAAAAsCAAAAAAUAAAAMAtACwAMFAAAA BwEDAAAAoXAAAEELIADMAHgAoAAAAAAA0ALAAwAAAAAoAAAAoAAAAHgAAAABABgAAAAAAADhAAAA AAAAAAAAAAAAAAAAAAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////tdbWADmMtWMA1tb/1v/W1rW1////1v//ADmMtYw5ADmM1ow5//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////jNb/ADmMjGMAADmMjGMAADmMtYw5c2OMADlz1ow5 AGO1/7Vj//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AGO11ow5//////////// ////////////////////////////////////Y7X///////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////jIy1AGOMAAAA/7Vjtf//1oyMtbW1////////AGO1YzkAADljYwAA//+11v// jLW1Y2Nj1oyMtbW1jIzWtbVjjLW1tYyM////AGO1jDkAAGOMjDkA1v/W1rW1AGO1YwAA//+1//// AGO1AAAA/7VjAGO1OQAAADk5YwAAtbVjjLX/ADk5OQAAADk5jDkA1v/WjLW1Y2Nj1oyMtbW1jLW1 ADmMOQAAADk5jDkA///W//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////jIy1AGOMAAAA/7Vjtf//1oyMAGO1 UgAAMTljtXNKjIzWtbVjjIzW//+1////jIzWtbW1//+1AGO1YwAAOWNjjIw5tYyM////////Y4y1 1rWMtbX/jLW1tbVjjGOMjIyM///W////AGO1YwAA1v+1tYyMjLX/ADk5YwAAAGNjOQAAADk5OQAA ADk5tWMA////jIzWtbW1//+1tbW1AGO1AAAAOQAAADk5tWMA//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////jIy1AGOMOQAA/9aMAGO1OQAAADk5OQAA/9aMAGO1jDkAOYy1YwAA//+1////tf//tWNj//// ////////////Y7X/tYyM////AGO1jDkAAGOMjDkAtf/W1oyMOYzWjDkA///W////AGO1OQAA/9aM ////////////////////////////////////////////tf//tWNj////Y7X///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////AGO1 1ow5AGO11ow5//////////////////////////////////////////////////////////////// ////////////////paUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwA nJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwA nJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUA nJwAnJwAnJwAnJwA//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////OYzWAAAAjDkA tbWMAGO1OQAAADk5YzkAADljYwAAtbVjjIzWtbVjY4zWADk5YwAA//+1////tbW1////jLW1ADmM OQAAADk5YzkAADljYzkAADljOQAAjIw5ADmMYwAA//+17///3s6Mzs7W3t5jnL21rZwAnK05va0A nK1jvZwA3t5jzs7W3t5jvc7WnK05vZwAzs5j3t6Mzt61nK2MrZwAnK05va0AnK1jva0AnK1jrZwA zs45nK2MvZwAzu+M7961zs6M7961vc61nK1jrZwAzs45nK2MrZwAnK05va0AnK1jvZwA3t5j3t7W 3t7W3t5jvc61nK1jrZwA3s45zt61nK2MvZwAzs5j3t6Mzs61///W//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////1v//tYyM////////jLW1tYyMjLX/ADk5jGMAADmMYwAAAGNjYwAAAGNjOQAA ADk5YwAA//+1////AGO1YwAAjLVjADmMOQAAADk5OQAAADk5OQAAADk5OQAAjIw5ADmMYwAA//+1 7///nK2MvZwAzt5j3s6Mzt7/nK05zr0AnK2MvZwAnL1jvZwAnL1jrZwAnK05vZwA7/+13s6Mzt61 nK2MrZwAnK05rZwAnK05rZwAnK05rZwAzs45nK2MvZwAvc5j796M3t7Wvc6Mvb1jnK1jrZwAzs45 nK2MrZwAnK05rZwAnK05vZwAnL1jnJwAvZwAzt5jvb2MnK1jrZwA3s45zt61nK2MvZwA//+1zt61 zr2M///W//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////Y7X/AAAAtWMAY7X///////// ////////////////////////////////////////////////AGO1OQAAY4yM//////////////// ////////////1v//tYyM////////////////////////vd7///////////////////////////// ////////////////////////rb21vc6M////////////////////////////7///3s6M//////// zu//nJw5nJwA/95j3t61////7///3s6M////////////////////////////////////vd7/3t61 ////7///3s6Mvd7/////////////vd7/3t61//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////nJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwA nJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwAnJwAnJwApaUAnJwA nJwAnJwApaUAnJwAnJwAnJwA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////tbW1Y2O1jLW1ADk5OQAAADk5jDkAtbWMtbX///+1////OYzW AAAA1ow5tbW1jLX/ADk5YwAAtbVjtbX///+1////3t613t7Wzt7WnK05rZwAnK05zq0A3t6M3t7/ vc5jnK1jzq0A3t6Mzt7/nK05vZwA3t5j3t7/zu+M7961zs6M79613t613t7/nL1jrZwAnK05vZwA vc6Mvc6M795jnK2MvZwA3t5jvc61nK1jva0AnK1jvZwA3t5j3t7W3t7W//+1//////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////Y7W1tbW1jGO1ADk5 OQAAADk5YwAAAGNjYwAA//+11v//tYyM////////AGO1OQAAADk5YwAAAGNjYwAA//+1////nL21 nJwArZwAnK05rZwAnK05vZwAnL1jvZwA7/+1nK2MvZwAnL1jrZwAnK05vZwAnL1jvZwAvc5j796M 3t7Wzs6MnL2MrZwA3s45zt7/nK05rZwA3t5jzr2Mzt6MnK2MvZwA3t5j7///nK2MrZwAnK05vZwA nL1jnJwAvZwA//+1//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////Y2O1//+1Y2O1//+1////////////tbW1////////////OYzWAAAA1ow5tbW1 ////////////////////////////////////////////////////////3t61//////////////// 3t61////////////////////zu//nJw5nJwA/95j3t61//////////////////////////////// ////////vd7///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// AGO1jDkA///W////nJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwA nJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwA nJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwA//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////jNb/tWM51v//ADmMYwAAjLVjADmMYwAA//+11v// ADmMOQAAtYw5jLX/ADk5YwAAtbVjjLX/tYw5jIzW//+1////vd7/795jnK2MvZwAzt5jnK2MvZwA vc5jnK1jzq0A3t6Mzt7/nK05vZwA3t5jzt7/3s45zs7Wzu+M7961zs6M79613t613t7/nL1jrZwA nK05vZwAvc6Mvc6M795jnK2MvZwA3t5jvc61nK1jva0AnK1jvZwA3t5j3t7W3t7W//+1//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////tbXWjLXW 1taMADmMYwAAAGNjAAAAYwAA//+1////tf//1oyMAGO1OQAAADk5YwAAAGNjOQAAADk5YwAA//+1 7///3s6Mvc61nK1jvZwAnL1jnJwAvZwA//+1nL213r0AnL21rZwAnK05vZwAnL1jrZwAnK05vZwA vc5j796M3t7Wzs6MnL2MrZwA3s45zt7/nK05rZwA3t5jzr2Mzt6MnK2MvZwA3t5j7///nK2MrZwA nK05vZwAnL1jnJwAvZwA//+1//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////1v//1rW11v//1rW1////////////////////////////AGO1AAAAtWMA //////////////////////////////////////////////////////////////////////////// 3t61////////////////////////////zu//nJw5nJwA/95j3t61//////////////////////// ////////////////vd7///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////AGO1jDkA ///W////////////////////////////////////1v//YzmM//+1////////nJwAnJwAnJwAnJwA nJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwA nJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwA nJwAnJwAnJwAnJwAnJwAnJwAnJwAnJwA//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// OYzWAAAAjDkAjLWMADmMOQAAtYw5jIzW//+1////tbW1Y2O1tbW1tbVjjLW1ADmMjDkAY4yMjGNj Y7XW/7Vj////7///3s6Mzs7Wzt5jnK2MrZwA3s45vc7WnK05vZwA3t5jvd7//95jzs613t6M3t7W 3t7W3t5jzt61nK2Mzq0Avc6Mzr1jvd7W/95jzu/W7961zs6M3t61nK2MvZwA3t5jzt61nK2Mva0A nK1jva0AnK1jva0AnK1jvZwA3t5j3t7/vc5jnK1jva0AnK1jvZwA3t5j3t7W3t7W//+1//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////1v//tYyM////////AGO1AAAAOQAAADk5YwAA//+1////Y7W1 tbW1tWO1tbVjAGO1AAAAtWMAOYy1jGM5tYyMjIy1///W7///nK2MvZwAnL1jnJwArZwAnK05rZwA nK05vZwAnL1j3r0Azs61///WnL21nJwAvZwA3t5jnL21nJwA3r0Arc61zr053s6Mzs61vc6M796M 3t7Wvc6MnK1jvZwArb1jzs45nK2MrZwAnK05zr0AnK2Mzr0AnK2MvZwAnL1jvZwA7/+1nK2MrZwA nK05vZwAnL1jnJwAvZwA//+1//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////Y7X/AAAAtWMA ////////////////////////////Y2O1//+1Y2O1Y7W1////////////tbW1//////////////// ////////////////////////////////////////////////////////////////////vd7///// ////////3t61////////////zu//nJw5nJwA/95j////////////vd7///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////OYzW/7Vj//////////////// ////////////////////////////////////////OYy1jDk5///W//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////AGO1AAAA1ow5jIy1 1v/WADmMAAAA1ow5tbXWOWOM/9aM////jIy1jNbW/7WMjIy1jIyMjIyM1v/WADmMAAAA/7VjjIy1 Y7XW/7VjjNb/tWM5////////////AGO1AAAA/7VjjIy1AGOMAAAA1ow5jIy1///W////////Y2O1 jNa1/7WMjIy1jNbW/7WMjIy1jIyMjNbW/7WMjIy1jIyMjNbW/7WMjIy1///W////OYzWAAAA/7Vj ////tbXW///W//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////1v//tYyMjNb/1oxjY2O1//+1jLW1ADmM1ow5tbXWc4yMADlz1ow5Y2O1jNa11oxj jIy1jIyMY2OM//+1AGO1tWM5///WAGO1tWMA////jIzWtbW11v+1ADmM1ow5jIy1tf/W1oyMY4y1 ADljAAAA1ow5Y2O11v+1ADmM1ow5Y2O1tf+11oyMY2O1jNa11oxjjIy1Y2OMjNa11oxjjIy1Y2OM jNa11oxjc4y1ADlztYw5tYyM1v//1rW1////tbXW///W//////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////Y7X/OTkA1oxjY7W1tWNjY7X/OQAA tdaMAABjAAAA/7Vj////Y7W1YwBjOYyM1ow5jIy1Y7WMtWNjOYzWjDkA///WjIy1Y7XW1rVj1rW1 tf//1oyM////////OYy1YwA5//+1jIy1jNbWYwA5//+1Y7W1tWNj////////Y7W1YwBj//+1Y7W1 YwBjOYyM1ow5Y7W1YwBjOYyM1ow5Y7W1YwBjOYyM1ow5////////jIy1jNbW1oxjOYzWjDkA///W //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////tf//1oyM////////////////////Y7X/1ow5////////////////////////jIy1///W ////////////////jIy1///W////////////////////////jIy1///W////jIy1///W//////// //////////////////////////////////////////////////////////////////////////// ////////jNb/jDk5///W////tbXW///W//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////tf//AABjAAAAjDkA///W//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////OYzW/7Vj////AGO1/7Vj//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////1v//ADmMtWMA Y7X/1ow5////OYzW/7Vjtf//AABjAAAAAAAA1ow5////////Y7X/1ow5////Y7X/1ow5////OYzW /7VjY7X/AAAAAAAAY2Nj1ow5Y7X/1ow5////Y7X/1ow5////OYzWtWMAY7X/1ow5Y7X/1ow5//// OYzW/7Vjtf//AABjAAAAOTk5/7Vj////////Y7X/1ow5////Y7X/1ow5////OYzW/7Vjtf//AABj AAAAAAAA1ow51v//ADmMtWMAY7X/1ow5////OYzW/7Vj1v//ADmMAAAAjDkA///Wtf//AABjAAAA OTk5/7Vj////////Y7X/1ow5Y7X/1ow5////OYzW/7Vj////////Y7X/AAAAAAAAAAAAjDkA///W tf//jDlj///WY7X/AAAAAAAAAAAAAAAA1ow5jNb/tWM5////////////AGO11ow5//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////tf//jDlj///WY7X/1ow5////OYzW/7VjOYzW/7Vj//////////////// ////Y7X/1ow5////Y7X/1ow5////OYzW/7VjOWO1/9aM////AGO1/7VjY7X/1ow5////Y7X/1ow5 tf//jDlj///WY7X/1ow5Y7X/1ow5////OYzW/7VjOYzW/7Vj////AGO1/7Vj////////Y7X/1ow5 ////Y7X/1ow5////OYzW/7VjOYzW/7Vj////////////tf//jDlj///WY7X/1ow5////OYzW/7Vj OYzW1ow5////OYzW1ow5OYzW/7Vj////AGO1/7Vj////////Y7X/1ow5Y7X/1ow5////OYzW/7Vj ////////Y7X/1ow5////////OYzW/7Vjtf//jDlj///WY7X/1ow5////////////////jNb/tWM5 ////////Y7X/tWMA//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////tf//jDlj///WY7X/1ow5//// OYzW/7VjAGO1AAAAAAAAAAAAtWMA////////Y7X/1ow5////Y7X/1ow5////OYzW/7Vj1v//ADmM AAAAAAAA/7VjY7X/1ow5////Y7X/AAAAOQAA/9aM////Y7X/1ow5Y7X/1ow5////OYzW/7VjOWO1 /9aM////OYzW/7Vj////////Y7X/1ow5////Y7X/1ow5////OYzW/7VjAGO1AAAAAAAAAAAAtWMA tf//jDlj///WY7X/1ow5////OYzW/7VjOWO1/9aM////jNb/tWM5OWO1/9aM////OYzW/7Vj//// ////Y7X/1ow5Y7X/1ow5////OYzW/7Vj////////Y7X/1ow5////////OYzW1ow5tf//jDlj///W Y7X/1ow5////////////////jNb/tWM5////jNb/jDk5///W//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////tf//jDlj///WY7X/jDkA///WOYzW/7VjOYzW/7Vj////Y7X/1ow5////////Y7X/jDkA ///WOYzWtWMA////OYzW/7Vj1tb////W////OYzW/7VjY7X/tWMA////Y7X/jIw5OQBj/9aM//// Y7X/1ow5Y7X/tWMA////OYzW/7VjOYzW/7Vj1v//ADmM/7Vj////////Y7X/jDkA///WOYzWtWMA ////OYzW/7VjOYzW/7Vj////Y7X/1ow5tf//jDlj///WY7X/jDkA///WOYzW/7VjOYzW1ow5//// OYzW1ow5OYzW/7Vj////AGO1/7Vj////////Y7X/1ow5Y7X/tWMA////OYzW/7Vj////////Y7X/ AAAAAAAAAAAAYwAA//+1tf//jDlj///WY7X/AAAAAAAAAAAAYwAA//+1jNb/AAA5AAAAAAAAAAAA 1ow5//////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////OYzWAAAAtWMAY7X/Y2M5AAA5YwAA//+1tf// AABjAAAAjDkA///W////////Y7X/Y2M5AAA5YwAAY7W1AAAAYwAA//+1jNb/AAA5AAAAOQAA/9aM Y7X/OTk5YwAAY7W11ow51v//ADmM1ow5Y7X/1ow5Y7X/AAAAAAAAYwAA//+1tf//AABjOQAAOWNj /7Vj////////Y7X/Y2M5AAA5YwAAY7W1AAAAYwAA//+1tf//AABjAAAAjDkA///WOYzWAAAAtWMA Y7X/Y2M5AAA5YwAA//+11v//ADmMAAAAjDkA///Wtf//AABjAAAAOTk5/7Vj////////Y7X/1ow5 Y7X/AAAAAAAAYwAA//+1////////Y7X/1ow5////////Y2O1//+1tf//jDlj///WY7X/1ow5//// ////////////jNb/tWM5////////1v//OTmM/9aM//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////tf// jDlj///WY7X/1ow5//////////////////////////////////////////////////////////// ////////////////////////////////////////////Y7X/1ow5//////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////tf//jDlj///WY7X/1ow5//////////////////////////////////// ////////OYzW/7Vj////////////////////////////////////////////Y7X/1ow5//////// OWO1/9aMtf//jDlj///WY7X/1ow5////////////////jNb/tWM5////////1v//OTmM/9aM//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////1tb////WY7X/1ow5//////////////////////////// //////////////////////////////////////////////////////////////////////////// Y7X/1ow5////////////Y7X/1ow5//////////////////////////////////////////////// ////////////////////////////////////////////////////////1tb////WY7X/1ow5//// ////////////////////////////////////////OYzW/7Vj////////Y7X/1ow5//////////// ////////////////Y7X/AAAAAAAAAAAAjDkA///Wtf//jDlj///WY7X/AAAAAAAAAAAAAAAA/7Vj jNb/AAA5AAAAAAAAAAAA1ow5//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////Y7X/1ow5//////////////// tf//AABjAAAAAAAA1ow5Y7X/1ow5////////OYzW/7Vj////1v//ADmMAAAAjDkA///WY7X/1ow5 ////Y7X/1ow5////Y7X/1ow5////OYzW/7VjY7X/AAAAAAAAY2Nj1ow5Y7X/1ow5////OYzW/7Vj ////AGO1AAAAOQAA/9aMtf//AABjAAAAAAAA1ow5////////Y7X/1ow5////Y7X/1ow5////OYzW /7Vjtf//AABjAAAAAAAA1ow5Y7X/AAAAAAAAY2Nj1ow5OYzWAAAAAAAAYwAAtf+1AABjAAAAOTk5 /7VjY7X/1ow5////tf//AABjAAAAAAAA1ow5Y7X/1ow5////Y7X/1ow5////OYzWtbVjAABjAAAA AAAA1ow5Y7X/1ow5////OYzW/7Vj1v//ADmMtWMA////////////AGO1/7VjY7X/jDkA///WY7X/ 1ow51v//ADmMtWMAY7X/1ow5////OYzW/7Vj//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////Y7X/1ow5////////////////OYzW/7Vj////////////Y7X/1ow5////////OYzW/7Vj ////OYzW1ow5////OYzW1ow5Y7X/1ow5////Y7X/1ow5////Y7X/1ow5////OYzW/7VjOWO1/9aM ////AGO1/7VjY7X/1ow5////OYzW/7VjY7X/1ow5////jNb/jDk5OYy1/7Vj//////////////// ////Y7X/1ow5////Y7X/1ow5////OYzW/7VjOYzW/7Vj////////////OWO1/9aM////AGO1/7Vj ////////////Y7X/OTk51ow5////AGO1/7VjY7X/1ow5////OYzW/7Vj////////////Y7X/1ow5 ////Y7X/1ow5////OYzWOTk5/7Vj////////////Y7X/1ow5////OYzW/7Vjtf//jDlj///W//// ////tf//OTlj1oxjY4zWYzk5//+1Y7X/1ow5tf//jDlj///WY7X/1ow5////OYzW/7Vj//////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////Y7X/1ow5////////////////AGO1AAAAAAAA AAAAtWMAY7X/1ow5////////OYzW/7Vj////OWO1/9aM////jNb/tWM5Y7X/1ow5////Y7X/1ow5 ////Y7X/1ow5////OYzW/7Vj1v//ADmMAAAAAAAA/7VjY7X/1ow5////OYzW/7VjOYzW/7Vj//// ////////AGO1AAAAAAAAAAAAtWMA////////Y7X/1ow5////Y7X/1ow5////OYzW/7VjAGO1AAAA AAAAAAAAtWMA1v//ADmMAAAAAAAA/7Vjtf//AABjAAAAOQAAY4yM1ow5////OYzW/7VjY7X/1ow5 ////AGO1AAAAAAAAAAAAtWMAY7X/1ow5////Y7X/1ow5////OYzWAAAAAAAAAAAAAAAAtWMAY7X/ 1ow5////OYzW/7Vjtf//jDlj///W////////Y7X/tYw5tYyMY2O1Y7W1/7VjY7X/1ow5tf//jDlj ///WY7X/1ow5////OYzW/7Vj//////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////Y7X/ AAAAAAAAAAAAYwAA//+1OYzW/7Vj////Y7X/1ow5Y7X/tWMA////////OYzW/7Vj////OYzW1ow5 ////OYzW1ow5Y7X/tWMA////Y7X/jDkA///WOYzWtWMA////OYzW/7Vj1tb////W////OYzW/7Vj Y7X/tWMA////OYzW/7VjY7X/1ow5////Y7X/tWMAOYzW/7Vj////Y7X/1ow5////////Y7X/jDkA ///WOYzWtWMA////OYzW/7VjOYzW/7Vj////Y7X/1ow51tb////W////OYzW/7VjOYzW/7Vj//// 1v//Y4zW1ow5////OYzW/7VjY7X/tWMA////OYzW/7Vj////Y7X/1ow5Y7X/jDkA///WOYzWtWMA ////OYzWOTk5/7Vj////Y7X/1ow5Y7X/tWMA////OYzW/7Vjtf//jDlj///W////////Y4zW/9aM Y4y1jGNjjNbW1oxjY7X/1ow5tf//jDlj///WY7X/jDkA///WOYzW/7Vj//////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////Y7X/1ow5////////Y7X/1ow5tf//AABjAAAAjDkA///WY7X/ OTk5YwAAjNa1AAA5OQAA/9aM1v//ADmMAAAAjDkA///WY7X/OTk5YwAAY7W1Y2M5AAA5YwAAY7W1 AAAAYwAA//+1jNb/AAA5AAAAOQAA/9aMY7X/AAAAAAAAYwAA//+11v//ADmMAAAAYwAA//+1tf// AABjAAAAjDkA///W////////Y7X/Y2M5AAA5YwAAY7W1AAAAYwAA//+1tf//AABjAAAAjDkA///W jNb/AAA5AAAAOQAA/9aMtf//AABjAAAAYwAAY7W11ow5////OYzW/7VjY7X/OTk5YwAAtf+1AABj AAAAjDkA///WY7X/Y2M5AAA5YwAAY7W1AAAAYwAAtf+1AABjAAAAjDkA///WY7X/AAAAAAAAYwAA //+1OYzWAAAAtWMA////1v//YzmM//+1OYzW1ow5tf//jDljY7XW1ow5OYzWAAAAtWMAY7X/Y2M5 AAA5YwAA//+1//////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////Y7X/1ow5//////// Y7X/1ow5////////////////////////////////////OYzW/7Vj//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////tf//jDlj///W//////////////////////////// ////////////tf//jDlj///WY7X/1ow5//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////Y7X/AAAAAAAAAAAAYwAA//+1//////////////////////////////////// jNb/AAA51ow5//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////1tb/ ///W////////////////////////////////Y7X/1ow5////1tb////WY7X/1ow5//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////AwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAgAA AALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rrQCAABwAgAAEAAAAAEAAACIAAAA AwAAAJAAAAAPAAAAsAAAAAQAAADEAAAABgAAAMwAAAAHAAAA1AAAAAgAAADcAAAACQAAAOQAAAAK AAAA7AAAABcAAAD0AAAACwAAAPwAAAAQAAAABAEAABMAAAAMAQAAFgAAABQBAAANAAAAHAEAAAwA AAAXAgAAAgAAAOn9AAAeAAAAGAAAAE9uLXNjcmVlbiBTaG93ICg0OjMpAAAAAB4AAAAMAAAARXJp Y3Nzb24AAAAAAwAAALdtAgADAAAASQAAAAMAAAAGAAAAAwAAAAEAAAADAAAAAAAAAAMAAAAAAAAA AwAAAAAADgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAKAAAABgAAAEFyaWFs AAgAAABDYWxpYnJpAAcAAADlrovkvZMADwAAAERlZmF1bHQgRGVzaWduAFIAAABQZXJmb3JtYW5j ZSBtZWFzdXJlbWVudCB3aXRoIHRoZSBtYXJraW5nIG1ldGhvZCBpbiBCSUVSIGRyYWZ0LW1pcnNr eS1iaWVyLXBtbW0tMDEADQAAAFdoYXQgYW5kIHdoeQATAAAAU2luZ2xlIE1hcmsgTWV0aG9kABMA AABEb3VibGUgTWFyayBNZXRob2QAFwAAAFNhbXBsZSBCSUVSIHN1Yi1kb21haW4ACwAAAE5leHQg U3RlcHMADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAMAAAAeAAAABgAAAFRoZW1lAAMA AAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAAAYAAAAAAAA4BAAABAAAAAAAAAAoAAAAAQAA AFYAAAACAAAAXgAAAAMAAAAqBAAAAgAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAwAAAA4AAABVcGRh dGVQcm9jZXNzAAIAAADp/QAAQQAAAMQDAAAwAAAAAwAAAAcAAAADAAAABgAAAAMAAAAAAAAAAwAA AAcAAAAfAAAAIwAAAG0AYQBpAGwAdABvADoAZwByAGUAZwBvAHIAeQAuAG0AaQByAHMAawB5AEAA ZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AAAAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAAD AAAAAAAAAAMAAAAHAAAAHwAAAB0AAABtAGEAaQBsAHQAbwA6AHYAZQByAG8ALgB6AGgAZQBuAGcA QABoAHUAYQB3AGUAaQAuAGMAbwBtAAAAAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAA AAAAAAADAAAABwAAAB8AAAAcAAAAbQBhAGkAbAB0AG8AOgBtAGEAYwBoAC4AYwBoAGUAbgBAAGgA dQBhAHcAZQBpAC4AYwBvAG0AAAAfAAAAAQAAAAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAAD AAAABwAAAB8AAAAqAAAAbQBhAGkAbAB0AG8AOgBnAGkAdQBzAGUAcABwAGUALgBmAGkAbwBjAGMA bwBsAGEAQAB0AGUAbABlAGMAbwBtAGkAdABhAGwAaQBhAC4AaQB0AAAAHwAAAAEAAAAAAAAAAwAA AAcAAAADAAAABgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAAIwAAAG0AYQBpAGwAdABvADoAZwByAGUA ZwBvAHIAeQAuAG0AaQByAHMAawB5AEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AAAAAAB8AAAAB AAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAAB0AAABtAGEAaQBsAHQA bwA6AHYAZQByAG8ALgB6AGgAZQBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAAAAAAAfAAAAAQAA AAAAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAAAcAAAAbQBhAGkAbAB0AG8A OgBtAGEAYwBoAC4AYwBoAGUAbgBAAGgAdQBhAHcAZQBpAC4AYwBvAG0AAAAfAAAAAQAAAAAAAAAD AAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAAAqAAAAbQBhAGkAbAB0AG8AOgBnAGkA dQBzAGUAcABwAGUALgBmAGkAbwBjAGMAbwBsAGEAQAB0AGUAbABlAGMAbwBtAGkAdABhAGwAaQBh AC4AaQB0AAAAHwAAAAEAAAAAAAAAHgAAAAQAAABFbmQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9g8mAAAAFAAAAF/AkeOTbQIADgD0AwMANABHcmVnb3J5 IE1pcnNreQgAAABHAHIAZQBnAG8AcgB5ACAATQBpAHIAcwBrAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAA AAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAo AAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYA AAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAA AEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAA UwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABh AAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8A AABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAA AH4AAAB/AAAAgAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAA jAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACa AAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgA AACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAAtgAA ALcAAAC4AAAAuQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAA xQAAAMYAAADHAAAAyAAAAMkAAADKAAAAywAAAMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADT AAAA1AAAANUAAADWAAAA1wAAANgAAADZAAAA2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEA AADiAAAA4wAAAOQAAADlAAAA5gAAAOcAAADoAAAA6QAAAOoAAADrAAAA7AAAAO0AAADuAAAA7wAA APAAAADxAAAA8gAAAPMAAAD0AAAA9QAAAPYAAAD3AAAA+AAAAPkAAAD6AAAA+wAAAPwAAAD9AAAA /gAAAP8AAAAAAQAAAQEAAAIBAAADAQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAM AQAADQEAAA4BAAAPAQAAEAEAABEBAAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoB AAAbAQAAHAEAAB0BAAAeAQAAHwEAACABAAAhAQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAAKAEA ACkBAAAqAQAAKwEAACwBAAAtAQAALgEAAC8BAAAwAQAAMQEAADIBAAAzAQAANAEAADUBAAA2AQAA /v///zgBAAA5AQAAOgEAADsBAAA8AQAAPQEAAD4BAAA/AQAAQAEAAEEBAABCAQAAQwEAAEQBAABF AQAARgEAAEcBAABIAQAASQEAAEoBAABLAQAATAEAAE0BAABOAQAATwEAAFABAABRAQAAUgEAAFMB AABUAQAAVQEAAFYBAABXAQAAWAEAAFkBAABaAQAAWwEAAFwBAABdAQAAXgEAAF8BAABgAQAAYQEA AGIBAABjAQAAZAEAAGUBAABmAQAAZwEAAGgBAABpAQAAagEAAGsBAABsAQAAbQEAAG4BAABvAQAA cAEAAHEBAAByAQAAcwEAAHQBAAB1AQAAdgEAAHcBAAB4AQAAeQEAAHoBAAB7AQAAfAEAAH0BAAB+ AQAAfwEAAIABAACBAQAAggEAAIMBAACEAQAAhQEAAIYBAACHAQAAiAEAAIkBAACKAQAAiwEAAIwB AACNAQAAjgEAAI8BAACQAQAAkQEAAJIBAACTAQAAlAEAAJUBAACWAQAAlwEAAJgBAACZAQAAmgEA AJsBAACcAQAAnQEAAJ4BAACfAQAAoAEAAKEBAACiAQAAowEAAKQBAAClAQAApgEAAKcBAACoAQAA /v///6oBAACrAQAArAEAAK0BAACuAQAArwEAALABAAD+////sgEAALMBAAC0AQAAtQEAALYBAAC3 AQAAuAEAAP7////9/////f////3////9////vgEAAP7///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAA AAAAAAAAAAAAAAAA/v///wAAAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACxAQAAABAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBu AGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEAAAD///// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADcBAAD44gAAAAAAAFAAbwB3 AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ALdtAgAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACpAQAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA= --_004_7347100B5761DC41A166AC17F22DF11221ADA9FCeusaamb103erics_-- From nobody Thu Jul 21 00:58: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 C871512DAD9; Thu, 21 Jul 2016 00:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 n_-hzKKVdLRs; Thu, 21 Jul 2016 00:58:05 -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 46D3612DA81; Thu, 21 Jul 2016 00:58:05 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 03:58:03 -0400 From: Dave Dolson To: Gregory Mirsky , "sfc@ietf.org" Thread-Topic: [sfc] Identifying OAM in NSH Thread-Index: AQHR4yWb0Kt3ZKrawUWZ2rsvELgMRQ== Date: Thu, 21 Jul 2016 07:58:02 +0000 Message-ID: <20160721075801.5697618.51293.99071@sandvine.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-ooam-dt@ietf.org" Subject: Re: [sfc] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 07:58:07 -0000 Greg, This answers some of the questions I had after your presentations. However, regarding appending OAM after the packet, NSH header doesn't have = a length field that could indicate where the appended portion begins. The current Length field is regarding the header size. -Dave From: Gregory Mirsky Sent: Thursday, July 21, 2016 9:01 AM To: sfc@ietf.org Cc: rtg-ooam-dt@ietf.org Subject: [sfc] Identifying OAM in NSH Dear All, we had very good discussion on OAM this week. We=92ve touched on Active, Pa= ssive and Something-in-between OAM. But can NSH indicate which OAM type, if= any, associated with a packet? I think that the current version of draft-i= etf-sfc-nsh does not allow that and may be ambiguous in some cases. I propo= se change to interpretation and applicability description of the O(AM) flag= and allocation of the new protocol type to be used in the Next Protocol fi= eld. RFC 7799 defines Active OAM as following: An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream. Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network=92s metric and should not leave g= iven domain. And, I believe, such packets should be identified by the proto= col type of their own. OAM which behaves as much as Passive OAM or Somethin= g-in-between, e.g. OAM appended to data packet either at the domain=92s edg= e or on-the-fly, identified by the protocol type of the data packet carried= in NSH. Below are changes I=92d like to propose: Section 3.2 O-bit: OLD O bit: when set to 0x1 indicates that this packet is an Operations, Administration and Maintenance (OAM) message. The receiving SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information). OAM message specifics and handling details are outside the scope of this document. END NEW O bit: when set to 0x1 indicates that data packet identified by the Next Protocol type has OAM metadata appended. Definition of the format(s) used by OAM metadata is outside the scope of this document. END At the end of Section 3.2: OLD This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6-0xFD: Unassigned 0xFE-0xFF: Experimental END NEW This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6: Active OAM 0x7-0xFD: Unassigned 0xFE-0xFF: Experimental END And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols. Greatly appreciate your consideration and comments. Regards, Greg From nobody Thu Jul 21 01:48:47 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 C176812DC03; Thu, 21 Jul 2016 01:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nLZOc8MWuyb; Thu, 21 Jul 2016 01:48:42 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498FD12DC0B; Thu, 21 Jul 2016 01:48:41 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-73-579081111fd4 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 08.AD.09012.11180975; Thu, 21 Jul 2016 10:00:18 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 04:48:39 -0400 From: Gregory Mirsky To: Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] Identifying OAM in NSH Thread-Index: AdHjGxqUb41VTqTfTwmZE/bgRl5mHQALAc8AAAcP4zA= Date: Thu, 21 Jul 2016 08:48:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221ADAAD3@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <20160721075801.5697618.51293.99071@sandvine.com> In-Reply-To: <20160721075801.5697618.51293.99071@sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonQVeocUK4wca9TBZblz1kt/jXupfV 4smDrewOzB5Llvxk8vi6eTtrAFMUl01Kak5mWWqRvl0CV8aB/S4FG6Qr7r39w9rAuEG0i5GT Q0LAROLE7yOMELaYxIV769m6GLk4hASOMkr8WHmGGcJZziixdvEbVpAqNgEjiRcbe9hBbBEB V4nO6wvA4swChhJbFyxkAbGFBTQltvy6BFWjJXG39QozhG0lsWbWE7BtLAKqEhMa3oHV8wr4 Srzdux1qcyOjxIEfB8CKOAXsJO5ua2YCsRmBzvt+ag0TxDJxiVtP5jNBnC0gsWTPeWYIW1Ti 5eN/rBC2ksSc19eYIep1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZ wMiyipGjtLggJzfdyGATIzBijkmw6e5gvD/d8xCjAAejEg+vwp7+cCHWxLLiytxDjBIczEoi vP9bJoQL8aYkVlalFuXHF5XmpBYfYpTmYFES5xV7pBguJJCeWJKanZpakFoEk2Xi4JRqYKz/ Exx0O9alaM43ySsmjr0TA3wtlXZFfJE527H5l3Jo6aqrmRZ/BNcsNzl4/zdbo9Hdphd3D7jr fuIOWues/Kp5bvvpP1Py7i28L/ukVLd97cKvHx9cmRp2g8V+xpP9BgGKZ42FTd6eU1o0XXCC SEYki7jgaWbx5j8Po4PL1C9ndau3/V/rdFOJpTgj0VCLuag4EQCCK+J9lAIAAA== Archived-At: Cc: "rtg-ooam-dt@ietf.org" Subject: Re: [sfc] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 08:48:46 -0000 Hi Dave, thank you for the clarification. You point to the very important issue that= has implication onto applicability of methods that add, prepend or append,= OAM-specific information to a data packet. One way to address, I assume, i= s to introduce Length field that equals number of octets in Next Protocol. Regards, Greg -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Thursday, July 21, 2016 9:58 AM To: Gregory Mirsky ; sfc@ietf.org Cc: rtg-ooam-dt@ietf.org Subject: Re: [sfc] Identifying OAM in NSH Greg, This answers some of the questions I had after your presentations. However, regarding appending OAM after the packet, NSH header doesn't have = a length field that could indicate where the appended portion begins. The current Length field is regarding the header size. -Dave From: Gregory Mirsky Sent: Thursday, July 21, 2016 9:01 AM To: sfc@ietf.org Cc: rtg-ooam-dt@ietf.org Subject: [sfc] Identifying OAM in NSH Dear All, we had very good discussion on OAM this week. We've touched on Active, Pass= ive and Something-in-between OAM. But can NSH indicate which OAM type, if a= ny, associated with a packet? I think that the current version of draft-iet= f-sfc-nsh does not allow that and may be ambiguous in some cases. I propose= change to interpretation and applicability description of the O(AM) flag a= nd allocation of the new protocol type to be used in the Next Protocol fiel= d. RFC 7799 defines Active OAM as following: An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream. Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network's metric and should not leave giv= en domain. And, I believe, such packets should be identified by the protoco= l type of their own. OAM which behaves as much as Passive OAM or Something-= in-between, e.g. OAM appended to data packet either at the domain's edge or= on-the-fly, identified by the protocol type of the data packet carried in = NSH. Below are changes I'd like to propose: Section 3.2 O-bit: OLD O bit: when set to 0x1 indicates that this packet is an Operations, Administration and Maintenance (OAM) message. The receiving SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information). OAM message specifics and handling details are outside the scope of this document. END NEW O bit: when set to 0x1 indicates that data packet identified by the Next Pr= otocol type has OAM metadata appended. Definition of the format(s) used by = OAM metadata is outside the scope of this document. END At the end of Section 3.2: OLD This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6-0xFD: Unassigned 0xFE-0xFF: Experimental END NEW This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6: Active OAM 0x7-0xFD: Unassigned 0xFE-0xFF: Experimental END And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols. Greatly appreciate your consideration and comments. Regards, Greg From nobody Thu Jul 21 15:07: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 495F312D9EF; Thu, 21 Jul 2016 15:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 icn_vva87wxd; Thu, 21 Jul 2016 15:07:21 -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 C71ED12D9EB; Thu, 21 Jul 2016 15:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29737; q=dns/txt; s=iport; t=1469138840; x=1470348440; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6EyVWV9T9k8wANv4+Mdm3s937kLe1+SDO8ujv+FufbI=; b=EaFlg7m2QbNDwo4VC5jzFUdqVejMkNtxNaDMRtSybyz2K3HKSPzZzPRv xkrk2BSo8vgeUkn5nvI5A5mEgxpF5ls/QBjeM20p/TNUoEqniv4aMIXJF AEuHIlaLtEsF8BQyqvQha3fXUrIW26dUVRJ+WsSt0VGVsgG6cBU8zSSJS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOAgDARpFX/5hdJa1dgnFOVnwGtkmCD?= =?us-ascii?q?4F7IoV4AoEtOBQBAQEBAQEBZSeEXAEBBS06EhACAQgRAwECIQcHMhQJCAIEAQ0?= =?us-ascii?q?FiDAOvQoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2EEhEBKhIYhSMFk2SFQ?= =?us-ascii?q?gGGFYhVgWyEWYh1kCABHjaCPoE1boZINn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,401,1464652800"; d="scan'208,217";a="300864717" 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; 21 Jul 2016 22:07:19 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6LM7IeK015203 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2016 22:07:18 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 17:07:17 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 17:07:17 -0500 From: "Deepak Kumar (dekumar)" To: "Saumya Dikshit (sadikshi)" , "Nagendra Kumar Nainar (naikumar)" , Gregory Mirsky , "BIER (bier@ietf.org)" , "sfc@ietf.org" , "nvo3@ietf.org" , "rtg-ooam-dt@ietf.org" , "rtgwg@ietf.org" Thread-Topic: [Rtg-ooam-dt] [nvo3] [Bier] Comments to OOAM Requirements draft from Ron Bonica Thread-Index: AQHR45w+BpeT5BYrHUeAvigYxGCQaA== Date: Thu, 21 Jul 2016 22:07:17 +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/14.6.5.160527 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.164.80] Content-Type: multipart/alternative; boundary="_000_D3B6922519326dekumarciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rbonica@juniper.net" Subject: Re: [sfc] [Rtg-ooam-dt] [nvo3] [Bier] Comments to OOAM Requirements draft from Ron Bonica X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 21 Jul 2016 22:07:24 -0000 --_000_D3B6922519326dekumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Below requirement looks like deal with ability of OAM to be extensible. We = should add requirement regarding Extensibility for OAM protocol without add= ing details of VNI, etc. Thanks, Deepak From: Rtg-ooam-dt > on behalf of "Saumya Dikshit (sadikshi)" > Date: Wednesday, July 20, 2016 at 6:03 AM To: "Saumya Dikshit (sadikshi)" >, "Nagendra Kumar Nainar (naikumar)" >, Gregory Mirsky >, "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.or= g" > Cc: "rbonica@juniper.net" > Subject: Re: [Rtg-ooam-dt] [nvo3] [Bier] Comments to OOAM Requirements draf= t from Ron Bonica Hi Greg, Authors of ooam-dt set of drafts Other than current requirements, it will be great to explicitly support the= OAM PDU semantics. * apply OAM function_set to group of VNI or band of VNI=92s and this in= formation carried in same OAM PDU. Although the response can be discrete on= a per VNI basis based on how and where the response is triggered from. If = It=92s proxy from remote NVE, then the response can be a replication to the= request. This is will reduce the number of probes which need to be send to= perform the OAM functions. * It will be great to designate VNI=92s as L2 or L3 and apply function_= Set to them. This is implicitly derived in data-path, but for OAM PDUs, it = will help to make it explicit either via using some flags or some other sem= antics. Hence we can carry bunch of L2 and L3 vnis with corresponding funct= ion-set In case these are valid requirements, which I feel they are. Can they find = a place in existing document. I can also come out with a peripheral draft defining these. Thanks Saumya. From: nvo3 > on behalf = of sadikshi > Date: Monday, July 4, 2016 at 8:09 PM To: "Nagendra Kumar Nainar (naikumar)" >, Gregory Mirsky >, "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org<= mailto:rtgwg@ietf.org>" > Cc: "rbonica@juniper.net" > Subject: Re: [nvo3] [Bier] Comments to OOAM Requirements draft from Ron Bon= ica Hi Nagendra, Thanks for the response. I missed this one in the below email: >>>>> REQ#14: Overlay OAM MUST have the ability to discover and exercise equal cost multipath (ECMP) paths in its transport network. This will require the underlay nodes/router/switches to support OAM semanti= cs, which may not be possible in case of brownfield deployments (deploying NVO tunnels over existing IP-c= ore network). Regards, Saumya. From: "Nagendra Kumar Nainar (naikumar)" > Date: Monday, July 4, 2016 at 4:39 PM To: sadikshi >, Gregory Mirsk= y >, "BIER = (bier@ietf.org)" = >, "sfc@ietf.org" >,= "nvo3@ietf.org" = >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: Re: [Bier] [nvo3] Comments to OOAM Requirements draft from Ron Bon= ica HI Saumya, Please see inline.. Hi Greg, I have following queries on Overlay OAM Requirements: >>>>> REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic, i.e. in-band with the monitored traffic, i.e. follow exactly the same path as data plane traffic, in forward direction, i.e. from ingress toward egress end point(s) of the OAM test session. =93Exactly same path=94, should be made explicit if it=92s referring to the= underlay transport path. Yes, that is the intention. We will clarify it. "OAM packets SHOULD be fate sharing with data traffic=94 will not apply to = "REQ#3: centralized controller=94. I think =93SHOULD=94 should be treated as a =93MUST=94 if the reference is = within the document :) >>>>> REQ#11: Overlay OAM MUST support fault localization of Loss of Continuity check. Does the =93localization=94 maps to overlay node/link context ? Can we have= a =93MAY=94 requirement for mapping it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement to narrow down to underlay for a speedier fault management. MAY statement sounds reasonable. REQ#22 =97 REQ#25 refer to =93per-segment=94. A =93segment=94 maps to a NVO-tunnel? Yes, a segment referes to NVO tunnel between NVEs. Multiple such= segments may comprise an end-to-end tunnel. Shouldn=92t there be on a per-VNI basis as well. I think the granularity should definitely at per-VNI level. >>>>> REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such OAM methods MAY combine in-band monitoring or measurement in forward direction and out-of-band notification in the reverse direction, i.e. from egress to ingress end point of the OAM test session. In case of optical deployments like, fiber management (both request and res= ponse) can be out-of-band, hence may need a mention here. I see. We will check this. Thanks for your comments. Regards, Nagendra Thanks Saumya From: nvo3 > on behalf = of Gregory Mirsky > Date: Tuesday, April 5, 2016 at 1:39 AM To: "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: [nvo3] Comments to OOAM Requirements draft from Ron Bonica Dear All, Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> = tag. The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Net= works: Gap Analysis. Regards, Greg --_000_D3B6922519326dekumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1CC615140F76794E8D7C97E639AE7884@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

Below requirement looks like deal with ability of OAM to be extensible= . We should add requirement regarding Extensibility for OAM protocol withou= t adding details of VNI, etc.

Thanks,
Deepak

From: Rtg-ooam-dt <rtg-ooam-dt-bounces@ietf.org> on = behalf of "Saumya Dikshit (sadikshi)" <sadikshi@cisco.com>
Date: Wednesday, July 20, 2016 at 6= :03 AM
To: "Saumya Dikshit (sadikshi)= " <sadikshi@cisco.com>= , "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>, "BIER (bier@ietf.org)" <= bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@ietf.o= rg" <nvo3@ietf.org>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [Rtg-ooam-dt] [nvo3] [= Bier] Comments to OOAM Requirements draft from Ron Bonica

Hi Greg, Authors of ooam-dt set of drafts

Other than current requirements, it will be great to explicitly suppor= t the OAM PDU semantics. 
  • apply OAM function_set to group of VNI or band of VNI=92s and this info= rmation carried in same OAM PDU. Although the response can be discrete on a= per VNI basis based on how and where the response is triggered from. If It= =92s proxy from remote NVE, then the response can be a replication to the request. This is will reduce the numb= er of probes which need to be send to perform the OAM functions.
  • It= will be great to designate VNI=92s as L2 or L3 and apply function_Set to t= hem. This is implicitly derived in data-path, but for OAM PDUs, it will hel= p to make it explicit either via using some flags or some other semantics. = Hence we can carry bunch of L2 and L3 vnis with corresponding function-set
In case these are valid requirements, which I feel they are. Can they = find a place in existing document.
I can also come out with a peripheral draft defining these. 

Thanks
Saumya.

From: nvo3 <nvo3-bounces@ietf.org> on behalf of sadikshi &l= t;sadikshi@cisco.com>
Date: Monday, July 4, 2016 at 8:09 = PM
To: "Nagendra Kumar Nainar (na= ikumar)" <naikumar@cisco.com<= /a>>, Gregory Mirsky <= gregory.mirsky@ericsson.com>, "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@= ietf.org" <nvo3@ietf.org&g= t;, "rtg-ooam-dt@ietf.org&= quot; <rtg-ooam-dt@ietf.org>, = "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [nvo3] [Bier] Comments= to OOAM Requirements draft from Ron Bonica

Hi Nagendra,

Thanks for the response. I missed this one in the below email:

>>>>> REQ#14: Overlay OAM MUS=
T have the ability to discover and exercise
            equal cost multipath (ECMP) paths in its transport network.=

This will require the underlay nodes/router/switches to support OAM se= mantics, which may not be possible 
in case of brownfield deployments (deploying NVO tunnels over existing= IP-core network). 


Regards,
Saumya.


From: "Nagendra Kumar Nainar (= naikumar)" <naikumar@cisco.co= m>
Date: Monday, July 4, 2016 at 4:39 = PM
To: sadikshi <sadikshi@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>= , "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@= ietf.org" <nvo3@ietf.org&g= t;, "rtg-ooam-dt@ietf.org&= quot; <rtg-ooam-dt@ietf.org>, = "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [Bier] [nvo3] Comments= to OOAM Requirements draft from Ron Bonica

HI Saumya,

Please see inline..

Hi Greg,

I have following queries on  Overlay OAM Requirements:

>>>>> REQ#6:  Overlay OAM pac=
kets SHOULD be fate sharing with data traffic,
            i.e. in-band with the monitored traffic, i.e. follow exactly
            the same path as data plane traffic, in forward direction,
            i.e. from ingress toward egress end point(s) of the OAM test
            session.

=93Exactly same path=94, should be made explicit if it=92s referring to the= underlay transport path.

<Nagendra> Yes, that is the intention. We will clarify it.

"OAM packets SHOULD be fate sharing wit= h data traffic= =94 will not apply to "REQ#3:  centralized controller= =94.
I think =93SHOULD=94 should be treated as a =93MU= ST=94 if the reference is within the document :)
 


>>>>> REQ#11: Overlay OAM MUS=
T support fault localization of Loss of
            Continuity check.
Does the =93localization=94 maps to overlay node/link context ? Can we have= a =93MAY=94 requirement for mapping
it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement
to narrow down to underlay for a speedier fault management.

<Nagendra> MAY statement sounds reasonable.

REQ#22 =97 REQ#25 refer to =93per-segment=94. 
A =93segment=94 maps to a NVO-tunnel? 

<Nagendra> Yes, a segment referes to NVO tunnel between NVEs. Mu= ltiple such segments may comprise an end-to-end tunnel.

 Shouldn=92t there be on a  per-VNI basis as well.

<Nagendra>I think  the granularity should definitely at per= -VNI level. 

>>>>> REQ#7:  Overlay OAM MUS=
T support bi-directional OAM methods.  Such
            OAM methods MAY combine in-band monitoring or measurement in
            forward direction and out-of-band notification in the
            reverse direction, i.e. from egress to ingress end point of
            the OAM test session.

In case of optical deployments like, fiber management (both request an= d response) can be out-of-band, hence may
need a mention here. 
<Nagendra> I see. We will check this.

Thanks for your comments.

Regards,
Nagendra


Thanks
Saumya

From: nvo3 <nvo3-bounces@ietf.org> on behalf of Gregory Mir= sky <gregory.mirsky@erics= son.com>
Date: Tuesday, April 5, 2016 at 1:3= 9 AM
To: "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org<= /a>" <sfc@ietf.org>, "<= a href=3D"mailto:nvo3@ietf.org">nvo3@ietf.org" <nvo3@ietf.org>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: [nvo3] Comments to OOAM Re= quirements draft from Ron Bonica

Dear All,

Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> tag= . The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Networks: Gap Analysis.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_D3B6922519326dekumarciscocom_-- From nobody Thu Jul 21 15: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 28B1512D89B; Thu, 21 Jul 2016 15:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 8m3_PQ4BJ5X5; Thu, 21 Jul 2016 15:44:27 -0700 (PDT) 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 7047312D0C4; Thu, 21 Jul 2016 15:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33409; q=dns/txt; s=iport; t=1469141067; x=1470350667; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Jbm1YNlotzbh7FbLW1qcwhfz0GvM3+EASSa/QUWAKfY=; b=SRwWGgRc+w3CwaVzhso7ca/Ccz4xmi+AsZQBF1cYgast5qI0CpnpgFcT 0YlFrUh2I7wXV2EWURZ+xJlUotpPkXhGX/zhsLbOQK/N3SIaP6JdE19LJ +lpG4opXPFdem5oBbVHoiSaeknIR5KkM9Eb6sQZyo7RG4OUEnILzoiOj0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgAIUJFX/4QNJK1dgnFOVnwGtkeCD?= =?us-ascii?q?4F7I4V5AoEuOBQBAQEBAQEBZSeEXAEBBS06EhACAQgRAwECIQEGBzIUCQgCBAE?= =?us-ascii?q?NBYgwDr0CAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhBIRASoSGIUjBZNkh?= =?us-ascii?q?UIBhhWIVYFshFmIdZAgAR42gj6BNW6GSDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,401,1464652800"; d="scan'208,217";a="131411177" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jul 2016 22:44:01 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6LMi17f030311 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2016 22:44:01 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 17:44:00 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 17:44:00 -0500 From: "Saumya Dikshit (sadikshi)" To: "Deepak Kumar (dekumar)" , "Nagendra Kumar Nainar (naikumar)" , Gregory Mirsky , "BIER (bier@ietf.org)" , "sfc@ietf.org" , "nvo3@ietf.org" , "rtg-ooam-dt@ietf.org" , "rtgwg@ietf.org" Thread-Topic: [Rtg-ooam-dt] [nvo3] [Bier] Comments to OOAM Requirements draft from Ron Bonica Thread-Index: AQHR4ocViWBwwTTmV0mY2c9hkRwUbKAjx0CAgAArxgA= Date: Thu, 21 Jul 2016 22:44:00 +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/14.6.5.160527 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.228.216] Content-Type: multipart/alternative; boundary="_000_D3B71C496BA4Csadikshiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rbonica@juniper.net" Subject: Re: [sfc] [Rtg-ooam-dt] [nvo3] [Bier] Comments to OOAM Requirements draft from Ron Bonica X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 21 Jul 2016 22:44:31 -0000 --_000_D3B71C496BA4Csadikshiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Deepak. I think we should also new define TLVs in draft-ooamdt-rtgwg= -ooam-header or any alternative publication addressing the requirement. From: "Deepak Kumar (dekumar)" = > Date: Friday, July 22, 2016 at 12:07 AM To: sadikshi >, "Nagendra Kum= ar Nainar (naikumar)" >, Greg= ory Mirsky = >, "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: Re: [Rtg-ooam-dt] [nvo3] [Bier] Comments to OOAM Requirements draf= t from Ron Bonica Hi, Below requirement looks like deal with ability of OAM to be extensible. We = should add requirement regarding Extensibility for OAM protocol without add= ing details of VNI, etc. Thanks, Deepak From: Rtg-ooam-dt > on behalf of "Saumya Dikshit (sadikshi)" > Date: Wednesday, July 20, 2016 at 6:03 AM To: "Saumya Dikshit (sadikshi)" >, "Nagendra Kumar Nainar (naikumar)" >, Gregory Mirsky >, "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.or= g" > Cc: "rbonica@juniper.net" > Subject: Re: [Rtg-ooam-dt] [nvo3] [Bier] Comments to OOAM Requirements draf= t from Ron Bonica Hi Greg, Authors of ooam-dt set of drafts Other than current requirements, it will be great to explicitly support the= OAM PDU semantics. * apply OAM function_set to group of VNI or band of VNI=92s and this in= formation carried in same OAM PDU. Although the response can be discrete on= a per VNI basis based on how and where the response is triggered from. If = It=92s proxy from remote NVE, then the response can be a replication to the= request. This is will reduce the number of probes which need to be send to= perform the OAM functions. * It will be great to designate VNI=92s as L2 or L3 and apply function_= Set to them. This is implicitly derived in data-path, but for OAM PDUs, it = will help to make it explicit either via using some flags or some other sem= antics. Hence we can carry bunch of L2 and L3 vnis with corresponding funct= ion-set In case these are valid requirements, which I feel they are. Can they find = a place in existing document. I can also come out with a peripheral draft defining these. Thanks Saumya. From: nvo3 > on behalf = of sadikshi > Date: Monday, July 4, 2016 at 8:09 PM To: "Nagendra Kumar Nainar (naikumar)" >, Gregory Mirsky >, "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org<= mailto:rtgwg@ietf.org>" > Cc: "rbonica@juniper.net" > Subject: Re: [nvo3] [Bier] Comments to OOAM Requirements draft from Ron Bon= ica Hi Nagendra, Thanks for the response. I missed this one in the below email: >>>>> REQ#14: Overlay OAM MUST have the ability to discover and exercise equal cost multipath (ECMP) paths in its transport network. This will require the underlay nodes/router/switches to support OAM semanti= cs, which may not be possible in case of brownfield deployments (deploying NVO tunnels over existing IP-c= ore network). Regards, Saumya. From: "Nagendra Kumar Nainar (naikumar)" > Date: Monday, July 4, 2016 at 4:39 PM To: sadikshi >, Gregory Mirsk= y >, "BIER = (bier@ietf.org)" = >, "sfc@ietf.org" >,= "nvo3@ietf.org" = >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: Re: [Bier] [nvo3] Comments to OOAM Requirements draft from Ron Bon= ica HI Saumya, Please see inline.. Hi Greg, I have following queries on Overlay OAM Requirements: >>>>> REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic, i.e. in-band with the monitored traffic, i.e. follow exactly the same path as data plane traffic, in forward direction, i.e. from ingress toward egress end point(s) of the OAM test session. =93Exactly same path=94, should be made explicit if it=92s referring to the= underlay transport path. Yes, that is the intention. We will clarify it. "OAM packets SHOULD be fate sharing with data traffic=94 will not apply to = "REQ#3: centralized controller=94. I think =93SHOULD=94 should be treated as a =93MUST=94 if the reference is = within the document :) >>>>> REQ#11: Overlay OAM MUST support fault localization of Loss of Continuity check. Does the =93localization=94 maps to overlay node/link context ? Can we have= a =93MAY=94 requirement for mapping it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement to narrow down to underlay for a speedier fault management. MAY statement sounds reasonable. REQ#22 =97 REQ#25 refer to =93per-segment=94. A =93segment=94 maps to a NVO-tunnel? Yes, a segment referes to NVO tunnel between NVEs. Multiple such= segments may comprise an end-to-end tunnel. Shouldn=92t there be on a per-VNI basis as well. I think the granularity should definitely at per-VNI level. >>>>> REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such OAM methods MAY combine in-band monitoring or measurement in forward direction and out-of-band notification in the reverse direction, i.e. from egress to ingress end point of the OAM test session. In case of optical deployments like, fiber management (both request and res= ponse) can be out-of-band, hence may need a mention here. I see. We will check this. Thanks for your comments. Regards, Nagendra Thanks Saumya From: nvo3 > on behalf = of Gregory Mirsky > Date: Tuesday, April 5, 2016 at 1:39 AM To: "BIER (bier@ietf.org)" >, "sfc@ietf.org" >, "nvo3@ietf.org" >, "rtg-ooam-dt@ietf.org" >, "rtgwg@ietf.org" > Cc: "rbonica@juniper.net" > Subject: [nvo3] Comments to OOAM Requirements draft from Ron Bonica Dear All, Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> = tag. The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Net= works: Gap Analysis. Regards, Greg --_000_D3B71C496BA4Csadikshiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks Deepak. I think we should also new define TLVs in draft-ooamdt-rtgwg-ooam-header<= /span> or any alternative publication addressing the requirement.

From: "Deepak Kumar (dekumar)&= quot; <dekumar@cisco.com> Date: Friday, July 22, 2016 at 12:0= 7 AM
To: sadikshi <sadikshi@cisco.com>, "Nagendra Kumar Nainar= (naikumar)" <naikumar@cisco.= com>, Gregory Mirsky <gregory.mirsky@ericsson.com>, "BIER (bier@ietf.org)" <= bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@ietf.o= rg" <nvo3@ietf.org>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [Rtg-ooam-dt] [nvo3] [= Bier] Comments to OOAM Requirements draft from Ron Bonica

Hi,

Below requirement looks like deal with ability of OAM to be extensible= . We should add requirement regarding Extensibility for OAM protocol withou= t adding details of VNI, etc.

Thanks,
Deepak

From: Rtg-ooam-dt <rtg-ooam-dt-bounces@ietf.org> on = behalf of "Saumya Dikshit (sadikshi)" <sadikshi@cisco.com>
Date: Wednesday, July 20, 2016 at 6= :03 AM
To: "Saumya Dikshit (sadikshi)= " <sadikshi@cisco.com>= , "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>, "BIER (bier@ietf.org)" <= bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@ietf.o= rg" <nvo3@ietf.org>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [Rtg-ooam-dt] [nvo3] [= Bier] Comments to OOAM Requirements draft from Ron Bonica

Hi Greg, Authors of ooam-dt set of drafts

Other than current requirements, it will be great to explicitly suppor= t the OAM PDU semantics. 
  • apply OAM function_set to group of VNI or band of VNI=92s and this info= rmation carried in same OAM PDU. Although the response can be discrete on a= per VNI basis based on how and where the response is triggered from. If It= =92s proxy from remote NVE, then the response can be a replication to the request. This is will reduce the numb= er of probes which need to be send to perform the OAM functions.
  • It= will be great to designate VNI=92s as L2 or L3 and apply function_Set to t= hem. This is implicitly derived in data-path, but for OAM PDUs, it will hel= p to make it explicit either via using some flags or some other semantics. = Hence we can carry bunch of L2 and L3 vnis with corresponding function-set
In case these are valid requirements, which I feel they are. Can they = find a place in existing document.
I can also come out with a peripheral draft defining these. 

Thanks
Saumya.

From: nvo3 <nvo3-bounces@ietf.org> on behalf of sadikshi &l= t;sadikshi@cisco.com>
Date: Monday, July 4, 2016 at 8:09 = PM
To: "Nagendra Kumar Nainar (na= ikumar)" <naikumar@cisco.com<= /a>>, Gregory Mirsky <= gregory.mirsky@ericsson.com>, "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@= ietf.org" <nvo3@ietf.org&g= t;, "rtg-ooam-dt@ietf.org&= quot; <rtg-ooam-dt@ietf.org>, = "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [nvo3] [Bier] Comments= to OOAM Requirements draft from Ron Bonica

Hi Nagendra,

Thanks for the response. I missed this one in the below email:

>>>>> REQ#14: Overlay OAM MUS=
T have the ability to discover and exercise
            equal cost multipath (ECMP) paths in its transport network.=

This will require the underlay nodes/router/switches to support OAM se= mantics, which may not be possible 
in case of brownfield deployments (deploying NVO tunnels over existing= IP-core network). 


Regards,
Saumya.


From: "Nagendra Kumar Nainar (= naikumar)" <naikumar@cisco.co= m>
Date: Monday, July 4, 2016 at 4:39 = PM
To: sadikshi <sadikshi@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>= , "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "nvo3@= ietf.org" <nvo3@ietf.org&g= t;, "rtg-ooam-dt@ietf.org&= quot; <rtg-ooam-dt@ietf.org>, = "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: Re: [Bier] [nvo3] Comments= to OOAM Requirements draft from Ron Bonica

HI Saumya,

Please see inline..

Hi Greg,

I have following queries on  Overlay OAM Requirements:

>>>>> REQ#6:  Overlay OAM pac=
kets SHOULD be fate sharing with data traffic,
            i.e. in-band with the monitored traffic, i.e. follow exactly
            the same path as data plane traffic, in forward direction,
            i.e. from ingress toward egress end point(s) of the OAM test
            session.

=93Exactly same path=94, should be made explicit if it=92s referring to the= underlay transport path.

<Nagendra> Yes, that is the intention. We will clarify it.

"OAM packets SHOULD be fate sharing wit= h data traffic= =94 will not apply to "REQ#3:  centralized controller= =94.
I think =93SHOULD=94 should be treated as a =93MU= ST=94 if the reference is within the document :)
 


>>>>> REQ#11: Overlay OAM MUS=
T support fault localization of Loss of
            Continuity check.
Does the =93localization=94 maps to overlay node/link context ? Can we have= a =93MAY=94 requirement for mapping
it to underlay. Since in datacenter, with more of east-west traffic, there = might be deployment requirement
to narrow down to underlay for a speedier fault management.

<Nagendra> MAY statement sounds reasonable.

REQ#22 =97 REQ#25 refer to =93per-segment=94. 
A =93segment=94 maps to a NVO-tunnel? 

<Nagendra> Yes, a segment referes to NVO tunnel between NVEs. Mu= ltiple such segments may comprise an end-to-end tunnel.

 Shouldn=92t there be on a  per-VNI basis as well.

<Nagendra>I think  the granularity should definitely at per= -VNI level. 

>>>>> REQ#7:  Overlay OAM MUS=
T support bi-directional OAM methods.  Such
            OAM methods MAY combine in-band monitoring or measurement in
            forward direction and out-of-band notification in the
            reverse direction, i.e. from egress to ingress end point of
            the OAM test session.

In case of optical deployments like, fiber management (both request an= d response) can be out-of-band, hence may
need a mention here. 
<Nagendra> I see. We will check this.

Thanks for your comments.

Regards,
Nagendra


Thanks
Saumya

From: nvo3 <nvo3-bounces@ietf.org> on behalf of Gregory Mir= sky <gregory.mirsky@erics= son.com>
Date: Tuesday, April 5, 2016 at 1:3= 9 AM
To: "BIER (bier@ietf.org)" <bier@ietf.org>, "sfc@ietf.org<= /a>" <sfc@ietf.org>, "<= a href=3D"mailto:nvo3@ietf.org">nvo3@ietf.org" <nvo3@ietf.org>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rbonica@juniper.net" <rbonica@juniper.net>
Subject: [nvo3] Comments to OOAM Re= quirements draft from Ron Bonica

Dear All,

Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> tag= . The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Networks: Gap Analysis.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_D3B71C496BA4Csadikshiciscocom_-- From nobody Fri Jul 22 01:10: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 2946A12D5EB; Fri, 22 Jul 2016 01:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 Yl1d4IO2p7es; Fri, 22 Jul 2016 01:10:26 -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 1FCC712D630; Fri, 22 Jul 2016 01:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15316; q=dns/txt; s=iport; t=1469175026; x=1470384626; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n/xhmytz3YXtb+IgXZW12q7mPNMXF/0r84OUJ3GLWQ0=; b=TNMCGU/s6t7SjkRzfAFmjXpqaS6LxOSDOVBnr+c3fKdN6a7jM+xwoCHh MgkT1V3gMQl4CZbCHh3MIYN11w94vAwW220/QshxSyfdvP9eP2eflTlJn 4Al3ps9TNTo5b9IsCru+pGvLS5fI6ghV4jxDgi5CrKrcgAw/Umw5lvM8L U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAgBq1JFX/4MNJK1dgnFOVnyzWIUFg?= =?us-ascii?q?XsjhXkCgTA4FAEBAQEBAQFdJ4RdAQUBASs6BwsQAgEIPwcnCxQRAgQOBYgwDrw?= =?us-ascii?q?+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoF4glWHbIIvBZNkhUIBjmyBbIRZi?= =?us-ascii?q?HWQIAEeNoNzbohVAQEB?= X-IronPort-AV: E=Sophos;i="5.28,404,1464652800"; d="scan'208,217";a="128701391" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2016 08:10:24 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6M8AOVK031553 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jul 2016 08:10:24 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 22 Jul 2016 04:10:23 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Fri, 22 Jul 2016 04:10:23 -0400 From: "Carlos Pignataro (cpignata)" To: Gregory Mirsky Thread-Topic: [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR4/B/s+mJr49HL0uqnvaJ3glSKw== Date: Fri, 22 Jul 2016 08:10:23 +0000 Message-ID: <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_9DBA673E960C49B09A904DB4828C08BEciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:10:28 -0000 --_000_9DBA673E960C49B09A904DB4828C08BEciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, Please find some comments inline. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Jul 21, 2016, at 09:01, Gregory Mirsky > wrote: Dear All, we had very good discussion on OAM this week. We've touched on Active, Pass= ive and Something-in-between OAM. But can NSH indicate which OAM type, if a= ny, associated with a packet? I think that the current version of draft-iet= f-sfc-nsh does not allow that and may be ambiguous in some cases. I propose= change to interpretation and applicability description of the O(AM) flag a= nd allocation of the new protocol type to be used in the Next Protocol fiel= d. Active, passive and something-in-between are not OAM protocol types but rat= her they are measuring methods. Active OAM can include a plurality of OAM p= rotocols, including BFD, S-BFD, something-over-ip, etc. I also believe that the current OAM text in NSH is not ambiguous and allows= enough processing of the header to understand something is OAM, without go= ing the specifics of an OAM handler. Therefore, I oppose this change. RFC 7799 defines Active OAM as following: An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream. Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network's metric and should not leave giv= en domain. And, I believe, such packets should be identified by the protoco= l type of their own. Seems you are advocating for a single "OAM" protocol type for OAM packets. = The functionality of identifying something as OAM is in the O-bit, so no ne= ed to waste bits in duplication. Then, at some point, you have to differentiate if an OAM is, say, IP or "ra= w BFD" or something else. That's what the Protocol field is for. I do not s= ee a need to add an indirection here to then have to have a protocol field = inside the OAM. OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM = appended to data packet either at the domain's edge or on-the-fly, identifi= ed by the protocol type of the data packet carried in NSH. That's correct, with the O bit cleared; it's a data packet and not an OAM o= ne. Below are changes I'd like to propose: Section 3.2 O-bit: OLD O bit: when set to 0x1 indicates that this packet is an Operations, Administration and Maintenance (OAM) message. The receiving SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information). OAM message specifics and handling details are outside the scope of this document. END NEW O bit: when set to 0x1 indicates that data packet identified by the Next Protocol type has OAM metadata appended. No. If it is a data packet it does not have the O bit set (to 1 or to which= ever other possible value for the bit :-) The goal is that looking at a single but it can be understood if it is a da= ta packet (which can be used, marked, etc. to be used for OAM purposes, or = not). We do not want OAM direct exception processing for data packets. Definition of the format(s) used by OAM metadata is outside the scope of this document. END At the end of Section 3.2: OLD This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6-0xFD: Unassigned 0xFE-0xFF: Experimental END NEW This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6: Active OAM As per above I do not believe there's a single OAM protocol. 0x7-0xFD: Unassigned 0xFE-0xFF: Experimental END And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols. Greatly appreciate your consideration and comments. My EUR0.02. Thanks, Carlos. Regards, Greg _______________________________________________ Rtg-ooam-dt mailing list Rtg-ooam-dt@ietf.org https://www.ietf.org/mailman/listinfo/rtg-ooam-dt --_000_9DBA673E960C49B09A904DB4828C08BEciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg,

Please find some comments inline. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Jul 21, 2016, at 09:01, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear All,

we had very good discussion on OAM this week. WeR= 17;ve touched on Active, Passive and Something-in-between OAM. But can NSH = indicate which OAM type, if any, associated with a packet? I think that the= current version of draft-ietf-sfc-nsh does not allow that and may be ambiguous in some cases. I propose change to int= erpretation and applicability description of the O(AM) flag and allocation = of the new protocol type to be used in the Next Protocol field.<= /p>

 


Active, passive and something-in-between are not OAM protocol types bu= t rather they are measuring methods. Active OAM can include a plurality of = OAM protocols, including BFD, S-BFD, something-over-ip, etc. 

I also believe that the current OAM text in NSH is not ambiguous and a= llows enough processing of the header to understand something is OAM, witho= ut going the specifics of an OAM handler. 

Therefore, I oppose this change. 

RFC 7799 defines Active OAM as following:=

An Active Metric or Metho= d depends on a dedicated measurement packet stream and observations of the = stream.

Thus, regardless of encapsulation used by OAM, it is= the packet constructed solely for monitoring, measuring network’s me= tric and should not leave given domain. And, I believe, such packets should= be identified by the protocol type of their own.


Seems you are advocating for a single "OAM" protocol type fo= r OAM packets. The functionality of identifying something as OAM is in the = O-bit, so no need to waste bits in duplication. 

Then, at some point, you have to differentiate if an OAM is, say, IP o= r "raw BFD" or something else. That's what the Protocol field is = for. I do not see a need to add an indirection here to then have to have a = protocol field inside the OAM. 

OAM which behaves as much as Passive OAM or Somethin= g-in-between, e.g. OAM appended to data packet either at the domain’s= edge or on-the-fly, identified by the protocol type of the data packet car= ried in NSH.


That's correct, with the O bit cleared; it's a data packet and not an OAM o= ne. 

Below are changes I’d like to propose:

Section 3.2 O-bit:

OLD

   O bit: when set to 0x1 indicates that t= his packet is an Operations,

   Administration and Maintenance (OAM) me= ssage.  The receiving SFF and

   SFs nodes MUST examine the payload and = take appropriate action (e.g.

   return status information).  OAM m= essage specifics and handling

   details are outside the scope of this d= ocument.

END

NEW

O bit: when set to 0x1 indicates that data packet id= entified by the Next

Protocol type has OAM metadata appended.


No. If it is a data packet it does not have the O bit set (to 1 or to = whichever other possible value for the bit :-)

The goal is that looking at a single but it can be understood if it is= a data packet (which can be used, marked, etc. to be used for OAM purposes= , or not). 

We do not want OAM direct exception processing for data packets. =

Definition of the format(s)

used by OAM metadata is outside the scope of this do= cument.

END

 

At the end of Section 3.2:

OLD

   This draft defines the following Next P= rotocol values:

 

   0x1 : IPv4

   0x2 : IPv6

   0x3 : Ethernet

   0x4: NSH

   0x5: MPLS

   0x6-0xFD: Unassigned

   0xFE-0xFF: Experimental

END

NEW

   This draft defines the following Next P= rotocol values:

 

   0x1 : IPv4

   0x2 : IPv6

   0x3 : Ethernet

   0x4: NSH

   0x5: MPLS

   0x6: Active OAM


As per above I do not believe there's a single OAM protocol. 

   0x7-0xFD: Unassigned

   0xFE-0xFF: Experimental

END

 

And, consequently, section 13.2.5 in IANA Considerat= ions section will request allocation of value 0x6 to be assigned to Active = OAM protocols.

 

Greatly appreciate your consideration and comments.<= o:p>

 


My €0.02. 

Thanks,

Carlos. 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

 

_______________________________________________
Rtg-ooam-dt mailing list
Rtg-ooam-dt@ietf.org
https:/= /www.ietf.org/mailman/listinfo/rtg-ooam-dt
--_000_9DBA673E960C49B09A904DB4828C08BEciscocom_-- From nobody Fri Jul 22 01:12: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 1096612D672; Fri, 22 Jul 2016 01:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 x788PrGC_lxN; Fri, 22 Jul 2016 01:12:06 -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 03F1E12D5EB; Fri, 22 Jul 2016 01:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4176; q=dns/txt; s=iport; t=1469175125; x=1470384725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LDuroTSpjp3TucjORu/T2ZZsgxzE3ZXgY2ItLWfKpOw=; b=XBH3glm17F5ksyUBbrXiflYWJYsQXJpUsmSjnoF6HYju86mqdkZtQ/mz Dy7HYCSb48Rp2FfC4Xwu11/4n/NSgyxjbANm6OZk2WExwNhfJuIMziwI1 z8U8jSyMh8gPJB8NUAB4aW+O48NRj3fvPtg9nftTHdbUawx7KdQolGTU9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AgC21JFX/4ENJK1dgz9WfLhdgXsjh?= =?us-ascii?q?XkCgTA4FAEBAQEBAQFdJ4RcAQEEAQEBOC0HCwUHBAIBCBEEAQEBHgkHJwsUCQg?= =?us-ascii?q?CBA4FiCgIDrw+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoF4glWEQIMsgi8Fm?= =?us-ascii?q?SYBjmyBbIRZiHWQIAEeNoNzbohVAQEB?= X-IronPort-AV: E=Sophos;i="5.28,404,1464652800"; d="scan'208";a="301012776" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2016 08:12:05 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6M8C4sN009705 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jul 2016 08:12:05 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 22 Jul 2016 04:12:04 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Fri, 22 Jul 2016 04:12:04 -0400 From: "Carlos Pignataro (cpignata)" To: Gregory Mirsky Thread-Topic: [Rtg-ooam-dt] [sfc] Identifying OAM in NSH Thread-Index: AQHR4/C6G5JtD7eESEKpu32R0om68Q== Date: Fri, 22 Jul 2016 08:12:04 +0000 Message-ID: <35A00960-472E-42DF-B422-D7AC57A92880@cisco.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <20160721075801.5697618.51293.99071@sandvine.com>, <7347100B5761DC41A166AC17F22DF11221ADAAD3@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221ADAAD3@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" , Dave Dolson Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:12:08 -0000 Dear Greg, Please see inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Jul 21, 2016, at 10:49, Gregory Mirsky w= rote: >=20 > Hi Dave, > thank you for the clarification. You point to the very important issue th= at has implication onto applicability of methods that add, prepend or appen= d, OAM-specific information to a data packet. One way to address, I assume,= is to introduce Length field that equals number of octets in Next Protocol= . I believe an approach like, coupled with the other proposal, this would add= unnecessary complexity.=20 Best, -- Carlos.=20 >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com]=20 > Sent: Thursday, July 21, 2016 9:58 AM > To: Gregory Mirsky ; sfc@ietf.org > Cc: rtg-ooam-dt@ietf.org > Subject: Re: [sfc] Identifying OAM in NSH >=20 > Greg, > This answers some of the questions I had after your presentations. >=20 > However, regarding appending OAM after the packet, NSH header doesn't hav= e a length field that could indicate where the appended portion begins. > The current Length field is regarding the header size. >=20 >=20 > -Dave >=20 >=20 > From: Gregory Mirsky > Sent: Thursday, July 21, 2016 9:01 AM > To: sfc@ietf.org > Cc: rtg-ooam-dt@ietf.org > Subject: [sfc] Identifying OAM in NSH >=20 >=20 > Dear All, > we had very good discussion on OAM this week. We've touched on Active, Pa= ssive and Something-in-between OAM. But can NSH indicate which OAM type, if= any, associated with a packet? I think that the current version of draft-i= etf-sfc-nsh does not allow that and may be ambiguous in some cases. I propo= se change to interpretation and applicability description of the O(AM) flag= and allocation of the new protocol type to be used in the Next Protocol fi= eld. >=20 > RFC 7799 defines Active OAM as following: > An Active Metric or Method depends on a dedicated measurement packet stre= am and observations of the stream. > Thus, regardless of encapsulation used by OAM, it is the packet construct= ed solely for monitoring, measuring network's metric and should not leave g= iven domain. And, I believe, such packets should be identified by the proto= col type of their own. OAM which behaves as much as Passive OAM or Somethin= g-in-between, e.g. OAM appended to data packet either at the domain's edge = or on-the-fly, identified by the protocol type of the data packet carried i= n NSH. > Below are changes I'd like to propose: > Section 3.2 O-bit: > OLD > O bit: when set to 0x1 indicates that this packet is an Operations, > Administration and Maintenance (OAM) message. The receiving SFF and > SFs nodes MUST examine the payload and take appropriate action (e.g. > return status information). OAM message specifics and handling > details are outside the scope of this document. > END > NEW > O bit: when set to 0x1 indicates that data packet identified by the Next = Protocol type has OAM metadata appended. Definition of the format(s) used b= y OAM metadata is outside the scope of this document. > END >=20 > At the end of Section 3.2: > OLD > This draft defines the following Next Protocol values: >=20 > 0x1 : IPv4 > 0x2 : IPv6 > 0x3 : Ethernet > 0x4: NSH > 0x5: MPLS > 0x6-0xFD: Unassigned > 0xFE-0xFF: Experimental > END > NEW > This draft defines the following Next Protocol values: >=20 > 0x1 : IPv4 > 0x2 : IPv6 > 0x3 : Ethernet > 0x4: NSH > 0x5: MPLS > 0x6: Active OAM > 0x7-0xFD: Unassigned > 0xFE-0xFF: Experimental > END >=20 > And, consequently, section 13.2.5 in IANA Considerations section will req= uest allocation of value 0x6 to be assigned to Active OAM protocols. >=20 > Greatly appreciate your consideration and comments. >=20 > Regards, > Greg >=20 > _______________________________________________ > Rtg-ooam-dt mailing list > Rtg-ooam-dt@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-ooam-dt From nobody Fri Jul 22 01:55: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 D4D5812DAAB; Fri, 22 Jul 2016 01:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 dXWXyZCWpdLz; Fri, 22 Jul 2016 01:55:47 -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 ADD8012DA2C; Fri, 22 Jul 2016 01:55:47 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Fri, 22 Jul 2016 04:55:46 -0400 From: Dave Dolson To: "Carlos Pignataro (cpignata)" , Gregory Mirsky Thread-Topic: [Rtg-ooam-dt] [sfc] Identifying OAM in NSH Thread-Index: AQHR4yWb0Kt3ZKrawUWZ2rsvELgMRaAi1hyAgAGIHAD//8f+4A== Date: Fri, 22 Jul 2016 08:55:44 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <20160721075801.5697618.51293.99071@sandvine.com>, <7347100B5761DC41A166AC17F22DF11221ADAAD3@eusaamb103.ericsson.se> <35A00960-472E-42DF-B422-D7AC57A92880@cisco.com> In-Reply-To: <35A00960-472E-42DF-B422-D7AC57A92880@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: Cc: "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:55:50 -0000 Carlos, do you suggest so-called "piggy-back" OAM should not be provided? -----Original Message----- From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: Friday, July 22, 2016 10:12 AM To: Gregory Mirsky Cc: Dave Dolson; sfc@ietf.org; rtg-ooam-dt@ietf.org Subject: Re: [Rtg-ooam-dt] [sfc] Identifying OAM in NSH Dear Greg, Please see inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Jul 21, 2016, at 10:49, Gregory Mirsky w= rote: >=20 > Hi Dave, > thank you for the clarification. You point to the very important issue th= at has implication onto applicability of methods that add, prepend or appen= d, OAM-specific information to a data packet. One way to address, I assume,= is to introduce Length field that equals number of octets in Next Protocol= . I believe an approach like, coupled with the other proposal, this would add= unnecessary complexity.=20 Best, -- Carlos.=20 >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com]=20 > Sent: Thursday, July 21, 2016 9:58 AM > To: Gregory Mirsky ; sfc@ietf.org > Cc: rtg-ooam-dt@ietf.org > Subject: Re: [sfc] Identifying OAM in NSH >=20 > Greg, > This answers some of the questions I had after your presentations. >=20 > However, regarding appending OAM after the packet, NSH header doesn't hav= e a length field that could indicate where the appended portion begins. > The current Length field is regarding the header size. >=20 >=20 > -Dave >=20 >=20 > From: Gregory Mirsky > Sent: Thursday, July 21, 2016 9:01 AM > To: sfc@ietf.org > Cc: rtg-ooam-dt@ietf.org > Subject: [sfc] Identifying OAM in NSH >=20 >=20 > Dear All, > we had very good discussion on OAM this week. We've touched on Active, Pa= ssive and Something-in-between OAM. But can NSH indicate which OAM type, if= any, associated with a packet? I think that the current version of draft-i= etf-sfc-nsh does not allow that and may be ambiguous in some cases. I propo= se change to interpretation and applicability description of the O(AM) flag= and allocation of the new protocol type to be used in the Next Protocol fi= eld. >=20 > RFC 7799 defines Active OAM as following: > An Active Metric or Method depends on a dedicated measurement packet stre= am and observations of the stream. > Thus, regardless of encapsulation used by OAM, it is the packet construct= ed solely for monitoring, measuring network's metric and should not leave g= iven domain. And, I believe, such packets should be identified by the proto= col type of their own. OAM which behaves as much as Passive OAM or Somethin= g-in-between, e.g. OAM appended to data packet either at the domain's edge = or on-the-fly, identified by the protocol type of the data packet carried i= n NSH. > Below are changes I'd like to propose: > Section 3.2 O-bit: > OLD > O bit: when set to 0x1 indicates that this packet is an Operations, > Administration and Maintenance (OAM) message. The receiving SFF and > SFs nodes MUST examine the payload and take appropriate action (e.g. > return status information). OAM message specifics and handling > details are outside the scope of this document. > END > NEW > O bit: when set to 0x1 indicates that data packet identified by the Next = Protocol type has OAM metadata appended. Definition of the format(s) used b= y OAM metadata is outside the scope of this document. > END >=20 > At the end of Section 3.2: > OLD > This draft defines the following Next Protocol values: >=20 > 0x1 : IPv4 > 0x2 : IPv6 > 0x3 : Ethernet > 0x4: NSH > 0x5: MPLS > 0x6-0xFD: Unassigned > 0xFE-0xFF: Experimental > END > NEW > This draft defines the following Next Protocol values: >=20 > 0x1 : IPv4 > 0x2 : IPv6 > 0x3 : Ethernet > 0x4: NSH > 0x5: MPLS > 0x6: Active OAM > 0x7-0xFD: Unassigned > 0xFE-0xFF: Experimental > END >=20 > And, consequently, section 13.2.5 in IANA Considerations section will req= uest allocation of value 0x6 to be assigned to Active OAM protocols. >=20 > Greatly appreciate your consideration and comments. >=20 > Regards, > Greg >=20 > _______________________________________________ > Rtg-ooam-dt mailing list > Rtg-ooam-dt@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-ooam-dt From nobody Fri Jul 22 02:02: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 06CA012DAC1; Fri, 22 Jul 2016 02:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 cZp11e7OQIQc; Fri, 22 Jul 2016 02:02:28 -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 5858712D7D8; Fri, 22 Jul 2016 02:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5436; q=dns/txt; s=iport; t=1469178148; x=1470387748; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=28ea/zdJLk9bbCIqRMSK9iOsiFAL0ZoGALiB8msJkAw=; b=Q2tbrdbK4Np46pUFkOf/woRxAY+YxMcIQtwWYDOhYWYCp5SxRZfG5TnE uB1opA2F/Ipmk9V/CiKXHZBkfiv2BiBFQ1lnde11mbBo3kbAGD4Yz5soV 7XHej/N661GAv1qw7mYtvaPrkROFS1vWBHvXjQKRYd3WUAmKeiI+9fJFh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AgBy4JFX/4cNJK1dgz9WfLhdgXslh?= =?us-ascii?q?XcCgTA4FAEBAQEBAQFdJ4RcAQEEAQEBOC0HCwUHBAIBCA4DBAEBAR4JBycLFAk?= =?us-ascii?q?IAgQOBYgoCA68RgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqBeIJVhECDLIIvB?= =?us-ascii?q?ZNkhUIBhhWIV4FshFmIdZAgAR42g3NuiFUBAQE?= X-IronPort-AV: E=Sophos;i="5.28,404,1464652800"; d="scan'208";a="132292221" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2016 09:02:27 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6M92QYO030211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jul 2016 09:02:27 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 22 Jul 2016 05:02:26 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Fri, 22 Jul 2016 05:02:26 -0400 From: "Carlos Pignataro (cpignata)" To: Dave Dolson Thread-Topic: [Rtg-ooam-dt] [sfc] Identifying OAM in NSH Thread-Index: AQHR4/C6G5JtD7eESEKpu32R0om68aAkaNYA//++0Xo= Date: Fri, 22 Jul 2016 09:02:25 +0000 Message-ID: <1AB3F3ED-B13D-4D83-AAF2-AC47556FC206@cisco.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <20160721075801.5697618.51293.99071@sandvine.com>, <7347100B5761DC41A166AC17F22DF11221ADAAD3@eusaamb103.ericsson.se> <35A00960-472E-42DF-B422-D7AC57A92880@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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 09:02:31 -0000 Hi Dave, No, that's not what I am suggesting. On the contrary.=20 The piggy-back OAM (let's call it iOAM without expanding the "i" for now so= as to not have tangential nomenclature discussions) is being carried along= for the ride in a data packet. The packet is data, not OAM.=20 Much like I recall discussions about carrying time stamps in the MD, this p= rovides you with a more generic mechanism.=20 See https://tools.ietf.org/html/draft-brockners-inband-oam-transport-01#sec= tion-5 What I am suggesting is that for an OAM packet, not iOAM, O=3D1 and the pro= tocol field specifies the OAM protocol.=20 Thanks! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Jul 22, 2016, at 10:55, Dave Dolson wrote: >=20 > Carlos, do you suggest so-called "piggy-back" OAM should not be provided? >=20 >=20 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 > Sent: Friday, July 22, 2016 10:12 AM > To: Gregory Mirsky > Cc: Dave Dolson; sfc@ietf.org; rtg-ooam-dt@ietf.org > Subject: Re: [Rtg-ooam-dt] [sfc] Identifying OAM in NSH >=20 > Dear Greg, >=20 > Please see inline.=20 >=20 > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows >=20 >> On Jul 21, 2016, at 10:49, Gregory Mirsky = wrote: >>=20 >> Hi Dave, >> thank you for the clarification. You point to the very important issue t= hat has implication onto applicability of methods that add, prepend or appe= nd, OAM-specific information to a data packet. One way to address, I assume= , is to introduce Length field that equals number of octets in Next Protoco= l. >=20 > I believe an approach like, coupled with the other proposal, this would a= dd unnecessary complexity.=20 >=20 > Best, >=20 > -- Carlos.=20 >=20 >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com]=20 >> Sent: Thursday, July 21, 2016 9:58 AM >> To: Gregory Mirsky ; sfc@ietf.org >> Cc: rtg-ooam-dt@ietf.org >> Subject: Re: [sfc] Identifying OAM in NSH >>=20 >> Greg, >> This answers some of the questions I had after your presentations. >>=20 >> However, regarding appending OAM after the packet, NSH header doesn't ha= ve a length field that could indicate where the appended portion begins. >> The current Length field is regarding the header size. >>=20 >>=20 >> -Dave >>=20 >>=20 >> From: Gregory Mirsky >> Sent: Thursday, July 21, 2016 9:01 AM >> To: sfc@ietf.org >> Cc: rtg-ooam-dt@ietf.org >> Subject: [sfc] Identifying OAM in NSH >>=20 >>=20 >> Dear All, >> we had very good discussion on OAM this week. We've touched on Active, P= assive and Something-in-between OAM. But can NSH indicate which OAM type, i= f any, associated with a packet? I think that the current version of draft-= ietf-sfc-nsh does not allow that and may be ambiguous in some cases. I prop= ose change to interpretation and applicability description of the O(AM) fla= g and allocation of the new protocol type to be used in the Next Protocol f= ield. >>=20 >> RFC 7799 defines Active OAM as following: >> An Active Metric or Method depends on a dedicated measurement packet str= eam and observations of the stream. >> Thus, regardless of encapsulation used by OAM, it is the packet construc= ted solely for monitoring, measuring network's metric and should not leave = given domain. And, I believe, such packets should be identified by the prot= ocol type of their own. OAM which behaves as much as Passive OAM or Somethi= ng-in-between, e.g. OAM appended to data packet either at the domain's edge= or on-the-fly, identified by the protocol type of the data packet carried = in NSH. >> Below are changes I'd like to propose: >> Section 3.2 O-bit: >> OLD >> O bit: when set to 0x1 indicates that this packet is an Operations, >> Administration and Maintenance (OAM) message. The receiving SFF and >> SFs nodes MUST examine the payload and take appropriate action (e.g. >> return status information). OAM message specifics and handling >> details are outside the scope of this document. >> END >> NEW >> O bit: when set to 0x1 indicates that data packet identified by the Next= Protocol type has OAM metadata appended. Definition of the format(s) used = by OAM metadata is outside the scope of this document. >> END >>=20 >> At the end of Section 3.2: >> OLD >> This draft defines the following Next Protocol values: >>=20 >> 0x1 : IPv4 >> 0x2 : IPv6 >> 0x3 : Ethernet >> 0x4: NSH >> 0x5: MPLS >> 0x6-0xFD: Unassigned >> 0xFE-0xFF: Experimental >> END >> NEW >> This draft defines the following Next Protocol values: >>=20 >> 0x1 : IPv4 >> 0x2 : IPv6 >> 0x3 : Ethernet >> 0x4: NSH >> 0x5: MPLS >> 0x6: Active OAM >> 0x7-0xFD: Unassigned >> 0xFE-0xFF: Experimental >> END >>=20 >> And, consequently, section 13.2.5 in IANA Considerations section will re= quest allocation of value 0x6 to be assigned to Active OAM protocols. >>=20 >> Greatly appreciate your consideration and comments. >>=20 >> Regards, >> Greg >>=20 >> _______________________________________________ >> Rtg-ooam-dt mailing list >> Rtg-ooam-dt@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt From nobody Fri Jul 22 02: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 6ABC312DC22; Fri, 22 Jul 2016 02:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv_vjXohwB57; Fri, 22 Jul 2016 02:24:37 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D86412DB9F; Fri, 22 Jul 2016 02:24:37 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-3c-5791daf03d7b Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id E0.13.09012.0FAD1975; Fri, 22 Jul 2016 10:36:01 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Fri, 22 Jul 2016 05:24:36 -0400 From: Gregory Mirsky To: "Carlos Pignataro (cpignata)" Thread-Topic: [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AdHjGxqUb41VTqTfTwmZE/bgRl5mHQA9utSAAAZMKgA= Date: Fri, 22 Jul 2016 09:24:35 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> In-Reply-To: <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221ADBCA5eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXRPoO7HWxPDDS6fELL49G4Hi8W/1r2s Fk8ebGV3YPaY8nsjq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDK2fwwruPebseLR9qXsDYwTvjJ2 MXJySAiYSEx8+p8VwhaTuHBvPVsXIxeHkMBRRolHTUfZQBJCAssZJb6uDQWx2QSMJF5s7GEH sUUEzCQaH09iArGZBYIk9q64AmYLCxhKLPs5hRWixkhi+98pjBC2lcSaV3NYQGwWAVWJnS0b wWp4BXwl5q84wwKxuIFR4uXfOcxdjBwcnAK2EvseGIPUMAId9/3UGqhd4hK3nsxngjhaQGLJ nvPMELaoxMvH/6CeUZKYtPQcK0R9vsS0f18YIXYJSpyc+YRlAqPoLCSjZiEpm4WkbBbQFcwC mhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FSNHaXFBTm66kcEmRmB8HZNg093BeH+65yFG AQ5GJR7eBbwTw4VYE8uKK3MPMUpwMCuJ8No/BArxpiRWVqUW5ccXleakFh9ilOZgURLnFXuk GC4kkJ5YkpqdmlqQWgSTZeLglGpgjLdu9Vl06rBtQu9GsfPLz9rskf69uP5ldNyXe2/Lj2/4 dKXKWFHS25n3b8fUZwtM2HZWnX6u+vpN2//bT9aeXFRxYFMgz8pmj2dHzk+zSCzJUr+67eKX 8uwIb7/TagJbO57GHU2y/pzYbRHx71BBp+j7osznM5n0YwLFnk9Zrr84a3vR/e7UZCWW4oxE Qy3mouJEAF8C1ZmrAgAA Archived-At: Cc: "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 09:24:40 -0000 --_000_7347100B5761DC41A166AC17F22DF11221ADBCA5eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KdGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIgY29tbWVudHMuIElmIEkgdW5k ZXJzdGFuZCBjb3JyZWN0bHksIHlvdSBzdWdnZXN0IHRvIGV4cG9zZSBwcm90b2NvbCB0eXBlcyBv ZiBPQU0gYXMgTmV4dCBQcm90b2NvbCByYXRoZXIgdGhhbiB0byB1c2Ugc2luZ2xlIEFjdGl2ZSBP QU0gcHJvdG9jb2wgdHlwZSBhbmQgdXNlIE9PQU0gSGVhZGVyIHRvIGRlbXV4IE9PQU0gdHlwZS4g VGhlbiwgdGhlIE5leHQgUHJvdG9jb2wgcmVnaXN0cnkgd2lsbCBoYXZlIHRvIGFsbG9jYXRlIHZh bHVlcyBmb3Igc2luZ2xlLWhvcCBCRkQsIG11bHRpLWhvcCBCRkQsIG11bHRpcG9pbnQgQkZELCBT LUJGRCwgRWNobyBSZXF1ZXN0L1JlcGx5LCBBSVMgcHJvdG9jb2wsIEFjdGl2ZSBQZXJmb3JtYW5j ZSBNZWFzdXJlbWVudCBwcm90b2NvbCwgYW5kIEnigJl2ZSBvbmx5IGxpc3RlZCBzb21lIG9mIEFP TSBwcm90b2NvbHMgdGhhdCBtYXkgYmUgdXNlZCB0byBvcGVyYXRlLCBhZG1pbmlzdGVyIGFuZCBt YWludGFpbiBTRlAuDQpBZGRpdGlvbmFsbHksIHlvdeKAmXZlIHN1Z2dlc3RlZCB0aGF0IG9ubHkg Ty1iaXQgdmFsdWUgdG8gYmUgdXNlZCB0byBkZXRlcm1pbmUgd2hldGhlciBwYWNrZXQgc2hvdWxk IGJlIHByb2Nlc3NlZCBhcyBPQU0gb3IgZGF0YSBwYWNrZXQuIEhlbmNlIHNob3VsZCBJIGV4cGVj dCB0aGF0IE8tYml0IGlzIHNldCBmb3IgQkZELCBBSVMsIGFuZCBFY2hvIFJlcXVlc3QvUmVwbHkg cGF5bG9hZCBhbmQgc2hvdWxkIG5vdCBiZSBzZXQgaWYgdGhlIE5leHQgUHJvdG9jb2wgaXMgbmVp dGhlciBvZiBwcm90b2NvbHMgbGlzdGVkIGFib3ZlPyBTaG91bGQgc3VjaCBzaXR1YXRpb24sIGku ZS4gTmV4dCBQcm90b2NvbCB2YWx1ZSBpcyBNUExTIGFuZCBPLWJpdCBzZXQgdG8gMHgxLCBzaG91 bGQgYmUgdmlld2VkIGFzIGVycm9yIGFuZCB0aGUgcGFja2V0IGRyb3BwZWQ/IE9yIHlvdSBwcm9w b3NlIHRoYXQgdGhlIE5leHQgUHJvdG9jb2wgdGFrZXMgcHJlY2VkZW5jZSBhbmQgdGhlIHBhY2tl dCB0cmVhdGVkIGFzIGRhdGE/IE9yIHBhY2tldCB2aWV3ZWQgYXMgT0FNIGFuZCBwYXNzZWQgdG8g dGhlIGxvY2FsIE9BTSBlbnRpdHk/IE9yIGhvdyB0byBpbnRlcnByZXQgc2l0dWF0aW9uIHdoZW4g Ty1iaXQgaXMgY2xlYXJlZCBhbmQgdGhlIE5leHQgUHJvdG9jb2wgdmFsdWUgaXMgb25lIG9mIE9B TSBwcm90b2NvbHM/IFRoaXMgaXMgdGhlIHNpdHVhdGlvbiB0aGF0LCBpbiBteSB2aWV3LCBpcyBh bWJpZ3VvdXMgYW5kIHVuZGVyLXNwZWNpZmllZCBpbiB0aGUgY3VycmVudCBOU0ggZG9jdW1lbnQu IE15IHByb3Bvc2FsIGlzIGFuIGF0dGVtcHQgdG8gbWFrZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBP QU0gYW5kIGRhdGEgcGFja2V0cyBtb3JlIGRldGVybWluaXN0aWMuDQoNCiAgICAgICAgICAgICAg ICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206 IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0N ClNlbnQ6IEZyaWRheSwgSnVseSAyMiwgMjAxNiAxMDoxMCBBTQ0KVG86IEdyZWdvcnkgTWlyc2t5 IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+DQpDYzogc2ZjQGlldGYub3JnOyBydGctb29h bS1kdEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtSdGctb29hbS1kdF0gSWRlbnRpZnlpbmcgT0FN IGluIE5TSA0KDQpHcmVnLA0KDQpQbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGlubGluZS4NClRo dW1iIHR5cGVkIGJ5IENhcmxvcyBQaWduYXRhcm8uDQpFeGN1emUgdHlwb2ZyYXBoaWNhayBlcnJv d3MNCg0KT24gSnVsIDIxLCAyMDE2LCBhdCAwOTowMSwgR3JlZ29yeSBNaXJza3kgPGdyZWdvcnku bWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4g d3JvdGU6DQpEZWFyIEFsbCwNCndlIGhhZCB2ZXJ5IGdvb2QgZGlzY3Vzc2lvbiBvbiBPQU0gdGhp cyB3ZWVrLiBXZeKAmXZlIHRvdWNoZWQgb24gQWN0aXZlLCBQYXNzaXZlIGFuZCBTb21ldGhpbmct aW4tYmV0d2VlbiBPQU0uIEJ1dCBjYW4gTlNIIGluZGljYXRlIHdoaWNoIE9BTSB0eXBlLCBpZiBh bnksIGFzc29jaWF0ZWQgd2l0aCBhIHBhY2tldD8gSSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHZl cnNpb24gb2YgZHJhZnQtaWV0Zi1zZmMtbnNoIGRvZXMgbm90IGFsbG93IHRoYXQgYW5kIG1heSBi ZSBhbWJpZ3VvdXMgaW4gc29tZSBjYXNlcy4gSSBwcm9wb3NlIGNoYW5nZSB0byBpbnRlcnByZXRh dGlvbiBhbmQgYXBwbGljYWJpbGl0eSBkZXNjcmlwdGlvbiBvZiB0aGUgTyhBTSkgZmxhZyBhbmQg YWxsb2NhdGlvbiBvZiB0aGUgbmV3IHByb3RvY29sIHR5cGUgdG8gYmUgdXNlZCBpbiB0aGUgTmV4 dCBQcm90b2NvbCBmaWVsZC4NCg0KDQpBY3RpdmUsIHBhc3NpdmUgYW5kIHNvbWV0aGluZy1pbi1i ZXR3ZWVuIGFyZSBub3QgT0FNIHByb3RvY29sIHR5cGVzIGJ1dCByYXRoZXIgdGhleSBhcmUgbWVh c3VyaW5nIG1ldGhvZHMuIEFjdGl2ZSBPQU0gY2FuIGluY2x1ZGUgYSBwbHVyYWxpdHkgb2YgT0FN IHByb3RvY29scywgaW5jbHVkaW5nIEJGRCwgUy1CRkQsIHNvbWV0aGluZy1vdmVyLWlwLCBldGMu DQoNCkkgYWxzbyBiZWxpZXZlIHRoYXQgdGhlIGN1cnJlbnQgT0FNIHRleHQgaW4gTlNIIGlzIG5v dCBhbWJpZ3VvdXMgYW5kIGFsbG93cyBlbm91Z2ggcHJvY2Vzc2luZyBvZiB0aGUgaGVhZGVyIHRv IHVuZGVyc3RhbmQgc29tZXRoaW5nIGlzIE9BTSwgd2l0aG91dCBnb2luZyB0aGUgc3BlY2lmaWNz IG9mIGFuIE9BTSBoYW5kbGVyLg0KDQpUaGVyZWZvcmUsIEkgb3Bwb3NlIHRoaXMgY2hhbmdlLg0K DQoNClJGQyA3Nzk5IGRlZmluZXMgQWN0aXZlIE9BTSBhcyBmb2xsb3dpbmc6DQpBbiBBY3RpdmUg TWV0cmljIG9yIE1ldGhvZCBkZXBlbmRzIG9uIGEgZGVkaWNhdGVkIG1lYXN1cmVtZW50IHBhY2tl dCBzdHJlYW0gYW5kIG9ic2VydmF0aW9ucyBvZiB0aGUgc3RyZWFtLg0KVGh1cywgcmVnYXJkbGVz cyBvZiBlbmNhcHN1bGF0aW9uIHVzZWQgYnkgT0FNLCBpdCBpcyB0aGUgcGFja2V0IGNvbnN0cnVj dGVkIHNvbGVseSBmb3IgbW9uaXRvcmluZywgbWVhc3VyaW5nIG5ldHdvcmvigJlzIG1ldHJpYyBh bmQgc2hvdWxkIG5vdCBsZWF2ZSBnaXZlbiBkb21haW4uIEFuZCwgSSBiZWxpZXZlLCBzdWNoIHBh Y2tldHMgc2hvdWxkIGJlIGlkZW50aWZpZWQgYnkgdGhlIHByb3RvY29sIHR5cGUgb2YgdGhlaXIg b3duLg0KDQpTZWVtcyB5b3UgYXJlIGFkdm9jYXRpbmcgZm9yIGEgc2luZ2xlICJPQU0iIHByb3Rv Y29sIHR5cGUgZm9yIE9BTSBwYWNrZXRzLiBUaGUgZnVuY3Rpb25hbGl0eSBvZiBpZGVudGlmeWlu ZyBzb21ldGhpbmcgYXMgT0FNIGlzIGluIHRoZSBPLWJpdCwgc28gbm8gbmVlZCB0byB3YXN0ZSBi aXRzIGluIGR1cGxpY2F0aW9uLg0KDQpUaGVuLCBhdCBzb21lIHBvaW50LCB5b3UgaGF2ZSB0byBk aWZmZXJlbnRpYXRlIGlmIGFuIE9BTSBpcywgc2F5LCBJUCBvciAicmF3IEJGRCIgb3Igc29tZXRo aW5nIGVsc2UuIFRoYXQncyB3aGF0IHRoZSBQcm90b2NvbCBmaWVsZCBpcyBmb3IuIEkgZG8gbm90 IHNlZSBhIG5lZWQgdG8gYWRkIGFuIGluZGlyZWN0aW9uIGhlcmUgdG8gdGhlbiBoYXZlIHRvIGhh dmUgYSBwcm90b2NvbCBmaWVsZCBpbnNpZGUgdGhlIE9BTS4NCg0KDQpPQU0gd2hpY2ggYmVoYXZl cyBhcyBtdWNoIGFzIFBhc3NpdmUgT0FNIG9yIFNvbWV0aGluZy1pbi1iZXR3ZWVuLCBlLmcuIE9B TSBhcHBlbmRlZCB0byBkYXRhIHBhY2tldCBlaXRoZXIgYXQgdGhlIGRvbWFpbuKAmXMgZWRnZSBv ciBvbi10aGUtZmx5LCBpZGVudGlmaWVkIGJ5IHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBkYXRh IHBhY2tldCBjYXJyaWVkIGluIE5TSC4NCg0KVGhhdCdzIGNvcnJlY3QsIHdpdGggdGhlIE8gYml0 IGNsZWFyZWQ7IGl0J3MgYSBkYXRhIHBhY2tldCBhbmQgbm90IGFuIE9BTSBvbmUuDQoNCg0KQmVs b3cgYXJlIGNoYW5nZXMgSeKAmWQgbGlrZSB0byBwcm9wb3NlOg0KU2VjdGlvbiAzLjIgTy1iaXQ6 DQpPTEQNCiAgIE8gYml0OiB3aGVuIHNldCB0byAweDEgaW5kaWNhdGVzIHRoYXQgdGhpcyBwYWNr ZXQgaXMgYW4gT3BlcmF0aW9ucywNCiAgIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAo T0FNKSBtZXNzYWdlLiAgVGhlIHJlY2VpdmluZyBTRkYgYW5kDQogICBTRnMgbm9kZXMgTVVTVCBl eGFtaW5lIHRoZSBwYXlsb2FkIGFuZCB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbiAoZS5nLg0KICAg cmV0dXJuIHN0YXR1cyBpbmZvcm1hdGlvbikuICBPQU0gbWVzc2FnZSBzcGVjaWZpY3MgYW5kIGhh bmRsaW5nDQogICBkZXRhaWxzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50 Lg0KRU5EDQpORVcNCk8gYml0OiB3aGVuIHNldCB0byAweDEgaW5kaWNhdGVzIHRoYXQgZGF0YSBw YWNrZXQgaWRlbnRpZmllZCBieSB0aGUgTmV4dA0KUHJvdG9jb2wgdHlwZSBoYXMgT0FNIG1ldGFk YXRhIGFwcGVuZGVkLg0KDQpOby4gSWYgaXQgaXMgYSBkYXRhIHBhY2tldCBpdCBkb2VzIG5vdCBo YXZlIHRoZSBPIGJpdCBzZXQgKHRvIDEgb3IgdG8gd2hpY2hldmVyIG90aGVyIHBvc3NpYmxlIHZh bHVlIGZvciB0aGUgYml0IDotKQ0KDQpUaGUgZ29hbCBpcyB0aGF0IGxvb2tpbmcgYXQgYSBzaW5n bGUgYnV0IGl0IGNhbiBiZSB1bmRlcnN0b29kIGlmIGl0IGlzIGEgZGF0YSBwYWNrZXQgKHdoaWNo IGNhbiBiZSB1c2VkLCBtYXJrZWQsIGV0Yy4gdG8gYmUgdXNlZCBmb3IgT0FNIHB1cnBvc2VzLCBv ciBub3QpLg0KDQpXZSBkbyBub3Qgd2FudCBPQU0gZGlyZWN0IGV4Y2VwdGlvbiBwcm9jZXNzaW5n IGZvciBkYXRhIHBhY2tldHMuDQoNCg0KRGVmaW5pdGlvbiBvZiB0aGUgZm9ybWF0KHMpDQp1c2Vk IGJ5IE9BTSBtZXRhZGF0YSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0K RU5EDQoNCkF0IHRoZSBlbmQgb2YgU2VjdGlvbiAzLjI6DQpPTEQNCiAgIFRoaXMgZHJhZnQgZGVm aW5lcyB0aGUgZm9sbG93aW5nIE5leHQgUHJvdG9jb2wgdmFsdWVzOg0KDQogICAweDEgOiBJUHY0 DQogICAweDIgOiBJUHY2DQogICAweDMgOiBFdGhlcm5ldA0KICAgMHg0OiBOU0gNCiAgIDB4NTog TVBMUw0KICAgMHg2LTB4RkQ6IFVuYXNzaWduZWQNCiAgIDB4RkUtMHhGRjogRXhwZXJpbWVudGFs DQpFTkQNCk5FVw0KICAgVGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgTmV4dCBQcm90 b2NvbCB2YWx1ZXM6DQoNCiAgIDB4MSA6IElQdjQNCiAgIDB4MiA6IElQdjYNCiAgIDB4MyA6IEV0 aGVybmV0DQogICAweDQ6IE5TSA0KICAgMHg1OiBNUExTDQogICAweDY6IEFjdGl2ZSBPQU0NCg0K QXMgcGVyIGFib3ZlIEkgZG8gbm90IGJlbGlldmUgdGhlcmUncyBhIHNpbmdsZSBPQU0gcHJvdG9j b2wuDQoNCg0KICAgMHg3LTB4RkQ6IFVuYXNzaWduZWQNCiAgIDB4RkUtMHhGRjogRXhwZXJpbWVu dGFsDQpFTkQNCg0KQW5kLCBjb25zZXF1ZW50bHksIHNlY3Rpb24gMTMuMi41IGluIElBTkEgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbiB3aWxsIHJlcXVlc3QgYWxsb2NhdGlvbiBvZiB2YWx1ZSAweDYg dG8gYmUgYXNzaWduZWQgdG8gQWN0aXZlIE9BTSBwcm90b2NvbHMuDQoNCkdyZWF0bHkgYXBwcmVj aWF0ZSB5b3VyIGNvbnNpZGVyYXRpb24gYW5kIGNvbW1lbnRzLg0KDQoNCk15IOKCrDAuMDIuDQoN ClRoYW5rcywNCg0KQ2FybG9zLg0KDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpSdGctb29hbS1kdCBtYWlsaW5nIGxpc3QNClJ0Zy1v b2FtLWR0QGlldGYub3JnPG1haWx0bzpSdGctb29hbS1kdEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLW9vYW0tZHQNCg== --_000_7347100B5761DC41A166AC17F22DF11221ADBCA5eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bh bg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQ2FybG9zLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIgY29t bWVudHMuIElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHlvdSBzdWdnZXN0IHRvIGV4cG9zZSBw cm90b2NvbCB0eXBlcyBvZiBPQU0gYXMgTmV4dCBQcm90b2NvbCByYXRoZXIgdGhhbiB0byB1c2Ug c2luZ2xlIEFjdGl2ZSBPQU0gcHJvdG9jb2wgdHlwZSBhbmQgdXNlIE9PQU0gSGVhZGVyIHRvIGRl bXV4IE9PQU0gdHlwZS4gVGhlbiwgdGhlIE5leHQgUHJvdG9jb2wNCiByZWdpc3RyeSB3aWxsIGhh dmUgdG8gYWxsb2NhdGUgdmFsdWVzIGZvciBzaW5nbGUtaG9wIEJGRCwgbXVsdGktaG9wIEJGRCwg bXVsdGlwb2ludCBCRkQsIFMtQkZELCBFY2hvIFJlcXVlc3QvUmVwbHksIEFJUyBwcm90b2NvbCwg QWN0aXZlIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IHByb3RvY29sLCBhbmQgSeKAmXZlIG9ubHkg bGlzdGVkIHNvbWUgb2YgQU9NIHByb3RvY29scyB0aGF0IG1heSBiZSB1c2VkIHRvIG9wZXJhdGUs IGFkbWluaXN0ZXIgYW5kDQogbWFpbnRhaW4gU0ZQLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QWRkaXRpb25hbGx5LCB5b3XigJl2ZSBzdWdnZXN0ZWQgdGhhdCBvbmx5IE8t Yml0IHZhbHVlIHRvIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgcGFja2V0IHNob3VsZCBi ZSBwcm9jZXNzZWQgYXMgT0FNIG9yIGRhdGEgcGFja2V0LiBIZW5jZSBzaG91bGQgSSBleHBlY3Qg dGhhdCBPLWJpdCBpcyBzZXQgZm9yIEJGRCwgQUlTLCBhbmQgRWNobyBSZXF1ZXN0L1JlcGx5IHBh eWxvYWQgYW5kIHNob3VsZCBub3QgYmUNCiBzZXQgaWYgdGhlIE5leHQgUHJvdG9jb2wgaXMgbmVp dGhlciBvZiBwcm90b2NvbHMgbGlzdGVkIGFib3ZlPyBTaG91bGQgc3VjaCBzaXR1YXRpb24sIGku ZS4gTmV4dCBQcm90b2NvbCB2YWx1ZSBpcyBNUExTIGFuZCBPLWJpdCBzZXQgdG8gMHgxLCBzaG91 bGQgYmUgdmlld2VkIGFzIGVycm9yIGFuZCB0aGUgcGFja2V0IGRyb3BwZWQ/IE9yIHlvdSBwcm9w b3NlIHRoYXQgdGhlIE5leHQgUHJvdG9jb2wgdGFrZXMgcHJlY2VkZW5jZSBhbmQgdGhlIHBhY2tl dA0KIHRyZWF0ZWQgYXMgZGF0YT8gT3IgcGFja2V0IHZpZXdlZCBhcyBPQU0gYW5kIHBhc3NlZCB0 byB0aGUgbG9jYWwgT0FNIGVudGl0eT8gT3IgaG93IHRvIGludGVycHJldCBzaXR1YXRpb24gd2hl biBPLWJpdCBpcyBjbGVhcmVkIGFuZCB0aGUgTmV4dCBQcm90b2NvbCB2YWx1ZSBpcyBvbmUgb2Yg T0FNIHByb3RvY29scz8gVGhpcyBpcyB0aGUgc2l0dWF0aW9uIHRoYXQsIGluIG15IHZpZXcsIGlz IGFtYmlndW91cyBhbmQgdW5kZXItc3BlY2lmaWVkIGluDQogdGhlIGN1cnJlbnQgTlNIIGRvY3Vt ZW50LiBNeSBwcm9wb3NhbCBpcyBhbiBhdHRlbXB0IHRvIG1ha2UgcmVsYXRpb25zaGlwIGJldHdl ZW4gT0FNIGFuZCBkYXRhIHBhY2tldHMgbW9yZSBkZXRlcm1pbmlzdGljLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFA Y2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAyMiwgMjAxNiAxMDox MCBBTTxicj4NCjxiPlRvOjwvYj4gR3JlZ29yeSBNaXJza3kgJmx0O2dyZWdvcnkubWlyc2t5QGVy aWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHNmY0BpZXRmLm9yZzsgcnRnLW9vYW0tZHRA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSdGctb29hbS1kdF0gSWRlbnRpZnlp bmcgT0FNIGluIE5TSDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkdyZWcsPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5QbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGlubGluZS4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+VGh1bWIgdHlwZWQgYnkgQ2FybG9zIFBpZ25hdGFyby48L3NwYW4+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0iYXBwbGUtc3R5bGUtc3BhbiI+RXhjdXplIHR5cG9mcmFwaGljYWsgZXJyb3dzPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDIxLCAy MDE2LCBhdCAwOTowMSwgR3JlZ29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5 Lm1pcnNreUBlcmljc3Nvbi5jb20iPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5EZWFyIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndlIGhh ZCB2ZXJ5IGdvb2QgZGlzY3Vzc2lvbiBvbiBPQU0gdGhpcyB3ZWVrLiBXZeKAmXZlIHRvdWNoZWQg b24gQWN0aXZlLCBQYXNzaXZlIGFuZCBTb21ldGhpbmctaW4tYmV0d2VlbiBPQU0uIEJ1dCBjYW4g TlNIIGluZGljYXRlIHdoaWNoIE9BTSB0eXBlLCBpZiBhbnksIGFzc29jaWF0ZWQgd2l0aCBhIHBh Y2tldD8gSSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1zZmMt bnNoIGRvZXMNCiBub3QgYWxsb3cgdGhhdCBhbmQgbWF5IGJlIGFtYmlndW91cyBpbiBzb21lIGNh c2VzLiBJIHByb3Bvc2UgY2hhbmdlIHRvIGludGVycHJldGF0aW9uIGFuZCBhcHBsaWNhYmlsaXR5 IGRlc2NyaXB0aW9uIG9mIHRoZSBPKEFNKSBmbGFnIGFuZCBhbGxvY2F0aW9uIG9mIHRoZSBuZXcg cHJvdG9jb2wgdHlwZSB0byBiZSB1c2VkIGluIHRoZSBOZXh0IFByb3RvY29sIGZpZWxkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QWN0aXZlLCBwYXNzaXZl IGFuZCBzb21ldGhpbmctaW4tYmV0d2VlbiBhcmUgbm90IE9BTSBwcm90b2NvbCB0eXBlcyBidXQg cmF0aGVyIHRoZXkgYXJlIG1lYXN1cmluZyBtZXRob2RzLiBBY3RpdmUgT0FNIGNhbiBpbmNsdWRl IGEgcGx1cmFsaXR5IG9mIE9BTSBwcm90b2NvbHMsIGluY2x1ZGluZw0KIEJGRCwgUy1CRkQsIHNv bWV0aGluZy1vdmVyLWlwLCBldGMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPkkgYWxzbyBiZWxpZXZlIHRoYXQgdGhlIGN1cnJlbnQgT0FN IHRleHQgaW4gTlNIIGlzIG5vdCBhbWJpZ3VvdXMgYW5kIGFsbG93cyBlbm91Z2ggcHJvY2Vzc2lu ZyBvZiB0aGUgaGVhZGVyIHRvIHVuZGVyc3RhbmQgc29tZXRoaW5nIGlzIE9BTSwgd2l0aG91dCBn b2luZyB0aGUgc3BlY2lmaWNzIG9mDQogYW4gT0FNIGhhbmRsZXIuJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlRoZXJlZm9yZSwgSSBvcHBv c2UgdGhpcyBjaGFuZ2UuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQyA3Nzk5IGRl ZmluZXMgQWN0aXZlIE9BTSBhcyBmb2xsb3dpbmc6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW4gQWN0aXZlIE1ldHJpYyBvciBN ZXRob2QgZGVwZW5kcyBvbiBhIGRlZGljYXRlZCBtZWFzdXJlbWVudCBwYWNrZXQgc3RyZWFtIGFu ZCBvYnNlcnZhdGlvbnMgb2YgdGhlIHN0cmVhbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRodXMsIHJlZ2FyZGxlc3Mgb2YgZW5jYXBzdWxhdGlvbiB1c2VkIGJ5IE9BTSwg aXQgaXMgdGhlIHBhY2tldCBjb25zdHJ1Y3RlZCBzb2xlbHkgZm9yIG1vbml0b3JpbmcsIG1lYXN1 cmluZyBuZXR3b3Jr4oCZcyBtZXRyaWMgYW5kIHNob3VsZCBub3QgbGVhdmUgZ2l2ZW4gZG9tYWlu LiBBbmQsIEkgYmVsaWV2ZSwgc3VjaCBwYWNrZXRzIHNob3VsZCBiZSBpZGVudGlmaWVkIGJ5IHRo ZSBwcm90b2NvbCB0eXBlIG9mIHRoZWlyDQogb3duLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5TZWVtcyB5b3UgYXJlIGFkdm9jYXRp bmcgZm9yIGEgc2luZ2xlICZxdW90O09BTSZxdW90OyBwcm90b2NvbCB0eXBlIGZvciBPQU0gcGFj a2V0cy4gVGhlIGZ1bmN0aW9uYWxpdHkgb2YgaWRlbnRpZnlpbmcgc29tZXRoaW5nIGFzIE9BTSBp cyBpbiB0aGUgTy1iaXQsIHNvIG5vIG5lZWQgdG8gd2FzdGUgYml0cyBpbg0KIGR1cGxpY2F0aW9u LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij5UaGVuLCBhdCBzb21lIHBvaW50LCB5b3UgaGF2ZSB0byBkaWZmZXJlbnRpYXRlIGlmIGFuIE9B TSBpcywgc2F5LCBJUCBvciAmcXVvdDtyYXcgQkZEJnF1b3Q7IG9yIHNvbWV0aGluZyBlbHNlLiBU aGF0J3Mgd2hhdCB0aGUgUHJvdG9jb2wgZmllbGQgaXMgZm9yLiBJIGRvIG5vdCBzZWUgYSBuZWVk IHRvIGFkZCBhbg0KIGluZGlyZWN0aW9uIGhlcmUgdG8gdGhlbiBoYXZlIHRvIGhhdmUgYSBwcm90 b2NvbCBmaWVsZCBpbnNpZGUgdGhlIE9BTS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T0FNIHdoaWNoIGJlaGF2ZXMgYXMgbXVjaCBhcyBQYXNzaXZlIE9BTSBvciBTb21ldGhpbmctaW4t YmV0d2VlbiwgZS5nLiBPQU0gYXBwZW5kZWQgdG8gZGF0YSBwYWNrZXQgZWl0aGVyIGF0IHRoZSBk b21haW7igJlzIGVkZ2Ugb3Igb24tdGhlLWZseSwgaWRlbnRpZmllZCBieSB0aGUgcHJvdG9jb2wg dHlwZSBvZiB0aGUgZGF0YSBwYWNrZXQgY2FycmllZCBpbiBOU0guPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5UaGF0J3MgY29ycmVjdCwgd2l0aCB0 aGUgTyBiaXQgY2xlYXJlZDsgaXQncyBhIGRhdGEgcGFja2V0IGFuZCBub3QgYW4gT0FNIG9uZS4m bmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlbG93IGFyZSBjaGFuZ2VzIEnigJlkIGxp a2UgdG8gcHJvcG9zZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rp b24gMy4yIE8tYml0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0xEPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgTyBiaXQ6IHdo ZW4gc2V0IHRvIDB4MSBpbmRpY2F0ZXMgdGhhdCB0aGlzIHBhY2tldCBpcyBhbiBPcGVyYXRpb25z LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IEFkbWlu aXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKSBtZXNzYWdlLiZuYnNwOyBUaGUgcmVjZWl2 aW5nIFNGRiBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyBTRnMgbm9kZXMgTVVTVCBleGFtaW5lIHRoZSBwYXlsb2FkIGFuZCB0YWtlIGFwcHJvcHJp YXRlIGFjdGlvbiAoZS5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7IHJldHVybiBzdGF0dXMgaW5mb3JtYXRpb24pLiZuYnNwOyBPQU0gbWVzc2FnZSBz cGVjaWZpY3MgYW5kIGhhbmRsaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgZGV0YWlscyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1ib3R0 b206c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMS4wcHQgMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkVORDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ORVc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk8gYml0 OiB3aGVuIHNldCB0byAweDEgaW5kaWNhdGVzIHRoYXQgZGF0YSBwYWNrZXQgaWRlbnRpZmllZCBi eSB0aGUgTmV4dA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcm90b2Nv bCB0eXBlIGhhcyBPQU0gbWV0YWRhdGEgYXBwZW5kZWQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPk5vLiBJZiBpdCBpcyBhIGRhdGEg cGFja2V0IGl0IGRvZXMgbm90IGhhdmUgdGhlIE8gYml0IHNldCAodG8gMSBvciB0byB3aGljaGV2 ZXIgb3RoZXIgcG9zc2libGUgdmFsdWUgZm9yIHRoZSBiaXQgOi0pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlRoZSBnb2FsIGlzIHRoYXQgbG9va2lu ZyBhdCBhIHNpbmdsZSBidXQgaXQgY2FuIGJlIHVuZGVyc3Rvb2QgaWYgaXQgaXMgYSBkYXRhIHBh Y2tldCAod2hpY2ggY2FuIGJlIHVzZWQsIG1hcmtlZCwgZXRjLiB0byBiZSB1c2VkIGZvciBPQU0g cHVycG9zZXMsIG9yIG5vdCkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPldlIGRvIG5vdCB3YW50IE9BTSBkaXJlY3QgZXhjZXB0aW9uIHBy b2Nlc3NpbmcgZm9yIGRhdGEgcGFja2V0cy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RGVmaW5pdGlvbiBvZiB0aGUgZm9ybWF0KHMpIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+dXNlZCBieSBPQU0gbWV0YWRhdGEgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVORDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGUgZW5kIG9mIFNlY3Rpb24gMy4yOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0xEPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgVGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcg TmV4dCBQcm90b2NvbCB2YWx1ZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyAweDEgOiBJUHY0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgMHgyIDogSVB2NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7IDB4MyA6IEV0aGVybmV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgMHg0OiBOU0g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyAweDU6IE1QTFM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAweDYtMHhGRDogVW5hc3NpZ25lZDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IDB4RkUtMHhGRjogRXhwZXJpbWVu dGFsPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItYm90dG9t OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDEuMHB0IDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5FTkQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TkVXPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgVGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgTmV4dCBQcm90b2NvbCB2YWx1 ZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAweDEgOiBJUHY0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgMHgyIDogSVB2Njxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IDB4MyA6IEV0 aGVybmV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg MHg0OiBOU0g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyAweDU6IE1QTFM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyAweDY6IEFjdGl2ZSBPQU08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPkFzIHBlciBhYm92ZSBJIGRvIG5vdCBiZWxpZXZlIHRoZXJlJ3MgYSBz aW5nbGUgT0FNIHByb3RvY29sLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7IDB4Ny0weEZEOiBVbmFzc2lnbmVkPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgMHhGRS0weEZGOiBFeHBlcmltZW50YWw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVORDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbmQsIGNvbnNlcXVlbnRseSwgc2VjdGlvbiAxMy4yLjUgaW4gSUFOQSBDb25zaWRlcmF0aW9u cyBzZWN0aW9uIHdpbGwgcmVxdWVzdCBhbGxvY2F0aW9uIG9mIHZhbHVlIDB4NiB0byBiZSBhc3Np Z25lZCB0byBBY3RpdmUgT0FNIHByb3RvY29scy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3Jl YXRseSBhcHByZWNpYXRlIHlvdXIgY29uc2lkZXJhdGlvbiBhbmQgY29tbWVudHMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPk15IOKCrDAuMDIuJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Q2FybG9zLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpSdGctb29hbS1kdCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UnRnLW9vYW0tZHRAaWV0Zi5vcmciPlJ0Zy1vb2FtLWR0 QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRnLW9vYW0tZHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRnLW9vYW0tZHQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF11221ADBCA5eusaamb103erics_-- From nobody Sat Jul 23 09:25: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 0C38312B057; Sat, 23 Jul 2016 09:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 wFSboc4Rln9e; Sat, 23 Jul 2016 09:24:58 -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 CF36F12D5AB; Sat, 23 Jul 2016 09:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50362; q=dns/txt; s=iport; t=1469291096; x=1470500696; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+oIWrLQ0wjcxlAz/rscoDHr3w5+ovS7XHZGfq4YTPRA=; b=P1l5WMA+uH3kB8UzK7KxOzU4FzSpS7J2/XICOGgD+03N26Q23aYHuVQV L2cGUwcdakyXwZkc2CCuyWJYZ+y2nLIwXEycOK8bg6Pc/p10rHe88fLcC ieZ8ATPdiAFORgrIjyDWy6qxT7craXSITkyXJCXOnvpfBmeLOu0MbmXhR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgB9mZNX/5RdJa1egnFOVnwGuFqBf?= =?us-ascii?q?COFeQIcgQw4FAEBAQEBAQFdJ4RcAQEFAQEhBEAHBAcQAgEIEQQBASEBBgMCAgI?= =?us-ascii?q?lCxQJCAIEDgWIMA6qEI0wAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoF4glWEV?= =?us-ascii?q?x+CSyuCLwWTZIVCAY5tgWyEWYh2kCABHjaCCxyBTG6HQn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,409,1464652800"; d="scan'208,217";a="129170762" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2016 16:24:55 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6NGOtvK024342 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 23 Jul 2016 16:24:55 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 23 Jul 2016 12:24:54 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sat, 23 Jul 2016 12:24:54 -0400 From: "Carlos Pignataro (cpignata)" To: Gregory Mirsky Thread-Topic: [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR4/B/s+mJr49HL0uqnvaJ3glSK6AkcOaAgAIHwQA= Date: Sat, 23 Jul 2016 16:24:54 +0000 Message-ID: <565E48DF-2D9E-43E6-BAB6-5376F926B609@cisco.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se> 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.61.241.205] Content-Type: multipart/alternative; boundary="_000_565E48DF2D9E43E6BAB65376F926B609ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 16:25:01 -0000 --_000_565E48DF2D9E43E6BAB65376F926B609ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEdyZWcsDQoNCk9uIEp1bCAyMiwgMjAxNiwgYXQgMTA6MjQgQU0sIEdyZWdvcnkgTWlyc2t5 IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNz c29uLmNvbT4+IHdyb3RlOg0KDQpIaSBDYXJsb3MsDQp0aGFuayB5b3UgZm9yIHNoYXJpbmcgeW91 ciBjb21tZW50cy4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IHN1Z2dlc3QgdG8gZXhw b3NlIHByb3RvY29sIHR5cGVzIG9mIE9BTSBhcyBOZXh0IFByb3RvY29sIHJhdGhlciB0aGFuIHRv IHVzZSBzaW5nbGUgQWN0aXZlIE9BTSBwcm90b2NvbCB0eXBlIGFuZCB1c2UgT09BTSBIZWFkZXIg dG8gZGVtdXggT09BTSB0eXBlLiBUaGVuLCB0aGUgTmV4dCBQcm90b2NvbCByZWdpc3RyeSB3aWxs IGhhdmUgdG8gYWxsb2NhdGUgdmFsdWVzIGZvciBzaW5nbGUtaG9wIEJGRCwgbXVsdGktaG9wIEJG RCwgbXVsdGlwb2ludCBCRkQsIFMtQkZELCBFY2hvIFJlcXVlc3QvUmVwbHksIEFJUyBwcm90b2Nv bCwgQWN0aXZlIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IHByb3RvY29sLCBhbmQgSeKAmXZlIG9u bHkgbGlzdGVkIHNvbWUgb2YgQU9NIHByb3RvY29scyB0aGF0IG1heSBiZSB1c2VkIHRvIG9wZXJh dGUsIGFkbWluaXN0ZXIgYW5kIG1haW50YWluIFNGUC4NCg0KWWVzLCB0aGUgcHJvdG9jb2wgZmll bGQgb3VnaHQgdG8gcmVnaXN0ZXIgdGhlIE9BTSBwcm90b2NvbHMgdGhhdCB3aWxsIGJlIHVzZWQg YW5kIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCDigJQgb2YgY291cnNlIG5vdCBhbGwgcG90ZW50 aWFsIHZhcmlhdGlvbnMgYW5kIHBlcm11dGF0aW9ucyBvZiBwb3NzaWJsZSBPQU1zICh3aGF0IGlz IEFJUyBwcm90b2NvbD8pDQoNCkFkZGl0aW9uYWxseSwgeW914oCZdmUgc3VnZ2VzdGVkIHRoYXQg b25seSBPLWJpdCB2YWx1ZSB0byBiZSB1c2VkIHRvIGRldGVybWluZSB3aGV0aGVyIHBhY2tldCBz aG91bGQgYmUgcHJvY2Vzc2VkIGFzIE9BTSBvciBkYXRhIHBhY2tldC4gSGVuY2Ugc2hvdWxkIEkg ZXhwZWN0IHRoYXQgTy1iaXQgaXMgc2V0IGZvciBCRkQsIEFJUywgYW5kIEVjaG8gUmVxdWVzdC9S ZXBseSBwYXlsb2FkIGFuZCBzaG91bGQgbm90IGJlIHNldCBpZiB0aGUgTmV4dCBQcm90b2NvbCBp cyBuZWl0aGVyIG9mIHByb3RvY29scyBsaXN0ZWQgYWJvdmU/IFNob3VsZCBzdWNoIHNpdHVhdGlv biwgaS5lLiBOZXh0IFByb3RvY29sIHZhbHVlIGlzIE1QTFMgYW5kIE8tYml0IHNldCB0byAweDEs IHNob3VsZCBiZSB2aWV3ZWQgYXMgZXJyb3IgYW5kIHRoZSBwYWNrZXQgZHJvcHBlZD8gT3IgeW91 IHByb3Bvc2UgdGhhdCB0aGUgTmV4dCBQcm90b2NvbCB0YWtlcyBwcmVjZWRlbmNlIGFuZCB0aGUg cGFja2V0IHRyZWF0ZWQgYXMgZGF0YT8gT3IgcGFja2V0IHZpZXdlZCBhcyBPQU0gYW5kIHBhc3Nl ZCB0byB0aGUgbG9jYWwgT0FNIGVudGl0eT8gT3IgaG93IHRvIGludGVycHJldCBzaXR1YXRpb24g d2hlbiBPLWJpdCBpcyBjbGVhcmVkIGFuZCB0aGUgTmV4dCBQcm90b2NvbCB2YWx1ZSBpcyBvbmUg b2YgT0FNIHByb3RvY29scz8gVGhpcyBpcyB0aGUgc2l0dWF0aW9uIHRoYXQsIGluIG15IHZpZXcs IGlzIGFtYmlndW91cyBhbmQgdW5kZXItc3BlY2lmaWVkIGluIHRoZSBjdXJyZW50IE5TSCBkb2N1 bWVudC4gTXkgcHJvcG9zYWwgaXMgYW4gYXR0ZW1wdCB0byBtYWtlIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIE9BTSBhbmQgZGF0YSBwYWNrZXRzIG1vcmUgZGV0ZXJtaW5pc3RpYy4NCg0KQW5zd2VyaW5n IGFsbCB0aG9zZSBxdWVzdGlvbnMgKHdoaWNoIGFyZSByZWFsbHkgc2xpZ2h0IHBlcm11dGF0aW9u cyBvZiB0aGUgc2FtZSBxdWVzdGlvbikgaW4gb25lIHNob3Q6IHRvIG1lLCBPPTAgaXMgYSBkYXRh IHBhY2tldCBhbmQgTz0xIGlzIGFuIE9BTSBwYWNrZXQuIElmIHRoZSBkYXRhIHByb2Nlc3Npbmcg ZG9lcyBub3QgaGF2ZSBhIGhhbmRsZXIgZm9yIHRoZSBwcm90b2NvbCBpbiB0aGUgUElELCBvciBp dOKAmXMgYW4gdW5kZWZpbmVkLCBkcm9wcyB0byB0aGUgYml0IGJ1Y2tldC4gRXF1YWxseSwgaWYg dGhlIE9BTSBoYW5kbGVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIHByb3RvY29sIElEIGNhcnJpZWQg YXMgT0FNLCBwdWZmLiBJUCBjYW4gY2FycnkgZGF0YSBvciBPQU0gZm9yIGV4YW1wbGUgYnkgdGhl IHdheS4NCg0KSXQgZG9lcyBub3QgZ2V0IGFueSBzaW1wbGVyIGFuZCB1bmFtYmlndW91cyB0aGFu IHRoYXQuIFdoYXTigJlzIHRoZSBhZHZhbnRhZ2Ugb2YgbW92aW5nIHRoZSBPQU0gUElEIGZ1cnRo ZXIgaW5zaWRlPw0KDQpBbmQgSSBkbyBub3QgYmVsaWV2ZSB0aGVyZeKAmXMgdW5kZXJzcGVjaWZp Y2F0aW9uIGluIE5TSCAtPiBPPTEsIE9BTSB0cmVhdG1lbnQsIG5vdCBkZXRhaWxlZCBoZXJlLg0K DQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogQ2FybG9zIFBpZ25h dGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KU2VudDogRnJpZGF5 LCBKdWx5IDIyLCAyMDE2IDEwOjEwIEFNDQpUbzogR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4NCkNj OiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47IHJ0Zy1vb2FtLWR0QGlldGYub3Jn PG1haWx0bzpydGctb29hbS1kdEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUnRnLW9vYW0tZHRd IElkZW50aWZ5aW5nIE9BTSBpbiBOU0gNCg0KR3JlZywNCg0KUGxlYXNlIGZpbmQgc29tZSBjb21t ZW50cyBpbmxpbmUuDQpUaHVtYiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0YXJvLg0KRXhjdXplIHR5 cG9mcmFwaGljYWsgZXJyb3dzDQoNCk9uIEp1bCAyMSwgMjAxNiwgYXQgMDk6MDEsIEdyZWdvcnkg TWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5 QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KRGVhciBBbGwsDQp3ZSBoYWQgdmVyeSBnb29kIGRpc2N1 c3Npb24gb24gT0FNIHRoaXMgd2Vlay4gV2XigJl2ZSB0b3VjaGVkIG9uIEFjdGl2ZSwgUGFzc2l2 ZSBhbmQgU29tZXRoaW5nLWluLWJldHdlZW4gT0FNLiBCdXQgY2FuIE5TSCBpbmRpY2F0ZSB3aGlj aCBPQU0gdHlwZSwgaWYgYW55LCBhc3NvY2lhdGVkIHdpdGggYSBwYWNrZXQ/IEkgdGhpbmsgdGhh dCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtc2ZjLW5zaCBkb2VzIG5vdCBhbGxv dyB0aGF0IGFuZCBtYXkgYmUgYW1iaWd1b3VzIGluIHNvbWUgY2FzZXMuIEkgcHJvcG9zZSBjaGFu Z2UgdG8gaW50ZXJwcmV0YXRpb24gYW5kIGFwcGxpY2FiaWxpdHkgZGVzY3JpcHRpb24gb2YgdGhl IE8oQU0pIGZsYWcgYW5kIGFsbG9jYXRpb24gb2YgdGhlIG5ldyBwcm90b2NvbCB0eXBlIHRvIGJl IHVzZWQgaW4gdGhlIE5leHQgUHJvdG9jb2wgZmllbGQuDQoNCg0KQWN0aXZlLCBwYXNzaXZlIGFu ZCBzb21ldGhpbmctaW4tYmV0d2VlbiBhcmUgbm90IE9BTSBwcm90b2NvbCB0eXBlcyBidXQgcmF0 aGVyIHRoZXkgYXJlIG1lYXN1cmluZyBtZXRob2RzLiBBY3RpdmUgT0FNIGNhbiBpbmNsdWRlIGEg cGx1cmFsaXR5IG9mIE9BTSBwcm90b2NvbHMsIGluY2x1ZGluZyBCRkQsIFMtQkZELCBzb21ldGhp bmctb3Zlci1pcCwgZXRjLg0KDQpJIGFsc28gYmVsaWV2ZSB0aGF0IHRoZSBjdXJyZW50IE9BTSB0 ZXh0IGluIE5TSCBpcyBub3QgYW1iaWd1b3VzIGFuZCBhbGxvd3MgZW5vdWdoIHByb2Nlc3Npbmcg b2YgdGhlIGhlYWRlciB0byB1bmRlcnN0YW5kIHNvbWV0aGluZyBpcyBPQU0sIHdpdGhvdXQgZ29p bmcgdGhlIHNwZWNpZmljcyBvZiBhbiBPQU0gaGFuZGxlci4NCg0KVGhlcmVmb3JlLCBJIG9wcG9z ZSB0aGlzIGNoYW5nZS4NCg0KDQpSRkMgNzc5OSBkZWZpbmVzIEFjdGl2ZSBPQU0gYXMgZm9sbG93 aW5nOg0KQW4gQWN0aXZlIE1ldHJpYyBvciBNZXRob2QgZGVwZW5kcyBvbiBhIGRlZGljYXRlZCBt ZWFzdXJlbWVudCBwYWNrZXQgc3RyZWFtIGFuZCBvYnNlcnZhdGlvbnMgb2YgdGhlIHN0cmVhbS4N ClRodXMsIHJlZ2FyZGxlc3Mgb2YgZW5jYXBzdWxhdGlvbiB1c2VkIGJ5IE9BTSwgaXQgaXMgdGhl IHBhY2tldCBjb25zdHJ1Y3RlZCBzb2xlbHkgZm9yIG1vbml0b3JpbmcsIG1lYXN1cmluZyBuZXR3 b3Jr4oCZcyBtZXRyaWMgYW5kIHNob3VsZCBub3QgbGVhdmUgZ2l2ZW4gZG9tYWluLiBBbmQsIEkg YmVsaWV2ZSwgc3VjaCBwYWNrZXRzIHNob3VsZCBiZSBpZGVudGlmaWVkIGJ5IHRoZSBwcm90b2Nv bCB0eXBlIG9mIHRoZWlyIG93bi4NCg0KU2VlbXMgeW91IGFyZSBhZHZvY2F0aW5nIGZvciBhIHNp bmdsZSAiT0FNIiBwcm90b2NvbCB0eXBlIGZvciBPQU0gcGFja2V0cy4gVGhlIGZ1bmN0aW9uYWxp dHkgb2YgaWRlbnRpZnlpbmcgc29tZXRoaW5nIGFzIE9BTSBpcyBpbiB0aGUgTy1iaXQsIHNvIG5v IG5lZWQgdG8gd2FzdGUgYml0cyBpbiBkdXBsaWNhdGlvbi4NCg0KVGhlbiwgYXQgc29tZSBwb2lu dCwgeW91IGhhdmUgdG8gZGlmZmVyZW50aWF0ZSBpZiBhbiBPQU0gaXMsIHNheSwgSVAgb3IgInJh dyBCRkQiIG9yIHNvbWV0aGluZyBlbHNlLiBUaGF0J3Mgd2hhdCB0aGUgUHJvdG9jb2wgZmllbGQg aXMgZm9yLiBJIGRvIG5vdCBzZWUgYSBuZWVkIHRvIGFkZCBhbiBpbmRpcmVjdGlvbiBoZXJlIHRv IHRoZW4gaGF2ZSB0byBoYXZlIGEgcHJvdG9jb2wgZmllbGQgaW5zaWRlIHRoZSBPQU0uDQoNCg0K T0FNIHdoaWNoIGJlaGF2ZXMgYXMgbXVjaCBhcyBQYXNzaXZlIE9BTSBvciBTb21ldGhpbmctaW4t YmV0d2VlbiwgZS5nLiBPQU0gYXBwZW5kZWQgdG8gZGF0YSBwYWNrZXQgZWl0aGVyIGF0IHRoZSBk b21haW7igJlzIGVkZ2Ugb3Igb24tdGhlLWZseSwgaWRlbnRpZmllZCBieSB0aGUgcHJvdG9jb2wg dHlwZSBvZiB0aGUgZGF0YSBwYWNrZXQgY2FycmllZCBpbiBOU0guDQoNClRoYXQncyBjb3JyZWN0 LCB3aXRoIHRoZSBPIGJpdCBjbGVhcmVkOyBpdCdzIGEgZGF0YSBwYWNrZXQgYW5kIG5vdCBhbiBP QU0gb25lLg0KDQoNCkJlbG93IGFyZSBjaGFuZ2VzIEnigJlkIGxpa2UgdG8gcHJvcG9zZToNClNl Y3Rpb24gMy4yIE8tYml0Og0KT0xEDQogICBPIGJpdDogd2hlbiBzZXQgdG8gMHgxIGluZGljYXRl cyB0aGF0IHRoaXMgcGFja2V0IGlzIGFuIE9wZXJhdGlvbnMsDQogICBBZG1pbmlzdHJhdGlvbiBh bmQgTWFpbnRlbmFuY2UgKE9BTSkgbWVzc2FnZS4gIFRoZSByZWNlaXZpbmcgU0ZGIGFuZA0KICAg U0ZzIG5vZGVzIE1VU1QgZXhhbWluZSB0aGUgcGF5bG9hZCBhbmQgdGFrZSBhcHByb3ByaWF0ZSBh Y3Rpb24gKGUuZy4NCiAgIHJldHVybiBzdGF0dXMgaW5mb3JtYXRpb24pLiAgT0FNIG1lc3NhZ2Ug c3BlY2lmaWNzIGFuZCBoYW5kbGluZw0KICAgZGV0YWlscyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4NCkVORA0KTkVXDQpPIGJpdDogd2hlbiBzZXQgdG8gMHgxIGluZGlj YXRlcyB0aGF0IGRhdGEgcGFja2V0IGlkZW50aWZpZWQgYnkgdGhlIE5leHQNClByb3RvY29sIHR5 cGUgaGFzIE9BTSBtZXRhZGF0YSBhcHBlbmRlZC4NCg0KTm8uIElmIGl0IGlzIGEgZGF0YSBwYWNr ZXQgaXQgZG9lcyBub3QgaGF2ZSB0aGUgTyBiaXQgc2V0ICh0byAxIG9yIHRvIHdoaWNoZXZlciBv dGhlciBwb3NzaWJsZSB2YWx1ZSBmb3IgdGhlIGJpdCA6LSkNCg0KVGhlIGdvYWwgaXMgdGhhdCBs b29raW5nIGF0IGEgc2luZ2xlIGJ1dCBpdCBjYW4gYmUgdW5kZXJzdG9vZCBpZiBpdCBpcyBhIGRh dGEgcGFja2V0ICh3aGljaCBjYW4gYmUgdXNlZCwgbWFya2VkLCBldGMuIHRvIGJlIHVzZWQgZm9y IE9BTSBwdXJwb3Nlcywgb3Igbm90KS4NCg0KV2UgZG8gbm90IHdhbnQgT0FNIGRpcmVjdCBleGNl cHRpb24gcHJvY2Vzc2luZyBmb3IgZGF0YSBwYWNrZXRzLg0KDQoNCkRlZmluaXRpb24gb2YgdGhl IGZvcm1hdChzKQ0KdXNlZCBieSBPQU0gbWV0YWRhdGEgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBkb2N1bWVudC4NCkVORA0KDQpBdCB0aGUgZW5kIG9mIFNlY3Rpb24gMy4yOg0KT0xEDQog ICBUaGlzIGRyYWZ0IGRlZmluZXMgdGhlIGZvbGxvd2luZyBOZXh0IFByb3RvY29sIHZhbHVlczoN Cg0KICAgMHgxIDogSVB2NA0KICAgMHgyIDogSVB2Ng0KICAgMHgzIDogRXRoZXJuZXQNCiAgIDB4 NDogTlNIDQogICAweDU6IE1QTFMNCiAgIDB4Ni0weEZEOiBVbmFzc2lnbmVkDQogICAweEZFLTB4 RkY6IEV4cGVyaW1lbnRhbA0KRU5EDQpORVcNCiAgIFRoaXMgZHJhZnQgZGVmaW5lcyB0aGUgZm9s bG93aW5nIE5leHQgUHJvdG9jb2wgdmFsdWVzOg0KDQogICAweDEgOiBJUHY0DQogICAweDIgOiBJ UHY2DQogICAweDMgOiBFdGhlcm5ldA0KICAgMHg0OiBOU0gNCiAgIDB4NTogTVBMUw0KICAgMHg2 OiBBY3RpdmUgT0FNDQoNCkFzIHBlciBhYm92ZSBJIGRvIG5vdCBiZWxpZXZlIHRoZXJlJ3MgYSBz aW5nbGUgT0FNIHByb3RvY29sLg0KDQoNCiAgIDB4Ny0weEZEOiBVbmFzc2lnbmVkDQogICAweEZF LTB4RkY6IEV4cGVyaW1lbnRhbA0KRU5EDQoNCkFuZCwgY29uc2VxdWVudGx5LCBzZWN0aW9uIDEz LjIuNSBpbiBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24gd2lsbCByZXF1ZXN0IGFsbG9jYXRp b24gb2YgdmFsdWUgMHg2IHRvIGJlIGFzc2lnbmVkIHRvIEFjdGl2ZSBPQU0gcHJvdG9jb2xzLg0K DQpHcmVhdGx5IGFwcHJlY2lhdGUgeW91ciBjb25zaWRlcmF0aW9uIGFuZCBjb21tZW50cy4NCg0K DQpNeSDigqwwLjAyLg0KDQpUaGFua3MsDQoNCkNhcmxvcy4NCg0KDQogICAgICAgICAgICAgICAg UmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUnRnLW9vYW0tZHQgbWFp bGluZyBsaXN0DQpSdGctb29hbS1kdEBpZXRmLm9yZzxtYWlsdG86UnRnLW9vYW0tZHRAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy1vb2FtLWR0DQoN Cg== --_000_565E48DF2D9E43E6BAB65376F926B609ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <506F0AF5AAB0AE4B836AD0A6812A6AB0@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksIEdyZWcsDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDIyLCAyMDE2LCBhdCAxMDoyNCBBTSwgR3JlZ29yeSBN aXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iIGNs YXNzPSIiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpIaSBDYXJs b3MsPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KdGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIgY29tbWVudHMuIElm IEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHlvdSBzdWdnZXN0IHRvIGV4cG9zZSBwcm90b2NvbCB0 eXBlcyBvZiBPQU0gYXMgTmV4dCBQcm90b2NvbCByYXRoZXIgdGhhbiB0byB1c2Ugc2luZ2xlIEFj dGl2ZSBPQU0gcHJvdG9jb2wgdHlwZSBhbmQgdXNlIE9PQU0gSGVhZGVyIHRvIGRlbXV4IE9PQU0g dHlwZS4gVGhlbiwgdGhlIE5leHQgUHJvdG9jb2wgcmVnaXN0cnkgd2lsbCBoYXZlDQogdG8gYWxs b2NhdGUgdmFsdWVzIGZvciBzaW5nbGUtaG9wIEJGRCwgbXVsdGktaG9wIEJGRCwgbXVsdGlwb2lu dCBCRkQsIFMtQkZELCBFY2hvIFJlcXVlc3QvUmVwbHksIEFJUyBwcm90b2NvbCwgQWN0aXZlIFBl cmZvcm1hbmNlIE1lYXN1cmVtZW50IHByb3RvY29sLCBhbmQgSeKAmXZlIG9ubHkgbGlzdGVkIHNv bWUgb2YgQU9NIHByb3RvY29scyB0aGF0IG1heSBiZSB1c2VkIHRvIG9wZXJhdGUsIGFkbWluaXN0 ZXIgYW5kIG1haW50YWluIFNGUC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5ZZXMsIHRoZSBwcm90b2NvbCBmaWVs ZCBvdWdodCB0byByZWdpc3RlciB0aGUgT0FNIHByb3RvY29scyB0aGF0IHdpbGwgYmUgdXNlZCBh bmQgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkIOKAlCBvZiBjb3Vyc2Ugbm90IGFsbCBwb3RlbnRp YWwgdmFyaWF0aW9ucyBhbmQgcGVybXV0YXRpb25zIG9mIHBvc3NpYmxlIE9BTXMgKHdoYXQgaXMg QUlTIHByb3RvY29sPyk8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIg c3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkFkZGl0aW9uYWxseSwgeW91 4oCZdmUgc3VnZ2VzdGVkIHRoYXQgb25seSBPLWJpdCB2YWx1ZSB0byBiZSB1c2VkIHRvIGRldGVy bWluZSB3aGV0aGVyIHBhY2tldCBzaG91bGQgYmUgcHJvY2Vzc2VkIGFzIE9BTSBvciBkYXRhIHBh Y2tldC4gSGVuY2Ugc2hvdWxkIEkgZXhwZWN0IHRoYXQgTy1iaXQgaXMgc2V0IGZvciBCRkQsIEFJ UywgYW5kIEVjaG8gUmVxdWVzdC9SZXBseSBwYXlsb2FkIGFuZCBzaG91bGQgbm90IGJlIHNldCBp ZiB0aGUgTmV4dCBQcm90b2NvbA0KIGlzIG5laXRoZXIgb2YgcHJvdG9jb2xzIGxpc3RlZCBhYm92 ZT8gU2hvdWxkIHN1Y2ggc2l0dWF0aW9uLCBpLmUuIE5leHQgUHJvdG9jb2wgdmFsdWUgaXMgTVBM UyBhbmQgTy1iaXQgc2V0IHRvIDB4MSwgc2hvdWxkIGJlIHZpZXdlZCBhcyBlcnJvciBhbmQgdGhl IHBhY2tldCBkcm9wcGVkPyBPciB5b3UgcHJvcG9zZSB0aGF0IHRoZSBOZXh0IFByb3RvY29sIHRh a2VzIHByZWNlZGVuY2UgYW5kIHRoZSBwYWNrZXQgdHJlYXRlZCBhcyBkYXRhPyBPcg0KIHBhY2tl dCB2aWV3ZWQgYXMgT0FNIGFuZCBwYXNzZWQgdG8gdGhlIGxvY2FsIE9BTSBlbnRpdHk/IE9yIGhv dyB0byBpbnRlcnByZXQgc2l0dWF0aW9uIHdoZW4gTy1iaXQgaXMgY2xlYXJlZCBhbmQgdGhlIE5l eHQgUHJvdG9jb2wgdmFsdWUgaXMgb25lIG9mIE9BTSBwcm90b2NvbHM/IFRoaXMgaXMgdGhlIHNp dHVhdGlvbiB0aGF0LCBpbiBteSB2aWV3LCBpcyBhbWJpZ3VvdXMgYW5kIHVuZGVyLXNwZWNpZmll ZCBpbiB0aGUgY3VycmVudCBOU0ggZG9jdW1lbnQuDQogTXkgcHJvcG9zYWwgaXMgYW4gYXR0ZW1w dCB0byBtYWtlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIE9BTSBhbmQgZGF0YSBwYWNrZXRzIG1vcmUg ZGV0ZXJtaW5pc3RpYy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5BbnN3ZXJpbmcgYWxsIHRob3NlIHF1ZXN0aW9u cyAod2hpY2ggYXJlIHJlYWxseSBzbGlnaHQgcGVybXV0YXRpb25zIG9mIHRoZSBzYW1lIHF1ZXN0 aW9uKSBpbiBvbmUgc2hvdDogdG8gbWUsIE89MCBpcyBhIGRhdGEgcGFja2V0IGFuZCBPPTEgaXMg YW4gT0FNIHBhY2tldC4gSWYgdGhlIGRhdGEgcHJvY2Vzc2luZyBkb2VzIG5vdCBoYXZlIGEgaGFu ZGxlciBmb3IgdGhlIHByb3RvY29sIGluIHRoZSBQSUQsIG9yIGl04oCZcyBhbiB1bmRlZmluZWQs DQogZHJvcHMgdG8gdGhlIGJpdCBidWNrZXQuIEVxdWFsbHksIGlmIHRoZSBPQU0gaGFuZGxlciBk b2VzIG5vdCBzdXBwb3J0IHRoZSBwcm90b2NvbCBJRCBjYXJyaWVkIGFzIE9BTSwgcHVmZi4gSVAg Y2FuIGNhcnJ5IGRhdGEgb3IgT0FNIGZvciBleGFtcGxlIGJ5IHRoZSB3YXkuPC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JdCBkb2VzIG5vdCBnZXQgYW55IHNpbXBsZXIg YW5kIHVuYW1iaWd1b3VzIHRoYW4gdGhhdC4gV2hhdOKAmXMgdGhlIGFkdmFudGFnZSBvZiBtb3Zp bmcgdGhlIE9BTSBQSUQgZnVydGhlciBpbnNpZGU/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj5BbmQgSSBkbyBub3QgYmVsaWV2ZSB0aGVyZeKAmXMgdW5kZXJzcGVjaWZp Y2F0aW9uIGluIE5TSCAtJmd0OyBPPTEsIE9BTSB0cmVhdG1lbnQsIG5vdCBkZXRhaWxlZCBoZXJl LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+4oCUIENhcmxvcy48L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBSZWdhcmRzLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRv cC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRp bmc6IDNwdCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkg WzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iIGNsYXNzPSIiPm1haWx0bzpjcGln bmF0YUBjaXNjby5jb208L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5LCBKdWx5IDIyLCAy MDE2IDEwOjEwIEFNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5HcmVnb3J5IE1pcnNreSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgY2xhc3M9IiI+Z3Jl Z29yeS5taXJza3lAZXJpY3Nzb24uY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0i Ij5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT47 DQo8YSBocmVmPSJtYWlsdG86cnRnLW9vYW0tZHRAaWV0Zi5vcmciIGNsYXNzPSIiPnJ0Zy1vb2Ft LWR0QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW1J0Zy1v b2FtLWR0XSBJZGVudGlmeWluZyBPQU0gaW4gTlNIPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpHcmVnLDxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMTJwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiPg0KUGxlYXNlIGZpbmQgc29tZSBjb21tZW50cyBpbmxpbmUuJm5ic3A7PG86cCBjbGFz cz0iIj48L286cD48L3A+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+VGh1bWIg dHlwZWQgYnkgQ2FybG9zIFBpZ25hdGFyby48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5FeGN1emUgdHlwb2ZyYXBoaWNh ayBlcnJvd3M8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDEycHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7Ij4NCjxiciBjbGFzcz0iIj4NCk9uIEp1bCAyMSwgMjAxNiwgYXQgMDk6MDEs IEdyZWdvcnkgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nz b24uY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IiBjbGFzcz0iIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw IGNsYXNzPSIiPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpEZWFyIEFsbCw8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQp3ZSBoYWQgdmVyeSBnb29kIGRpc2N1c3Npb24gb24gT0FNIHRoaXMgd2Vlay4g V2XigJl2ZSB0b3VjaGVkIG9uIEFjdGl2ZSwgUGFzc2l2ZSBhbmQgU29tZXRoaW5nLWluLWJldHdl ZW4gT0FNLiBCdXQgY2FuIE5TSCBpbmRpY2F0ZSB3aGljaCBPQU0gdHlwZSwgaWYgYW55LCBhc3Nv Y2lhdGVkIHdpdGggYSBwYWNrZXQ/IEkgdGhpbmsgdGhhdCB0aGUgY3VycmVudCB2ZXJzaW9uIG9m IGRyYWZ0LWlldGYtc2ZjLW5zaCBkb2VzIG5vdCBhbGxvdyB0aGF0IGFuZA0KIG1heSBiZSBhbWJp Z3VvdXMgaW4gc29tZSBjYXNlcy4gSSBwcm9wb3NlIGNoYW5nZSB0byBpbnRlcnByZXRhdGlvbiBh bmQgYXBwbGljYWJpbGl0eSBkZXNjcmlwdGlvbiBvZiB0aGUgTyhBTSkgZmxhZyBhbmQgYWxsb2Nh dGlvbiBvZiB0aGUgbmV3IHByb3RvY29sIHR5cGUgdG8gYmUgdXNlZCBpbiB0aGUgTmV4dCBQcm90 b2NvbCBmaWVsZC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj5BY3RpdmUsIHBhc3NpdmUgYW5kIHNvbWV0aGluZy1pbi1iZXR3ZWVuIGFyZSBu b3QgT0FNIHByb3RvY29sIHR5cGVzIGJ1dCByYXRoZXIgdGhleSBhcmUgbWVhc3VyaW5nIG1ldGhv ZHMuIEFjdGl2ZSBPQU0gY2FuIGluY2x1ZGUgYSBwbHVyYWxpdHkgb2YgT0FNIHByb3RvY29scywg aW5jbHVkaW5nIEJGRCwgUy1CRkQsDQogc29tZXRoaW5nLW92ZXItaXAsIGV0Yy4mbmJzcDs8bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+SSBhbHNvIGJlbGlldmUgdGhhdCB0aGUgY3VycmVudCBP QU0gdGV4dCBpbiBOU0ggaXMgbm90IGFtYmlndW91cyBhbmQgYWxsb3dzIGVub3VnaCBwcm9jZXNz aW5nIG9mIHRoZSBoZWFkZXIgdG8gdW5kZXJzdGFuZCBzb21ldGhpbmcgaXMgT0FNLCB3aXRob3V0 IGdvaW5nIHRoZSBzcGVjaWZpY3Mgb2YgYW4gT0FNDQogaGFuZGxlci4mbmJzcDs8bzpwIGNsYXNz PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi PjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+VGhlcmVmb3JlLCBJIG9wcG9zZSB0aGlzIGNoYW5nZS4mbmJzcDs8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7 IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NClJGQyA3Nzk5IGRlZmluZXMgQWN0aXZlIE9BTSBhcyBmb2xsb3dpbmc6 PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdCAwLjVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KQW4gQWN0aXZlIE1ldHJpYyBvciBNZXRob2QgZGVwZW5kcyBv biBhIGRlZGljYXRlZCBtZWFzdXJlbWVudCBwYWNrZXQgc3RyZWFtIGFuZCBvYnNlcnZhdGlvbnMg b2YgdGhlIHN0cmVhbS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpUaHVzLCByZWdhcmRsZXNzIG9mIGVuY2Fwc3Vs YXRpb24gdXNlZCBieSBPQU0sIGl0IGlzIHRoZSBwYWNrZXQgY29uc3RydWN0ZWQgc29sZWx5IGZv ciBtb25pdG9yaW5nLCBtZWFzdXJpbmcgbmV0d29ya+KAmXMgbWV0cmljIGFuZCBzaG91bGQgbm90 IGxlYXZlIGdpdmVuIGRvbWFpbi4gQW5kLCBJIGJlbGlldmUsIHN1Y2ggcGFja2V0cyBzaG91bGQg YmUgaWRlbnRpZmllZCBieSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGVpciBvd24uPHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPlNlZW1zIHlvdSBhcmUgYWR2b2NhdGluZyBmb3IgYSBzaW5nbGUg JnF1b3Q7T0FNJnF1b3Q7IHByb3RvY29sIHR5cGUgZm9yIE9BTSBwYWNrZXRzLiBUaGUgZnVuY3Rp b25hbGl0eSBvZiBpZGVudGlmeWluZyBzb21ldGhpbmcgYXMgT0FNIGlzIGluIHRoZSBPLWJpdCwg c28gbm8gbmVlZCB0byB3YXN0ZSBiaXRzIGluIGR1cGxpY2F0aW9uLiZuYnNwOzxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj5UaGVuLCBhdCBzb21lIHBvaW50LCB5b3UgaGF2ZSB0byBkaWZmZXJl bnRpYXRlIGlmIGFuIE9BTSBpcywgc2F5LCBJUCBvciAmcXVvdDtyYXcgQkZEJnF1b3Q7IG9yIHNv bWV0aGluZyBlbHNlLiBUaGF0J3Mgd2hhdCB0aGUgUHJvdG9jb2wgZmllbGQgaXMgZm9yLiBJIGRv IG5vdCBzZWUgYSBuZWVkIHRvIGFkZCBhbiBpbmRpcmVjdGlvbg0KIGhlcmUgdG8gdGhlbiBoYXZl IHRvIGhhdmUgYSBwcm90b2NvbCBmaWVsZCBpbnNpZGUgdGhlIE9BTS4mbmJzcDs8bzpwIGNsYXNz PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCk9BTSB3aGljaCBiZWhhdmVzIGFzIG11Y2ggYXMgUGFzc2l2ZSBPQU0gb3IgU29tZXRo aW5nLWluLWJldHdlZW4sIGUuZy4gT0FNIGFwcGVuZGVkIHRvIGRhdGEgcGFja2V0IGVpdGhlciBh dCB0aGUgZG9tYWlu4oCZcyBlZGdlIG9yIG9uLXRoZS1mbHksIGlkZW50aWZpZWQgYnkgdGhlIHBy b3RvY29sIHR5cGUgb2YgdGhlIGRhdGEgcGFja2V0IGNhcnJpZWQgaW4gTlNILjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+VGhhdCdzIGNvcnJlY3QsIHdpdGggdGhlIE8gYml0IGNsZWFyZWQ7IGl0J3MgYSBk YXRhIHBhY2tldCBhbmQgbm90IGFuIE9BTSBvbmUuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCkJlbG93IGFyZSBjaGFuZ2VzIEnigJlkIGxpa2UgdG8gcHJvcG9zZTo8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQpTZWN0aW9uIDMuMiBPLWJpdDo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpPTEQ8bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsgTyBiaXQ6IHdoZW4gc2V0IHRvIDB4MSBpbmRpY2F0ZXMgdGhhdCB0aGlzIHBhY2tl dCBpcyBhbiBPcGVyYXRpb25zLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyBBZG1pbmlzdHJh dGlvbiBhbmQgTWFpbnRlbmFuY2UgKE9BTSkgbWVzc2FnZS4mbmJzcDsgVGhlIHJlY2VpdmluZyBT RkYgYW5kPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IFNGcyBub2RlcyBNVVNUIGV4YW1pbmUg dGhlIHBheWxvYWQgYW5kIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9uIChlLmcuPG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7IHJldHVybiBzdGF0dXMgaW5mb3JtYXRpb24pLiZuYnNwOyBPQU0gbWVz c2FnZSBzcGVjaWZpY3MgYW5kIGhhbmRsaW5nPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IGRl dGFpbHMgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIHNvbGlk OyBib3JkZXItYm90dG9tLWNvbG9yOiB3aW5kb3d0ZXh0OyBib3JkZXItYm90dG9tLXdpZHRoOiAx cHQ7IHBhZGRpbmc6IDBpbiAwaW4gMXB0OyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkVORDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KTkVXPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KTyBiaXQ6IHdoZW4gc2V0IHRvIDB4MSBpbmRpY2F0ZXMgdGhhdCBkYXRhIHBh Y2tldCBpZGVudGlmaWVkIGJ5IHRoZSBOZXh0PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KUHJvdG9jb2wgdHlwZSBo YXMgT0FNIG1ldGFkYXRhIGFwcGVuZGVkLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj5Oby4g SWYgaXQgaXMgYSBkYXRhIHBhY2tldCBpdCBkb2VzIG5vdCBoYXZlIHRoZSBPIGJpdCBzZXQgKHRv IDEgb3IgdG8gd2hpY2hldmVyIG90aGVyIHBvc3NpYmxlIHZhbHVlIGZvciB0aGUgYml0IDotKTxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj5UaGUgZ29hbCBpcyB0aGF0IGxvb2tpbmcgYXQgYSBz aW5nbGUgYnV0IGl0IGNhbiBiZSB1bmRlcnN0b29kIGlmIGl0IGlzIGEgZGF0YSBwYWNrZXQgKHdo aWNoIGNhbiBiZSB1c2VkLCBtYXJrZWQsIGV0Yy4gdG8gYmUgdXNlZCBmb3IgT0FNIHB1cnBvc2Vz LCBvciBub3QpLiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj5XZSBkbyBub3Qgd2Fu dCBPQU0gZGlyZWN0IGV4Y2VwdGlvbiBwcm9jZXNzaW5nIGZvciBkYXRhIHBhY2tldHMuJm5ic3A7 PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0 OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQpEZWZpbml0aW9uIG9mIHRoZSBmb3JtYXQocyk8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KdXNlZCBi eSBPQU0gbWV0YWRhdGEgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQpFTkQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpBdCB0aGUg ZW5kIG9mIFNlY3Rpb24gMy4yOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCk9MRDxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyBUaGlzIGRyYWZ0IGRlZmluZXMgdGhlIGZvbGxvd2luZyBOZXh0IFByb3RvY29sIHZh bHVlczo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgMHgx IDogSVB2NDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyAweDIgOiBJUHY2PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7IDB4MyA6IEV0aGVybmV0PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 IDB4NDogTlNIPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IDB4NTogTVBMUzxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyAweDYtMHhGRDogVW5hc3NpZ25lZDxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyAweEZFLTB4RkY6IEV4cGVyaW1lbnRhbDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWJvdHRv bS1jb2xvcjogd2luZG93dGV4dDsgYm9yZGVyLWJvdHRvbS13aWR0aDogMXB0OyBwYWRkaW5nOiAw aW4gMGluIDFwdDsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQpFTkQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCk5FVzxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyBUaGlzIGRyYWZ0IGRlZmluZXMgdGhlIGZvbGxvd2luZyBOZXh0IFByb3RvY29s IHZhbHVlczo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsg MHgxIDogSVB2NDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyAweDIgOiBJUHY2PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7IDB4MyA6IEV0aGVybmV0PG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7IDB4NDogTlNIPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IDB4NTogTVBMUzxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyAweDY6IEFjdGl2ZSBPQU08bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+PG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPkFz IHBlciBhYm92ZSBJIGRvIG5vdCBiZWxpZXZlIHRoZXJlJ3MgYSBzaW5nbGUgT0FNIHByb3RvY29s LiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDog NXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyAweDct MHhGRDogVW5hc3NpZ25lZDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyAweEZFLTB4RkY6IEV4 cGVyaW1lbnRhbDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkVORDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCkFuZCwgY29uc2VxdWVudGx5LCBzZWN0aW9uIDEzLjIuNSBpbiBJQU5BIENvbnNpZGVy YXRpb25zIHNlY3Rpb24gd2lsbCByZXF1ZXN0IGFsbG9jYXRpb24gb2YgdmFsdWUgMHg2IHRvIGJl IGFzc2lnbmVkIHRvIEFjdGl2ZSBPQU0gcHJvdG9jb2xzLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCkdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIGNvbnNpZGVyYXRpb24gYW5kIGNv bW1lbnRzLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+TXkg4oKsMC4w Mi4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+VGhhbmtzLDxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+PG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj5DYXJsb3MuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NClJ0Zy1vb2FtLWR0IG1haWxpbmcgbGlzdDxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Im1haWx0bzpSdGctb29hbS1kdEBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBw dXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+UnRnLW9vYW0tZHRA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGctb29hbS1kdCIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGctb29hbS1kdDwvYT48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_565E48DF2D9E43E6BAB65376F926B609ciscocom_-- From nobody Sat Jul 23 10:39: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 96CD112D67D; Sat, 23 Jul 2016 10:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 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.287] 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 elhcxx3HoeGl; Sat, 23 Jul 2016 10:38: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 6B38712D65F; Sat, 23 Jul 2016 10:38:53 -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.0294.000; Sat, 23 Jul 2016 13:38:50 -0400 From: Dave Dolson To: "Carlos Pignataro (cpignata)" , Gregory Mirsky Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR5QkToxex5qfvO06IBz1JKa0fbA== Date: Sat, 23 Jul 2016 17:38:50 +0000 Message-ID: <20160723173849.5714002.69288.99598@sandvine.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se>, <565E48DF-2D9E-43E6-BAB6-5376F926B609@cisco.com> In-Reply-To: <565E48DF-2D9E-43E6-BAB6-5376F926B609@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: multipart/alternative; boundary="_000_2016072317384957140026928899598sandvinecom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 17:38:56 -0000 --_000_2016072317384957140026928899598sandvinecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Carlos, I think some of what is being said in emails needs to be clarified in the d= ocument. It still isn't crystal clear to me. If O=3D1, and next protocol is IPv4, can there be an OAM header piggy-backe= d with the IPv4? If so, before or after? Some drafts imply this is possible but nothing says how. -Dave From: Carlos Pignataro (cpignata) Sent: Saturday, July 23, 2016 12:25 PM To: Gregory Mirsky Cc: rtg-ooam-dt@ietf.org; sfc@ietf.org Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Hi, Greg, On Jul 22, 2016, at 10:24 AM, Gregory Mirsky > wrote: Hi Carlos, thank you for sharing your comments. If I understand correctly, you suggest= to expose protocol types of OAM as Next Protocol rather than to use single= Active OAM protocol type and use OOAM Header to demux OOAM type. Then, the= Next Protocol registry will have to allocate values for single-hop BFD, mu= lti-hop BFD, multipoint BFD, S-BFD, Echo Request/Reply, AIS protocol, Activ= e Performance Measurement protocol, and I=92ve only listed some of AOM prot= ocols that may be used to operate, administer and maintain SFP. Yes, the protocol field ought to register the OAM protocols that will be us= ed and implemented and deployed =97 of course not all potential variations = and permutations of possible OAMs (what is AIS protocol?) Additionally, you=92ve suggested that only O-bit value to be used to determ= ine whether packet should be processed as OAM or data packet. Hence should = I expect that O-bit is set for BFD, AIS, and Echo Request/Reply payload and= should not be set if the Next Protocol is neither of protocols listed abov= e? Should such situation, i.e. Next Protocol value is MPLS and O-bit set to= 0x1, should be viewed as error and the packet dropped? Or you propose that= the Next Protocol takes precedence and the packet treated as data? Or pack= et viewed as OAM and passed to the local OAM entity? Or how to interpret si= tuation when O-bit is cleared and the Next Protocol value is one of OAM pro= tocols? This is the situation that, in my view, is ambiguous and under-spec= ified in the current NSH document. My proposal is an attempt to make relati= onship between OAM and data packets more deterministic. Answering all those questions (which are really slight permutations of the = same question) in one shot: to me, O=3D0 is a data packet and O=3D1 is an O= AM packet. If the data processing does not have a handler for the protocol = in the PID, or it=92s an undefined, drops to the bit bucket. Equally, if th= e OAM handler does not support the protocol ID carried as OAM, puff. IP can= carry data or OAM for example by the way. It does not get any simpler and unambiguous than that. What=92s the advanta= ge of moving the OAM PID further inside? And I do not believe there=92s underspecification in NSH -> O=3D1, OAM trea= tment, not detailed here. Thanks, =97 Carlos. Regards, Greg From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Friday, July 22, 2016 10:10 AM To: Gregory Mirsky > Cc: sfc@ietf.org; rtg-ooam-dt@ietf.org Subject: Re: [Rtg-ooam-dt] Identifying OAM in NSH Greg, Please find some comments inline. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Jul 21, 2016, at 09:01, Gregory Mirsky > wrote: Dear All, we had very good discussion on OAM this week. We=92ve touched on Active, Pa= ssive and Something-in-between OAM. But can NSH indicate which OAM type, if= any, associated with a packet? I think that the current version of draft-i= etf-sfc-nsh does not allow that and may be ambiguous in some cases. I propo= se change to interpretation and applicability description of the O(AM) flag= and allocation of the new protocol type to be used in the Next Protocol fi= eld. Active, passive and something-in-between are not OAM protocol types but rat= her they are measuring methods. Active OAM can include a plurality of OAM p= rotocols, including BFD, S-BFD, something-over-ip, etc. I also believe that the current OAM text in NSH is not ambiguous and allows= enough processing of the header to understand something is OAM, without go= ing the specifics of an OAM handler. Therefore, I oppose this change. RFC 7799 defines Active OAM as following: An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream. Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network=92s metric and should not leave g= iven domain. And, I believe, such packets should be identified by the proto= col type of their own. Seems you are advocating for a single "OAM" protocol type for OAM packets. = The functionality of identifying something as OAM is in the O-bit, so no ne= ed to waste bits in duplication. Then, at some point, you have to differentiate if an OAM is, say, IP or "ra= w BFD" or something else. That's what the Protocol field is for. I do not s= ee a need to add an indirection here to then have to have a protocol field = inside the OAM. OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM = appended to data packet either at the domain=92s edge or on-the-fly, identi= fied by the protocol type of the data packet carried in NSH. That's correct, with the O bit cleared; it's a data packet and not an OAM o= ne. Below are changes I=92d like to propose: Section 3.2 O-bit: OLD O bit: when set to 0x1 indicates that this packet is an Operations, Administration and Maintenance (OAM) message. The receiving SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information). OAM message specifics and handling details are outside the scope of this document. END NEW O bit: when set to 0x1 indicates that data packet identified by the Next Protocol type has OAM metadata appended. No. If it is a data packet it does not have the O bit set (to 1 or to which= ever other possible value for the bit :-) The goal is that looking at a single but it can be understood if it is a da= ta packet (which can be used, marked, etc. to be used for OAM purposes, or = not). We do not want OAM direct exception processing for data packets. Definition of the format(s) used by OAM metadata is outside the scope of this document. END At the end of Section 3.2: OLD This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6-0xFD: Unassigned 0xFE-0xFF: Experimental END NEW This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6: Active OAM As per above I do not believe there's a single OAM protocol. 0x7-0xFD: Unassigned 0xFE-0xFF: Experimental END And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols. Greatly appreciate your consideration and comments. My =800.02. Thanks, Carlos. Regards, Greg _______________________________________________ Rtg-ooam-dt mailing list Rtg-ooam-dt@ietf.org https://www.ietf.org/mailman/listinfo/rtg-ooam-dt --_000_2016072317384957140026928899598sandvinecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
From: Carlos Pignataro (cpignata)
Sent: Saturday, July 23, 2016 12:25 PM
To: Gregory Mirsky
Cc: rtg-ooam-dt@ietf.org; sfc@ietf.org
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

Hi, Greg,

On Jul 22, 2016, at 10:24 AM, Gregory Mirsky <gregory.mirsky@ericsson.com= > wrote:

Hi Carlos,
thank you for sharing your comments. If I understand correctly, you suggest= to expose protocol types of OAM as Next Protocol rather than to use single= Active OAM protocol type and use OOAM Header to demux OOAM type. Then, the= Next Protocol registry will have to allocate values for single-hop BFD, multi-hop BFD, multipoint BFD, S-BF= D, Echo Request/Reply, AIS protocol, Active Performance Measurement protoco= l, and I=92ve only listed some of AOM protocols that may be used to operate= , administer and maintain SFP.

Yes, the protocol field ought to register the OAM protocols that will = be used and implemented and deployed =97 of course not all potential variat= ions and permutations of possible OAMs (what is AIS protocol?)

Additionally, you=92ve suggested that only O-bit value to be used to determ= ine whether packet should be processed as OAM or data packet. Hence should = I expect that O-bit is set for BFD, AIS, and Echo Request/Reply payload and= should not be set if the Next Protocol is neither of protocols listed above? Should such situation, i.e. Next Pro= tocol value is MPLS and O-bit set to 0x1, should be viewed as error and the= packet dropped? Or you propose that the Next Protocol takes precedence and= the packet treated as data? Or packet viewed as OAM and passed to the local OAM entity? Or how to interpr= et situation when O-bit is cleared and the Next Protocol value is one of OA= M protocols? This is the situation that, in my view, is ambiguous and under= -specified in the current NSH document. My proposal is an attempt to make relationship between OAM and data packet= s more deterministic.

Answering all those questions (which are really slight permutations of= the same question) in one shot: to me, O=3D0 is a data packet and O=3D1 is= an OAM packet. If the data processing does not have a handler for the prot= ocol in the PID, or it=92s an undefined, drops to the bit bucket. Equally, if the OAM handler does not support the = protocol ID carried as OAM, puff. IP can carry data or OAM for example by t= he way.

It does not get any simpler and unambiguous than that. What=92s the ad= vantage of moving the OAM PID further inside?

And I do not believe there=92s underspecification in NSH -> O=3D1, = OAM treatment, not detailed here.

Thanks,

=97 Carlos.

 
            &nb= sp;   Regards,
            &nb= sp;            =        Greg
 
From: C= arlos Pignataro (cpignata) [mailto:cpignata@cisco.com] = ;
Sent: F= riday, July 22, 2016 10:10 AM
To: Gre= gory Mirsky <g= regory.mirsky@ericsson.com>
Cc: sfc@ietf.org; rtg-ooam-dt@ietf.org=
Subject: Re: [Rtg-ooam-dt] Identifying OAM in NSH
 
Greg,
 

Please find some comments inline. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows


On Jul 21, 2016, at 09:01, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear All,
we had very good discussion on OAM this week. We=92ve touched on Active, Pa= ssive and Something-in-between OAM. But can NSH indicate which OAM type, if= any, associated with a packet? I think that the current version of draft-i= etf-sfc-nsh does not allow that and may be ambiguous in some cases. I propose change to interpretation and app= licability description of the O(AM) flag and allocation of the new protocol= type to be used in the Next Protocol field.
 
 
Active, passive and something-in-between are not OAM protocol types but= rather they are measuring methods. Active OAM can include a plurality of O= AM protocols, including BFD, S-BFD, something-over-ip, etc. 
 
I also believe that the current OAM text in NSH is not ambiguous and al= lows enough processing of the header to understand something is OAM, withou= t going the specifics of an OAM handler. 
 
Therefore, I oppose this change. 


RFC 7799 defines Active OAM as following:
An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream.
Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network=92s metric and should not leave g= iven domain. And, I believe, such packets should be identified by the proto= col type of their own. 
 
Seems you are advocating for a single "OAM" protocol type for= OAM packets. The functionality of identifying something as OAM is in the O= -bit, so no need to waste bits in duplication. 
 
Then, at some point, you have to differentiate if an OAM is, say, IP or= "raw BFD" or something else. That's what the Protocol field is f= or. I do not see a need to add an indirection here to then have to have a protocol field inside the OAM. 


OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM = appended to data packet either at the domain=92s edge or on-the-fly, identi= fied by the protocol type of the data packet carried in NSH.
 
That's correct, with the O bit cleared; it's a data packet and not an O= AM one. 


Below are changes I=92d like to propose:
Section 3.2 O-bit:
OLD
   O bit: when set to 0x1 indicates that this packet is an Operat= ions,
   Administration and Maintenance (OAM) message.  The receiv= ing SFF and
   SFs nodes MUST examine the payload and take appropriate action= (e.g.
   return status information).  OAM message specifics and ha= ndling
   details are outside the scope of this document.
END
NEW
O bit: when set to 0x1 indicates that data packet identified by the Next
Protocol type has OAM metadata appended. 
 
No. If it is a data packet it does not have the O bit set (to 1 or to w= hichever other possible value for the bit :-)
 
The goal is that looking at a single but it can be understood if it is = a data packet (which can be used, marked, etc. to be used for OAM purposes,= or not). 
 
We do not want OAM direct exception processing for data packets. <= /span>


Definition of the format(s) 
used by OAM metadata is outside the scope of this document.
END
 
At the end of Section 3.2:
OLD
   This draft defines the following Next Protocol values:
 
   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW
   This draft defines the following Next Protocol values:
 
   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM
 
As per above I do not believe there's a single OAM protocol. 


   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
 
And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols.
 
Greatly appreciate your consideration and comments.
 
 
My =800.02. 
 
Thanks,
 
Carlos. 


            &nb= sp;   Regards,
            &nb= sp;            =        Greg
 
_______________________________________________
Rtg-ooam-dt mailing list
Rtg-ooam-dt@ietf.org
https://www.ietf.org/mailma= n/listinfo/rtg-ooam-dt

--_000_2016072317384957140026928899598sandvinecom_-- From nobody Sat Jul 23 11:45: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 596E012D104; Sat, 23 Jul 2016 11:45:16 -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 OINNL_S0ydDE; Sat, 23 Jul 2016 11:45:13 -0700 (PDT) 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 E7C3B12B04C; Sat, 23 Jul 2016 11:45:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CCE3798008B; Sat, 23 Jul 2016 11:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1469299513; bh=sJnv7FO4JwJRA1QJKoESISY5s3GwBG3N1Kkq+g2+Ap8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=aaacgvocVLYrNVmtmuUUhd1EaTZPRiOBeAtUKZTCSg6XL0+IBe4xOjM86AFR7GA5L YcKr+u16k69SGDWaidqnK1Fmb3DKz46v2M84xNTJjkFfJdCpW8I9gMwaqQF3H4MK68 h/SKSUxpz2c/fU4/IEe9D0Q/lCiy+fWOoIwsn/V8= 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 0677E1C057C; Sat, 23 Jul 2016 11:45:12 -0700 (PDT) To: "Carlos Pignataro (cpignata)" , Gregory Mirsky References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se> <565E48DF-2D9E-43E6-BAB6-5376F926B609@cisco.com> From: "Joel M. Halpern" Message-ID: <03e6e582-e85e-d09a-8ded-541820d9cc32@joelhalpern.com> Date: Sat, 23 Jul 2016 14:45:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <565E48DF-2D9E-43E6-BAB6-5376F926B609@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 18:45:16 -0000 There is one situation that folks are asking for that seems not to be clearly covered in the spec, and appears to me to be clarified by Greg's proposal. We have had a couple of requests for the ability to put OAM marking on user data packets. The most obvious use is to monitor how long it takes NSH-aware service functions to process the user packets. If the only case where we will need this is for service function processing, the putting it in the TLVs, without additional markings, and allowing the service functions which understand the TLV to work with it seems sufficient. But it is not clear to me that there is not a desire (whether it is a requirement is probably an important open question) for similar capability at SFF. If we have situations where SFF, in passing user data packets, also need to perform OAM operations, then it seems to me that we need the OAM bit to tell the SFF to look at this. Efforts with routers to do this with router alert options have been a mess. If we need the capability, it seems to me that we really want it in a standardized and efficient place. If we are very sure we don't need this, then we should write that down, and move on. Yours, Joel On 7/23/16 12:24 PM, Carlos Pignataro (cpignata) wrote: > Hi, Greg, > >> On Jul 22, 2016, at 10:24 AM, Gregory Mirsky >> > wrote: >> >> Hi Carlos, >> thank you for sharing your comments. If I understand correctly, you >> suggest to expose protocol types of OAM as Next Protocol rather than >> to use single Active OAM protocol type and use OOAM Header to demux >> OOAM type. Then, the Next Protocol registry will have to allocate >> values for single-hop BFD, multi-hop BFD, multipoint BFD, S-BFD, Echo >> Request/Reply, AIS protocol, Active Performance Measurement protocol, >> and I’ve only listed some of AOM protocols that may be used to >> operate, administer and maintain SFP. > > Yes, the protocol field ought to register the OAM protocols that will be > used and implemented and deployed — of course not all potential > variations and permutations of possible OAMs (what is AIS protocol?) > >> Additionally, you’ve suggested that only O-bit value to be used to >> determine whether packet should be processed as OAM or data packet. >> Hence should I expect that O-bit is set for BFD, AIS, and Echo >> Request/Reply payload and should not be set if the Next Protocol is >> neither of protocols listed above? Should such situation, i.e. Next >> Protocol value is MPLS and O-bit set to 0x1, should be viewed as error >> and the packet dropped? Or you propose that the Next Protocol takes >> precedence and the packet treated as data? Or packet viewed as OAM and >> passed to the local OAM entity? Or how to interpret situation when >> O-bit is cleared and the Next Protocol value is one of OAM protocols? >> This is the situation that, in my view, is ambiguous and >> under-specified in the current NSH document. My proposal is an attempt >> to make relationship between OAM and data packets more deterministic. > > Answering all those questions (which are really slight permutations of > the same question) in one shot: to me, O=0 is a data packet and O=1 is > an OAM packet. If the data processing does not have a handler for the > protocol in the PID, or it’s an undefined, drops to the bit bucket. > Equally, if the OAM handler does not support the protocol ID carried as > OAM, puff. IP can carry data or OAM for example by the way. > > It does not get any simpler and unambiguous than that. What’s the > advantage of moving the OAM PID further inside? > > And I do not believe there’s underspecification in NSH -> O=1, OAM > treatment, not detailed here. > > Thanks, > > — Carlos. > >> >> Regards, >> Greg >> >> *From:* Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> *Sent:* Friday, July 22, 2016 10:10 AM >> *To:* Gregory Mirsky > > >> *Cc:* sfc@ietf.org ; rtg-ooam-dt@ietf.org >> >> *Subject:* Re: [Rtg-ooam-dt] Identifying OAM in NSH >> >> Greg, >> >> >> Please find some comments inline. >> >> Thumb typed by Carlos Pignataro. >> Excuze typofraphicak errows >> >> >> On Jul 21, 2016, at 09:01, Gregory Mirsky > > wrote: >> >> Dear All, >> we had very good discussion on OAM this week. We’ve touched on >> Active, Passive and Something-in-between OAM. But can NSH indicate >> which OAM type, if any, associated with a packet? I think that the >> current version of draft-ietf-sfc-nsh does not allow that and may >> be ambiguous in some cases. I propose change to interpretation and >> applicability description of the O(AM) flag and allocation of the >> new protocol type to be used in the Next Protocol field. >> >> >> >> Active, passive and something-in-between are not OAM protocol types >> but rather they are measuring methods. Active OAM can include a >> plurality of OAM protocols, including BFD, S-BFD, something-over-ip, etc. >> >> I also believe that the current OAM text in NSH is not ambiguous and >> allows enough processing of the header to understand something is OAM, >> without going the specifics of an OAM handler. >> >> Therefore, I oppose this change. >> >> >> RFC 7799 defines Active OAM as following: >> An Active Metric or Method depends on a dedicated measurement >> packet stream and observations of the stream. >> Thus, regardless of encapsulation used by OAM, it is the packet >> constructed solely for monitoring, measuring network’s metric and >> should not leave given domain. And, I believe, such packets should >> be identified by the protocol type of their own. >> >> >> Seems you are advocating for a single "OAM" protocol type for OAM >> packets. The functionality of identifying something as OAM is in the >> O-bit, so no need to waste bits in duplication. >> >> Then, at some point, you have to differentiate if an OAM is, say, IP >> or "raw BFD" or something else. That's what the Protocol field is for. >> I do not see a need to add an indirection here to then have to have a >> protocol field inside the OAM. >> >> >> OAM which behaves as much as Passive OAM or Something-in-between, >> e.g. OAM appended to data packet either at the domain’s edge or >> on-the-fly, identified by the protocol type of the data packet >> carried in NSH. >> >> >> That's correct, with the O bit cleared; it's a data packet and not an >> OAM one. >> >> >> Below are changes I’d like to propose: >> Section 3.2 O-bit: >> OLD >> O bit: when set to 0x1 indicates that this packet is an Operations, >> Administration and Maintenance (OAM) message. The receiving >> SFF and >> SFs nodes MUST examine the payload and take appropriate action >> (e.g. >> return status information). OAM message specifics and handling >> details are outside the scope of this document. >> END >> NEW >> O bit: when set to 0x1 indicates that data packet identified by >> the Next >> Protocol type has OAM metadata appended. >> >> >> No. If it is a data packet it does not have the O bit set (to 1 or to >> whichever other possible value for the bit :-) >> >> The goal is that looking at a single but it can be understood if it is >> a data packet (which can be used, marked, etc. to be used for OAM >> purposes, or not). >> >> We do not want OAM direct exception processing for data packets. >> >> >> Definition of the format(s) >> used by OAM metadata is outside the scope of this document. >> END >> >> At the end of Section 3.2: >> OLD >> This draft defines the following Next Protocol values: >> >> 0x1 : IPv4 >> 0x2 : IPv6 >> 0x3 : Ethernet >> 0x4: NSH >> 0x5: MPLS >> 0x6-0xFD: Unassigned >> 0xFE-0xFF: Experimental >> END >> NEW >> This draft defines the following Next Protocol values: >> >> 0x1 : IPv4 >> 0x2 : IPv6 >> 0x3 : Ethernet >> 0x4: NSH >> 0x5: MPLS >> 0x6: Active OAM >> >> >> As per above I do not believe there's a single OAM protocol. >> >> >> 0x7-0xFD: Unassigned >> 0xFE-0xFF: Experimental >> END >> >> And, consequently, section 13.2.5 in IANA Considerations section >> will request allocation of value 0x6 to be assigned to Active OAM >> protocols. >> >> Greatly appreciate your consideration and comments. >> >> >> >> My €0.02. >> >> Thanks, >> >> Carlos. >> >> >> Regards, >> Greg >> >> >> _______________________________________________ >> Rtg-ooam-dt mailing list >> Rtg-ooam-dt@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt >> > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Sat Jul 23 16:29: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 8742712B077; Sat, 23 Jul 2016 16:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 HZxT5AuQGCGE; Sat, 23 Jul 2016 16:29:02 -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 23CD512B02C; Sat, 23 Jul 2016 16:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42559; q=dns/txt; s=iport; t=1469316542; x=1470526142; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kDb5LFeWHDudfyjoEw4F4HXWMvjaxbv5VJa14r/yRDk=; b=ldQ/lSdTWnpDiAle2OE9SYxo9wsPCEOinCTT50W22HyyrwV4YE7KZCzJ Ea+Muc7BeuubojcpVSVwoYe2qFDBBvFIsK1ERh/+v4EIBHil85NE2E09u evBONyDizLNQxHn3rGywdFuIXqyxVYYGGrSA8I7ChlG7QFopDzKD7YOia 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgAj/ZNX/4QNJK1TCoJxTlZ8Brhdg?= =?us-ascii?q?XwjhXkCgSg4FAEBAQEBAQFdJ4RcAQEFAQElQAcEBxACAQgOAwQBASEBBgcnCxQ?= =?us-ascii?q?JCAIEDgWIMA64EAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqBeIJVhBhegnaCL?= =?us-ascii?q?wWTZIVCAY5tgWyEWYh2kCABHjaCCAMcgUxuhmt/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,411,1464652800"; d="scan'208,217";a="127096021" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jul 2016 23:29:00 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6NNT0eb011860 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 23 Jul 2016 23:29:00 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 23 Jul 2016 19:28:59 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sat, 23 Jul 2016 19:28:59 -0400 From: "Carlos Pignataro (cpignata)" To: Dave Dolson Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR4/B/s+mJr49HL0uqnvaJ3glSK6AkcOaAgAIHwQCAABSrAIAAYdCA Date: Sat, 23 Jul 2016 23:28:58 +0000 Message-ID: <60C37038-D54A-4DB9-9BE7-24377F176F1A@cisco.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se> <565E48DF-2D9E-43E6-BAB6-5376F926B609@cisco.com> <20160723173849.5714002.69288.99598@sandvine.com> In-Reply-To: <20160723173849.5714002.69288.99598@sandvine.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.61.165.229] Content-Type: multipart/alternative; boundary="_000_60C37038D54A4DB99BE724377F176F1Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 23:29:05 -0000 --_000_60C37038D54A4DB99BE724377F176F1Aciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Dave, On Jul 23, 2016, at 6:38 PM, Dave Dolson > wrote: Carlos, I think some of what is being said in emails needs to be clarified in the d= ocument. It still isn't crystal clear to me. I agree that it needs to be clarified, with diagrams, and specs. However, w= hen you say =93in the document=94, I do not think those details belong in t= he NSH document itself. The NSH, in my humble opinion, needs to say how to = identify an OAM packet. If O=3D1, and next protocol is IPv4, can there be an OAM header piggy-backe= d with the IPv4? If so, before or after? Some drafts imply this is possible but nothing says how. If O=3D1 and the next protocol is IPv4, I=92d expect an IPv4 packet encapsu= lating the OAM (either UDP-> BFD, or ICMP, for example). With =93OAM header= =94, do you mean the OOAM DT header? What would be the use for those extra = bytes in this case? Thanks, =97 Carlos. -Dave From: Carlos Pignataro (cpignata) Sent: Saturday, July 23, 2016 12:25 PM To: Gregory Mirsky Cc: rtg-ooam-dt@ietf.org; sfc@ietf.org Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Hi, Greg, On Jul 22, 2016, at 10:24 AM, Gregory Mirsky > wrote: Hi Carlos, thank you for sharing your comments. If I understand correctly, you suggest= to expose protocol types of OAM as Next Protocol rather than to use single= Active OAM protocol type and use OOAM Header to demux OOAM type. Then, the= Next Protocol registry will have to allocate values for single-hop BFD, mu= lti-hop BFD, multipoint BFD, S-BFD, Echo Request/Reply, AIS protocol, Activ= e Performance Measurement protocol, and I=92ve only listed some of AOM prot= ocols that may be used to operate, administer and maintain SFP. Yes, the protocol field ought to register the OAM protocols that will be us= ed and implemented and deployed =97 of course not all potential variations = and permutations of possible OAMs (what is AIS protocol?) Additionally, you=92ve suggested that only O-bit value to be used to determ= ine whether packet should be processed as OAM or data packet. Hence should = I expect that O-bit is set for BFD, AIS, and Echo Request/Reply payload and= should not be set if the Next Protocol is neither of protocols listed abov= e? Should such situation, i.e. Next Protocol value is MPLS and O-bit set to= 0x1, should be viewed as error and the packet dropped? Or you propose that= the Next Protocol takes precedence and the packet treated as data? Or pack= et viewed as OAM and passed to the local OAM entity? Or how to interpret si= tuation when O-bit is cleared and the Next Protocol value is one of OAM pro= tocols? This is the situation that, in my view, is ambiguous and under-spec= ified in the current NSH document. My proposal is an attempt to make relati= onship between OAM and data packets more deterministic. Answering all those questions (which are really slight permutations of the = same question) in one shot: to me, O=3D0 is a data packet and O=3D1 is an O= AM packet. If the data processing does not have a handler for the protocol = in the PID, or it=92s an undefined, drops to the bit bucket. Equally, if th= e OAM handler does not support the protocol ID carried as OAM, puff. IP can= carry data or OAM for example by the way. It does not get any simpler and unambiguous than that. What=92s the advanta= ge of moving the OAM PID further inside? And I do not believe there=92s underspecification in NSH -> O=3D1, OAM trea= tment, not detailed here. Thanks, =97 Carlos. Regards, Greg From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Friday, July 22, 2016 10:10 AM To: Gregory Mirsky > Cc: sfc@ietf.org; rtg-ooam-dt@ietf.org Subject: Re: [Rtg-ooam-dt] Identifying OAM in NSH Greg, Please find some comments inline. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Jul 21, 2016, at 09:01, Gregory Mirsky > wrote: Dear All, we had very good discussion on OAM this week. We=92ve touched on Active, Pa= ssive and Something-in-between OAM. But can NSH indicate which OAM type, if= any, associated with a packet? I think that the current version of draft-i= etf-sfc-nsh does not allow that and may be ambiguous in some cases. I propo= se change to interpretation and applicability description of the O(AM) flag= and allocation of the new protocol type to be used in the Next Protocol fi= eld. Active, passive and something-in-between are not OAM protocol types but rat= her they are measuring methods. Active OAM can include a plurality of OAM p= rotocols, including BFD, S-BFD, something-over-ip, etc. I also believe that the current OAM text in NSH is not ambiguous and allows= enough processing of the header to understand something is OAM, without go= ing the specifics of an OAM handler. Therefore, I oppose this change. RFC 7799 defines Active OAM as following: An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream. Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network=92s metric and should not leave g= iven domain. And, I believe, such packets should be identified by the proto= col type of their own. Seems you are advocating for a single "OAM" protocol type for OAM packets. = The functionality of identifying something as OAM is in the O-bit, so no ne= ed to waste bits in duplication. Then, at some point, you have to differentiate if an OAM is, say, IP or "ra= w BFD" or something else. That's what the Protocol field is for. I do not s= ee a need to add an indirection here to then have to have a protocol field = inside the OAM. OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM = appended to data packet either at the domain=92s edge or on-the-fly, identi= fied by the protocol type of the data packet carried in NSH. That's correct, with the O bit cleared; it's a data packet and not an OAM o= ne. Below are changes I=92d like to propose: Section 3.2 O-bit: OLD O bit: when set to 0x1 indicates that this packet is an Operations, Administration and Maintenance (OAM) message. The receiving SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information). OAM message specifics and handling details are outside the scope of this document. END NEW O bit: when set to 0x1 indicates that data packet identified by the Next Protocol type has OAM metadata appended. No. If it is a data packet it does not have the O bit set (to 1 or to which= ever other possible value for the bit :-) The goal is that looking at a single but it can be understood if it is a da= ta packet (which can be used, marked, etc. to be used for OAM purposes, or = not). We do not want OAM direct exception processing for data packets. Definition of the format(s) used by OAM metadata is outside the scope of this document. END At the end of Section 3.2: OLD This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6-0xFD: Unassigned 0xFE-0xFF: Experimental END NEW This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6: Active OAM As per above I do not believe there's a single OAM protocol. 0x7-0xFD: Unassigned 0xFE-0xFF: Experimental END And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols. Greatly appreciate your consideration and comments. My =800.02. Thanks, Carlos. Regards, Greg _______________________________________________ Rtg-ooam-dt mailing list Rtg-ooam-dt@ietf.org https://www.ietf.org/mailman/listinfo/rtg-ooam-dt --_000_60C37038D54A4DB99BE724377F176F1Aciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Dave,

On Jul 23, 2016, at 6:38 PM, Dave Dolson <ddolson@sandvine.com> wrote:
From: Carlos Pignataro (cpignata)
Sent: Saturday, July 23, 2016 12:25 PM
To: Gregory Mirsky
Cc: rtg-ooam-dt@ietf.org; sfc@ietf.org
Subject: Re: [sfc] [Rtg-ooam-dt] Identify= ing OAM in NSH

Hi, Greg,

On Jul 22, 2016, at 10:24 AM, Gregory Mirsky <gregory.mirsky@ericsson.com= > wrote:

Hi Carlos,
thank you for sharing your comments. If I understand correctly, you suggest= to expose protocol types of OAM as Next Protocol rather than to use single= Active OAM protocol type and use OOAM Header to demux OOAM type. Then, the= Next Protocol registry will have to allocate values for single-hop BFD, multi-hop BFD, multipoint BFD, S-BF= D, Echo Request/Reply, AIS protocol, Active Performance Measurement protoco= l, and I=92ve only listed some of AOM protocols that may be used to operate= , administer and maintain SFP.

Yes, the protocol field ought to register the OAM protocols= that will be used and implemented and deployed =97 of course not all poten= tial variations and permutations of possible OAMs (what is AIS protocol?)
Additionally, you=92ve suggested that only O-bit value to be used to determ= ine whether packet should be processed as OAM or data packet. Hence should = I expect that O-bit is set for BFD, AIS, and Echo Request/Reply payload and= should not be set if the Next Protocol is neither of protocols listed above? Should such situation, i.e. Next Pro= tocol value is MPLS and O-bit set to 0x1, should be viewed as error and the= packet dropped? Or you propose that the Next Protocol takes precedence and= the packet treated as data? Or packet viewed as OAM and passed to the local OAM entity? Or how to interpr= et situation when O-bit is cleared and the Next Protocol value is one of OA= M protocols? This is the situation that, in my view, is ambiguous and under= -specified in the current NSH document. My proposal is an attempt to make relationship between OAM and data packet= s more deterministic.

Answering all those questions (which are really slight perm= utations of the same question) in one shot: to me, O=3D0 is a data packet a= nd O=3D1 is an OAM packet. If the data processing does not have a handler f= or the protocol in the PID, or it=92s an undefined, drops to the bit bucket. Equally, if the OAM handler does not s= upport the protocol ID carried as OAM, puff. IP can carry data or OAM for e= xample by the way.

It does not get any simpler and unambiguous than that. What= =92s the advantage of moving the OAM PID further inside?

And I do not believe there=92s underspecification in NSH -&= gt; O=3D1, OAM treatment, not detailed here.

Thanks,

=97 Carlos.

 
            &nb= sp;   Regards,
            &nb= sp;            =        Greg
 
From: C= arlos Pignataro (cpignata) [mailto:cpignata@cisco.com] = ;
Sent: F= riday, July 22, 2016 10:10 AM
To: Gre= gory Mirsky <g= regory.mirsky@ericsson.com>
Cc: sfc@ietf.org; rtg-ooam-dt@ietf.org=
Subject: Re: [Rtg-ooam-dt] Identifying OAM in NSH
 
Greg,
 

Please find some comments inline. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows


On Jul 21, 2016, at 09:01, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear All,
we had very good discussion on OAM this week. We=92ve touched on Active, Pa= ssive and Something-in-between OAM. But can NSH indicate which OAM type, if= any, associated with a packet? I think that the current version of draft-i= etf-sfc-nsh does not allow that and may be ambiguous in some cases. I propose change to interpretation and app= licability description of the O(AM) flag and allocation of the new protocol= type to be used in the Next Protocol field.
 
 
Active, passive and something-in-between are not OAM protocol types but= rather they are measuring methods. Active OAM can include a plurality of O= AM protocols, including BFD, S-BFD, something-over-ip, etc. 
 
I also believe that the current OAM text in NSH is not ambiguous and al= lows enough processing of the header to understand something is OAM, withou= t going the specifics of an OAM handler. 
 
Therefore, I oppose this change. 


RFC 7799 defines Active OAM as following:
An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream.
Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network=92s metric and should not leave g= iven domain. And, I believe, such packets should be identified by the proto= col type of their own. 
 
Seems you are advocating for a single "OAM" protocol type for= OAM packets. The functionality of identifying something as OAM is in the O= -bit, so no need to waste bits in duplication. 
 
Then, at some point, you have to differentiate if an OAM is, say, IP or= "raw BFD" or something else. That's what the Protocol field is f= or. I do not see a need to add an indirection here to then have to have a protocol field inside the OAM. 


OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM = appended to data packet either at the domain=92s edge or on-the-fly, identi= fied by the protocol type of the data packet carried in NSH.
 
That's correct, with the O bit cleared; it's a data packet and not an O= AM one. 


Below are changes I=92d like to propose:
Section 3.2 O-bit:
OLD
   O bit: when set to 0x1 indicates that this packet is an Operat= ions,
   Administration and Maintenance (OAM) message.  The receiv= ing SFF and
   SFs nodes MUST examine the payload and take appropriate action= (e.g.
   return status information).  OAM message specifics and ha= ndling
   details are outside the scope of this document.
END
NEW
O bit: when set to 0x1 indicates that data packet identified by the Next
Protocol type has OAM metadata appended. 
 
No. If it is a data packet it does not have the O bit set (to 1 or to w= hichever other possible value for the bit :-)
 
The goal is that looking at a single but it can be understood if it is = a data packet (which can be used, marked, etc. to be used for OAM purposes,= or not). 
 
We do not want OAM direct exception processing for data packets. <= /span>


Definition of the format(s) 
used by OAM metadata is outside the scope of this document.
END
 
At the end of Section 3.2:
OLD
   This draft defines the following Next Protocol values:
 
   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW
   This draft defines the following Next Protocol values:
 
   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM
 
As per above I do not believe there's a single OAM protocol. 


   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
 
And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols.
 
Greatly appreciate your consideration and comments.
 
 
My =800.02. 
 
Thanks,
 
Carlos. 


            &nb= sp;   Regards,
            &nb= sp;            =        Greg
 
_______________________________________________
Rtg-ooam-dt mailing list
Rtg-ooam-dt@ietf.org
https://www.ietf.org/mailma= n/listinfo/rtg-ooam-dt


--_000_60C37038D54A4DB99BE724377F176F1Aciscocom_-- From nobody Sat Jul 23 16:34: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 5106512D633; Sat, 23 Jul 2016 16:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 p5hjxe-Gth2k; Sat, 23 Jul 2016 16:34:13 -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 CC49D12B02C; Sat, 23 Jul 2016 16:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10170; q=dns/txt; s=iport; t=1469316852; x=1470526452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QOlawM/viQvQ6rJpdIngCIiUqfFD/zz3FXNHPadSsMg=; b=PqHSE6R2c30Ojo4dJYlcQqGhElMt0Y1qZJX6OSNVqKUuqpIzZvbotN+Y JOqJxK+5jrtfYHoVaOSK5SczjivCWKutjYiA1miqt4BEYMgHmLSI9B8rx niK7H8Y8r6d8HPS6JgjW8WPO9o4jLd/5LUpKnu/stuyjF+UFMdSx6ecr5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgBp/pNX/4QNJK1dgz9WfAa4XYF8I?= =?us-ascii?q?4V5AoEoOBQBAQEBAQEBXSeEXAEBBAEBASVABwQHBQsCAQgRBAEBAScHJwsUCQg?= =?us-ascii?q?CBA4FiCgIDrgRAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoF4glWEQIMsgi8BB?= =?us-ascii?q?JkmAY5tgWyEWYh2kCABHjaCCxyBTG6Ga38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,411,1464652800"; d="scan'208";a="127440566" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jul 2016 23:34:11 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6NNYAJI015584 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 23 Jul 2016 23:34:11 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 23 Jul 2016 19:34:10 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sat, 23 Jul 2016 19:34:10 -0400 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR4/B/s+mJr49HL0uqnvaJ3glSK6AkcOaAgAIHwQCAACcwgIAAUL4A Date: Sat, 23 Jul 2016 23:34:09 +0000 Message-ID: <83EF1E06-D242-4FE6-8C7A-B00AE858557B@cisco.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se> <565E48DF-2D9E-43E6-BAB6-5376F926B609@cisco.com> <03e6e582-e85e-d09a-8ded-541820d9cc32@joelhalpern.com> In-Reply-To: <03e6e582-e85e-d09a-8ded-541820d9cc32@joelhalpern.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.61.165.229] Content-Type: text/plain; charset="Windows-1252" Content-ID: <280E1A9C04B8264390446A252808A401@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 23:34:15 -0000 Hi, Joel, > On Jul 23, 2016, at 7:45 PM, Joel M. Halpern wrote: >=20 > There is one situation that folks are asking for that seems not to be cle= arly covered in the spec, and appears to me to be clarified by Greg's propo= sal. >=20 > We have had a couple of requests for the ability to put OAM marking on us= er data packets. The most obvious use is to monitor how long it takes NSH-= aware service functions to process the user packets. >=20 Just to make sure I understand, you are talking about the case of =93piggy-= back OAM=94, correct? > If the only case where we will need this is for service function processi= ng, the putting it in the TLVs, without additional markings, and allowing t= he service functions which understand the TLV to work with it seems suffici= ent. >=20 > But it is not clear to me that there is not a desire (whether it is a req= uirement is probably an important open question) for similar capability at = SFF. If we have situations where SFF, in passing user data packets, also n= eed to perform OAM operations, then it seems to me that we need the OAM bit= to tell the SFF to look at this. If you set the O bit in a user data packet, how would a system infer that= =92s not an OAM packet? Thanks, =97 Carlos. > Efforts with routers to do this with router alert options have been a mes= s. If we need the capability, it seems to me that we really want it in a st= andardized and efficient place. > If we are very sure we don't need this, then we should write that down, a= nd move on. >=20 > Yours, > Joel >=20 > On 7/23/16 12:24 PM, Carlos Pignataro (cpignata) wrote: >> Hi, Greg, >>=20 >>> On Jul 22, 2016, at 10:24 AM, Gregory Mirsky >>> > wrot= e: >>>=20 >>> Hi Carlos, >>> thank you for sharing your comments. If I understand correctly, you >>> suggest to expose protocol types of OAM as Next Protocol rather than >>> to use single Active OAM protocol type and use OOAM Header to demux >>> OOAM type. Then, the Next Protocol registry will have to allocate >>> values for single-hop BFD, multi-hop BFD, multipoint BFD, S-BFD, Echo >>> Request/Reply, AIS protocol, Active Performance Measurement protocol, >>> and I=92ve only listed some of AOM protocols that may be used to >>> operate, administer and maintain SFP. >>=20 >> Yes, the protocol field ought to register the OAM protocols that will be >> used and implemented and deployed =97 of course not all potential >> variations and permutations of possible OAMs (what is AIS protocol?) >>=20 >>> Additionally, you=92ve suggested that only O-bit value to be used to >>> determine whether packet should be processed as OAM or data packet. >>> Hence should I expect that O-bit is set for BFD, AIS, and Echo >>> Request/Reply payload and should not be set if the Next Protocol is >>> neither of protocols listed above? Should such situation, i.e. Next >>> Protocol value is MPLS and O-bit set to 0x1, should be viewed as error >>> and the packet dropped? Or you propose that the Next Protocol takes >>> precedence and the packet treated as data? Or packet viewed as OAM and >>> passed to the local OAM entity? Or how to interpret situation when >>> O-bit is cleared and the Next Protocol value is one of OAM protocols? >>> This is the situation that, in my view, is ambiguous and >>> under-specified in the current NSH document. My proposal is an attempt >>> to make relationship between OAM and data packets more deterministic. >>=20 >> Answering all those questions (which are really slight permutations of >> the same question) in one shot: to me, O=3D0 is a data packet and O=3D1 = is >> an OAM packet. If the data processing does not have a handler for the >> protocol in the PID, or it=92s an undefined, drops to the bit bucket. >> Equally, if the OAM handler does not support the protocol ID carried as >> OAM, puff. IP can carry data or OAM for example by the way. >>=20 >> It does not get any simpler and unambiguous than that. What=92s the >> advantage of moving the OAM PID further inside? >>=20 >> And I do not believe there=92s underspecification in NSH -> O=3D1, OAM >> treatment, not detailed here. >>=20 >> Thanks, >>=20 >> =97 Carlos. >>=20 >>>=20 >>> Regards, >>> Greg >>>=20 >>> *From:* Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>> *Sent:* Friday, July 22, 2016 10:10 AM >>> *To:* Gregory Mirsky >> > >>> *Cc:* sfc@ietf.org ; rtg-ooam-dt@ietf.org >>> >>> *Subject:* Re: [Rtg-ooam-dt] Identifying OAM in NSH >>>=20 >>> Greg, >>>=20 >>>=20 >>> Please find some comments inline. >>>=20 >>> Thumb typed by Carlos Pignataro. >>> Excuze typofraphicak errows >>>=20 >>>=20 >>> On Jul 21, 2016, at 09:01, Gregory Mirsky >> > wrote: >>>=20 >>> Dear All, >>> we had very good discussion on OAM this week. We=92ve touched on >>> Active, Passive and Something-in-between OAM. But can NSH indicate >>> which OAM type, if any, associated with a packet? I think that the >>> current version of draft-ietf-sfc-nsh does not allow that and may >>> be ambiguous in some cases. I propose change to interpretation and >>> applicability description of the O(AM) flag and allocation of the >>> new protocol type to be used in the Next Protocol field. >>>=20 >>>=20 >>>=20 >>> Active, passive and something-in-between are not OAM protocol types >>> but rather they are measuring methods. Active OAM can include a >>> plurality of OAM protocols, including BFD, S-BFD, something-over-ip, et= c. >>>=20 >>> I also believe that the current OAM text in NSH is not ambiguous and >>> allows enough processing of the header to understand something is OAM, >>> without going the specifics of an OAM handler. >>>=20 >>> Therefore, I oppose this change. >>>=20 >>>=20 >>> RFC 7799 defines Active OAM as following: >>> An Active Metric or Method depends on a dedicated measurement >>> packet stream and observations of the stream. >>> Thus, regardless of encapsulation used by OAM, it is the packet >>> constructed solely for monitoring, measuring network=92s metric and >>> should not leave given domain. And, I believe, such packets should >>> be identified by the protocol type of their own. >>>=20 >>>=20 >>> Seems you are advocating for a single "OAM" protocol type for OAM >>> packets. The functionality of identifying something as OAM is in the >>> O-bit, so no need to waste bits in duplication. >>>=20 >>> Then, at some point, you have to differentiate if an OAM is, say, IP >>> or "raw BFD" or something else. That's what the Protocol field is for. >>> I do not see a need to add an indirection here to then have to have a >>> protocol field inside the OAM. >>>=20 >>>=20 >>> OAM which behaves as much as Passive OAM or Something-in-between, >>> e.g. OAM appended to data packet either at the domain=92s edge or >>> on-the-fly, identified by the protocol type of the data packet >>> carried in NSH. >>>=20 >>>=20 >>> That's correct, with the O bit cleared; it's a data packet and not an >>> OAM one. >>>=20 >>>=20 >>> Below are changes I=92d like to propose: >>> Section 3.2 O-bit: >>> OLD >>> O bit: when set to 0x1 indicates that this packet is an Operation= s, >>> Administration and Maintenance (OAM) message. The receiving >>> SFF and >>> SFs nodes MUST examine the payload and take appropriate action >>> (e.g. >>> return status information). OAM message specifics and handling >>> details are outside the scope of this document. >>> END >>> NEW >>> O bit: when set to 0x1 indicates that data packet identified by >>> the Next >>> Protocol type has OAM metadata appended. >>>=20 >>>=20 >>> No. If it is a data packet it does not have the O bit set (to 1 or to >>> whichever other possible value for the bit :-) >>>=20 >>> The goal is that looking at a single but it can be understood if it is >>> a data packet (which can be used, marked, etc. to be used for OAM >>> purposes, or not). >>>=20 >>> We do not want OAM direct exception processing for data packets. >>>=20 >>>=20 >>> Definition of the format(s) >>> used by OAM metadata is outside the scope of this document. >>> END >>>=20 >>> At the end of Section 3.2: >>> OLD >>> This draft defines the following Next Protocol values: >>>=20 >>> 0x1 : IPv4 >>> 0x2 : IPv6 >>> 0x3 : Ethernet >>> 0x4: NSH >>> 0x5: MPLS >>> 0x6-0xFD: Unassigned >>> 0xFE-0xFF: Experimental >>> END >>> NEW >>> This draft defines the following Next Protocol values: >>>=20 >>> 0x1 : IPv4 >>> 0x2 : IPv6 >>> 0x3 : Ethernet >>> 0x4: NSH >>> 0x5: MPLS >>> 0x6: Active OAM >>>=20 >>>=20 >>> As per above I do not believe there's a single OAM protocol. >>>=20 >>>=20 >>> 0x7-0xFD: Unassigned >>> 0xFE-0xFF: Experimental >>> END >>>=20 >>> And, consequently, section 13.2.5 in IANA Considerations section >>> will request allocation of value 0x6 to be assigned to Active OAM >>> protocols. >>>=20 >>> Greatly appreciate your consideration and comments. >>>=20 >>>=20 >>>=20 >>> My =800.02. >>>=20 >>> Thanks, >>>=20 >>> Carlos. >>>=20 >>>=20 >>> Regards, >>> Greg >>>=20 >>>=20 >>> _______________________________________________ >>> Rtg-ooam-dt mailing list >>> Rtg-ooam-dt@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 From nobody Sat Jul 23 17:02: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 934DA12D7A8; Sat, 23 Jul 2016 17:01:59 -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 UsrB778Slknz; Sat, 23 Jul 2016 17:01:57 -0700 (PDT) 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 E7A8D12D1C0; Sat, 23 Jul 2016 17:01:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C504A9800B3; Sat, 23 Jul 2016 17:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1469318516; bh=jt8FGkv/uarDvr5v4MW5xnDZABcyHl7JPBbk1179/Zs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=CBzUR0jbYL42MpVPoZBK4eV/ggFCmfU+eCzcKzY7rTcin8maiOdFzHhK13D4BIJRI fayOPr+11KK0G9NMEcTy4XWti1rF2cV4j1TgHgJ1ld5s10K+bZEHcUvxpVIe+ViQk5 oNtqRt8YAQj+8ezbazTp0HZMDnQuXOzMs2sBsfH4= 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 E7F211D26B4; Sat, 23 Jul 2016 17:01:55 -0700 (PDT) To: "Carlos Pignataro (cpignata)" References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se> <565E48DF-2D9E-43E6-BAB6-5376F926B609@cisco.com> <03e6e582-e85e-d09a-8ded-541820d9cc32@joelhalpern.com> <83EF1E06-D242-4FE6-8C7A-B00AE858557B@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Sat, 23 Jul 2016 20:01:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <83EF1E06-D242-4FE6-8C7A-B00AE858557B@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Gregory Mirsky , "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 00:01:59 -0000 Carlos, Yesx, I am talking about the same case that other folks are calling piggy-back OAM. I wanted to describe the case instead of naming it, both for clarity and to raise the point about who needs to process the OAM information. You ask how the SF (or even if the SFF if that applies_ will know there is a user packet. I think the proposal is to use the OAM bit specifically to indicate that. The result of that usage is that the SFF needs to check the packet type in order to recognize OAM packets that are not user data packets and that it needs to process. That is an unfortunate complexity in a critical processing path. I suspect it is this efficiency that is driving you. Which suggests another possible interpretation. What if 1) we set the OAM bit for any packet that needs OAM processing 2) And define a (set of) packet types for packets where the cotnent is OAM 3) And declare that any other packet types are user packets with OAM TLV information. This is slightly simpler if we declare a single OAM packet type in the NSH header, as that avoids any ambiguity. (Whether the device can actually do the OAM still depends upon it understanding the OAM packets, but that is true of all structures.) This does avoid creating any confusion between the use of the OAM flag and the packet type. Yours, Joel On 7/23/16 7:34 PM, Carlos Pignataro (cpignata) wrote: > Hi, Joel, > >> On Jul 23, 2016, at 7:45 PM, Joel M. Halpern wrote: >> >> There is one situation that folks are asking for that seems not to be clearly covered in the spec, and appears to me to be clarified by Greg's proposal. >> >> We have had a couple of requests for the ability to put OAM marking on user data packets. The most obvious use is to monitor how long it takes NSH-aware service functions to process the user packets. >> > > Just to make sure I understand, you are talking about the case of “piggy-back OAM”, correct? > >> If the only case where we will need this is for service function processing, the putting it in the TLVs, without additional markings, and allowing the service functions which understand the TLV to work with it seems sufficient. >> >> But it is not clear to me that there is not a desire (whether it is a requirement is probably an important open question) for similar capability at SFF. If we have situations where SFF, in passing user data packets, also need to perform OAM operations, then it seems to me that we need the OAM bit to tell the SFF to look at this. > > If you set the O bit in a user data packet, how would a system infer that’s not an OAM packet? > > Thanks, > > — Carlos. > >> Efforts with routers to do this with router alert options have been a mess. If we need the capability, it seems to me that we really want it in a standardized and efficient place. >> If we are very sure we don't need this, then we should write that down, and move on. >> >> Yours, >> Joel >> >> On 7/23/16 12:24 PM, Carlos Pignataro (cpignata) wrote: >>> Hi, Greg, >>> >>>> On Jul 22, 2016, at 10:24 AM, Gregory Mirsky >>>> > wrote: >>>> >>>> Hi Carlos, >>>> thank you for sharing your comments. If I understand correctly, you >>>> suggest to expose protocol types of OAM as Next Protocol rather than >>>> to use single Active OAM protocol type and use OOAM Header to demux >>>> OOAM type. Then, the Next Protocol registry will have to allocate >>>> values for single-hop BFD, multi-hop BFD, multipoint BFD, S-BFD, Echo >>>> Request/Reply, AIS protocol, Active Performance Measurement protocol, >>>> and I’ve only listed some of AOM protocols that may be used to >>>> operate, administer and maintain SFP. >>> >>> Yes, the protocol field ought to register the OAM protocols that will be >>> used and implemented and deployed — of course not all potential >>> variations and permutations of possible OAMs (what is AIS protocol?) >>> >>>> Additionally, you’ve suggested that only O-bit value to be used to >>>> determine whether packet should be processed as OAM or data packet. >>>> Hence should I expect that O-bit is set for BFD, AIS, and Echo >>>> Request/Reply payload and should not be set if the Next Protocol is >>>> neither of protocols listed above? Should such situation, i.e. Next >>>> Protocol value is MPLS and O-bit set to 0x1, should be viewed as error >>>> and the packet dropped? Or you propose that the Next Protocol takes >>>> precedence and the packet treated as data? Or packet viewed as OAM and >>>> passed to the local OAM entity? Or how to interpret situation when >>>> O-bit is cleared and the Next Protocol value is one of OAM protocols? >>>> This is the situation that, in my view, is ambiguous and >>>> under-specified in the current NSH document. My proposal is an attempt >>>> to make relationship between OAM and data packets more deterministic. >>> >>> Answering all those questions (which are really slight permutations of >>> the same question) in one shot: to me, O=0 is a data packet and O=1 is >>> an OAM packet. If the data processing does not have a handler for the >>> protocol in the PID, or it’s an undefined, drops to the bit bucket. >>> Equally, if the OAM handler does not support the protocol ID carried as >>> OAM, puff. IP can carry data or OAM for example by the way. >>> >>> It does not get any simpler and unambiguous than that. What’s the >>> advantage of moving the OAM PID further inside? >>> >>> And I do not believe there’s underspecification in NSH -> O=1, OAM >>> treatment, not detailed here. >>> >>> Thanks, >>> >>> — Carlos. >>> >>>> >>>> Regards, >>>> Greg >>>> >>>> *From:* Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>> *Sent:* Friday, July 22, 2016 10:10 AM >>>> *To:* Gregory Mirsky >>> > >>>> *Cc:* sfc@ietf.org ; rtg-ooam-dt@ietf.org >>>> >>>> *Subject:* Re: [Rtg-ooam-dt] Identifying OAM in NSH >>>> >>>> Greg, >>>> >>>> >>>> Please find some comments inline. >>>> >>>> Thumb typed by Carlos Pignataro. >>>> Excuze typofraphicak errows >>>> >>>> >>>> On Jul 21, 2016, at 09:01, Gregory Mirsky >>> > wrote: >>>> >>>> Dear All, >>>> we had very good discussion on OAM this week. We’ve touched on >>>> Active, Passive and Something-in-between OAM. But can NSH indicate >>>> which OAM type, if any, associated with a packet? I think that the >>>> current version of draft-ietf-sfc-nsh does not allow that and may >>>> be ambiguous in some cases. I propose change to interpretation and >>>> applicability description of the O(AM) flag and allocation of the >>>> new protocol type to be used in the Next Protocol field. >>>> >>>> >>>> >>>> Active, passive and something-in-between are not OAM protocol types >>>> but rather they are measuring methods. Active OAM can include a >>>> plurality of OAM protocols, including BFD, S-BFD, something-over-ip, etc. >>>> >>>> I also believe that the current OAM text in NSH is not ambiguous and >>>> allows enough processing of the header to understand something is OAM, >>>> without going the specifics of an OAM handler. >>>> >>>> Therefore, I oppose this change. >>>> >>>> >>>> RFC 7799 defines Active OAM as following: >>>> An Active Metric or Method depends on a dedicated measurement >>>> packet stream and observations of the stream. >>>> Thus, regardless of encapsulation used by OAM, it is the packet >>>> constructed solely for monitoring, measuring network’s metric and >>>> should not leave given domain. And, I believe, such packets should >>>> be identified by the protocol type of their own. >>>> >>>> >>>> Seems you are advocating for a single "OAM" protocol type for OAM >>>> packets. The functionality of identifying something as OAM is in the >>>> O-bit, so no need to waste bits in duplication. >>>> >>>> Then, at some point, you have to differentiate if an OAM is, say, IP >>>> or "raw BFD" or something else. That's what the Protocol field is for. >>>> I do not see a need to add an indirection here to then have to have a >>>> protocol field inside the OAM. >>>> >>>> >>>> OAM which behaves as much as Passive OAM or Something-in-between, >>>> e.g. OAM appended to data packet either at the domain’s edge or >>>> on-the-fly, identified by the protocol type of the data packet >>>> carried in NSH. >>>> >>>> >>>> That's correct, with the O bit cleared; it's a data packet and not an >>>> OAM one. >>>> >>>> >>>> Below are changes I’d like to propose: >>>> Section 3.2 O-bit: >>>> OLD >>>> O bit: when set to 0x1 indicates that this packet is an Operations, >>>> Administration and Maintenance (OAM) message. The receiving >>>> SFF and >>>> SFs nodes MUST examine the payload and take appropriate action >>>> (e.g. >>>> return status information). OAM message specifics and handling >>>> details are outside the scope of this document. >>>> END >>>> NEW >>>> O bit: when set to 0x1 indicates that data packet identified by >>>> the Next >>>> Protocol type has OAM metadata appended. >>>> >>>> >>>> No. If it is a data packet it does not have the O bit set (to 1 or to >>>> whichever other possible value for the bit :-) >>>> >>>> The goal is that looking at a single but it can be understood if it is >>>> a data packet (which can be used, marked, etc. to be used for OAM >>>> purposes, or not). >>>> >>>> We do not want OAM direct exception processing for data packets. >>>> >>>> >>>> Definition of the format(s) >>>> used by OAM metadata is outside the scope of this document. >>>> END >>>> >>>> At the end of Section 3.2: >>>> OLD >>>> This draft defines the following Next Protocol values: >>>> >>>> 0x1 : IPv4 >>>> 0x2 : IPv6 >>>> 0x3 : Ethernet >>>> 0x4: NSH >>>> 0x5: MPLS >>>> 0x6-0xFD: Unassigned >>>> 0xFE-0xFF: Experimental >>>> END >>>> NEW >>>> This draft defines the following Next Protocol values: >>>> >>>> 0x1 : IPv4 >>>> 0x2 : IPv6 >>>> 0x3 : Ethernet >>>> 0x4: NSH >>>> 0x5: MPLS >>>> 0x6: Active OAM >>>> >>>> >>>> As per above I do not believe there's a single OAM protocol. >>>> >>>> >>>> 0x7-0xFD: Unassigned >>>> 0xFE-0xFF: Experimental >>>> END >>>> >>>> And, consequently, section 13.2.5 in IANA Considerations section >>>> will request allocation of value 0x6 to be assigned to Active OAM >>>> protocols. >>>> >>>> Greatly appreciate your consideration and comments. >>>> >>>> >>>> >>>> My €0.02. >>>> >>>> Thanks, >>>> >>>> Carlos. >>>> >>>> >>>> Regards, >>>> Greg >>>> >>>> >>>> _______________________________________________ >>>> Rtg-ooam-dt mailing list >>>> Rtg-ooam-dt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt >>>> >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> > > From nobody Sun Jul 24 04:44: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 D650512B040; Sun, 24 Jul 2016 04:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 GklUX4trSEVY; Sun, 24 Jul 2016 04:44:03 -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 CC08A12B009; Sun, 24 Jul 2016 04:44:02 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Sun, 24 Jul 2016 07:44:00 -0400 From: Dave Dolson To: "Joel M. Halpern" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AdHjGxqUb41VTqTfTwmZE/bgRl5mHQA9utSAAAZMKgAAPUPDAAAE5aOAAAoYKYAAAPZ3gAAQJUhA Date: Sun, 24 Jul 2016 11:44:01 +0000 Message-ID: <20160724114359.5714005.75862.99628@sandvine.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se> <565E48DF-2D9E-43E6-BAB6-5376F926B609@cisco.com> <03e6e582-e85e-d09a-8ded-541820d9cc32@joelhalpern.com> <83EF1E06-D242-4FE6-8C7A-B00AE858557B@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 11:44:05 -0000 Should the doc say, If the OAM bit O=3D0, this indicates the SFF MUST forward the packet based solely on the SPI and SI fields, without regard to next protocol or further payload headers. If the OAM bit O=3D1, this indicates the SFF =FDMUST NOT process the packet solely by SPI/SI forwarding but instead by the semantics specified by the =FDOAM protocol named in the Next Protocol field. I think these paragraphs get to the optimization for SFFs, and I think provide precise language without defining OAM protocols. =FDWithout further language, it is not specified how to handle *any* next-protocol values when O=3D1. And when specified... As for so-called piggyback OAM, we could define that if O=3D1 and Next Protocol=3DIPv4 there may be an OAM header following the IPv4 packet, located using IPv4 total length.=FD Or we could define a new number for IPv4-with-OAM-trailer. Note that for Next Protocol of MPLS, Ethernet or NSH, these do not have total-length fields that would allow trailing OAM. Furthermore, we could say that if O=3D1, the SFF MUST determine if the payload is addressed to it, e.g., if the next IPv6 packet is addressed to the SFF's loop-back address. I think many of us are anxious to get to work clarifying these things. -Dave Original Message From: Joel M. Halpern Sent: Saturday, July 23, 2016 8:02 PM To: Carlos Pignataro (cpignata) Cc: Gregory Mirsky; rtg-ooam-dt@ietf.org; sfc@ietf.org Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Carlos, Yesx, I am talking about the same case that other folks are calling piggy-back OAM. I wanted to describe the case instead of naming it, both for clarity and to raise the point about who needs to process the OAM information. You ask how the SF (or even if the SFF if that applies_ will know there is a user packet. I think the proposal is to use the OAM bit specifically to indicate that. The result of that usage is that the SFF needs to check the packet type in order to recognize OAM packets that are not user data packets and that it needs to process. That is an unfortunate complexity in a critical processing path. I suspect it is this efficiency that is driving you. Which suggests another possible interpretation. What if 1) we set the OAM bit for any packet that needs OAM processing 2) And define a (set of) packet types for packets where the cotnent is OAM 3) And declare that any other packet types are user packets with OAM TLV information. This is slightly simpler if we declare a single OAM packet type in the NSH header, as that avoids any ambiguity. (Whether the device can actually do the OAM still depends upon it understanding the OAM packets, but that is true of all structures.) This does avoid creating any confusion between the use of the OAM flag and the packet type. Yours, Joel On 7/23/16 7:34 PM, Carlos Pignataro (cpignata) wrote: > Hi, Joel, > >> On Jul 23, 2016, at 7:45 PM, Joel M. Halpern wrote= : >> >> There is one situation that folks are asking for that seems not to be cl= early covered in the spec, and appears to me to be clarified by Greg's prop= osal. >> >> We have had a couple of requests for the ability to put OAM marking on u= ser data packets. The most obvious use is to monitor how long it takes NSH= -aware service functions to process the user packets. >> > > Just to make sure I understand, you are talking about the case of =93pigg= y-back OAM=94, correct? > >> If the only case where we will need this is for service function process= ing, the putting it in the TLVs, without additional markings, and allowing = the service functions which understand the TLV to work with it seems suffic= ient. >> >> But it is not clear to me that there is not a desire (whether it is a re= quirement is probably an important open question) for similar capability at= SFF. If we have situations where SFF, in passing user data packets, also = need to perform OAM operations, then it seems to me that we need the OAM bi= t to tell the SFF to look at this. > > If you set the O bit in a user data packet, how would a system infer that= =92s not an OAM packet? > > Thanks, > > =97 Carlos. > >> Efforts with routers to do this with router alert options have been a me= ss. If we need the capability, it seems to me that we really want it in a s= tandardized and efficient place. >> If we are very sure we don't need this, then we should write that down, = and move on. >> >> Yours, >> Joel >> >> On 7/23/16 12:24 PM, Carlos Pignataro (cpignata) wrote: >>> Hi, Greg, >>> >>>> On Jul 22, 2016, at 10:24 AM, Gregory Mirsky >>>> > wro= te: >>>> >>>> Hi Carlos, >>>> thank you for sharing your comments. If I understand correctly, you >>>> suggest to expose protocol types of OAM as Next Protocol rather than >>>> to use single Active OAM protocol type and use OOAM Header to demux >>>> OOAM type. Then, the Next Protocol registry will have to allocate >>>> values for single-hop BFD, multi-hop BFD, multipoint BFD, S-BFD, Echo >>>> Request/Reply, AIS protocol, Active Performance Measurement protocol, >>>> and I=92ve only listed some of AOM protocols that may be used to >>>> operate, administer and maintain SFP. >>> >>> Yes, the protocol field ought to register the OAM protocols that will b= e >>> used and implemented and deployed =97 of course not all potential >>> variations and permutations of possible OAMs (what is AIS protocol?) >>> >>>> Additionally, you=92ve suggested that only O-bit value to be used to >>>> determine whether packet should be processed as OAM or data packet. >>>> Hence should I expect that O-bit is set for BFD, AIS, and Echo >>>> Request/Reply payload and should not be set if the Next Protocol is >>>> neither of protocols listed above? Should such situation, i.e. Next >>>> Protocol value is MPLS and O-bit set to 0x1, should be viewed as error >>>> and the packet dropped? Or you propose that the Next Protocol takes >>>> precedence and the packet treated as data? Or packet viewed as OAM and >>>> passed to the local OAM entity? Or how to interpret situation when >>>> O-bit is cleared and the Next Protocol value is one of OAM protocols? >>>> This is the situation that, in my view, is ambiguous and >>>> under-specified in the current NSH document. My proposal is an attempt >>>> to make relationship between OAM and data packets more deterministic. >>> >>> Answering all those questions (which are really slight permutations of >>> the same question) in one shot: to me, O=3D0 is a data packet and O=3D1= is >>> an OAM packet. If the data processing does not have a handler for the >>> protocol in the PID, or it=92s an undefined, drops to the bit bucket. >>> Equally, if the OAM handler does not support the protocol ID carried as >>> OAM, puff. IP can carry data or OAM for example by the way. >>> >>> It does not get any simpler and unambiguous than that. What=92s the >>> advantage of moving the OAM PID further inside? >>> >>> And I do not believe there=92s underspecification in NSH -> O=3D1, OAM >>> treatment, not detailed here. >>> >>> Thanks, >>> >>> =97 Carlos. >>> >>>> >>>> Regards, >>>> Greg >>>> >>>> *From:* Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >>>> *Sent:* Friday, July 22, 2016 10:10 AM >>>> *To:* Gregory Mirsky >>> > >>>> *Cc:* sfc@ietf.org ; rtg-ooam-dt@ietf.org >>>> >>>> *Subject:* Re: [Rtg-ooam-dt] Identifying OAM in NSH >>>> >>>> Greg, >>>> >>>> >>>> Please find some comments inline. >>>> >>>> Thumb typed by Carlos Pignataro. >>>> Excuze typofraphicak errows >>>> >>>> >>>> On Jul 21, 2016, at 09:01, Gregory Mirsky >>> > wrote: >>>> >>>> Dear All, >>>> we had very good discussion on OAM this week. We=92ve touched on >>>> Active, Passive and Something-in-between OAM. But can NSH indicate >>>> which OAM type, if any, associated with a packet? I think that the >>>> current version of draft-ietf-sfc-nsh does not allow that and may >>>> be ambiguous in some cases. I propose change to interpretation and >>>> applicability description of the O(AM) flag and allocation of the >>>> new protocol type to be used in the Next Protocol field. >>>> >>>> >>>> >>>> Active, passive and something-in-between are not OAM protocol types >>>> but rather they are measuring methods. Active OAM can include a >>>> plurality of OAM protocols, including BFD, S-BFD, something-over-ip, e= tc. >>>> >>>> I also believe that the current OAM text in NSH is not ambiguous and >>>> allows enough processing of the header to understand something is OAM, >>>> without going the specifics of an OAM handler. >>>> >>>> Therefore, I oppose this change. >>>> >>>> >>>> RFC 7799 defines Active OAM as following: >>>> An Active Metric or Method depends on a dedicated measurement >>>> packet stream and observations of the stream. >>>> Thus, regardless of encapsulation used by OAM, it is the packet >>>> constructed solely for monitoring, measuring network=92s metric and >>>> should not leave given domain. And, I believe, such packets should >>>> be identified by the protocol type of their own. >>>> >>>> >>>> Seems you are advocating for a single "OAM" protocol type for OAM >>>> packets. The functionality of identifying something as OAM is in the >>>> O-bit, so no need to waste bits in duplication. >>>> >>>> Then, at some point, you have to differentiate if an OAM is, say, IP >>>> or "raw BFD" or something else. That's what the Protocol field is for. >>>> I do not see a need to add an indirection here to then have to have a >>>> protocol field inside the OAM. >>>> >>>> >>>> OAM which behaves as much as Passive OAM or Something-in-between, >>>> e.g. OAM appended to data packet either at the domain=92s edge or >>>> on-the-fly, identified by the protocol type of the data packet >>>> carried in NSH. >>>> >>>> >>>> That's correct, with the O bit cleared; it's a data packet and not an >>>> OAM one. >>>> >>>> >>>> Below are changes I=92d like to propose: >>>> Section 3.2 O-bit: >>>> OLD >>>> O bit: when set to 0x1 indicates that this packet is an Operatio= ns, >>>> Administration and Maintenance (OAM) message. The receiving >>>> SFF and >>>> SFs nodes MUST examine the payload and take appropriate action >>>> (e.g. >>>> return status information). OAM message specifics and handling >>>> details are outside the scope of this document. >>>> END >>>> NEW >>>> O bit: when set to 0x1 indicates that data packet identified by >>>> the Next >>>> Protocol type has OAM metadata appended. >>>> >>>> >>>> No. If it is a data packet it does not have the O bit set (to 1 or to >>>> whichever other possible value for the bit :-) >>>> >>>> The goal is that looking at a single but it can be understood if it is >>>> a data packet (which can be used, marked, etc. to be used for OAM >>>> purposes, or not). >>>> >>>> We do not want OAM direct exception processing for data packets. >>>> >>>> >>>> Definition of the format(s) >>>> used by OAM metadata is outside the scope of this document. >>>> END >>>> >>>> At the end of Section 3.2: >>>> OLD >>>> This draft defines the following Next Protocol values: >>>> >>>> 0x1 : IPv4 >>>> 0x2 : IPv6 >>>> 0x3 : Ethernet >>>> 0x4: NSH >>>> 0x5: MPLS >>>> 0x6-0xFD: Unassigned >>>> 0xFE-0xFF: Experimental >>>> END >>>> NEW >>>> This draft defines the following Next Protocol values: >>>> >>>> 0x1 : IPv4 >>>> 0x2 : IPv6 >>>> 0x3 : Ethernet >>>> 0x4: NSH >>>> 0x5: MPLS >>>> 0x6: Active OAM >>>> >>>> >>>> As per above I do not believe there's a single OAM protocol. >>>> >>>> >>>> 0x7-0xFD: Unassigned >>>> 0xFE-0xFF: Experimental >>>> END >>>> >>>> And, consequently, section 13.2.5 in IANA Considerations section >>>> will request allocation of value 0x6 to be assigned to Active OAM >>>> protocols. >>>> >>>> Greatly appreciate your consideration and comments. >>>> >>>> >>>> >>>> My =800.02. >>>> >>>> Thanks, >>>> >>>> Carlos. >>>> >>>> >>>> Regards, >>>> Greg >>>> >>>> >>>> _______________________________________________ >>>> Rtg-ooam-dt mailing list >>>> Rtg-ooam-dt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 Jul 24 05:26: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 4601712D095; Sun, 24 Jul 2016 05:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] 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 w-ePsMhSn5qB; Sun, 24 Jul 2016 05:25:53 -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 51E72127078; Sun, 24 Jul 2016 05:25:53 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Sun, 24 Jul 2016 08:25:51 -0400 From: Dave Dolson To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR5QkToxex5qfvO06IBz1JKa0fbKAm7PQAgACWArQ= Date: Sun, 24 Jul 2016 12:25:51 +0000 Message-ID: <20160724122550.5714005.36177.99632@sandvine.com> References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <9DBA673E-960C-49B0-9A90-4DB4828C08BE@cisco.com> <7347100B5761DC41A166AC17F22DF11221ADBCA5@eusaamb103.ericsson.se> <565E48DF-2D9E-43E6-BAB6-5376F926B609@cisco.com> <20160723173849.5714002.69288.99598@sandvine.com>, <60C37038-D54A-4DB9-9BE7-24377F176F1A@cisco.com> In-Reply-To: <60C37038-D54A-4DB9-9BE7-24377F176F1A@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: multipart/alternative; boundary="_000_2016072412255057140053617799632sandvinecom_" MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "rtg-ooam-dt@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 12:25:56 -0000 --_000_2016072412255057140053617799632sandvinecom_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Carlos, I don't find it satisfying to define a protocol which says if O=3D1 the be= havior is undefined. (Same outcome as when version!=3D0) But, while the NSH draft is mute on the topic, it is fair to speculate on v= arious schemes. =FDTrailing an OAM header is an alternative to putting piggyback OAM in the= metadata. I'm not sure where I heard it mentioned. Perhaps it was in the c= ontext of unified Overlay OAM. Logically if O=3D1, there must be an OAM hea= der, right? > If O=3D1 and the next protocol is IPv4, I=92d expect an IPv4 packet > encapsulating the OAM (either UDP-> BFD, or ICMP, for example). Do you mean check to see if the embedded IPv4 packet is addressed to the SFF itself? I.e., send the packet up the local ipv4 stack? From: Carlos Pignataro (cpignata) Sent: Saturday, July 23, 2016 7:29 PM To: Dave Dolson Cc: Gregory Mirsky; rtg-ooam-dt@ietf.org; sfc@ietf.org Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Hi, Dave, On Jul 23, 2016, at 6:38 PM, Dave Dolson > wrote: Carlos, I think some of what is being said in emails needs to be clarified in the d= ocument. It still isn't crystal clear to me. I agree that it needs to be clarified, with diagrams, and specs. However, w= hen you say =93in the document=94, I do not think those details belong in t= he NSH document itself. The NSH, in my humble opinion, needs to say how to = identify an OAM packet. If O=3D1, and next protocol is IPv4, can there be an OAM header piggy-backe= d with the IPv4? If so, before or after? Some drafts imply this is possible but nothing says how. If O=3D1 and the next protocol is IPv4, I=92d expect an IPv4 packet encapsu= lating the OAM (either UDP-> BFD, or ICMP, for example). With =93OAM header= =94, do you mean the OOAM DT header? What would be the use for those extra = bytes in this case? Thanks, =97 Carlos. -Dave From: Carlos Pignataro (cpignata) Sent: Saturday, July 23, 2016 12:25 PM To: Gregory Mirsky Cc: rtg-ooam-dt@ietf.org; sfc@ietf.org Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Hi, Greg, On Jul 22, 2016, at 10:24 AM, Gregory Mirsky > wrote: Hi Carlos, thank you for sharing your comments. If I understand correctly, you suggest= to expose protocol types of OAM as Next Protocol rather than to use single= Active OAM protocol type and use OOAM Header to demux OOAM type. Then, the= Next Protocol registry will have to allocate values for single-hop BFD, mu= lti-hop BFD, multipoint BFD, S-BFD, Echo Request/Reply, AIS protocol, Activ= e Performance Measurement protocol, and I=92ve only listed some of AOM prot= ocols that may be used to operate, administer and maintain SFP. Yes, the protocol field ought to register the OAM protocols that will be us= ed and implemented and deployed =97 of course not all potential variations = and permutations of possible OAMs (what is AIS protocol?) Additionally, you=92ve suggested that only O-bit value to be used to determ= ine whether packet should be processed as OAM or data packet. Hence should = I expect that O-bit is set for BFD, AIS, and Echo Request/Reply payload and= should not be set if the Next Protocol is neither of protocols listed abov= e? Should such situation, i.e. Next Protocol value is MPLS and O-bit set to= 0x1, should be viewed as error and the packet dropped? Or you propose that= the Next Protocol takes precedence and the packet treated as data? Or pack= et viewed as OAM and passed to the local OAM entity? Or how to interpret si= tuation when O-bit is cleared and the Next Protocol value is one of OAM pro= tocols? This is the situation that, in my view, is ambiguous and under-spec= ified in the current NSH document. My proposal is an attempt to make relati= onship between OAM and data packets more deterministic. Answering all those questions (which are really slight permutations of the = same question) in one shot: to me, O=3D0 is a data packet and O=3D1 is an O= AM packet. If the data processing does not have a handler for the protocol = in the PID, or it=92s an undefined, drops to the bit bucket. Equally, if th= e OAM handler does not support the protocol ID carried as OAM, puff. IP can= carry data or OAM for example by the way. It does not get any simpler and unambiguous than that. What=92s the advanta= ge of moving the OAM PID further inside? And I do not believe there=92s underspecification in NSH -> O=3D1, OAM trea= tment, not detailed here. Thanks, =97 Carlos. Regards, Greg From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Friday, July 22, 2016 10:10 AM To: Gregory Mirsky > Cc: sfc@ietf.org; rtg-ooam-dt@ietf.org Subject: Re: [Rtg-ooam-dt] Identifying OAM in NSH Greg, Please find some comments inline. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Jul 21, 2016, at 09:01, Gregory Mirsky > wrote: Dear All, we had very good discussion on OAM this week. We=92ve touched on Active, Pa= ssive and Something-in-between OAM. But can NSH indicate which OAM type, if= any, associated with a packet? I think that the current version of draft-i= etf-sfc-nsh does not allow that and may be ambiguous in some cases. I propo= se change to interpretation and applicability description of the O(AM) flag= and allocation of the new protocol type to be used in the Next Protocol fi= eld. Active, passive and something-in-between are not OAM protocol types but rat= her they are measuring methods. Active OAM can include a plurality of OAM p= rotocols, including BFD, S-BFD, something-over-ip, etc. I also believe that the current OAM text in NSH is not ambiguous and allows= enough processing of the header to understand something is OAM, without go= ing the specifics of an OAM handler. Therefore, I oppose this change. RFC 7799 defines Active OAM as following: An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream. Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network=92s metric and should not leave g= iven domain. And, I believe, such packets should be identified by the proto= col type of their own. Seems you are advocating for a single "OAM" protocol type for OAM packets. = The functionality of identifying something as OAM is in the O-bit, so no ne= ed to waste bits in duplication. Then, at some point, you have to differentiate if an OAM is, say, IP or "ra= w BFD" or something else. That's what the Protocol field is for. I do not s= ee a need to add an indirection here to then have to have a protocol field = inside the OAM. OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM = appended to data packet either at the domain=92s edge or on-the-fly, identi= fied by the protocol type of the data packet carried in NSH. That's correct, with the O bit cleared; it's a data packet and not an OAM o= ne. Below are changes I=92d like to propose: Section 3.2 O-bit: OLD O bit: when set to 0x1 indicates that this packet is an Operations, Administration and Maintenance (OAM) message. The receiving SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information). OAM message specifics and handling details are outside the scope of this document. END NEW O bit: when set to 0x1 indicates that data packet identified by the Next Protocol type has OAM metadata appended. No. If it is a data packet it does not have the O bit set (to 1 or to which= ever other possible value for the bit :-) The goal is that looking at a single but it can be understood if it is a da= ta packet (which can be used, marked, etc. to be used for OAM purposes, or = not). We do not want OAM direct exception processing for data packets. Definition of the format(s) used by OAM metadata is outside the scope of this document. END At the end of Section 3.2: OLD This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6-0xFD: Unassigned 0xFE-0xFF: Experimental END NEW This draft defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4: NSH 0x5: MPLS 0x6: Active OAM As per above I do not believe there's a single OAM protocol. 0x7-0xFD: Unassigned 0xFE-0xFF: Experimental END And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols. Greatly appreciate your consideration and comments. My =800.02. Thanks, Carlos. Regards, Greg _______________________________________________ Rtg-ooam-dt mailing list Rtg-ooam-dt@ietf.org https://www.ietf.org/mailman/listinfo/rtg-ooam-dt --_000_2016072412255057140053617799632sandvinecom_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
From: Carlos Pignataro (cpignata)
Sent: Saturday, July 23, 2016 7:29 PM
To: Dave Dolson
Cc: Gregory Mirsky; rtg-ooam-dt@ietf.org; sfc@ietf.org
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

Hi, Dave,

On Jul 23, 2016, at 6:38 PM, Dave Dolson <ddolson@sandvine.com> wrote:
Carlos,
I think some of what is being said in emails needs to be clarified in the d= ocument.
It still isn't crystal clear to me.


I agree that it needs to be clarified, with diagrams, and specs. Howev= er, when you say =93in the document=94, I do not think those details belong= in the NSH document itself. The NSH, in my humble opinion, needs to say ho= w to identify an OAM packet.

If O=3D1, and next protocol is IPv4, can there be an OAM header piggy-backe= d with the IPv4? If so, before or after?
Some drafts imply this is possible but nothing says how.

If O=3D1 and the next protocol is IPv4, I=92d expect an IPv4 packet en= capsulating the OAM (either UDP-> BFD, or ICMP, for example). With =93OA= M header=94, do you mean the OOAM DT header? What would be the use for thos= e extra bytes in this case?

Thanks,

=97 Carlos.


-Dave


From: Carlos Pignataro (cpignata)
Sent: Saturday, July 23, 2016 12:25 PM
To: Gregory Mirsky
Cc: rtg-ooam-dt@ietf.org; sfc@ietf.org
Subject: Re: [sfc] [Rtg-ooam-dt] Identify= ing OAM in NSH

Hi, Greg,

On Jul 22, 2016, at 10:24 AM, Gregory Mirsky <gregory.mirsky@ericsson.com= > wrote:

Hi Carlos,
thank you for sharing your comments. If I understand correctly, you suggest= to expose protocol types of OAM as Next Protocol rather than to use single= Active OAM protocol type and use OOAM Header to demux OOAM type. Then, the= Next Protocol registry will have to allocate values for single-hop BFD, multi-hop BFD, multipoint BFD, S-BF= D, Echo Request/Reply, AIS protocol, Active Performance Measurement protoco= l, and I=92ve only listed some of AOM protocols that may be used to operate= , administer and maintain SFP.

Yes, the protocol field ought to register the OAM protocols= that will be used and implemented and deployed =97 of course not all poten= tial variations and permutations of possible OAMs (what is AIS protocol?)
Additionally, you=92ve suggested that only O-bit value to be used to determ= ine whether packet should be processed as OAM or data packet. Hence should = I expect that O-bit is set for BFD, AIS, and Echo Request/Reply payload and= should not be set if the Next Protocol is neither of protocols listed above? Should such situation, i.e. Next Pro= tocol value is MPLS and O-bit set to 0x1, should be viewed as error and the= packet dropped? Or you propose that the Next Protocol takes precedence and= the packet treated as data? Or packet viewed as OAM and passed to the local OAM entity? Or how to interpr= et situation when O-bit is cleared and the Next Protocol value is one of OA= M protocols? This is the situation that, in my view, is ambiguous and under= -specified in the current NSH document. My proposal is an attempt to make relationship between OAM and data packet= s more deterministic.

Answering all those questions (which are really slight perm= utations of the same question) in one shot: to me, O=3D0 is a data packet a= nd O=3D1 is an OAM packet. If the data processing does not have a handler f= or the protocol in the PID, or it=92s an undefined, drops to the bit bucket. Equally, if the OAM handler does not s= upport the protocol ID carried as OAM, puff. IP can carry data or OAM for e= xample by the way.

It does not get any simpler and unambiguous than that. What= =92s the advantage of moving the OAM PID further inside?

And I do not believe there=92s underspecification in NSH -&= gt; O=3D1, OAM treatment, not detailed here.

Thanks,

=97 Carlos.

 
            &nb= sp;   Regards,
            &nb= sp;            =        Greg
 
From: C= arlos Pignataro (cpignata) [mailto:cpignata@cisco.com] = ;
Sent: F= riday, July 22, 2016 10:10 AM
To: Gre= gory Mirsky <g= regory.mirsky@ericsson.com>
Cc: sfc@ietf.org; rtg-ooam-dt@ietf.org=
Subject: Re: [Rtg-ooam-dt] Identifying OAM in NSH
 
Greg,
 

Please find some comments inline. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows


On Jul 21, 2016, at 09:01, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear All,
we had very good discussion on OAM this week. We=92ve touched on Active, Pa= ssive and Something-in-between OAM. But can NSH indicate which OAM type, if= any, associated with a packet? I think that the current version of draft-i= etf-sfc-nsh does not allow that and may be ambiguous in some cases. I propose change to interpretation and app= licability description of the O(AM) flag and allocation of the new protocol= type to be used in the Next Protocol field.
 
 
Active, passive and something-in-between are not OAM protocol types but= rather they are measuring methods. Active OAM can include a plurality of O= AM protocols, including BFD, S-BFD, something-over-ip, etc. 
 
I also believe that the current OAM text in NSH is not ambiguous and al= lows enough processing of the header to understand something is OAM, withou= t going the specifics of an OAM handler. 
 
Therefore, I oppose this change. 


RFC 7799 defines Active OAM as following:
An Active Metric or Method depends on a dedicated measurement packet stream= and observations of the stream.
Thus, regardless of encapsulation used by OAM, it is the packet constructed= solely for monitoring, measuring network=92s metric and should not leave g= iven domain. And, I believe, such packets should be identified by the proto= col type of their own. 
 
Seems you are advocating for a single "OAM" protocol type for= OAM packets. The functionality of identifying something as OAM is in the O= -bit, so no need to waste bits in duplication. 
 
Then, at some point, you have to differentiate if an OAM is, say, IP or= "raw BFD" or something else. That's what the Protocol field is f= or. I do not see a need to add an indirection here to then have to have a protocol field inside the OAM. 


OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM = appended to data packet either at the domain=92s edge or on-the-fly, identi= fied by the protocol type of the data packet carried in NSH.
 
That's correct, with the O bit cleared; it's a data packet and not an O= AM one. 


Below are changes I=92d like to propose:
Section 3.2 O-bit:
OLD
   O bit: when set to 0x1 indicates that this packet is an Operat= ions,
   Administration and Maintenance (OAM) message.  The receiv= ing SFF and
   SFs nodes MUST examine the payload and take appropriate action= (e.g.
   return status information).  OAM message specifics and ha= ndling
   details are outside the scope of this document.
END
NEW
O bit: when set to 0x1 indicates that data packet identified by the Next
Protocol type has OAM metadata appended. 
 
No. If it is a data packet it does not have the O bit set (to 1 or to w= hichever other possible value for the bit :-)
 
The goal is that looking at a single but it can be understood if it is = a data packet (which can be used, marked, etc. to be used for OAM purposes,= or not). 
 
We do not want OAM direct exception processing for data packets. <= /span>


Definition of the format(s) 
used by OAM metadata is outside the scope of this document.
END
 
At the end of Section 3.2:
OLD
   This draft defines the following Next Protocol values:
 
   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW
   This draft defines the following Next Protocol values:
 
   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM
 
As per above I do not believe there's a single OAM protocol. 


   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
 
And, consequently, section 13.2.5 in IANA Considerations section will reque= st allocation of value 0x6 to be assigned to Active OAM protocols.
 
Greatly appreciate your consideration and comments.
 
 
My =800.02. 
 
Thanks,
 
Carlos. 


            &nb= sp;   Regards,
            &nb= sp;            =        Greg
 
_______________________________________________
Rtg-ooam-dt mailing list
Rtg-ooam-dt@ietf.org
https://www.ietf.org/mailma= n/listinfo/rtg-ooam-dt


--_000_2016072412255057140053617799632sandvinecom_-- From nobody Mon Jul 25 14:56: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 85DE512DA54 for ; Mon, 25 Jul 2016 14:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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.287, 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 lGMcrEiAXGGl for ; Mon, 25 Jul 2016 14:56:10 -0700 (PDT) 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 6C05412D1D8 for ; Mon, 25 Jul 2016 14:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1648; q=dns/txt; s=iport; t=1469483770; x=1470693370; h=from:to:subject:date:message-id:mime-version; bh=ilsZfPX+Y3MMLndjnj4HP8Tc1HT23vz/L2AzKF4is20=; b=mcQCnB/J54KIUNzdFXiObFaM/B9cR1o1V7/7K0EvupCTyM+voERard05 gFj39AJ8Kdieq9oz/yFsmIdS5lj1H5MZZGwIrVpa5umRG+VswFugfODQP SAxgOnFkLpLo6R5SVYQP8wkoGu87f+/shLA5ENOucEh2jnG99JSpGntfJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AgC3iZZX/4wNJK1cgnFOgVizaIUFg?= =?us-ascii?q?XyGO4EnOBQBAQEBAQEBXRwLhFMQI2gBCwE+AgQwJwSIQ5hwj2ONWAEBAQEBBQE?= =?us-ascii?q?BAQEBAQEBAR6GKoF4ihYrgi8FmSgBjm6BbIRaiHmQIAEeNoNziEx/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,421,1464652800"; d="scan'208,217";a="301396242" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2016 21:56:09 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6PLu9iM015517 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Jul 2016 21:56:09 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, 25 Jul 2016 16:56:08 -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; Mon, 25 Jul 2016 16:56:09 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: WG adoption of draft-dolson-sfc-hierarchical-06 Thread-Index: AQHR5r9ZQoFfZuUTS0ubb6qfXCK1IQ== Date: Mon, 25 Jul 2016 21:56:08 +0000 Message-ID: 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_FE4A3B41652D4A81AF0BC592DF0356E1ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] WG adoption of draft-dolson-sfc-hierarchical-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 25 Jul 2016 21:56:11 -0000 --_000_FE4A3B41652D4A81AF0BC592DF0356E1ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZXRpbmdzIFdHOg0KDQpXZSBoYXZlIHJlY2VpdmVkIGdvb2Qgc3VwcG9ydCBmb3IgdGhlIGFk b3B0aW9uIG9mIGRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTA2IGFzIGEgV0cgZG9jdW1l bnQuDQoNCkF1dGhvcnMsIGNhbiB5b3UgcGxlYXNlIHBvc3QgYSBuZXcgdmVyc2lvbiBhcyBkcmFm dC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDAuDQoNCkppbSwgTWFydGluICYgVGhvbWFzDQo= --_000_FE4A3B41652D4A81AF0BC592DF0356E1ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8F26F8BCC5822D41AF59731D35FE84AB@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkdyZWV0aW5ncyBXRzo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlIGhhdmUg cmVjZWl2ZWQgZ29vZCBzdXBwb3J0IGZvciB0aGUgYWRvcHRpb24gb2YgZHJhZnQtZG9sc29uLXNm Yy1oaWVyYXJjaGljYWwtMDYgYXMgYSBXRyBkb2N1bWVudC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkF1dGhvcnMsIGNhbiB5b3UgcGxlYXNlIHBvc3QgYSBuZXcgdmVyc2lv biBhcyBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDAuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5KaW0sIE1hcnRpbiAmYW1wOyBUaG9tYXM8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlk PSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_FE4A3B41652D4A81AF0BC592DF0356E1ciscocom_-- From nobody Tue Jul 26 09:03:35 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 AD39612B01C; Tue, 26 Jul 2016 09:03:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160726160330.30917.19747.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2016 09:03:30 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 16:03:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Hierarchical Service Function Chaining (hSFC) Authors : David Dolson Shunsuke Homma Diego R. Lopez Mohamed Boucadair Dapeng Liu Ting Ao Vu Anh Vu Filename : draft-ietf-sfc-hierarchical-00.txt Pages : 23 Date : 2016-07-26 Abstract: Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to compartmentalize a large- scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to reason about, simpler to control and to able support independent functional groups within large operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 27 04:25:47 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 AE74512E040 for ; Wed, 27 Jul 2016 04:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 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.287, 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 jBs6yIRERQg1 for ; Wed, 27 Jul 2016 04:25:44 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.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 B716012E03C for ; Wed, 27 Jul 2016 04:25:42 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 1590E404C9 for ; Wed, 27 Jul 2016 13:25:41 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id E6A371A006D for ; Wed, 27 Jul 2016 13:25:40 +0200 (CEST) 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.0301.000; Wed, 27 Jul 2016 13:25:40 +0200 From: To: "sfc@ietf.org" Thread-Topic: I-D Action: draft-ietf-sfc-hierarchical-00.txt Thread-Index: AQHR51dOmj+SupHZCEqk92251G3i1KAsIqGw Date: Wed, 27 Jul 2016 11:25:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DED108@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20160726160330.30917.19747.idtracker@ietfa.amsl.com> In-Reply-To: <20160726160330.30917.19747.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.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] I-D Action: draft-ietf-sfc-hierarchical-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, 27 Jul 2016 11:25:46 -0000 Dear all,=20 In the prez made in the last IETF meeting (https://www.ietf.org/proceedings= /96/slides/slides-96-sfc-7.pdf), we raised some points for which we would l= ike to hear some feedback from the WG. =20 Also, given that several iterations of the document were made in the past, = we are seeking for volunteers with fresh eyes to review the document. Don't= hesitate to contact us if you are planning to review.=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mardi 26 juillet 2016 18:04 > =C0=A0: i-d-announce@ietf.org > Cc=A0: sfc@ietf.org > Objet=A0: I-D Action: draft-ietf-sfc-hierarchical-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Service Function Chaining of the IETF. >=20 > Title : Hierarchical Service Function Chaining (hSFC) > Authors : David Dolson > Shunsuke Homma > Diego R. Lopez > Mohamed Boucadair > Dapeng Liu > Ting Ao > Vu Anh Vu > Filename : draft-ietf-sfc-hierarchical-00.txt > Pages : 23 > Date : 2016-07-26 >=20 > Abstract: > Hierarchical Service Function Chaining (hSFC) is a network > architecture allowing an organization to compartmentalize a large- > scale network into multiple domains of administration. >=20 > The goals of hSFC are to make a large-scale network easier to reason > about, simpler to control and to able support independent functional > groups within large operators. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt