From nobody Fri Aug 5 04:55: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 1CE6712D9E6; Wed, 27 Jul 2016 16:13:19 -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 EiVJphuXkavC; Wed, 27 Jul 2016 16:13:15 -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 1E67F12DA26; Wed, 27 Jul 2016 16:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37196; q=dns/txt; s=iport; t=1469661195; x=1470870795; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oVgSZ915QoR2U9nzpibTD/4tuUW97C0FQqmK3JDo65E=; b=T2BD/4HNabQYBfyut6KhP3n2pTSzQpDymetFGREXfpN25dfuST9tIVVQ 1zkWVWbGfOcFJHcKXE5/17INK/dO+5R3SKjhli8fitR1DadI79Y1SA8Pv SdDPAcriRhKk33BNVuTuWLOq1G3mIgK5hkb9ecrCVr82yrUfjOzP25/hV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQBdP5lX/4UNJK1dgnFOVm4OBrZbg?= =?us-ascii?q?g+BfSSFeQKBNTgUAQEBAQEBAV0nhFwBAQUtOhIQAgEIEQMBAiEBBgcyFAkIAgQ?= =?us-ascii?q?BDQWIMQ67YgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqETYQSEQEqEhiFIwWTb?= =?us-ascii?q?4VCAYYXiGSBa4RaiHmMLYN3AR42gkOBNW6HUzZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,431,1464652800"; d="scan'208,217";a="302418240" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2016 23:13:13 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6RNDDfs011977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Jul 2016 23:13:13 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 27 Jul 2016 18:13: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; Wed, 27 Jul 2016 18:13:12 -0500 From: "Saumya Dikshit (sadikshi)" To: "Saumya Dikshit (sadikshi)" , "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: AQHR4ocViWBwwTTmV0mY2c9hkRwUbKAjx0CAgAArxgCACXYfAA== Date: Wed, 27 Jul 2016 23:13:12 +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.86.52] Content-Type: multipart/alternative; boundary="_000_D3BF0C676C0F3sadikshiciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 05 Aug 2016 04:55:43 -0700 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: Wed, 27 Jul 2016 23:13:19 -0000 --_000_D3BF0C676C0F3sadikshiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Authors, Please do know your views on having these requirements as part of the docum= ent, as deepak also mentioned in the below format. Thanks Saumya. From: rtgwg > on beha= lf of sadikshi > Date: Friday, July 22, 2016 at 12:44 AM 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" > Cc: "rbonica@juniper.net" > Subject: Re: [Rtg-ooam-dt] [nvo3] [Bier] Comments to OOAM Requirements draf= t from Ron Bonica 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_D3BF0C676C0F3sadikshiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello Authors,

Please do know your views on having these requirements as part of the = document, as deepak also mentioned in the below format.

Thanks
Saumya.

From: rtgwg <rtgwg-bounces@ietf.org> on behalf of sadikshi= <sadikshi@cisco.com>
Date: Friday, July 22, 2016 at 12:4= 4 AM
To: "Deepak Kumar (dekumar)&qu= ot; <dekumar@cisco.com>, &qu= ot;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

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_D3BF0C676C0F3sadikshiciscocom_-- From nobody Mon Aug 8 17:31:49 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEAD12D5A5; Mon, 8 Aug 2016 17:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.767 X-Spam-Level: X-Spam-Status: No, score=-15.767 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.247, 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 11GEp5MKdcKq; Mon, 8 Aug 2016 17:31:09 -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 8A72312D59E; Mon, 8 Aug 2016 17:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67074; q=dns/txt; s=iport; t=1470702669; x=1471912269; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NV8AdPoZmkRVBddBtTYTVT0BSBQWwuQ0Q1l0vd+ZJ4k=; b=SYIP0QkH520hcC7DoWMBKjwmU01uGir6jIjhBpojcW7GwkQSbD4Hcm5A uO7zL08mmNzNVJI+zZ+j28Lr80RqjDf0BHaYj3J4GjROqgIbCsnaCVi7Y ULZKKZF+memu1jZC3L7fFfRHcymOiPClFwg/r0GUe0O1riXDLqa4sWpOF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAgCjI6lX/4kNJK1TCoJ3TlZ8B7kXg?= =?us-ascii?q?X0khXkCHIEmOBQBAQEBAQEBXSeEXgEBBAEBASEEQAcEBwULAgEIDgMEAQEhAQY?= =?us-ascii?q?DAgICJQsUCQgCBA4FiCkIDrJykBsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqg?= =?us-ascii?q?XgIgk2EGD8fgksrgi8Fk3WFRAGPCYFrhFuIfYw0g3cBHjaCDwMcgUxuhXd/AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.28,492,1464652800"; d="scan'208,217";a="137726204" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Aug 2016 00:31:08 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u790V7tx016633 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 00:31:07 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; Mon, 8 Aug 2016 20:31:06 -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; Mon, 8 Aug 2016 20:31:06 -0400 From: "Carlos Pignataro (cpignata)" To: Dave Dolson Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR4/B/s+mJr49HL0uqnvaJ3glSK6AkcOaAgAIHwQCAABSrAIAAYdCAgADZEoCAGF2bAA== Date: Tue, 9 Aug 2016 00:31:06 +0000 Message-ID: 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> <20160724122550.5714005.36177.99632@sandvine.com> In-Reply-To: <20160724122550.5714005.36177.99632@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.82.213.152] Content-Type: multipart/alternative; boundary="_000_A19424902E4E499F9319AC2A1110F5FCciscocom_" 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: Tue, 09 Aug 2016 00:31:12 -0000 --_000_A19424902E4E499F9319AC2A1110F5FCciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2ZSwNCg0KW0Fwb2xvZ2llcyBmb3IgdGhlIGRlbGF5IGluIHJlc3BvbmRpbmcg4oCUIEkgd2Fz IG9uIHZhY2F0aW9uXQ0KDQpJIGFwcHJlY2lhdGUgdGhlIGhlYWx0aHkgdGVuc2lvbiBiZXR3ZWVu IG92ZXItIGFuZCB1bmRlci1zcGVjaWZ5aW5nLiBJIGRvIG5vdCB0aGluayBob3dldmVyIHRoYXQg dGhlIGJlaGF2aW9yIGlzIHVuZGVmaW5lZCBpbiB0aGlzIHBhcnRpY3VsYXIgY2FzZS4NCg0KVG8g bWUsIHRoZSBzcGVjaWZpY2F0aW9uIGlzOiDigJx3aGVuIE89MSwgdGhlbiB0aGUgcGFja2V0IGlz IGFuIE9BTSBwYWNrZXQgcHJvY2Vzc2VkIGJ5IGFuIE9BTSBtb2R1bGXigJ0gd2l0aCB0aGUgY29y b2xsYXJpZXMgcmVnYXJkaW5nIHRoZSBPQU0gaGFuZGluZzogKHdpdGggdGhlIE9BTSBtb2R1bGUg cHJvY2Vzc2luZyBkZWZpbmVkIGluIGEgc2VwYXJhdGUgcGxhY2UpIGFuZCAoaWYgdGhlIE9BTSBt b2R1bGUgaXMgTlVMTCAoZG9lcyBub3QgZXhpc3QpLCB0aGVuIHRoZSBwYWNrZXQgZ29lcyB0byB0 aGUgYml0LWJ1Y2tldCkNCg0KTz0xIGRvZXMgbm90IG1lYW4gYW4gT0FNIGhlYWRlciBmb2xsb3dz LiBJdCBtZWFucyBpdOKAmXMgYW4gT0FNIHBhY2tldC4gQW5kIE9BTSBpcyBub3QgYSBwcm90b2Nv bCB0eXBlLCBpdOKAmXMgYSBzZXQgb2YgZnVuY3Rpb25hbGl0aWVzIHJlYWxpemVkIGJ5IHZhcmlv dXMgcHJvdG9jb2xzIHBvdGVudGlhbGx5Lg0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCk9u IEp1bCAyNCwgMjAxNiwgYXQgMjoyNSBQTSwgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUu Y29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+IHdyb3RlOg0KDQpDYXJsb3MsDQpJIGRv bid0IGZpbmQgaXQgc2F0aXNmeWluZyAgdG8gZGVmaW5lIGEgcHJvdG9jb2wgd2hpY2ggc2F5cyBp ZiBPPTEgdGhlIGJlaGF2aW9yIGlzIHVuZGVmaW5lZC4gKFNhbWUgb3V0Y29tZSBhcyB3aGVuIHZl cnNpb24hPTApDQoNCkJ1dCwgd2hpbGUgdGhlIE5TSCBkcmFmdCBpcyBtdXRlIG9uIHRoZSB0b3Bp YywgaXQgaXMgZmFpciB0byBzcGVjdWxhdGUgb24gdmFyaW91cyAgc2NoZW1lcy4NCg0K4oCOVHJh aWxpbmcgYW4gT0FNIGhlYWRlciBpcyBhbiBhbHRlcm5hdGl2ZSB0byBwdXR0aW5nIHBpZ2d5YmFj ayBPQU0gaW4gdGhlIG1ldGFkYXRhLiBJJ20gbm90IHN1cmUgd2hlcmUgSSBoZWFyZCBpdCBtZW50 aW9uZWQuIFBlcmhhcHMgaXQgd2FzIGluIHRoZSBjb250ZXh0IG9mIHVuaWZpZWQgT3ZlcmxheSBP QU0uIExvZ2ljYWxseSBpZiBPPTEsIHRoZXJlIG11c3QgYmUgYW4gT0FNIGhlYWRlciwgcmlnaHQ/ DQoNCj4gSWYgTz0xIGFuZCB0aGUgbmV4dCBwcm90b2NvbCBpcyBJUHY0LCBJ4oCZZCBleHBlY3Qg YW4gSVB2NCBwYWNrZXQNCj4gZW5jYXBzdWxhdGluZyB0aGUgT0FNIChlaXRoZXIgVURQLT4gQkZE LCBvciBJQ01QLCBmb3IgZXhhbXBsZSkuDQpEbyB5b3UgbWVhbiBjaGVjayB0byBzZWUgaWYgdGhl IGVtYmVkZGVkIElQdjQgcGFja2V0IGlzIGFkZHJlc3NlZCB0bw0KdGhlIFNGRiBpdHNlbGY/IEku ZS4sIHNlbmQgdGhlIHBhY2tldCB1cCB0aGUgbG9jYWwgaXB2NCBzdGFjaz8NCg0KDQoNCg0KRnJv bTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQpTZW50OiBTYXR1cmRheSwgSnVseSAyMywg MjAxNiA3OjI5IFBNDQpUbzogRGF2ZSBEb2xzb24NCkNjOiBHcmVnb3J5IE1pcnNreTsgcnRnLW9v YW0tZHRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1vb2FtLWR0QGlldGYub3JnPjsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gW1J0Zy1vb2FtLWR0XSBJ ZGVudGlmeWluZyBPQU0gaW4gTlNIDQoNCg0KSGksIERhdmUsDQoNCk9uIEp1bCAyMywgMjAxNiwg YXQgNjozOCBQTSwgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9s c29uQHNhbmR2aW5lLmNvbT4+IHdyb3RlOg0KDQpDYXJsb3MsDQpJIHRoaW5rIHNvbWUgb2Ygd2hh dCBpcyBiZWluZyBzYWlkIGluIGVtYWlscyBuZWVkcyB0byBiZSBjbGFyaWZpZWQgaW4gdGhlIGRv Y3VtZW50Lg0KSXQgc3RpbGwgaXNuJ3QgY3J5c3RhbCBjbGVhciB0byBtZS4NCg0KDQpJIGFncmVl IHRoYXQgaXQgbmVlZHMgdG8gYmUgY2xhcmlmaWVkLCB3aXRoIGRpYWdyYW1zLCBhbmQgc3BlY3Mu IEhvd2V2ZXIsIHdoZW4geW91IHNheSDigJxpbiB0aGUgZG9jdW1lbnTigJ0sIEkgZG8gbm90IHRo aW5rIHRob3NlIGRldGFpbHMgYmVsb25nIGluIHRoZSBOU0ggZG9jdW1lbnQgaXRzZWxmLiBUaGUg TlNILCBpbiBteSBodW1ibGUgb3BpbmlvbiwgbmVlZHMgdG8gc2F5IGhvdyB0byBpZGVudGlmeSBh biBPQU0gcGFja2V0Lg0KDQpJZiBPPTEsIGFuZCBuZXh0IHByb3RvY29sIGlzIElQdjQsIGNhbiB0 aGVyZSBiZSBhbiBPQU0gaGVhZGVyIHBpZ2d5LWJhY2tlZCB3aXRoIHRoZSBJUHY0PyBJZiBzbywg YmVmb3JlIG9yIGFmdGVyPw0KU29tZSBkcmFmdHMgaW1wbHkgdGhpcyBpcyBwb3NzaWJsZSBidXQg bm90aGluZyBzYXlzIGhvdy4NCg0KSWYgTz0xIGFuZCB0aGUgbmV4dCBwcm90b2NvbCBpcyBJUHY0 LCBJ4oCZZCBleHBlY3QgYW4gSVB2NCBwYWNrZXQgZW5jYXBzdWxhdGluZyB0aGUgT0FNIChlaXRo ZXIgVURQLT4gQkZELCBvciBJQ01QLCBmb3IgZXhhbXBsZSkuIFdpdGgg4oCcT0FNIGhlYWRlcuKA nSwgZG8geW91IG1lYW4gdGhlIE9PQU0gRFQgaGVhZGVyPyBXaGF0IHdvdWxkIGJlIHRoZSB1c2Ug Zm9yIHRob3NlIGV4dHJhIGJ5dGVzIGluIHRoaXMgY2FzZT8NCg0KVGhhbmtzLA0KDQrigJQgQ2Fy bG9zLg0KDQoNCi1EYXZlDQoNCg0KRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQpT ZW50OiBTYXR1cmRheSwgSnVseSAyMywgMjAxNiAxMjoyNSBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5 DQpDYzogcnRnLW9vYW0tZHRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1vb2FtLWR0QGlldGYub3JnPjsg c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gW1J0 Zy1vb2FtLWR0XSBJZGVudGlmeWluZyBPQU0gaW4gTlNIDQoNCg0KSGksIEdyZWcsDQoNCk9uIEp1 bCAyMiwgMjAxNiwgYXQgMTA6MjQgQU0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K DQpIaSBDYXJsb3MsDQp0aGFuayB5b3UgZm9yIHNoYXJpbmcgeW91ciBjb21tZW50cy4gSWYgSSB1 bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IHN1Z2dlc3QgdG8gZXhwb3NlIHByb3RvY29sIHR5cGVz IG9mIE9BTSBhcyBOZXh0IFByb3RvY29sIHJhdGhlciB0aGFuIHRvIHVzZSBzaW5nbGUgQWN0aXZl IE9BTSBwcm90b2NvbCB0eXBlIGFuZCB1c2UgT09BTSBIZWFkZXIgdG8gZGVtdXggT09BTSB0eXBl LiBUaGVuLCB0aGUgTmV4dCBQcm90b2NvbCByZWdpc3RyeSB3aWxsIGhhdmUgdG8gYWxsb2NhdGUg dmFsdWVzIGZvciBzaW5nbGUtaG9wIEJGRCwgbXVsdGktaG9wIEJGRCwgbXVsdGlwb2ludCBCRkQs IFMtQkZELCBFY2hvIFJlcXVlc3QvUmVwbHksIEFJUyBwcm90b2NvbCwgQWN0aXZlIFBlcmZvcm1h bmNlIE1lYXN1cmVtZW50IHByb3RvY29sLCBhbmQgSeKAmXZlIG9ubHkgbGlzdGVkIHNvbWUgb2Yg QU9NIHByb3RvY29scyB0aGF0IG1heSBiZSB1c2VkIHRvIG9wZXJhdGUsIGFkbWluaXN0ZXIgYW5k IG1haW50YWluIFNGUC4NCg0KWWVzLCB0aGUgcHJvdG9jb2wgZmllbGQgb3VnaHQgdG8gcmVnaXN0 ZXIgdGhlIE9BTSBwcm90b2NvbHMgdGhhdCB3aWxsIGJlIHVzZWQgYW5kIGltcGxlbWVudGVkIGFu ZCBkZXBsb3llZCDigJQgb2YgY291cnNlIG5vdCBhbGwgcG90ZW50aWFsIHZhcmlhdGlvbnMgYW5k IHBlcm11dGF0aW9ucyBvZiBwb3NzaWJsZSBPQU1zICh3aGF0IGlzIEFJUyBwcm90b2NvbD8pDQoN CkFkZGl0aW9uYWxseSwgeW914oCZdmUgc3VnZ2VzdGVkIHRoYXQgb25seSBPLWJpdCB2YWx1ZSB0 byBiZSB1c2VkIHRvIGRldGVybWluZSB3aGV0aGVyIHBhY2tldCBzaG91bGQgYmUgcHJvY2Vzc2Vk IGFzIE9BTSBvciBkYXRhIHBhY2tldC4gSGVuY2Ugc2hvdWxkIEkgZXhwZWN0IHRoYXQgTy1iaXQg aXMgc2V0IGZvciBCRkQsIEFJUywgYW5kIEVjaG8gUmVxdWVzdC9SZXBseSBwYXlsb2FkIGFuZCBz aG91bGQgbm90IGJlIHNldCBpZiB0aGUgTmV4dCBQcm90b2NvbCBpcyBuZWl0aGVyIG9mIHByb3Rv Y29scyBsaXN0ZWQgYWJvdmU/IFNob3VsZCBzdWNoIHNpdHVhdGlvbiwgaS5lLiBOZXh0IFByb3Rv Y29sIHZhbHVlIGlzIE1QTFMgYW5kIE8tYml0IHNldCB0byAweDEsIHNob3VsZCBiZSB2aWV3ZWQg YXMgZXJyb3IgYW5kIHRoZSBwYWNrZXQgZHJvcHBlZD8gT3IgeW91IHByb3Bvc2UgdGhhdCB0aGUg TmV4dCBQcm90b2NvbCB0YWtlcyBwcmVjZWRlbmNlIGFuZCB0aGUgcGFja2V0IHRyZWF0ZWQgYXMg ZGF0YT8gT3IgcGFja2V0IHZpZXdlZCBhcyBPQU0gYW5kIHBhc3NlZCB0byB0aGUgbG9jYWwgT0FN IGVudGl0eT8gT3IgaG93IHRvIGludGVycHJldCBzaXR1YXRpb24gd2hlbiBPLWJpdCBpcyBjbGVh cmVkIGFuZCB0aGUgTmV4dCBQcm90b2NvbCB2YWx1ZSBpcyBvbmUgb2YgT0FNIHByb3RvY29scz8g VGhpcyBpcyB0aGUgc2l0dWF0aW9uIHRoYXQsIGluIG15IHZpZXcsIGlzIGFtYmlndW91cyBhbmQg dW5kZXItc3BlY2lmaWVkIGluIHRoZSBjdXJyZW50IE5TSCBkb2N1bWVudC4gTXkgcHJvcG9zYWwg aXMgYW4gYXR0ZW1wdCB0byBtYWtlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIE9BTSBhbmQgZGF0YSBw YWNrZXRzIG1vcmUgZGV0ZXJtaW5pc3RpYy4NCg0KQW5zd2VyaW5nIGFsbCB0aG9zZSBxdWVzdGlv bnMgKHdoaWNoIGFyZSByZWFsbHkgc2xpZ2h0IHBlcm11dGF0aW9ucyBvZiB0aGUgc2FtZSBxdWVz dGlvbikgaW4gb25lIHNob3Q6IHRvIG1lLCBPPTAgaXMgYSBkYXRhIHBhY2tldCBhbmQgTz0xIGlz IGFuIE9BTSBwYWNrZXQuIElmIHRoZSBkYXRhIHByb2Nlc3NpbmcgZG9lcyBub3QgaGF2ZSBhIGhh bmRsZXIgZm9yIHRoZSBwcm90b2NvbCBpbiB0aGUgUElELCBvciBpdOKAmXMgYW4gdW5kZWZpbmVk LCBkcm9wcyB0byB0aGUgYml0IGJ1Y2tldC4gRXF1YWxseSwgaWYgdGhlIE9BTSBoYW5kbGVyIGRv ZXMgbm90IHN1cHBvcnQgdGhlIHByb3RvY29sIElEIGNhcnJpZWQgYXMgT0FNLCBwdWZmLiBJUCBj YW4gY2FycnkgZGF0YSBvciBPQU0gZm9yIGV4YW1wbGUgYnkgdGhlIHdheS4NCg0KSXQgZG9lcyBu b3QgZ2V0IGFueSBzaW1wbGVyIGFuZCB1bmFtYmlndW91cyB0aGFuIHRoYXQuIFdoYXTigJlzIHRo ZSBhZHZhbnRhZ2Ugb2YgbW92aW5nIHRoZSBPQU0gUElEIGZ1cnRoZXIgaW5zaWRlPw0KDQpBbmQg SSBkbyBub3QgYmVsaWV2ZSB0aGVyZeKAmXMgdW5kZXJzcGVjaWZpY2F0aW9uIGluIE5TSCAtPiBP PTEsIE9BTSB0cmVhdG1lbnQsIG5vdCBkZXRhaWxlZCBoZXJlLg0KDQpUaGFua3MsDQoNCuKAlCBD YXJsb3MuDQoNCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFtt YWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KU2VudDogRnJpZGF5LCBKdWx5IDIyLCAyMDE2IDEw OjEwIEFNDQpUbzogR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxt YWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4NCkNjOiBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz47IHJ0Zy1vb2FtLWR0QGlldGYub3JnPG1haWx0bzpydGctb29hbS1k dEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUnRnLW9vYW0tZHRdIElkZW50aWZ5aW5nIE9BTSBp biBOU0gNCg0KR3JlZywNCg0KUGxlYXNlIGZpbmQgc29tZSBjb21tZW50cyBpbmxpbmUuDQpUaHVt YiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0YXJvLg0KRXhjdXplIHR5cG9mcmFwaGljYWsgZXJyb3dz DQoNCk9uIEp1bCAyMSwgMjAxNiwgYXQgMDk6MDEsIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1p cnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdy b3RlOg0KRGVhciBBbGwsDQp3ZSBoYWQgdmVyeSBnb29kIGRpc2N1c3Npb24gb24gT0FNIHRoaXMg d2Vlay4gV2XigJl2ZSB0b3VjaGVkIG9uIEFjdGl2ZSwgUGFzc2l2ZSBhbmQgU29tZXRoaW5nLWlu LWJldHdlZW4gT0FNLiBCdXQgY2FuIE5TSCBpbmRpY2F0ZSB3aGljaCBPQU0gdHlwZSwgaWYgYW55 LCBhc3NvY2lhdGVkIHdpdGggYSBwYWNrZXQ/IEkgdGhpbmsgdGhhdCB0aGUgY3VycmVudCB2ZXJz aW9uIG9mIGRyYWZ0LWlldGYtc2ZjLW5zaCBkb2VzIG5vdCBhbGxvdyB0aGF0IGFuZCBtYXkgYmUg YW1iaWd1b3VzIGluIHNvbWUgY2FzZXMuIEkgcHJvcG9zZSBjaGFuZ2UgdG8gaW50ZXJwcmV0YXRp b24gYW5kIGFwcGxpY2FiaWxpdHkgZGVzY3JpcHRpb24gb2YgdGhlIE8oQU0pIGZsYWcgYW5kIGFs bG9jYXRpb24gb2YgdGhlIG5ldyBwcm90b2NvbCB0eXBlIHRvIGJlIHVzZWQgaW4gdGhlIE5leHQg UHJvdG9jb2wgZmllbGQuDQoNCg0KQWN0aXZlLCBwYXNzaXZlIGFuZCBzb21ldGhpbmctaW4tYmV0 d2VlbiBhcmUgbm90IE9BTSBwcm90b2NvbCB0eXBlcyBidXQgcmF0aGVyIHRoZXkgYXJlIG1lYXN1 cmluZyBtZXRob2RzLiBBY3RpdmUgT0FNIGNhbiBpbmNsdWRlIGEgcGx1cmFsaXR5IG9mIE9BTSBw cm90b2NvbHMsIGluY2x1ZGluZyBCRkQsIFMtQkZELCBzb21ldGhpbmctb3Zlci1pcCwgZXRjLg0K DQpJIGFsc28gYmVsaWV2ZSB0aGF0IHRoZSBjdXJyZW50IE9BTSB0ZXh0IGluIE5TSCBpcyBub3Qg YW1iaWd1b3VzIGFuZCBhbGxvd3MgZW5vdWdoIHByb2Nlc3Npbmcgb2YgdGhlIGhlYWRlciB0byB1 bmRlcnN0YW5kIHNvbWV0aGluZyBpcyBPQU0sIHdpdGhvdXQgZ29pbmcgdGhlIHNwZWNpZmljcyBv ZiBhbiBPQU0gaGFuZGxlci4NCg0KVGhlcmVmb3JlLCBJIG9wcG9zZSB0aGlzIGNoYW5nZS4NCg0K DQpSRkMgNzc5OSBkZWZpbmVzIEFjdGl2ZSBPQU0gYXMgZm9sbG93aW5nOg0KQW4gQWN0aXZlIE1l dHJpYyBvciBNZXRob2QgZGVwZW5kcyBvbiBhIGRlZGljYXRlZCBtZWFzdXJlbWVudCBwYWNrZXQg c3RyZWFtIGFuZCBvYnNlcnZhdGlvbnMgb2YgdGhlIHN0cmVhbS4NClRodXMsIHJlZ2FyZGxlc3Mg b2YgZW5jYXBzdWxhdGlvbiB1c2VkIGJ5IE9BTSwgaXQgaXMgdGhlIHBhY2tldCBjb25zdHJ1Y3Rl ZCBzb2xlbHkgZm9yIG1vbml0b3JpbmcsIG1lYXN1cmluZyBuZXR3b3Jr4oCZcyBtZXRyaWMgYW5k IHNob3VsZCBub3QgbGVhdmUgZ2l2ZW4gZG9tYWluLiBBbmQsIEkgYmVsaWV2ZSwgc3VjaCBwYWNr ZXRzIHNob3VsZCBiZSBpZGVudGlmaWVkIGJ5IHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZWlyIG93 bi4NCg0KU2VlbXMgeW91IGFyZSBhZHZvY2F0aW5nIGZvciBhIHNpbmdsZSAiT0FNIiBwcm90b2Nv bCB0eXBlIGZvciBPQU0gcGFja2V0cy4gVGhlIGZ1bmN0aW9uYWxpdHkgb2YgaWRlbnRpZnlpbmcg c29tZXRoaW5nIGFzIE9BTSBpcyBpbiB0aGUgTy1iaXQsIHNvIG5vIG5lZWQgdG8gd2FzdGUgYml0 cyBpbiBkdXBsaWNhdGlvbi4NCg0KVGhlbiwgYXQgc29tZSBwb2ludCwgeW91IGhhdmUgdG8gZGlm ZmVyZW50aWF0ZSBpZiBhbiBPQU0gaXMsIHNheSwgSVAgb3IgInJhdyBCRkQiIG9yIHNvbWV0aGlu ZyBlbHNlLiBUaGF0J3Mgd2hhdCB0aGUgUHJvdG9jb2wgZmllbGQgaXMgZm9yLiBJIGRvIG5vdCBz ZWUgYSBuZWVkIHRvIGFkZCBhbiBpbmRpcmVjdGlvbiBoZXJlIHRvIHRoZW4gaGF2ZSB0byBoYXZl IGEgcHJvdG9jb2wgZmllbGQgaW5zaWRlIHRoZSBPQU0uDQoNCg0KT0FNIHdoaWNoIGJlaGF2ZXMg YXMgbXVjaCBhcyBQYXNzaXZlIE9BTSBvciBTb21ldGhpbmctaW4tYmV0d2VlbiwgZS5nLiBPQU0g YXBwZW5kZWQgdG8gZGF0YSBwYWNrZXQgZWl0aGVyIGF0IHRoZSBkb21haW7igJlzIGVkZ2Ugb3Ig b24tdGhlLWZseSwgaWRlbnRpZmllZCBieSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUgZGF0YSBw YWNrZXQgY2FycmllZCBpbiBOU0guDQoNClRoYXQncyBjb3JyZWN0LCB3aXRoIHRoZSBPIGJpdCBj bGVhcmVkOyBpdCdzIGEgZGF0YSBwYWNrZXQgYW5kIG5vdCBhbiBPQU0gb25lLg0KDQoNCkJlbG93 IGFyZSBjaGFuZ2VzIEnigJlkIGxpa2UgdG8gcHJvcG9zZToNClNlY3Rpb24gMy4yIE8tYml0Og0K T0xEDQogICBPIGJpdDogd2hlbiBzZXQgdG8gMHgxIGluZGljYXRlcyB0aGF0IHRoaXMgcGFja2V0 IGlzIGFuIE9wZXJhdGlvbnMsDQogICBBZG1pbmlzdHJhdGlvbiBhbmQgTWFpbnRlbmFuY2UgKE9B TSkgbWVzc2FnZS4gIFRoZSByZWNlaXZpbmcgU0ZGIGFuZA0KICAgU0ZzIG5vZGVzIE1VU1QgZXhh bWluZSB0aGUgcGF5bG9hZCBhbmQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24gKGUuZy4NCiAgIHJl dHVybiBzdGF0dXMgaW5mb3JtYXRpb24pLiAgT0FNIG1lc3NhZ2Ugc3BlY2lmaWNzIGFuZCBoYW5k bGluZw0KICAgZGV0YWlscyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4N CkVORA0KTkVXDQpPIGJpdDogd2hlbiBzZXQgdG8gMHgxIGluZGljYXRlcyB0aGF0IGRhdGEgcGFj a2V0IGlkZW50aWZpZWQgYnkgdGhlIE5leHQNClByb3RvY29sIHR5cGUgaGFzIE9BTSBtZXRhZGF0 YSBhcHBlbmRlZC4NCg0KTm8uIElmIGl0IGlzIGEgZGF0YSBwYWNrZXQgaXQgZG9lcyBub3QgaGF2 ZSB0aGUgTyBiaXQgc2V0ICh0byAxIG9yIHRvIHdoaWNoZXZlciBvdGhlciBwb3NzaWJsZSB2YWx1 ZSBmb3IgdGhlIGJpdCA6LSkNCg0KVGhlIGdvYWwgaXMgdGhhdCBsb29raW5nIGF0IGEgc2luZ2xl IGJ1dCBpdCBjYW4gYmUgdW5kZXJzdG9vZCBpZiBpdCBpcyBhIGRhdGEgcGFja2V0ICh3aGljaCBj YW4gYmUgdXNlZCwgbWFya2VkLCBldGMuIHRvIGJlIHVzZWQgZm9yIE9BTSBwdXJwb3Nlcywgb3Ig bm90KS4NCg0KV2UgZG8gbm90IHdhbnQgT0FNIGRpcmVjdCBleGNlcHRpb24gcHJvY2Vzc2luZyBm b3IgZGF0YSBwYWNrZXRzLg0KDQoNCkRlZmluaXRpb24gb2YgdGhlIGZvcm1hdChzKQ0KdXNlZCBi eSBPQU0gbWV0YWRhdGEgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCkVO RA0KDQpBdCB0aGUgZW5kIG9mIFNlY3Rpb24gMy4yOg0KT0xEDQogICBUaGlzIGRyYWZ0IGRlZmlu ZXMgdGhlIGZvbGxvd2luZyBOZXh0IFByb3RvY29sIHZhbHVlczoNCg0KICAgMHgxIDogSVB2NA0K ICAgMHgyIDogSVB2Ng0KICAgMHgzIDogRXRoZXJuZXQNCiAgIDB4NDogTlNIDQogICAweDU6IE1Q TFMNCiAgIDB4Ni0weEZEOiBVbmFzc2lnbmVkDQogICAweEZFLTB4RkY6IEV4cGVyaW1lbnRhbA0K RU5EDQpORVcNCiAgIFRoaXMgZHJhZnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nIE5leHQgUHJvdG9j b2wgdmFsdWVzOg0KDQogICAweDEgOiBJUHY0DQogICAweDIgOiBJUHY2DQogICAweDMgOiBFdGhl cm5ldA0KICAgMHg0OiBOU0gNCiAgIDB4NTogTVBMUw0KICAgMHg2OiBBY3RpdmUgT0FNDQoNCkFz IHBlciBhYm92ZSBJIGRvIG5vdCBiZWxpZXZlIHRoZXJlJ3MgYSBzaW5nbGUgT0FNIHByb3RvY29s Lg0KDQoNCiAgIDB4Ny0weEZEOiBVbmFzc2lnbmVkDQogICAweEZFLTB4RkY6IEV4cGVyaW1lbnRh bA0KRU5EDQoNCkFuZCwgY29uc2VxdWVudGx5LCBzZWN0aW9uIDEzLjIuNSBpbiBJQU5BIENvbnNp ZGVyYXRpb25zIHNlY3Rpb24gd2lsbCByZXF1ZXN0IGFsbG9jYXRpb24gb2YgdmFsdWUgMHg2IHRv IGJlIGFzc2lnbmVkIHRvIEFjdGl2ZSBPQU0gcHJvdG9jb2xzLg0KDQpHcmVhdGx5IGFwcHJlY2lh dGUgeW91ciBjb25zaWRlcmF0aW9uIGFuZCBjb21tZW50cy4NCg0KDQpNeSDigqwwLjAyLg0KDQpU aGFua3MsDQoNCkNhcmxvcy4NCg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KUnRnLW9vYW0tZHQgbWFpbGluZyBsaXN0DQpSdGctb29h bS1kdEBpZXRmLm9yZzxtYWlsdG86UnRnLW9vYW0tZHRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy1vb2FtLWR0DQoNCg0KDQo= --_000_A19424902E4E499F9319AC2A1110F5FCciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8E067E1CE66AD44E8D00B3593891F79E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGF2ZSwNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPltBcG9sb2dpZXMgZm9yIHRoZSBk ZWxheSBpbiByZXNwb25kaW5nIOKAlCBJIHdhcyBvbiB2YWNhdGlvbl08L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYXBwcmVjaWF0ZSB0 aGUgaGVhbHRoeSB0ZW5zaW9uIGJldHdlZW4gb3Zlci0gYW5kIHVuZGVyLXNwZWNpZnlpbmcuIEkg ZG8gbm90IHRoaW5rIGhvd2V2ZXIgdGhhdCB0aGUgYmVoYXZpb3IgaXMgdW5kZWZpbmVkIGluIHRo aXMgcGFydGljdWxhciBjYXNlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VG8gbWUsIHRoZSBzcGVjaWZpY2F0aW9uIGlzOiDigJx3aGVu IE89MSwgdGhlbiB0aGUgcGFja2V0IGlzIGFuIE9BTSBwYWNrZXQgcHJvY2Vzc2VkIGJ5IGFuIE9B TSBtb2R1bGXigJ0gd2l0aCB0aGUgY29yb2xsYXJpZXMgcmVnYXJkaW5nIHRoZSBPQU0gaGFuZGlu ZzogKHdpdGggdGhlIE9BTSBtb2R1bGUgcHJvY2Vzc2luZyBkZWZpbmVkIGluIGEgc2VwYXJhdGUg cGxhY2UpIGFuZCAoaWYgdGhlIE9BTSBtb2R1bGUgaXMgTlVMTCAoZG9lcw0KIG5vdCBleGlzdCks IHRoZW4gdGhlIHBhY2tldCBnb2VzIHRvIHRoZSBiaXQtYnVja2V0KTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tz0xIGRvZXMgbm90IG1l YW4gYW4gT0FNIGhlYWRlciBmb2xsb3dzLiBJdCBtZWFucyBpdOKAmXMgYW4gT0FNIHBhY2tldC4g QW5kIE9BTSBpcyBub3QgYSBwcm90b2NvbCB0eXBlLCBpdOKAmXMgYSBzZXQgb2YgZnVuY3Rpb25h bGl0aWVzIHJlYWxpemVkIGJ5IHZhcmlvdXMgcHJvdG9jb2xzIHBvdGVudGlhbGx5LjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtz ITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+4oCUIENhcmxvcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwg MjQsIDIwMTYsIGF0IDI6MjUgUE0sIERhdmUgRG9sc29uICZsdDs8YSBocmVmPSJtYWlsdG86ZGRv bHNvbkBzYW5kdmluZS5jb20iIGNsYXNzPSIiPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4N CjxkaXYgc3R5bGU9IndpZHRoOjEwMCU7IGZvbnQtc2l6ZTppbml0aWFsOyBmb250LWZhbWlseTpD YWxpYnJpLCdTbGF0ZSBQcm8nLHNhbnMtc2VyaWYsc2Fucy1zZXJpZjsgY29sb3I6cmdiKDMxLDcz LDEyNSk7IHRleHQtYWxpZ246aW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwy NTUpIiBjbGFzcz0iIj4NCkNhcmxvcywmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IndpZHRoOjEw MCU7IGZvbnQtc2l6ZTppbml0aWFsOyBmb250LWZhbWlseTpDYWxpYnJpLCdTbGF0ZSBQcm8nLHNh bnMtc2VyaWYsc2Fucy1zZXJpZjsgY29sb3I6cmdiKDMxLDczLDEyNSk7IHRleHQtYWxpZ246aW5p dGlhbDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIiBjbGFzcz0iIj4NCkkgZG9u J3QgZmluZCBpdCBzYXRpc2Z5aW5nICZuYnNwO3RvIGRlZmluZSBhIHByb3RvY29sIHdoaWNoIHNh eXMgaWYgTz0xIHRoZSBiZWhhdmlvciBpcyB1bmRlZmluZWQuIChTYW1lIG91dGNvbWUgYXMgd2hl biB2ZXJzaW9uIT0wKTwvZGl2Pg0KPGRpdiBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmlu aXRpYWw7IGZvbnQtZmFtaWx5OkNhbGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNl cmlmOyBjb2xvcjpyZ2IoMzEsNzMsMTI1KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5k LWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJ3aWR0aDoxMDAlOyBmb250LXNpemU6aW5pdGlhbDsgZm9udC1mYW1pbHk6 Q2FsaWJyaSwnU2xhdGUgUHJvJyxzYW5zLXNlcmlmLHNhbnMtc2VyaWY7IGNvbG9yOnJnYigzMSw3 MywxMjUpOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUs MjU1KSIgY2xhc3M9IiI+DQpCdXQsIDxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDppbml0aWFsIiBj bGFzcz0iIj53aGlsZSB0aGUgTlNIIGRyYWZ0IGlzIG11dGUgb24gdGhlIHRvcGljLCBpdCBpcyBm YWlyIHRvIHNwZWN1bGF0ZSBvbiB2YXJpb3VzICZuYnNwO3NjaGVtZXMuPC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRpYWw7IGZvbnQtZmFtaWx5OkNh bGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmOyBjb2xvcjpyZ2IoMzEsNzMs MTI1KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1 NSkiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OmluaXRpYWwiIGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9IndpZHRoOjEwMCU7IGZv bnQtc2l6ZTppbml0aWFsOyBmb250LWZhbWlseTpDYWxpYnJpLCdTbGF0ZSBQcm8nLHNhbnMtc2Vy aWYsc2Fucy1zZXJpZjsgY29sb3I6cmdiKDMxLDczLDEyNSk7IHRleHQtYWxpZ246aW5pdGlhbDsg YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIiBjbGFzcz0iIj4NCuKAjlRyYWlsaW5n IGFuIE9BTSBoZWFkZXIgaXMgYW4gYWx0ZXJuYXRpdmUgdG8gcHV0dGluZyBwaWdneWJhY2sgT0FN IGluIHRoZSBtZXRhZGF0YS4gSSdtIG5vdCBzdXJlIHdoZXJlIEkgaGVhcmQgaXQgbWVudGlvbmVk LiBQZXJoYXBzIGl0IHdhcyBpbiB0aGUgY29udGV4dCBvZiB1bmlmaWVkIE92ZXJsYXkgT0FNLiBM b2dpY2FsbHkgaWYgTz0xLCB0aGVyZSBtdXN0IGJlIGFuIE9BTSBoZWFkZXIsIHJpZ2h0PzwvZGl2 Pg0KPGRpdiBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRpYWw7IGZvbnQtZmFtaWx5 OkNhbGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmOyBjb2xvcjpyZ2IoMzEs NzMsMTI1KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1 LDI1NSkiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJ3aWR0 aDoxMDAlOyBmb250LXNpemU6aW5pdGlhbDsgZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJv JyxzYW5zLXNlcmlmLHNhbnMtc2VyaWY7IGNvbG9yOnJnYigzMSw3MywxMjUpOyB0ZXh0LWFsaWdu OmluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSIgY2xhc3M9IiI+DQom Z3Q7IDxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDppbml0aWFsIiBjbGFzcz0iIj5JZiBPPTEgYW5k IHRoZSBuZXh0IHByb3RvY29sIGlzIElQdjQsIEnigJlkIGV4cGVjdCBhbiBJUHY0IHBhY2tldCZu YnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9IndpZHRoOjEwMCU7IGZvbnQtc2l6ZTppbml0 aWFsOyBmb250LWZhbWlseTpDYWxpYnJpLCdTbGF0ZSBQcm8nLHNhbnMtc2VyaWYsc2Fucy1zZXJp ZjsgY29sb3I6cmdiKDMxLDczLDEyNSk7IHRleHQtYWxpZ246aW5pdGlhbDsgYmFja2dyb3VuZC1j b2xvcjpyZ2IoMjU1LDI1NSwyNTUpIiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdo dDppbml0aWFsIiBjbGFzcz0iIj4mZ3Q7IGVuY2Fwc3VsYXRpbmcgdGhlIE9BTSAoZWl0aGVyIFVE UC0mZ3Q7IEJGRCwgb3IgSUNNUCwgZm9yIGV4YW1wbGUpLjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9IndpZHRoOjEwMCU7IGZvbnQtc2l6ZTppbml0aWFsOyBmb250LWZhbWlseTpDYWxpYnJpLCdT bGF0ZSBQcm8nLHNhbnMtc2VyaWYsc2Fucy1zZXJpZjsgY29sb3I6cmdiKDMxLDczLDEyNSk7IHRl eHQtYWxpZ246aW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIiBjbGFz cz0iIj4NCkRvIHlvdSBtZWFuIGNoZWNrIHRvIHNlZSBpZiB0aGUgZW1iZWRkZWQgSVB2NCBwYWNr ZXQgaXMgYWRkcmVzc2VkIHRvPC9kaXY+DQo8ZGl2IHN0eWxlPSJ3aWR0aDoxMDAlOyBmb250LXNp emU6aW5pdGlhbDsgZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJvJyxzYW5zLXNlcmlmLHNh bnMtc2VyaWY7IGNvbG9yOnJnYigzMSw3MywxMjUpOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tn cm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSIgY2xhc3M9IiI+DQp0aGUgU0ZGIGl0c2VsZj8g SS5lLiwgc2VuZCB0aGUgcGFja2V0IHVwIHRoZSBsb2NhbCBpcHY0IHN0YWNrPzwvZGl2Pg0KPGRp diBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRpYWw7IGZvbnQtZmFtaWx5OkNhbGli cmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmOyBjb2xvcjpyZ2IoMzEsNzMsMTI1 KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSki IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJ3aWR0aDoxMDAl OyBmb250LXNpemU6aW5pdGlhbDsgZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJvJyxzYW5z LXNlcmlmLHNhbnMtc2VyaWY7IGNvbG9yOnJnYigzMSw3MywxMjUpOyB0ZXh0LWFsaWduOmluaXRp YWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IndpZHRoOjEwMCU7IGZvbnQtc2l6ZTppbml0aWFs OyBmb250LWZhbWlseTpDYWxpYnJpLCdTbGF0ZSBQcm8nLHNhbnMtc2VyaWYsc2Fucy1zZXJpZjsg Y29sb3I6cmdiKDMxLDczLDEyNSk7IHRleHQtYWxpZ246aW5pdGlhbDsgYmFja2dyb3VuZC1jb2xv cjpyZ2IoMjU1LDI1NSwyNTUpIiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRpYWw7IGZvbnQtZmFtaWx5OkNhbGli cmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmOyBjb2xvcjpyZ2IoMzEsNzMsMTI1 KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSki IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6 aW5pdGlhbDsgZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJvJyxzYW5zLXNlcmlmLHNhbnMt c2VyaWY7IGNvbG9yOnJnYigzMSw3MywxMjUpOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tncm91 bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSIgY2xhc3M9IiI+DQo8L2Rpdj4NCjx0YWJsZSB3aWR0 aD0iMTAwJSIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6d2hpdGU7IGJvcmRlci1zcGFjaW5nOjBw eCIgY2xhc3M9IiI+DQo8dGJvZHkgY2xhc3M9IiI+DQo8dHIgY2xhc3M9IiI+DQo8dGQgY29sc3Bh bj0iMiIgc3R5bGU9ImZvbnQtc2l6ZTppbml0aWFsOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tn cm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3Jk ZXItc3R5bGU6c29saWQgbm9uZSBub25lOyBib3JkZXItdG9wLWNvbG9yOnJnYigxODEsMTk2LDIy Myk7IGJvcmRlci10b3Atd2lkdGg6MXB0OyBwYWRkaW5nOjNwdCAwaW4gMGluOyBmb250LWZhbWls eTpUYWhvbWEsJ0JCIEFscGhhIFNhbnMnLCdTbGF0ZSBQcm8nOyBmb250LXNpemU6MTBwdCIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZyb206IDwvYj5DYXJsb3MgUGlnbmF0 YXJvIChjcGlnbmF0YSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+U2VudDogPC9i PlNhdHVyZGF5LCBKdWx5IDIzLCAyMDE2IDc6MjkgUE08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIg Y2xhc3M9IiI+VG86IDwvYj5EYXZlIERvbHNvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFz cz0iIj5DYzogPC9iPkdyZWdvcnkgTWlyc2t5OyA8YSBocmVmPSJtYWlsdG86cnRnLW9vYW0tZHRA aWV0Zi5vcmciIGNsYXNzPSIiPg0KcnRnLW9vYW0tZHRAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiIGNsYXNzPSIiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gW1J0Zy1vb2FtLWR0 XSBJZGVudGlmeWluZyBPQU0gaW4gTlNIPC9kaXY+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6c29saWQgbm9uZSBub25l OyBib3JkZXItdG9wLWNvbG9yOnJnYigxODYsMTg4LDIwOSk7IGJvcmRlci10b3Atd2lkdGg6MXB0 OyBmb250LXNpemU6aW5pdGlhbDsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9y OnJnYigyNTUsMjU1LDI1NSkiIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPkhpLCBEYXZlLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pk9uIEp1bCAyMywgMjAxNiwgYXQgNjozOCBQTSwgRGF2ZSBEb2xzb24gJmx0OzxhIGhyZWY9Im1h aWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSIgY2xhc3M9IiI+ZGRvbHNvbkBzYW5kdmluZS5jb208 L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRp YWw7IGZvbnQtZmFtaWx5OkNhbGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlm OyBjb2xvcjpyZ2IoMzEsNzMsMTI1KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNv bG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KQ2FybG9zLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRpYWw7IGZvbnQtZmFtaWx5OkNhbGlicmksJ1Ns YXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmOyBjb2xvcjpyZ2IoMzEsNzMsMTI1KTsgdGV4 dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KSSB0 aGluayBzb21lIG9mIHdoYXQgaXMgYmVpbmcgc2FpZCBpbiBlbWFpbHMgbmVlZHMgdG8gYmUgY2xh cmlmaWVkIGluIHRoZSBkb2N1bWVudC48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndpZHRo OjEwMCU7IGZvbnQtc2l6ZTppbml0aWFsOyBmb250LWZhbWlseTpDYWxpYnJpLCdTbGF0ZSBQcm8n LHNhbnMtc2VyaWYsc2Fucy1zZXJpZjsgY29sb3I6cmdiKDMxLDczLDEyNSk7IHRleHQtYWxpZ246 aW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4NCkl0IHN0aWxsIGlz bid0IGNyeXN0YWwgY2xlYXIgdG8gbWUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3aWR0 aDoxMDAlOyBmb250LXNpemU6aW5pdGlhbDsgZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJv JyxzYW5zLXNlcmlmLHNhbnMtc2VyaWY7IGNvbG9yOnJnYigzMSw3MywxMjUpOyB0ZXh0LWFsaWdu OmluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFncmVlIHRoYXQgaXQgbmVl ZHMgdG8gYmUgY2xhcmlmaWVkLCB3aXRoIGRpYWdyYW1zLCBhbmQgc3BlY3MuIEhvd2V2ZXIsIHdo ZW4geW91IHNheSDigJxpbiB0aGUgZG9jdW1lbnTigJ0sIEkgZG8gbm90IHRoaW5rIHRob3NlIGRl dGFpbHMgYmVsb25nIGluIHRoZSBOU0ggZG9jdW1lbnQgaXRzZWxmLiBUaGUgTlNILCBpbiBteSBo dW1ibGUgb3BpbmlvbiwgbmVlZHMgdG8gc2F5IGhvdyB0byBpZGVudGlmeSBhbiBPQU0gcGFja2V0 LjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdv cmQiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRpYWw7 IGZvbnQtZmFtaWx5OkNhbGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmOyBj b2xvcjpyZ2IoMzEsNzMsMTI1KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9y OnJnYigyNTUsMjU1LDI1NSkiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3aWR0aDox MDAlOyBmb250LXNpemU6aW5pdGlhbDsgZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJvJyxz YW5zLXNlcmlmLHNhbnMtc2VyaWY7IGNvbG9yOnJnYigzMSw3MywxMjUpOyB0ZXh0LWFsaWduOmlu aXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQpJZiBPPTEsIGFuZCBu ZXh0IHByb3RvY29sIGlzIElQdjQsIGNhbiB0aGVyZSBiZSBhbiBPQU0gaGVhZGVyIHBpZ2d5LWJh Y2tlZCB3aXRoIHRoZSBJUHY0PyBJZiBzbywgYmVmb3JlIG9yIGFmdGVyPzwvZGl2Pg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRpYWw7IGZvbnQtZmFtaWx5 OkNhbGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlmOyBjb2xvcjpyZ2IoMzEs NzMsMTI1KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1 LDI1NSkiPg0KU29tZSBkcmFmdHMgaW1wbHkgdGhpcyBpcyBwb3NzaWJsZSBidXQgbm90aGluZyBz YXlzIGhvdy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiBPPTEgYW5kIHRoZSBu ZXh0IHByb3RvY29sIGlzIElQdjQsIEnigJlkIGV4cGVjdCBhbiBJUHY0IHBhY2tldCBlbmNhcHN1 bGF0aW5nIHRoZSBPQU0gKGVpdGhlciBVRFAtJmd0OyBCRkQsIG9yIElDTVAsIGZvciBleGFtcGxl KS4gV2l0aCDigJxPQU0gaGVhZGVy4oCdLCBkbyB5b3UgbWVhbiB0aGUgT09BTSBEVCBoZWFkZXI/ IFdoYXQgd291bGQgYmUgdGhlIHVzZSBmb3IgdGhvc2UgZXh0cmEgYnl0ZXMgaW4gdGhpcyBjYXNl PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+4oCUIENhcmxvcy48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5 bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndpZHRoOjEw MCU7IGZvbnQtc2l6ZTppbml0aWFsOyBmb250LWZhbWlseTpDYWxpYnJpLCdTbGF0ZSBQcm8nLHNh bnMtc2VyaWYsc2Fucy1zZXJpZjsgY29sb3I6cmdiKDMxLDczLDEyNSk7IHRleHQtYWxpZ246aW5p dGlhbDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1zaXplOmluaXRp YWw7IGZvbnQtZmFtaWx5OkNhbGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixzYW5zLXNlcmlm OyBjb2xvcjpyZ2IoMzEsNzMsMTI1KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNrZ3JvdW5kLWNv bG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KLURhdmU8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9 IndpZHRoOjEwMCU7IGZvbnQtc2l6ZTppbml0aWFsOyBmb250LWZhbWlseTpDYWxpYnJpLCdTbGF0 ZSBQcm8nLHNhbnMtc2VyaWYsc2Fucy1zZXJpZjsgY29sb3I6cmdiKDMxLDczLDEyNSk7IHRleHQt YWxpZ246aW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0id2lkdGg6MTAwJTsgZm9udC1z aXplOmluaXRpYWw7IGZvbnQtZmFtaWx5OkNhbGlicmksJ1NsYXRlIFBybycsc2Fucy1zZXJpZixz YW5zLXNlcmlmOyBjb2xvcjpyZ2IoMzEsNzMsMTI1KTsgdGV4dC1hbGlnbjppbml0aWFsOyBiYWNr Z3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KPGJyIGNsYXNzPSIiIHN0eWxlPSJkaXNw bGF5OmluaXRpYWwiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6aW5p dGlhbDsgZm9udC1mYW1pbHk6Q2FsaWJyaSwnU2xhdGUgUHJvJyxzYW5zLXNlcmlmLHNhbnMtc2Vy aWY7IGNvbG9yOnJnYigzMSw3MywxMjUpOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tncm91bmQt Y29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQo8L2Rpdj4NCjx0YWJsZSB3aWR0aD0iMTAwJSIgY2xh c3M9IiIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6d2hpdGU7IGJvcmRlci1zcGFjaW5nOjBweCI+ DQo8dGJvZHkgY2xhc3M9IiI+DQo8dHIgY2xhc3M9IiI+DQo8dGQgY29sc3Bhbj0iMiIgY2xhc3M9 IiIgc3R5bGU9ImZvbnQtc2l6ZTppbml0aWFsOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tncm91 bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJib3JkZXIt c3R5bGU6c29saWQgbm9uZSBub25lOyBib3JkZXItdG9wLWNvbG9yOnJnYigxODEsMTk2LDIyMyk7 IGJvcmRlci10b3Atd2lkdGg6MXB0OyBwYWRkaW5nOjNwdCAwaW4gMGluOyBmb250LWZhbWlseTpU YWhvbWEsJ0JCIEFscGhhIFNhbnMnLCdTbGF0ZSBQcm8nOyBmb250LXNpemU6MTBwdCI+DQo8ZGl2 IGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZyb206IDwvYj5DYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0 YSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+U2VudDogPC9iPlNhdHVyZGF5LCBK dWx5IDIzLCAyMDE2IDEyOjI1IFBNPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPlRv OiA8L2I+R3JlZ29yeSBNaXJza3k8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+Q2M6 IDwvYj48YSBocmVmPSJtYWlsdG86cnRnLW9vYW0tZHRAaWV0Zi5vcmciIGNsYXNzPSIiPnJ0Zy1v b2FtLWR0QGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIGNsYXNz PSIiPnNmY0BpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+U3Vi amVjdDogPC9iPlJlOiBbc2ZjXSBbUnRnLW9vYW0tZHRdIElkZW50aWZ5aW5nIE9BTSBpbiBOU0g8 L2Rpdj4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9ImJvcmRlci1zdHlsZTpzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29s b3I6cmdiKDE4NiwxODgsMjA5KTsgYm9yZGVyLXRvcC13aWR0aDoxcHQ7IGZvbnQtc2l6ZTppbml0 aWFsOyB0ZXh0LWFsaWduOmluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1 KSI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGksIEdyZWcsDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDIyLCAyMDE2LCBhdCAxMDoy NCBBTSwgR3JlZ29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb20iIGNsYXNzPSIiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJmb250LWZhbWls eTpIZWx2ZXRpY2E7IGZvbnQtc2l6ZToxMnB4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC13ZWln aHQ6bm9ybWFsOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IG9ycGhhbnM6YXV0bzsgdGV4dC1hbGln bjpzdGFydDsgdGV4dC1pbmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFj ZTpub3JtYWw7IHdpZG93czphdXRvOyB3b3JkLXNwYWNpbmc6MHB4Ij4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCkhpIENhcmxvcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCnRoYW5rIHlvdSBmb3Igc2hhcmluZyB5b3VyIGNvbW1l bnRzLiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB5b3Ugc3VnZ2VzdCB0byBleHBvc2UgcHJv dG9jb2wgdHlwZXMgb2YgT0FNIGFzIE5leHQgUHJvdG9jb2wgcmF0aGVyIHRoYW4gdG8gdXNlIHNp bmdsZSBBY3RpdmUgT0FNIHByb3RvY29sIHR5cGUgYW5kIHVzZSBPT0FNIEhlYWRlciB0byBkZW11 eCBPT0FNIHR5cGUuIFRoZW4sIHRoZSBOZXh0IFByb3RvY29sIHJlZ2lzdHJ5IHdpbGwgaGF2ZQ0K IHRvIGFsbG9jYXRlIHZhbHVlcyBmb3Igc2luZ2xlLWhvcCBCRkQsIG11bHRpLWhvcCBCRkQsIG11 bHRpcG9pbnQgQkZELCBTLUJGRCwgRWNobyBSZXF1ZXN0L1JlcGx5LCBBSVMgcHJvdG9jb2wsIEFj dGl2ZSBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBwcm90b2NvbCwgYW5kIEnigJl2ZSBvbmx5IGxp c3RlZCBzb21lIG9mIEFPTSBwcm90b2NvbHMgdGhhdCBtYXkgYmUgdXNlZCB0byBvcGVyYXRlLCBh ZG1pbmlzdGVyIGFuZCBtYWludGFpbiBTRlAuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+WWVzLCB0aGUgcHJvdG9jb2wgZmllbGQgb3VnaHQgdG8gcmVnaXN0ZXIgdGhlIE9BTSBwcm90 b2NvbHMgdGhhdCB3aWxsIGJlIHVzZWQgYW5kIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCDigJQg b2YgY291cnNlIG5vdCBhbGwgcG90ZW50aWFsIHZhcmlhdGlvbnMgYW5kIHBlcm11dGF0aW9ucyBv ZiBwb3NzaWJsZSBPQU1zICh3aGF0IGlzIEFJUyBwcm90b2NvbD8pPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7IGZv bnQtc2l6ZToxMnB4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC13ZWlnaHQ6bm9ybWFsOyBsZXR0 ZXItc3BhY2luZzpub3JtYWw7IG9ycGhhbnM6YXV0bzsgdGV4dC1hbGlnbjpzdGFydDsgdGV4dC1p bmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpub3JtYWw7IHdpZG93 czphdXRvOyB3b3JkLXNwYWNpbmc6MHB4Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjow aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0K QWRkaXRpb25hbGx5LCB5b3XigJl2ZSBzdWdnZXN0ZWQgdGhhdCBvbmx5IE8tYml0IHZhbHVlIHRv IGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgcGFja2V0IHNob3VsZCBiZSBwcm9jZXNzZWQg YXMgT0FNIG9yIGRhdGEgcGFja2V0LiBIZW5jZSBzaG91bGQgSSBleHBlY3QgdGhhdCBPLWJpdCBp cyBzZXQgZm9yIEJGRCwgQUlTLCBhbmQgRWNobyBSZXF1ZXN0L1JlcGx5IHBheWxvYWQgYW5kIHNo b3VsZCBub3QgYmUgc2V0IGlmIHRoZSBOZXh0IFByb3RvY29sDQogaXMgbmVpdGhlciBvZiBwcm90 b2NvbHMgbGlzdGVkIGFib3ZlPyBTaG91bGQgc3VjaCBzaXR1YXRpb24sIGkuZS4gTmV4dCBQcm90 b2NvbCB2YWx1ZSBpcyBNUExTIGFuZCBPLWJpdCBzZXQgdG8gMHgxLCBzaG91bGQgYmUgdmlld2Vk IGFzIGVycm9yIGFuZCB0aGUgcGFja2V0IGRyb3BwZWQ/IE9yIHlvdSBwcm9wb3NlIHRoYXQgdGhl IE5leHQgUHJvdG9jb2wgdGFrZXMgcHJlY2VkZW5jZSBhbmQgdGhlIHBhY2tldCB0cmVhdGVkIGFz IGRhdGE/IE9yDQogcGFja2V0IHZpZXdlZCBhcyBPQU0gYW5kIHBhc3NlZCB0byB0aGUgbG9jYWwg T0FNIGVudGl0eT8gT3IgaG93IHRvIGludGVycHJldCBzaXR1YXRpb24gd2hlbiBPLWJpdCBpcyBj bGVhcmVkIGFuZCB0aGUgTmV4dCBQcm90b2NvbCB2YWx1ZSBpcyBvbmUgb2YgT0FNIHByb3RvY29s cz8gVGhpcyBpcyB0aGUgc2l0dWF0aW9uIHRoYXQsIGluIG15IHZpZXcsIGlzIGFtYmlndW91cyBh bmQgdW5kZXItc3BlY2lmaWVkIGluIHRoZSBjdXJyZW50IE5TSCBkb2N1bWVudC4NCiBNeSBwcm9w b3NhbCBpcyBhbiBhdHRlbXB0IHRvIG1ha2UgcmVsYXRpb25zaGlwIGJldHdlZW4gT0FNIGFuZCBk YXRhIHBhY2tldHMgbW9yZSBkZXRlcm1pbmlzdGljLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkFuc3dlcmluZyBhbGwgdGhvc2UgcXVlc3Rpb25zICh3aGljaCBhcmUgcmVhbGx5IHNs aWdodCBwZXJtdXRhdGlvbnMgb2YgdGhlIHNhbWUgcXVlc3Rpb24pIGluIG9uZSBzaG90OiB0byBt ZSwgTz0wIGlzIGEgZGF0YSBwYWNrZXQgYW5kIE89MSBpcyBhbiBPQU0gcGFja2V0LiBJZiB0aGUg ZGF0YSBwcm9jZXNzaW5nIGRvZXMgbm90IGhhdmUgYSBoYW5kbGVyIGZvciB0aGUgcHJvdG9jb2wg aW4gdGhlIFBJRCwgb3IgaXTigJlzIGFuDQogdW5kZWZpbmVkLCBkcm9wcyB0byB0aGUgYml0IGJ1 Y2tldC4gRXF1YWxseSwgaWYgdGhlIE9BTSBoYW5kbGVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIHBy b3RvY29sIElEIGNhcnJpZWQgYXMgT0FNLCBwdWZmLiBJUCBjYW4gY2FycnkgZGF0YSBvciBPQU0g Zm9yIGV4YW1wbGUgYnkgdGhlIHdheS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkl0IGRvZXMgbm90IGdldCBhbnkgc2ltcGxlciBhbmQg dW5hbWJpZ3VvdXMgdGhhbiB0aGF0LiBXaGF04oCZcyB0aGUgYWR2YW50YWdlIG9mIG1vdmluZyB0 aGUgT0FNIFBJRCBmdXJ0aGVyIGluc2lkZT88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFuZCBJIGRvIG5vdCBiZWxpZXZlIHRoZXJl4oCZ cyB1bmRlcnNwZWNpZmljYXRpb24gaW4gTlNIIC0mZ3Q7IE89MSwgT0FNIHRyZWF0bWVudCwgbm90 IGRldGFpbGVkIGhlcmUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhOyBmb250 LXNpemU6MTJweDsgZm9udC1zdHlsZTpub3JtYWw7IGZvbnQtd2VpZ2h0Om5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6bm9ybWFsOyBvcnBoYW5zOmF1dG87IHRleHQtYWxpZ246c3RhcnQ7IHRleHQtaW5k ZW50OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsgd2hpdGUtc3BhY2U6bm9ybWFsOyB3aWRvd3M6 YXV0bzsgd29yZC1zcGFjaW5nOjBweCI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZu YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIi IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzwvZGl2Pg0KPGRp diBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0 OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iYm9yZGVyLXN0eWxlOnNvbGlkIG5vbmUgbm9u ZTsgYm9yZGVyLXRvcC1jb2xvcjpyZ2IoMjI1LDIyNSwyMjUpOyBib3JkZXItdG9wLXdpZHRoOjFw dDsgcGFkZGluZzozcHQgMGluIDBpbiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZiI+DQo8YiBjbGFzcz0iIj5Gcm9tOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFs8YSBocmVm PSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIiBjbGFzcz0iIj5tYWlsdG86Y3BpZ25hdGFAY2lz Y28uY29tPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZyaWRheSwgSnVseSAyMiwgMjAxNiAxMDox MCBBTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+R3JlZ29yeSBNaXJza3kgJmx0OzxhIGhyZWY9 Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iIGNsYXNzPSIiPmdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9i PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJl Zj0ibWFpbHRvOnJ0Zy1vb2FtLWR0QGlldGYub3JnIiBjbGFzcz0iIj5ydGctb29hbS1kdEBpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtSdGctb29hbS1kdF0g SWRlbnRpZnlpbmcgT0FNIGluIE5TSDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1m YW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCkdyZWcsPHNwYW4gY2xhc3M9 IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJzcDs8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46MGluIDBpbiAxMnB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxz YW5zLXNlcmlmIj4NClBsZWFzZSBmaW5kIHNvbWUgY29tbWVudHMgaW5saW5lLiZuYnNwOzwvcD4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8 c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+VGh1bWIgdHlwZWQgYnkgQ2FybG9zIFBpZ25h dGFyby48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i bWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPkV4Y3V6ZSB0 eXBvZnJhcGhpY2FrIGVycm93czwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBpbiAw aW4gMTJwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+ DQo8YnIgY2xhc3M9IiI+DQpPbiBKdWwgMjEsIDIwMTYsIGF0IDA5OjAxLCBHcmVnb3J5IE1pcnNr eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgY2xhc3M9 IiIgc3R5bGU9ImNvbG9yOnB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+Z3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luLXRvcDo1cHQ7IG1hcmdpbi1ib3R0b206NXB0Ij4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQpE ZWFyIEFsbCw8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCndl IGhhZCB2ZXJ5IGdvb2QgZGlzY3Vzc2lvbiBvbiBPQU0gdGhpcyB3ZWVrLiBXZeKAmXZlIHRvdWNo ZWQgb24gQWN0aXZlLCBQYXNzaXZlIGFuZCBTb21ldGhpbmctaW4tYmV0d2VlbiBPQU0uIEJ1dCBj YW4gTlNIIGluZGljYXRlIHdoaWNoIE9BTSB0eXBlLCBpZiBhbnksIGFzc29jaWF0ZWQgd2l0aCBh IHBhY2tldD8gSSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1z ZmMtbnNoIGRvZXMgbm90IGFsbG93IHRoYXQgYW5kDQogbWF5IGJlIGFtYmlndW91cyBpbiBzb21l IGNhc2VzLiBJIHByb3Bvc2UgY2hhbmdlIHRvIGludGVycHJldGF0aW9uIGFuZCBhcHBsaWNhYmls aXR5IGRlc2NyaXB0aW9uIG9mIHRoZSBPKEFNKSBmbGFnIGFuZCBhbGxvY2F0aW9uIG9mIHRoZSBu ZXcgcHJvdG9jb2wgdHlwZSB0byBiZSB1c2VkIGluIHRoZSBOZXh0IFByb3RvY29sIGZpZWxkLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KJm5ic3A7PC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0 eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5 OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEy cHQ7IGZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46 MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEycHQ7IGZvbnQtZmFt aWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj5BY3RpdmUsIHBhc3NpdmUgYW5kIHNvbWV0aGlu Zy1pbi1iZXR3ZWVuIGFyZSBub3QgT0FNIHByb3RvY29sIHR5cGVzIGJ1dCByYXRoZXIgdGhleSBh cmUgbWVhc3VyaW5nIG1ldGhvZHMuIEFjdGl2ZSBPQU0gY2FuIGluY2x1ZGUgYSBwbHVyYWxpdHkg b2YgT0FNIHByb3RvY29scywgaW5jbHVkaW5nIEJGRCwgUy1CRkQsDQogc29tZXRoaW5nLW92ZXIt aXAsIGV0Yy4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7 IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0i Zm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj4mbmJz cDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0 eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5 OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEy cHQ7IGZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj5JIGFsc28gYmVsaWV2ZSB0 aGF0IHRoZSBjdXJyZW50IE9BTSB0ZXh0IGluIE5TSCBpcyBub3QgYW1iaWd1b3VzIGFuZCBhbGxv d3MgZW5vdWdoIHByb2Nlc3Npbmcgb2YgdGhlIGhlYWRlciB0byB1bmRlcnN0YW5kIHNvbWV0aGlu ZyBpcyBPQU0sIHdpdGhvdXQgZ29pbmcgdGhlIHNwZWNpZmljcyBvZiBhbiBPQU0gaGFuZGxlci4m bmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXpl OjEycHQ7IGZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj4mbmJzcDs8L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJn aW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEycHQ7IGZvbnQt ZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj5UaGVyZWZvcmUsIEkgb3Bwb3NlIHRoaXMg Y2hhbmdlLiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i bWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBm b250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9IiIgc3R5bGU9Im1hcmdp bi10b3A6NXB0OyBtYXJnaW4tYm90dG9tOjVwdCI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KUkZDIDc3OTkgZGVmaW5lcyBBY3RpdmUgT0FN IGFzIGZvbGxvd2luZzo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGlu IDAuMDAwMXB0IDAuNWluOyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj4NCkFuIEFjdGl2ZSBNZXRyaWMgb3IgTWV0aG9kIGRlcGVuZHMgb24gYSBkZWRpY2F0 ZWQgbWVhc3VyZW1lbnQgcGFja2V0IHN0cmVhbSBhbmQgb2JzZXJ2YXRpb25zIG9mIHRoZSBzdHJl YW0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQpUaHVzLCBy ZWdhcmRsZXNzIG9mIGVuY2Fwc3VsYXRpb24gdXNlZCBieSBPQU0sIGl0IGlzIHRoZSBwYWNrZXQg Y29uc3RydWN0ZWQgc29sZWx5IGZvciBtb25pdG9yaW5nLCBtZWFzdXJpbmcgbmV0d29ya+KAmXMg bWV0cmljIGFuZCBzaG91bGQgbm90IGxlYXZlIGdpdmVuIGRvbWFpbi4gQW5kLCBJIGJlbGlldmUs IHN1Y2ggcGFja2V0cyBzaG91bGQgYmUgaWRlbnRpZmllZCBieSB0aGUgcHJvdG9jb2wgdHlwZSBv ZiB0aGVpciBvd24uPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZv bnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+Jm5ic3A7 PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpD YWxpYnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0 OyBmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+U2VlbXMgeW91IGFyZSBhZHZv Y2F0aW5nIGZvciBhIHNpbmdsZSAmcXVvdDtPQU0mcXVvdDsgcHJvdG9jb2wgdHlwZSBmb3IgT0FN IHBhY2tldHMuIFRoZSBmdW5jdGlvbmFsaXR5IG9mIGlkZW50aWZ5aW5nIHNvbWV0aGluZyBhcyBP QU0gaXMgaW4gdGhlIE8tYml0LCBzbyBubyBuZWVkIHRvIHdhc3RlIGJpdHMgaW4gZHVwbGljYXRp b24uJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQt c2l6ZToxMnB0OyBmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+Jm5ic3A7PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i bWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBm b250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+VGhlbiwgYXQgc29tZSBwb2ludCwg eW91IGhhdmUgdG8gZGlmZmVyZW50aWF0ZSBpZiBhbiBPQU0gaXMsIHNheSwgSVAgb3IgJnF1b3Q7 cmF3IEJGRCZxdW90OyBvciBzb21ldGhpbmcgZWxzZS4gVGhhdCdzIHdoYXQgdGhlIFByb3RvY29s IGZpZWxkIGlzIGZvci4gSSBkbyBub3Qgc2VlIGEgbmVlZCB0byBhZGQgYW4gaW5kaXJlY3Rpb24N CiBoZXJlIHRvIHRoZW4gaGF2ZSB0byBoYXZlIGEgcHJvdG9jb2wgZmllbGQgaW5zaWRlIHRoZSBP QU0uJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJn aW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEycHQ7IGZvbnQt ZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luLXRv cDo1cHQ7IG1hcmdpbi1ib3R0b206NXB0Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQpPQU0gd2hpY2ggYmVoYXZlcyBhcyBtdWNoIGFzIFBh c3NpdmUgT0FNIG9yIFNvbWV0aGluZy1pbi1iZXR3ZWVuLCBlLmcuIE9BTSBhcHBlbmRlZCB0byBk YXRhIHBhY2tldCBlaXRoZXIgYXQgdGhlIGRvbWFpbuKAmXMgZWRnZSBvciBvbi10aGUtZmx5LCBp ZGVudGlmaWVkIGJ5IHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBkYXRhIHBhY2tldCBjYXJyaWVk IGluIE5TSC48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFw dDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxzcGFuIGNsYXNzPSIiIHN0eWxl PSJmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiPiZu YnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWls eTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+VGhhdCdzIGNvcnJlY3QsIHdpdGggdGhlIE8gYml0 IGNsZWFyZWQ7IGl0J3MgYSBkYXRhIHBhY2tldCBhbmQgbm90IGFuIE9BTSBvbmUuJm5ic3A7PC9z cGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjow aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj4NCjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6MTJwdDsgZm9udC1mYW1p bHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Cjwvc3Bhbj48L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSIiIHN0eWxlPSJtYXJnaW4tdG9wOjVw dDsgbWFyZ2luLWJvdHRvbTo1cHQiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5 bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCkJlbG93IGFyZSBjaGFuZ2VzIEnigJlkIGxpa2UgdG8gcHJv cG9zZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NClNlY3Rp b24gMy4yIE8tYml0OjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYi Pg0KT0xEPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJz cDsmbmJzcDsgTyBiaXQ6IHdoZW4gc2V0IHRvIDB4MSBpbmRpY2F0ZXMgdGhhdCB0aGlzIHBhY2tl dCBpcyBhbiBPcGVyYXRpb25zLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWYiPg0KJm5ic3A7Jm5ic3A7IEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FN KSBtZXNzYWdlLiZuYnNwOyBUaGUgcmVjZWl2aW5nIFNGRiBhbmQ8L2Rpdj4NCjxkaXYgY2xhc3M9 IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1m YW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZuYnNwOyZuYnNwOyBTRnMgbm9kZXMgTVVTVCBl eGFtaW5lIHRoZSBwYXlsb2FkIGFuZCB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbiAoZS5nLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KJm5ic3A7Jm5ic3A7IHJl dHVybiBzdGF0dXMgaW5mb3JtYXRpb24pLiZuYnNwOyBPQU0gbWVzc2FnZSBzcGVjaWZpY3MgYW5k IGhhbmRsaW5nPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQom bmJzcDsmbmJzcDsgZGV0YWlscyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVu dC48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImJvcmRlci1zdHlsZTpub25lIG5vbmUgc29s aWQ7IGJvcmRlci1ib3R0b20tY29sb3I6d2luZG93dGV4dDsgYm9yZGVyLWJvdHRvbS13aWR0aDox cHQ7IHBhZGRpbmc6MGluIDBpbiAxcHQiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWYiPg0KRU5EPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjow aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj4NCk5FVzwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYi Pg0KTyBiaXQ6IHdoZW4gc2V0IHRvIDB4MSBpbmRpY2F0ZXMgdGhhdCBkYXRhIHBhY2tldCBpZGVu dGlmaWVkIGJ5IHRoZSBOZXh0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZiI+DQpQcm90b2NvbCB0eXBlIGhhcyBPQU0gbWV0YWRhdGEgYXBwZW5kZWQuPHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2lu OjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBmb250LWZh bWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0K PHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTonVGltZXMg TmV3IFJvbWFuJyxzZXJpZiI+Tm8uIElmIGl0IGlzIGEgZGF0YSBwYWNrZXQgaXQgZG9lcyBub3Qg aGF2ZSB0aGUgTyBiaXQgc2V0ICh0byAxIG9yIHRvIHdoaWNoZXZlciBvdGhlciBwb3NzaWJsZSB2 YWx1ZSBmb3IgdGhlIGJpdCA6LSk8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBz dHlsZT0iZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlm Ij4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1z aXplOjEycHQ7IGZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj5UaGUgZ29hbCBp cyB0aGF0IGxvb2tpbmcgYXQgYSBzaW5nbGUgYnV0IGl0IGNhbiBiZSB1bmRlcnN0b29kIGlmIGl0 IGlzIGEgZGF0YSBwYWNrZXQgKHdoaWNoIGNhbiBiZSB1c2VkLCBtYXJrZWQsIGV0Yy4gdG8gYmUg dXNlZCBmb3IgT0FNIHB1cnBvc2VzLCBvciBub3QpLiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4N CjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6J1RpbWVz IE5ldyBSb21hbicsc2VyaWYiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxzcGFuIGNsYXNz PSIiIHN0eWxlPSJmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbics c2VyaWYiPldlIGRvIG5vdCB3YW50IE9BTSBkaXJlY3QgZXhjZXB0aW9uIHByb2Nlc3NpbmcgZm9y IGRhdGEgcGFja2V0cy4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6 MTJwdDsgZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiPjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSIiIHN0eWxl PSJtYXJnaW4tdG9wOjVwdDsgbWFyZ2luLWJvdHRvbTo1cHQiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFw dDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCkRlZmluaXRpb24gb2YgdGhlIGZv cm1hdChzKTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCnVzZWQgYnkgT0FN IG1ldGFkYXRhIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjEx cHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQpFTkQ8L2Rpdj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i IiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KQXQgdGhlIGVuZCBvZiBTZWN0aW9uIDMuMjo8L2Rp dj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCk9MRDwvZGl2Pg0KPGRp diBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0 OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KJm5ic3A7Jm5ic3A7IFRoaXMgZHJh ZnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nIE5leHQgUHJvdG9jb2wgdmFsdWVzOjwvZGl2Pg0KPGRp diBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0 OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZv bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJzcDsmbmJzcDsgMHgxIDogSVB2NDwv ZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KJm5ic3A7Jm5ic3A7 IDB4MiA6IElQdjY8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4N CiZuYnNwOyZuYnNwOyAweDMgOiBFdGhlcm5ldDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i bWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWYiPg0KJm5ic3A7Jm5ic3A7IDB4NDogTlNIPC9kaXY+DQo8ZGl2IGNsYXNz PSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJzcDsmbmJzcDsgMHg1OiBNUExTPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJzcDsmbmJzcDsgMHg2 LTB4RkQ6IFVuYXNzaWduZWQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl cmlmIj4NCiZuYnNwOyZuYnNwOyAweEZFLTB4RkY6IEV4cGVyaW1lbnRhbDwvZGl2Pg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0iYm9yZGVyLXN0eWxlOm5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWJvdHRv bS1jb2xvcjp3aW5kb3d0ZXh0OyBib3JkZXItYm90dG9tLXdpZHRoOjFwdDsgcGFkZGluZzowaW4g MGluIDFwdCI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQpFTkQ8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KTkVXPC9k aXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJzcDsmbmJzcDsg VGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgTmV4dCBQcm90b2NvbCB2YWx1ZXM6PC9k aXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJzcDs8L2Rpdj4N CjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZuYnNwOyZuYnNwOyAweDEg OiBJUHY0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJz cDsmbmJzcDsgMHgyIDogSVB2NjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWYiPg0KJm5ic3A7Jm5ic3A7IDB4MyA6IEV0aGVybmV0PC9kaXY+DQo8ZGl2IGNsYXNzPSIi IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJzcDsmbmJzcDsgMHg0OiBOU0g8L2Rpdj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFw dDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZuYnNwOyZuYnNwOyAweDU6IE1Q TFM8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZuYnNwOyZu YnNwOyAweDY6IEFjdGl2ZSBPQU08L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxzcGFuIGNs YXNzPSIiIHN0eWxlPSJmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21h bicsc2VyaWYiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpD YWxpYnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0 OyBmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+QXMgcGVyIGFib3ZlIEkgZG8g bm90IGJlbGlldmUgdGhlcmUncyBhIHNpbmdsZSBPQU0gcHJvdG9jb2wuJm5ic3A7PC9zcGFuPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2lu OjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBmb250LWZh bWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPC9zcGFuPjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbi10b3A6 NXB0OyBtYXJnaW4tYm90dG9tOjVwdCI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBz dHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWls eTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KJm5ic3A7Jm5ic3A7IDB4Ny0weEZEOiBVbmFzc2lnbmVk PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQombmJzcDsmbmJz cDsgMHhGRS0weEZGOiBFeHBlcmltZW50YWw8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im1h cmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJy aSxzYW5zLXNlcmlmIj4NCkVORDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWYiPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJp ZiI+DQpBbmQsIGNvbnNlcXVlbnRseSwgc2VjdGlvbiAxMy4yLjUgaW4gSUFOQSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uIHdpbGwgcmVxdWVzdCBhbGxvY2F0aW9uIG9mIHZhbHVlIDB4NiB0byBiZSBh c3NpZ25lZCB0byBBY3RpdmUgT0FNIHByb3RvY29scy48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5 bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i bWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWYiPg0KR3JlYXRseSBhcHByZWNpYXRlIHlvdXIgY29uc2lkZXJhdGlvbiBh bmQgY29tbWVudHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+ DQombmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFw dDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxzcGFuIGNsYXNzPSIiIHN0eWxl PSJmb250LXNpemU6MTJwdDsgZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiPiZu YnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWls eTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+TXkg4oKsMC4wMi4mbmJzcDs8L3NwYW4+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5 OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3Bh biBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5OidUaW1lcyBOZXcg Um9tYW4nLHNlcmlmIj5UaGFua3MsPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIg c3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJp ZiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4gY2xhc3M9IiIgc3R5bGU9ImZvbnQt c2l6ZToxMnB0OyBmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+Q2FybG9zLiZu YnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6 MTJwdDsgZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiPjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSIiIHN0eWxl PSJtYXJnaW4tdG9wOjVwdDsgbWFyZ2luLWJvdHRvbTo1cHQiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFw dDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBSZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ibWFyZ2lu OjBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWYiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5 bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBjbGFzcz0iIiBzdHlsZT0ibWFyZ2luLXRvcDo1cHQ7IG1hcmdpbi1ib3R0 b206NXB0Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJtYXJnaW46MGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZiI+DQo8c3BhbiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOjEycHQ7IGZvbnQtZmFtaWx5 OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClJ0Zy1vb2FtLWR0IG1haWxpbmcgbGlzdDxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpSdGctb29hbS1kdEBpZXRmLm9yZyIgY2xhc3M9 IiIgc3R5bGU9ImNvbG9yOnB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+UnRnLW9v YW0tZHRAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGctb29hbS1kdCIgY2xhc3M9IiIgc3R5bGU9ImNvbG9y OnB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGctb29hbS1kdDwvYT48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_A19424902E4E499F9319AC2A1110F5FCciscocom_-- From nobody Mon Aug 8 17:32: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 80C8512D5AA; Mon, 8 Aug 2016 17:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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.247, 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 oIxTWZqtrGxr; Mon, 8 Aug 2016 17:31:10 -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 170B912D5A1; Mon, 8 Aug 2016 17:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19760; q=dns/txt; s=iport; t=1470702670; x=1471912270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ax0TF4amdw3+7OG01bDXC+WYEC4WU8xD8DYPqRTlvrk=; b=i/0AnUkNqqbzHCldkH78FCAZirgIdFnbHe+1hKgOzTWFxEUwbImhumPl 3vC1BT4733xiXK6G8ojW64frj6ymlwLayw2zG6zuwQ6E46NHlw76qjpeX nX3OXFAxfmM/mOEwdBH9TvRpfVvVRUuM76S+uPD5YOBjB6Gk4g238IVg9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAgCjI6lX/4MNJK1dg0VWfAe5F4F9J?= =?us-ascii?q?IV5AhyBJjgUAQEBAQEBAV0nhF4BAQQBAQEhBA0zBwQHBQsCAQgOAwQBAQECAiM?= =?us-ascii?q?DAgICJQsUAQgIAgQOBYgpCA6ycpAbAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBA?= =?us-ascii?q?YUpgXiCVYRAF4JqK4IvBZk5AYkYhXGBa4RbiH2MNIN3AR42ghIcgUxuhXd/AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.28,492,1464652800"; d="scan'208";a="308315747" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Aug 2016 00:31:08 +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 u790V8P4005958 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 00:31:08 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; Mon, 8 Aug 2016 20:31:07 -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; Mon, 8 Aug 2016 20:31:07 -0400 From: "Carlos Pignataro (cpignata)" To: Dave Dolson Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR4/B/s+mJr49HL0uqnvaJ3glSK6AkcOaAgAIHwQCAACcwgIAAUL4AgAAHt4CAAMQ4gIAYaUyA Date: Tue, 9 Aug 2016 00:31:06 +0000 Message-ID: <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@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> <83EF1E06-D242-4FE6-8C7A-B00AE858557B@cisco.com> <20160724114359.5714005.75862.99628@sandvine.com> In-Reply-To: <20160724114359.5714005.75862.99628@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.82.213.152] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "rtg-ooam-dt@ietf.org" , "Joel M. Halpern" , "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: Tue, 09 Aug 2016 00:31:13 -0000 SGkgRGF2ZSwNCg0KV2l0aCBhcG9sb2dpZXMgZm9yIHRoZSBtdWNoIGJlbGF0ZWQgcmVzcG9uc2U7 IHBsZWFzZSBmaW5kIG9uZSBjbGFyaWZpY2F0aW9uIGlubGluZToNCg0KPiBPbiBKdWwgMjQsIDIw MTYsIGF0IDE6NDQgUE0sIERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4gd3JvdGU6 DQo+IA0KPiBTaG91bGQgdGhlIGRvYyBzYXksDQo+IA0KPiAgIElmIHRoZSBPQU0gYml0IE89MCwg dGhpcyBpbmRpY2F0ZXMgdGhlIFNGRiBNVVNUIGZvcndhcmQNCj4gICB0aGUgcGFja2V0IGJhc2Vk IHNvbGVseSBvbiB0aGUgU1BJIGFuZCBTSSBmaWVsZHMsIHdpdGhvdXQNCj4gICAgcmVnYXJkIHRv IG5leHQgcHJvdG9jb2wgb3IgZnVydGhlciBwYXlsb2FkIGhlYWRlcnMuDQo+IA0KPiAgIElmIHRo ZSBPQU0gYml0IE89MSwgdGhpcyBpbmRpY2F0ZXMgdGhlIFNGRiDigI5NVVNUIE5PVA0KPiAgIHBy b2Nlc3MgdGhlIHBhY2tldCBzb2xlbHkgYnkgU1BJL1NJIGZvcndhcmRpbmcgYnV0DQo+ICAgaW5z dGVhZCBieSB0aGUgc2VtYW50aWNzIHNwZWNpZmllZCBieSB0aGUg4oCOT0FNDQo+ICAgcHJvdG9j b2wgbmFtZWQgaW4gdGhlIE5leHQgUHJvdG9jb2wgZmllbGQuDQo+IA0KPiBJIHRoaW5rIHRoZXNl IHBhcmFncmFwaHMgZ2V0IHRvIHRoZSBvcHRpbWl6YXRpb24gZm9yIFNGRnMsDQo+IGFuZCBJIHRo aW5rIHByb3ZpZGUgcHJlY2lzZSBsYW5ndWFnZSB3aXRob3V0IGRlZmluaW5nDQo+IE9BTSBwcm90 b2NvbHMuDQo+IA0KPiDigI5XaXRob3V0IGZ1cnRoZXIgbGFuZ3VhZ2UsIGl0IGlzIG5vdCBzcGVj aWZpZWQgaG93DQo+IHRvIGhhbmRsZSAqYW55KiBuZXh0LXByb3RvY29sIHZhbHVlcyB3aGVuIE89 MS4NCj4gDQo+IEFuZCB3aGVuIHNwZWNpZmllZC4uLg0KPiANCj4gQXMgZm9yIHNvLWNhbGxlZCBw aWdneWJhY2sgT0FNLCB3ZSBjb3VsZCBkZWZpbmUNCj4gdGhhdCBpZiBPPTENCg0KVGhpcyBtaWdo dCBiZSB0aGUgc291cmNlIG9mIHRoZSBjb25mdXNpb24g4oCUIGlmIE89MSwgdGhhdOKAmXMgbm90 IGEgZGF0YSBwYWNrZXQuIFRoZSBpZGVhIHdpdGggcGlnZ3liYWNrIE9BTSBpcyB0byBkaXN0dXJi IHRoZSBwYWNrZXQgdGhlIGxlYXN0LiBJZiB3ZSBmbGFnIGEgZGF0YSBwYWNrZXQgYXMgT0FNLCBp dCB0YWtlcyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IHByb2Nlc3NpbmcgcGF0aC4gDQoNClBpZ2d5 YmFjayBPQU0gaXMgYSBkYXRhIHBhY2tldCwgTz0wLCB3aXRoIGVtYmVkZGVkIGluc3RydW1lbnRh dGlvbiwgYXMgaW4gZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tdHJhbnNwb3J0Lg0KDQo+IGFu ZCBOZXh0IFByb3RvY29sPUlQdjQgdGhlcmUgbWF5IGJlDQo+IGFuIE9BTSBoZWFkZXIgZm9sbG93 aW5nIHRoZSBJUHY0IHBhY2tldCwNCj4gbG9jYXRlZCB1c2luZyBJUHY0IHRvdGFsIGxlbmd0aC7i gI4gT3Igd2UgY291bGQNCj4gZGVmaW5lIGEgbmV3IG51bWJlciBmb3IgSVB2NC13aXRoLU9BTS10 cmFpbGVyLg0KDQpTb3JyeSBidXQgdGhlcmUgc2VlbXMgdG8gYmUgYSBsb3Qgb2YgdW5uZWNlc3Nh cnkgY29tcGxleGl0eSBpbiB0aGF0LiBXaHkgYW4gT0FNIGhlYWRlcj8gV2h5IGEgdHJhaWxlcj8g Tz0xIHdpdGggSVB2NCwgdG8gbWUsIG1lYW5zIGFuIE9BTSBwYWNrZXQgaW4gSVB2NCAoYXMgZm9y IGV4YW1wbGUgYW4gSUNNUHY0IHBhY2tldCwgb3IgZm9yIGV4YW1wbGUgYSBCRkRvVURQb0lQdjQg cGFja2V0Lg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCj4gDQo+IE5vdGUgdGhhdCBmb3Ig TmV4dCBQcm90b2NvbCBvZiBNUExTLCBFdGhlcm5ldCBvcg0KPiBOU0gsIHRoZXNlIGRvIG5vdCBo YXZlIHRvdGFsLWxlbmd0aCBmaWVsZHMgdGhhdA0KPiB3b3VsZCBhbGxvdyB0cmFpbGluZyBPQU0u DQo+IA0KPiBGdXJ0aGVybW9yZSwgd2UgY291bGQgc2F5IHRoYXQgaWYgTz0xLCB0aGUgU0ZGDQo+ IE1VU1QgZGV0ZXJtaW5lIGlmIHRoZSBwYXlsb2FkIGlzIGFkZHJlc3NlZA0KPiB0byBpdCwgZS5n LiwgaWYgdGhlIG5leHQgSVB2NiBwYWNrZXQgaXMgYWRkcmVzc2VkDQo+IHRvIHRoZSBTRkYncyBs b29wLWJhY2sgYWRkcmVzcy4NCj4gDQo+IEkgdGhpbmsgbWFueSBvZiB1cyBhcmUgYW54aW91cyB0 byBnZXQgdG8gd29yaw0KPiBjbGFyaWZ5aW5nIHRoZXNlIHRoaW5ncy4NCj4gDQo+IC1EYXZlDQo+ IA0KPiAgT3JpZ2luYWwgTWVzc2FnZQ0KPiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4NCj4gU2VudDog U2F0dXJkYXksIEp1bHkgMjMsIDIwMTYgODowMiBQTQ0KPiBUbzogQ2FybG9zIFBpZ25hdGFybyAo Y3BpZ25hdGEpDQo+IENjOiBHcmVnb3J5IE1pcnNreTsgcnRnLW9vYW0tZHRAaWV0Zi5vcmc7IHNm Y0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gW1J0Zy1vb2FtLWR0XSBJZGVudGlmeWlu ZyBPQU0gaW4gTlNIDQo+IA0KPiANCj4gQ2FybG9zLA0KPiAgICAgWWVzeCwgSSBhbSB0YWxraW5n IGFib3V0IHRoZSBzYW1lIGNhc2UgdGhhdCBvdGhlciBmb2xrcyBhcmUgY2FsbGluZw0KPiBwaWdn eS1iYWNrIE9BTS4gIEkgd2FudGVkIHRvIGRlc2NyaWJlIHRoZSBjYXNlIGluc3RlYWQgb2YgbmFt aW5nIGl0LA0KPiBib3RoIGZvciBjbGFyaXR5IGFuZCB0byByYWlzZSB0aGUgcG9pbnQgYWJvdXQg d2hvIG5lZWRzIHRvIHByb2Nlc3MgdGhlDQo+IE9BTSBpbmZvcm1hdGlvbi4NCj4gDQo+IFlvdSBh c2sgaG93IHRoZSBTRiAob3IgZXZlbiBpZiB0aGUgU0ZGIGlmIHRoYXQgYXBwbGllc18gd2lsbCBr bm93IHRoZXJlDQo+IGlzIGEgdXNlciBwYWNrZXQuICBJIHRoaW5rIHRoZSBwcm9wb3NhbCBpcyB0 byB1c2UgdGhlIE9BTSBiaXQNCj4gc3BlY2lmaWNhbGx5IHRvIGluZGljYXRlIHRoYXQuDQo+IFRo ZSByZXN1bHQgb2YgdGhhdCB1c2FnZSBpcyB0aGF0IHRoZSBTRkYgbmVlZHMgdG8gY2hlY2sgdGhl IHBhY2tldCB0eXBlDQo+IGluIG9yZGVyIHRvIHJlY29nbml6ZSBPQU0gcGFja2V0cyB0aGF0IGFy ZSBub3QgdXNlciBkYXRhIHBhY2tldHMgYW5kDQo+IHRoYXQgaXQgbmVlZHMgdG8gcHJvY2Vzcy4N Cj4gVGhhdCBpcyBhbiB1bmZvcnR1bmF0ZSBjb21wbGV4aXR5IGluIGEgY3JpdGljYWwgcHJvY2Vz c2luZyBwYXRoLg0KPiANCj4gSSBzdXNwZWN0IGl0IGlzIHRoaXMgZWZmaWNpZW5jeSB0aGF0IGlz IGRyaXZpbmcgeW91Lg0KPiBXaGljaCBzdWdnZXN0cyBhbm90aGVyIHBvc3NpYmxlIGludGVycHJl dGF0aW9uLg0KPiBXaGF0IGlmDQo+IDEpIHdlIHNldCB0aGUgT0FNIGJpdCBmb3IgYW55IHBhY2tl dCB0aGF0IG5lZWRzIE9BTSBwcm9jZXNzaW5nDQo+IDIpIEFuZCBkZWZpbmUgYSAoc2V0IG9mKSBw YWNrZXQgdHlwZXMgZm9yIHBhY2tldHMgd2hlcmUgdGhlIGNvdG5lbnQgaXMgT0FNDQo+IDMpIEFu ZCBkZWNsYXJlIHRoYXQgYW55IG90aGVyIHBhY2tldCB0eXBlcyBhcmUgdXNlciBwYWNrZXRzIHdp dGggT0FNIFRMVg0KPiBpbmZvcm1hdGlvbi4NCj4gDQo+IFRoaXMgaXMgc2xpZ2h0bHkgc2ltcGxl ciBpZiB3ZSBkZWNsYXJlIGEgc2luZ2xlIE9BTSBwYWNrZXQgdHlwZSBpbiB0aGUNCj4gTlNIIGhl YWRlciwgYXMgdGhhdCBhdm9pZHMgYW55IGFtYmlndWl0eS4gIChXaGV0aGVyIHRoZSBkZXZpY2Ug Y2FuDQo+IGFjdHVhbGx5IGRvIHRoZSBPQU0gc3RpbGwgZGVwZW5kcyB1cG9uIGl0IHVuZGVyc3Rh bmRpbmcgdGhlIE9BTSBwYWNrZXRzLA0KPiBidXQgdGhhdCBpcyB0cnVlIG9mIGFsbCBzdHJ1Y3R1 cmVzLikgIFRoaXMgZG9lcyBhdm9pZCBjcmVhdGluZyBhbnkNCj4gY29uZnVzaW9uIGJldHdlZW4g dGhlIHVzZSBvZiB0aGUgT0FNIGZsYWcgYW5kIHRoZSBwYWNrZXQgdHlwZS4NCj4gDQo+IFlvdXJz LA0KPiBKb2VsDQo+IA0KPiBPbiA3LzIzLzE2IDc6MzQgUE0sIENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKSB3cm90ZToNCj4+IEhpLCBKb2VsLA0KPj4gDQo+Pj4gT24gSnVsIDIzLCAyMDE2LCBh dCA3OjQ1IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0K Pj4+IA0KPj4+IFRoZXJlIGlzIG9uZSBzaXR1YXRpb24gdGhhdCBmb2xrcyBhcmUgYXNraW5nIGZv ciB0aGF0IHNlZW1zIG5vdCB0byBiZSBjbGVhcmx5IGNvdmVyZWQgaW4gdGhlIHNwZWMsIGFuZCBh cHBlYXJzIHRvIG1lIHRvIGJlIGNsYXJpZmllZCBieSBHcmVnJ3MgcHJvcG9zYWwuDQo+Pj4gDQo+ Pj4gV2UgaGF2ZSBoYWQgYSBjb3VwbGUgb2YgcmVxdWVzdHMgZm9yIHRoZSBhYmlsaXR5IHRvIHB1 dCBPQU0gbWFya2luZyBvbiB1c2VyIGRhdGEgcGFja2V0cy4gIFRoZSBtb3N0IG9idmlvdXMgdXNl IGlzIHRvIG1vbml0b3IgaG93IGxvbmcgaXQgdGFrZXMgTlNILWF3YXJlIHNlcnZpY2UgZnVuY3Rp b25zIHRvIHByb2Nlc3MgdGhlIHVzZXIgcGFja2V0cy4NCj4+PiANCj4+IA0KPj4gSnVzdCB0byBt YWtlIHN1cmUgSSB1bmRlcnN0YW5kLCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGNhc2Ugb2Yg 4oCccGlnZ3ktYmFjayBPQU3igJ0sIGNvcnJlY3Q/DQo+PiANCj4+PiBJZiB0aGUgb25seSBjYXNl IHdoZXJlIHdlIHdpbGwgbmVlZCB0aGlzIGlzIGZvciBzZXJ2aWNlIGZ1bmN0aW9uIHByb2Nlc3Np bmcsIHRoZSBwdXR0aW5nIGl0IGluIHRoZSBUTFZzLCB3aXRob3V0IGFkZGl0aW9uYWwgbWFya2lu Z3MsIGFuZCBhbGxvd2luZyB0aGUgc2VydmljZSBmdW5jdGlvbnMgd2hpY2ggdW5kZXJzdGFuZCB0 aGUgVExWIHRvIHdvcmsgd2l0aCBpdCBzZWVtcyBzdWZmaWNpZW50Lg0KPj4+IA0KPj4+IEJ1dCBp dCBpcyBub3QgY2xlYXIgdG8gbWUgdGhhdCB0aGVyZSBpcyBub3QgYSBkZXNpcmUgKHdoZXRoZXIg aXQgaXMgYSByZXF1aXJlbWVudCBpcyBwcm9iYWJseSBhbiBpbXBvcnRhbnQgb3BlbiBxdWVzdGlv bikgZm9yIHNpbWlsYXIgY2FwYWJpbGl0eSBhdCBTRkYuICBJZiB3ZSBoYXZlIHNpdHVhdGlvbnMg d2hlcmUgU0ZGLCBpbiBwYXNzaW5nIHVzZXIgZGF0YSBwYWNrZXRzLCBhbHNvIG5lZWQgdG8gcGVy Zm9ybSBPQU0gb3BlcmF0aW9ucywgdGhlbiBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIG5lZWQgdGhl IE9BTSBiaXQgdG8gdGVsbCB0aGUgU0ZGIHRvIGxvb2sgYXQgdGhpcy4NCj4+IA0KPj4gSWYgeW91 IHNldCB0aGUgTyBiaXQgaW4gYSB1c2VyIGRhdGEgcGFja2V0LCBob3cgd291bGQgYSBzeXN0ZW0g aW5mZXIgdGhhdOKAmXMgbm90IGFuIE9BTSBwYWNrZXQ/DQo+PiANCj4+IFRoYW5rcywNCj4+IA0K Pj4g4oCUIENhcmxvcy4NCj4+IA0KPj4+IEVmZm9ydHMgd2l0aCByb3V0ZXJzIHRvIGRvIHRoaXMg d2l0aCByb3V0ZXIgYWxlcnQgb3B0aW9ucyBoYXZlIGJlZW4gYSBtZXNzLiBJZiB3ZSBuZWVkIHRo ZSBjYXBhYmlsaXR5LCBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIHJlYWxseSB3YW50IGl0IGluIGEg c3RhbmRhcmRpemVkIGFuZCBlZmZpY2llbnQgcGxhY2UuDQo+Pj4gSWYgd2UgYXJlIHZlcnkgc3Vy ZSB3ZSBkb24ndCBuZWVkIHRoaXMsIHRoZW4gd2Ugc2hvdWxkIHdyaXRlIHRoYXQgZG93biwgYW5k IG1vdmUgb24uDQo+Pj4gDQo+Pj4gWW91cnMsDQo+Pj4gSm9lbA0KPj4+IA0KPj4+IE9uIDcvMjMv MTYgMTI6MjQgUE0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSB3cm90ZToNCj4+Pj4gSGks IEdyZWcsDQo+Pj4+IA0KPj4+Pj4gT24gSnVsIDIyLCAyMDE2LCBhdCAxMDoyNCBBTSwgR3JlZ29y eSBNaXJza3kNCj4+Pj4+IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20gPG1haWx0bzpncmVn b3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gSGkgQ2FybG9z LA0KPj4+Pj4gdGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIgY29tbWVudHMuIElmIEkgdW5kZXJz dGFuZCBjb3JyZWN0bHksIHlvdQ0KPj4+Pj4gc3VnZ2VzdCB0byBleHBvc2UgcHJvdG9jb2wgdHlw ZXMgb2YgT0FNIGFzIE5leHQgUHJvdG9jb2wgcmF0aGVyIHRoYW4NCj4+Pj4+IHRvIHVzZSBzaW5n bGUgQWN0aXZlIE9BTSBwcm90b2NvbCB0eXBlIGFuZCB1c2UgT09BTSBIZWFkZXIgdG8gZGVtdXgN Cj4+Pj4+IE9PQU0gdHlwZS4gVGhlbiwgdGhlIE5leHQgUHJvdG9jb2wgcmVnaXN0cnkgd2lsbCBo YXZlIHRvIGFsbG9jYXRlDQo+Pj4+PiB2YWx1ZXMgZm9yIHNpbmdsZS1ob3AgQkZELCBtdWx0aS1o b3AgQkZELCBtdWx0aXBvaW50IEJGRCwgUy1CRkQsIEVjaG8NCj4+Pj4+IFJlcXVlc3QvUmVwbHks IEFJUyBwcm90b2NvbCwgQWN0aXZlIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IHByb3RvY29sLA0K Pj4+Pj4gYW5kIEnigJl2ZSBvbmx5IGxpc3RlZCBzb21lIG9mIEFPTSBwcm90b2NvbHMgdGhhdCBt YXkgYmUgdXNlZCB0bw0KPj4+Pj4gb3BlcmF0ZSwgYWRtaW5pc3RlciBhbmQgbWFpbnRhaW4gU0ZQ Lg0KPj4+PiANCj4+Pj4gWWVzLCB0aGUgcHJvdG9jb2wgZmllbGQgb3VnaHQgdG8gcmVnaXN0ZXIg dGhlIE9BTSBwcm90b2NvbHMgdGhhdCB3aWxsIGJlDQo+Pj4+IHVzZWQgYW5kIGltcGxlbWVudGVk IGFuZCBkZXBsb3llZCDigJQgb2YgY291cnNlIG5vdCBhbGwgcG90ZW50aWFsDQo+Pj4+IHZhcmlh dGlvbnMgYW5kIHBlcm11dGF0aW9ucyBvZiBwb3NzaWJsZSBPQU1zICh3aGF0IGlzIEFJUyBwcm90 b2NvbD8pDQo+Pj4+IA0KPj4+Pj4gQWRkaXRpb25hbGx5LCB5b3XigJl2ZSBzdWdnZXN0ZWQgdGhh dCBvbmx5IE8tYml0IHZhbHVlIHRvIGJlIHVzZWQgdG8NCj4+Pj4+IGRldGVybWluZSB3aGV0aGVy IHBhY2tldCBzaG91bGQgYmUgcHJvY2Vzc2VkIGFzIE9BTSBvciBkYXRhIHBhY2tldC4NCj4+Pj4+ IEhlbmNlIHNob3VsZCBJIGV4cGVjdCB0aGF0IE8tYml0IGlzIHNldCBmb3IgQkZELCBBSVMsIGFu ZCBFY2hvDQo+Pj4+PiBSZXF1ZXN0L1JlcGx5IHBheWxvYWQgYW5kIHNob3VsZCBub3QgYmUgc2V0 IGlmIHRoZSBOZXh0IFByb3RvY29sIGlzDQo+Pj4+PiBuZWl0aGVyIG9mIHByb3RvY29scyBsaXN0 ZWQgYWJvdmU/IFNob3VsZCBzdWNoIHNpdHVhdGlvbiwgaS5lLiBOZXh0DQo+Pj4+PiBQcm90b2Nv bCB2YWx1ZSBpcyBNUExTIGFuZCBPLWJpdCBzZXQgdG8gMHgxLCBzaG91bGQgYmUgdmlld2VkIGFz IGVycm9yDQo+Pj4+PiBhbmQgdGhlIHBhY2tldCBkcm9wcGVkPyBPciB5b3UgcHJvcG9zZSB0aGF0 IHRoZSBOZXh0IFByb3RvY29sIHRha2VzDQo+Pj4+PiBwcmVjZWRlbmNlIGFuZCB0aGUgcGFja2V0 IHRyZWF0ZWQgYXMgZGF0YT8gT3IgcGFja2V0IHZpZXdlZCBhcyBPQU0gYW5kDQo+Pj4+PiBwYXNz ZWQgdG8gdGhlIGxvY2FsIE9BTSBlbnRpdHk/IE9yIGhvdyB0byBpbnRlcnByZXQgc2l0dWF0aW9u IHdoZW4NCj4+Pj4+IE8tYml0IGlzIGNsZWFyZWQgYW5kIHRoZSBOZXh0IFByb3RvY29sIHZhbHVl IGlzIG9uZSBvZiBPQU0gcHJvdG9jb2xzPw0KPj4+Pj4gVGhpcyBpcyB0aGUgc2l0dWF0aW9uIHRo YXQsIGluIG15IHZpZXcsIGlzIGFtYmlndW91cyBhbmQNCj4+Pj4+IHVuZGVyLXNwZWNpZmllZCBp biB0aGUgY3VycmVudCBOU0ggZG9jdW1lbnQuIE15IHByb3Bvc2FsIGlzIGFuIGF0dGVtcHQNCj4+ Pj4+IHRvIG1ha2UgcmVsYXRpb25zaGlwIGJldHdlZW4gT0FNIGFuZCBkYXRhIHBhY2tldHMgbW9y ZSBkZXRlcm1pbmlzdGljLg0KPj4+PiANCj4+Pj4gQW5zd2VyaW5nIGFsbCB0aG9zZSBxdWVzdGlv bnMgKHdoaWNoIGFyZSByZWFsbHkgc2xpZ2h0IHBlcm11dGF0aW9ucyBvZg0KPj4+PiB0aGUgc2Ft ZSBxdWVzdGlvbikgaW4gb25lIHNob3Q6IHRvIG1lLCBPPTAgaXMgYSBkYXRhIHBhY2tldCBhbmQg Tz0xIGlzDQo+Pj4+IGFuIE9BTSBwYWNrZXQuIElmIHRoZSBkYXRhIHByb2Nlc3NpbmcgZG9lcyBu b3QgaGF2ZSBhIGhhbmRsZXIgZm9yIHRoZQ0KPj4+PiBwcm90b2NvbCBpbiB0aGUgUElELCBvciBp dOKAmXMgYW4gdW5kZWZpbmVkLCBkcm9wcyB0byB0aGUgYml0IGJ1Y2tldC4NCj4+Pj4gRXF1YWxs eSwgaWYgdGhlIE9BTSBoYW5kbGVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIHByb3RvY29sIElEIGNh cnJpZWQgYXMNCj4+Pj4gT0FNLCBwdWZmLiBJUCBjYW4gY2FycnkgZGF0YSBvciBPQU0gZm9yIGV4 YW1wbGUgYnkgdGhlIHdheS4NCj4+Pj4gDQo+Pj4+IEl0IGRvZXMgbm90IGdldCBhbnkgc2ltcGxl ciBhbmQgdW5hbWJpZ3VvdXMgdGhhbiB0aGF0LiBXaGF04oCZcyB0aGUNCj4+Pj4gYWR2YW50YWdl IG9mIG1vdmluZyB0aGUgT0FNIFBJRCBmdXJ0aGVyIGluc2lkZT8NCj4+Pj4gDQo+Pj4+IEFuZCBJ IGRvIG5vdCBiZWxpZXZlIHRoZXJl4oCZcyB1bmRlcnNwZWNpZmljYXRpb24gaW4gTlNIIC0+IE89 MSwgT0FNDQo+Pj4+IHRyZWF0bWVudCwgbm90IGRldGFpbGVkIGhlcmUuDQo+Pj4+IA0KPj4+PiBU aGFua3MsDQo+Pj4+IA0KPj4+PiDigJQgQ2FybG9zLg0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4gICAg ICAgICAgICAgICBSZWdhcmRzLA0KPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg R3JlZw0KPj4+Pj4gDQo+Pj4+PiAqRnJvbToqIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBb bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCj4+Pj4+ICpTZW50OiogRnJpZGF5LCBKdWx5IDIy LCAyMDE2IDEwOjEwIEFNDQo+Pj4+PiAqVG86KiBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJz a3lAZXJpY3Nzb24uY29tDQo+Pj4+PiA8bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNv bT4+DQo+Pj4+PiAqQ2M6KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+OyBydGct b29hbS1kdEBpZXRmLm9yZw0KPj4+Pj4gPG1haWx0bzpydGctb29hbS1kdEBpZXRmLm9yZz4NCj4+ Pj4+ICpTdWJqZWN0OiogUmU6IFtSdGctb29hbS1kdF0gSWRlbnRpZnlpbmcgT0FNIGluIE5TSA0K Pj4+Pj4gDQo+Pj4+PiBHcmVnLA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFBsZWFzZSBmaW5kIHNv bWUgY29tbWVudHMgaW5saW5lLg0KPj4+Pj4gDQo+Pj4+PiBUaHVtYiB0eXBlZCBieSBDYXJsb3Mg UGlnbmF0YXJvLg0KPj4+Pj4gRXhjdXplIHR5cG9mcmFwaGljYWsgZXJyb3dzDQo+Pj4+PiANCj4+ Pj4+IA0KPj4+Pj4gT24gSnVsIDIxLCAyMDE2LCBhdCAwOTowMSwgR3JlZ29yeSBNaXJza3kgPGdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbQ0KPj4+Pj4gPG1haWx0bzpncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb20+PiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gICBEZWFyIEFsbCwNCj4+Pj4+ICAg d2UgaGFkIHZlcnkgZ29vZCBkaXNjdXNzaW9uIG9uIE9BTSB0aGlzIHdlZWsuIFdl4oCZdmUgdG91 Y2hlZCBvbg0KPj4+Pj4gICBBY3RpdmUsIFBhc3NpdmUgYW5kIFNvbWV0aGluZy1pbi1iZXR3ZWVu IE9BTS4gQnV0IGNhbiBOU0ggaW5kaWNhdGUNCj4+Pj4+ICAgd2hpY2ggT0FNIHR5cGUsIGlmIGFu eSwgYXNzb2NpYXRlZCB3aXRoIGEgcGFja2V0PyBJIHRoaW5rIHRoYXQgdGhlDQo+Pj4+PiAgIGN1 cnJlbnQgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLXNmYy1uc2ggZG9lcyBub3QgYWxsb3cgdGhhdCBh bmQgbWF5DQo+Pj4+PiAgIGJlIGFtYmlndW91cyBpbiBzb21lIGNhc2VzLiBJIHByb3Bvc2UgY2hh bmdlIHRvIGludGVycHJldGF0aW9uIGFuZA0KPj4+Pj4gICBhcHBsaWNhYmlsaXR5IGRlc2NyaXB0 aW9uIG9mIHRoZSBPKEFNKSBmbGFnIGFuZCBhbGxvY2F0aW9uIG9mIHRoZQ0KPj4+Pj4gICBuZXcg cHJvdG9jb2wgdHlwZSB0byBiZSB1c2VkIGluIHRoZSBOZXh0IFByb3RvY29sIGZpZWxkLg0KPj4+ Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQWN0aXZlLCBwYXNzaXZlIGFuZCBzb21ldGhpbmct aW4tYmV0d2VlbiBhcmUgbm90IE9BTSBwcm90b2NvbCB0eXBlcw0KPj4+Pj4gYnV0IHJhdGhlciB0 aGV5IGFyZSBtZWFzdXJpbmcgbWV0aG9kcy4gQWN0aXZlIE9BTSBjYW4gaW5jbHVkZSBhDQo+Pj4+ PiBwbHVyYWxpdHkgb2YgT0FNIHByb3RvY29scywgaW5jbHVkaW5nIEJGRCwgUy1CRkQsIHNvbWV0 aGluZy1vdmVyLWlwLCBldGMuDQo+Pj4+PiANCj4+Pj4+IEkgYWxzbyBiZWxpZXZlIHRoYXQgdGhl IGN1cnJlbnQgT0FNIHRleHQgaW4gTlNIIGlzIG5vdCBhbWJpZ3VvdXMgYW5kDQo+Pj4+PiBhbGxv d3MgZW5vdWdoIHByb2Nlc3Npbmcgb2YgdGhlIGhlYWRlciB0byB1bmRlcnN0YW5kIHNvbWV0aGlu ZyBpcyBPQU0sDQo+Pj4+PiB3aXRob3V0IGdvaW5nIHRoZSBzcGVjaWZpY3Mgb2YgYW4gT0FNIGhh bmRsZXIuDQo+Pj4+PiANCj4+Pj4+IFRoZXJlZm9yZSwgSSBvcHBvc2UgdGhpcyBjaGFuZ2UuDQo+ Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gICBSRkMgNzc5OSBkZWZpbmVzIEFjdGl2ZSBPQU0gYXMgZm9s bG93aW5nOg0KPj4+Pj4gICBBbiBBY3RpdmUgTWV0cmljIG9yIE1ldGhvZCBkZXBlbmRzIG9uIGEg ZGVkaWNhdGVkIG1lYXN1cmVtZW50DQo+Pj4+PiAgIHBhY2tldCBzdHJlYW0gYW5kIG9ic2VydmF0 aW9ucyBvZiB0aGUgc3RyZWFtLg0KPj4+Pj4gICBUaHVzLCByZWdhcmRsZXNzIG9mIGVuY2Fwc3Vs YXRpb24gdXNlZCBieSBPQU0sIGl0IGlzIHRoZSBwYWNrZXQNCj4+Pj4+ICAgY29uc3RydWN0ZWQg c29sZWx5IGZvciBtb25pdG9yaW5nLCBtZWFzdXJpbmcgbmV0d29ya+KAmXMgbWV0cmljIGFuZA0K Pj4+Pj4gICBzaG91bGQgbm90IGxlYXZlIGdpdmVuIGRvbWFpbi4gQW5kLCBJIGJlbGlldmUsIHN1 Y2ggcGFja2V0cyBzaG91bGQNCj4+Pj4+ICAgYmUgaWRlbnRpZmllZCBieSB0aGUgcHJvdG9jb2wg dHlwZSBvZiB0aGVpciBvd24uDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gU2VlbXMgeW91IGFyZSBh ZHZvY2F0aW5nIGZvciBhIHNpbmdsZSAiT0FNIiBwcm90b2NvbCB0eXBlIGZvciBPQU0NCj4+Pj4+ IHBhY2tldHMuIFRoZSBmdW5jdGlvbmFsaXR5IG9mIGlkZW50aWZ5aW5nIHNvbWV0aGluZyBhcyBP QU0gaXMgaW4gdGhlDQo+Pj4+PiBPLWJpdCwgc28gbm8gbmVlZCB0byB3YXN0ZSBiaXRzIGluIGR1 cGxpY2F0aW9uLg0KPj4+Pj4gDQo+Pj4+PiBUaGVuLCBhdCBzb21lIHBvaW50LCB5b3UgaGF2ZSB0 byBkaWZmZXJlbnRpYXRlIGlmIGFuIE9BTSBpcywgc2F5LCBJUA0KPj4+Pj4gb3IgInJhdyBCRkQi IG9yIHNvbWV0aGluZyBlbHNlLiBUaGF0J3Mgd2hhdCB0aGUgUHJvdG9jb2wgZmllbGQgaXMgZm9y Lg0KPj4+Pj4gSSBkbyBub3Qgc2VlIGEgbmVlZCB0byBhZGQgYW4gaW5kaXJlY3Rpb24gaGVyZSB0 byB0aGVuIGhhdmUgdG8gaGF2ZSBhDQo+Pj4+PiBwcm90b2NvbCBmaWVsZCBpbnNpZGUgdGhlIE9B TS4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAgIE9BTSB3aGljaCBiZWhhdmVzIGFzIG11Y2ggYXMg UGFzc2l2ZSBPQU0gb3IgU29tZXRoaW5nLWluLWJldHdlZW4sDQo+Pj4+PiAgIGUuZy4gT0FNIGFw cGVuZGVkIHRvIGRhdGEgcGFja2V0IGVpdGhlciBhdCB0aGUgZG9tYWlu4oCZcyBlZGdlIG9yDQo+ Pj4+PiAgIG9uLXRoZS1mbHksIGlkZW50aWZpZWQgYnkgdGhlIHByb3RvY29sIHR5cGUgb2YgdGhl IGRhdGEgcGFja2V0DQo+Pj4+PiAgIGNhcnJpZWQgaW4gTlNILg0KPj4+Pj4gDQo+Pj4+PiANCj4+ Pj4+IFRoYXQncyBjb3JyZWN0LCB3aXRoIHRoZSBPIGJpdCBjbGVhcmVkOyBpdCdzIGEgZGF0YSBw YWNrZXQgYW5kIG5vdCBhbg0KPj4+Pj4gT0FNIG9uZS4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAg IEJlbG93IGFyZSBjaGFuZ2VzIEnigJlkIGxpa2UgdG8gcHJvcG9zZToNCj4+Pj4+ICAgU2VjdGlv biAzLjIgTy1iaXQ6DQo+Pj4+PiAgIE9MRA0KPj4+Pj4gICAgICBPIGJpdDogd2hlbiBzZXQgdG8g MHgxIGluZGljYXRlcyB0aGF0IHRoaXMgcGFja2V0IGlzIGFuIE9wZXJhdGlvbnMsDQo+Pj4+PiAg ICAgIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKSBtZXNzYWdlLiAgVGhlIHJl Y2VpdmluZw0KPj4+Pj4gICBTRkYgYW5kDQo+Pj4+PiAgICAgIFNGcyBub2RlcyBNVVNUIGV4YW1p bmUgdGhlIHBheWxvYWQgYW5kIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9uDQo+Pj4+PiAgIChlLmcu DQo+Pj4+PiAgICAgIHJldHVybiBzdGF0dXMgaW5mb3JtYXRpb24pLiAgT0FNIG1lc3NhZ2Ugc3Bl Y2lmaWNzIGFuZCBoYW5kbGluZw0KPj4+Pj4gICAgICBkZXRhaWxzIGFyZSBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPj4+Pj4gICBFTkQNCj4+Pj4+ICAgTkVXDQo+Pj4+PiAg IE8gYml0OiB3aGVuIHNldCB0byAweDEgaW5kaWNhdGVzIHRoYXQgZGF0YSBwYWNrZXQgaWRlbnRp ZmllZCBieQ0KPj4+Pj4gICB0aGUgTmV4dA0KPj4+Pj4gICBQcm90b2NvbCB0eXBlIGhhcyBPQU0g bWV0YWRhdGEgYXBwZW5kZWQuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gTm8uIElmIGl0IGlzIGEg ZGF0YSBwYWNrZXQgaXQgZG9lcyBub3QgaGF2ZSB0aGUgTyBiaXQgc2V0ICh0byAxIG9yIHRvDQo+ Pj4+PiB3aGljaGV2ZXIgb3RoZXIgcG9zc2libGUgdmFsdWUgZm9yIHRoZSBiaXQgOi0pDQo+Pj4+ PiANCj4+Pj4+IFRoZSBnb2FsIGlzIHRoYXQgbG9va2luZyBhdCBhIHNpbmdsZSBidXQgaXQgY2Fu IGJlIHVuZGVyc3Rvb2QgaWYgaXQgaXMNCj4+Pj4+IGEgZGF0YSBwYWNrZXQgKHdoaWNoIGNhbiBi ZSB1c2VkLCBtYXJrZWQsIGV0Yy4gdG8gYmUgdXNlZCBmb3IgT0FNDQo+Pj4+PiBwdXJwb3Nlcywg b3Igbm90KS4NCj4+Pj4+IA0KPj4+Pj4gV2UgZG8gbm90IHdhbnQgT0FNIGRpcmVjdCBleGNlcHRp b24gcHJvY2Vzc2luZyBmb3IgZGF0YSBwYWNrZXRzLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ICAg RGVmaW5pdGlvbiBvZiB0aGUgZm9ybWF0KHMpDQo+Pj4+PiAgIHVzZWQgYnkgT0FNIG1ldGFkYXRh IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+Pj4+PiAgIEVORA0KPj4+ Pj4gDQo+Pj4+PiAgIEF0IHRoZSBlbmQgb2YgU2VjdGlvbiAzLjI6DQo+Pj4+PiAgIE9MRA0KPj4+ Pj4gICAgICBUaGlzIGRyYWZ0IGRlZmluZXMgdGhlIGZvbGxvd2luZyBOZXh0IFByb3RvY29sIHZh bHVlczoNCj4+Pj4+IA0KPj4+Pj4gICAgICAweDEgOiBJUHY0DQo+Pj4+PiAgICAgIDB4MiA6IElQ djYNCj4+Pj4+ICAgICAgMHgzIDogRXRoZXJuZXQNCj4+Pj4+ICAgICAgMHg0OiBOU0gNCj4+Pj4+ ICAgICAgMHg1OiBNUExTDQo+Pj4+PiAgICAgIDB4Ni0weEZEOiBVbmFzc2lnbmVkDQo+Pj4+PiAg ICAgIDB4RkUtMHhGRjogRXhwZXJpbWVudGFsDQo+Pj4+PiAgIEVORA0KPj4+Pj4gICBORVcNCj4+ Pj4+ICAgICAgVGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgTmV4dCBQcm90b2NvbCB2 YWx1ZXM6DQo+Pj4+PiANCj4+Pj4+ICAgICAgMHgxIDogSVB2NA0KPj4+Pj4gICAgICAweDIgOiBJ UHY2DQo+Pj4+PiAgICAgIDB4MyA6IEV0aGVybmV0DQo+Pj4+PiAgICAgIDB4NDogTlNIDQo+Pj4+ PiAgICAgIDB4NTogTVBMUw0KPj4+Pj4gICAgICAweDY6IEFjdGl2ZSBPQU0NCj4+Pj4+IA0KPj4+ Pj4gDQo+Pj4+PiBBcyBwZXIgYWJvdmUgSSBkbyBub3QgYmVsaWV2ZSB0aGVyZSdzIGEgc2luZ2xl IE9BTSBwcm90b2NvbC4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAgICAgIDB4Ny0weEZEOiBVbmFz c2lnbmVkDQo+Pj4+PiAgICAgIDB4RkUtMHhGRjogRXhwZXJpbWVudGFsDQo+Pj4+PiAgIEVORA0K Pj4+Pj4gDQo+Pj4+PiAgIEFuZCwgY29uc2VxdWVudGx5LCBzZWN0aW9uIDEzLjIuNSBpbiBJQU5B IENvbnNpZGVyYXRpb25zIHNlY3Rpb24NCj4+Pj4+ICAgd2lsbCByZXF1ZXN0IGFsbG9jYXRpb24g b2YgdmFsdWUgMHg2IHRvIGJlIGFzc2lnbmVkIHRvIEFjdGl2ZSBPQU0NCj4+Pj4+ICAgcHJvdG9j b2xzLg0KPj4+Pj4gDQo+Pj4+PiAgIEdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIGNvbnNpZGVyYXRp b24gYW5kIGNvbW1lbnRzLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gTXkg4oKsMC4w Mi4NCj4+Pj4+IA0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4gDQo+Pj4+PiBDYXJsb3MuDQo+Pj4+PiAN Cj4+Pj4+IA0KPj4+Pj4gICAgICAgICAgICAgICAgICAgUmVnYXJkcywNCj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gICBS dGctb29hbS1kdCBtYWlsaW5nIGxpc3QNCj4+Pj4+ICAgUnRnLW9vYW0tZHRAaWV0Zi5vcmcgPG1h aWx0bzpSdGctb29hbS1kdEBpZXRmLm9yZz4NCj4+Pj4+ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGctb29hbS1kdA0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4g DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+IA0KPj4gDQo+PiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWls aW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQoNCg== From nobody Tue Aug 9 00:25: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 CF38812D0DF; Tue, 9 Aug 2016 00:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sJOmBydpN_e; Tue, 9 Aug 2016 00:25:10 -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 473D512B043; Tue, 9 Aug 2016 00:25:10 -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.294.0; Tue, 9 Aug 2016 03:25:08 -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, 9 Aug 2016 03:25:08 -0400 From: Dave Dolson To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AdHjGxqUb41VTqTfTwmZE/bgRl5mHQA9utSAAAZMKgAAPUPDAAAE5aOAAAoYKYAAAPZ3gAAQJUhAAxWLFAAABhPNLw== Date: Tue, 9 Aug 2016 07:25:06 +0000 Message-ID: <20160809072502.5714003.12271.102144@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> <20160724114359.5714005.75862.99628@sandvine.com>, <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> In-Reply-To: <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "rtg-ooam-dt@ietf.org" , "Joel M. Halpern" , "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: Tue, 09 Aug 2016 07:25:13 -0000 I guess the confusion is that piggyback OAM is not using the OAM bit. Original Message From: Carlos Pignataro (cpignata) Sent: Tuesday, August 9, 2016 1:31 AM To: Dave Dolson Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; sfc@ietf.org Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Hi Dave, With apologies for the much belated response; please find one clarification= inline: > On Jul 24, 2016, at 1:44 PM, Dave Dolson wrote: > > 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 This might be the source of the confusion =97 if O=3D1, that=92s not a data= packet. The idea with piggyback OAM is to disturb the packet the least. If= we flag a data packet as OAM, it takes a completely different processing p= ath. Piggyback OAM is a data packet, O=3D0, with embedded instrumentation, as in= draft-brockners-inband-oam-transport. > 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. Sorry but there seems to be a lot of unnecessary complexity in that. Why an= OAM header? Why a trailer? O=3D1 with IPv4, to me, means an OAM packet in = IPv4 (as for example an ICMPv4 packet, or for example a BFDoUDPoIPv4 packet= . Thanks, =97 Carlos. > > 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 OA= M > 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 wrot= e: >>> >>> There is one situation that folks are asking for that seems not to be c= learly covered in the spec, and appears to me to be clarified by Greg's pro= posal. >>> >>> 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 NS= H-aware service functions to process the user packets. >>> >> >> Just to make sure I understand, you are talking about the case of =93pig= gy-back OAM=94, correct? >> >>> If the only case where we will need this is for service function proces= sing, the putting it in the TLVs, without additional markings, and allowing= the service functions which understand the TLV to work with it seems suffi= cient. >>> >>> But it is not clear to me that there is not a desire (whether it is a r= equirement is probably an important open question) for similar capability a= t 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 b= it to tell the SFF to look at this. >> >> If you set the O bit in a user data packet, how would a system infer tha= t=92s not an OAM packet? >> >> Thanks, >> >> =97 Carlos. >> >>> Efforts with routers to do this with router alert options have been a m= ess. 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 >>>>> > wr= ote: >>>>> >>>>> 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 = be >>>> 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 erro= r >>>>> and the packet dropped? Or you propose that the Next Protocol takes >>>>> precedence and the packet treated as data? Or packet viewed as OAM an= d >>>>> 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 attemp= t >>>>> 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=3D= 1 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 a= s >>>> 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, = 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=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 i= s >>>>> 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 Tue Aug 9 05:03: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 1E27612D7E3; Tue, 9 Aug 2016 05:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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.247, 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 5RkZYJlyc2Fe; Tue, 9 Aug 2016 05:03:09 -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 6D12F12D7A0; Tue, 9 Aug 2016 05:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20860; q=dns/txt; s=iport; t=1470744189; x=1471953789; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8v+UB2H7V0D12wNw3UOOvD5nHwLrC5X1uspiesWbHnY=; b=hi0meZJC2jjlYjK5xR/HXAVT09vuEVYdMq7U+yPNyyUT9rDy+yTLrp0c ugT9ybAKZTm343ieHaMNhgX49qDATaXE6jUXF8Ih4GDdvgaigvAf9xzyu mojcwVkIfFE9Qs4Jc896AQknCnAHWa86X/cjHa7UOPU70YVW1JM7+JRHD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAgCQxalX/5ldJa1dg0VWfAe5HYF9J?= =?us-ascii?q?IV5AhyBLjgUAQEBAQEBAV0nhF4BAQQBAQEhBA0zBwQHBQsCAQgOAwQBAQECAiM?= =?us-ascii?q?DAgICJQsUAQgIAgQOBYgpCA6yFJAgAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBA?= =?us-ascii?q?YUpgXiCVYRXgmorgi8FmTkBiRiFcYFrhFuIfYw0g3cBHjaCEhyBTG6GTn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,494,1464652800"; d="scan'208";a="138533712" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2016 12:03:07 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u79C37j6025413 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 12:03:07 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 Aug 2016 08:03:06 -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; Tue, 9 Aug 2016 08:03:06 -0400 From: "Carlos Pignataro (cpignata)" To: Dave Dolson Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR4/B/s+mJr49HL0uqnvaJ3glSK6AkcOaAgAIHwQCAACcwgIAAUL4AgAAHt4CAAMQ4gIAYaUyAgABzqgCAAE2rgA== Date: Tue, 9 Aug 2016 12:03:06 +0000 Message-ID: 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> In-Reply-To: <20160809072502.5714003.12271.102144@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.150.49.8] Content-Type: text/plain; charset="utf-8" Content-ID: <76FA1311328CE840A21C00813EB98120@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "rtg-ooam-dt@ietf.org" , "Joel M. Halpern" , "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: Tue, 09 Aug 2016 12:03:12 -0000 4oCcUGlnZ3liYWNrIE9BTeKAnSBwaWdneWJhY2tzIG9uIGEgZGF0YSBwYWNrZXQsIG5vdCBhbiBP QU0gcGFja2V0Lg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCj4gT24gQXVnIDksIDIwMTYs IGF0IDM6MjUgQU0sIERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4gd3JvdGU6DQo+ IA0KPiBJIGd1ZXNzIHRoZSBjb25mdXNpb24gaXMgdGhhdCBwaWdneWJhY2sgT0FNIGlzIG5vdCB1 c2luZyB0aGUgT0FNIGJpdC4NCj4gDQo+IA0KPiAgT3JpZ2luYWwgTWVzc2FnZQ0KPiBGcm9tOiBD YXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCj4gU2VudDogVHVlc2RheSwgQXVndXN0IDksIDIw MTYgMTozMSBBTQ0KPiBUbzogRGF2ZSBEb2xzb24NCj4gQ2M6IEpvZWwgTS4gSGFscGVybjsgR3Jl Z29yeSBNaXJza3k7IHJ0Zy1vb2FtLWR0QGlldGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtzZmNdIFtSdGctb29hbS1kdF0gSWRlbnRpZnlpbmcgT0FNIGluIE5TSA0KPiANCj4g DQo+IEhpIERhdmUsDQo+IA0KPiBXaXRoIGFwb2xvZ2llcyBmb3IgdGhlIG11Y2ggYmVsYXRlZCBy ZXNwb25zZTsgcGxlYXNlIGZpbmQgb25lIGNsYXJpZmljYXRpb24gaW5saW5lOg0KPiANCj4+IE9u IEp1bCAyNCwgMjAxNiwgYXQgMTo0NCBQTSwgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUu Y29tPiB3cm90ZToNCj4+IA0KPj4gU2hvdWxkIHRoZSBkb2Mgc2F5LA0KPj4gDQo+PiAgSWYgdGhl IE9BTSBiaXQgTz0wLCB0aGlzIGluZGljYXRlcyB0aGUgU0ZGIE1VU1QgZm9yd2FyZA0KPj4gIHRo ZSBwYWNrZXQgYmFzZWQgc29sZWx5IG9uIHRoZSBTUEkgYW5kIFNJIGZpZWxkcywgd2l0aG91dA0K Pj4gICByZWdhcmQgdG8gbmV4dCBwcm90b2NvbCBvciBmdXJ0aGVyIHBheWxvYWQgaGVhZGVycy4N Cj4+IA0KPj4gIElmIHRoZSBPQU0gYml0IE89MSwgdGhpcyBpbmRpY2F0ZXMgdGhlIFNGRiDigI5N VVNUIE5PVA0KPj4gIHByb2Nlc3MgdGhlIHBhY2tldCBzb2xlbHkgYnkgU1BJL1NJIGZvcndhcmRp bmcgYnV0DQo+PiAgaW5zdGVhZCBieSB0aGUgc2VtYW50aWNzIHNwZWNpZmllZCBieSB0aGUg4oCO T0FNDQo+PiAgcHJvdG9jb2wgbmFtZWQgaW4gdGhlIE5leHQgUHJvdG9jb2wgZmllbGQuDQo+PiAN Cj4+IEkgdGhpbmsgdGhlc2UgcGFyYWdyYXBocyBnZXQgdG8gdGhlIG9wdGltaXphdGlvbiBmb3Ig U0ZGcywNCj4+IGFuZCBJIHRoaW5rIHByb3ZpZGUgcHJlY2lzZSBsYW5ndWFnZSB3aXRob3V0IGRl ZmluaW5nDQo+PiBPQU0gcHJvdG9jb2xzLg0KPj4gDQo+PiDigI5XaXRob3V0IGZ1cnRoZXIgbGFu Z3VhZ2UsIGl0IGlzIG5vdCBzcGVjaWZpZWQgaG93DQo+PiB0byBoYW5kbGUgKmFueSogbmV4dC1w cm90b2NvbCB2YWx1ZXMgd2hlbiBPPTEuDQo+PiANCj4+IEFuZCB3aGVuIHNwZWNpZmllZC4uLg0K Pj4gDQo+PiBBcyBmb3Igc28tY2FsbGVkIHBpZ2d5YmFjayBPQU0sIHdlIGNvdWxkIGRlZmluZQ0K Pj4gdGhhdCBpZiBPPTENCj4gDQo+IFRoaXMgbWlnaHQgYmUgdGhlIHNvdXJjZSBvZiB0aGUgY29u ZnVzaW9uIOKAlCBpZiBPPTEsIHRoYXTigJlzIG5vdCBhIGRhdGEgcGFja2V0LiBUaGUgaWRlYSB3 aXRoIHBpZ2d5YmFjayBPQU0gaXMgdG8gZGlzdHVyYiB0aGUgcGFja2V0IHRoZSBsZWFzdC4gSWYg d2UgZmxhZyBhIGRhdGEgcGFja2V0IGFzIE9BTSwgaXQgdGFrZXMgYSBjb21wbGV0ZWx5IGRpZmZl cmVudCBwcm9jZXNzaW5nIHBhdGguDQo+IA0KPiBQaWdneWJhY2sgT0FNIGlzIGEgZGF0YSBwYWNr ZXQsIE89MCwgd2l0aCBlbWJlZGRlZCBpbnN0cnVtZW50YXRpb24sIGFzIGluIGRyYWZ0LWJyb2Nr bmVycy1pbmJhbmQtb2FtLXRyYW5zcG9ydC4NCj4gDQo+PiBhbmQgTmV4dCBQcm90b2NvbD1JUHY0 IHRoZXJlIG1heSBiZQ0KPj4gYW4gT0FNIGhlYWRlciBmb2xsb3dpbmcgdGhlIElQdjQgcGFja2V0 LA0KPj4gbG9jYXRlZCB1c2luZyBJUHY0IHRvdGFsIGxlbmd0aC7igI4gT3Igd2UgY291bGQNCj4+ IGRlZmluZSBhIG5ldyBudW1iZXIgZm9yIElQdjQtd2l0aC1PQU0tdHJhaWxlci4NCj4gDQo+IFNv cnJ5IGJ1dCB0aGVyZSBzZWVtcyB0byBiZSBhIGxvdCBvZiB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5 IGluIHRoYXQuIFdoeSBhbiBPQU0gaGVhZGVyPyBXaHkgYSB0cmFpbGVyPyBPPTEgd2l0aCBJUHY0 LCB0byBtZSwgbWVhbnMgYW4gT0FNIHBhY2tldCBpbiBJUHY0IChhcyBmb3IgZXhhbXBsZSBhbiBJ Q01QdjQgcGFja2V0LCBvciBmb3IgZXhhbXBsZSBhIEJGRG9VRFBvSVB2NCBwYWNrZXQuDQo+IA0K PiBUaGFua3MsDQo+IA0KPiDigJQgQ2FybG9zLg0KPiANCj4+IA0KPj4gTm90ZSB0aGF0IGZvciBO ZXh0IFByb3RvY29sIG9mIE1QTFMsIEV0aGVybmV0IG9yDQo+PiBOU0gsIHRoZXNlIGRvIG5vdCBo YXZlIHRvdGFsLWxlbmd0aCBmaWVsZHMgdGhhdA0KPj4gd291bGQgYWxsb3cgdHJhaWxpbmcgT0FN Lg0KPj4gDQo+PiBGdXJ0aGVybW9yZSwgd2UgY291bGQgc2F5IHRoYXQgaWYgTz0xLCB0aGUgU0ZG DQo+PiBNVVNUIGRldGVybWluZSBpZiB0aGUgcGF5bG9hZCBpcyBhZGRyZXNzZWQNCj4+IHRvIGl0 LCBlLmcuLCBpZiB0aGUgbmV4dCBJUHY2IHBhY2tldCBpcyBhZGRyZXNzZWQNCj4+IHRvIHRoZSBT RkYncyBsb29wLWJhY2sgYWRkcmVzcy4NCj4+IA0KPj4gSSB0aGluayBtYW55IG9mIHVzIGFyZSBh bnhpb3VzIHRvIGdldCB0byB3b3JrDQo+PiBjbGFyaWZ5aW5nIHRoZXNlIHRoaW5ncy4NCj4+IA0K Pj4gLURhdmUNCj4+IA0KPj4gT3JpZ2luYWwgTWVzc2FnZQ0KPj4gRnJvbTogSm9lbCBNLiBIYWxw ZXJuDQo+PiBTZW50OiBTYXR1cmRheSwgSnVseSAyMywgMjAxNiA4OjAyIFBNDQo+PiBUbzogQ2Fy bG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+PiBDYzogR3JlZ29yeSBNaXJza3k7IHJ0Zy1vb2Ft LWR0QGlldGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBbUnRnLW9v YW0tZHRdIElkZW50aWZ5aW5nIE9BTSBpbiBOU0gNCj4+IA0KPj4gDQo+PiBDYXJsb3MsDQo+PiAg ICBZZXN4LCBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgY2FzZSB0aGF0IG90aGVyIGZvbGtz IGFyZSBjYWxsaW5nDQo+PiBwaWdneS1iYWNrIE9BTS4gIEkgd2FudGVkIHRvIGRlc2NyaWJlIHRo ZSBjYXNlIGluc3RlYWQgb2YgbmFtaW5nIGl0LA0KPj4gYm90aCBmb3IgY2xhcml0eSBhbmQgdG8g cmFpc2UgdGhlIHBvaW50IGFib3V0IHdobyBuZWVkcyB0byBwcm9jZXNzIHRoZQ0KPj4gT0FNIGlu Zm9ybWF0aW9uLg0KPj4gDQo+PiBZb3UgYXNrIGhvdyB0aGUgU0YgKG9yIGV2ZW4gaWYgdGhlIFNG RiBpZiB0aGF0IGFwcGxpZXNfIHdpbGwga25vdyB0aGVyZQ0KPj4gaXMgYSB1c2VyIHBhY2tldC4g IEkgdGhpbmsgdGhlIHByb3Bvc2FsIGlzIHRvIHVzZSB0aGUgT0FNIGJpdA0KPj4gc3BlY2lmaWNh bGx5IHRvIGluZGljYXRlIHRoYXQuDQo+PiBUaGUgcmVzdWx0IG9mIHRoYXQgdXNhZ2UgaXMgdGhh dCB0aGUgU0ZGIG5lZWRzIHRvIGNoZWNrIHRoZSBwYWNrZXQgdHlwZQ0KPj4gaW4gb3JkZXIgdG8g cmVjb2duaXplIE9BTSBwYWNrZXRzIHRoYXQgYXJlIG5vdCB1c2VyIGRhdGEgcGFja2V0cyBhbmQN Cj4+IHRoYXQgaXQgbmVlZHMgdG8gcHJvY2Vzcy4NCj4+IFRoYXQgaXMgYW4gdW5mb3J0dW5hdGUg Y29tcGxleGl0eSBpbiBhIGNyaXRpY2FsIHByb2Nlc3NpbmcgcGF0aC4NCj4+IA0KPj4gSSBzdXNw ZWN0IGl0IGlzIHRoaXMgZWZmaWNpZW5jeSB0aGF0IGlzIGRyaXZpbmcgeW91Lg0KPj4gV2hpY2gg c3VnZ2VzdHMgYW5vdGhlciBwb3NzaWJsZSBpbnRlcnByZXRhdGlvbi4NCj4+IFdoYXQgaWYNCj4+ IDEpIHdlIHNldCB0aGUgT0FNIGJpdCBmb3IgYW55IHBhY2tldCB0aGF0IG5lZWRzIE9BTSBwcm9j ZXNzaW5nDQo+PiAyKSBBbmQgZGVmaW5lIGEgKHNldCBvZikgcGFja2V0IHR5cGVzIGZvciBwYWNr ZXRzIHdoZXJlIHRoZSBjb3RuZW50IGlzIE9BTQ0KPj4gMykgQW5kIGRlY2xhcmUgdGhhdCBhbnkg b3RoZXIgcGFja2V0IHR5cGVzIGFyZSB1c2VyIHBhY2tldHMgd2l0aCBPQU0gVExWDQo+PiBpbmZv cm1hdGlvbi4NCj4+IA0KPj4gVGhpcyBpcyBzbGlnaHRseSBzaW1wbGVyIGlmIHdlIGRlY2xhcmUg YSBzaW5nbGUgT0FNIHBhY2tldCB0eXBlIGluIHRoZQ0KPj4gTlNIIGhlYWRlciwgYXMgdGhhdCBh dm9pZHMgYW55IGFtYmlndWl0eS4gIChXaGV0aGVyIHRoZSBkZXZpY2UgY2FuDQo+PiBhY3R1YWxs eSBkbyB0aGUgT0FNIHN0aWxsIGRlcGVuZHMgdXBvbiBpdCB1bmRlcnN0YW5kaW5nIHRoZSBPQU0g cGFja2V0cywNCj4+IGJ1dCB0aGF0IGlzIHRydWUgb2YgYWxsIHN0cnVjdHVyZXMuKSAgVGhpcyBk b2VzIGF2b2lkIGNyZWF0aW5nIGFueQ0KPj4gY29uZnVzaW9uIGJldHdlZW4gdGhlIHVzZSBvZiB0 aGUgT0FNIGZsYWcgYW5kIHRoZSBwYWNrZXQgdHlwZS4NCj4+IA0KPj4gWW91cnMsDQo+PiBKb2Vs DQo+PiANCj4+IE9uIDcvMjMvMTYgNzozNCBQTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp IHdyb3RlOg0KPj4+IEhpLCBKb2VsLA0KPj4+IA0KPj4+PiBPbiBKdWwgMjMsIDIwMTYsIGF0IDc6 NDUgUE0sIEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4+ IA0KPj4+PiBUaGVyZSBpcyBvbmUgc2l0dWF0aW9uIHRoYXQgZm9sa3MgYXJlIGFza2luZyBmb3Ig dGhhdCBzZWVtcyBub3QgdG8gYmUgY2xlYXJseSBjb3ZlcmVkIGluIHRoZSBzcGVjLCBhbmQgYXBw ZWFycyB0byBtZSB0byBiZSBjbGFyaWZpZWQgYnkgR3JlZydzIHByb3Bvc2FsLg0KPj4+PiANCj4+ Pj4gV2UgaGF2ZSBoYWQgYSBjb3VwbGUgb2YgcmVxdWVzdHMgZm9yIHRoZSBhYmlsaXR5IHRvIHB1 dCBPQU0gbWFya2luZyBvbiB1c2VyIGRhdGEgcGFja2V0cy4gIFRoZSBtb3N0IG9idmlvdXMgdXNl IGlzIHRvIG1vbml0b3IgaG93IGxvbmcgaXQgdGFrZXMgTlNILWF3YXJlIHNlcnZpY2UgZnVuY3Rp b25zIHRvIHByb2Nlc3MgdGhlIHVzZXIgcGFja2V0cy4NCj4+Pj4gDQo+Pj4gDQo+Pj4gSnVzdCB0 byBtYWtlIHN1cmUgSSB1bmRlcnN0YW5kLCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGNhc2Ug b2Yg4oCccGlnZ3ktYmFjayBPQU3igJ0sIGNvcnJlY3Q/DQo+Pj4gDQo+Pj4+IElmIHRoZSBvbmx5 IGNhc2Ugd2hlcmUgd2Ugd2lsbCBuZWVkIHRoaXMgaXMgZm9yIHNlcnZpY2UgZnVuY3Rpb24gcHJv Y2Vzc2luZywgdGhlIHB1dHRpbmcgaXQgaW4gdGhlIFRMVnMsIHdpdGhvdXQgYWRkaXRpb25hbCBt YXJraW5ncywgYW5kIGFsbG93aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB3aGljaCB1bmRlcnN0 YW5kIHRoZSBUTFYgdG8gd29yayB3aXRoIGl0IHNlZW1zIHN1ZmZpY2llbnQuDQo+Pj4+IA0KPj4+ PiBCdXQgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMgbm90IGEgZGVzaXJlICh3 aGV0aGVyIGl0IGlzIGEgcmVxdWlyZW1lbnQgaXMgcHJvYmFibHkgYW4gaW1wb3J0YW50IG9wZW4g cXVlc3Rpb24pIGZvciBzaW1pbGFyIGNhcGFiaWxpdHkgYXQgU0ZGLiAgSWYgd2UgaGF2ZSBzaXR1 YXRpb25zIHdoZXJlIFNGRiwgaW4gcGFzc2luZyB1c2VyIGRhdGEgcGFja2V0cywgYWxzbyBuZWVk IHRvIHBlcmZvcm0gT0FNIG9wZXJhdGlvbnMsIHRoZW4gaXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBu ZWVkIHRoZSBPQU0gYml0IHRvIHRlbGwgdGhlIFNGRiB0byBsb29rIGF0IHRoaXMuDQo+Pj4gDQo+ Pj4gSWYgeW91IHNldCB0aGUgTyBiaXQgaW4gYSB1c2VyIGRhdGEgcGFja2V0LCBob3cgd291bGQg YSBzeXN0ZW0gaW5mZXIgdGhhdOKAmXMgbm90IGFuIE9BTSBwYWNrZXQ/DQo+Pj4gDQo+Pj4gVGhh bmtzLA0KPj4+IA0KPj4+IOKAlCBDYXJsb3MuDQo+Pj4gDQo+Pj4+IEVmZm9ydHMgd2l0aCByb3V0 ZXJzIHRvIGRvIHRoaXMgd2l0aCByb3V0ZXIgYWxlcnQgb3B0aW9ucyBoYXZlIGJlZW4gYSBtZXNz LiBJZiB3ZSBuZWVkIHRoZSBjYXBhYmlsaXR5LCBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIHJlYWxs eSB3YW50IGl0IGluIGEgc3RhbmRhcmRpemVkIGFuZCBlZmZpY2llbnQgcGxhY2UuDQo+Pj4+IElm IHdlIGFyZSB2ZXJ5IHN1cmUgd2UgZG9uJ3QgbmVlZCB0aGlzLCB0aGVuIHdlIHNob3VsZCB3cml0 ZSB0aGF0IGRvd24sIGFuZCBtb3ZlIG9uLg0KPj4+PiANCj4+Pj4gWW91cnMsDQo+Pj4+IEpvZWwN Cj4+Pj4gDQo+Pj4+IE9uIDcvMjMvMTYgMTI6MjQgUE0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKSB3cm90ZToNCj4+Pj4+IEhpLCBHcmVnLA0KPj4+Pj4gDQo+Pj4+Pj4gT24gSnVsIDIyLCAy MDE2LCBhdCAxMDoyNCBBTSwgR3JlZ29yeSBNaXJza3kNCj4+Pj4+PiA8Z3JlZ29yeS5taXJza3lA ZXJpY3Nzb24uY29tIDxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6 DQo+Pj4+Pj4gDQo+Pj4+Pj4gSGkgQ2FybG9zLA0KPj4+Pj4+IHRoYW5rIHlvdSBmb3Igc2hhcmlu ZyB5b3VyIGNvbW1lbnRzLiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB5b3UNCj4+Pj4+PiBz dWdnZXN0IHRvIGV4cG9zZSBwcm90b2NvbCB0eXBlcyBvZiBPQU0gYXMgTmV4dCBQcm90b2NvbCBy YXRoZXIgdGhhbg0KPj4+Pj4+IHRvIHVzZSBzaW5nbGUgQWN0aXZlIE9BTSBwcm90b2NvbCB0eXBl IGFuZCB1c2UgT09BTSBIZWFkZXIgdG8gZGVtdXgNCj4+Pj4+PiBPT0FNIHR5cGUuIFRoZW4sIHRo ZSBOZXh0IFByb3RvY29sIHJlZ2lzdHJ5IHdpbGwgaGF2ZSB0byBhbGxvY2F0ZQ0KPj4+Pj4+IHZh bHVlcyBmb3Igc2luZ2xlLWhvcCBCRkQsIG11bHRpLWhvcCBCRkQsIG11bHRpcG9pbnQgQkZELCBT LUJGRCwgRWNobw0KPj4+Pj4+IFJlcXVlc3QvUmVwbHksIEFJUyBwcm90b2NvbCwgQWN0aXZlIFBl cmZvcm1hbmNlIE1lYXN1cmVtZW50IHByb3RvY29sLA0KPj4+Pj4+IGFuZCBJ4oCZdmUgb25seSBs aXN0ZWQgc29tZSBvZiBBT00gcHJvdG9jb2xzIHRoYXQgbWF5IGJlIHVzZWQgdG8NCj4+Pj4+PiBv cGVyYXRlLCBhZG1pbmlzdGVyIGFuZCBtYWludGFpbiBTRlAuDQo+Pj4+PiANCj4+Pj4+IFllcywg dGhlIHByb3RvY29sIGZpZWxkIG91Z2h0IHRvIHJlZ2lzdGVyIHRoZSBPQU0gcHJvdG9jb2xzIHRo YXQgd2lsbCBiZQ0KPj4+Pj4gdXNlZCBhbmQgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkIOKAlCBv ZiBjb3Vyc2Ugbm90IGFsbCBwb3RlbnRpYWwNCj4+Pj4+IHZhcmlhdGlvbnMgYW5kIHBlcm11dGF0 aW9ucyBvZiBwb3NzaWJsZSBPQU1zICh3aGF0IGlzIEFJUyBwcm90b2NvbD8pDQo+Pj4+PiANCj4+ Pj4+PiBBZGRpdGlvbmFsbHksIHlvdeKAmXZlIHN1Z2dlc3RlZCB0aGF0IG9ubHkgTy1iaXQgdmFs dWUgdG8gYmUgdXNlZCB0bw0KPj4+Pj4+IGRldGVybWluZSB3aGV0aGVyIHBhY2tldCBzaG91bGQg YmUgcHJvY2Vzc2VkIGFzIE9BTSBvciBkYXRhIHBhY2tldC4NCj4+Pj4+PiBIZW5jZSBzaG91bGQg SSBleHBlY3QgdGhhdCBPLWJpdCBpcyBzZXQgZm9yIEJGRCwgQUlTLCBhbmQgRWNobw0KPj4+Pj4+ IFJlcXVlc3QvUmVwbHkgcGF5bG9hZCBhbmQgc2hvdWxkIG5vdCBiZSBzZXQgaWYgdGhlIE5leHQg UHJvdG9jb2wgaXMNCj4+Pj4+PiBuZWl0aGVyIG9mIHByb3RvY29scyBsaXN0ZWQgYWJvdmU/IFNo b3VsZCBzdWNoIHNpdHVhdGlvbiwgaS5lLiBOZXh0DQo+Pj4+Pj4gUHJvdG9jb2wgdmFsdWUgaXMg TVBMUyBhbmQgTy1iaXQgc2V0IHRvIDB4MSwgc2hvdWxkIGJlIHZpZXdlZCBhcyBlcnJvcg0KPj4+ Pj4+IGFuZCB0aGUgcGFja2V0IGRyb3BwZWQ/IE9yIHlvdSBwcm9wb3NlIHRoYXQgdGhlIE5leHQg UHJvdG9jb2wgdGFrZXMNCj4+Pj4+PiBwcmVjZWRlbmNlIGFuZCB0aGUgcGFja2V0IHRyZWF0ZWQg YXMgZGF0YT8gT3IgcGFja2V0IHZpZXdlZCBhcyBPQU0gYW5kDQo+Pj4+Pj4gcGFzc2VkIHRvIHRo ZSBsb2NhbCBPQU0gZW50aXR5PyBPciBob3cgdG8gaW50ZXJwcmV0IHNpdHVhdGlvbiB3aGVuDQo+ Pj4+Pj4gTy1iaXQgaXMgY2xlYXJlZCBhbmQgdGhlIE5leHQgUHJvdG9jb2wgdmFsdWUgaXMgb25l IG9mIE9BTSBwcm90b2NvbHM/DQo+Pj4+Pj4gVGhpcyBpcyB0aGUgc2l0dWF0aW9uIHRoYXQsIGlu IG15IHZpZXcsIGlzIGFtYmlndW91cyBhbmQNCj4+Pj4+PiB1bmRlci1zcGVjaWZpZWQgaW4gdGhl IGN1cnJlbnQgTlNIIGRvY3VtZW50LiBNeSBwcm9wb3NhbCBpcyBhbiBhdHRlbXB0DQo+Pj4+Pj4g dG8gbWFrZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBPQU0gYW5kIGRhdGEgcGFja2V0cyBtb3JlIGRl dGVybWluaXN0aWMuDQo+Pj4+PiANCj4+Pj4+IEFuc3dlcmluZyBhbGwgdGhvc2UgcXVlc3Rpb25z ICh3aGljaCBhcmUgcmVhbGx5IHNsaWdodCBwZXJtdXRhdGlvbnMgb2YNCj4+Pj4+IHRoZSBzYW1l IHF1ZXN0aW9uKSBpbiBvbmUgc2hvdDogdG8gbWUsIE89MCBpcyBhIGRhdGEgcGFja2V0IGFuZCBP PTEgaXMNCj4+Pj4+IGFuIE9BTSBwYWNrZXQuIElmIHRoZSBkYXRhIHByb2Nlc3NpbmcgZG9lcyBu b3QgaGF2ZSBhIGhhbmRsZXIgZm9yIHRoZQ0KPj4+Pj4gcHJvdG9jb2wgaW4gdGhlIFBJRCwgb3Ig aXTigJlzIGFuIHVuZGVmaW5lZCwgZHJvcHMgdG8gdGhlIGJpdCBidWNrZXQuDQo+Pj4+PiBFcXVh bGx5LCBpZiB0aGUgT0FNIGhhbmRsZXIgZG9lcyBub3Qgc3VwcG9ydCB0aGUgcHJvdG9jb2wgSUQg Y2FycmllZCBhcw0KPj4+Pj4gT0FNLCBwdWZmLiBJUCBjYW4gY2FycnkgZGF0YSBvciBPQU0gZm9y IGV4YW1wbGUgYnkgdGhlIHdheS4NCj4+Pj4+IA0KPj4+Pj4gSXQgZG9lcyBub3QgZ2V0IGFueSBz aW1wbGVyIGFuZCB1bmFtYmlndW91cyB0aGFuIHRoYXQuIFdoYXTigJlzIHRoZQ0KPj4+Pj4gYWR2 YW50YWdlIG9mIG1vdmluZyB0aGUgT0FNIFBJRCBmdXJ0aGVyIGluc2lkZT8NCj4+Pj4+IA0KPj4+ Pj4gQW5kIEkgZG8gbm90IGJlbGlldmUgdGhlcmXigJlzIHVuZGVyc3BlY2lmaWNhdGlvbiBpbiBO U0ggLT4gTz0xLCBPQU0NCj4+Pj4+IHRyZWF0bWVudCwgbm90IGRldGFpbGVkIGhlcmUuDQo+Pj4+ PiANCj4+Pj4+IFRoYW5rcywNCj4+Pj4+IA0KPj4+Pj4g4oCUIENhcmxvcy4NCj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+ICAgICAgICAgICAgICBSZWdhcmRzLA0KPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgR3JlZw0KPj4+Pj4+IA0KPj4+Pj4+ICpGcm9tOiogQ2FybG9zIFBpZ25h dGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KPj4+Pj4+ICpTZW50 OiogRnJpZGF5LCBKdWx5IDIyLCAyMDE2IDEwOjEwIEFNDQo+Pj4+Pj4gKlRvOiogR3JlZ29yeSBN aXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbQ0KPj4+Pj4+IDxtYWlsdG86Z3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tPj4NCj4+Pj4+PiAqQ2M6KiBzZmNAaWV0Zi5vcmcgPG1haWx0 bzpzZmNAaWV0Zi5vcmc+OyBydGctb29hbS1kdEBpZXRmLm9yZw0KPj4+Pj4+IDxtYWlsdG86cnRn LW9vYW0tZHRAaWV0Zi5vcmc+DQo+Pj4+Pj4gKlN1YmplY3Q6KiBSZTogW1J0Zy1vb2FtLWR0XSBJ ZGVudGlmeWluZyBPQU0gaW4gTlNIDQo+Pj4+Pj4gDQo+Pj4+Pj4gR3JlZywNCj4+Pj4+PiANCj4+ Pj4+PiANCj4+Pj4+PiBQbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGlubGluZS4NCj4+Pj4+PiAN Cj4+Pj4+PiBUaHVtYiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0YXJvLg0KPj4+Pj4+IEV4Y3V6ZSB0 eXBvZnJhcGhpY2FrIGVycm93cw0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IE9uIEp1bCAyMSwg MjAxNiwgYXQgMDk6MDEsIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b20NCj4+Pj4+PiA8bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K Pj4+Pj4+IA0KPj4+Pj4+ICBEZWFyIEFsbCwNCj4+Pj4+PiAgd2UgaGFkIHZlcnkgZ29vZCBkaXNj dXNzaW9uIG9uIE9BTSB0aGlzIHdlZWsuIFdl4oCZdmUgdG91Y2hlZCBvbg0KPj4+Pj4+ICBBY3Rp dmUsIFBhc3NpdmUgYW5kIFNvbWV0aGluZy1pbi1iZXR3ZWVuIE9BTS4gQnV0IGNhbiBOU0ggaW5k aWNhdGUNCj4+Pj4+PiAgd2hpY2ggT0FNIHR5cGUsIGlmIGFueSwgYXNzb2NpYXRlZCB3aXRoIGEg cGFja2V0PyBJIHRoaW5rIHRoYXQgdGhlDQo+Pj4+Pj4gIGN1cnJlbnQgdmVyc2lvbiBvZiBkcmFm dC1pZXRmLXNmYy1uc2ggZG9lcyBub3QgYWxsb3cgdGhhdCBhbmQgbWF5DQo+Pj4+Pj4gIGJlIGFt YmlndW91cyBpbiBzb21lIGNhc2VzLiBJIHByb3Bvc2UgY2hhbmdlIHRvIGludGVycHJldGF0aW9u IGFuZA0KPj4+Pj4+ICBhcHBsaWNhYmlsaXR5IGRlc2NyaXB0aW9uIG9mIHRoZSBPKEFNKSBmbGFn IGFuZCBhbGxvY2F0aW9uIG9mIHRoZQ0KPj4+Pj4+ICBuZXcgcHJvdG9jb2wgdHlwZSB0byBiZSB1 c2VkIGluIHRoZSBOZXh0IFByb3RvY29sIGZpZWxkLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+ IA0KPj4+Pj4+IEFjdGl2ZSwgcGFzc2l2ZSBhbmQgc29tZXRoaW5nLWluLWJldHdlZW4gYXJlIG5v dCBPQU0gcHJvdG9jb2wgdHlwZXMNCj4+Pj4+PiBidXQgcmF0aGVyIHRoZXkgYXJlIG1lYXN1cmlu ZyBtZXRob2RzLiBBY3RpdmUgT0FNIGNhbiBpbmNsdWRlIGENCj4+Pj4+PiBwbHVyYWxpdHkgb2Yg T0FNIHByb3RvY29scywgaW5jbHVkaW5nIEJGRCwgUy1CRkQsIHNvbWV0aGluZy1vdmVyLWlwLCBl dGMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gSSBhbHNvIGJlbGlldmUgdGhhdCB0aGUgY3VycmVudCBPQU0g dGV4dCBpbiBOU0ggaXMgbm90IGFtYmlndW91cyBhbmQNCj4+Pj4+PiBhbGxvd3MgZW5vdWdoIHBy b2Nlc3Npbmcgb2YgdGhlIGhlYWRlciB0byB1bmRlcnN0YW5kIHNvbWV0aGluZyBpcyBPQU0sDQo+ Pj4+Pj4gd2l0aG91dCBnb2luZyB0aGUgc3BlY2lmaWNzIG9mIGFuIE9BTSBoYW5kbGVyLg0KPj4+ Pj4+IA0KPj4+Pj4+IFRoZXJlZm9yZSwgSSBvcHBvc2UgdGhpcyBjaGFuZ2UuDQo+Pj4+Pj4gDQo+ Pj4+Pj4gDQo+Pj4+Pj4gIFJGQyA3Nzk5IGRlZmluZXMgQWN0aXZlIE9BTSBhcyBmb2xsb3dpbmc6 DQo+Pj4+Pj4gIEFuIEFjdGl2ZSBNZXRyaWMgb3IgTWV0aG9kIGRlcGVuZHMgb24gYSBkZWRpY2F0 ZWQgbWVhc3VyZW1lbnQNCj4+Pj4+PiAgcGFja2V0IHN0cmVhbSBhbmQgb2JzZXJ2YXRpb25zIG9m IHRoZSBzdHJlYW0uDQo+Pj4+Pj4gIFRodXMsIHJlZ2FyZGxlc3Mgb2YgZW5jYXBzdWxhdGlvbiB1 c2VkIGJ5IE9BTSwgaXQgaXMgdGhlIHBhY2tldA0KPj4+Pj4+ICBjb25zdHJ1Y3RlZCBzb2xlbHkg Zm9yIG1vbml0b3JpbmcsIG1lYXN1cmluZyBuZXR3b3Jr4oCZcyBtZXRyaWMgYW5kDQo+Pj4+Pj4g IHNob3VsZCBub3QgbGVhdmUgZ2l2ZW4gZG9tYWluLiBBbmQsIEkgYmVsaWV2ZSwgc3VjaCBwYWNr ZXRzIHNob3VsZA0KPj4+Pj4+ICBiZSBpZGVudGlmaWVkIGJ5IHRoZSBwcm90b2NvbCB0eXBlIG9m IHRoZWlyIG93bi4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBTZWVtcyB5b3UgYXJlIGFkdm9j YXRpbmcgZm9yIGEgc2luZ2xlICJPQU0iIHByb3RvY29sIHR5cGUgZm9yIE9BTQ0KPj4+Pj4+IHBh Y2tldHMuIFRoZSBmdW5jdGlvbmFsaXR5IG9mIGlkZW50aWZ5aW5nIHNvbWV0aGluZyBhcyBPQU0g aXMgaW4gdGhlDQo+Pj4+Pj4gTy1iaXQsIHNvIG5vIG5lZWQgdG8gd2FzdGUgYml0cyBpbiBkdXBs aWNhdGlvbi4NCj4+Pj4+PiANCj4+Pj4+PiBUaGVuLCBhdCBzb21lIHBvaW50LCB5b3UgaGF2ZSB0 byBkaWZmZXJlbnRpYXRlIGlmIGFuIE9BTSBpcywgc2F5LCBJUA0KPj4+Pj4+IG9yICJyYXcgQkZE IiBvciBzb21ldGhpbmcgZWxzZS4gVGhhdCdzIHdoYXQgdGhlIFByb3RvY29sIGZpZWxkIGlzIGZv ci4NCj4+Pj4+PiBJIGRvIG5vdCBzZWUgYSBuZWVkIHRvIGFkZCBhbiBpbmRpcmVjdGlvbiBoZXJl IHRvIHRoZW4gaGF2ZSB0byBoYXZlIGENCj4+Pj4+PiBwcm90b2NvbCBmaWVsZCBpbnNpZGUgdGhl IE9BTS4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiAgT0FNIHdoaWNoIGJlaGF2ZXMgYXMgbXVj aCBhcyBQYXNzaXZlIE9BTSBvciBTb21ldGhpbmctaW4tYmV0d2VlbiwNCj4+Pj4+PiAgZS5nLiBP QU0gYXBwZW5kZWQgdG8gZGF0YSBwYWNrZXQgZWl0aGVyIGF0IHRoZSBkb21haW7igJlzIGVkZ2Ug b3INCj4+Pj4+PiAgb24tdGhlLWZseSwgaWRlbnRpZmllZCBieSB0aGUgcHJvdG9jb2wgdHlwZSBv ZiB0aGUgZGF0YSBwYWNrZXQNCj4+Pj4+PiAgY2FycmllZCBpbiBOU0guDQo+Pj4+Pj4gDQo+Pj4+ Pj4gDQo+Pj4+Pj4gVGhhdCdzIGNvcnJlY3QsIHdpdGggdGhlIE8gYml0IGNsZWFyZWQ7IGl0J3Mg YSBkYXRhIHBhY2tldCBhbmQgbm90IGFuDQo+Pj4+Pj4gT0FNIG9uZS4NCj4+Pj4+PiANCj4+Pj4+ PiANCj4+Pj4+PiAgQmVsb3cgYXJlIGNoYW5nZXMgSeKAmWQgbGlrZSB0byBwcm9wb3NlOg0KPj4+ Pj4+ICBTZWN0aW9uIDMuMiBPLWJpdDoNCj4+Pj4+PiAgT0xEDQo+Pj4+Pj4gICAgIE8gYml0OiB3 aGVuIHNldCB0byAweDEgaW5kaWNhdGVzIHRoYXQgdGhpcyBwYWNrZXQgaXMgYW4gT3BlcmF0aW9u cywNCj4+Pj4+PiAgICAgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50ZW5hbmNlIChPQU0pIG1lc3Nh Z2UuICBUaGUgcmVjZWl2aW5nDQo+Pj4+Pj4gIFNGRiBhbmQNCj4+Pj4+PiAgICAgU0ZzIG5vZGVz IE1VU1QgZXhhbWluZSB0aGUgcGF5bG9hZCBhbmQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24NCj4+ Pj4+PiAgKGUuZy4NCj4+Pj4+PiAgICAgcmV0dXJuIHN0YXR1cyBpbmZvcm1hdGlvbikuICBPQU0g bWVzc2FnZSBzcGVjaWZpY3MgYW5kIGhhbmRsaW5nDQo+Pj4+Pj4gICAgIGRldGFpbHMgYXJlIG91 dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+Pj4+Pj4gIEVORA0KPj4+Pj4+ICBO RVcNCj4+Pj4+PiAgTyBiaXQ6IHdoZW4gc2V0IHRvIDB4MSBpbmRpY2F0ZXMgdGhhdCBkYXRhIHBh Y2tldCBpZGVudGlmaWVkIGJ5DQo+Pj4+Pj4gIHRoZSBOZXh0DQo+Pj4+Pj4gIFByb3RvY29sIHR5 cGUgaGFzIE9BTSBtZXRhZGF0YSBhcHBlbmRlZC4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBO by4gSWYgaXQgaXMgYSBkYXRhIHBhY2tldCBpdCBkb2VzIG5vdCBoYXZlIHRoZSBPIGJpdCBzZXQg KHRvIDEgb3IgdG8NCj4+Pj4+PiB3aGljaGV2ZXIgb3RoZXIgcG9zc2libGUgdmFsdWUgZm9yIHRo ZSBiaXQgOi0pDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlIGdvYWwgaXMgdGhhdCBsb29raW5nIGF0IGEg c2luZ2xlIGJ1dCBpdCBjYW4gYmUgdW5kZXJzdG9vZCBpZiBpdCBpcw0KPj4+Pj4+IGEgZGF0YSBw YWNrZXQgKHdoaWNoIGNhbiBiZSB1c2VkLCBtYXJrZWQsIGV0Yy4gdG8gYmUgdXNlZCBmb3IgT0FN DQo+Pj4+Pj4gcHVycG9zZXMsIG9yIG5vdCkuDQo+Pj4+Pj4gDQo+Pj4+Pj4gV2UgZG8gbm90IHdh bnQgT0FNIGRpcmVjdCBleGNlcHRpb24gcHJvY2Vzc2luZyBmb3IgZGF0YSBwYWNrZXRzLg0KPj4+ Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+ICBEZWZpbml0aW9uIG9mIHRoZSBmb3JtYXQocykNCj4+Pj4+ PiAgdXNlZCBieSBPQU0gbWV0YWRhdGEgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC4NCj4+Pj4+PiAgRU5EDQo+Pj4+Pj4gDQo+Pj4+Pj4gIEF0IHRoZSBlbmQgb2YgU2VjdGlv biAzLjI6DQo+Pj4+Pj4gIE9MRA0KPj4+Pj4+ICAgICBUaGlzIGRyYWZ0IGRlZmluZXMgdGhlIGZv bGxvd2luZyBOZXh0IFByb3RvY29sIHZhbHVlczoNCj4+Pj4+PiANCj4+Pj4+PiAgICAgMHgxIDog SVB2NA0KPj4+Pj4+ICAgICAweDIgOiBJUHY2DQo+Pj4+Pj4gICAgIDB4MyA6IEV0aGVybmV0DQo+ Pj4+Pj4gICAgIDB4NDogTlNIDQo+Pj4+Pj4gICAgIDB4NTogTVBMUw0KPj4+Pj4+ICAgICAweDYt MHhGRDogVW5hc3NpZ25lZA0KPj4+Pj4+ICAgICAweEZFLTB4RkY6IEV4cGVyaW1lbnRhbA0KPj4+ Pj4+ICBFTkQNCj4+Pj4+PiAgTkVXDQo+Pj4+Pj4gICAgIFRoaXMgZHJhZnQgZGVmaW5lcyB0aGUg Zm9sbG93aW5nIE5leHQgUHJvdG9jb2wgdmFsdWVzOg0KPj4+Pj4+IA0KPj4+Pj4+ICAgICAweDEg OiBJUHY0DQo+Pj4+Pj4gICAgIDB4MiA6IElQdjYNCj4+Pj4+PiAgICAgMHgzIDogRXRoZXJuZXQN Cj4+Pj4+PiAgICAgMHg0OiBOU0gNCj4+Pj4+PiAgICAgMHg1OiBNUExTDQo+Pj4+Pj4gICAgIDB4 NjogQWN0aXZlIE9BTQ0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IEFzIHBlciBhYm92ZSBJIGRv IG5vdCBiZWxpZXZlIHRoZXJlJ3MgYSBzaW5nbGUgT0FNIHByb3RvY29sLg0KPj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+ICAgICAweDctMHhGRDogVW5hc3NpZ25lZA0KPj4+Pj4+ICAgICAweEZFLTB4 RkY6IEV4cGVyaW1lbnRhbA0KPj4+Pj4+ICBFTkQNCj4+Pj4+PiANCj4+Pj4+PiAgQW5kLCBjb25z ZXF1ZW50bHksIHNlY3Rpb24gMTMuMi41IGluIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbg0K Pj4+Pj4+ICB3aWxsIHJlcXVlc3QgYWxsb2NhdGlvbiBvZiB2YWx1ZSAweDYgdG8gYmUgYXNzaWdu ZWQgdG8gQWN0aXZlIE9BTQ0KPj4+Pj4+ICBwcm90b2NvbHMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gIEdy ZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIGNvbnNpZGVyYXRpb24gYW5kIGNvbW1lbnRzLg0KPj4+Pj4+ IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IE15IOKCrDAuMDIuDQo+Pj4+Pj4gDQo+Pj4+Pj4g VGhhbmtzLA0KPj4+Pj4+IA0KPj4+Pj4+IENhcmxvcy4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+ PiAgICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgR3JlZw0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+ICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ICBSdGctb29hbS1kdCBt YWlsaW5nIGxpc3QNCj4+Pj4+PiAgUnRnLW9vYW0tZHRAaWV0Zi5vcmcgPG1haWx0bzpSdGctb29h bS1kdEBpZXRmLm9yZz4NCj4+Pj4+PiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGctb29hbS1kdA0KPj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHNm YyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+IA0KPj4+IA0KPj4+IA0KPj4gDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1h aWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPiANCg0K From nobody Tue Aug 9 06:29: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 3EA7212D0B2; Tue, 9 Aug 2016 06:29:04 -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 XkbCKtcQ19mF; Tue, 9 Aug 2016 06:29:01 -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 B5B0212D095; Tue, 9 Aug 2016 06:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 98E37280090; Tue, 9 Aug 2016 06:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470749341; bh=OA7muyIVCFDGQ8dYzeW7RMZefdfTkmvp6iQFhurixgQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cSL2uCMlbjuVG49EjN2Xh9jczOUr7AG/5PeO+B169R+MsLmy6s4f4GIsVRfELkIsg qLIkoxDnE9FFFiZAT7+rBz2LKYEOjPnJhoFtDjKQpoBCXCh36fO15et+Qb0hhAILWx 3Rosh/irVijFK4WMuvbB5KvCgfq9YQHtODavsWdE= 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 A52CF1C0541; Tue, 9 Aug 2016 06:29:00 -0700 (PDT) To: "Carlos Pignataro (cpignata)" , Dave Dolson 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 9 Aug 2016 09:30: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: Content-Type: text/plain; charset=utf-8; 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: Tue, 09 Aug 2016 13:29:04 -0000 I would normally be inclined to agree with your definition Carlos. However, if there can be "Piggyback OAM" that has to be processed by SFF, then we have to make that efficient for the SFF to detect (since it has to check every packet for this case. Note that the meaning of the OAM bit is whatever we say it is. One definition is "the carried packet is an OAM packet." But we could also define it more similarly to the router alert bit as in "this packet needs special checking at each SFF and SF." Yours, Joel On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: > “Piggyback OAM” piggybacks on a data packet, not an OAM packet. > > Thanks, > > — Carlos. > >> On Aug 9, 2016, at 3:25 AM, Dave Dolson wrote: >> >> I guess the confusion is that piggyback OAM is not using the OAM bit. >> >> >> Original Message >> From: Carlos Pignataro (cpignata) >> Sent: Tuesday, August 9, 2016 1:31 AM >> To: Dave Dolson >> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; sfc@ietf.org >> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >> >> >> Hi Dave, >> >> With apologies for the much belated response; please find one clarification inline: >> >>> On Jul 24, 2016, at 1:44 PM, Dave Dolson wrote: >>> >>> Should the doc say, >>> >>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT >>> process the packet solely by SPI/SI forwarding but >>> instead by the semantics specified by the ‎OAM >>> 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. >>> >>> ‎Without further language, it is not specified how >>> to handle *any* next-protocol values when O=1. >>> >>> And when specified... >>> >>> As for so-called piggyback OAM, we could define >>> that if O=1 >> >> This might be the source of the confusion — if O=1, that’s not a data packet. The idea with piggyback OAM is to disturb the packet the least. If we flag a data packet as OAM, it takes a completely different processing path. >> >> Piggyback OAM is a data packet, O=0, with embedded instrumentation, as in draft-brockners-inband-oam-transport. >> >>> and Next Protocol=IPv4 there may be >>> an OAM header following the IPv4 packet, >>> located using IPv4 total length.‎ Or we could >>> define a new number for IPv4-with-OAM-trailer. >> >> Sorry but there seems to be a lot of unnecessary complexity in that. Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an OAM packet in IPv4 (as for example an ICMPv4 packet, or for example a BFDoUDPoIPv4 packet. >> >> Thanks, >> >> — Carlos. >> >>> >>> 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=1, 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 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 >>>>>> >>>> >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> > From nobody Tue Aug 9 06: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 0BD9912D845 for ; Tue, 9 Aug 2016 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7FZEEbSJ_8e for ; Tue, 9 Aug 2016 06:36:41 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A73412D86B for ; Tue, 9 Aug 2016 06:36:34 -0700 (PDT) Received: from [192.168.0.2] (c213-89-108-172.bredband.comhem.se [213.89.108.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CBA5318013E2 for ; Tue, 9 Aug 2016 15:36:32 +0200 (CEST) To: sfc@ietf.org 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> From: Loa Andersson Message-ID: <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> Date: Tue, 9 Aug 2016 15:36:27 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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: Tue, 09 Aug 2016 13:36:45 -0000 Folks, Maybe a naive question. On 2016-08-09 15:30, Joel M. Halpern wrote: > I would normally be inclined to agree with your definition Carlos. > However, if there can be "Piggyback OAM" that has to be processed by > SFF, then we have to make that efficient for the SFF to detect (since it > has to check every packet for this case. > > Note that the meaning of the OAM bit is whatever we say it is. > One definition is "the carried packet is an OAM packet." But we could > also define it more similarly to the router alert bit as in "this packet > needs special checking at each SFF and SF." During the discussions on MPLS OAM we had as a rule of thumb, that the route and processing of OAM packets need to be the same as for payload packet. If we postulate "needs special checking at each SFF and SF" are we abandoning this for SFC? /Loa > > Yours, > Joel > > On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: >> “Piggyback OAM” piggybacks on a data packet, not an OAM packet. >> >> Thanks, >> >> — Carlos. >> >>> On Aug 9, 2016, at 3:25 AM, Dave Dolson wrote: >>> >>> I guess the confusion is that piggyback OAM is not using the OAM bit. >>> >>> >>> Original Message >>> From: Carlos Pignataro (cpignata) >>> Sent: Tuesday, August 9, 2016 1:31 AM >>> To: Dave Dolson >>> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; sfc@ietf.org >>> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >>> >>> >>> Hi Dave, >>> >>> With apologies for the much belated response; please find one >>> clarification inline: >>> >>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson wrote: >>>> >>>> Should the doc say, >>>> >>>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT >>>> process the packet solely by SPI/SI forwarding but >>>> instead by the semantics specified by the ‎OAM >>>> 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. >>>> >>>> ‎Without further language, it is not specified how >>>> to handle *any* next-protocol values when O=1. >>>> >>>> And when specified... >>>> >>>> As for so-called piggyback OAM, we could define >>>> that if O=1 >>> >>> This might be the source of the confusion — if O=1, that’s not a data >>> packet. The idea with piggyback OAM is to disturb the packet the >>> least. If we flag a data packet as OAM, it takes a completely >>> different processing path. >>> >>> Piggyback OAM is a data packet, O=0, with embedded instrumentation, >>> as in draft-brockners-inband-oam-transport. >>> >>>> and Next Protocol=IPv4 there may be >>>> an OAM header following the IPv4 packet, >>>> located using IPv4 total length.‎ Or we could >>>> define a new number for IPv4-with-OAM-trailer. >>> >>> Sorry but there seems to be a lot of unnecessary complexity in that. >>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an OAM >>> packet in IPv4 (as for example an ICMPv4 packet, or for example a >>> BFDoUDPoIPv4 packet. >>> >>> Thanks, >>> >>> — Carlos. >>> >>>> >>>> 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=1, 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 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 >>>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Aug 9 06:40: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 BA4F612D876; Tue, 9 Aug 2016 06:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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.247, 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 fVjiyWlPQ9Y6; Tue, 9 Aug 2016 06:40:49 -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 528F712D87C; Tue, 9 Aug 2016 06:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23458; q=dns/txt; s=iport; t=1470750046; x=1471959646; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LuH26nUrg51A8N2XLsZLc/ci87KyiMDeKX6ztxQ/RMg=; b=QZkLDiPwQOQAzfBXGiPaSm9CSDc3ERx8iK5DXDLfQNEZW8MRjCcDLsbp 2JIWF6gD5PbmA5c/TpFUgvucx9XQyXwQrg6bnynTehFGrfmbBpBUl6H4F RJMZ3ADfHnc/Hl0PWmQ4u9eM3LfECLPyBofAdLlUE4z5m24B+G1vjf6mj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAgAk3KlX/4oNJK1dg0VWfAe5HYF9J?= =?us-ascii?q?IV5AhyBMTgUAQEBAQEBAV0nhF4BAQQBAQEhBA0zBwQHBQsCAQgRBAEBAQICIwM?= =?us-ascii?q?CAgIlCxQBCAgCBA4FiCkIDrF1kCABAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBh?= =?us-ascii?q?SmBeAiCTYQRRoJqK4IvBZN1hUQBiRiFcYFrhFuIfYw0g3cBHjaCEhyBTG6GTn8?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.28,494,1464652800"; d="scan'208";a="135758408" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Aug 2016 13:40:44 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u79DeiTp031017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 13:40:44 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; Tue, 9 Aug 2016 09:40:43 -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; Tue, 9 Aug 2016 09:40:43 -0400 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR4/B/s+mJr49HL0uqnvaJ3glSK6AkcOaAgAIHwQCAACcwgIAAUL4AgAAHt4CAAMQ4gIAYaUyAgABzqgCAAE2rgIAAGHyAgAACy4A= Date: Tue, 9 Aug 2016 13:40:43 +0000 Message-ID: <5150831E-1328-4451-B65E-3298F422D31D@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> <83EF1E06-D242-4FE6-8C7A-B00AE858557B@cisco.com> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.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.150.49.8] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "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: Tue, 09 Aug 2016 13:40:52 -0000 Sm9lbCwNCg0KPiBPbiBBdWcgOSwgMjAxNiwgYXQgOTozMCBBTSwgSm9lbCBNLiBIYWxwZXJuIDxq bWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4gDQo+IEkgd291bGQgbm9ybWFsbHkgYmUgaW5j bGluZWQgdG8gYWdyZWUgd2l0aCB5b3VyIGRlZmluaXRpb24gQ2FybG9zLg0KPiBIb3dldmVyLCBp ZiB0aGVyZSBjYW4gYmUgIlBpZ2d5YmFjayBPQU0iIHRoYXQgaGFzIHRvIGJlIHByb2Nlc3NlZCBi eSBTRkYsIHRoZW4gd2UgaGF2ZSB0byBtYWtlIHRoYXQgZWZmaWNpZW50IGZvciB0aGUgU0ZGIHRv IGRldGVjdCAoc2luY2UgaXQgaGFzIHRvIGNoZWNrIGV2ZXJ5IHBhY2tldCBmb3IgdGhpcyBjYXNl Lg0KPiANCj4gTm90ZSB0aGF0IHRoZSBtZWFuaW5nIG9mIHRoZSBPQU0gYml0IGlzIHdoYXRldmVy IHdlIHNheSBpdCBpcy4NCj4gT25lIGRlZmluaXRpb24gaXMgInRoZSBjYXJyaWVkIHBhY2tldCBp cyBhbiBPQU0gcGFja2V0LiIgIEJ1dCB3ZSBjb3VsZCBhbHNvIGRlZmluZSBpdCBtb3JlIHNpbWls YXJseSB0byB0aGUgcm91dGVyIGFsZXJ0IGJpdCBhcyBpbiAidGhpcyBwYWNrZXQgbmVlZHMgc3Bl Y2lhbCBjaGVja2luZyBhdCBlYWNoIFNGRiBhbmQgU0Yu4oCdDQo+IA0KDQpJbmRlZWQsIGl0IGlz IGZvciB1cyB0byBkZWZpbmUuIA0KDQpUaGVyZeKAmXMgYW4gaW1wb3J0YW50IGNvcm9sbGFyeSBp biBkZWZpbmluZyBhbiDigJxpbnNwZWN0IGNsb3NlbHnigJ0gLyBSQU8tbGlrZSBiaXQsIHdoaWNo IGlzIHRoYXQgaXQgd2lsbCBhZmZlY3QgcHJvY2Vzc2luZyBhbmQgcHVudCB0byBhIGRpZmZlcmVu dCBwYXRoLCBlcXVhbGx5IGZvciDigJxhY3RpdmUgT0FN4oCdIHRoYW4gdG8g4oCccGlnZ3kgYmFj ayBPQU3igJ0uDQoNClBlcnNvbmFsbHksIEnigJlkIGZlZWwgbW9yZSBmdXR1cmUtc2FmZSBpcyB3 ZSBkbyBub3QgY29uZmxhdGUgYm90aCBhcHByb2FjaGVzIG9uIHRoZSBzYW1lIGJpdCwgYXMgdGhl cmUgYXJlIG90aGVyIG9wdGlvbnMgZm9yIGludGVyY2VwdGluZyBpT0FNIHBvdGVudGlhbGx5LCBh bmQga2VlcCBhbiBPIGJpdCB0byBtZWFuIOKAnE9BTSBwYWNrZXQsIE9BTS1wcm9jZXNzIGl04oCd Lg0KDQpEbyB5b3Ugc2VlIGRyYXdiYWNrcyB3aXRoIHRoYXQ/DQoNClRoYW5rcywNCg0KQ2FybG9z Lg0KDQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBPbiA4LzkvMTYgODowMyBBTSwgQ2FybG9zIFBp Z25hdGFybyAoY3BpZ25hdGEpIHdyb3RlOg0KPj4g4oCcUGlnZ3liYWNrIE9BTeKAnSBwaWdneWJh Y2tzIG9uIGEgZGF0YSBwYWNrZXQsIG5vdCBhbiBPQU0gcGFja2V0Lg0KPj4gDQo+PiBUaGFua3Ms DQo+PiANCj4+IOKAlCBDYXJsb3MuDQo+PiANCj4+PiBPbiBBdWcgOSwgMjAxNiwgYXQgMzoyNSBB TSwgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPiB3cm90ZToNCj4+PiANCj4+PiBJ IGd1ZXNzIHRoZSBjb25mdXNpb24gaXMgdGhhdCBwaWdneWJhY2sgT0FNIGlzIG5vdCB1c2luZyB0 aGUgT0FNIGJpdC4NCj4+PiANCj4+PiANCj4+PiBPcmlnaW5hbCBNZXNzYWdlDQo+Pj4gRnJvbTog Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+Pj4gU2VudDogVHVlc2RheSwgQXVndXN0IDks IDIwMTYgMTozMSBBTQ0KPj4+IFRvOiBEYXZlIERvbHNvbg0KPj4+IENjOiBKb2VsIE0uIEhhbHBl cm47IEdyZWdvcnkgTWlyc2t5OyBydGctb29hbS1kdEBpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+ Pj4gU3ViamVjdDogUmU6IFtzZmNdIFtSdGctb29hbS1kdF0gSWRlbnRpZnlpbmcgT0FNIGluIE5T SA0KPj4+IA0KPj4+IA0KPj4+IEhpIERhdmUsDQo+Pj4gDQo+Pj4gV2l0aCBhcG9sb2dpZXMgZm9y IHRoZSBtdWNoIGJlbGF0ZWQgcmVzcG9uc2U7IHBsZWFzZSBmaW5kIG9uZSBjbGFyaWZpY2F0aW9u IGlubGluZToNCj4+PiANCj4+Pj4gT24gSnVsIDI0LCAyMDE2LCBhdCAxOjQ0IFBNLCBEYXZlIERv bHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gU2hvdWxkIHRo ZSBkb2Mgc2F5LA0KPj4+PiANCj4+Pj4gSWYgdGhlIE9BTSBiaXQgTz0wLCB0aGlzIGluZGljYXRl cyB0aGUgU0ZGIE1VU1QgZm9yd2FyZA0KPj4+PiB0aGUgcGFja2V0IGJhc2VkIHNvbGVseSBvbiB0 aGUgU1BJIGFuZCBTSSBmaWVsZHMsIHdpdGhvdXQNCj4+Pj4gIHJlZ2FyZCB0byBuZXh0IHByb3Rv Y29sIG9yIGZ1cnRoZXIgcGF5bG9hZCBoZWFkZXJzLg0KPj4+PiANCj4+Pj4gSWYgdGhlIE9BTSBi aXQgTz0xLCB0aGlzIGluZGljYXRlcyB0aGUgU0ZGIOKAjk1VU1QgTk9UDQo+Pj4+IHByb2Nlc3Mg dGhlIHBhY2tldCBzb2xlbHkgYnkgU1BJL1NJIGZvcndhcmRpbmcgYnV0DQo+Pj4+IGluc3RlYWQg YnkgdGhlIHNlbWFudGljcyBzcGVjaWZpZWQgYnkgdGhlIOKAjk9BTQ0KPj4+PiBwcm90b2NvbCBu YW1lZCBpbiB0aGUgTmV4dCBQcm90b2NvbCBmaWVsZC4NCj4+Pj4gDQo+Pj4+IEkgdGhpbmsgdGhl c2UgcGFyYWdyYXBocyBnZXQgdG8gdGhlIG9wdGltaXphdGlvbiBmb3IgU0ZGcywNCj4+Pj4gYW5k IEkgdGhpbmsgcHJvdmlkZSBwcmVjaXNlIGxhbmd1YWdlIHdpdGhvdXQgZGVmaW5pbmcNCj4+Pj4g T0FNIHByb3RvY29scy4NCj4+Pj4gDQo+Pj4+IOKAjldpdGhvdXQgZnVydGhlciBsYW5ndWFnZSwg aXQgaXMgbm90IHNwZWNpZmllZCBob3cNCj4+Pj4gdG8gaGFuZGxlICphbnkqIG5leHQtcHJvdG9j b2wgdmFsdWVzIHdoZW4gTz0xLg0KPj4+PiANCj4+Pj4gQW5kIHdoZW4gc3BlY2lmaWVkLi4uDQo+ Pj4+IA0KPj4+PiBBcyBmb3Igc28tY2FsbGVkIHBpZ2d5YmFjayBPQU0sIHdlIGNvdWxkIGRlZmlu ZQ0KPj4+PiB0aGF0IGlmIE89MQ0KPj4+IA0KPj4+IFRoaXMgbWlnaHQgYmUgdGhlIHNvdXJjZSBv ZiB0aGUgY29uZnVzaW9uIOKAlCBpZiBPPTEsIHRoYXTigJlzIG5vdCBhIGRhdGEgcGFja2V0LiBU aGUgaWRlYSB3aXRoIHBpZ2d5YmFjayBPQU0gaXMgdG8gZGlzdHVyYiB0aGUgcGFja2V0IHRoZSBs ZWFzdC4gSWYgd2UgZmxhZyBhIGRhdGEgcGFja2V0IGFzIE9BTSwgaXQgdGFrZXMgYSBjb21wbGV0 ZWx5IGRpZmZlcmVudCBwcm9jZXNzaW5nIHBhdGguDQo+Pj4gDQo+Pj4gUGlnZ3liYWNrIE9BTSBp cyBhIGRhdGEgcGFja2V0LCBPPTAsIHdpdGggZW1iZWRkZWQgaW5zdHJ1bWVudGF0aW9uLCBhcyBp biBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS10cmFuc3BvcnQuDQo+Pj4gDQo+Pj4+IGFuZCBO ZXh0IFByb3RvY29sPUlQdjQgdGhlcmUgbWF5IGJlDQo+Pj4+IGFuIE9BTSBoZWFkZXIgZm9sbG93 aW5nIHRoZSBJUHY0IHBhY2tldCwNCj4+Pj4gbG9jYXRlZCB1c2luZyBJUHY0IHRvdGFsIGxlbmd0 aC7igI4gT3Igd2UgY291bGQNCj4+Pj4gZGVmaW5lIGEgbmV3IG51bWJlciBmb3IgSVB2NC13aXRo LU9BTS10cmFpbGVyLg0KPj4+IA0KPj4+IFNvcnJ5IGJ1dCB0aGVyZSBzZWVtcyB0byBiZSBhIGxv dCBvZiB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5IGluIHRoYXQuIFdoeSBhbiBPQU0gaGVhZGVyPyBX aHkgYSB0cmFpbGVyPyBPPTEgd2l0aCBJUHY0LCB0byBtZSwgbWVhbnMgYW4gT0FNIHBhY2tldCBp biBJUHY0IChhcyBmb3IgZXhhbXBsZSBhbiBJQ01QdjQgcGFja2V0LCBvciBmb3IgZXhhbXBsZSBh IEJGRG9VRFBvSVB2NCBwYWNrZXQuDQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IA0KPj4+IOKAlCBD YXJsb3MuDQo+Pj4gDQo+Pj4+IA0KPj4+PiBOb3RlIHRoYXQgZm9yIE5leHQgUHJvdG9jb2wgb2Yg TVBMUywgRXRoZXJuZXQgb3INCj4+Pj4gTlNILCB0aGVzZSBkbyBub3QgaGF2ZSB0b3RhbC1sZW5n dGggZmllbGRzIHRoYXQNCj4+Pj4gd291bGQgYWxsb3cgdHJhaWxpbmcgT0FNLg0KPj4+PiANCj4+ Pj4gRnVydGhlcm1vcmUsIHdlIGNvdWxkIHNheSB0aGF0IGlmIE89MSwgdGhlIFNGRg0KPj4+PiBN VVNUIGRldGVybWluZSBpZiB0aGUgcGF5bG9hZCBpcyBhZGRyZXNzZWQNCj4+Pj4gdG8gaXQsIGUu Zy4sIGlmIHRoZSBuZXh0IElQdjYgcGFja2V0IGlzIGFkZHJlc3NlZA0KPj4+PiB0byB0aGUgU0ZG J3MgbG9vcC1iYWNrIGFkZHJlc3MuDQo+Pj4+IA0KPj4+PiBJIHRoaW5rIG1hbnkgb2YgdXMgYXJl IGFueGlvdXMgdG8gZ2V0IHRvIHdvcmsNCj4+Pj4gY2xhcmlmeWluZyB0aGVzZSB0aGluZ3MuDQo+ Pj4+IA0KPj4+PiAtRGF2ZQ0KPj4+PiANCj4+Pj4gT3JpZ2luYWwgTWVzc2FnZQ0KPj4+PiBGcm9t OiBKb2VsIE0uIEhhbHBlcm4NCj4+Pj4gU2VudDogU2F0dXJkYXksIEp1bHkgMjMsIDIwMTYgODow MiBQTQ0KPj4+PiBUbzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+Pj4+IENjOiBHcmVn b3J5IE1pcnNreTsgcnRnLW9vYW0tZHRAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPj4+PiBTdWJq ZWN0OiBSZTogW3NmY10gW1J0Zy1vb2FtLWR0XSBJZGVudGlmeWluZyBPQU0gaW4gTlNIDQo+Pj4+ IA0KPj4+PiANCj4+Pj4gQ2FybG9zLA0KPj4+PiAgIFllc3gsIEkgYW0gdGFsa2luZyBhYm91dCB0 aGUgc2FtZSBjYXNlIHRoYXQgb3RoZXIgZm9sa3MgYXJlIGNhbGxpbmcNCj4+Pj4gcGlnZ3ktYmFj ayBPQU0uICBJIHdhbnRlZCB0byBkZXNjcmliZSB0aGUgY2FzZSBpbnN0ZWFkIG9mIG5hbWluZyBp dCwNCj4+Pj4gYm90aCBmb3IgY2xhcml0eSBhbmQgdG8gcmFpc2UgdGhlIHBvaW50IGFib3V0IHdo byBuZWVkcyB0byBwcm9jZXNzIHRoZQ0KPj4+PiBPQU0gaW5mb3JtYXRpb24uDQo+Pj4+IA0KPj4+ PiBZb3UgYXNrIGhvdyB0aGUgU0YgKG9yIGV2ZW4gaWYgdGhlIFNGRiBpZiB0aGF0IGFwcGxpZXNf IHdpbGwga25vdyB0aGVyZQ0KPj4+PiBpcyBhIHVzZXIgcGFja2V0LiAgSSB0aGluayB0aGUgcHJv cG9zYWwgaXMgdG8gdXNlIHRoZSBPQU0gYml0DQo+Pj4+IHNwZWNpZmljYWxseSB0byBpbmRpY2F0 ZSB0aGF0Lg0KPj4+PiBUaGUgcmVzdWx0IG9mIHRoYXQgdXNhZ2UgaXMgdGhhdCB0aGUgU0ZGIG5l ZWRzIHRvIGNoZWNrIHRoZSBwYWNrZXQgdHlwZQ0KPj4+PiBpbiBvcmRlciB0byByZWNvZ25pemUg T0FNIHBhY2tldHMgdGhhdCBhcmUgbm90IHVzZXIgZGF0YSBwYWNrZXRzIGFuZA0KPj4+PiB0aGF0 IGl0IG5lZWRzIHRvIHByb2Nlc3MuDQo+Pj4+IFRoYXQgaXMgYW4gdW5mb3J0dW5hdGUgY29tcGxl eGl0eSBpbiBhIGNyaXRpY2FsIHByb2Nlc3NpbmcgcGF0aC4NCj4+Pj4gDQo+Pj4+IEkgc3VzcGVj dCBpdCBpcyB0aGlzIGVmZmljaWVuY3kgdGhhdCBpcyBkcml2aW5nIHlvdS4NCj4+Pj4gV2hpY2gg c3VnZ2VzdHMgYW5vdGhlciBwb3NzaWJsZSBpbnRlcnByZXRhdGlvbi4NCj4+Pj4gV2hhdCBpZg0K Pj4+PiAxKSB3ZSBzZXQgdGhlIE9BTSBiaXQgZm9yIGFueSBwYWNrZXQgdGhhdCBuZWVkcyBPQU0g cHJvY2Vzc2luZw0KPj4+PiAyKSBBbmQgZGVmaW5lIGEgKHNldCBvZikgcGFja2V0IHR5cGVzIGZv ciBwYWNrZXRzIHdoZXJlIHRoZSBjb3RuZW50IGlzIE9BTQ0KPj4+PiAzKSBBbmQgZGVjbGFyZSB0 aGF0IGFueSBvdGhlciBwYWNrZXQgdHlwZXMgYXJlIHVzZXIgcGFja2V0cyB3aXRoIE9BTSBUTFYN Cj4+Pj4gaW5mb3JtYXRpb24uDQo+Pj4+IA0KPj4+PiBUaGlzIGlzIHNsaWdodGx5IHNpbXBsZXIg aWYgd2UgZGVjbGFyZSBhIHNpbmdsZSBPQU0gcGFja2V0IHR5cGUgaW4gdGhlDQo+Pj4+IE5TSCBo ZWFkZXIsIGFzIHRoYXQgYXZvaWRzIGFueSBhbWJpZ3VpdHkuICAoV2hldGhlciB0aGUgZGV2aWNl IGNhbg0KPj4+PiBhY3R1YWxseSBkbyB0aGUgT0FNIHN0aWxsIGRlcGVuZHMgdXBvbiBpdCB1bmRl cnN0YW5kaW5nIHRoZSBPQU0gcGFja2V0cywNCj4+Pj4gYnV0IHRoYXQgaXMgdHJ1ZSBvZiBhbGwg c3RydWN0dXJlcy4pICBUaGlzIGRvZXMgYXZvaWQgY3JlYXRpbmcgYW55DQo+Pj4+IGNvbmZ1c2lv biBiZXR3ZWVuIHRoZSB1c2Ugb2YgdGhlIE9BTSBmbGFnIGFuZCB0aGUgcGFja2V0IHR5cGUuDQo+ Pj4+IA0KPj4+PiBZb3VycywNCj4+Pj4gSm9lbA0KPj4+PiANCj4+Pj4gT24gNy8yMy8xNiA3OjM0 IFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQo+Pj4+PiBIaSwgSm9lbCwN Cj4+Pj4+IA0KPj4+Pj4+IE9uIEp1bCAyMywgMjAxNiwgYXQgNzo0NSBQTSwgSm9lbCBNLiBIYWxw ZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBUaGVyZSBp cyBvbmUgc2l0dWF0aW9uIHRoYXQgZm9sa3MgYXJlIGFza2luZyBmb3IgdGhhdCBzZWVtcyBub3Qg dG8gYmUgY2xlYXJseSBjb3ZlcmVkIGluIHRoZSBzcGVjLCBhbmQgYXBwZWFycyB0byBtZSB0byBi ZSBjbGFyaWZpZWQgYnkgR3JlZydzIHByb3Bvc2FsLg0KPj4+Pj4+IA0KPj4+Pj4+IFdlIGhhdmUg aGFkIGEgY291cGxlIG9mIHJlcXVlc3RzIGZvciB0aGUgYWJpbGl0eSB0byBwdXQgT0FNIG1hcmtp bmcgb24gdXNlciBkYXRhIHBhY2tldHMuICBUaGUgbW9zdCBvYnZpb3VzIHVzZSBpcyB0byBtb25p dG9yIGhvdyBsb25nIGl0IHRha2VzIE5TSC1hd2FyZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0byBwcm9j ZXNzIHRoZSB1c2VyIHBhY2tldHMuDQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEp1c3QgdG8gbWFr ZSBzdXJlIEkgdW5kZXJzdGFuZCwgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBjYXNlIG9mIOKA nHBpZ2d5LWJhY2sgT0FN4oCdLCBjb3JyZWN0Pw0KPj4+Pj4gDQo+Pj4+Pj4gSWYgdGhlIG9ubHkg Y2FzZSB3aGVyZSB3ZSB3aWxsIG5lZWQgdGhpcyBpcyBmb3Igc2VydmljZSBmdW5jdGlvbiBwcm9j ZXNzaW5nLCB0aGUgcHV0dGluZyBpdCBpbiB0aGUgVExWcywgd2l0aG91dCBhZGRpdGlvbmFsIG1h cmtpbmdzLCBhbmQgYWxsb3dpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHdoaWNoIHVuZGVyc3Rh bmQgdGhlIFRMViB0byB3b3JrIHdpdGggaXQgc2VlbXMgc3VmZmljaWVudC4NCj4+Pj4+PiANCj4+ Pj4+PiBCdXQgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMgbm90IGEgZGVzaXJl ICh3aGV0aGVyIGl0IGlzIGEgcmVxdWlyZW1lbnQgaXMgcHJvYmFibHkgYW4gaW1wb3J0YW50IG9w ZW4gcXVlc3Rpb24pIGZvciBzaW1pbGFyIGNhcGFiaWxpdHkgYXQgU0ZGLiAgSWYgd2UgaGF2ZSBz aXR1YXRpb25zIHdoZXJlIFNGRiwgaW4gcGFzc2luZyB1c2VyIGRhdGEgcGFja2V0cywgYWxzbyBu ZWVkIHRvIHBlcmZvcm0gT0FNIG9wZXJhdGlvbnMsIHRoZW4gaXQgc2VlbXMgdG8gbWUgdGhhdCB3 ZSBuZWVkIHRoZSBPQU0gYml0IHRvIHRlbGwgdGhlIFNGRiB0byBsb29rIGF0IHRoaXMuDQo+Pj4+ PiANCj4+Pj4+IElmIHlvdSBzZXQgdGhlIE8gYml0IGluIGEgdXNlciBkYXRhIHBhY2tldCwgaG93 IHdvdWxkIGEgc3lzdGVtIGluZmVyIHRoYXTigJlzIG5vdCBhbiBPQU0gcGFja2V0Pw0KPj4+Pj4g DQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiANCj4+Pj4+IOKAlCBDYXJsb3MuDQo+Pj4+PiANCj4+Pj4+ PiBFZmZvcnRzIHdpdGggcm91dGVycyB0byBkbyB0aGlzIHdpdGggcm91dGVyIGFsZXJ0IG9wdGlv bnMgaGF2ZSBiZWVuIGEgbWVzcy4gSWYgd2UgbmVlZCB0aGUgY2FwYWJpbGl0eSwgaXQgc2VlbXMg dG8gbWUgdGhhdCB3ZSByZWFsbHkgd2FudCBpdCBpbiBhIHN0YW5kYXJkaXplZCBhbmQgZWZmaWNp ZW50IHBsYWNlLg0KPj4+Pj4+IElmIHdlIGFyZSB2ZXJ5IHN1cmUgd2UgZG9uJ3QgbmVlZCB0aGlz LCB0aGVuIHdlIHNob3VsZCB3cml0ZSB0aGF0IGRvd24sIGFuZCBtb3ZlIG9uLg0KPj4+Pj4+IA0K Pj4+Pj4+IFlvdXJzLA0KPj4+Pj4+IEpvZWwNCj4+Pj4+PiANCj4+Pj4+PiBPbiA3LzIzLzE2IDEy OjI0IFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQo+Pj4+Pj4+IEhpLCBH cmVnLA0KPj4+Pj4+PiANCj4+Pj4+Pj4+IE9uIEp1bCAyMiwgMjAxNiwgYXQgMTA6MjQgQU0sIEdy ZWdvcnkgTWlyc2t5DQo+Pj4+Pj4+PiA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIDxtYWls dG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IEhpIENhcmxvcywNCj4+Pj4+Pj4+IHRoYW5rIHlvdSBmb3Igc2hhcmluZyB5b3VyIGNvbW1l bnRzLiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB5b3UNCj4+Pj4+Pj4+IHN1Z2dlc3QgdG8g ZXhwb3NlIHByb3RvY29sIHR5cGVzIG9mIE9BTSBhcyBOZXh0IFByb3RvY29sIHJhdGhlciB0aGFu DQo+Pj4+Pj4+PiB0byB1c2Ugc2luZ2xlIEFjdGl2ZSBPQU0gcHJvdG9jb2wgdHlwZSBhbmQgdXNl IE9PQU0gSGVhZGVyIHRvIGRlbXV4DQo+Pj4+Pj4+PiBPT0FNIHR5cGUuIFRoZW4sIHRoZSBOZXh0 IFByb3RvY29sIHJlZ2lzdHJ5IHdpbGwgaGF2ZSB0byBhbGxvY2F0ZQ0KPj4+Pj4+Pj4gdmFsdWVz IGZvciBzaW5nbGUtaG9wIEJGRCwgbXVsdGktaG9wIEJGRCwgbXVsdGlwb2ludCBCRkQsIFMtQkZE LCBFY2hvDQo+Pj4+Pj4+PiBSZXF1ZXN0L1JlcGx5LCBBSVMgcHJvdG9jb2wsIEFjdGl2ZSBQZXJm b3JtYW5jZSBNZWFzdXJlbWVudCBwcm90b2NvbCwNCj4+Pj4+Pj4+IGFuZCBJ4oCZdmUgb25seSBs aXN0ZWQgc29tZSBvZiBBT00gcHJvdG9jb2xzIHRoYXQgbWF5IGJlIHVzZWQgdG8NCj4+Pj4+Pj4+ IG9wZXJhdGUsIGFkbWluaXN0ZXIgYW5kIG1haW50YWluIFNGUC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IFllcywgdGhlIHByb3RvY29sIGZpZWxkIG91Z2h0IHRvIHJlZ2lzdGVyIHRoZSBPQU0gcHJvdG9j b2xzIHRoYXQgd2lsbCBiZQ0KPj4+Pj4+PiB1c2VkIGFuZCBpbXBsZW1lbnRlZCBhbmQgZGVwbG95 ZWQg4oCUIG9mIGNvdXJzZSBub3QgYWxsIHBvdGVudGlhbA0KPj4+Pj4+PiB2YXJpYXRpb25zIGFu ZCBwZXJtdXRhdGlvbnMgb2YgcG9zc2libGUgT0FNcyAod2hhdCBpcyBBSVMgcHJvdG9jb2w/KQ0K Pj4+Pj4+PiANCj4+Pj4+Pj4+IEFkZGl0aW9uYWxseSwgeW914oCZdmUgc3VnZ2VzdGVkIHRoYXQg b25seSBPLWJpdCB2YWx1ZSB0byBiZSB1c2VkIHRvDQo+Pj4+Pj4+PiBkZXRlcm1pbmUgd2hldGhl ciBwYWNrZXQgc2hvdWxkIGJlIHByb2Nlc3NlZCBhcyBPQU0gb3IgZGF0YSBwYWNrZXQuDQo+Pj4+ Pj4+PiBIZW5jZSBzaG91bGQgSSBleHBlY3QgdGhhdCBPLWJpdCBpcyBzZXQgZm9yIEJGRCwgQUlT LCBhbmQgRWNobw0KPj4+Pj4+Pj4gUmVxdWVzdC9SZXBseSBwYXlsb2FkIGFuZCBzaG91bGQgbm90 IGJlIHNldCBpZiB0aGUgTmV4dCBQcm90b2NvbCBpcw0KPj4+Pj4+Pj4gbmVpdGhlciBvZiBwcm90 b2NvbHMgbGlzdGVkIGFib3ZlPyBTaG91bGQgc3VjaCBzaXR1YXRpb24sIGkuZS4gTmV4dA0KPj4+ Pj4+Pj4gUHJvdG9jb2wgdmFsdWUgaXMgTVBMUyBhbmQgTy1iaXQgc2V0IHRvIDB4MSwgc2hvdWxk IGJlIHZpZXdlZCBhcyBlcnJvcg0KPj4+Pj4+Pj4gYW5kIHRoZSBwYWNrZXQgZHJvcHBlZD8gT3Ig eW91IHByb3Bvc2UgdGhhdCB0aGUgTmV4dCBQcm90b2NvbCB0YWtlcw0KPj4+Pj4+Pj4gcHJlY2Vk ZW5jZSBhbmQgdGhlIHBhY2tldCB0cmVhdGVkIGFzIGRhdGE/IE9yIHBhY2tldCB2aWV3ZWQgYXMg T0FNIGFuZA0KPj4+Pj4+Pj4gcGFzc2VkIHRvIHRoZSBsb2NhbCBPQU0gZW50aXR5PyBPciBob3cg dG8gaW50ZXJwcmV0IHNpdHVhdGlvbiB3aGVuDQo+Pj4+Pj4+PiBPLWJpdCBpcyBjbGVhcmVkIGFu ZCB0aGUgTmV4dCBQcm90b2NvbCB2YWx1ZSBpcyBvbmUgb2YgT0FNIHByb3RvY29scz8NCj4+Pj4+ Pj4+IFRoaXMgaXMgdGhlIHNpdHVhdGlvbiB0aGF0LCBpbiBteSB2aWV3LCBpcyBhbWJpZ3VvdXMg YW5kDQo+Pj4+Pj4+PiB1bmRlci1zcGVjaWZpZWQgaW4gdGhlIGN1cnJlbnQgTlNIIGRvY3VtZW50 LiBNeSBwcm9wb3NhbCBpcyBhbiBhdHRlbXB0DQo+Pj4+Pj4+PiB0byBtYWtlIHJlbGF0aW9uc2hp cCBiZXR3ZWVuIE9BTSBhbmQgZGF0YSBwYWNrZXRzIG1vcmUgZGV0ZXJtaW5pc3RpYy4NCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IEFuc3dlcmluZyBhbGwgdGhvc2UgcXVlc3Rpb25zICh3aGljaCBhcmUgcmVh bGx5IHNsaWdodCBwZXJtdXRhdGlvbnMgb2YNCj4+Pj4+Pj4gdGhlIHNhbWUgcXVlc3Rpb24pIGlu IG9uZSBzaG90OiB0byBtZSwgTz0wIGlzIGEgZGF0YSBwYWNrZXQgYW5kIE89MSBpcw0KPj4+Pj4+ PiBhbiBPQU0gcGFja2V0LiBJZiB0aGUgZGF0YSBwcm9jZXNzaW5nIGRvZXMgbm90IGhhdmUgYSBo YW5kbGVyIGZvciB0aGUNCj4+Pj4+Pj4gcHJvdG9jb2wgaW4gdGhlIFBJRCwgb3IgaXTigJlzIGFu IHVuZGVmaW5lZCwgZHJvcHMgdG8gdGhlIGJpdCBidWNrZXQuDQo+Pj4+Pj4+IEVxdWFsbHksIGlm IHRoZSBPQU0gaGFuZGxlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBwcm90b2NvbCBJRCBjYXJyaWVk IGFzDQo+Pj4+Pj4+IE9BTSwgcHVmZi4gSVAgY2FuIGNhcnJ5IGRhdGEgb3IgT0FNIGZvciBleGFt cGxlIGJ5IHRoZSB3YXkuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJdCBkb2VzIG5vdCBnZXQgYW55IHNp bXBsZXIgYW5kIHVuYW1iaWd1b3VzIHRoYW4gdGhhdC4gV2hhdOKAmXMgdGhlDQo+Pj4+Pj4+IGFk dmFudGFnZSBvZiBtb3ZpbmcgdGhlIE9BTSBQSUQgZnVydGhlciBpbnNpZGU/DQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBBbmQgSSBkbyBub3QgYmVsaWV2ZSB0aGVyZeKAmXMgdW5kZXJzcGVjaWZpY2F0aW9u IGluIE5TSCAtPiBPPTEsIE9BTQ0KPj4+Pj4+PiB0cmVhdG1lbnQsIG5vdCBkZXRhaWxlZCBoZXJl Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiANCj4+Pj4+Pj4g4oCUIENhcmxv cy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAgICAgICAgICAgIFJlZ2FyZHMsDQo+ Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiAqRnJvbToqIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRh QGNpc2NvLmNvbV0NCj4+Pj4+Pj4+ICpTZW50OiogRnJpZGF5LCBKdWx5IDIyLCAyMDE2IDEwOjEw IEFNDQo+Pj4+Pj4+PiAqVG86KiBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nz b24uY29tDQo+Pj4+Pj4+PiA8bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+DQo+ Pj4+Pj4+PiAqQ2M6KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+OyBydGctb29h bS1kdEBpZXRmLm9yZw0KPj4+Pj4+Pj4gPG1haWx0bzpydGctb29hbS1kdEBpZXRmLm9yZz4NCj4+ Pj4+Pj4+ICpTdWJqZWN0OiogUmU6IFtSdGctb29hbS1kdF0gSWRlbnRpZnlpbmcgT0FNIGluIE5T SA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBHcmVnLA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IFBsZWFzZSBmaW5kIHNvbWUgY29tbWVudHMgaW5saW5lLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBUaHVtYiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0YXJvLg0KPj4+Pj4+Pj4gRXhjdXplIHR5cG9m cmFwaGljYWsgZXJyb3dzDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gT24gSnVsIDIx LCAyMDE2LCBhdCAwOTowMSwgR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29u LmNvbQ0KPj4+Pj4+Pj4gPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PiB3cm90 ZToNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gRGVhciBBbGwsDQo+Pj4+Pj4+PiB3ZSBoYWQgdmVyeSBn b29kIGRpc2N1c3Npb24gb24gT0FNIHRoaXMgd2Vlay4gV2XigJl2ZSB0b3VjaGVkIG9uDQo+Pj4+ Pj4+PiBBY3RpdmUsIFBhc3NpdmUgYW5kIFNvbWV0aGluZy1pbi1iZXR3ZWVuIE9BTS4gQnV0IGNh biBOU0ggaW5kaWNhdGUNCj4+Pj4+Pj4+IHdoaWNoIE9BTSB0eXBlLCBpZiBhbnksIGFzc29jaWF0 ZWQgd2l0aCBhIHBhY2tldD8gSSB0aGluayB0aGF0IHRoZQ0KPj4+Pj4+Pj4gY3VycmVudCB2ZXJz aW9uIG9mIGRyYWZ0LWlldGYtc2ZjLW5zaCBkb2VzIG5vdCBhbGxvdyB0aGF0IGFuZCBtYXkNCj4+ Pj4+Pj4+IGJlIGFtYmlndW91cyBpbiBzb21lIGNhc2VzLiBJIHByb3Bvc2UgY2hhbmdlIHRvIGlu dGVycHJldGF0aW9uIGFuZA0KPj4+Pj4+Pj4gYXBwbGljYWJpbGl0eSBkZXNjcmlwdGlvbiBvZiB0 aGUgTyhBTSkgZmxhZyBhbmQgYWxsb2NhdGlvbiBvZiB0aGUNCj4+Pj4+Pj4+IG5ldyBwcm90b2Nv bCB0eXBlIHRvIGJlIHVzZWQgaW4gdGhlIE5leHQgUHJvdG9jb2wgZmllbGQuDQo+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBBY3RpdmUsIHBhc3NpdmUgYW5kIHNvbWV0 aGluZy1pbi1iZXR3ZWVuIGFyZSBub3QgT0FNIHByb3RvY29sIHR5cGVzDQo+Pj4+Pj4+PiBidXQg cmF0aGVyIHRoZXkgYXJlIG1lYXN1cmluZyBtZXRob2RzLiBBY3RpdmUgT0FNIGNhbiBpbmNsdWRl IGENCj4+Pj4+Pj4+IHBsdXJhbGl0eSBvZiBPQU0gcHJvdG9jb2xzLCBpbmNsdWRpbmcgQkZELCBT LUJGRCwgc29tZXRoaW5nLW92ZXItaXAsIGV0Yy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gSSBhbHNv IGJlbGlldmUgdGhhdCB0aGUgY3VycmVudCBPQU0gdGV4dCBpbiBOU0ggaXMgbm90IGFtYmlndW91 cyBhbmQNCj4+Pj4+Pj4+IGFsbG93cyBlbm91Z2ggcHJvY2Vzc2luZyBvZiB0aGUgaGVhZGVyIHRv IHVuZGVyc3RhbmQgc29tZXRoaW5nIGlzIE9BTSwNCj4+Pj4+Pj4+IHdpdGhvdXQgZ29pbmcgdGhl IHNwZWNpZmljcyBvZiBhbiBPQU0gaGFuZGxlci4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gVGhlcmVm b3JlLCBJIG9wcG9zZSB0aGlzIGNoYW5nZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBSRkMgNzc5OSBkZWZpbmVzIEFjdGl2ZSBPQU0gYXMgZm9sbG93aW5nOg0KPj4+Pj4+Pj4gQW4g QWN0aXZlIE1ldHJpYyBvciBNZXRob2QgZGVwZW5kcyBvbiBhIGRlZGljYXRlZCBtZWFzdXJlbWVu dA0KPj4+Pj4+Pj4gcGFja2V0IHN0cmVhbSBhbmQgb2JzZXJ2YXRpb25zIG9mIHRoZSBzdHJlYW0u DQo+Pj4+Pj4+PiBUaHVzLCByZWdhcmRsZXNzIG9mIGVuY2Fwc3VsYXRpb24gdXNlZCBieSBPQU0s IGl0IGlzIHRoZSBwYWNrZXQNCj4+Pj4+Pj4+IGNvbnN0cnVjdGVkIHNvbGVseSBmb3IgbW9uaXRv cmluZywgbWVhc3VyaW5nIG5ldHdvcmvigJlzIG1ldHJpYyBhbmQNCj4+Pj4+Pj4+IHNob3VsZCBu b3QgbGVhdmUgZ2l2ZW4gZG9tYWluLiBBbmQsIEkgYmVsaWV2ZSwgc3VjaCBwYWNrZXRzIHNob3Vs ZA0KPj4+Pj4+Pj4gYmUgaWRlbnRpZmllZCBieSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGVpciBv d24uDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gU2VlbXMgeW91IGFyZSBhZHZvY2F0 aW5nIGZvciBhIHNpbmdsZSAiT0FNIiBwcm90b2NvbCB0eXBlIGZvciBPQU0NCj4+Pj4+Pj4+IHBh Y2tldHMuIFRoZSBmdW5jdGlvbmFsaXR5IG9mIGlkZW50aWZ5aW5nIHNvbWV0aGluZyBhcyBPQU0g aXMgaW4gdGhlDQo+Pj4+Pj4+PiBPLWJpdCwgc28gbm8gbmVlZCB0byB3YXN0ZSBiaXRzIGluIGR1 cGxpY2F0aW9uLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGVuLCBhdCBzb21lIHBvaW50LCB5b3Ug aGF2ZSB0byBkaWZmZXJlbnRpYXRlIGlmIGFuIE9BTSBpcywgc2F5LCBJUA0KPj4+Pj4+Pj4gb3Ig InJhdyBCRkQiIG9yIHNvbWV0aGluZyBlbHNlLiBUaGF0J3Mgd2hhdCB0aGUgUHJvdG9jb2wgZmll bGQgaXMgZm9yLg0KPj4+Pj4+Pj4gSSBkbyBub3Qgc2VlIGEgbmVlZCB0byBhZGQgYW4gaW5kaXJl Y3Rpb24gaGVyZSB0byB0aGVuIGhhdmUgdG8gaGF2ZSBhDQo+Pj4+Pj4+PiBwcm90b2NvbCBmaWVs ZCBpbnNpZGUgdGhlIE9BTS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBPQU0gd2hp Y2ggYmVoYXZlcyBhcyBtdWNoIGFzIFBhc3NpdmUgT0FNIG9yIFNvbWV0aGluZy1pbi1iZXR3ZWVu LA0KPj4+Pj4+Pj4gZS5nLiBPQU0gYXBwZW5kZWQgdG8gZGF0YSBwYWNrZXQgZWl0aGVyIGF0IHRo ZSBkb21haW7igJlzIGVkZ2Ugb3INCj4+Pj4+Pj4+IG9uLXRoZS1mbHksIGlkZW50aWZpZWQgYnkg dGhlIHByb3RvY29sIHR5cGUgb2YgdGhlIGRhdGEgcGFja2V0DQo+Pj4+Pj4+PiBjYXJyaWVkIGlu IE5TSC4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGF0J3MgY29ycmVjdCwgd2l0 aCB0aGUgTyBiaXQgY2xlYXJlZDsgaXQncyBhIGRhdGEgcGFja2V0IGFuZCBub3QgYW4NCj4+Pj4+ Pj4+IE9BTSBvbmUuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gQmVsb3cgYXJlIGNo YW5nZXMgSeKAmWQgbGlrZSB0byBwcm9wb3NlOg0KPj4+Pj4+Pj4gU2VjdGlvbiAzLjIgTy1iaXQ6 DQo+Pj4+Pj4+PiBPTEQNCj4+Pj4+Pj4+ICAgIE8gYml0OiB3aGVuIHNldCB0byAweDEgaW5kaWNh dGVzIHRoYXQgdGhpcyBwYWNrZXQgaXMgYW4gT3BlcmF0aW9ucywNCj4+Pj4+Pj4+ICAgIEFkbWlu aXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKSBtZXNzYWdlLiAgVGhlIHJlY2VpdmluZw0K Pj4+Pj4+Pj4gU0ZGIGFuZA0KPj4+Pj4+Pj4gICAgU0ZzIG5vZGVzIE1VU1QgZXhhbWluZSB0aGUg cGF5bG9hZCBhbmQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24NCj4+Pj4+Pj4+IChlLmcuDQo+Pj4+ Pj4+PiAgICByZXR1cm4gc3RhdHVzIGluZm9ybWF0aW9uKS4gIE9BTSBtZXNzYWdlIHNwZWNpZmlj cyBhbmQgaGFuZGxpbmcNCj4+Pj4+Pj4+ICAgIGRldGFpbHMgYXJlIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQuDQo+Pj4+Pj4+PiBFTkQNCj4+Pj4+Pj4+IE5FVw0KPj4+Pj4+Pj4g TyBiaXQ6IHdoZW4gc2V0IHRvIDB4MSBpbmRpY2F0ZXMgdGhhdCBkYXRhIHBhY2tldCBpZGVudGlm aWVkIGJ5DQo+Pj4+Pj4+PiB0aGUgTmV4dA0KPj4+Pj4+Pj4gUHJvdG9jb2wgdHlwZSBoYXMgT0FN IG1ldGFkYXRhIGFwcGVuZGVkLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IE5vLiBJ ZiBpdCBpcyBhIGRhdGEgcGFja2V0IGl0IGRvZXMgbm90IGhhdmUgdGhlIE8gYml0IHNldCAodG8g MSBvciB0bw0KPj4+Pj4+Pj4gd2hpY2hldmVyIG90aGVyIHBvc3NpYmxlIHZhbHVlIGZvciB0aGUg Yml0IDotKQ0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGUgZ29hbCBpcyB0aGF0IGxvb2tpbmcgYXQg YSBzaW5nbGUgYnV0IGl0IGNhbiBiZSB1bmRlcnN0b29kIGlmIGl0IGlzDQo+Pj4+Pj4+PiBhIGRh dGEgcGFja2V0ICh3aGljaCBjYW4gYmUgdXNlZCwgbWFya2VkLCBldGMuIHRvIGJlIHVzZWQgZm9y IE9BTQ0KPj4+Pj4+Pj4gcHVycG9zZXMsIG9yIG5vdCkuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFdl IGRvIG5vdCB3YW50IE9BTSBkaXJlY3QgZXhjZXB0aW9uIHByb2Nlc3NpbmcgZm9yIGRhdGEgcGFj a2V0cy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBEZWZpbml0aW9uIG9mIHRoZSBm b3JtYXQocykNCj4+Pj4+Pj4+IHVzZWQgYnkgT0FNIG1ldGFkYXRhIGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+Pj4+Pj4+PiBFTkQNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g QXQgdGhlIGVuZCBvZiBTZWN0aW9uIDMuMjoNCj4+Pj4+Pj4+IE9MRA0KPj4+Pj4+Pj4gICAgVGhp cyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgTmV4dCBQcm90b2NvbCB2YWx1ZXM6DQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+ICAgIDB4MSA6IElQdjQNCj4+Pj4+Pj4+ICAgIDB4MiA6IElQdjYNCj4+ Pj4+Pj4+ICAgIDB4MyA6IEV0aGVybmV0DQo+Pj4+Pj4+PiAgICAweDQ6IE5TSA0KPj4+Pj4+Pj4g ICAgMHg1OiBNUExTDQo+Pj4+Pj4+PiAgICAweDYtMHhGRDogVW5hc3NpZ25lZA0KPj4+Pj4+Pj4g ICAgMHhGRS0weEZGOiBFeHBlcmltZW50YWwNCj4+Pj4+Pj4+IEVORA0KPj4+Pj4+Pj4gTkVXDQo+ Pj4+Pj4+PiAgICBUaGlzIGRyYWZ0IGRlZmluZXMgdGhlIGZvbGxvd2luZyBOZXh0IFByb3RvY29s IHZhbHVlczoNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gICAgMHgxIDogSVB2NA0KPj4+Pj4+Pj4gICAg MHgyIDogSVB2Ng0KPj4+Pj4+Pj4gICAgMHgzIDogRXRoZXJuZXQNCj4+Pj4+Pj4+ICAgIDB4NDog TlNIDQo+Pj4+Pj4+PiAgICAweDU6IE1QTFMNCj4+Pj4+Pj4+ICAgIDB4NjogQWN0aXZlIE9BTQ0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEFzIHBlciBhYm92ZSBJIGRvIG5vdCBiZWxp ZXZlIHRoZXJlJ3MgYSBzaW5nbGUgT0FNIHByb3RvY29sLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+ICAgIDB4Ny0weEZEOiBVbmFzc2lnbmVkDQo+Pj4+Pj4+PiAgICAweEZFLTB4RkY6 IEV4cGVyaW1lbnRhbA0KPj4+Pj4+Pj4gRU5EDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEFuZCwgY29u c2VxdWVudGx5LCBzZWN0aW9uIDEzLjIuNSBpbiBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24N Cj4+Pj4+Pj4+IHdpbGwgcmVxdWVzdCBhbGxvY2F0aW9uIG9mIHZhbHVlIDB4NiB0byBiZSBhc3Np Z25lZCB0byBBY3RpdmUgT0FNDQo+Pj4+Pj4+PiBwcm90b2NvbHMuDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IEdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIGNvbnNpZGVyYXRpb24gYW5kIGNvbW1lbnRzLg0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gTXkg4oKsMC4wMi4NCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBDYXJsb3MuDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQo+ Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+Pj4gUnRnLW9vYW0tZHQgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBS dGctb29hbS1kdEBpZXRmLm9yZyA8bWFpbHRvOlJ0Zy1vb2FtLWR0QGlldGYub3JnPg0KPj4+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGctb29hbS1kdA0KPj4+ Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IHNmYyBtYWlsaW5n IGxpc3QNCj4+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4gDQo+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gDQo+PiANCg0K From nobody Tue Aug 9 07:06: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 DB2CE12D810; Tue, 9 Aug 2016 07:06:09 -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 0rn6nYeZ78Xm; Tue, 9 Aug 2016 07:06:04 -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 A05C212D16F; Tue, 9 Aug 2016 07:06:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8DC931C0541; Tue, 9 Aug 2016 07:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470751563; bh=L47aNd741w4bZyTpNBTLo+Dn0+uv4gqvkzG2NIYK9Zk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ScPCE0lmuHJtON7bIJ0ekFjqY+1MAZ81szzmhyYq8zNgSIKMKAtH6TDMxKhxflzFL rXdWEcf+XGPRUA6JdYOocHGX6HT4U5gYxaNiARFpNezkndhHpL/BvEBoV856wtKAOw 9a78YAqfad8bX3jgO+R4NS+sokOrUguxyZeYye7c= 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 9C16742122A; Tue, 9 Aug 2016 07:06:02 -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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <5150831E-1328-4451-B65E-3298F422D31D@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 9 Aug 2016 10:07:46 -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: <5150831E-1328-4451-B65E-3298F422D31D@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Gregory Mirsky , "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: Tue, 09 Aug 2016 14:06:10 -0000 What would you suggest for intercepting iOAM? I do think being clear about the difference in meaning, and the semantics of what we are defining, is quite important and helpful. Yours, Joel On 8/9/16 9:40 AM, Carlos Pignataro (cpignata) wrote: > Joel, > >> On Aug 9, 2016, at 9:30 AM, Joel M. Halpern wrote: >> >> I would normally be inclined to agree with your definition Carlos. >> However, if there can be "Piggyback OAM" that has to be processed by SFF, then we have to make that efficient for the SFF to detect (since it has to check every packet for this case. >> >> Note that the meaning of the OAM bit is whatever we say it is. >> One definition is "the carried packet is an OAM packet." But we could also define it more similarly to the router alert bit as in "this packet needs special checking at each SFF and SF.” >> > > Indeed, it is for us to define. > > There’s an important corollary in defining an “inspect closely” / RAO-like bit, which is that it will affect processing and punt to a different path, equally for “active OAM” than to “piggy back OAM”. > > Personally, I’d feel more future-safe is we do not conflate both approaches on the same bit, as there are other options for intercepting iOAM potentially, and keep an O bit to mean “OAM packet, OAM-process it”. > > Do you see drawbacks with that? > > Thanks, > > Carlos. > >> Yours, >> Joel >> >> On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: >>> “Piggyback OAM” piggybacks on a data packet, not an OAM packet. >>> >>> Thanks, >>> >>> — Carlos. >>> >>>> On Aug 9, 2016, at 3:25 AM, Dave Dolson wrote: >>>> >>>> I guess the confusion is that piggyback OAM is not using the OAM bit. >>>> >>>> >>>> Original Message >>>> From: Carlos Pignataro (cpignata) >>>> Sent: Tuesday, August 9, 2016 1:31 AM >>>> To: Dave Dolson >>>> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; sfc@ietf.org >>>> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >>>> >>>> >>>> Hi Dave, >>>> >>>> With apologies for the much belated response; please find one clarification inline: >>>> >>>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson wrote: >>>>> >>>>> Should the doc say, >>>>> >>>>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT >>>>> process the packet solely by SPI/SI forwarding but >>>>> instead by the semantics specified by the ‎OAM >>>>> 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. >>>>> >>>>> ‎Without further language, it is not specified how >>>>> to handle *any* next-protocol values when O=1. >>>>> >>>>> And when specified... >>>>> >>>>> As for so-called piggyback OAM, we could define >>>>> that if O=1 >>>> >>>> This might be the source of the confusion — if O=1, that’s not a data packet. The idea with piggyback OAM is to disturb the packet the least. If we flag a data packet as OAM, it takes a completely different processing path. >>>> >>>> Piggyback OAM is a data packet, O=0, with embedded instrumentation, as in draft-brockners-inband-oam-transport. >>>> >>>>> and Next Protocol=IPv4 there may be >>>>> an OAM header following the IPv4 packet, >>>>> located using IPv4 total length.‎ Or we could >>>>> define a new number for IPv4-with-OAM-trailer. >>>> >>>> Sorry but there seems to be a lot of unnecessary complexity in that. Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an OAM packet in IPv4 (as for example an ICMPv4 packet, or for example a BFDoUDPoIPv4 packet. >>>> >>>> Thanks, >>>> >>>> — Carlos. >>>> >>>>> >>>>> 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=1, 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 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 >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> > From nobody Tue Aug 9 09:17: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 EFAE912D7B8 for ; Tue, 9 Aug 2016 09:17:34 -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 7-HDw9akVCT1 for ; Tue, 9 Aug 2016 09:17:31 -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 5A00812D643 for ; Tue, 9 Aug 2016 09:17:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 420C86C001E; Tue, 9 Aug 2016 09:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470759451; bh=VT/q2brMjIsDiTZXrjmei0XaC0nmt2pAuY+wTa0sNgM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=daQ27xDDUZ2tETjSgrRyNqMgJ/1coRy/AA979EEwRVzl4X2kQrRbMHVp07IdKcuYM 6bqeij1Lj0Uw65YobGfGwXbsgCM0SxL25oZs6QAYAreVoHEM7H7LvNHHnynoqkVuFQ OJACo41wgBaa5a7R9pb6zdc87L2lrBTgSSy4XqrU= 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 958AC1C0C2B; Tue, 9 Aug 2016 09:17:30 -0700 (PDT) To: Loa Andersson , sfc@ietf.org 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> From: "Joel M. Halpern" Message-ID: Date: Tue, 9 Aug 2016 12:19:16 -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: <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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: Tue, 09 Aug 2016 16:17:35 -0000 Clearly, we would like as much fate sharing as possible. I believe most of the MPLS OAM cases where such that intermediate MPLS LSPs do not have to do any OAM processing. In contrast, there are proposed SFC OAM behaviors that require processing at intermediate SFF. MPLS uses TTL mechanisms to cover the few cases where it needs that. NSH can not do that, because the service index (which alos provides loop suppression) is part of the forwarding logic. So constructing initial packets with different SIs will break forwarding. Yours, Joel On 8/9/16 9:36 AM, Loa Andersson wrote: > Folks, > > Maybe a naive question. > > On 2016-08-09 15:30, Joel M. Halpern wrote: >> I would normally be inclined to agree with your definition Carlos. >> However, if there can be "Piggyback OAM" that has to be processed by >> SFF, then we have to make that efficient for the SFF to detect (since it >> has to check every packet for this case. >> >> Note that the meaning of the OAM bit is whatever we say it is. >> One definition is "the carried packet is an OAM packet." But we could >> also define it more similarly to the router alert bit as in "this packet >> needs special checking at each SFF and SF." > > During the discussions on MPLS OAM we had as a rule of thumb, that the > route and processing of OAM packets need to be the same as for payload > packet. > > If we postulate "needs special checking at each SFF and SF" are we > abandoning this for SFC? > > /Loa >> >> Yours, >> Joel >> >> On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: >>> “Piggyback OAM” piggybacks on a data packet, not an OAM packet. >>> >>> Thanks, >>> >>> — Carlos. >>> >>>> On Aug 9, 2016, at 3:25 AM, Dave Dolson wrote: >>>> >>>> I guess the confusion is that piggyback OAM is not using the OAM bit. >>>> >>>> >>>> Original Message >>>> From: Carlos Pignataro (cpignata) >>>> Sent: Tuesday, August 9, 2016 1:31 AM >>>> To: Dave Dolson >>>> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; sfc@ietf.org >>>> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >>>> >>>> >>>> Hi Dave, >>>> >>>> With apologies for the much belated response; please find one >>>> clarification inline: >>>> >>>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson wrote: >>>>> >>>>> Should the doc say, >>>>> >>>>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT >>>>> process the packet solely by SPI/SI forwarding but >>>>> instead by the semantics specified by the ‎OAM >>>>> 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. >>>>> >>>>> ‎Without further language, it is not specified how >>>>> to handle *any* next-protocol values when O=1. >>>>> >>>>> And when specified... >>>>> >>>>> As for so-called piggyback OAM, we could define >>>>> that if O=1 >>>> >>>> This might be the source of the confusion — if O=1, that’s not a data >>>> packet. The idea with piggyback OAM is to disturb the packet the >>>> least. If we flag a data packet as OAM, it takes a completely >>>> different processing path. >>>> >>>> Piggyback OAM is a data packet, O=0, with embedded instrumentation, >>>> as in draft-brockners-inband-oam-transport. >>>> >>>>> and Next Protocol=IPv4 there may be >>>>> an OAM header following the IPv4 packet, >>>>> located using IPv4 total length.‎ Or we could >>>>> define a new number for IPv4-with-OAM-trailer. >>>> >>>> Sorry but there seems to be a lot of unnecessary complexity in that. >>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an OAM >>>> packet in IPv4 (as for example an ICMPv4 packet, or for example a >>>> BFDoUDPoIPv4 packet. >>>> >>>> Thanks, >>>> >>>> — Carlos. >>>> >>>>> >>>>> 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=1, 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 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 >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Aug 10 04:19: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 2E96312D0C8 for ; Wed, 10 Aug 2016 04:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B4kHqN4apMQ for ; Wed, 10 Aug 2016 04:19:13 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291A712D091 for ; Wed, 10 Aug 2016 04:19:13 -0700 (PDT) Received: from [192.168.0.102] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 86F9E18015A1; Wed, 10 Aug 2016 13:19:11 +0200 (CEST) To: "Joel M. Halpern" , sfc@ietf.org 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> From: Loa Andersson Message-ID: Date: Wed, 10 Aug 2016 13:19:05 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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: Wed, 10 Aug 2016 11:19:16 -0000 Joel, Yes I see the problem, you described (high-level) what happens in an MPLS(-TP), but wouldn't we limit the data plane measurements we could do if the OAM and payload packets are treated differently by the data plane? Would it be feasible to look into a mechanism that only do the OAM treatment at the end-points? /Loa On 2016-08-09 18:19, Joel M. Halpern wrote: > Clearly, we would like as much fate sharing as possible. > > I believe most of the MPLS OAM cases where such that intermediate MPLS > LSPs do not have to do any OAM processing. > > In contrast, there are proposed SFC OAM behaviors that require > processing at intermediate SFF. > MPLS uses TTL mechanisms to cover the few cases where it needs that. NSH > can not do that, because the service index (which alos provides loop > suppression) is part of the forwarding logic. So constructing initial > packets with different SIs will break forwarding. > > Yours, > Joel > > On 8/9/16 9:36 AM, Loa Andersson wrote: >> Folks, >> >> Maybe a naive question. >> >> On 2016-08-09 15:30, Joel M. Halpern wrote: >>> I would normally be inclined to agree with your definition Carlos. >>> However, if there can be "Piggyback OAM" that has to be processed by >>> SFF, then we have to make that efficient for the SFF to detect (since it >>> has to check every packet for this case. >>> >>> Note that the meaning of the OAM bit is whatever we say it is. >>> One definition is "the carried packet is an OAM packet." But we could >>> also define it more similarly to the router alert bit as in "this packet >>> needs special checking at each SFF and SF." >> >> During the discussions on MPLS OAM we had as a rule of thumb, that the >> route and processing of OAM packets need to be the same as for payload >> packet. >> >> If we postulate "needs special checking at each SFF and SF" are we >> abandoning this for SFC? >> >> /Loa >>> >>> Yours, >>> Joel >>> >>> On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: >>>> “Piggyback OAM” piggybacks on a data packet, not an OAM packet. >>>> >>>> Thanks, >>>> >>>> — Carlos. >>>> >>>>> On Aug 9, 2016, at 3:25 AM, Dave Dolson wrote: >>>>> >>>>> I guess the confusion is that piggyback OAM is not using the OAM bit. >>>>> >>>>> >>>>> Original Message >>>>> From: Carlos Pignataro (cpignata) >>>>> Sent: Tuesday, August 9, 2016 1:31 AM >>>>> To: Dave Dolson >>>>> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >>>>> >>>>> >>>>> Hi Dave, >>>>> >>>>> With apologies for the much belated response; please find one >>>>> clarification inline: >>>>> >>>>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson >>>>>> wrote: >>>>>> >>>>>> Should the doc say, >>>>>> >>>>>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT >>>>>> process the packet solely by SPI/SI forwarding but >>>>>> instead by the semantics specified by the ‎OAM >>>>>> 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. >>>>>> >>>>>> ‎Without further language, it is not specified how >>>>>> to handle *any* next-protocol values when O=1. >>>>>> >>>>>> And when specified... >>>>>> >>>>>> As for so-called piggyback OAM, we could define >>>>>> that if O=1 >>>>> >>>>> This might be the source of the confusion — if O=1, that’s not a data >>>>> packet. The idea with piggyback OAM is to disturb the packet the >>>>> least. If we flag a data packet as OAM, it takes a completely >>>>> different processing path. >>>>> >>>>> Piggyback OAM is a data packet, O=0, with embedded instrumentation, >>>>> as in draft-brockners-inband-oam-transport. >>>>> >>>>>> and Next Protocol=IPv4 there may be >>>>>> an OAM header following the IPv4 packet, >>>>>> located using IPv4 total length.‎ Or we could >>>>>> define a new number for IPv4-with-OAM-trailer. >>>>> >>>>> Sorry but there seems to be a lot of unnecessary complexity in that. >>>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an OAM >>>>> packet in IPv4 (as for example an ICMPv4 packet, or for example a >>>>> BFDoUDPoIPv4 packet. >>>>> >>>>> Thanks, >>>>> >>>>> — Carlos. >>>>> >>>>>> >>>>>> 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=1, 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 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 >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Aug 10 06:58: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 AF88112D7E4 for ; Wed, 10 Aug 2016 06:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOKjUJqTHC-B for ; Wed, 10 Aug 2016 06:57:47 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32CF12D73D for ; Wed, 10 Aug 2016 06:57:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8B2D5263CDE; Wed, 10 Aug 2016 06:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470837467; bh=kv8d2U6bZai/yt9J4qHPY0x6uG/Iet/5c2wAVbiQsg0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Pmu81ZpV5CN7825/S9OheqmZ61MyoAJGPabclM5EmAN4GLwqPZfM9qmUxKXvvBhCr CA5qM/BSit6VIvgWb18LIsBtNT5GWAyFjFGSfSpZbheoV4NdAK9zki9gfQBgpW65Lx wzx9ec7hDMOh5mhcpOampASvZZf2wh5rKqFGHeK0= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E7E8524FD3E; Wed, 10 Aug 2016 06:57:46 -0700 (PDT) To: Loa Andersson , sfc@ietf.org 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> From: "Joel M. Halpern" Message-ID: <291a8452-bdef-e224-c78a-392843cee125@joelhalpern.com> Date: Wed, 10 Aug 2016 09:59:52 -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=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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: Wed, 10 Aug 2016 13:57:53 -0000 There are OAM tasks where only the end-points are involved. In that case, I think we would all like to see as much fate sharing with the normal data path as a possible. But there are a lot of cases where that does not apply. So we can not simply take the rule of thumb you suggested and run with it. Yours, Joel On 8/10/16 7:19 AM, Loa Andersson wrote: > Joel, > > Yes I see the problem, you described (high-level) what happens in an > MPLS(-TP), but wouldn't we limit the data plane measurements we could > do if the OAM and payload packets are treated differently by the > data plane? Would it be feasible to look into a mechanism that only > do the OAM treatment at the end-points? > > /Loa > > On 2016-08-09 18:19, Joel M. Halpern wrote: >> Clearly, we would like as much fate sharing as possible. >> >> I believe most of the MPLS OAM cases where such that intermediate MPLS >> LSPs do not have to do any OAM processing. >> >> In contrast, there are proposed SFC OAM behaviors that require >> processing at intermediate SFF. >> MPLS uses TTL mechanisms to cover the few cases where it needs that. NSH >> can not do that, because the service index (which alos provides loop >> suppression) is part of the forwarding logic. So constructing initial >> packets with different SIs will break forwarding. >> >> Yours, >> Joel >> >> On 8/9/16 9:36 AM, Loa Andersson wrote: >>> Folks, >>> >>> Maybe a naive question. >>> >>> On 2016-08-09 15:30, Joel M. Halpern wrote: >>>> I would normally be inclined to agree with your definition Carlos. >>>> However, if there can be "Piggyback OAM" that has to be processed by >>>> SFF, then we have to make that efficient for the SFF to detect >>>> (since it >>>> has to check every packet for this case. >>>> >>>> Note that the meaning of the OAM bit is whatever we say it is. >>>> One definition is "the carried packet is an OAM packet." But we could >>>> also define it more similarly to the router alert bit as in "this >>>> packet >>>> needs special checking at each SFF and SF." >>> >>> During the discussions on MPLS OAM we had as a rule of thumb, that the >>> route and processing of OAM packets need to be the same as for payload >>> packet. >>> >>> If we postulate "needs special checking at each SFF and SF" are we >>> abandoning this for SFC? >>> >>> /Loa >>>> >>>> Yours, >>>> Joel >>>> >>>> On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: >>>>> “Piggyback OAM” piggybacks on a data packet, not an OAM packet. >>>>> >>>>> Thanks, >>>>> >>>>> — Carlos. >>>>> >>>>>> On Aug 9, 2016, at 3:25 AM, Dave Dolson wrote: >>>>>> >>>>>> I guess the confusion is that piggyback OAM is not using the OAM bit. >>>>>> >>>>>> >>>>>> Original Message >>>>>> From: Carlos Pignataro (cpignata) >>>>>> Sent: Tuesday, August 9, 2016 1:31 AM >>>>>> To: Dave Dolson >>>>>> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; >>>>>> sfc@ietf.org >>>>>> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >>>>>> >>>>>> >>>>>> Hi Dave, >>>>>> >>>>>> With apologies for the much belated response; please find one >>>>>> clarification inline: >>>>>> >>>>>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson >>>>>>> wrote: >>>>>>> >>>>>>> Should the doc say, >>>>>>> >>>>>>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT >>>>>>> process the packet solely by SPI/SI forwarding but >>>>>>> instead by the semantics specified by the ‎OAM >>>>>>> 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. >>>>>>> >>>>>>> ‎Without further language, it is not specified how >>>>>>> to handle *any* next-protocol values when O=1. >>>>>>> >>>>>>> And when specified... >>>>>>> >>>>>>> As for so-called piggyback OAM, we could define >>>>>>> that if O=1 >>>>>> >>>>>> This might be the source of the confusion — if O=1, that’s not a data >>>>>> packet. The idea with piggyback OAM is to disturb the packet the >>>>>> least. If we flag a data packet as OAM, it takes a completely >>>>>> different processing path. >>>>>> >>>>>> Piggyback OAM is a data packet, O=0, with embedded instrumentation, >>>>>> as in draft-brockners-inband-oam-transport. >>>>>> >>>>>>> and Next Protocol=IPv4 there may be >>>>>>> an OAM header following the IPv4 packet, >>>>>>> located using IPv4 total length.‎ Or we could >>>>>>> define a new number for IPv4-with-OAM-trailer. >>>>>> >>>>>> Sorry but there seems to be a lot of unnecessary complexity in that. >>>>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an OAM >>>>>> packet in IPv4 (as for example an ICMPv4 packet, or for example a >>>>>> BFDoUDPoIPv4 packet. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> — Carlos. >>>>>> >>>>>>> >>>>>>> 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=1, 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 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 >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Aug 10 07:11: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 3FC9A12D73D for ; Wed, 10 Aug 2016 07:11:33 -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 XRKXngHBfnPo for ; Wed, 10 Aug 2016 07:11:26 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76CCB12D7EF for ; Wed, 10 Aug 2016 07:11:25 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id q128so96376030wma.1 for ; Wed, 10 Aug 2016 07:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=lYwG5KV1TP6PqcNfGZ0keP0DRwsyAyxJ4ofKmghp3zk=; b=U6xOO+ygCioOQUrXJEfrsrgMRTtQ+8p0GOPb9mObP9f+pIYS4AuO5Gl+5JkwL0cd2j 1jBR/ODZ88R4TOecWln2uLHSjZgIyWlWu1U14cJXvEmIQLfNb/gspMSfosuIQvB2rdKt GxEFE0xIvvOHaIw9FguQqHJA/jEryVP0F6bOlOp6t141wWqX4k8PbENXFA+ym6M6WgXZ 4nDBYo+OX1ALi8pNVPuM1LQI8P3Rev22pj+0ijls+e1XpVFvDTFkgvO+G/YxgRmbIlwn qnFZJEjapyqC+/ZFd3/dJoG/tpvWnDOdtFpMRB+yNnxgmrr/hmIXPpIg4mgTo8Dvqz5M 5Zdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=lYwG5KV1TP6PqcNfGZ0keP0DRwsyAyxJ4ofKmghp3zk=; b=dcgwOth98c6n28fbrkPh6CwAUfRioMX7W5H+3Y0xRxbo5dWB0xb+eDQ9NIdh1i+o9/ jjNpJqbcIrvLfjHhz2bnlYApNxUOAe9fgE5bLwdRuK3uCV7VvsLvbfpBtbiUmOe37ScY epQKrtEbCGRRaqgM3OCZPA9MowNODVeS8wX41cgRKfd/AtjXJy0rPEDdXoTMpjCge7ZZ LXEJ/EQdhlNVtjaYKYzqMYTL3N+GRc3U3voSUJSyjjoAis71Hoqq8Xih1gpJpUsKirQ4 9sQxUwKTjc3Xb2PX/5BUeEG5KJty5h/LpjAoznQqy/LI4Jz3dLdLFmzC1+PKlBL4Em1C uQxQ== X-Gm-Message-State: AEkoouvX8uLzADAz1Mh6M836xOPd263axCRExYJAJ76cKVaqTSdlRmBh4Vk7pG84Wej6nw== X-Received: by 10.28.184.19 with SMTP id i19mr3339135wmf.43.1470838283780; Wed, 10 Aug 2016 07:11:23 -0700 (PDT) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id w129sm8613732wmd.9.2016.08.10.07.11.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Aug 2016 07:11:22 -0700 (PDT) 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> <291a8452-bdef-e224-c78a-392843cee125@joelhalpern.com> To: "Joel M. Halpern" , Loa Andersson , sfc@ietf.org From: Huub van Helvoort Message-ID: Date: Wed, 10 Aug 2016 16:11:21 +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 In-Reply-To: <291a8452-bdef-e224-c78a-392843cee125@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH 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: Wed, 10 Aug 2016 14:11:33 -0000 Hello Joel, You wrote: > There are OAM tasks where only the end-points are involved. In that > case, I think we would all like to see as much fate sharing with the > normal data path as a possible. Correct! > But there are a lot of cases where that does not apply. Note that in these cases the performance of the OAM will be measured, and *NOT* the performance of the payload. > So we can not simply take the rule of thumb you suggested and run with it. Why would you need to measure the performance of the OAM? Best regards, Huub. > On 8/10/16 7:19 AM, Loa Andersson wrote: >> Joel, >> >> Yes I see the problem, you described (high-level) what happens in an >> MPLS(-TP), but wouldn't we limit the data plane measurements we could >> do if the OAM and payload packets are treated differently by the >> data plane? Would it be feasible to look into a mechanism that only >> do the OAM treatment at the end-points? >> >> /Loa >> >> On 2016-08-09 18:19, Joel M. Halpern wrote: >>> Clearly, we would like as much fate sharing as possible. >>> >>> I believe most of the MPLS OAM cases where such that intermediate MPLS >>> LSPs do not have to do any OAM processing. >>> >>> In contrast, there are proposed SFC OAM behaviors that require >>> processing at intermediate SFF. >>> MPLS uses TTL mechanisms to cover the few cases where it needs that. NSH >>> can not do that, because the service index (which alos provides loop >>> suppression) is part of the forwarding logic. So constructing initial >>> packets with different SIs will break forwarding. >>> >>> Yours, >>> Joel >>> >>> On 8/9/16 9:36 AM, Loa Andersson wrote: >>>> Folks, >>>> >>>> Maybe a naive question. >>>> >>>> On 2016-08-09 15:30, Joel M. Halpern wrote: >>>>> I would normally be inclined to agree with your definition Carlos. >>>>> However, if there can be "Piggyback OAM" that has to be processed by >>>>> SFF, then we have to make that efficient for the SFF to detect >>>>> (since it >>>>> has to check every packet for this case. >>>>> >>>>> Note that the meaning of the OAM bit is whatever we say it is. >>>>> One definition is "the carried packet is an OAM packet." But we could >>>>> also define it more similarly to the router alert bit as in "this >>>>> packet >>>>> needs special checking at each SFF and SF." >>>> >>>> During the discussions on MPLS OAM we had as a rule of thumb, that the >>>> route and processing of OAM packets need to be the same as for payload >>>> packet. >>>> >>>> If we postulate "needs special checking at each SFF and SF" are we >>>> abandoning this for SFC? >>>> >>>> /Loa >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: >>>>>> “Piggyback OAM” piggybacks on a data packet, not an OAM packet. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> — Carlos. >>>>>> >>>>>>> On Aug 9, 2016, at 3:25 AM, Dave Dolson >>>>>>> wrote: >>>>>>> >>>>>>> I guess the confusion is that piggyback OAM is not using the OAM >>>>>>> bit. >>>>>>> >>>>>>> >>>>>>> Original Message >>>>>>> From: Carlos Pignataro (cpignata) >>>>>>> Sent: Tuesday, August 9, 2016 1:31 AM >>>>>>> To: Dave Dolson >>>>>>> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; >>>>>>> sfc@ietf.org >>>>>>> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >>>>>>> >>>>>>> >>>>>>> Hi Dave, >>>>>>> >>>>>>> With apologies for the much belated response; please find one >>>>>>> clarification inline: >>>>>>> >>>>>>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson >>>>>>>> wrote: >>>>>>>> >>>>>>>> Should the doc say, >>>>>>>> >>>>>>>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT >>>>>>>> process the packet solely by SPI/SI forwarding but >>>>>>>> instead by the semantics specified by the ‎OAM >>>>>>>> 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. >>>>>>>> >>>>>>>> ‎Without further language, it is not specified how >>>>>>>> to handle *any* next-protocol values when O=1. >>>>>>>> >>>>>>>> And when specified... >>>>>>>> >>>>>>>> As for so-called piggyback OAM, we could define >>>>>>>> that if O=1 >>>>>>> >>>>>>> This might be the source of the confusion — if O=1, that’s not a >>>>>>> data >>>>>>> packet. The idea with piggyback OAM is to disturb the packet the >>>>>>> least. If we flag a data packet as OAM, it takes a completely >>>>>>> different processing path. >>>>>>> >>>>>>> Piggyback OAM is a data packet, O=0, with embedded instrumentation, >>>>>>> as in draft-brockners-inband-oam-transport. >>>>>>> >>>>>>>> and Next Protocol=IPv4 there may be >>>>>>>> an OAM header following the IPv4 packet, >>>>>>>> located using IPv4 total length.‎ Or we could >>>>>>>> define a new number for IPv4-with-OAM-trailer. >>>>>>> >>>>>>> Sorry but there seems to be a lot of unnecessary complexity in that. >>>>>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an OAM >>>>>>> packet in IPv4 (as for example an ICMPv4 packet, or for example a >>>>>>> BFDoUDPoIPv4 packet. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> — Carlos. >>>>>>> >>>>>>>> >>>>>>>> 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=1, 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 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 >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 -- ================================================================ Always remember that you are unique...just like everyone else... From nobody Wed Aug 10 08:00: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 1BFEA12D779 for ; Wed, 10 Aug 2016 08:00:14 -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 DsQbhpEJsg8R for ; Wed, 10 Aug 2016 08:00:10 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4543E12D5D1 for ; Wed, 10 Aug 2016 08:00:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2CFED26372D; Wed, 10 Aug 2016 08:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470841209; bh=AmJkDjuffYK/oPkWKQm5hzjSmeJWVZGVJoLyz3QcBNM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=L5nTsJoGpysdgwZyIV1UF24Pf6orkf2olkprfk+Yw1b5tDELgYQ2o3qLAl9/rGFlQ rwd5aTjmwJfKKI38zb/oMhLoNROG4AdvRYNWPFfG7QBSSuMFBnkxO/MxmUyr8rgULP PiYBJbl7w3Bcdpj9icI/kYIf+0yT3W6Mk7tTGPig= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6DD7D24051F; Wed, 10 Aug 2016 08:00:08 -0700 (PDT) To: huubatwork@gmail.com, Loa Andersson , sfc@ietf.org 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> <291a8452-bdef-e224-c78a-392843cee125@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <8f80b912-6c50-db63-d88b-832e497bfcac@joelhalpern.com> Date: Wed, 10 Aug 2016 11:02:15 -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=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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: Wed, 10 Aug 2016 15:00:14 -0000 Let me try phrasing this differently. As a general rule, it is clear that one wants measurement traffic to share fate with what you want to measure. Even pure connectivity checking needs to share enough fate that one can reasonably conclude from the OAM observations what the likely status is of the underlying traffic connectivity. However, the differences in constraints mean that the degree to which this can be done varies from case to case. In the case of SFC, we want to use the same SPI and SI for OAM as for regular traffic, since that helps us hae that confidence. And where we can, it is nice to have OAM traffic that is only perturbed at the end-points. However the nature of the SFF behaviors, and more importantly the nature of the SF behaviors, mean that there are serious limitations on what one can do with active mechanisms of this sort. Yours, Joel On 8/10/16 10:11 AM, Huub van Helvoort wrote: > Hello Joel, > > You wrote: > >> There are OAM tasks where only the end-points are involved. In that >> case, I think we would all like to see as much fate sharing with the >> normal data path as a possible. > > Correct! > >> But there are a lot of cases where that does not apply. > > Note that in these cases the performance of the OAM will be measured, > and *NOT* the performance of the payload. > >> So we can not simply take the rule of thumb you suggested and run with >> it. > > Why would you need to measure the performance of the OAM? > > Best regards, Huub. > > >> On 8/10/16 7:19 AM, Loa Andersson wrote: >>> Joel, >>> >>> Yes I see the problem, you described (high-level) what happens in an >>> MPLS(-TP), but wouldn't we limit the data plane measurements we could >>> do if the OAM and payload packets are treated differently by the >>> data plane? Would it be feasible to look into a mechanism that only >>> do the OAM treatment at the end-points? >>> >>> /Loa >>> >>> On 2016-08-09 18:19, Joel M. Halpern wrote: >>>> Clearly, we would like as much fate sharing as possible. >>>> >>>> I believe most of the MPLS OAM cases where such that intermediate MPLS >>>> LSPs do not have to do any OAM processing. >>>> >>>> In contrast, there are proposed SFC OAM behaviors that require >>>> processing at intermediate SFF. >>>> MPLS uses TTL mechanisms to cover the few cases where it needs that. >>>> NSH >>>> can not do that, because the service index (which alos provides loop >>>> suppression) is part of the forwarding logic. So constructing initial >>>> packets with different SIs will break forwarding. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 8/9/16 9:36 AM, Loa Andersson wrote: >>>>> Folks, >>>>> >>>>> Maybe a naive question. >>>>> >>>>> On 2016-08-09 15:30, Joel M. Halpern wrote: >>>>>> I would normally be inclined to agree with your definition Carlos. >>>>>> However, if there can be "Piggyback OAM" that has to be processed by >>>>>> SFF, then we have to make that efficient for the SFF to detect >>>>>> (since it >>>>>> has to check every packet for this case. >>>>>> >>>>>> Note that the meaning of the OAM bit is whatever we say it is. >>>>>> One definition is "the carried packet is an OAM packet." But we >>>>>> could >>>>>> also define it more similarly to the router alert bit as in "this >>>>>> packet >>>>>> needs special checking at each SFF and SF." >>>>> >>>>> During the discussions on MPLS OAM we had as a rule of thumb, that the >>>>> route and processing of OAM packets need to be the same as for payload >>>>> packet. >>>>> >>>>> If we postulate "needs special checking at each SFF and SF" are we >>>>> abandoning this for SFC? >>>>> >>>>> /Loa >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: >>>>>>> “Piggyback OAM” piggybacks on a data packet, not an OAM packet. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> — Carlos. >>>>>>> >>>>>>>> On Aug 9, 2016, at 3:25 AM, Dave Dolson >>>>>>>> wrote: >>>>>>>> >>>>>>>> I guess the confusion is that piggyback OAM is not using the OAM >>>>>>>> bit. >>>>>>>> >>>>>>>> >>>>>>>> Original Message >>>>>>>> From: Carlos Pignataro (cpignata) >>>>>>>> Sent: Tuesday, August 9, 2016 1:31 AM >>>>>>>> To: Dave Dolson >>>>>>>> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; >>>>>>>> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >>>>>>>> >>>>>>>> >>>>>>>> Hi Dave, >>>>>>>> >>>>>>>> With apologies for the much belated response; please find one >>>>>>>> clarification inline: >>>>>>>> >>>>>>>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Should the doc say, >>>>>>>>> >>>>>>>>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT >>>>>>>>> process the packet solely by SPI/SI forwarding but >>>>>>>>> instead by the semantics specified by the ‎OAM >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> ‎Without further language, it is not specified how >>>>>>>>> to handle *any* next-protocol values when O=1. >>>>>>>>> >>>>>>>>> And when specified... >>>>>>>>> >>>>>>>>> As for so-called piggyback OAM, we could define >>>>>>>>> that if O=1 >>>>>>>> >>>>>>>> This might be the source of the confusion — if O=1, that’s not a >>>>>>>> data >>>>>>>> packet. The idea with piggyback OAM is to disturb the packet the >>>>>>>> least. If we flag a data packet as OAM, it takes a completely >>>>>>>> different processing path. >>>>>>>> >>>>>>>> Piggyback OAM is a data packet, O=0, with embedded instrumentation, >>>>>>>> as in draft-brockners-inband-oam-transport. >>>>>>>> >>>>>>>>> and Next Protocol=IPv4 there may be >>>>>>>>> an OAM header following the IPv4 packet, >>>>>>>>> located using IPv4 total length.‎ Or we could >>>>>>>>> define a new number for IPv4-with-OAM-trailer. >>>>>>>> >>>>>>>> Sorry but there seems to be a lot of unnecessary complexity in >>>>>>>> that. >>>>>>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an >>>>>>>> OAM >>>>>>>> packet in IPv4 (as for example an ICMPv4 packet, or for example a >>>>>>>> BFDoUDPoIPv4 packet. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> — Carlos. >>>>>>>> >>>>>>>>> >>>>>>>>> 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=1, 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 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 >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > From nobody Wed Aug 10 09:22: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 C9D2D12D80B for ; Wed, 10 Aug 2016 09:22:09 -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 jSlX-HR9A-HK for ; Wed, 10 Aug 2016 09:22:07 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5872512D7B4 for ; Wed, 10 Aug 2016 09:22:07 -0700 (PDT) X-AuditID: c618062d-597ff70000000a08-60-57ab5551f560 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by (Symantec Mail Security) with SMTP id 01.B1.02568.1555BA75; Wed, 10 Aug 2016 18:24:51 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0301.000; Wed, 10 Aug 2016 12:12:31 -0400 From: Gregory Mirsky To: "huubatwork@gmail.com" , "Joel M. Halpern" , Loa Andersson , "sfc@ietf.org" Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AdHjGxqUb41VTqTfTwmZE/bgRl5mHQA9utSAAAZMKgAAPUPDAAAE5aOAAAoYKYAAAPZ3gAAQJUhAAxWLFAAABhPNLwASFykAAAMPW4AAADNCgAAFr7IAACfOwYAABZ2EAAAAZqyAAARHyEA= Date: Wed, 10 Aug 2016 16:12:31 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221AF899B@eusaamb103.ericsson.se> 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> <291a8452-bdef-e224-c78a-392843cee125@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPuG5w6Opwg6fb+CxmzL7MavHx1Bsm i39z5zBbPHmwld2BxWPnrLvsHkuW/GTyODflO6PHrOltbAEsUVw2Kak5mWWpRfp2CVwZL+/8 YyrY9Z6xorevsIFxxUvGLkZODgkBE4mHd7azdzFycQgJbGCU+Dq5hxXCWc4ocanzGAtIFZuA kcSLjT1gVSICMxglPu+9B9YuLGAusWLhDnYQW0TAQmLb3HtsEEXzGCVWtdxiBkmwCKhKrJry AczmFfCVaLw0BWrfcnaJBVvWgk3iFLCV6LhzHayIUUBM4vupNUwgNrOAuMStJ/OZII4VkFiy 5zwzhC0q8fLxP1YIW1FiX/90oKEcQPWaEut36UO0KkpM6X7IDrFXUOLkzCcsExhFZiGZOguh YxaSjllIOhYwsqxi5CgtLsjJTTcy2MQIjJFjEmy6OxjvT/c8xCjAwajEw6sgtSpciDWxrLgy 9xCjBAezkgivoP/qcCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Yo8Uw4UE0hNLUrNTUwtSi2Cy TBycUg2MG7ecYOV2krJx2P8q6k3id6324Eu7Sr+XXc56Mu/WvNxX8xe4f9z9XWF9sM65ruTT zfndTKu8Iy87fpr88ur0w9pHlz7RML5rb1pjzf7dwv30XZG9CTK3oxvyCpgv/mvbNGVh7oaM RfN2iaQWTfq8bXp32iKL4jl2fO92NXG9KXY1NZu2YM9NTyWW4oxEQy3mouJEAED5w/6NAgAA Archived-At: 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: Wed, 10 Aug 2016 16:22:10 -0000 SGkgSHV1YiwNCndoZW4gd2UgY29uc2lkZXIgZTJlIGFuZCBzZWdtZW50IE9BTSBzY2VuYXJpb3Mg d2UgaW5jbHVkZSBub3Qgb25seSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCAoUE0pIGJ1dCBmYXVs dCBtYW5hZ2VtZW50IChGTSkgY2FzZXMuIEkgYmVsaWV2ZSB0aGF0IGZvciB0aGUgRk0gaXQgaXMg aW1wb3J0YW50IHRvIGhhdmUgZmF0ZSBzaGFyaW5nIGZvciBzZWdtZW50IE9BTSBhcyBtdWNoIGFz IGZvciBlMmUgT0FNLiBPciBoYXZlIEkgbWlzc2VkIHRoZSBwb2ludCBvZiB0aGUgZGlzY3Vzc2lv biBjb21wbGV0ZWx5Pw0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBIdXViIHZhbiBIZWx2b29ydA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTAsIDIwMTYg NzoxMSBBTQ0KVG86IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT47IExvYSBB bmRlcnNzb24gPGxvYUBwaS5udT47IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFtS dGctb29hbS1kdF0gSWRlbnRpZnlpbmcgT0FNIGluIE5TSA0KDQpIZWxsbyBKb2VsLA0KDQpZb3Ug d3JvdGU6DQoNCj4gVGhlcmUgYXJlIE9BTSB0YXNrcyB3aGVyZSBvbmx5IHRoZSBlbmQtcG9pbnRz IGFyZSBpbnZvbHZlZC4gIEluIHRoYXQgDQo+IGNhc2UsIEkgdGhpbmsgd2Ugd291bGQgYWxsIGxp a2UgdG8gc2VlIGFzIG11Y2ggZmF0ZSBzaGFyaW5nIHdpdGggdGhlIA0KPiBub3JtYWwgZGF0YSBw YXRoIGFzIGEgcG9zc2libGUuDQoNCkNvcnJlY3QhDQoNCj4gQnV0IHRoZXJlIGFyZSBhIGxvdCBv ZiBjYXNlcyB3aGVyZSB0aGF0IGRvZXMgbm90IGFwcGx5Lg0KDQpOb3RlIHRoYXQgaW4gdGhlc2Ug Y2FzZXMgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBPQU0gd2lsbCBiZSBtZWFzdXJlZCwgYW5kICpO T1QqIHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgcGF5bG9hZC4NCg0KPiBTbyB3ZSBjYW4gbm90IHNp bXBseSB0YWtlIHRoZSBydWxlIG9mIHRodW1iIHlvdSBzdWdnZXN0ZWQgYW5kIHJ1biB3aXRoIGl0 Lg0KDQpXaHkgd291bGQgeW91IG5lZWQgdG8gbWVhc3VyZSB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhl IE9BTT8NCg0KQmVzdCByZWdhcmRzLCBIdXViLg0KDQoNCj4gT24gOC8xMC8xNiA3OjE5IEFNLCBM b2EgQW5kZXJzc29uIHdyb3RlOg0KPj4gSm9lbCwNCj4+DQo+PiBZZXMgSSBzZWUgdGhlIHByb2Js ZW0sIHlvdSBkZXNjcmliZWQgKGhpZ2gtbGV2ZWwpIHdoYXQgaGFwcGVucyBpbiBhbiANCj4+IE1Q TFMoLVRQKSwgYnV0IHdvdWxkbid0IHdlIGxpbWl0IHRoZSBkYXRhIHBsYW5lIG1lYXN1cmVtZW50 cyB3ZSBjb3VsZCANCj4+IGRvIGlmIHRoZSBPQU0gYW5kIHBheWxvYWQgcGFja2V0cyBhcmUgdHJl YXRlZCBkaWZmZXJlbnRseSBieSB0aGUgZGF0YSANCj4+IHBsYW5lPyBXb3VsZCBpdCBiZSBmZWFz aWJsZSB0byBsb29rIGludG8gYSBtZWNoYW5pc20gdGhhdCBvbmx5IGRvIHRoZSANCj4+IE9BTSB0 cmVhdG1lbnQgYXQgdGhlIGVuZC1wb2ludHM/DQo+Pg0KPj4gL0xvYQ0KPj4NCj4+IE9uIDIwMTYt MDgtMDkgMTg6MTksIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+PiBDbGVhcmx5LCB3ZSB3b3Vs ZCBsaWtlIGFzIG11Y2ggZmF0ZSBzaGFyaW5nIGFzIHBvc3NpYmxlLg0KPj4+DQo+Pj4gSSBiZWxp ZXZlIG1vc3Qgb2YgdGhlIE1QTFMgT0FNIGNhc2VzIHdoZXJlIHN1Y2ggdGhhdCBpbnRlcm1lZGlh dGUgDQo+Pj4gTVBMUyBMU1BzIGRvIG5vdCBoYXZlIHRvIGRvIGFueSBPQU0gcHJvY2Vzc2luZy4N Cj4+Pg0KPj4+IEluIGNvbnRyYXN0LCB0aGVyZSBhcmUgcHJvcG9zZWQgU0ZDIE9BTSBiZWhhdmlv cnMgdGhhdCByZXF1aXJlIA0KPj4+IHByb2Nlc3NpbmcgYXQgaW50ZXJtZWRpYXRlIFNGRi4NCj4+ PiBNUExTIHVzZXMgVFRMIG1lY2hhbmlzbXMgdG8gY292ZXIgdGhlIGZldyBjYXNlcyB3aGVyZSBp dCBuZWVkcyB0aGF0LiANCj4+PiBOU0ggY2FuIG5vdCBkbyB0aGF0LCBiZWNhdXNlIHRoZSBzZXJ2 aWNlIGluZGV4ICh3aGljaCBhbG9zIHByb3ZpZGVzIA0KPj4+IGxvb3ANCj4+PiBzdXBwcmVzc2lv bikgaXMgcGFydCBvZiB0aGUgZm9yd2FyZGluZyBsb2dpYy4gIFNvIGNvbnN0cnVjdGluZyANCj4+ PiBpbml0aWFsIHBhY2tldHMgd2l0aCBkaWZmZXJlbnQgU0lzIHdpbGwgYnJlYWsgZm9yd2FyZGlu Zy4NCj4+Pg0KPj4+IFlvdXJzLA0KPj4+IEpvZWwNCj4+Pg0KPj4+IE9uIDgvOS8xNiA5OjM2IEFN LCBMb2EgQW5kZXJzc29uIHdyb3RlOg0KPj4+PiBGb2xrcywNCj4+Pj4NCj4+Pj4gTWF5YmUgYSBu YWl2ZSBxdWVzdGlvbi4NCj4+Pj4NCj4+Pj4gT24gMjAxNi0wOC0wOSAxNTozMCwgSm9lbCBNLiBI YWxwZXJuIHdyb3RlOg0KPj4+Pj4gSSB3b3VsZCBub3JtYWxseSBiZSBpbmNsaW5lZCB0byBhZ3Jl ZSB3aXRoIHlvdXIgZGVmaW5pdGlvbiBDYXJsb3MuDQo+Pj4+PiBIb3dldmVyLCBpZiB0aGVyZSBj YW4gYmUgIlBpZ2d5YmFjayBPQU0iIHRoYXQgaGFzIHRvIGJlIHByb2Nlc3NlZCANCj4+Pj4+IGJ5 IFNGRiwgdGhlbiB3ZSBoYXZlIHRvIG1ha2UgdGhhdCBlZmZpY2llbnQgZm9yIHRoZSBTRkYgdG8g ZGV0ZWN0IA0KPj4+Pj4gKHNpbmNlIGl0IGhhcyB0byBjaGVjayBldmVyeSBwYWNrZXQgZm9yIHRo aXMgY2FzZS4NCj4+Pj4+DQo+Pj4+PiBOb3RlIHRoYXQgdGhlIG1lYW5pbmcgb2YgdGhlIE9BTSBi aXQgaXMgd2hhdGV2ZXIgd2Ugc2F5IGl0IGlzLg0KPj4+Pj4gT25lIGRlZmluaXRpb24gaXMgInRo ZSBjYXJyaWVkIHBhY2tldCBpcyBhbiBPQU0gcGFja2V0LiIgIEJ1dCB3ZSANCj4+Pj4+IGNvdWxk IGFsc28gZGVmaW5lIGl0IG1vcmUgc2ltaWxhcmx5IHRvIHRoZSByb3V0ZXIgYWxlcnQgYml0IGFz IGluIA0KPj4+Pj4gInRoaXMgcGFja2V0IG5lZWRzIHNwZWNpYWwgY2hlY2tpbmcgYXQgZWFjaCBT RkYgYW5kIFNGLiINCj4+Pj4NCj4+Pj4gRHVyaW5nIHRoZSBkaXNjdXNzaW9ucyBvbiBNUExTIE9B TSB3ZSBoYWQgYXMgYSBydWxlIG9mIHRodW1iLCB0aGF0IA0KPj4+PiB0aGUgcm91dGUgYW5kIHBy b2Nlc3Npbmcgb2YgT0FNIHBhY2tldHMgbmVlZCB0byBiZSB0aGUgc2FtZSBhcyBmb3IgDQo+Pj4+ IHBheWxvYWQgcGFja2V0Lg0KPj4+Pg0KPj4+PiBJZiB3ZSBwb3N0dWxhdGUgIm5lZWRzIHNwZWNp YWwgY2hlY2tpbmcgYXQgZWFjaCBTRkYgYW5kIFNGIiBhcmUgd2UgDQo+Pj4+IGFiYW5kb25pbmcg dGhpcyBmb3IgU0ZDPw0KPj4+Pg0KPj4+PiAvTG9hDQo+Pj4+Pg0KPj4+Pj4gWW91cnMsDQo+Pj4+ PiBKb2VsDQo+Pj4+Pg0KPj4+Pj4gT24gOC85LzE2IDg6MDMgQU0sIENhcmxvcyBQaWduYXRhcm8g KGNwaWduYXRhKSB3cm90ZToNCj4+Pj4+PiDigJxQaWdneWJhY2sgT0FN4oCdIHBpZ2d5YmFja3Mg b24gYSBkYXRhIHBhY2tldCwgbm90IGFuIE9BTSBwYWNrZXQuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGFu a3MsDQo+Pj4+Pj4NCj4+Pj4+PiDigJQgQ2FybG9zLg0KPj4+Pj4+DQo+Pj4+Pj4+IE9uIEF1ZyA5 LCAyMDE2LCBhdCAzOjI1IEFNLCBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+DQo+ Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJIGd1ZXNzIHRoZSBjb25mdXNpb24gaXMg dGhhdCBwaWdneWJhY2sgT0FNIGlzIG5vdCB1c2luZyB0aGUgT0FNIA0KPj4+Pj4+PiBiaXQuDQo+ Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICBPcmlnaW5hbCBNZXNzYWdlDQo+Pj4+Pj4+IEZyb206 IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KPj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBBdWd1 c3QgOSwgMjAxNiAxOjMxIEFNDQo+Pj4+Pj4+IFRvOiBEYXZlIERvbHNvbg0KPj4+Pj4+PiBDYzog Sm9lbCBNLiBIYWxwZXJuOyBHcmVnb3J5IE1pcnNreTsgcnRnLW9vYW0tZHRAaWV0Zi5vcmc7IA0K Pj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFtSdGctb29h bS1kdF0gSWRlbnRpZnlpbmcgT0FNIGluIE5TSA0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBI aSBEYXZlLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBXaXRoIGFwb2xvZ2llcyBmb3IgdGhlIG11Y2ggYmVs YXRlZCByZXNwb25zZTsgcGxlYXNlIGZpbmQgb25lIA0KPj4+Pj4+PiBjbGFyaWZpY2F0aW9uIGlu bGluZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIEp1bCAyNCwgMjAxNiwgYXQgMTo0NCBQTSwgRGF2 ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPg0KPj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4gU2hvdWxkIHRoZSBkb2Mgc2F5LA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICBJZiB0 aGUgT0FNIGJpdCBPPTAsIHRoaXMgaW5kaWNhdGVzIHRoZSBTRkYgTVVTVCBmb3J3YXJkICB0aGUg DQo+Pj4+Pj4+PiBwYWNrZXQgYmFzZWQgc29sZWx5IG9uIHRoZSBTUEkgYW5kIFNJIGZpZWxkcywg d2l0aG91dA0KPj4+Pj4+Pj4gICByZWdhcmQgdG8gbmV4dCBwcm90b2NvbCBvciBmdXJ0aGVyIHBh eWxvYWQgaGVhZGVycy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgSWYgdGhlIE9BTSBiaXQgTz0xLCB0 aGlzIGluZGljYXRlcyB0aGUgU0ZGIOKAjk1VU1QgTk9UICBwcm9jZXNzIA0KPj4+Pj4+Pj4gdGhl IHBhY2tldCBzb2xlbHkgYnkgU1BJL1NJIGZvcndhcmRpbmcgYnV0ICBpbnN0ZWFkIGJ5IHRoZSAN Cj4+Pj4+Pj4+IHNlbWFudGljcyBzcGVjaWZpZWQgYnkgdGhlIOKAjk9BTSAgcHJvdG9jb2wgbmFt ZWQgaW4gdGhlIE5leHQgDQo+Pj4+Pj4+PiBQcm90b2NvbCBmaWVsZC4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiBJIHRoaW5rIHRoZXNlIHBhcmFncmFwaHMgZ2V0IHRvIHRoZSBvcHRpbWl6YXRpb24gZm9y IFNGRnMsIGFuZCANCj4+Pj4+Pj4+IEkgdGhpbmsgcHJvdmlkZSBwcmVjaXNlIGxhbmd1YWdlIHdp dGhvdXQgZGVmaW5pbmcgT0FNIA0KPj4+Pj4+Pj4gcHJvdG9jb2xzLg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+IOKAjldpdGhvdXQgZnVydGhlciBsYW5ndWFnZSwgaXQgaXMgbm90IHNwZWNpZmllZCBob3cg dG8gaGFuZGxlIA0KPj4+Pj4+Pj4gKmFueSogbmV4dC1wcm90b2NvbCB2YWx1ZXMgd2hlbiBPPTEu DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQW5kIHdoZW4gc3BlY2lmaWVkLi4uDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gQXMgZm9yIHNvLWNhbGxlZCBwaWdneWJhY2sgT0FNLCB3ZSBjb3VsZCBkZWZpbmUgdGhh dCBpZiBPPTENCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhpcyBtaWdodCBiZSB0aGUgc291cmNlIG9mIHRo ZSBjb25mdXNpb24g4oCUIGlmIE89MSwgdGhhdOKAmXMgbm90IGEgDQo+Pj4+Pj4+IGRhdGEgcGFj a2V0LiBUaGUgaWRlYSB3aXRoIHBpZ2d5YmFjayBPQU0gaXMgdG8gZGlzdHVyYiB0aGUgDQo+Pj4+ Pj4+IHBhY2tldCB0aGUgbGVhc3QuIElmIHdlIGZsYWcgYSBkYXRhIHBhY2tldCBhcyBPQU0sIGl0 IHRha2VzIGEgDQo+Pj4+Pj4+IGNvbXBsZXRlbHkgZGlmZmVyZW50IHByb2Nlc3NpbmcgcGF0aC4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gUGlnZ3liYWNrIE9BTSBpcyBhIGRhdGEgcGFja2V0LCBPPTAsIHdp dGggZW1iZWRkZWQgDQo+Pj4+Pj4+IGluc3RydW1lbnRhdGlvbiwgYXMgaW4gZHJhZnQtYnJvY2tu ZXJzLWluYmFuZC1vYW0tdHJhbnNwb3J0Lg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gYW5kIE5leHQgUHJv dG9jb2w9SVB2NCB0aGVyZSBtYXkgYmUgYW4gT0FNIGhlYWRlciBmb2xsb3dpbmcgdGhlIA0KPj4+ Pj4+Pj4gSVB2NCBwYWNrZXQsIGxvY2F0ZWQgdXNpbmcgSVB2NCB0b3RhbCBsZW5ndGgu4oCOIE9y IHdlIGNvdWxkIA0KPj4+Pj4+Pj4gZGVmaW5lIGEgbmV3IG51bWJlciBmb3IgSVB2NC13aXRoLU9B TS10cmFpbGVyLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBTb3JyeSBidXQgdGhlcmUgc2VlbXMgdG8gYmUg YSBsb3Qgb2YgdW5uZWNlc3NhcnkgY29tcGxleGl0eSBpbiB0aGF0Lg0KPj4+Pj4+PiBXaHkgYW4g T0FNIGhlYWRlcj8gV2h5IGEgdHJhaWxlcj8gTz0xIHdpdGggSVB2NCwgdG8gbWUsIG1lYW5zIGFu IA0KPj4+Pj4+PiBPQU0gcGFja2V0IGluIElQdjQgKGFzIGZvciBleGFtcGxlIGFuIElDTVB2NCBw YWNrZXQsIG9yIGZvciANCj4+Pj4+Pj4gZXhhbXBsZSBhDQo+Pj4+Pj4+IEJGRG9VRFBvSVB2NCBw YWNrZXQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4NCj4+Pj4+Pj4g4oCUIENh cmxvcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBOb3RlIHRoYXQgZm9yIE5leHQgUHJv dG9jb2wgb2YgTVBMUywgRXRoZXJuZXQgb3IgTlNILCB0aGVzZSBkbyANCj4+Pj4+Pj4+IG5vdCBo YXZlIHRvdGFsLWxlbmd0aCBmaWVsZHMgdGhhdCB3b3VsZCBhbGxvdyB0cmFpbGluZyBPQU0uDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRnVydGhlcm1vcmUsIHdlIGNvdWxkIHNheSB0aGF0IGlmIE89MSwg dGhlIFNGRiBNVVNUIGRldGVybWluZSANCj4+Pj4+Pj4+IGlmIHRoZSBwYXlsb2FkIGlzIGFkZHJl c3NlZCB0byBpdCwgZS5nLiwgaWYgdGhlIG5leHQgSVB2NiANCj4+Pj4+Pj4+IHBhY2tldCBpcyBh ZGRyZXNzZWQgdG8gdGhlIFNGRidzIGxvb3AtYmFjayBhZGRyZXNzLg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+IEkgdGhpbmsgbWFueSBvZiB1cyBhcmUgYW54aW91cyB0byBnZXQgdG8gd29yayBjbGFyaWZ5 aW5nIHRoZXNlIA0KPj4+Pj4+Pj4gdGhpbmdzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IC1EYXZlDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT3JpZ2luYWwgTWVzc2FnZQ0KPj4+Pj4+Pj4gRnJvbTogSm9lbCBN LiBIYWxwZXJuDQo+Pj4+Pj4+PiBTZW50OiBTYXR1cmRheSwgSnVseSAyMywgMjAxNiA4OjAyIFBN DQo+Pj4+Pj4+PiBUbzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+Pj4+Pj4+PiBDYzog R3JlZ29yeSBNaXJza3k7IHJ0Zy1vb2FtLWR0QGlldGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4+Pj4+ Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBbUnRnLW9vYW0tZHRdIElkZW50aWZ5aW5nIE9BTSBpbiBO U0gNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQ2FybG9zLA0KPj4+Pj4+Pj4gICAgWWVz eCwgSSBhbSB0YWxraW5nIGFib3V0IHRoZSBzYW1lIGNhc2UgdGhhdCBvdGhlciBmb2xrcyBhcmUg DQo+Pj4+Pj4+PiBjYWxsaW5nIHBpZ2d5LWJhY2sgT0FNLiAgSSB3YW50ZWQgdG8gZGVzY3JpYmUg dGhlIGNhc2UgaW5zdGVhZCANCj4+Pj4+Pj4+IG9mIG5hbWluZyBpdCwgYm90aCBmb3IgY2xhcml0 eSBhbmQgdG8gcmFpc2UgdGhlIHBvaW50IGFib3V0IHdobyANCj4+Pj4+Pj4+IG5lZWRzIHRvIHBy b2Nlc3MgdGhlIE9BTSBpbmZvcm1hdGlvbi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBZb3UgYXNrIGhv dyB0aGUgU0YgKG9yIGV2ZW4gaWYgdGhlIFNGRiBpZiB0aGF0IGFwcGxpZXNfIHdpbGwgDQo+Pj4+ Pj4+PiBrbm93IHRoZXJlIGlzIGEgdXNlciBwYWNrZXQuICBJIHRoaW5rIHRoZSBwcm9wb3NhbCBp cyB0byB1c2UgDQo+Pj4+Pj4+PiB0aGUgT0FNIGJpdCBzcGVjaWZpY2FsbHkgdG8gaW5kaWNhdGUg dGhhdC4NCj4+Pj4+Pj4+IFRoZSByZXN1bHQgb2YgdGhhdCB1c2FnZSBpcyB0aGF0IHRoZSBTRkYg bmVlZHMgdG8gY2hlY2sgdGhlIA0KPj4+Pj4+Pj4gcGFja2V0IHR5cGUgaW4gb3JkZXIgdG8gcmVj b2duaXplIE9BTSBwYWNrZXRzIHRoYXQgYXJlIG5vdCB1c2VyIA0KPj4+Pj4+Pj4gZGF0YSBwYWNr ZXRzIGFuZCB0aGF0IGl0IG5lZWRzIHRvIHByb2Nlc3MuDQo+Pj4+Pj4+PiBUaGF0IGlzIGFuIHVu Zm9ydHVuYXRlIGNvbXBsZXhpdHkgaW4gYSBjcml0aWNhbCBwcm9jZXNzaW5nIHBhdGguDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gSSBzdXNwZWN0IGl0IGlzIHRoaXMgZWZmaWNpZW5jeSB0aGF0IGlzIGRy aXZpbmcgeW91Lg0KPj4+Pj4+Pj4gV2hpY2ggc3VnZ2VzdHMgYW5vdGhlciBwb3NzaWJsZSBpbnRl cnByZXRhdGlvbi4NCj4+Pj4+Pj4+IFdoYXQgaWYNCj4+Pj4+Pj4+IDEpIHdlIHNldCB0aGUgT0FN IGJpdCBmb3IgYW55IHBhY2tldCB0aGF0IG5lZWRzIE9BTSBwcm9jZXNzaW5nDQo+Pj4+Pj4+PiAy KSBBbmQgZGVmaW5lIGEgKHNldCBvZikgcGFja2V0IHR5cGVzIGZvciBwYWNrZXRzIHdoZXJlIHRo ZSANCj4+Pj4+Pj4+IGNvdG5lbnQgaXMgT0FNDQo+Pj4+Pj4+PiAzKSBBbmQgZGVjbGFyZSB0aGF0 IGFueSBvdGhlciBwYWNrZXQgdHlwZXMgYXJlIHVzZXIgcGFja2V0cyANCj4+Pj4+Pj4+IHdpdGgg T0FNIFRMViBpbmZvcm1hdGlvbi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGlzIGlzIHNsaWdodGx5 IHNpbXBsZXIgaWYgd2UgZGVjbGFyZSBhIHNpbmdsZSBPQU0gcGFja2V0IHR5cGUgDQo+Pj4+Pj4+ PiBpbiB0aGUgTlNIIGhlYWRlciwgYXMgdGhhdCBhdm9pZHMgYW55IGFtYmlndWl0eS4gIChXaGV0 aGVyIHRoZSANCj4+Pj4+Pj4+IGRldmljZSBjYW4gYWN0dWFsbHkgZG8gdGhlIE9BTSBzdGlsbCBk ZXBlbmRzIHVwb24gaXQgDQo+Pj4+Pj4+PiB1bmRlcnN0YW5kaW5nIHRoZSBPQU0gcGFja2V0cywg YnV0IHRoYXQgaXMgdHJ1ZSBvZiBhbGwgDQo+Pj4+Pj4+PiBzdHJ1Y3R1cmVzLikgIFRoaXMgZG9l cyBhdm9pZCBjcmVhdGluZyBhbnkgY29uZnVzaW9uIGJldHdlZW4gDQo+Pj4+Pj4+PiB0aGUgdXNl IG9mIHRoZSBPQU0gZmxhZyBhbmQgdGhlIHBhY2tldCB0eXBlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IFlvdXJzLA0KPj4+Pj4+Pj4gSm9lbA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIDcvMjMvMTYgNzoz NCBQTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIHdyb3RlOg0KPj4+Pj4+Pj4+IEhpLCBK b2VsLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE9uIEp1bCAyMywgMjAxNiwgYXQgNzo0NSBQTSwg Sm9lbCBNLiBIYWxwZXJuIA0KPj4+Pj4+Pj4+PiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+Pj4+ Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRoZXJlIGlzIG9uZSBzaXR1YXRp b24gdGhhdCBmb2xrcyBhcmUgYXNraW5nIGZvciB0aGF0IHNlZW1zIA0KPj4+Pj4+Pj4+PiBub3Qg dG8gYmUgY2xlYXJseSBjb3ZlcmVkIGluIHRoZSBzcGVjLCBhbmQgYXBwZWFycyB0byBtZSB0byAN Cj4+Pj4+Pj4+Pj4gYmUgY2xhcmlmaWVkIGJ5IEdyZWcncyBwcm9wb3NhbC4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4gV2UgaGF2ZSBoYWQgYSBjb3VwbGUgb2YgcmVxdWVzdHMgZm9yIHRoZSBhYmls aXR5IHRvIHB1dCBPQU0gDQo+Pj4+Pj4+Pj4+IG1hcmtpbmcgb24gdXNlciBkYXRhIHBhY2tldHMu ICBUaGUgbW9zdCBvYnZpb3VzIHVzZSBpcyB0byANCj4+Pj4+Pj4+Pj4gbW9uaXRvciBob3cgbG9u ZyBpdCB0YWtlcyBOU0gtYXdhcmUgc2VydmljZSBmdW5jdGlvbnMgdG8gDQo+Pj4+Pj4+Pj4+IHBy b2Nlc3MgdGhlIHVzZXIgcGFja2V0cy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ IEp1c3QgdG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZCwgeW91IGFyZSB0YWxraW5nIGFib3V0IHRo ZSBjYXNlIA0KPj4+Pj4+Pj4+IG9mIOKAnHBpZ2d5LWJhY2sgT0FN4oCdLCBjb3JyZWN0Pw0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IElmIHRoZSBvbmx5IGNhc2Ugd2hlcmUgd2Ugd2lsbCBuZWVkIHRo aXMgaXMgZm9yIHNlcnZpY2UgDQo+Pj4+Pj4+Pj4+IGZ1bmN0aW9uIHByb2Nlc3NpbmcsIHRoZSBw dXR0aW5nIGl0IGluIHRoZSBUTFZzLCB3aXRob3V0IA0KPj4+Pj4+Pj4+PiBhZGRpdGlvbmFsIG1h cmtpbmdzLCBhbmQgYWxsb3dpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHdoaWNoIA0KPj4+Pj4+ Pj4+PiB1bmRlcnN0YW5kIHRoZSBUTFYgdG8gd29yayB3aXRoIGl0IHNlZW1zIHN1ZmZpY2llbnQu DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEJ1dCBpdCBpcyBub3QgY2xlYXIgdG8gbWUgdGhhdCB0 aGVyZSBpcyBub3QgYSBkZXNpcmUgKHdoZXRoZXIgDQo+Pj4+Pj4+Pj4+IGl0IGlzIGEgcmVxdWly ZW1lbnQgaXMgcHJvYmFibHkgYW4gaW1wb3J0YW50IG9wZW4gcXVlc3Rpb24pIA0KPj4+Pj4+Pj4+ PiBmb3Igc2ltaWxhciBjYXBhYmlsaXR5IGF0IFNGRi4gIElmIHdlIGhhdmUgc2l0dWF0aW9ucyB3 aGVyZSANCj4+Pj4+Pj4+Pj4gU0ZGLCBpbiBwYXNzaW5nIHVzZXIgZGF0YSBwYWNrZXRzLCBhbHNv IG5lZWQgdG8gcGVyZm9ybSBPQU0gDQo+Pj4+Pj4+Pj4+IG9wZXJhdGlvbnMsIHRoZW4gaXQgc2Vl bXMgdG8gbWUgdGhhdCB3ZSBuZWVkIHRoZSBPQU0gYml0IHRvIA0KPj4+Pj4+Pj4+PiB0ZWxsIHRo ZSBTRkYgdG8gbG9vayBhdCB0aGlzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSWYgeW91IHNldCB0 aGUgTyBiaXQgaW4gYSB1c2VyIGRhdGEgcGFja2V0LCBob3cgd291bGQgYSBzeXN0ZW0gDQo+Pj4+ Pj4+Pj4gaW5mZXIgdGhhdOKAmXMgbm90IGFuIE9BTSBwYWNrZXQ/DQo+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiDigJQgQ2FybG9zLg0KPj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+IEVmZm9ydHMgd2l0aCByb3V0ZXJzIHRvIGRvIHRoaXMgd2l0aCByb3V0ZXIg YWxlcnQgb3B0aW9ucyANCj4+Pj4+Pj4+Pj4gaGF2ZSBiZWVuIGEgbWVzcy4gSWYgd2UgbmVlZCB0 aGUgY2FwYWJpbGl0eSwgaXQgc2VlbXMgdG8gbWUgDQo+Pj4+Pj4+Pj4+IHRoYXQgd2UgcmVhbGx5 IHdhbnQgaXQgaW4gYSBzdGFuZGFyZGl6ZWQgYW5kIGVmZmljaWVudCBwbGFjZS4NCj4+Pj4+Pj4+ Pj4gSWYgd2UgYXJlIHZlcnkgc3VyZSB3ZSBkb24ndCBuZWVkIHRoaXMsIHRoZW4gd2Ugc2hvdWxk IHdyaXRlIA0KPj4+Pj4+Pj4+PiB0aGF0IGRvd24sIGFuZCBtb3ZlIG9uLg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+PiBZb3VycywNCj4+Pj4+Pj4+Pj4gSm9lbA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBPbiA3LzIzLzE2IDEyOjI0IFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6 DQo+Pj4+Pj4+Pj4+PiBIaSwgR3JlZywNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gT24gSnVs IDIyLCAyMDE2LCBhdCAxMDoyNCBBTSwgR3JlZ29yeSBNaXJza3kgDQo+Pj4+Pj4+Pj4+Pj4gPGdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSANCj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmdyZWdvcnku bWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4g SGkgQ2FybG9zLA0KPj4+Pj4+Pj4+Pj4+IHRoYW5rIHlvdSBmb3Igc2hhcmluZyB5b3VyIGNvbW1l bnRzLiBJZiBJIHVuZGVyc3RhbmQgDQo+Pj4+Pj4+Pj4+Pj4gY29ycmVjdGx5LCB5b3Ugc3VnZ2Vz dCB0byBleHBvc2UgcHJvdG9jb2wgdHlwZXMgb2YgT0FNIGFzIA0KPj4+Pj4+Pj4+Pj4+IE5leHQg UHJvdG9jb2wgcmF0aGVyIHRoYW4gdG8gdXNlIHNpbmdsZSBBY3RpdmUgT0FNIHByb3RvY29sIA0K Pj4+Pj4+Pj4+Pj4+IHR5cGUgYW5kIHVzZSBPT0FNIEhlYWRlciB0byBkZW11eCBPT0FNIHR5cGUu IFRoZW4sIHRoZSBOZXh0IA0KPj4+Pj4+Pj4+Pj4+IFByb3RvY29sIHJlZ2lzdHJ5IHdpbGwgaGF2 ZSB0byBhbGxvY2F0ZSB2YWx1ZXMgZm9yIA0KPj4+Pj4+Pj4+Pj4+IHNpbmdsZS1ob3AgQkZELCBt dWx0aS1ob3AgQkZELCBtdWx0aXBvaW50IEJGRCwgUy1CRkQsIEVjaG8gDQo+Pj4+Pj4+Pj4+Pj4g UmVxdWVzdC9SZXBseSwgQUlTIHByb3RvY29sLCBBY3RpdmUgUGVyZm9ybWFuY2UgTWVhc3VyZW1l bnQgDQo+Pj4+Pj4+Pj4+Pj4gcHJvdG9jb2wsIGFuZCBJ4oCZdmUgb25seSBsaXN0ZWQgc29tZSBv ZiBBT00gcHJvdG9jb2xzIHRoYXQgDQo+Pj4+Pj4+Pj4+Pj4gbWF5IGJlIHVzZWQgdG8gb3BlcmF0 ZSwgYWRtaW5pc3RlciBhbmQgbWFpbnRhaW4gU0ZQLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ IFllcywgdGhlIHByb3RvY29sIGZpZWxkIG91Z2h0IHRvIHJlZ2lzdGVyIHRoZSBPQU0gcHJvdG9j b2xzIA0KPj4+Pj4+Pj4+Pj4gdGhhdCB3aWxsIGJlIHVzZWQgYW5kIGltcGxlbWVudGVkIGFuZCBk ZXBsb3llZCDigJQgb2YgY291cnNlIA0KPj4+Pj4+Pj4+Pj4gbm90IGFsbCBwb3RlbnRpYWwgdmFy aWF0aW9ucyBhbmQgcGVybXV0YXRpb25zIG9mIHBvc3NpYmxlIA0KPj4+Pj4+Pj4+Pj4gT0FNcyAo d2hhdCBpcyBBSVMNCj4+Pj4+Pj4+Pj4+IHByb3RvY29sPykNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4gQWRkaXRpb25hbGx5LCB5b3XigJl2ZSBzdWdnZXN0ZWQgdGhhdCBvbmx5IE8tYml0IHZh bHVlIHRvIGJlIA0KPj4+Pj4+Pj4+Pj4+IHVzZWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgcGFja2V0 IHNob3VsZCBiZSBwcm9jZXNzZWQgYXMgT0FNIA0KPj4+Pj4+Pj4+Pj4+IG9yIGRhdGEgcGFja2V0 Lg0KPj4+Pj4+Pj4+Pj4+IEhlbmNlIHNob3VsZCBJIGV4cGVjdCB0aGF0IE8tYml0IGlzIHNldCBm b3IgQkZELCBBSVMsIGFuZCANCj4+Pj4+Pj4+Pj4+PiBFY2hvIFJlcXVlc3QvUmVwbHkgcGF5bG9h ZCBhbmQgc2hvdWxkIG5vdCBiZSBzZXQgaWYgdGhlIA0KPj4+Pj4+Pj4+Pj4+IE5leHQgUHJvdG9j b2wgaXMgbmVpdGhlciBvZiBwcm90b2NvbHMgbGlzdGVkIGFib3ZlPyBTaG91bGQgDQo+Pj4+Pj4+ Pj4+Pj4gc3VjaCBzaXR1YXRpb24sIGkuZS4NCj4+Pj4+Pj4+Pj4+PiBOZXh0DQo+Pj4+Pj4+Pj4+ Pj4gUHJvdG9jb2wgdmFsdWUgaXMgTVBMUyBhbmQgTy1iaXQgc2V0IHRvIDB4MSwgc2hvdWxkIGJl IA0KPj4+Pj4+Pj4+Pj4+IHZpZXdlZCBhcyBlcnJvciBhbmQgdGhlIHBhY2tldCBkcm9wcGVkPyBP ciB5b3UgcHJvcG9zZSB0aGF0IA0KPj4+Pj4+Pj4+Pj4+IHRoZSBOZXh0IFByb3RvY29sIHRha2Vz IHByZWNlZGVuY2UgYW5kIHRoZSBwYWNrZXQgdHJlYXRlZCANCj4+Pj4+Pj4+Pj4+PiBhcyBkYXRh PyBPciBwYWNrZXQgdmlld2VkIGFzIE9BTSBhbmQgcGFzc2VkIHRvIHRoZSBsb2NhbCANCj4+Pj4+ Pj4+Pj4+PiBPQU0gZW50aXR5PyBPciBob3cgdG8gaW50ZXJwcmV0IHNpdHVhdGlvbiB3aGVuIE8t Yml0IGlzIA0KPj4+Pj4+Pj4+Pj4+IGNsZWFyZWQgYW5kIHRoZSBOZXh0IFByb3RvY29sIHZhbHVl IGlzIG9uZSBvZiBPQU0gDQo+Pj4+Pj4+Pj4+Pj4gcHJvdG9jb2xzPw0KPj4+Pj4+Pj4+Pj4+IFRo aXMgaXMgdGhlIHNpdHVhdGlvbiB0aGF0LCBpbiBteSB2aWV3LCBpcyBhbWJpZ3VvdXMgYW5kIA0K Pj4+Pj4+Pj4+Pj4+IHVuZGVyLXNwZWNpZmllZCBpbiB0aGUgY3VycmVudCBOU0ggZG9jdW1lbnQu IE15IHByb3Bvc2FsIGlzIA0KPj4+Pj4+Pj4+Pj4+IGFuIGF0dGVtcHQgdG8gbWFrZSByZWxhdGlv bnNoaXAgYmV0d2VlbiBPQU0gYW5kIGRhdGEgDQo+Pj4+Pj4+Pj4+Pj4gcGFja2V0cyBtb3JlIGRl dGVybWluaXN0aWMuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQW5zd2VyaW5nIGFsbCB0aG9z ZSBxdWVzdGlvbnMgKHdoaWNoIGFyZSByZWFsbHkgc2xpZ2h0IA0KPj4+Pj4+Pj4+Pj4gcGVybXV0 YXRpb25zIG9mIHRoZSBzYW1lIHF1ZXN0aW9uKSBpbiBvbmUgc2hvdDogdG8gbWUsIE89MCANCj4+ Pj4+Pj4+Pj4+IGlzIGEgZGF0YSBwYWNrZXQgYW5kDQo+Pj4+Pj4+Pj4+PiBPPTEgaXMNCj4+Pj4+ Pj4+Pj4+IGFuIE9BTSBwYWNrZXQuIElmIHRoZSBkYXRhIHByb2Nlc3NpbmcgZG9lcyBub3QgaGF2 ZSBhIA0KPj4+Pj4+Pj4+Pj4gaGFuZGxlciBmb3IgdGhlIHByb3RvY29sIGluIHRoZSBQSUQsIG9y IGl04oCZcyBhbiB1bmRlZmluZWQsIA0KPj4+Pj4+Pj4+Pj4gZHJvcHMgdG8gdGhlIGJpdCBidWNr ZXQuDQo+Pj4+Pj4+Pj4+PiBFcXVhbGx5LCBpZiB0aGUgT0FNIGhhbmRsZXIgZG9lcyBub3Qgc3Vw cG9ydCB0aGUgcHJvdG9jb2wgSUQgDQo+Pj4+Pj4+Pj4+PiBjYXJyaWVkIGFzIE9BTSwgcHVmZi4g SVAgY2FuIGNhcnJ5IGRhdGEgb3IgT0FNIGZvciBleGFtcGxlIA0KPj4+Pj4+Pj4+Pj4gYnkgdGhl IHdheS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBJdCBkb2VzIG5vdCBnZXQgYW55IHNpbXBs ZXIgYW5kIHVuYW1iaWd1b3VzIHRoYW4gdGhhdC4gDQo+Pj4+Pj4+Pj4+PiBXaGF04oCZcyB0aGUg YWR2YW50YWdlIG9mIG1vdmluZyB0aGUgT0FNIFBJRCBmdXJ0aGVyIGluc2lkZT8NCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiBBbmQgSSBkbyBub3QgYmVsaWV2ZSB0aGVyZeKAmXMgdW5kZXJzcGVj aWZpY2F0aW9uIGluIE5TSCAtPiANCj4+Pj4+Pj4+Pj4+IE89MSwgT0FNIHRyZWF0bWVudCwgbm90 IGRldGFpbGVkIGhlcmUuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IOKAlCBDYXJsb3MuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgIFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAq RnJvbToqIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSANCj4+Pj4+Pj4+Pj4+PiBbbWFpbHRv OmNwaWduYXRhQGNpc2NvLmNvbV0NCj4+Pj4+Pj4+Pj4+PiAqU2VudDoqIEZyaWRheSwgSnVseSAy MiwgMjAxNiAxMDoxMCBBTQ0KPj4+Pj4+Pj4+Pj4+ICpUbzoqIEdyZWdvcnkgTWlyc2t5IDxncmVn b3J5Lm1pcnNreUBlcmljc3Nvbi5jb20gDQo+Pj4+Pj4+Pj4+Pj4gPG1haWx0bzpncmVnb3J5Lm1p cnNreUBlcmljc3Nvbi5jb20+Pg0KPj4+Pj4+Pj4+Pj4+ICpDYzoqIHNmY0BpZXRmLm9yZyA8bWFp bHRvOnNmY0BpZXRmLm9yZz47IA0KPj4+Pj4+Pj4+Pj4+IHJ0Zy1vb2FtLWR0QGlldGYub3JnIDxt YWlsdG86cnRnLW9vYW0tZHRAaWV0Zi5vcmc+DQo+Pj4+Pj4+Pj4+Pj4gKlN1YmplY3Q6KiBSZTog W1J0Zy1vb2FtLWR0XSBJZGVudGlmeWluZyBPQU0gaW4gTlNIDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+PiBHcmVnLA0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBQ bGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGlubGluZS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+IFRodW1iIHR5cGVkIGJ5IENhcmxvcyBQaWduYXRhcm8uDQo+Pj4+Pj4+Pj4+Pj4gRXhjdXpl IHR5cG9mcmFwaGljYWsgZXJyb3dzDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+IE9uIEp1bCAyMSwgMjAxNiwgYXQgMDk6MDEsIEdyZWdvcnkgTWlyc2t5IA0KPj4+Pj4+ Pj4+Pj4+IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20gDQo+Pj4+Pj4+Pj4+Pj4gPG1haWx0 bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+ICBEZWFyIEFsbCwNCj4+Pj4+Pj4+Pj4+PiAgd2UgaGFkIHZlcnkgZ29vZCBkaXNj dXNzaW9uIG9uIE9BTSB0aGlzIHdlZWsuIFdl4oCZdmUgDQo+Pj4+Pj4+Pj4+Pj4gdG91Y2hlZCBv biAgQWN0aXZlLCBQYXNzaXZlIGFuZCBTb21ldGhpbmctaW4tYmV0d2VlbiBPQU0uIA0KPj4+Pj4+ Pj4+Pj4+IEJ1dCBjYW4gTlNIIGluZGljYXRlICB3aGljaCBPQU0gdHlwZSwgaWYgYW55LCBhc3Nv Y2lhdGVkIA0KPj4+Pj4+Pj4+Pj4+IHdpdGggYSBwYWNrZXQ/IEkgdGhpbmsgdGhhdCB0aGUgIGN1 cnJlbnQgdmVyc2lvbiBvZiANCj4+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLXNmYy1uc2ggZG9lcyBu b3QgYWxsb3cgdGhhdCBhbmQgbWF5ICBiZSANCj4+Pj4+Pj4+Pj4+PiBhbWJpZ3VvdXMgaW4gc29t ZSBjYXNlcy4gSSBwcm9wb3NlIGNoYW5nZSB0byBpbnRlcnByZXRhdGlvbiANCj4+Pj4+Pj4+Pj4+ PiBhbmQgIGFwcGxpY2FiaWxpdHkgZGVzY3JpcHRpb24gb2YgdGhlIE8oQU0pIGZsYWcgYW5kIA0K Pj4+Pj4+Pj4+Pj4+IGFsbG9jYXRpb24gb2YgdGhlICBuZXcgcHJvdG9jb2wgdHlwZSB0byBiZSB1 c2VkIGluIHRoZSBOZXh0IA0KPj4+Pj4+Pj4+Pj4+IFByb3RvY29sIGZpZWxkLg0KPj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEFjdGl2ZSwgcGFz c2l2ZSBhbmQgc29tZXRoaW5nLWluLWJldHdlZW4gYXJlIG5vdCBPQU0gDQo+Pj4+Pj4+Pj4+Pj4g cHJvdG9jb2wgdHlwZXMgYnV0IHJhdGhlciB0aGV5IGFyZSBtZWFzdXJpbmcgbWV0aG9kcy4gDQo+ Pj4+Pj4+Pj4+Pj4gQWN0aXZlIE9BTSBjYW4gaW5jbHVkZSBhIHBsdXJhbGl0eSBvZiBPQU0gcHJv dG9jb2xzLCANCj4+Pj4+Pj4+Pj4+PiBpbmNsdWRpbmcgQkZELCBTLUJGRCwgc29tZXRoaW5nLW92 ZXItaXAsIGV0Yy4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEkgYWxzbyBiZWxpZXZlIHRo YXQgdGhlIGN1cnJlbnQgT0FNIHRleHQgaW4gTlNIIGlzIG5vdCANCj4+Pj4+Pj4+Pj4+PiBhbWJp Z3VvdXMgYW5kIGFsbG93cyBlbm91Z2ggcHJvY2Vzc2luZyBvZiB0aGUgaGVhZGVyIHRvIA0KPj4+ Pj4+Pj4+Pj4+IHVuZGVyc3RhbmQgc29tZXRoaW5nIGlzIE9BTSwgd2l0aG91dCBnb2luZyB0aGUg c3BlY2lmaWNzIG9mIA0KPj4+Pj4+Pj4+Pj4+IGFuIE9BTSBoYW5kbGVyLg0KPj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4gVGhlcmVmb3JlLCBJIG9wcG9zZSB0aGlzIGNoYW5nZS4NCj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gIFJGQyA3Nzk5IGRlZmluZXMgQWN0aXZl IE9BTSBhcyBmb2xsb3dpbmc6DQo+Pj4+Pj4+Pj4+Pj4gIEFuIEFjdGl2ZSBNZXRyaWMgb3IgTWV0 aG9kIGRlcGVuZHMgb24gYSBkZWRpY2F0ZWQgDQo+Pj4+Pj4+Pj4+Pj4gbWVhc3VyZW1lbnQgIHBh Y2tldCBzdHJlYW0gYW5kIG9ic2VydmF0aW9ucyBvZiB0aGUgc3RyZWFtLg0KPj4+Pj4+Pj4+Pj4+ ICBUaHVzLCByZWdhcmRsZXNzIG9mIGVuY2Fwc3VsYXRpb24gdXNlZCBieSBPQU0sIGl0IGlzIHRo ZSANCj4+Pj4+Pj4+Pj4+PiBwYWNrZXQgIGNvbnN0cnVjdGVkIHNvbGVseSBmb3IgbW9uaXRvcmlu ZywgbWVhc3VyaW5nIA0KPj4+Pj4+Pj4+Pj4+IG5ldHdvcmvigJlzIG1ldHJpYyBhbmQgIHNob3Vs ZCBub3QgbGVhdmUgZ2l2ZW4gZG9tYWluLiBBbmQsIEkgDQo+Pj4+Pj4+Pj4+Pj4gYmVsaWV2ZSwg c3VjaCBwYWNrZXRzIHNob3VsZCAgYmUgaWRlbnRpZmllZCBieSB0aGUgcHJvdG9jb2wgDQo+Pj4+ Pj4+Pj4+Pj4gdHlwZSBvZiB0aGVpciBvd24uDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+IFNlZW1zIHlvdSBhcmUgYWR2b2NhdGluZyBmb3IgYSBzaW5nbGUgIk9BTSIg cHJvdG9jb2wgdHlwZSANCj4+Pj4+Pj4+Pj4+PiBmb3IgT0FNIHBhY2tldHMuIFRoZSBmdW5jdGlv bmFsaXR5IG9mIGlkZW50aWZ5aW5nIHNvbWV0aGluZyANCj4+Pj4+Pj4+Pj4+PiBhcyBPQU0gaXMg aW4gdGhlIE8tYml0LCBzbyBubyBuZWVkIHRvIHdhc3RlIGJpdHMgaW4gDQo+Pj4+Pj4+Pj4+Pj4g ZHVwbGljYXRpb24uDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBUaGVuLCBhdCBzb21lIHBv aW50LCB5b3UgaGF2ZSB0byBkaWZmZXJlbnRpYXRlIGlmIGFuIE9BTSANCj4+Pj4+Pj4+Pj4+PiBp cywgc2F5LCBJUCBvciAicmF3IEJGRCIgb3Igc29tZXRoaW5nIGVsc2UuIFRoYXQncyB3aGF0IHRo ZSANCj4+Pj4+Pj4+Pj4+PiBQcm90b2NvbCBmaWVsZCBpcyBmb3IuDQo+Pj4+Pj4+Pj4+Pj4gSSBk byBub3Qgc2VlIGEgbmVlZCB0byBhZGQgYW4gaW5kaXJlY3Rpb24gaGVyZSB0byB0aGVuIGhhdmUg DQo+Pj4+Pj4+Pj4+Pj4gdG8gaGF2ZSBhIHByb3RvY29sIGZpZWxkIGluc2lkZSB0aGUgT0FNLg0K Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAgT0FNIHdoaWNoIGJlaGF2 ZXMgYXMgbXVjaCBhcyBQYXNzaXZlIE9BTSBvciANCj4+Pj4+Pj4+Pj4+PiBTb21ldGhpbmctaW4t YmV0d2VlbiwgIGUuZy4gT0FNIGFwcGVuZGVkIHRvIGRhdGEgcGFja2V0IA0KPj4+Pj4+Pj4+Pj4+ IGVpdGhlciBhdCB0aGUgZG9tYWlu4oCZcyBlZGdlIG9yICBvbi10aGUtZmx5LCBpZGVudGlmaWVk IGJ5IA0KPj4+Pj4+Pj4+Pj4+IHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBkYXRhIHBhY2tldCAg Y2FycmllZCBpbiBOU0guDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ IFRoYXQncyBjb3JyZWN0LCB3aXRoIHRoZSBPIGJpdCBjbGVhcmVkOyBpdCdzIGEgZGF0YSBwYWNr ZXQgDQo+Pj4+Pj4+Pj4+Pj4gYW5kIG5vdCBhbiBPQU0gb25lLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAgQmVsb3cgYXJlIGNoYW5nZXMgSeKAmWQgbGlrZSB0byBw cm9wb3NlOg0KPj4+Pj4+Pj4+Pj4+ICBTZWN0aW9uIDMuMiBPLWJpdDoNCj4+Pj4+Pj4+Pj4+PiAg T0xEDQo+Pj4+Pj4+Pj4+Pj4gICAgIE8gYml0OiB3aGVuIHNldCB0byAweDEgaW5kaWNhdGVzIHRo YXQgdGhpcyBwYWNrZXQgaXMgYW4gDQo+Pj4+Pj4+Pj4+Pj4gT3BlcmF0aW9ucywNCj4+Pj4+Pj4+ Pj4+PiAgICAgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50ZW5hbmNlIChPQU0pIG1lc3NhZ2UuICBU aGUgDQo+Pj4+Pj4+Pj4+Pj4gcmVjZWl2aW5nICBTRkYgYW5kDQo+Pj4+Pj4+Pj4+Pj4gICAgIFNG cyBub2RlcyBNVVNUIGV4YW1pbmUgdGhlIHBheWxvYWQgYW5kIHRha2UgYXBwcm9wcmlhdGUgDQo+ Pj4+Pj4+Pj4+Pj4gYWN0aW9uICAoZS5nLg0KPj4+Pj4+Pj4+Pj4+ICAgICByZXR1cm4gc3RhdHVz IGluZm9ybWF0aW9uKS4gIE9BTSBtZXNzYWdlIHNwZWNpZmljcyBhbmQgDQo+Pj4+Pj4+Pj4+Pj4g aGFuZGxpbmcNCj4+Pj4+Pj4+Pj4+PiAgICAgZGV0YWlscyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4NCj4+Pj4+Pj4+Pj4+PiAgRU5EDQo+Pj4+Pj4+Pj4+Pj4gIE5FVw0K Pj4+Pj4+Pj4+Pj4+ICBPIGJpdDogd2hlbiBzZXQgdG8gMHgxIGluZGljYXRlcyB0aGF0IGRhdGEg cGFja2V0IA0KPj4+Pj4+Pj4+Pj4+IGlkZW50aWZpZWQgYnkgIHRoZSBOZXh0ICBQcm90b2NvbCB0 eXBlIGhhcyBPQU0gbWV0YWRhdGEgDQo+Pj4+Pj4+Pj4+Pj4gYXBwZW5kZWQuDQo+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IE5vLiBJZiBpdCBpcyBhIGRhdGEgcGFja2V0 IGl0IGRvZXMgbm90IGhhdmUgdGhlIE8gYml0IHNldCANCj4+Pj4+Pj4+Pj4+PiAodG8gMSBvciB0 byB3aGljaGV2ZXIgb3RoZXIgcG9zc2libGUgdmFsdWUgZm9yIHRoZSBiaXQgOi0pDQo+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBUaGUgZ29hbCBpcyB0aGF0IGxvb2tpbmcgYXQgYSBzaW5nbGUg YnV0IGl0IGNhbiBiZSANCj4+Pj4+Pj4+Pj4+PiB1bmRlcnN0b29kIGlmIGl0IGlzIGEgZGF0YSBw YWNrZXQgKHdoaWNoIGNhbiBiZSB1c2VkLCANCj4+Pj4+Pj4+Pj4+PiBtYXJrZWQsIGV0Yy4gdG8g YmUgdXNlZCBmb3IgT0FNIHB1cnBvc2VzLCBvciBub3QpLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4gV2UgZG8gbm90IHdhbnQgT0FNIGRpcmVjdCBleGNlcHRpb24gcHJvY2Vzc2luZyBmb3Ig ZGF0YSANCj4+Pj4+Pj4+Pj4+PiBwYWNrZXRzLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+PiAgRGVmaW5pdGlvbiBvZiB0aGUgZm9ybWF0KHMpICB1c2VkIGJ5IE9BTSBt ZXRhZGF0YSBpcyANCj4+Pj4+Pj4+Pj4+PiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50Lg0KPj4+Pj4+Pj4+Pj4+ICBFTkQNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICBBdCB0 aGUgZW5kIG9mIFNlY3Rpb24gMy4yOg0KPj4+Pj4+Pj4+Pj4+ICBPTEQNCj4+Pj4+Pj4+Pj4+PiAg ICAgVGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgTmV4dCBQcm90b2NvbCB2YWx1ZXM6 DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAgICAgMHgxIDogSVB2NA0KPj4+Pj4+Pj4+Pj4+ ICAgICAweDIgOiBJUHY2DQo+Pj4+Pj4+Pj4+Pj4gICAgIDB4MyA6IEV0aGVybmV0DQo+Pj4+Pj4+ Pj4+Pj4gICAgIDB4NDogTlNIDQo+Pj4+Pj4+Pj4+Pj4gICAgIDB4NTogTVBMUw0KPj4+Pj4+Pj4+ Pj4+ICAgICAweDYtMHhGRDogVW5hc3NpZ25lZA0KPj4+Pj4+Pj4+Pj4+ICAgICAweEZFLTB4RkY6 IEV4cGVyaW1lbnRhbCAgRU5EICBORVcNCj4+Pj4+Pj4+Pj4+PiAgICAgVGhpcyBkcmFmdCBkZWZp bmVzIHRoZSBmb2xsb3dpbmcgTmV4dCBQcm90b2NvbCB2YWx1ZXM6DQo+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+PiAgICAgMHgxIDogSVB2NA0KPj4+Pj4+Pj4+Pj4+ICAgICAweDIgOiBJUHY2DQo+ Pj4+Pj4+Pj4+Pj4gICAgIDB4MyA6IEV0aGVybmV0DQo+Pj4+Pj4+Pj4+Pj4gICAgIDB4NDogTlNI DQo+Pj4+Pj4+Pj4+Pj4gICAgIDB4NTogTVBMUw0KPj4+Pj4+Pj4+Pj4+ICAgICAweDY6IEFjdGl2 ZSBPQU0NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gQXMgcGVyIGFi b3ZlIEkgZG8gbm90IGJlbGlldmUgdGhlcmUncyBhIHNpbmdsZSBPQU0gcHJvdG9jb2wuDQo+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICAgICAweDctMHhGRDogVW5hc3Np Z25lZA0KPj4+Pj4+Pj4+Pj4+ICAgICAweEZFLTB4RkY6IEV4cGVyaW1lbnRhbCAgRU5EDQo+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAgQW5kLCBjb25zZXF1ZW50bHksIHNlY3Rpb24gMTMuMi41 IGluIElBTkEgQ29uc2lkZXJhdGlvbnMgDQo+Pj4+Pj4+Pj4+Pj4gc2VjdGlvbiAgd2lsbCByZXF1 ZXN0IGFsbG9jYXRpb24gb2YgdmFsdWUgMHg2IHRvIGJlIA0KPj4+Pj4+Pj4+Pj4+IGFzc2lnbmVk IHRvIEFjdGl2ZSBPQU0gIHByb3RvY29scy4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICBH cmVhdGx5IGFwcHJlY2lhdGUgeW91ciBjb25zaWRlcmF0aW9uIGFuZCBjb21tZW50cy4NCj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBNeSDigqww LjAyLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4gQ2FybG9zLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+PiAgICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgR3JlZw0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+PiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+Pj4+Pj4+PiAgUnRnLW9vYW0tZHQgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+Pj4g IFJ0Zy1vb2FtLWR0QGlldGYub3JnIDxtYWlsdG86UnRnLW9vYW0tZHRAaWV0Zi5vcmc+ICANCj4+ Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy1vb2Ft LWR0DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+Pj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+PiBzZmNAaWV0Zi5v cmcNCj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4g c2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4NCj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2ZjIG1haWxpbmcg bGlzdA0KPj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFp bGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KDQoNCi0tDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpBbHdheXMgcmVtZW1iZXIgdGhhdCB5b3Ug YXJlIHVuaXF1ZS4uLmp1c3QgbGlrZSBldmVyeW9uZSBlbHNlLi4uDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Wed Aug 10 09:31:03 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993D412D824 for ; Wed, 10 Aug 2016 09:31:01 -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 jdhkM_IFdfHG for ; Wed, 10 Aug 2016 09:30:58 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FE312D823 for ; Wed, 10 Aug 2016 09:30:58 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-0b-57ab5766587e Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 3C.03.02568.6675BA75; Wed, 10 Aug 2016 18:33:42 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0301.000; Wed, 10 Aug 2016 12:28:11 -0400 From: Gregory Mirsky To: "Joel M. Halpern" , "huubatwork@gmail.com" , Loa Andersson , "sfc@ietf.org" Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AdHjGxqUb41VTqTfTwmZE/bgRl5mHQA9utSAAAZMKgAAPUPDAAAE5aOAAAoYKYAAAPZ3gAAQJUhAAxWLFAAABhPNLwASFykAAAMPW4AAADNCgAAFr7IAACfOwYAABZ2EAAAAZqyAAAHHFIAABcJPcA== Date: Wed, 10 Aug 2016 16:28:11 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221AF89BC@eusaamb103.ericsson.se> 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> <291a8452-bdef-e224-c78a-392843cee125@joelhalpern.com> <8f80b912-6c50-db63-d88b-832e497bfcac@joelhalpern.com> In-Reply-To: <8f80b912-6c50-db63-d88b-832e497bfcac@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPlG5a+Opwg1MPZS1mzL7MavHx1Bsm i39z5zBbPHmwld2BxWPnrLvsHkuW/GTyODflO6PHrOltbAEsUVw2Kak5mWWpRfp2CVwZp3b8 YynY1chU8WbBdaYGxje/GLsYOTgkBEwkzq337mLk4hAS2MAoMXFrIwuEs5xRonf6cvYuRk4O NgEjiRcbe9hBEiICMxgl1pz4AJYQFjCXWLFwB5gtImAhsW3uPTaIomWMEhvnHgRLsAioStz4 eJoZxOYV8JVoWd7PBLHiAbvEjH2LwYo4BZwl3u+6zARiMwqISXw/tQbMZhYQl7j1ZD6YLSEg ILFkz3lmCFtU4uXjf6wQtqLEvv7p7CD/MAtoSqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUmYVk 6iyEjllIOmYh6VjAyLKKkaO0uCAnN93IYBMjMEaOSbDp7mC8P93zEKMAB6MSD6+C1KpwIdbE suLK3EOMEhzMSiK854NXhwvxpiRWVqUW5ccXleakFh9ilOZgURLnFXukGC4kkJ5YkpqdmlqQ WgSTZeLglGpgPGg5RaJr235eyfsqyv94GNsMW49IT4vxaZ9ufCigd2qbgehcsQJejXzFtM1r utSvrTb8GPJgZWvK5aRXHs8s6thn9hYr77Xk8/IPZHj+ZwbPz12BjPahJZemR7z7+fzgRpd5 v15OfqEUGyRSytqpxCyfUPzyxtXXGj83vTXXmvxuW3PqVLZfSizFGYmGWsxFxYkAkg5sDo0C AAA= Archived-At: 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: Wed, 10 Aug 2016 16:31:01 -0000 SGkgSm9lbCwNCmluIGRpc2N1c3Npb25zIHdpdGhpbiBPT0FNIERUIHdlJ3ZlIGNvbnNpZGVyZWQg c2VwYXJhdGlvbiBvZiBBY3RpdmUgT0FNIGZvciBTRkMgaW50byBTRlAgT0FNIHRoYXQgaW5jbHVk ZXMgQ2xhc3NpZmllciBhbmQgU0ZGcyBhbmQgU0ZGIHRvIGxvY2FsbHkgbWFwcGVkIFNGIE9BTS4g QW55IG90aGVyIGFjdGl2ZSBPQU0gdGhhdCBpbmNsdWRlcyBTRiwgaW4gbXkgdmlldywgaXMgbW9y ZSBjbGllbnQsIGkuZS4gc2VydmljZSwgT0FNIHRoYW4gb3ZlcmxheSBuZXR3b3JrLCB3aGljaCBp cyB0aGUgc2VydmVyIGxheWVyLCBPQU0uIElmIGFuIE9BTSBjb250cm9sIHBhY2tldCB0cmF2ZXJz ZXMgdGhlIHNlcnZpY2UgcmVwcmVzZW50ZWQgYnkgYW4gU0YsIHRoZW4gd2hhdCByZWFsbHkgd2Fz IG1lYXN1cmVkLCBhZ2FpbiBwZXIgbXkgdW5kZXJzdGFuZGluZywgaXMgdGhlIHNlcnZpY2UgcGVy Zm9ybWFuY2UgaW5jbHVkaW5nIHBlcmZvcm1hbmNlIG9mIHRoZSBwYXJ0aWN1bGFyIFNGQy4gVG8g Y2xlYXIsIHRvIHNlcGFyYXRlIFNlcnZpY2UgT0FNIGZyb20gU0ZDIE9BTSwgd2hlbiB1c2luZyBh Y3RpdmUgT0FNLCB3ZSBuZWVkIHRvIGhhdmUgc2VwYXJhdGUgT0FNIGRvbWFpbnMuDQoNCglSZWdh cmRzLA0KCQlHcmVnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0K U2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTAsIDIwMTYgODowMiBBTQ0KVG86IGh1dWJhdHdvcmtA Z21haWwuY29tOyBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+OyBzZmNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbc2ZjXSBbUnRnLW9vYW0tZHRdIElkZW50aWZ5aW5nIE9BTSBpbiBOU0gNCg0KTGV0 IG1lIHRyeSBwaHJhc2luZyB0aGlzIGRpZmZlcmVudGx5Lg0KDQpBcyBhIGdlbmVyYWwgcnVsZSwg aXQgaXMgY2xlYXIgdGhhdCBvbmUgd2FudHMgbWVhc3VyZW1lbnQgdHJhZmZpYyB0byBzaGFyZSBm YXRlIHdpdGggd2hhdCB5b3Ugd2FudCB0byBtZWFzdXJlLiAgRXZlbiBwdXJlIGNvbm5lY3Rpdml0 eSBjaGVja2luZyBuZWVkcyB0byBzaGFyZSBlbm91Z2ggZmF0ZSB0aGF0IG9uZSBjYW4gcmVhc29u YWJseSBjb25jbHVkZSBmcm9tIHRoZSBPQU0gb2JzZXJ2YXRpb25zIHdoYXQgdGhlIGxpa2VseSBz dGF0dXMgaXMgb2YgdGhlIHVuZGVybHlpbmcgdHJhZmZpYyBjb25uZWN0aXZpdHkuDQoNCkhvd2V2 ZXIsIHRoZSBkaWZmZXJlbmNlcyBpbiBjb25zdHJhaW50cyBtZWFuIHRoYXQgdGhlIGRlZ3JlZSB0 byB3aGljaCB0aGlzIGNhbiBiZSBkb25lIHZhcmllcyBmcm9tIGNhc2UgdG8gY2FzZS4NCkluIHRo ZSBjYXNlIG9mIFNGQywgd2Ugd2FudCB0byB1c2UgdGhlIHNhbWUgU1BJIGFuZCBTSSBmb3IgT0FN IGFzIGZvciByZWd1bGFyIHRyYWZmaWMsIHNpbmNlIHRoYXQgaGVscHMgdXMgaGFlIHRoYXQgY29u ZmlkZW5jZS4NCkFuZCB3aGVyZSB3ZSBjYW4sIGl0IGlzIG5pY2UgdG8gaGF2ZSBPQU0gdHJhZmZp YyB0aGF0IGlzIG9ubHkgcGVydHVyYmVkIGF0IHRoZSBlbmQtcG9pbnRzLg0KSG93ZXZlciB0aGUg bmF0dXJlIG9mIHRoZSBTRkYgYmVoYXZpb3JzLCBhbmQgbW9yZSBpbXBvcnRhbnRseSB0aGUgbmF0 dXJlIG9mIHRoZSBTRiBiZWhhdmlvcnMsIG1lYW4gdGhhdCB0aGVyZSBhcmUgc2VyaW91cyBsaW1p dGF0aW9ucyBvbiB3aGF0IG9uZSBjYW4gZG8gd2l0aCBhY3RpdmUgbWVjaGFuaXNtcyBvZiB0aGlz IHNvcnQuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiA4LzEwLzE2IDEwOjExIEFNLCBIdXViIHZhbiBI ZWx2b29ydCB3cm90ZToNCj4gSGVsbG8gSm9lbCwNCj4NCj4gWW91IHdyb3RlOg0KPg0KPj4gVGhl cmUgYXJlIE9BTSB0YXNrcyB3aGVyZSBvbmx5IHRoZSBlbmQtcG9pbnRzIGFyZSBpbnZvbHZlZC4g IEluIHRoYXQgDQo+PiBjYXNlLCBJIHRoaW5rIHdlIHdvdWxkIGFsbCBsaWtlIHRvIHNlZSBhcyBt dWNoIGZhdGUgc2hhcmluZyB3aXRoIHRoZSANCj4+IG5vcm1hbCBkYXRhIHBhdGggYXMgYSBwb3Nz aWJsZS4NCj4NCj4gQ29ycmVjdCENCj4NCj4+IEJ1dCB0aGVyZSBhcmUgYSBsb3Qgb2YgY2FzZXMg d2hlcmUgdGhhdCBkb2VzIG5vdCBhcHBseS4NCj4NCj4gTm90ZSB0aGF0IGluIHRoZXNlIGNhc2Vz IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgT0FNIHdpbGwgYmUgbWVhc3VyZWQsIA0KPiBhbmQgKk5P VCogdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBwYXlsb2FkLg0KPg0KPj4gU28gd2UgY2FuIG5vdCBz aW1wbHkgdGFrZSB0aGUgcnVsZSBvZiB0aHVtYiB5b3Ugc3VnZ2VzdGVkIGFuZCBydW4gDQo+PiB3 aXRoIGl0Lg0KPg0KPiBXaHkgd291bGQgeW91IG5lZWQgdG8gbWVhc3VyZSB0aGUgcGVyZm9ybWFu Y2Ugb2YgdGhlIE9BTT8NCj4NCj4gQmVzdCByZWdhcmRzLCBIdXViLg0KPg0KPg0KPj4gT24gOC8x MC8xNiA3OjE5IEFNLCBMb2EgQW5kZXJzc29uIHdyb3RlOg0KPj4+IEpvZWwsDQo+Pj4NCj4+PiBZ ZXMgSSBzZWUgdGhlIHByb2JsZW0sIHlvdSBkZXNjcmliZWQgKGhpZ2gtbGV2ZWwpIHdoYXQgaGFw cGVucyBpbiBhbiANCj4+PiBNUExTKC1UUCksIGJ1dCB3b3VsZG4ndCB3ZSBsaW1pdCB0aGUgZGF0 YSBwbGFuZSBtZWFzdXJlbWVudHMgd2UgDQo+Pj4gY291bGQgZG8gaWYgdGhlIE9BTSBhbmQgcGF5 bG9hZCBwYWNrZXRzIGFyZSB0cmVhdGVkIGRpZmZlcmVudGx5IGJ5IA0KPj4+IHRoZSBkYXRhIHBs YW5lPyBXb3VsZCBpdCBiZSBmZWFzaWJsZSB0byBsb29rIGludG8gYSBtZWNoYW5pc20gdGhhdCAN Cj4+PiBvbmx5IGRvIHRoZSBPQU0gdHJlYXRtZW50IGF0IHRoZSBlbmQtcG9pbnRzPw0KPj4+DQo+ Pj4gL0xvYQ0KPj4+DQo+Pj4gT24gMjAxNi0wOC0wOSAxODoxOSwgSm9lbCBNLiBIYWxwZXJuIHdy b3RlOg0KPj4+PiBDbGVhcmx5LCB3ZSB3b3VsZCBsaWtlIGFzIG11Y2ggZmF0ZSBzaGFyaW5nIGFz IHBvc3NpYmxlLg0KPj4+Pg0KPj4+PiBJIGJlbGlldmUgbW9zdCBvZiB0aGUgTVBMUyBPQU0gY2Fz ZXMgd2hlcmUgc3VjaCB0aGF0IGludGVybWVkaWF0ZSANCj4+Pj4gTVBMUyBMU1BzIGRvIG5vdCBo YXZlIHRvIGRvIGFueSBPQU0gcHJvY2Vzc2luZy4NCj4+Pj4NCj4+Pj4gSW4gY29udHJhc3QsIHRo ZXJlIGFyZSBwcm9wb3NlZCBTRkMgT0FNIGJlaGF2aW9ycyB0aGF0IHJlcXVpcmUgDQo+Pj4+IHBy b2Nlc3NpbmcgYXQgaW50ZXJtZWRpYXRlIFNGRi4NCj4+Pj4gTVBMUyB1c2VzIFRUTCBtZWNoYW5p c21zIHRvIGNvdmVyIHRoZSBmZXcgY2FzZXMgd2hlcmUgaXQgbmVlZHMgdGhhdC4NCj4+Pj4gTlNI DQo+Pj4+IGNhbiBub3QgZG8gdGhhdCwgYmVjYXVzZSB0aGUgc2VydmljZSBpbmRleCAod2hpY2gg YWxvcyBwcm92aWRlcyANCj4+Pj4gbG9vcA0KPj4+PiBzdXBwcmVzc2lvbikgaXMgcGFydCBvZiB0 aGUgZm9yd2FyZGluZyBsb2dpYy4gIFNvIGNvbnN0cnVjdGluZyANCj4+Pj4gaW5pdGlhbCBwYWNr ZXRzIHdpdGggZGlmZmVyZW50IFNJcyB3aWxsIGJyZWFrIGZvcndhcmRpbmcuDQo+Pj4+DQo+Pj4+ IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+DQo+Pj4+IE9uIDgvOS8xNiA5OjM2IEFNLCBMb2EgQW5k ZXJzc29uIHdyb3RlOg0KPj4+Pj4gRm9sa3MsDQo+Pj4+Pg0KPj4+Pj4gTWF5YmUgYSBuYWl2ZSBx dWVzdGlvbi4NCj4+Pj4+DQo+Pj4+PiBPbiAyMDE2LTA4LTA5IDE1OjMwLCBKb2VsIE0uIEhhbHBl cm4gd3JvdGU6DQo+Pj4+Pj4gSSB3b3VsZCBub3JtYWxseSBiZSBpbmNsaW5lZCB0byBhZ3JlZSB3 aXRoIHlvdXIgZGVmaW5pdGlvbiBDYXJsb3MuDQo+Pj4+Pj4gSG93ZXZlciwgaWYgdGhlcmUgY2Fu IGJlICJQaWdneWJhY2sgT0FNIiB0aGF0IGhhcyB0byBiZSBwcm9jZXNzZWQgDQo+Pj4+Pj4gYnkg U0ZGLCB0aGVuIHdlIGhhdmUgdG8gbWFrZSB0aGF0IGVmZmljaWVudCBmb3IgdGhlIFNGRiB0byBk ZXRlY3QgDQo+Pj4+Pj4gKHNpbmNlIGl0IGhhcyB0byBjaGVjayBldmVyeSBwYWNrZXQgZm9yIHRo aXMgY2FzZS4NCj4+Pj4+Pg0KPj4+Pj4+IE5vdGUgdGhhdCB0aGUgbWVhbmluZyBvZiB0aGUgT0FN IGJpdCBpcyB3aGF0ZXZlciB3ZSBzYXkgaXQgaXMuDQo+Pj4+Pj4gT25lIGRlZmluaXRpb24gaXMg InRoZSBjYXJyaWVkIHBhY2tldCBpcyBhbiBPQU0gcGFja2V0LiIgIEJ1dCB3ZSANCj4+Pj4+PiBj b3VsZCBhbHNvIGRlZmluZSBpdCBtb3JlIHNpbWlsYXJseSB0byB0aGUgcm91dGVyIGFsZXJ0IGJp dCBhcyBpbiANCj4+Pj4+PiAidGhpcyBwYWNrZXQgbmVlZHMgc3BlY2lhbCBjaGVja2luZyBhdCBl YWNoIFNGRiBhbmQgU0YuIg0KPj4+Pj4NCj4+Pj4+IER1cmluZyB0aGUgZGlzY3Vzc2lvbnMgb24g TVBMUyBPQU0gd2UgaGFkIGFzIGEgcnVsZSBvZiB0aHVtYiwgdGhhdCANCj4+Pj4+IHRoZSByb3V0 ZSBhbmQgcHJvY2Vzc2luZyBvZiBPQU0gcGFja2V0cyBuZWVkIHRvIGJlIHRoZSBzYW1lIGFzIGZv ciANCj4+Pj4+IHBheWxvYWQgcGFja2V0Lg0KPj4+Pj4NCj4+Pj4+IElmIHdlIHBvc3R1bGF0ZSAi bmVlZHMgc3BlY2lhbCBjaGVja2luZyBhdCBlYWNoIFNGRiBhbmQgU0YiIGFyZSB3ZSANCj4+Pj4+ IGFiYW5kb25pbmcgdGhpcyBmb3IgU0ZDPw0KPj4+Pj4NCj4+Pj4+IC9Mb2ENCj4+Pj4+Pg0KPj4+ Pj4+IFlvdXJzLA0KPj4+Pj4+IEpvZWwNCj4+Pj4+Pg0KPj4+Pj4+IE9uIDgvOS8xNiA4OjAzIEFN LCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQo+Pj4+Pj4+IOKAnFBpZ2d5YmFj ayBPQU3igJ0gcGlnZ3liYWNrcyBvbiBhIGRhdGEgcGFja2V0LCBub3QgYW4gT0FNIHBhY2tldC4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pg0KPj4+Pj4+PiDigJQgQ2FybG9zLg0K Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gQXVnIDksIDIwMTYsIGF0IDM6MjUgQU0sIERhdmUgRG9sc29u IDxkZG9sc29uQHNhbmR2aW5lLmNvbT4NCj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+IEkgZ3Vlc3MgdGhlIGNvbmZ1c2lvbiBpcyB0aGF0IHBpZ2d5YmFjayBPQU0gaXMgbm90IHVz aW5nIHRoZSANCj4+Pj4+Pj4+IE9BTSBiaXQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ ICBPcmlnaW5hbCBNZXNzYWdlDQo+Pj4+Pj4+PiBGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGln bmF0YSkNCj4+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCA5LCAyMDE2IDE6MzEgQU0NCj4+ Pj4+Pj4+IFRvOiBEYXZlIERvbHNvbg0KPj4+Pj4+Pj4gQ2M6IEpvZWwgTS4gSGFscGVybjsgR3Jl Z29yeSBNaXJza3k7IHJ0Zy1vb2FtLWR0QGlldGYub3JnOyANCj4+Pj4+Pj4+IHNmY0BpZXRmLm9y Zw0KPj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFtSdGctb29hbS1kdF0gSWRlbnRpZnlpbmcg T0FNIGluIE5TSA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBIaSBEYXZlLA0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+IFdpdGggYXBvbG9naWVzIGZvciB0aGUgbXVjaCBiZWxhdGVkIHJlc3BvbnNl OyBwbGVhc2UgZmluZCBvbmUgDQo+Pj4+Pj4+PiBjbGFyaWZpY2F0aW9uIGlubGluZToNCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4gT24gSnVsIDI0LCAyMDE2LCBhdCAxOjQ0IFBNLCBEYXZlIERvbHNvbiAN Cj4+Pj4+Pj4+PiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+DQo+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+PiBTaG91bGQgdGhlIGRvYyBzYXksDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ PiAgSWYgdGhlIE9BTSBiaXQgTz0wLCB0aGlzIGluZGljYXRlcyB0aGUgU0ZGIE1VU1QgZm9yd2Fy ZCAgdGhlIA0KPj4+Pj4+Pj4+IHBhY2tldCBiYXNlZCBzb2xlbHkgb24gdGhlIFNQSSBhbmQgU0kg ZmllbGRzLCB3aXRob3V0DQo+Pj4+Pj4+Pj4gICByZWdhcmQgdG8gbmV4dCBwcm90b2NvbCBvciBm dXJ0aGVyIHBheWxvYWQgaGVhZGVycy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICBJZiB0aGUgT0FN IGJpdCBPPTEsIHRoaXMgaW5kaWNhdGVzIHRoZSBTRkYg4oCOTVVTVCBOT1QgIHByb2Nlc3MgDQo+ Pj4+Pj4+Pj4gdGhlIHBhY2tldCBzb2xlbHkgYnkgU1BJL1NJIGZvcndhcmRpbmcgYnV0ICBpbnN0 ZWFkIGJ5IHRoZSANCj4+Pj4+Pj4+PiBzZW1hbnRpY3Mgc3BlY2lmaWVkIGJ5IHRoZSDigI5PQU0g IHByb3RvY29sIG5hbWVkIGluIHRoZSBOZXh0IA0KPj4+Pj4+Pj4+IFByb3RvY29sIGZpZWxkLg0K Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSSB0aGluayB0aGVzZSBwYXJhZ3JhcGhzIGdldCB0byB0aGUg b3B0aW1pemF0aW9uIGZvciBTRkZzLCBhbmQgDQo+Pj4+Pj4+Pj4gSSB0aGluayBwcm92aWRlIHBy ZWNpc2UgbGFuZ3VhZ2Ugd2l0aG91dCBkZWZpbmluZyBPQU0gDQo+Pj4+Pj4+Pj4gcHJvdG9jb2xz Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g4oCOV2l0aG91dCBmdXJ0aGVyIGxhbmd1YWdlLCBpdCBp cyBub3Qgc3BlY2lmaWVkIGhvdyB0byBoYW5kbGUgDQo+Pj4+Pj4+Pj4gKmFueSogbmV4dC1wcm90 b2NvbCB2YWx1ZXMgd2hlbiBPPTEuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBBbmQgd2hlbiBzcGVj aWZpZWQuLi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEFzIGZvciBzby1jYWxsZWQgcGlnZ3liYWNr IE9BTSwgd2UgY291bGQgZGVmaW5lIHRoYXQgaWYgTz0xDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhp cyBtaWdodCBiZSB0aGUgc291cmNlIG9mIHRoZSBjb25mdXNpb24g4oCUIGlmIE89MSwgdGhhdOKA mXMgbm90IA0KPj4+Pj4+Pj4gYSBkYXRhIHBhY2tldC4gVGhlIGlkZWEgd2l0aCBwaWdneWJhY2sg T0FNIGlzIHRvIGRpc3R1cmIgdGhlIA0KPj4+Pj4+Pj4gcGFja2V0IHRoZSBsZWFzdC4gSWYgd2Ug ZmxhZyBhIGRhdGEgcGFja2V0IGFzIE9BTSwgaXQgdGFrZXMgYSANCj4+Pj4+Pj4+IGNvbXBsZXRl bHkgZGlmZmVyZW50IHByb2Nlc3NpbmcgcGF0aC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBQaWdneWJh Y2sgT0FNIGlzIGEgZGF0YSBwYWNrZXQsIE89MCwgd2l0aCBlbWJlZGRlZCANCj4+Pj4+Pj4+IGlu c3RydW1lbnRhdGlvbiwgYXMgaW4gZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tdHJhbnNwb3J0 Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBhbmQgTmV4dCBQcm90b2NvbD1JUHY0IHRoZXJlIG1heSBi ZSBhbiBPQU0gaGVhZGVyIGZvbGxvd2luZyANCj4+Pj4+Pj4+PiB0aGUgSVB2NCBwYWNrZXQsIGxv Y2F0ZWQgdXNpbmcgSVB2NCB0b3RhbCBsZW5ndGgu4oCOIE9yIHdlIGNvdWxkIA0KPj4+Pj4+Pj4+ IGRlZmluZSBhIG5ldyBudW1iZXIgZm9yIElQdjQtd2l0aC1PQU0tdHJhaWxlci4NCj4+Pj4+Pj4+ DQo+Pj4+Pj4+PiBTb3JyeSBidXQgdGhlcmUgc2VlbXMgdG8gYmUgYSBsb3Qgb2YgdW5uZWNlc3Nh cnkgY29tcGxleGl0eSBpbiANCj4+Pj4+Pj4+IHRoYXQuDQo+Pj4+Pj4+PiBXaHkgYW4gT0FNIGhl YWRlcj8gV2h5IGEgdHJhaWxlcj8gTz0xIHdpdGggSVB2NCwgdG8gbWUsIG1lYW5zIA0KPj4+Pj4+ Pj4gYW4gT0FNIHBhY2tldCBpbiBJUHY0IChhcyBmb3IgZXhhbXBsZSBhbiBJQ01QdjQgcGFja2V0 LCBvciBmb3IgDQo+Pj4+Pj4+PiBleGFtcGxlIGENCj4+Pj4+Pj4+IEJGRG9VRFBvSVB2NCBwYWNr ZXQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IOKAlCBD YXJsb3MuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gTm90ZSB0aGF0IGZvciBOZXh0 IFByb3RvY29sIG9mIE1QTFMsIEV0aGVybmV0IG9yIE5TSCwgdGhlc2UgZG8gDQo+Pj4+Pj4+Pj4g bm90IGhhdmUgdG90YWwtbGVuZ3RoIGZpZWxkcyB0aGF0IHdvdWxkIGFsbG93IHRyYWlsaW5nIE9B TS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEZ1cnRoZXJtb3JlLCB3ZSBjb3VsZCBzYXkgdGhhdCBp ZiBPPTEsIHRoZSBTRkYgTVVTVCBkZXRlcm1pbmUgDQo+Pj4+Pj4+Pj4gaWYgdGhlIHBheWxvYWQg aXMgYWRkcmVzc2VkIHRvIGl0LCBlLmcuLCBpZiB0aGUgbmV4dCBJUHY2IA0KPj4+Pj4+Pj4+IHBh Y2tldCBpcyBhZGRyZXNzZWQgdG8gdGhlIFNGRidzIGxvb3AtYmFjayBhZGRyZXNzLg0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4gSSB0aGluayBtYW55IG9mIHVzIGFyZSBhbnhpb3VzIHRvIGdldCB0byB3 b3JrIGNsYXJpZnlpbmcgdGhlc2UgDQo+Pj4+Pj4+Pj4gdGhpbmdzLg0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gLURhdmUNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9yaWdpbmFsIE1lc3NhZ2UNCj4+Pj4+ Pj4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4NCj4+Pj4+Pj4+PiBTZW50OiBTYXR1cmRheSwgSnVs eSAyMywgMjAxNiA4OjAyIFBNDQo+Pj4+Pj4+Pj4gVG86IENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKQ0KPj4+Pj4+Pj4+IENjOiBHcmVnb3J5IE1pcnNreTsgcnRnLW9vYW0tZHRAaWV0Zi5vcmc7 IHNmY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBbUnRnLW9vYW0tZHRd IElkZW50aWZ5aW5nIE9BTSBpbiBOU0gNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g Q2FybG9zLA0KPj4+Pj4+Pj4+ICAgIFllc3gsIEkgYW0gdGFsa2luZyBhYm91dCB0aGUgc2FtZSBj YXNlIHRoYXQgb3RoZXIgZm9sa3MgYXJlIA0KPj4+Pj4+Pj4+IGNhbGxpbmcgcGlnZ3ktYmFjayBP QU0uICBJIHdhbnRlZCB0byBkZXNjcmliZSB0aGUgY2FzZSBpbnN0ZWFkIA0KPj4+Pj4+Pj4+IG9m IG5hbWluZyBpdCwgYm90aCBmb3IgY2xhcml0eSBhbmQgdG8gcmFpc2UgdGhlIHBvaW50IGFib3V0 IA0KPj4+Pj4+Pj4+IHdobyBuZWVkcyB0byBwcm9jZXNzIHRoZSBPQU0gaW5mb3JtYXRpb24uDQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBZb3UgYXNrIGhvdyB0aGUgU0YgKG9yIGV2ZW4gaWYgdGhlIFNG RiBpZiB0aGF0IGFwcGxpZXNfIHdpbGwgDQo+Pj4+Pj4+Pj4ga25vdyB0aGVyZSBpcyBhIHVzZXIg cGFja2V0LiAgSSB0aGluayB0aGUgcHJvcG9zYWwgaXMgdG8gdXNlIA0KPj4+Pj4+Pj4+IHRoZSBP QU0gYml0IHNwZWNpZmljYWxseSB0byBpbmRpY2F0ZSB0aGF0Lg0KPj4+Pj4+Pj4+IFRoZSByZXN1 bHQgb2YgdGhhdCB1c2FnZSBpcyB0aGF0IHRoZSBTRkYgbmVlZHMgdG8gY2hlY2sgdGhlIA0KPj4+ Pj4+Pj4+IHBhY2tldCB0eXBlIGluIG9yZGVyIHRvIHJlY29nbml6ZSBPQU0gcGFja2V0cyB0aGF0 IGFyZSBub3QgDQo+Pj4+Pj4+Pj4gdXNlciBkYXRhIHBhY2tldHMgYW5kIHRoYXQgaXQgbmVlZHMg dG8gcHJvY2Vzcy4NCj4+Pj4+Pj4+PiBUaGF0IGlzIGFuIHVuZm9ydHVuYXRlIGNvbXBsZXhpdHkg aW4gYSBjcml0aWNhbCBwcm9jZXNzaW5nIHBhdGguDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIHN1 c3BlY3QgaXQgaXMgdGhpcyBlZmZpY2llbmN5IHRoYXQgaXMgZHJpdmluZyB5b3UuDQo+Pj4+Pj4+ Pj4gV2hpY2ggc3VnZ2VzdHMgYW5vdGhlciBwb3NzaWJsZSBpbnRlcnByZXRhdGlvbi4NCj4+Pj4+ Pj4+PiBXaGF0IGlmDQo+Pj4+Pj4+Pj4gMSkgd2Ugc2V0IHRoZSBPQU0gYml0IGZvciBhbnkgcGFj a2V0IHRoYXQgbmVlZHMgT0FNIHByb2Nlc3NpbmcNCj4+Pj4+Pj4+PiAyKSBBbmQgZGVmaW5lIGEg KHNldCBvZikgcGFja2V0IHR5cGVzIGZvciBwYWNrZXRzIHdoZXJlIHRoZSANCj4+Pj4+Pj4+PiBj b3RuZW50IGlzIE9BTQ0KPj4+Pj4+Pj4+IDMpIEFuZCBkZWNsYXJlIHRoYXQgYW55IG90aGVyIHBh Y2tldCB0eXBlcyBhcmUgdXNlciBwYWNrZXRzIA0KPj4+Pj4+Pj4+IHdpdGggT0FNIFRMViBpbmZv cm1hdGlvbi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoaXMgaXMgc2xpZ2h0bHkgc2ltcGxlciBp ZiB3ZSBkZWNsYXJlIGEgc2luZ2xlIE9BTSBwYWNrZXQgDQo+Pj4+Pj4+Pj4gdHlwZSBpbiB0aGUg TlNIIGhlYWRlciwgYXMgdGhhdCBhdm9pZHMgYW55IGFtYmlndWl0eS4gIA0KPj4+Pj4+Pj4+IChX aGV0aGVyIHRoZSBkZXZpY2UgY2FuIGFjdHVhbGx5IGRvIHRoZSBPQU0gc3RpbGwgZGVwZW5kcyB1 cG9uIA0KPj4+Pj4+Pj4+IGl0IHVuZGVyc3RhbmRpbmcgdGhlIE9BTSBwYWNrZXRzLCBidXQgdGhh dCBpcyB0cnVlIG9mIGFsbCANCj4+Pj4+Pj4+PiBzdHJ1Y3R1cmVzLikgIFRoaXMgZG9lcyBhdm9p ZCBjcmVhdGluZyBhbnkgY29uZnVzaW9uIGJldHdlZW4gDQo+Pj4+Pj4+Pj4gdGhlIHVzZSBvZiB0 aGUgT0FNIGZsYWcgYW5kIHRoZSBwYWNrZXQgdHlwZS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFlv dXJzLA0KPj4+Pj4+Pj4+IEpvZWwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDcvMjMvMTYgNzoz NCBQTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIHdyb3RlOg0KPj4+Pj4+Pj4+PiBIaSwg Sm9lbCwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IE9uIEp1bCAyMywgMjAxNiwgYXQgNzo0NSBQ TSwgSm9lbCBNLiBIYWxwZXJuIA0KPj4+Pj4+Pj4+Pj4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+ Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBUaGVyZSBpcyBvbmUg c2l0dWF0aW9uIHRoYXQgZm9sa3MgYXJlIGFza2luZyBmb3IgdGhhdCBzZWVtcyANCj4+Pj4+Pj4+ Pj4+IG5vdCB0byBiZSBjbGVhcmx5IGNvdmVyZWQgaW4gdGhlIHNwZWMsIGFuZCBhcHBlYXJzIHRv IG1lIHRvIA0KPj4+Pj4+Pj4+Pj4gYmUgY2xhcmlmaWVkIGJ5IEdyZWcncyBwcm9wb3NhbC4NCj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBXZSBoYXZlIGhhZCBhIGNvdXBsZSBvZiByZXF1ZXN0cyBm b3IgdGhlIGFiaWxpdHkgdG8gcHV0IE9BTSANCj4+Pj4+Pj4+Pj4+IG1hcmtpbmcgb24gdXNlciBk YXRhIHBhY2tldHMuICBUaGUgbW9zdCBvYnZpb3VzIHVzZSBpcyB0byANCj4+Pj4+Pj4+Pj4+IG1v bml0b3IgaG93IGxvbmcgaXQgdGFrZXMgTlNILWF3YXJlIHNlcnZpY2UgZnVuY3Rpb25zIHRvIA0K Pj4+Pj4+Pj4+Pj4gcHJvY2VzcyB0aGUgdXNlciBwYWNrZXRzLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSnVzdCB0byBtYWtlIHN1cmUgSSB1bmRlcnN0YW5kLCB5b3UgYXJl IHRhbGtpbmcgYWJvdXQgdGhlIA0KPj4+Pj4+Pj4+PiBjYXNlIG9mIOKAnHBpZ2d5LWJhY2sgT0FN 4oCdLCBjb3JyZWN0Pw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gSWYgdGhlIG9ubHkgY2FzZSB3 aGVyZSB3ZSB3aWxsIG5lZWQgdGhpcyBpcyBmb3Igc2VydmljZSANCj4+Pj4+Pj4+Pj4+IGZ1bmN0 aW9uIHByb2Nlc3NpbmcsIHRoZSBwdXR0aW5nIGl0IGluIHRoZSBUTFZzLCB3aXRob3V0IA0KPj4+ Pj4+Pj4+Pj4gYWRkaXRpb25hbCBtYXJraW5ncywgYW5kIGFsbG93aW5nIHRoZSBzZXJ2aWNlIGZ1 bmN0aW9ucyANCj4+Pj4+Pj4+Pj4+IHdoaWNoIHVuZGVyc3RhbmQgdGhlIFRMViB0byB3b3JrIHdp dGggaXQgc2VlbXMgc3VmZmljaWVudC4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBCdXQgaXQg aXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMgbm90IGEgZGVzaXJlIA0KPj4+Pj4+Pj4+ Pj4gKHdoZXRoZXIgaXQgaXMgYSByZXF1aXJlbWVudCBpcyBwcm9iYWJseSBhbiBpbXBvcnRhbnQg b3BlbiANCj4+Pj4+Pj4+Pj4+IHF1ZXN0aW9uKSBmb3Igc2ltaWxhciBjYXBhYmlsaXR5IGF0IFNG Ri4gIElmIHdlIGhhdmUgDQo+Pj4+Pj4+Pj4+PiBzaXR1YXRpb25zIHdoZXJlIFNGRiwgaW4gcGFz c2luZyB1c2VyIGRhdGEgcGFja2V0cywgYWxzbyANCj4+Pj4+Pj4+Pj4+IG5lZWQgdG8gcGVyZm9y bSBPQU0gb3BlcmF0aW9ucywgdGhlbiBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIA0KPj4+Pj4+Pj4+ Pj4gbmVlZCB0aGUgT0FNIGJpdCB0byB0ZWxsIHRoZSBTRkYgdG8gbG9vayBhdCB0aGlzLg0KPj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBJZiB5b3Ugc2V0IHRoZSBPIGJpdCBpbiBhIHVzZXIgZGF0YSBw YWNrZXQsIGhvdyB3b3VsZCBhIA0KPj4+Pj4+Pj4+PiBzeXN0ZW0gaW5mZXIgdGhhdOKAmXMgbm90 IGFuIE9BTSBwYWNrZXQ/DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4g4oCUIENhcmxvcy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEVmZm9y dHMgd2l0aCByb3V0ZXJzIHRvIGRvIHRoaXMgd2l0aCByb3V0ZXIgYWxlcnQgb3B0aW9ucyANCj4+ Pj4+Pj4+Pj4+IGhhdmUgYmVlbiBhIG1lc3MuIElmIHdlIG5lZWQgdGhlIGNhcGFiaWxpdHksIGl0 IHNlZW1zIHRvIG1lIA0KPj4+Pj4+Pj4+Pj4gdGhhdCB3ZSByZWFsbHkgd2FudCBpdCBpbiBhIHN0 YW5kYXJkaXplZCBhbmQgZWZmaWNpZW50IHBsYWNlLg0KPj4+Pj4+Pj4+Pj4gSWYgd2UgYXJlIHZl cnkgc3VyZSB3ZSBkb24ndCBuZWVkIHRoaXMsIHRoZW4gd2Ugc2hvdWxkIHdyaXRlIA0KPj4+Pj4+ Pj4+Pj4gdGhhdCBkb3duLCBhbmQgbW92ZSBvbi4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBZ b3VycywNCj4+Pj4+Pj4+Pj4+IEpvZWwNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBPbiA3LzIz LzE2IDEyOjI0IFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQo+Pj4+Pj4+ Pj4+Pj4gSGksIEdyZWcsDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gT24gSnVsIDIyLCAy MDE2LCBhdCAxMDoyNCBBTSwgR3JlZ29yeSBNaXJza3kgDQo+Pj4+Pj4+Pj4+Pj4+IDxncmVnb3J5 Lm1pcnNreUBlcmljc3Nvbi5jb20gDQo+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86Z3JlZ29yeS5taXJz a3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IEhp IENhcmxvcywNCj4+Pj4+Pj4+Pj4+Pj4gdGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIgY29tbWVu dHMuIElmIEkgdW5kZXJzdGFuZCANCj4+Pj4+Pj4+Pj4+Pj4gY29ycmVjdGx5LCB5b3Ugc3VnZ2Vz dCB0byBleHBvc2UgcHJvdG9jb2wgdHlwZXMgb2YgT0FNIGFzIA0KPj4+Pj4+Pj4+Pj4+PiBOZXh0 IFByb3RvY29sIHJhdGhlciB0aGFuIHRvIHVzZSBzaW5nbGUgQWN0aXZlIE9BTSANCj4+Pj4+Pj4+ Pj4+Pj4gcHJvdG9jb2wgdHlwZSBhbmQgdXNlIE9PQU0gSGVhZGVyIHRvIGRlbXV4IE9PQU0gdHlw ZS4gDQo+Pj4+Pj4+Pj4+Pj4+IFRoZW4sIHRoZSBOZXh0IFByb3RvY29sIHJlZ2lzdHJ5IHdpbGwg aGF2ZSB0byBhbGxvY2F0ZSANCj4+Pj4+Pj4+Pj4+Pj4gdmFsdWVzIGZvciBzaW5nbGUtaG9wIEJG RCwgbXVsdGktaG9wIEJGRCwgbXVsdGlwb2ludCBCRkQsIA0KPj4+Pj4+Pj4+Pj4+PiBTLUJGRCwg RWNobyBSZXF1ZXN0L1JlcGx5LCBBSVMgcHJvdG9jb2wsIEFjdGl2ZSANCj4+Pj4+Pj4+Pj4+Pj4g UGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgcHJvdG9jb2wsIGFuZCBJ4oCZdmUgb25seSBsaXN0ZWQg DQo+Pj4+Pj4+Pj4+Pj4+IHNvbWUgb2YgQU9NIHByb3RvY29scyB0aGF0IG1heSBiZSB1c2VkIHRv IG9wZXJhdGUsIA0KPj4+Pj4+Pj4+Pj4+PiBhZG1pbmlzdGVyIGFuZCBtYWludGFpbiBTRlAuDQo+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBZZXMsIHRoZSBwcm90b2NvbCBmaWVsZCBvdWdodCB0 byByZWdpc3RlciB0aGUgT0FNIHByb3RvY29scyANCj4+Pj4+Pj4+Pj4+PiB0aGF0IHdpbGwgYmUg dXNlZCBhbmQgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkIOKAlCBvZiBjb3Vyc2UgDQo+Pj4+Pj4+ Pj4+Pj4gbm90IGFsbCBwb3RlbnRpYWwgdmFyaWF0aW9ucyBhbmQgcGVybXV0YXRpb25zIG9mIHBv c3NpYmxlIA0KPj4+Pj4+Pj4+Pj4+IE9BTXMgKHdoYXQgaXMgQUlTDQo+Pj4+Pj4+Pj4+Pj4gcHJv dG9jb2w/KQ0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IEFkZGl0aW9uYWxseSwgeW914oCZ dmUgc3VnZ2VzdGVkIHRoYXQgb25seSBPLWJpdCB2YWx1ZSB0byBiZSANCj4+Pj4+Pj4+Pj4+Pj4g dXNlZCB0byBkZXRlcm1pbmUgd2hldGhlciBwYWNrZXQgc2hvdWxkIGJlIHByb2Nlc3NlZCBhcyAN Cj4+Pj4+Pj4+Pj4+Pj4gT0FNIG9yIGRhdGEgcGFja2V0Lg0KPj4+Pj4+Pj4+Pj4+PiBIZW5jZSBz aG91bGQgSSBleHBlY3QgdGhhdCBPLWJpdCBpcyBzZXQgZm9yIEJGRCwgQUlTLCBhbmQgDQo+Pj4+ Pj4+Pj4+Pj4+IEVjaG8gUmVxdWVzdC9SZXBseSBwYXlsb2FkIGFuZCBzaG91bGQgbm90IGJlIHNl dCBpZiB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+IE5leHQgUHJvdG9jb2wgaXMgbmVpdGhlciBvZiBwcm90 b2NvbHMgbGlzdGVkIGFib3ZlPyBTaG91bGQgDQo+Pj4+Pj4+Pj4+Pj4+IHN1Y2ggc2l0dWF0aW9u LCBpLmUuDQo+Pj4+Pj4+Pj4+Pj4+IE5leHQNCj4+Pj4+Pj4+Pj4+Pj4gUHJvdG9jb2wgdmFsdWUg aXMgTVBMUyBhbmQgTy1iaXQgc2V0IHRvIDB4MSwgc2hvdWxkIGJlIA0KPj4+Pj4+Pj4+Pj4+PiB2 aWV3ZWQgYXMgZXJyb3IgYW5kIHRoZSBwYWNrZXQgZHJvcHBlZD8gT3IgeW91IHByb3Bvc2UgDQo+ Pj4+Pj4+Pj4+Pj4+IHRoYXQgdGhlIE5leHQgUHJvdG9jb2wgdGFrZXMgcHJlY2VkZW5jZSBhbmQg dGhlIHBhY2tldCANCj4+Pj4+Pj4+Pj4+Pj4gdHJlYXRlZCBhcyBkYXRhPyBPciBwYWNrZXQgdmll d2VkIGFzIE9BTSBhbmQgcGFzc2VkIHRvIHRoZSANCj4+Pj4+Pj4+Pj4+Pj4gbG9jYWwgT0FNIGVu dGl0eT8gT3IgaG93IHRvIGludGVycHJldCBzaXR1YXRpb24gd2hlbiBPLWJpdCANCj4+Pj4+Pj4+ Pj4+Pj4gaXMgY2xlYXJlZCBhbmQgdGhlIE5leHQgUHJvdG9jb2wgdmFsdWUgaXMgb25lIG9mIE9B TSANCj4+Pj4+Pj4+Pj4+Pj4gcHJvdG9jb2xzPw0KPj4+Pj4+Pj4+Pj4+PiBUaGlzIGlzIHRoZSBz aXR1YXRpb24gdGhhdCwgaW4gbXkgdmlldywgaXMgYW1iaWd1b3VzIGFuZCANCj4+Pj4+Pj4+Pj4+ Pj4gdW5kZXItc3BlY2lmaWVkIGluIHRoZSBjdXJyZW50IE5TSCBkb2N1bWVudC4gTXkgcHJvcG9z YWwgDQo+Pj4+Pj4+Pj4+Pj4+IGlzIGFuIGF0dGVtcHQgdG8gbWFrZSByZWxhdGlvbnNoaXAgYmV0 d2VlbiBPQU0gYW5kIGRhdGEgDQo+Pj4+Pj4+Pj4+Pj4+IHBhY2tldHMgbW9yZSBkZXRlcm1pbmlz dGljLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gQW5zd2VyaW5nIGFsbCB0aG9zZSBxdWVz dGlvbnMgKHdoaWNoIGFyZSByZWFsbHkgc2xpZ2h0IA0KPj4+Pj4+Pj4+Pj4+IHBlcm11dGF0aW9u cyBvZiB0aGUgc2FtZSBxdWVzdGlvbikgaW4gb25lIHNob3Q6IHRvIG1lLCBPPTAgDQo+Pj4+Pj4+ Pj4+Pj4gaXMgYSBkYXRhIHBhY2tldCBhbmQNCj4+Pj4+Pj4+Pj4+PiBPPTEgaXMNCj4+Pj4+Pj4+ Pj4+PiBhbiBPQU0gcGFja2V0LiBJZiB0aGUgZGF0YSBwcm9jZXNzaW5nIGRvZXMgbm90IGhhdmUg YSANCj4+Pj4+Pj4+Pj4+PiBoYW5kbGVyIGZvciB0aGUgcHJvdG9jb2wgaW4gdGhlIFBJRCwgb3Ig aXTigJlzIGFuIHVuZGVmaW5lZCwgDQo+Pj4+Pj4+Pj4+Pj4gZHJvcHMgdG8gdGhlIGJpdCBidWNr ZXQuDQo+Pj4+Pj4+Pj4+Pj4gRXF1YWxseSwgaWYgdGhlIE9BTSBoYW5kbGVyIGRvZXMgbm90IHN1 cHBvcnQgdGhlIHByb3RvY29sIA0KPj4+Pj4+Pj4+Pj4+IElEIGNhcnJpZWQgYXMgT0FNLCBwdWZm LiBJUCBjYW4gY2FycnkgZGF0YSBvciBPQU0gZm9yIA0KPj4+Pj4+Pj4+Pj4+IGV4YW1wbGUgYnkg dGhlIHdheS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEl0IGRvZXMgbm90IGdldCBhbnkg c2ltcGxlciBhbmQgdW5hbWJpZ3VvdXMgdGhhbiB0aGF0LiANCj4+Pj4+Pj4+Pj4+PiBXaGF04oCZ cyB0aGUgYWR2YW50YWdlIG9mIG1vdmluZyB0aGUgT0FNIFBJRCBmdXJ0aGVyIGluc2lkZT8NCj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEFuZCBJIGRvIG5vdCBiZWxpZXZlIHRoZXJl4oCZcyB1 bmRlcnNwZWNpZmljYXRpb24gaW4gTlNIIC0+IA0KPj4+Pj4+Pj4+Pj4+IE89MSwgT0FNIHRyZWF0 bWVudCwgbm90IGRldGFpbGVkIGhlcmUuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBUaGFu a3MsDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiDigJQgQ2FybG9zLg0KPj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICBSZWdhcmRzLA0KPj4+ Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4gKkZyb206KiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgDQo+ Pj4+Pj4+Pj4+Pj4+IFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KPj4+Pj4+Pj4+Pj4+PiAq U2VudDoqIEZyaWRheSwgSnVseSAyMiwgMjAxNiAxMDoxMCBBTQ0KPj4+Pj4+Pj4+Pj4+PiAqVG86 KiBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIA0KPj4+Pj4+Pj4+ Pj4+PiA8bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+DQo+Pj4+Pj4+Pj4+Pj4+ ICpDYzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz47IA0KPj4+Pj4+Pj4+Pj4+ PiBydGctb29hbS1kdEBpZXRmLm9yZyA8bWFpbHRvOnJ0Zy1vb2FtLWR0QGlldGYub3JnPg0KPj4+ Pj4+Pj4+Pj4+PiAqU3ViamVjdDoqIFJlOiBbUnRnLW9vYW0tZHRdIElkZW50aWZ5aW5nIE9BTSBp biBOU0gNCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gR3JlZywNCj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gUGxlYXNlIGZpbmQgc29tZSBjb21tZW50cyBp bmxpbmUuDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IFRodW1iIHR5cGVkIGJ5IENhcmxv cyBQaWduYXRhcm8uDQo+Pj4+Pj4+Pj4+Pj4+IEV4Y3V6ZSB0eXBvZnJhcGhpY2FrIGVycm93cw0K Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBPbiBKdWwgMjEsIDIw MTYsIGF0IDA5OjAxLCBHcmVnb3J5IE1pcnNreSANCj4+Pj4+Pj4+Pj4+Pj4gPGdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbSANCj4+Pj4+Pj4+Pj4+Pj4gPG1haWx0bzpncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb20+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gIERlYXIg QWxsLA0KPj4+Pj4+Pj4+Pj4+PiAgd2UgaGFkIHZlcnkgZ29vZCBkaXNjdXNzaW9uIG9uIE9BTSB0 aGlzIHdlZWsuIFdl4oCZdmUgDQo+Pj4+Pj4+Pj4+Pj4+IHRvdWNoZWQgb24gIEFjdGl2ZSwgUGFz c2l2ZSBhbmQgU29tZXRoaW5nLWluLWJldHdlZW4gT0FNLiANCj4+Pj4+Pj4+Pj4+Pj4gQnV0IGNh biBOU0ggaW5kaWNhdGUgIHdoaWNoIE9BTSB0eXBlLCBpZiBhbnksIGFzc29jaWF0ZWQgDQo+Pj4+ Pj4+Pj4+Pj4+IHdpdGggYSBwYWNrZXQ/IEkgdGhpbmsgdGhhdCB0aGUgIGN1cnJlbnQgdmVyc2lv biBvZiANCj4+Pj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1zZmMtbnNoIGRvZXMgbm90IGFsbG93IHRo YXQgYW5kIG1heSAgYmUgDQo+Pj4+Pj4+Pj4+Pj4+IGFtYmlndW91cyBpbiBzb21lIGNhc2VzLiBJ IHByb3Bvc2UgY2hhbmdlIHRvIA0KPj4+Pj4+Pj4+Pj4+PiBpbnRlcnByZXRhdGlvbiBhbmQgIGFw cGxpY2FiaWxpdHkgZGVzY3JpcHRpb24gb2YgdGhlIE8oQU0pIA0KPj4+Pj4+Pj4+Pj4+PiBmbGFn IGFuZCBhbGxvY2F0aW9uIG9mIHRoZSAgbmV3IHByb3RvY29sIHR5cGUgdG8gYmUgdXNlZCANCj4+ Pj4+Pj4+Pj4+Pj4gaW4gdGhlIE5leHQgUHJvdG9jb2wgZmllbGQuDQo+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IEFjdGl2ZSwgcGFzc2l2 ZSBhbmQgc29tZXRoaW5nLWluLWJldHdlZW4gYXJlIG5vdCBPQU0gDQo+Pj4+Pj4+Pj4+Pj4+IHBy b3RvY29sIHR5cGVzIGJ1dCByYXRoZXIgdGhleSBhcmUgbWVhc3VyaW5nIG1ldGhvZHMuIA0KPj4+ Pj4+Pj4+Pj4+PiBBY3RpdmUgT0FNIGNhbiBpbmNsdWRlIGEgcGx1cmFsaXR5IG9mIE9BTSBwcm90 b2NvbHMsIA0KPj4+Pj4+Pj4+Pj4+PiBpbmNsdWRpbmcgQkZELCBTLUJGRCwgc29tZXRoaW5nLW92 ZXItaXAsIGV0Yy4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gSSBhbHNvIGJlbGlldmUg dGhhdCB0aGUgY3VycmVudCBPQU0gdGV4dCBpbiBOU0ggaXMgbm90IA0KPj4+Pj4+Pj4+Pj4+PiBh bWJpZ3VvdXMgYW5kIGFsbG93cyBlbm91Z2ggcHJvY2Vzc2luZyBvZiB0aGUgaGVhZGVyIHRvIA0K Pj4+Pj4+Pj4+Pj4+PiB1bmRlcnN0YW5kIHNvbWV0aGluZyBpcyBPQU0sIHdpdGhvdXQgZ29pbmcg dGhlIHNwZWNpZmljcyANCj4+Pj4+Pj4+Pj4+Pj4gb2YgYW4gT0FNIGhhbmRsZXIuDQo+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IFRoZXJlZm9yZSwgSSBvcHBvc2UgdGhpcyBjaGFuZ2UuDQo+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ICBSRkMgNzc5OSBkZWZp bmVzIEFjdGl2ZSBPQU0gYXMgZm9sbG93aW5nOg0KPj4+Pj4+Pj4+Pj4+PiAgQW4gQWN0aXZlIE1l dHJpYyBvciBNZXRob2QgZGVwZW5kcyBvbiBhIGRlZGljYXRlZCANCj4+Pj4+Pj4+Pj4+Pj4gbWVh c3VyZW1lbnQgIHBhY2tldCBzdHJlYW0gYW5kIG9ic2VydmF0aW9ucyBvZiB0aGUgc3RyZWFtLg0K Pj4+Pj4+Pj4+Pj4+PiAgVGh1cywgcmVnYXJkbGVzcyBvZiBlbmNhcHN1bGF0aW9uIHVzZWQgYnkg T0FNLCBpdCBpcyB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+IHBhY2tldCAgY29uc3RydWN0ZWQgc29sZWx5 IGZvciBtb25pdG9yaW5nLCBtZWFzdXJpbmcgDQo+Pj4+Pj4+Pj4+Pj4+IG5ldHdvcmvigJlzIG1l dHJpYyBhbmQgIHNob3VsZCBub3QgbGVhdmUgZ2l2ZW4gZG9tYWluLiBBbmQsIA0KPj4+Pj4+Pj4+ Pj4+PiBJIGJlbGlldmUsIHN1Y2ggcGFja2V0cyBzaG91bGQgIGJlIGlkZW50aWZpZWQgYnkgdGhl IA0KPj4+Pj4+Pj4+Pj4+PiBwcm90b2NvbCB0eXBlIG9mIHRoZWlyIG93bi4NCj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gU2VlbXMgeW91IGFyZSBhZHZvY2F0aW5n IGZvciBhIHNpbmdsZSAiT0FNIiBwcm90b2NvbCB0eXBlIA0KPj4+Pj4+Pj4+Pj4+PiBmb3IgT0FN IHBhY2tldHMuIFRoZSBmdW5jdGlvbmFsaXR5IG9mIGlkZW50aWZ5aW5nIA0KPj4+Pj4+Pj4+Pj4+ PiBzb21ldGhpbmcgYXMgT0FNIGlzIGluIHRoZSBPLWJpdCwgc28gbm8gbmVlZCB0byB3YXN0ZSBi aXRzIA0KPj4+Pj4+Pj4+Pj4+PiBpbiBkdXBsaWNhdGlvbi4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4gVGhlbiwgYXQgc29tZSBwb2ludCwgeW91IGhhdmUgdG8gZGlmZmVyZW50aWF0ZSBp ZiBhbiBPQU0gDQo+Pj4+Pj4+Pj4+Pj4+IGlzLCBzYXksIElQIG9yICJyYXcgQkZEIiBvciBzb21l dGhpbmcgZWxzZS4gVGhhdCdzIHdoYXQgDQo+Pj4+Pj4+Pj4+Pj4+IHRoZSBQcm90b2NvbCBmaWVs ZCBpcyBmb3IuDQo+Pj4+Pj4+Pj4+Pj4+IEkgZG8gbm90IHNlZSBhIG5lZWQgdG8gYWRkIGFuIGlu ZGlyZWN0aW9uIGhlcmUgdG8gdGhlbiANCj4+Pj4+Pj4+Pj4+Pj4gaGF2ZSB0byBoYXZlIGEgcHJv dG9jb2wgZmllbGQgaW5zaWRlIHRoZSBPQU0uDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+ICBPQU0gd2hpY2ggYmVoYXZlcyBhcyBtdWNoIGFzIFBhc3NpdmUgT0FN IG9yIA0KPj4+Pj4+Pj4+Pj4+PiBTb21ldGhpbmctaW4tYmV0d2VlbiwgIGUuZy4gT0FNIGFwcGVu ZGVkIHRvIGRhdGEgcGFja2V0IA0KPj4+Pj4+Pj4+Pj4+PiBlaXRoZXIgYXQgdGhlIGRvbWFpbuKA mXMgZWRnZSBvciAgb24tdGhlLWZseSwgaWRlbnRpZmllZCBieSANCj4+Pj4+Pj4+Pj4+Pj4gdGhl IHByb3RvY29sIHR5cGUgb2YgdGhlIGRhdGEgcGFja2V0ICBjYXJyaWVkIGluIE5TSC4NCj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gVGhhdCdzIGNvcnJlY3QsIHdp dGggdGhlIE8gYml0IGNsZWFyZWQ7IGl0J3MgYSBkYXRhIHBhY2tldCANCj4+Pj4+Pj4+Pj4+Pj4g YW5kIG5vdCBhbiBPQU0gb25lLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+PiAgQmVsb3cgYXJlIGNoYW5nZXMgSeKAmWQgbGlrZSB0byBwcm9wb3NlOg0KPj4+Pj4+ Pj4+Pj4+PiAgU2VjdGlvbiAzLjIgTy1iaXQ6DQo+Pj4+Pj4+Pj4+Pj4+ICBPTEQNCj4+Pj4+Pj4+ Pj4+Pj4gICAgIE8gYml0OiB3aGVuIHNldCB0byAweDEgaW5kaWNhdGVzIHRoYXQgdGhpcyBwYWNr ZXQgaXMgDQo+Pj4+Pj4+Pj4+Pj4+IGFuIE9wZXJhdGlvbnMsDQo+Pj4+Pj4+Pj4+Pj4+ICAgICBB ZG1pbmlzdHJhdGlvbiBhbmQgTWFpbnRlbmFuY2UgKE9BTSkgbWVzc2FnZS4gIFRoZSANCj4+Pj4+ Pj4+Pj4+Pj4gcmVjZWl2aW5nICBTRkYgYW5kDQo+Pj4+Pj4+Pj4+Pj4+ICAgICBTRnMgbm9kZXMg TVVTVCBleGFtaW5lIHRoZSBwYXlsb2FkIGFuZCB0YWtlIA0KPj4+Pj4+Pj4+Pj4+PiBhcHByb3By aWF0ZSBhY3Rpb24gIChlLmcuDQo+Pj4+Pj4+Pj4+Pj4+ICAgICByZXR1cm4gc3RhdHVzIGluZm9y bWF0aW9uKS4gIE9BTSBtZXNzYWdlIHNwZWNpZmljcyBhbmQgDQo+Pj4+Pj4+Pj4+Pj4+IGhhbmRs aW5nDQo+Pj4+Pj4+Pj4+Pj4+ICAgICBkZXRhaWxzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50Lg0KPj4+Pj4+Pj4+Pj4+PiAgRU5EDQo+Pj4+Pj4+Pj4+Pj4+ICBORVcNCj4+ Pj4+Pj4+Pj4+Pj4gIE8gYml0OiB3aGVuIHNldCB0byAweDEgaW5kaWNhdGVzIHRoYXQgZGF0YSBw YWNrZXQgDQo+Pj4+Pj4+Pj4+Pj4+IGlkZW50aWZpZWQgYnkgIHRoZSBOZXh0ICBQcm90b2NvbCB0 eXBlIGhhcyBPQU0gbWV0YWRhdGEgDQo+Pj4+Pj4+Pj4+Pj4+IGFwcGVuZGVkLg0KPj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBOby4gSWYgaXQgaXMgYSBkYXRhIHBh Y2tldCBpdCBkb2VzIG5vdCBoYXZlIHRoZSBPIGJpdCBzZXQgDQo+Pj4+Pj4+Pj4+Pj4+ICh0byAx IG9yIHRvIHdoaWNoZXZlciBvdGhlciBwb3NzaWJsZSB2YWx1ZSBmb3IgdGhlIGJpdCA6LSkNCj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gVGhlIGdvYWwgaXMgdGhhdCBsb29raW5nIGF0IGEg c2luZ2xlIGJ1dCBpdCBjYW4gYmUgDQo+Pj4+Pj4+Pj4+Pj4+IHVuZGVyc3Rvb2QgaWYgaXQgaXMg YSBkYXRhIHBhY2tldCAod2hpY2ggY2FuIGJlIHVzZWQsIA0KPj4+Pj4+Pj4+Pj4+PiBtYXJrZWQs IGV0Yy4gdG8gYmUgdXNlZCBmb3IgT0FNIHB1cnBvc2VzLCBvciBub3QpLg0KPj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+PiBXZSBkbyBub3Qgd2FudCBPQU0gZGlyZWN0IGV4Y2VwdGlvbiBwcm9j ZXNzaW5nIGZvciBkYXRhIA0KPj4+Pj4+Pj4+Pj4+PiBwYWNrZXRzLg0KPj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiAgRGVmaW5pdGlvbiBvZiB0aGUgZm9ybWF0KHMp ICB1c2VkIGJ5IE9BTSBtZXRhZGF0YSBpcyANCj4+Pj4+Pj4+Pj4+Pj4gb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4NCj4+Pj4+Pj4+Pj4+Pj4gIEVORA0KPj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+PiAgQXQgdGhlIGVuZCBvZiBTZWN0aW9uIDMuMjoNCj4+Pj4+Pj4+Pj4+Pj4g IE9MRA0KPj4+Pj4+Pj4+Pj4+PiAgICAgVGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcg TmV4dCBQcm90b2NvbCB2YWx1ZXM6DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAw eDEgOiBJUHY0DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAweDIgOiBJUHY2DQo+Pj4+Pj4+Pj4+Pj4+ICAg ICAweDMgOiBFdGhlcm5ldA0KPj4+Pj4+Pj4+Pj4+PiAgICAgMHg0OiBOU0gNCj4+Pj4+Pj4+Pj4+ Pj4gICAgIDB4NTogTVBMUw0KPj4+Pj4+Pj4+Pj4+PiAgICAgMHg2LTB4RkQ6IFVuYXNzaWduZWQN Cj4+Pj4+Pj4+Pj4+Pj4gICAgIDB4RkUtMHhGRjogRXhwZXJpbWVudGFsICBFTkQgIE5FVw0KPj4+ Pj4+Pj4+Pj4+PiAgICAgVGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgTmV4dCBQcm90 b2NvbCB2YWx1ZXM6DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAweDEgOiBJUHY0 DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAweDIgOiBJUHY2DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAweDMgOiBF dGhlcm5ldA0KPj4+Pj4+Pj4+Pj4+PiAgICAgMHg0OiBOU0gNCj4+Pj4+Pj4+Pj4+Pj4gICAgIDB4 NTogTVBMUw0KPj4+Pj4+Pj4+Pj4+PiAgICAgMHg2OiBBY3RpdmUgT0FNDQo+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IEFzIHBlciBhYm92ZSBJIGRvIG5vdCBiZWxp ZXZlIHRoZXJlJ3MgYSBzaW5nbGUgT0FNIHByb3RvY29sLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiAgICAgMHg3LTB4RkQ6IFVuYXNzaWduZWQNCj4+Pj4+Pj4+ Pj4+Pj4gICAgIDB4RkUtMHhGRjogRXhwZXJpbWVudGFsICBFTkQNCj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4gIEFuZCwgY29uc2VxdWVudGx5LCBzZWN0aW9uIDEzLjIuNSBpbiBJQU5BIENv bnNpZGVyYXRpb25zIA0KPj4+Pj4+Pj4+Pj4+PiBzZWN0aW9uICB3aWxsIHJlcXVlc3QgYWxsb2Nh dGlvbiBvZiB2YWx1ZSAweDYgdG8gYmUgDQo+Pj4+Pj4+Pj4+Pj4+IGFzc2lnbmVkIHRvIEFjdGl2 ZSBPQU0gIHByb3RvY29scy4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gIEdyZWF0bHkg YXBwcmVjaWF0ZSB5b3VyIGNvbnNpZGVyYXRpb24gYW5kIGNvbW1lbnRzLg0KPj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBNeSDigqwwLjAy Lg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+IENhcmxvcy4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICBSZWdhcmRzLA0KPj4+Pj4+Pj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+Pj4+Pj4+PiAgUnRnLW9vYW0tZHQgbWFpbGluZyBsaXN0DQo+Pj4+ Pj4+Pj4+Pj4+ICBSdGctb29hbS1kdEBpZXRmLm9yZyA8bWFpbHRvOlJ0Zy1vb2FtLWR0QGlldGYu b3JnPiAgDQo+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRnLW9vYW0tZHQNCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+ Pj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+PiBzZmNA aWV0Zi5vcmcNCj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0K Pj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRm Lm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pg0KPj4NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0 DQo+PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Wed Aug 10 09:40: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 C365F12D81F for ; Wed, 10 Aug 2016 09:40:44 -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 6P5__lS1eLej for ; Wed, 10 Aug 2016 09:40:41 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F2D12B04F for ; Wed, 10 Aug 2016 09:40:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 91E70265E76; Wed, 10 Aug 2016 09:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470847241; bh=6rT83LSYDEq1tJHMhXLkWrEq/wcKXCF79Yda0yxjsO0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VFf5Z9XChVNRA0XT8TbUsFnM6oF55BQt0yi8A7DV7/KzqjeEdk4/arWLHABu6xUvS cWlJqhk9YDUe3VHB7yd364jZg2YmTdMh1wgfqaFY0hvp+tBiU010PbOO5Ao5MO8HER jXQEGtTDv8Xbokk3n6aPRzWeaNcvCsx9ovwvRALo= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BCC6924FD3E; Wed, 10 Aug 2016 09:40:40 -0700 (PDT) To: Gregory Mirsky , "huubatwork@gmail.com" , Loa Andersson , "sfc@ietf.org" References: <7347100B5761DC41A166AC17F22DF11221ADA9CB@eusaamb103.ericsson.se> <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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> <291a8452-bdef-e224-c78a-392843cee125@joelhalpern.com> <8f80b912-6c50-db63-d88b-832e497bfcac@joelhalpern.com> <7347100B5761DC41A166AC17F22DF11221AF89BC@eusaamb103.ericsson.se> From: Joel Halpern Direct Message-ID: <43aee572-35b3-74c9-2ac3-a39a1d4f3d47@joelhalpern.com> Date: Wed, 10 Aug 2016 12:42:49 -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: <7347100B5761DC41A166AC17F22DF11221AF89BC@eusaamb103.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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: Wed, 10 Aug 2016 16:40:45 -0000 I agree that we should keep service function OAM separate from SFP OAM. This is one of the examples where trying to get perfect fate sharing would make life harder instead of easier. Yours, Joel On 8/10/16 12:28 PM, Gregory Mirsky wrote: > Hi Joel, > in discussions within OOAM DT we've considered separation of Active OAM for SFC into SFP OAM that includes Classifier and SFFs and SFF to locally mapped SF OAM. Any other active OAM that includes SF, in my view, is more client, i.e. service, OAM than overlay network, which is the server layer, OAM. If an OAM control packet traverses the service represented by an SF, then what really was measured, again per my understanding, is the service performance including performance of the particular SFC. To clear, to separate Service OAM from SFC OAM, when using active OAM, we need to have separate OAM domains. > > Regards, > Greg > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, August 10, 2016 8:02 AM > To: huubatwork@gmail.com; Loa Andersson ; sfc@ietf.org > Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH > > Let me try phrasing this differently. > > As a general rule, it is clear that one wants measurement traffic to share fate with what you want to measure. Even pure connectivity checking needs to share enough fate that one can reasonably conclude from the OAM observations what the likely status is of the underlying traffic connectivity. > > However, the differences in constraints mean that the degree to which this can be done varies from case to case. > In the case of SFC, we want to use the same SPI and SI for OAM as for regular traffic, since that helps us hae that confidence. > And where we can, it is nice to have OAM traffic that is only perturbed at the end-points. > However the nature of the SFF behaviors, and more importantly the nature of the SF behaviors, mean that there are serious limitations on what one can do with active mechanisms of this sort. > > Yours, > Joel > > On 8/10/16 10:11 AM, Huub van Helvoort wrote: >> Hello Joel, >> >> You wrote: >> >>> There are OAM tasks where only the end-points are involved. In that >>> case, I think we would all like to see as much fate sharing with the >>> normal data path as a possible. >> >> Correct! >> >>> But there are a lot of cases where that does not apply. >> >> Note that in these cases the performance of the OAM will be measured, >> and *NOT* the performance of the payload. >> >>> So we can not simply take the rule of thumb you suggested and run >>> with it. >> >> Why would you need to measure the performance of the OAM? >> >> Best regards, Huub. >> >> >>> On 8/10/16 7:19 AM, Loa Andersson wrote: >>>> Joel, >>>> >>>> Yes I see the problem, you described (high-level) what happens in an >>>> MPLS(-TP), but wouldn't we limit the data plane measurements we >>>> could do if the OAM and payload packets are treated differently by >>>> the data plane? Would it be feasible to look into a mechanism that >>>> only do the OAM treatment at the end-points? >>>> >>>> /Loa >>>> >>>> On 2016-08-09 18:19, Joel M. Halpern wrote: >>>>> Clearly, we would like as much fate sharing as possible. >>>>> >>>>> I believe most of the MPLS OAM cases where such that intermediate >>>>> MPLS LSPs do not have to do any OAM processing. >>>>> >>>>> In contrast, there are proposed SFC OAM behaviors that require >>>>> processing at intermediate SFF. >>>>> MPLS uses TTL mechanisms to cover the few cases where it needs that. >>>>> NSH >>>>> can not do that, because the service index (which alos provides >>>>> loop >>>>> suppression) is part of the forwarding logic. So constructing >>>>> initial packets with different SIs will break forwarding. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 8/9/16 9:36 AM, Loa Andersson wrote: >>>>>> Folks, >>>>>> >>>>>> Maybe a naive question. >>>>>> >>>>>> On 2016-08-09 15:30, Joel M. Halpern wrote: >>>>>>> I would normally be inclined to agree with your definition Carlos. >>>>>>> However, if there can be "Piggyback OAM" that has to be processed >>>>>>> by SFF, then we have to make that efficient for the SFF to detect >>>>>>> (since it has to check every packet for this case. >>>>>>> >>>>>>> Note that the meaning of the OAM bit is whatever we say it is. >>>>>>> One definition is "the carried packet is an OAM packet." But we >>>>>>> could also define it more similarly to the router alert bit as in >>>>>>> "this packet needs special checking at each SFF and SF." >>>>>> >>>>>> During the discussions on MPLS OAM we had as a rule of thumb, that >>>>>> the route and processing of OAM packets need to be the same as for >>>>>> payload packet. >>>>>> >>>>>> If we postulate "needs special checking at each SFF and SF" are we >>>>>> abandoning this for SFC? >>>>>> >>>>>> /Loa >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: >>>>>>>> “Piggyback OAM” piggybacks on a data packet, not an OAM packet. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> — Carlos. >>>>>>>> >>>>>>>>> On Aug 9, 2016, at 3:25 AM, Dave Dolson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I guess the confusion is that piggyback OAM is not using the >>>>>>>>> OAM bit. >>>>>>>>> >>>>>>>>> >>>>>>>>> Original Message >>>>>>>>> From: Carlos Pignataro (cpignata) >>>>>>>>> Sent: Tuesday, August 9, 2016 1:31 AM >>>>>>>>> To: Dave Dolson >>>>>>>>> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; >>>>>>>>> sfc@ietf.org >>>>>>>>> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Dave, >>>>>>>>> >>>>>>>>> With apologies for the much belated response; please find one >>>>>>>>> clarification inline: >>>>>>>>> >>>>>>>>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Should the doc say, >>>>>>>>>> >>>>>>>>>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT process >>>>>>>>>> the packet solely by SPI/SI forwarding but instead by the >>>>>>>>>> semantics specified by the ‎OAM 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. >>>>>>>>>> >>>>>>>>>> ‎Without further language, it is not specified how to handle >>>>>>>>>> *any* next-protocol values when O=1. >>>>>>>>>> >>>>>>>>>> And when specified... >>>>>>>>>> >>>>>>>>>> As for so-called piggyback OAM, we could define that if O=1 >>>>>>>>> >>>>>>>>> This might be the source of the confusion — if O=1, that’s not >>>>>>>>> a data packet. The idea with piggyback OAM is to disturb the >>>>>>>>> packet the least. If we flag a data packet as OAM, it takes a >>>>>>>>> completely different processing path. >>>>>>>>> >>>>>>>>> Piggyback OAM is a data packet, O=0, with embedded >>>>>>>>> instrumentation, as in draft-brockners-inband-oam-transport. >>>>>>>>> >>>>>>>>>> and Next Protocol=IPv4 there may be an OAM header following >>>>>>>>>> the IPv4 packet, located using IPv4 total length.‎ Or we could >>>>>>>>>> define a new number for IPv4-with-OAM-trailer. >>>>>>>>> >>>>>>>>> Sorry but there seems to be a lot of unnecessary complexity in >>>>>>>>> that. >>>>>>>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means >>>>>>>>> an OAM packet in IPv4 (as for example an ICMPv4 packet, or for >>>>>>>>> example a >>>>>>>>> BFDoUDPoIPv4 packet. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> — Carlos. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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=1, 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 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 >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 Wed Aug 10 09:49: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 100FF12D645 for ; Wed, 10 Aug 2016 09:49:48 -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 0zLuPJGsJvio for ; Wed, 10 Aug 2016 09:49:44 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4965412D600 for ; Wed, 10 Aug 2016 09:49:44 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id i5so116923413wmg.0 for ; Wed, 10 Aug 2016 09:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=A2I+nBPPsPSLFwpmPss9maZE18fHtQmzOdCiOKKD1so=; b=hLwcbS9tE6XegSP8J22EnVWbL/gHbogrQpkjh4Nef5EN6QWkq346c8XfA+fjtYf5FB X1OSxmEdSDQ7Fu0noJvy2wkuX05IeHcjVjM0VmPlNxmDLYjXoqR0C4ucl25B4eSEWIGi lgsJDtiGNp28pKbPKYpLyfA5hbNxKM3AP0WrTmPzwcXNB29BF76ODyLZmYmW7CTPvmMt NKxEMdyNUdVugkG0VUUNEvAmkpWscHhDJXFb0Er8R85qpf8hhMU8ydkQRAuDZayxYdCK 6BGLLMjcs/cotNPFahje9j+Gwh8QBmgcPeWRjr8qVtMDnxsCIKI/XFZcTkCWsnW6vvLz T4xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=A2I+nBPPsPSLFwpmPss9maZE18fHtQmzOdCiOKKD1so=; b=d9qQdKzbbr/HEj0qftJGvOy3sljt5EvbpO+c0thLpbU0f/ObM8B9WXQUbmulJqJJS+ i4WZ8ZEjozeERbXxqZVHX4Ae8Z9FDpIgayj+iT1FrEeyrIUizCy92CtXF3awCAhCSBRg ipLHonXdndQ1QWmO0NuSW8EQaATT4qVCtS8BCOoRTjwJ7KdhTMAbWi0ousSQAatNpYmq 2ak5gdQnnwKKO23yXmsN2V/Oxy6kE/ZQDumlGrxhb2eE6lS0VFyL17Nobf/w91vH9kma tKVg8uSYrZZrL0w3vp+B1lEnHp+t3K551iEYqJ0Mq/69c5aEpB8356bkDvk8Df+qbpM7 /Hsw== X-Gm-Message-State: AEkoousim5iaxfQjZU+sPSdAtQjUUPq9Nn+dkPXfoNg8C9FdYEvzABQLHApkNqmVKO8+qw== X-Received: by 10.194.113.105 with SMTP id ix9mr4965863wjb.30.1470847782288; Wed, 10 Aug 2016 09:49:42 -0700 (PDT) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id a2sm43874229wjg.46.2016.08.10.09.49.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Aug 2016 09:49:41 -0700 (PDT) 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> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> <291a8452-bdef-e224-c78a-392843cee125@joelhalpern.com> <7347100B5761DC41A166AC17F22DF11221AF899B@eusaamb103.ericsson.se> To: Gregory Mirsky , "Joel M. Halpern" , Loa Andersson , "sfc@ietf.org" From: Huub van Helvoort Message-ID: <10050382-07bd-369e-e01c-835781e5ac4a@gmail.com> Date: Wed, 10 Aug 2016 18:49:40 +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 In-Reply-To: <7347100B5761DC41A166AC17F22DF11221AF899B@eusaamb103.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH 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: Wed, 10 Aug 2016 16:49:48 -0000 Hello Greg, You wrote: > when we consider e2e and segment OAM scenarios we include not > only performance measurement (PM) but fault management (FM) cases. Absolutely! > I believe that for the FM it is important to have fate sharing > for segment OAM as much as for e2e OAM. Indeed. > Or have I missed the point of the discussion completely? I don't thinks so. Cheers, Huub. > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Huub van Helvoort > Sent: Wednesday, August 10, 2016 7:11 AM > To: Joel M. Halpern ; Loa Andersson ; sfc@ietf.org > Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH > > Hello Joel, > > You wrote: > >> There are OAM tasks where only the end-points are involved. In that >> case, I think we would all like to see as much fate sharing with the >> normal data path as a possible. > > Correct! > >> But there are a lot of cases where that does not apply. > > Note that in these cases the performance of the OAM will be measured, and *NOT* the performance of the payload. > >> So we can not simply take the rule of thumb you suggested and run with it. > > Why would you need to measure the performance of the OAM? > > Best regards, Huub. > > >> On 8/10/16 7:19 AM, Loa Andersson wrote: >>> Joel, >>> >>> Yes I see the problem, you described (high-level) what happens in an >>> MPLS(-TP), but wouldn't we limit the data plane measurements we could >>> do if the OAM and payload packets are treated differently by the data >>> plane? Would it be feasible to look into a mechanism that only do the >>> OAM treatment at the end-points? >>> >>> /Loa >>> >>> On 2016-08-09 18:19, Joel M. Halpern wrote: >>>> Clearly, we would like as much fate sharing as possible. >>>> >>>> I believe most of the MPLS OAM cases where such that intermediate >>>> MPLS LSPs do not have to do any OAM processing. >>>> >>>> In contrast, there are proposed SFC OAM behaviors that require >>>> processing at intermediate SFF. >>>> MPLS uses TTL mechanisms to cover the few cases where it needs that. >>>> NSH can not do that, because the service index (which alos provides >>>> loop >>>> suppression) is part of the forwarding logic. So constructing >>>> initial packets with different SIs will break forwarding. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 8/9/16 9:36 AM, Loa Andersson wrote: >>>>> Folks, >>>>> >>>>> Maybe a naive question. >>>>> >>>>> On 2016-08-09 15:30, Joel M. Halpern wrote: >>>>>> I would normally be inclined to agree with your definition Carlos. >>>>>> However, if there can be "Piggyback OAM" that has to be processed >>>>>> by SFF, then we have to make that efficient for the SFF to detect >>>>>> (since it has to check every packet for this case. >>>>>> >>>>>> Note that the meaning of the OAM bit is whatever we say it is. >>>>>> One definition is "the carried packet is an OAM packet." But we >>>>>> could also define it more similarly to the router alert bit as in >>>>>> "this packet needs special checking at each SFF and SF." >>>>> >>>>> During the discussions on MPLS OAM we had as a rule of thumb, that >>>>> the route and processing of OAM packets need to be the same as for >>>>> payload packet. >>>>> >>>>> If we postulate "needs special checking at each SFF and SF" are we >>>>> abandoning this for SFC? >>>>> >>>>> /Loa >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 8/9/16 8:03 AM, Carlos Pignataro (cpignata) wrote: >>>>>>> “Piggyback OAM” piggybacks on a data packet, not an OAM packet. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> — Carlos. >>>>>>> >>>>>>>> On Aug 9, 2016, at 3:25 AM, Dave Dolson >>>>>>>> wrote: >>>>>>>> >>>>>>>> I guess the confusion is that piggyback OAM is not using the OAM >>>>>>>> bit. >>>>>>>> >>>>>>>> >>>>>>>> Original Message >>>>>>>> From: Carlos Pignataro (cpignata) >>>>>>>> Sent: Tuesday, August 9, 2016 1:31 AM >>>>>>>> To: Dave Dolson >>>>>>>> Cc: Joel M. Halpern; Gregory Mirsky; rtg-ooam-dt@ietf.org; >>>>>>>> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH >>>>>>>> >>>>>>>> >>>>>>>> Hi Dave, >>>>>>>> >>>>>>>> With apologies for the much belated response; please find one >>>>>>>> clarification inline: >>>>>>>> >>>>>>>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Should the doc say, >>>>>>>>> >>>>>>>>> If the OAM bit O=0, 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=1, this indicates the SFF ‎MUST NOT process >>>>>>>>> the packet solely by SPI/SI forwarding but instead by the >>>>>>>>> semantics specified by the ‎OAM 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. >>>>>>>>> >>>>>>>>> ‎Without further language, it is not specified how to handle >>>>>>>>> *any* next-protocol values when O=1. >>>>>>>>> >>>>>>>>> And when specified... >>>>>>>>> >>>>>>>>> As for so-called piggyback OAM, we could define that if O=1 >>>>>>>> >>>>>>>> This might be the source of the confusion — if O=1, that’s not a >>>>>>>> data packet. The idea with piggyback OAM is to disturb the >>>>>>>> packet the least. If we flag a data packet as OAM, it takes a >>>>>>>> completely different processing path. >>>>>>>> >>>>>>>> Piggyback OAM is a data packet, O=0, with embedded >>>>>>>> instrumentation, as in draft-brockners-inband-oam-transport. >>>>>>>> >>>>>>>>> and Next Protocol=IPv4 there may be an OAM header following the >>>>>>>>> IPv4 packet, located using IPv4 total length.‎ Or we could >>>>>>>>> define a new number for IPv4-with-OAM-trailer. >>>>>>>> >>>>>>>> Sorry but there seems to be a lot of unnecessary complexity in that. >>>>>>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an >>>>>>>> OAM packet in IPv4 (as for example an ICMPv4 packet, or for >>>>>>>> example a >>>>>>>> BFDoUDPoIPv4 packet. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> — Carlos. >>>>>>>> >>>>>>>>> >>>>>>>>> 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=1, 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 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 >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 > > > -- > ================================================================ > Always remember that you are unique...just like everyone else... > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ================================================================ Always remember that you are unique...just like everyone else... From nobody Wed Aug 10 10:21: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 DB29712D6AE for ; Wed, 10 Aug 2016 10:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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.247, 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 JQhZfPnxN_ie for ; Wed, 10 Aug 2016 10:21:41 -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 7387D12D607 for ; Wed, 10 Aug 2016 10:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32326; q=dns/txt; s=iport; t=1470849701; x=1472059301; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fApzStWFYvm8ULtBxecWTVlq4h+Qhc3LWj0JSDF/ffA=; b=Kpvd2rlPQIp8atMg4SVVlKBKTXrLtJow+v4zXXCWBTwfNE45GMXB6//x 63Q6SI7gQqPEw9thKuMkweg6wWttkFoBfDx+7sdn72CvZCTht0gp6lID7 vzeiDmVtKr0Hk1puK5w8EB7CP0AOZcrcNpE4Jr17PV/CzdSfYMCpa3i5r M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAgDVYatX/5JdJa1dg0VWfAe5I4F9J?= =?us-ascii?q?IV5AhyBQzgUAQEBAQEBAV0nhF4BAQQBAQEYCQQNMwcEBwUHBAIBCBEEAQEBAgI?= =?us-ascii?q?jAwICAiULFAEICAIEDgWIKQgOsWuQPwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFg?= =?us-ascii?q?QGFKYF4glWEHSMXgmorgi8FmTwBiFZEhXeBa4RbiH2MNIN3AR42ghIcgUxuhVx?= =?us-ascii?q?FfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,501,1464652800"; d="scan'208";a="307395716" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Aug 2016 17:21:39 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u7AHLdF5021744 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Aug 2016 17:21:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 Aug 2016 13:21:38 -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, 10 Aug 2016 13:21:38 -0400 From: "Carlos Pignataro (cpignata)" To: Gregory Mirsky Thread-Topic: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH Thread-Index: AQHR4/B/s+mJr49HL0uqnvaJ3glSK6AkcOaAgAIHwQCAACcwgIAAUL4AgAAHt4CAAMQ4gIAYaUyAgABzqgCAAE2rgIAAGHyAgAABmoCAAC1+AIABPnaAgAAs7ACAAAM1gIAAIduAgAATTwA= Date: Wed, 10 Aug 2016 17:21:38 +0000 Message-ID: <4724BDC9-FD31-41AB-84E6-25715233DDE5@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> <83EF1E06-D242-4FE6-8C7A-B00AE858557B@cisco.com> <20160724114359.5714005.75862.99628@sandvine.com> <6D2AB7AC-5CE3-4E85-A665-B6105141C61A@cisco.com> <20160809072502.5714003.12271.102144@sandvine.com> <6710bb6e-acfa-0782-aadd-f963d5fdbaba@pi.nu> <291a8452-bdef-e224-c78a-392843cee125@joelhalpern.com> <7347100B5761DC41A166AC17F22DF11221AF899B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221AF899B@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.150.50.87] Content-Type: text/plain; charset="utf-8" Content-ID: <2512531EF2C4744A906BA761E4A759B2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Loa Andersson , "Joel M. Halpern" , "sfc@ietf.org" , "huubatwork@gmail.com" 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: Wed, 10 Aug 2016 17:21:45 -0000 DQo+IE9uIEF1ZyAxMCwgMjAxNiwgYXQgMTI6MTIgUE0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5 Lm1pcnNreUBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGkgSHV1YiwNCj4gd2hlbiB3ZSBj b25zaWRlciBlMmUgYW5kIHNlZ21lbnQgT0FNIHNjZW5hcmlvcyB3ZSBpbmNsdWRlIG5vdCBvbmx5 IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IChQTSkgYnV0IGZhdWx0IG1hbmFnZW1lbnQgKEZNKSBj YXNlcy4gSSBiZWxpZXZlIHRoYXQgZm9yIHRoZSBGTSBpdCBpcyBpbXBvcnRhbnQgdG8gaGF2ZSBm YXRlIHNoYXJpbmcgZm9yIHNlZ21lbnQgT0FNIGFzIG11Y2ggYXMgZm9yIGUyZSBPQU0uDQoNCkkg dGhpbmsgdGhlcmUgYXJlIHNvbWUgc3VidGxlIGRpc3RpbmN0aW9ucyBpbiB0aGUgY29udGV4dCBv ZiBzZXJ2aWNlIGNoYWluaW5nLCB3aGljaCBtYWtlIGZhdGUtc2hhcmluZyBub3QgYmluYXJ5Lg0K DQpXaXRoaW4gU0ZDLCBJIGRvIG5vdCBiZWxpZXZlIHdlIHdhbnQgT0FNIHRvIGJlIHByb2Nlc3Nl ZCBieSBTRnMgKGUuZy4sIGdvIHRocm91Z2ggdGhlIGZpcmV3YWxsIG9yIHRyYW5zY29kZXIpLiBU aGlzIGlzIGEgZGVwYXJ0dXJlIGZyb20gImZhdGUtc2hhcmluZyIsIGJ1dCBhIGdvb2Qgb25lLCBJ TUhPLg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCj4gT3IgaGF2ZSBJIG1pc3NlZCB0aGUg cG9pbnQgb2YgdGhlIGRpc2N1c3Npb24gY29tcGxldGVseT8NCj4gDQo+IAlSZWdhcmRzLA0KPiAJ CUdyZWcNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSHV1YiB2YW4gSGVsdm9vcnQN Cj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTAsIDIwMTYgNzoxMSBBTQ0KPiBUbzogSm9lbCBN LiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51 Pjsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBbUnRnLW9vYW0tZHRdIElkZW50 aWZ5aW5nIE9BTSBpbiBOU0gNCj4gDQo+IEhlbGxvIEpvZWwsDQo+IA0KPiBZb3Ugd3JvdGU6DQo+ IA0KPj4gVGhlcmUgYXJlIE9BTSB0YXNrcyB3aGVyZSBvbmx5IHRoZSBlbmQtcG9pbnRzIGFyZSBp bnZvbHZlZC4gIEluIHRoYXQgDQo+PiBjYXNlLCBJIHRoaW5rIHdlIHdvdWxkIGFsbCBsaWtlIHRv IHNlZSBhcyBtdWNoIGZhdGUgc2hhcmluZyB3aXRoIHRoZSANCj4+IG5vcm1hbCBkYXRhIHBhdGgg YXMgYSBwb3NzaWJsZS4NCj4gDQo+IENvcnJlY3QhDQo+IA0KPj4gQnV0IHRoZXJlIGFyZSBhIGxv dCBvZiBjYXNlcyB3aGVyZSB0aGF0IGRvZXMgbm90IGFwcGx5Lg0KPiANCj4gTm90ZSB0aGF0IGlu IHRoZXNlIGNhc2VzIHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgT0FNIHdpbGwgYmUgbWVhc3VyZWQs IGFuZCAqTk9UKiB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIHBheWxvYWQuDQo+IA0KPj4gU28gd2Ug Y2FuIG5vdCBzaW1wbHkgdGFrZSB0aGUgcnVsZSBvZiB0aHVtYiB5b3Ugc3VnZ2VzdGVkIGFuZCBy dW4gd2l0aCBpdC4NCj4gDQo+IFdoeSB3b3VsZCB5b3UgbmVlZCB0byBtZWFzdXJlIHRoZSBwZXJm b3JtYW5jZSBvZiB0aGUgT0FNPw0KPiANCj4gQmVzdCByZWdhcmRzLCBIdXViLg0KPiANCj4gDQo+ PiBPbiA4LzEwLzE2IDc6MTkgQU0sIExvYSBBbmRlcnNzb24gd3JvdGU6DQo+Pj4gSm9lbCwNCj4+ PiANCj4+PiBZZXMgSSBzZWUgdGhlIHByb2JsZW0sIHlvdSBkZXNjcmliZWQgKGhpZ2gtbGV2ZWwp IHdoYXQgaGFwcGVucyBpbiBhbiANCj4+PiBNUExTKC1UUCksIGJ1dCB3b3VsZG4ndCB3ZSBsaW1p dCB0aGUgZGF0YSBwbGFuZSBtZWFzdXJlbWVudHMgd2UgY291bGQgDQo+Pj4gZG8gaWYgdGhlIE9B TSBhbmQgcGF5bG9hZCBwYWNrZXRzIGFyZSB0cmVhdGVkIGRpZmZlcmVudGx5IGJ5IHRoZSBkYXRh IA0KPj4+IHBsYW5lPyBXb3VsZCBpdCBiZSBmZWFzaWJsZSB0byBsb29rIGludG8gYSBtZWNoYW5p c20gdGhhdCBvbmx5IGRvIHRoZSANCj4+PiBPQU0gdHJlYXRtZW50IGF0IHRoZSBlbmQtcG9pbnRz Pw0KPj4+IA0KPj4+IC9Mb2ENCj4+PiANCj4+PiBPbiAyMDE2LTA4LTA5IDE4OjE5LCBKb2VsIE0u IEhhbHBlcm4gd3JvdGU6DQo+Pj4+IENsZWFybHksIHdlIHdvdWxkIGxpa2UgYXMgbXVjaCBmYXRl IHNoYXJpbmcgYXMgcG9zc2libGUuDQo+Pj4+IA0KPj4+PiBJIGJlbGlldmUgbW9zdCBvZiB0aGUg TVBMUyBPQU0gY2FzZXMgd2hlcmUgc3VjaCB0aGF0IGludGVybWVkaWF0ZSANCj4+Pj4gTVBMUyBM U1BzIGRvIG5vdCBoYXZlIHRvIGRvIGFueSBPQU0gcHJvY2Vzc2luZy4NCj4+Pj4gDQo+Pj4+IElu IGNvbnRyYXN0LCB0aGVyZSBhcmUgcHJvcG9zZWQgU0ZDIE9BTSBiZWhhdmlvcnMgdGhhdCByZXF1 aXJlIA0KPj4+PiBwcm9jZXNzaW5nIGF0IGludGVybWVkaWF0ZSBTRkYuDQo+Pj4+IE1QTFMgdXNl cyBUVEwgbWVjaGFuaXNtcyB0byBjb3ZlciB0aGUgZmV3IGNhc2VzIHdoZXJlIGl0IG5lZWRzIHRo YXQuIA0KPj4+PiBOU0ggY2FuIG5vdCBkbyB0aGF0LCBiZWNhdXNlIHRoZSBzZXJ2aWNlIGluZGV4 ICh3aGljaCBhbG9zIHByb3ZpZGVzIA0KPj4+PiBsb29wDQo+Pj4+IHN1cHByZXNzaW9uKSBpcyBw YXJ0IG9mIHRoZSBmb3J3YXJkaW5nIGxvZ2ljLiAgU28gY29uc3RydWN0aW5nIA0KPj4+PiBpbml0 aWFsIHBhY2tldHMgd2l0aCBkaWZmZXJlbnQgU0lzIHdpbGwgYnJlYWsgZm9yd2FyZGluZy4NCj4+ Pj4gDQo+Pj4+IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+IA0KPj4+PiBPbiA4LzkvMTYgOTozNiBB TSwgTG9hIEFuZGVyc3NvbiB3cm90ZToNCj4+Pj4+IEZvbGtzLA0KPj4+Pj4gDQo+Pj4+PiBNYXli ZSBhIG5haXZlIHF1ZXN0aW9uLg0KPj4+Pj4gDQo+Pj4+PiBPbiAyMDE2LTA4LTA5IDE1OjMwLCBK b2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+Pj4+Pj4gSSB3b3VsZCBub3JtYWxseSBiZSBpbmNsaW5l ZCB0byBhZ3JlZSB3aXRoIHlvdXIgZGVmaW5pdGlvbiBDYXJsb3MuDQo+Pj4+Pj4gSG93ZXZlciwg aWYgdGhlcmUgY2FuIGJlICJQaWdneWJhY2sgT0FNIiB0aGF0IGhhcyB0byBiZSBwcm9jZXNzZWQg DQo+Pj4+Pj4gYnkgU0ZGLCB0aGVuIHdlIGhhdmUgdG8gbWFrZSB0aGF0IGVmZmljaWVudCBmb3Ig dGhlIFNGRiB0byBkZXRlY3QgDQo+Pj4+Pj4gKHNpbmNlIGl0IGhhcyB0byBjaGVjayBldmVyeSBw YWNrZXQgZm9yIHRoaXMgY2FzZS4NCj4+Pj4+PiANCj4+Pj4+PiBOb3RlIHRoYXQgdGhlIG1lYW5p bmcgb2YgdGhlIE9BTSBiaXQgaXMgd2hhdGV2ZXIgd2Ugc2F5IGl0IGlzLg0KPj4+Pj4+IE9uZSBk ZWZpbml0aW9uIGlzICJ0aGUgY2FycmllZCBwYWNrZXQgaXMgYW4gT0FNIHBhY2tldC4iICBCdXQg d2UgDQo+Pj4+Pj4gY291bGQgYWxzbyBkZWZpbmUgaXQgbW9yZSBzaW1pbGFybHkgdG8gdGhlIHJv dXRlciBhbGVydCBiaXQgYXMgaW4gDQo+Pj4+Pj4gInRoaXMgcGFja2V0IG5lZWRzIHNwZWNpYWwg Y2hlY2tpbmcgYXQgZWFjaCBTRkYgYW5kIFNGLiINCj4+Pj4+IA0KPj4+Pj4gRHVyaW5nIHRoZSBk aXNjdXNzaW9ucyBvbiBNUExTIE9BTSB3ZSBoYWQgYXMgYSBydWxlIG9mIHRodW1iLCB0aGF0IA0K Pj4+Pj4gdGhlIHJvdXRlIGFuZCBwcm9jZXNzaW5nIG9mIE9BTSBwYWNrZXRzIG5lZWQgdG8gYmUg dGhlIHNhbWUgYXMgZm9yIA0KPj4+Pj4gcGF5bG9hZCBwYWNrZXQuDQo+Pj4+PiANCj4+Pj4+IElm IHdlIHBvc3R1bGF0ZSAibmVlZHMgc3BlY2lhbCBjaGVja2luZyBhdCBlYWNoIFNGRiBhbmQgU0Yi IGFyZSB3ZSANCj4+Pj4+IGFiYW5kb25pbmcgdGhpcyBmb3IgU0ZDPw0KPj4+Pj4gDQo+Pj4+PiAv TG9hDQo+Pj4+Pj4gDQo+Pj4+Pj4gWW91cnMsDQo+Pj4+Pj4gSm9lbA0KPj4+Pj4+IA0KPj4+Pj4+ IE9uIDgvOS8xNiA4OjAzIEFNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQo+ Pj4+Pj4+IOKAnFBpZ2d5YmFjayBPQU3igJ0gcGlnZ3liYWNrcyBvbiBhIGRhdGEgcGFja2V0LCBu b3QgYW4gT0FNIHBhY2tldC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IOKAlCBDYXJsb3MuDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gT24gQXVnIDksIDIwMTYsIGF0 IDM6MjUgQU0sIERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4NCj4+Pj4+Pj4+IHdy b3RlOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJIGd1ZXNzIHRoZSBjb25mdXNpb24gaXMgdGhhdCBw aWdneWJhY2sgT0FNIGlzIG5vdCB1c2luZyB0aGUgT0FNIA0KPj4+Pj4+Pj4gYml0Lg0KPj4+Pj4+ Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IE9yaWdpbmFsIE1lc3NhZ2UNCj4+Pj4+Pj4+IEZyb206 IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KPj4+Pj4+Pj4gU2VudDogVHVlc2RheSwgQXVn dXN0IDksIDIwMTYgMTozMSBBTQ0KPj4+Pj4+Pj4gVG86IERhdmUgRG9sc29uDQo+Pj4+Pj4+PiBD YzogSm9lbCBNLiBIYWxwZXJuOyBHcmVnb3J5IE1pcnNreTsgcnRnLW9vYW0tZHRAaWV0Zi5vcmc7 IA0KPj4+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW3NmY10gW1J0 Zy1vb2FtLWR0XSBJZGVudGlmeWluZyBPQU0gaW4gTlNIDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gSGkgRGF2ZSwNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gV2l0aCBhcG9sb2dpZXMgZm9y IHRoZSBtdWNoIGJlbGF0ZWQgcmVzcG9uc2U7IHBsZWFzZSBmaW5kIG9uZSANCj4+Pj4+Pj4+IGNs YXJpZmljYXRpb24gaW5saW5lOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gT24gSnVsIDI0LCAyMDE2 LCBhdCAxOjQ0IFBNLCBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+DQo+Pj4+Pj4+ Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gU2hvdWxkIHRoZSBkb2Mgc2F5LA0KPj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+IElmIHRoZSBPQU0gYml0IE89MCwgdGhpcyBpbmRpY2F0ZXMgdGhl IFNGRiBNVVNUIGZvcndhcmQgIHRoZSANCj4+Pj4+Pj4+PiBwYWNrZXQgYmFzZWQgc29sZWx5IG9u IHRoZSBTUEkgYW5kIFNJIGZpZWxkcywgd2l0aG91dA0KPj4+Pj4+Pj4+ICByZWdhcmQgdG8gbmV4 dCBwcm90b2NvbCBvciBmdXJ0aGVyIHBheWxvYWQgaGVhZGVycy4NCj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+PiBJZiB0aGUgT0FNIGJpdCBPPTEsIHRoaXMgaW5kaWNhdGVzIHRoZSBTRkYg4oCOTVVTVCBO T1QgIHByb2Nlc3MgDQo+Pj4+Pj4+Pj4gdGhlIHBhY2tldCBzb2xlbHkgYnkgU1BJL1NJIGZvcndh cmRpbmcgYnV0ICBpbnN0ZWFkIGJ5IHRoZSANCj4+Pj4+Pj4+PiBzZW1hbnRpY3Mgc3BlY2lmaWVk IGJ5IHRoZSDigI5PQU0gIHByb3RvY29sIG5hbWVkIGluIHRoZSBOZXh0IA0KPj4+Pj4+Pj4+IFBy b3RvY29sIGZpZWxkLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEkgdGhpbmsgdGhlc2UgcGFyYWdy YXBocyBnZXQgdG8gdGhlIG9wdGltaXphdGlvbiBmb3IgU0ZGcywgYW5kIA0KPj4+Pj4+Pj4+IEkg dGhpbmsgcHJvdmlkZSBwcmVjaXNlIGxhbmd1YWdlIHdpdGhvdXQgZGVmaW5pbmcgT0FNIA0KPj4+ Pj4+Pj4+IHByb3RvY29scy4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiDigI5XaXRob3V0IGZ1cnRo ZXIgbGFuZ3VhZ2UsIGl0IGlzIG5vdCBzcGVjaWZpZWQgaG93IHRvIGhhbmRsZSANCj4+Pj4+Pj4+ PiAqYW55KiBuZXh0LXByb3RvY29sIHZhbHVlcyB3aGVuIE89MS4NCj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+PiBBbmQgd2hlbiBzcGVjaWZpZWQuLi4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBBcyBmb3Ig c28tY2FsbGVkIHBpZ2d5YmFjayBPQU0sIHdlIGNvdWxkIGRlZmluZSB0aGF0IGlmIE89MQ0KPj4+ Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGlzIG1pZ2h0IGJlIHRoZSBzb3VyY2Ugb2YgdGhlIGNvbmZ1c2lv biDigJQgaWYgTz0xLCB0aGF04oCZcyBub3QgYSANCj4+Pj4+Pj4+IGRhdGEgcGFja2V0LiBUaGUg aWRlYSB3aXRoIHBpZ2d5YmFjayBPQU0gaXMgdG8gZGlzdHVyYiB0aGUgDQo+Pj4+Pj4+PiBwYWNr ZXQgdGhlIGxlYXN0LiBJZiB3ZSBmbGFnIGEgZGF0YSBwYWNrZXQgYXMgT0FNLCBpdCB0YWtlcyBh IA0KPj4+Pj4+Pj4gY29tcGxldGVseSBkaWZmZXJlbnQgcHJvY2Vzc2luZyBwYXRoLg0KPj4+Pj4+ Pj4gDQo+Pj4+Pj4+PiBQaWdneWJhY2sgT0FNIGlzIGEgZGF0YSBwYWNrZXQsIE89MCwgd2l0aCBl bWJlZGRlZCANCj4+Pj4+Pj4+IGluc3RydW1lbnRhdGlvbiwgYXMgaW4gZHJhZnQtYnJvY2tuZXJz LWluYmFuZC1vYW0tdHJhbnNwb3J0Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gYW5kIE5leHQgUHJv dG9jb2w9SVB2NCB0aGVyZSBtYXkgYmUgYW4gT0FNIGhlYWRlciBmb2xsb3dpbmcgdGhlIA0KPj4+ Pj4+Pj4+IElQdjQgcGFja2V0LCBsb2NhdGVkIHVzaW5nIElQdjQgdG90YWwgbGVuZ3RoLuKAjiBP ciB3ZSBjb3VsZCANCj4+Pj4+Pj4+PiBkZWZpbmUgYSBuZXcgbnVtYmVyIGZvciBJUHY0LXdpdGgt T0FNLXRyYWlsZXIuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFNvcnJ5IGJ1dCB0aGVyZSBzZWVtcyB0 byBiZSBhIGxvdCBvZiB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5IGluIHRoYXQuDQo+Pj4+Pj4+PiBX aHkgYW4gT0FNIGhlYWRlcj8gV2h5IGEgdHJhaWxlcj8gTz0xIHdpdGggSVB2NCwgdG8gbWUsIG1l YW5zIGFuIA0KPj4+Pj4+Pj4gT0FNIHBhY2tldCBpbiBJUHY0IChhcyBmb3IgZXhhbXBsZSBhbiBJ Q01QdjQgcGFja2V0LCBvciBmb3IgDQo+Pj4+Pj4+PiBleGFtcGxlIGENCj4+Pj4+Pj4+IEJGRG9V RFBvSVB2NCBwYWNrZXQuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4g4oCUIENhcmxvcy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE5v dGUgdGhhdCBmb3IgTmV4dCBQcm90b2NvbCBvZiBNUExTLCBFdGhlcm5ldCBvciBOU0gsIHRoZXNl IGRvIA0KPj4+Pj4+Pj4+IG5vdCBoYXZlIHRvdGFsLWxlbmd0aCBmaWVsZHMgdGhhdCB3b3VsZCBh bGxvdyB0cmFpbGluZyBPQU0uDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gRnVydGhlcm1vcmUsIHdl IGNvdWxkIHNheSB0aGF0IGlmIE89MSwgdGhlIFNGRiBNVVNUIGRldGVybWluZSANCj4+Pj4+Pj4+ PiBpZiB0aGUgcGF5bG9hZCBpcyBhZGRyZXNzZWQgdG8gaXQsIGUuZy4sIGlmIHRoZSBuZXh0IElQ djYgDQo+Pj4+Pj4+Pj4gcGFja2V0IGlzIGFkZHJlc3NlZCB0byB0aGUgU0ZGJ3MgbG9vcC1iYWNr IGFkZHJlc3MuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gSSB0aGluayBtYW55IG9mIHVzIGFyZSBh bnhpb3VzIHRvIGdldCB0byB3b3JrIGNsYXJpZnlpbmcgdGhlc2UgDQo+Pj4+Pj4+Pj4gdGhpbmdz Lg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IC1EYXZlDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gT3Jp Z2luYWwgTWVzc2FnZQ0KPj4+Pj4+Pj4+IEZyb206IEpvZWwgTS4gSGFscGVybg0KPj4+Pj4+Pj4+ IFNlbnQ6IFNhdHVyZGF5LCBKdWx5IDIzLCAyMDE2IDg6MDIgUE0NCj4+Pj4+Pj4+PiBUbzogQ2Fy bG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+Pj4+Pj4+Pj4gQ2M6IEdyZWdvcnkgTWlyc2t5OyBy dGctb29hbS1kdEBpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6 IFtzZmNdIFtSdGctb29hbS1kdF0gSWRlbnRpZnlpbmcgT0FNIGluIE5TSA0KPj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IENhcmxvcywNCj4+Pj4+Pj4+PiAgIFllc3gsIEkgYW0gdGFs a2luZyBhYm91dCB0aGUgc2FtZSBjYXNlIHRoYXQgb3RoZXIgZm9sa3MgYXJlIA0KPj4+Pj4+Pj4+ IGNhbGxpbmcgcGlnZ3ktYmFjayBPQU0uICBJIHdhbnRlZCB0byBkZXNjcmliZSB0aGUgY2FzZSBp bnN0ZWFkIA0KPj4+Pj4+Pj4+IG9mIG5hbWluZyBpdCwgYm90aCBmb3IgY2xhcml0eSBhbmQgdG8g cmFpc2UgdGhlIHBvaW50IGFib3V0IHdobyANCj4+Pj4+Pj4+PiBuZWVkcyB0byBwcm9jZXNzIHRo ZSBPQU0gaW5mb3JtYXRpb24uDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gWW91IGFzayBob3cgdGhl IFNGIChvciBldmVuIGlmIHRoZSBTRkYgaWYgdGhhdCBhcHBsaWVzXyB3aWxsIA0KPj4+Pj4+Pj4+ IGtub3cgdGhlcmUgaXMgYSB1c2VyIHBhY2tldC4gIEkgdGhpbmsgdGhlIHByb3Bvc2FsIGlzIHRv IHVzZSANCj4+Pj4+Pj4+PiB0aGUgT0FNIGJpdCBzcGVjaWZpY2FsbHkgdG8gaW5kaWNhdGUgdGhh dC4NCj4+Pj4+Pj4+PiBUaGUgcmVzdWx0IG9mIHRoYXQgdXNhZ2UgaXMgdGhhdCB0aGUgU0ZGIG5l ZWRzIHRvIGNoZWNrIHRoZSANCj4+Pj4+Pj4+PiBwYWNrZXQgdHlwZSBpbiBvcmRlciB0byByZWNv Z25pemUgT0FNIHBhY2tldHMgdGhhdCBhcmUgbm90IHVzZXIgDQo+Pj4+Pj4+Pj4gZGF0YSBwYWNr ZXRzIGFuZCB0aGF0IGl0IG5lZWRzIHRvIHByb2Nlc3MuDQo+Pj4+Pj4+Pj4gVGhhdCBpcyBhbiB1 bmZvcnR1bmF0ZSBjb21wbGV4aXR5IGluIGEgY3JpdGljYWwgcHJvY2Vzc2luZyBwYXRoLg0KPj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEkgc3VzcGVjdCBpdCBpcyB0aGlzIGVmZmljaWVuY3kgdGhhdCBp cyBkcml2aW5nIHlvdS4NCj4+Pj4+Pj4+PiBXaGljaCBzdWdnZXN0cyBhbm90aGVyIHBvc3NpYmxl IGludGVycHJldGF0aW9uLg0KPj4+Pj4+Pj4+IFdoYXQgaWYNCj4+Pj4+Pj4+PiAxKSB3ZSBzZXQg dGhlIE9BTSBiaXQgZm9yIGFueSBwYWNrZXQgdGhhdCBuZWVkcyBPQU0gcHJvY2Vzc2luZw0KPj4+ Pj4+Pj4+IDIpIEFuZCBkZWZpbmUgYSAoc2V0IG9mKSBwYWNrZXQgdHlwZXMgZm9yIHBhY2tldHMg d2hlcmUgdGhlIA0KPj4+Pj4+Pj4+IGNvdG5lbnQgaXMgT0FNDQo+Pj4+Pj4+Pj4gMykgQW5kIGRl Y2xhcmUgdGhhdCBhbnkgb3RoZXIgcGFja2V0IHR5cGVzIGFyZSB1c2VyIHBhY2tldHMgDQo+Pj4+ Pj4+Pj4gd2l0aCBPQU0gVExWIGluZm9ybWF0aW9uLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFRo aXMgaXMgc2xpZ2h0bHkgc2ltcGxlciBpZiB3ZSBkZWNsYXJlIGEgc2luZ2xlIE9BTSBwYWNrZXQg dHlwZSANCj4+Pj4+Pj4+PiBpbiB0aGUgTlNIIGhlYWRlciwgYXMgdGhhdCBhdm9pZHMgYW55IGFt YmlndWl0eS4gIChXaGV0aGVyIHRoZSANCj4+Pj4+Pj4+PiBkZXZpY2UgY2FuIGFjdHVhbGx5IGRv IHRoZSBPQU0gc3RpbGwgZGVwZW5kcyB1cG9uIGl0IA0KPj4+Pj4+Pj4+IHVuZGVyc3RhbmRpbmcg dGhlIE9BTSBwYWNrZXRzLCBidXQgdGhhdCBpcyB0cnVlIG9mIGFsbCANCj4+Pj4+Pj4+PiBzdHJ1 Y3R1cmVzLikgIFRoaXMgZG9lcyBhdm9pZCBjcmVhdGluZyBhbnkgY29uZnVzaW9uIGJldHdlZW4g DQo+Pj4+Pj4+Pj4gdGhlIHVzZSBvZiB0aGUgT0FNIGZsYWcgYW5kIHRoZSBwYWNrZXQgdHlwZS4N Cj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBZb3VycywNCj4+Pj4+Pj4+PiBKb2VsDQo+Pj4+Pj4+Pj4g DQo+Pj4+Pj4+Pj4gT24gNy8yMy8xNiA3OjM0IFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0 YSkgd3JvdGU6DQo+Pj4+Pj4+Pj4+IEhpLCBKb2VsLA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ IE9uIEp1bCAyMywgMjAxNiwgYXQgNzo0NSBQTSwgSm9lbCBNLiBIYWxwZXJuIA0KPj4+Pj4+Pj4+ Pj4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4gVGhlcmUgaXMgb25lIHNpdHVhdGlvbiB0aGF0IGZvbGtzIGFyZSBhc2tp bmcgZm9yIHRoYXQgc2VlbXMgDQo+Pj4+Pj4+Pj4+PiBub3QgdG8gYmUgY2xlYXJseSBjb3ZlcmVk IGluIHRoZSBzcGVjLCBhbmQgYXBwZWFycyB0byBtZSB0byANCj4+Pj4+Pj4+Pj4+IGJlIGNsYXJp ZmllZCBieSBHcmVnJ3MgcHJvcG9zYWwuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IFdlIGhh dmUgaGFkIGEgY291cGxlIG9mIHJlcXVlc3RzIGZvciB0aGUgYWJpbGl0eSB0byBwdXQgT0FNIA0K Pj4+Pj4+Pj4+Pj4gbWFya2luZyBvbiB1c2VyIGRhdGEgcGFja2V0cy4gIFRoZSBtb3N0IG9idmlv dXMgdXNlIGlzIHRvIA0KPj4+Pj4+Pj4+Pj4gbW9uaXRvciBob3cgbG9uZyBpdCB0YWtlcyBOU0gt YXdhcmUgc2VydmljZSBmdW5jdGlvbnMgdG8gDQo+Pj4+Pj4+Pj4+PiBwcm9jZXNzIHRoZSB1c2Vy IHBhY2tldHMuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEp1c3QgdG8g bWFrZSBzdXJlIEkgdW5kZXJzdGFuZCwgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBjYXNlIA0K Pj4+Pj4+Pj4+PiBvZiDigJxwaWdneS1iYWNrIE9BTeKAnSwgY29ycmVjdD8NCj4+Pj4+Pj4+Pj4g DQo+Pj4+Pj4+Pj4+PiBJZiB0aGUgb25seSBjYXNlIHdoZXJlIHdlIHdpbGwgbmVlZCB0aGlzIGlz IGZvciBzZXJ2aWNlIA0KPj4+Pj4+Pj4+Pj4gZnVuY3Rpb24gcHJvY2Vzc2luZywgdGhlIHB1dHRp bmcgaXQgaW4gdGhlIFRMVnMsIHdpdGhvdXQgDQo+Pj4+Pj4+Pj4+PiBhZGRpdGlvbmFsIG1hcmtp bmdzLCBhbmQgYWxsb3dpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHdoaWNoIA0KPj4+Pj4+Pj4+ Pj4gdW5kZXJzdGFuZCB0aGUgVExWIHRvIHdvcmsgd2l0aCBpdCBzZWVtcyBzdWZmaWNpZW50Lg0K Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBCdXQgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoYXQg dGhlcmUgaXMgbm90IGEgZGVzaXJlICh3aGV0aGVyIA0KPj4+Pj4+Pj4+Pj4gaXQgaXMgYSByZXF1 aXJlbWVudCBpcyBwcm9iYWJseSBhbiBpbXBvcnRhbnQgb3BlbiBxdWVzdGlvbikgDQo+Pj4+Pj4+ Pj4+PiBmb3Igc2ltaWxhciBjYXBhYmlsaXR5IGF0IFNGRi4gIElmIHdlIGhhdmUgc2l0dWF0aW9u cyB3aGVyZSANCj4+Pj4+Pj4+Pj4+IFNGRiwgaW4gcGFzc2luZyB1c2VyIGRhdGEgcGFja2V0cywg YWxzbyBuZWVkIHRvIHBlcmZvcm0gT0FNIA0KPj4+Pj4+Pj4+Pj4gb3BlcmF0aW9ucywgdGhlbiBp dCBzZWVtcyB0byBtZSB0aGF0IHdlIG5lZWQgdGhlIE9BTSBiaXQgdG8gDQo+Pj4+Pj4+Pj4+PiB0 ZWxsIHRoZSBTRkYgdG8gbG9vayBhdCB0aGlzLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gSWYg eW91IHNldCB0aGUgTyBiaXQgaW4gYSB1c2VyIGRhdGEgcGFja2V0LCBob3cgd291bGQgYSBzeXN0 ZW0gDQo+Pj4+Pj4+Pj4+IGluZmVyIHRoYXTigJlzIG5vdCBhbiBPQU0gcGFja2V0Pw0KPj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4g4oCUIENh cmxvcy4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBFZmZvcnRzIHdpdGggcm91dGVycyB0byBk byB0aGlzIHdpdGggcm91dGVyIGFsZXJ0IG9wdGlvbnMgDQo+Pj4+Pj4+Pj4+PiBoYXZlIGJlZW4g YSBtZXNzLiBJZiB3ZSBuZWVkIHRoZSBjYXBhYmlsaXR5LCBpdCBzZWVtcyB0byBtZSANCj4+Pj4+ Pj4+Pj4+IHRoYXQgd2UgcmVhbGx5IHdhbnQgaXQgaW4gYSBzdGFuZGFyZGl6ZWQgYW5kIGVmZmlj aWVudCBwbGFjZS4NCj4+Pj4+Pj4+Pj4+IElmIHdlIGFyZSB2ZXJ5IHN1cmUgd2UgZG9uJ3QgbmVl ZCB0aGlzLCB0aGVuIHdlIHNob3VsZCB3cml0ZSANCj4+Pj4+Pj4+Pj4+IHRoYXQgZG93biwgYW5k IG1vdmUgb24uDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IFlvdXJzLA0KPj4+Pj4+Pj4+Pj4g Sm9lbA0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBPbiA3LzIzLzE2IDEyOjI0IFBNLCBDYXJs b3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4gSGksIEdyZWcsDQo+ Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IE9uIEp1bCAyMiwgMjAxNiwgYXQgMTA6MjQgQU0s IEdyZWdvcnkgTWlyc2t5IA0KPj4+Pj4+Pj4+Pj4+PiA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tIA0KPj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+ IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gSGkgQ2FybG9zLA0KPj4+Pj4+ Pj4+Pj4+PiB0aGFuayB5b3UgZm9yIHNoYXJpbmcgeW91ciBjb21tZW50cy4gSWYgSSB1bmRlcnN0 YW5kIA0KPj4+Pj4+Pj4+Pj4+PiBjb3JyZWN0bHksIHlvdSBzdWdnZXN0IHRvIGV4cG9zZSBwcm90 b2NvbCB0eXBlcyBvZiBPQU0gYXMgDQo+Pj4+Pj4+Pj4+Pj4+IE5leHQgUHJvdG9jb2wgcmF0aGVy IHRoYW4gdG8gdXNlIHNpbmdsZSBBY3RpdmUgT0FNIHByb3RvY29sIA0KPj4+Pj4+Pj4+Pj4+PiB0 eXBlIGFuZCB1c2UgT09BTSBIZWFkZXIgdG8gZGVtdXggT09BTSB0eXBlLiBUaGVuLCB0aGUgTmV4 dCANCj4+Pj4+Pj4+Pj4+Pj4gUHJvdG9jb2wgcmVnaXN0cnkgd2lsbCBoYXZlIHRvIGFsbG9jYXRl IHZhbHVlcyBmb3IgDQo+Pj4+Pj4+Pj4+Pj4+IHNpbmdsZS1ob3AgQkZELCBtdWx0aS1ob3AgQkZE LCBtdWx0aXBvaW50IEJGRCwgUy1CRkQsIEVjaG8gDQo+Pj4+Pj4+Pj4+Pj4+IFJlcXVlc3QvUmVw bHksIEFJUyBwcm90b2NvbCwgQWN0aXZlIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IA0KPj4+Pj4+ Pj4+Pj4+PiBwcm90b2NvbCwgYW5kIEnigJl2ZSBvbmx5IGxpc3RlZCBzb21lIG9mIEFPTSBwcm90 b2NvbHMgdGhhdCANCj4+Pj4+Pj4+Pj4+Pj4gbWF5IGJlIHVzZWQgdG8gb3BlcmF0ZSwgYWRtaW5p c3RlciBhbmQgbWFpbnRhaW4gU0ZQLg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IFllcywg dGhlIHByb3RvY29sIGZpZWxkIG91Z2h0IHRvIHJlZ2lzdGVyIHRoZSBPQU0gcHJvdG9jb2xzIA0K Pj4+Pj4+Pj4+Pj4+IHRoYXQgd2lsbCBiZSB1c2VkIGFuZCBpbXBsZW1lbnRlZCBhbmQgZGVwbG95 ZWQg4oCUIG9mIGNvdXJzZSANCj4+Pj4+Pj4+Pj4+PiBub3QgYWxsIHBvdGVudGlhbCB2YXJpYXRp b25zIGFuZCBwZXJtdXRhdGlvbnMgb2YgcG9zc2libGUgDQo+Pj4+Pj4+Pj4+Pj4gT0FNcyAod2hh dCBpcyBBSVMNCj4+Pj4+Pj4+Pj4+PiBwcm90b2NvbD8pDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4+IEFkZGl0aW9uYWxseSwgeW914oCZdmUgc3VnZ2VzdGVkIHRoYXQgb25seSBPLWJpdCB2 YWx1ZSB0byBiZSANCj4+Pj4+Pj4+Pj4+Pj4gdXNlZCB0byBkZXRlcm1pbmUgd2hldGhlciBwYWNr ZXQgc2hvdWxkIGJlIHByb2Nlc3NlZCBhcyBPQU0gDQo+Pj4+Pj4+Pj4+Pj4+IG9yIGRhdGEgcGFj a2V0Lg0KPj4+Pj4+Pj4+Pj4+PiBIZW5jZSBzaG91bGQgSSBleHBlY3QgdGhhdCBPLWJpdCBpcyBz ZXQgZm9yIEJGRCwgQUlTLCBhbmQgDQo+Pj4+Pj4+Pj4+Pj4+IEVjaG8gUmVxdWVzdC9SZXBseSBw YXlsb2FkIGFuZCBzaG91bGQgbm90IGJlIHNldCBpZiB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+IE5leHQg UHJvdG9jb2wgaXMgbmVpdGhlciBvZiBwcm90b2NvbHMgbGlzdGVkIGFib3ZlPyBTaG91bGQgDQo+ Pj4+Pj4+Pj4+Pj4+IHN1Y2ggc2l0dWF0aW9uLCBpLmUuDQo+Pj4+Pj4+Pj4+Pj4+IE5leHQNCj4+ Pj4+Pj4+Pj4+Pj4gUHJvdG9jb2wgdmFsdWUgaXMgTVBMUyBhbmQgTy1iaXQgc2V0IHRvIDB4MSwg c2hvdWxkIGJlIA0KPj4+Pj4+Pj4+Pj4+PiB2aWV3ZWQgYXMgZXJyb3IgYW5kIHRoZSBwYWNrZXQg ZHJvcHBlZD8gT3IgeW91IHByb3Bvc2UgdGhhdCANCj4+Pj4+Pj4+Pj4+Pj4gdGhlIE5leHQgUHJv dG9jb2wgdGFrZXMgcHJlY2VkZW5jZSBhbmQgdGhlIHBhY2tldCB0cmVhdGVkIA0KPj4+Pj4+Pj4+ Pj4+PiBhcyBkYXRhPyBPciBwYWNrZXQgdmlld2VkIGFzIE9BTSBhbmQgcGFzc2VkIHRvIHRoZSBs b2NhbCANCj4+Pj4+Pj4+Pj4+Pj4gT0FNIGVudGl0eT8gT3IgaG93IHRvIGludGVycHJldCBzaXR1 YXRpb24gd2hlbiBPLWJpdCBpcyANCj4+Pj4+Pj4+Pj4+Pj4gY2xlYXJlZCBhbmQgdGhlIE5leHQg UHJvdG9jb2wgdmFsdWUgaXMgb25lIG9mIE9BTSANCj4+Pj4+Pj4+Pj4+Pj4gcHJvdG9jb2xzPw0K Pj4+Pj4+Pj4+Pj4+PiBUaGlzIGlzIHRoZSBzaXR1YXRpb24gdGhhdCwgaW4gbXkgdmlldywgaXMg YW1iaWd1b3VzIGFuZCANCj4+Pj4+Pj4+Pj4+Pj4gdW5kZXItc3BlY2lmaWVkIGluIHRoZSBjdXJy ZW50IE5TSCBkb2N1bWVudC4gTXkgcHJvcG9zYWwgaXMgDQo+Pj4+Pj4+Pj4+Pj4+IGFuIGF0dGVt cHQgdG8gbWFrZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBPQU0gYW5kIGRhdGEgDQo+Pj4+Pj4+Pj4+ Pj4+IHBhY2tldHMgbW9yZSBkZXRlcm1pbmlzdGljLg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ Pj4+IEFuc3dlcmluZyBhbGwgdGhvc2UgcXVlc3Rpb25zICh3aGljaCBhcmUgcmVhbGx5IHNsaWdo dCANCj4+Pj4+Pj4+Pj4+PiBwZXJtdXRhdGlvbnMgb2YgdGhlIHNhbWUgcXVlc3Rpb24pIGluIG9u ZSBzaG90OiB0byBtZSwgTz0wIA0KPj4+Pj4+Pj4+Pj4+IGlzIGEgZGF0YSBwYWNrZXQgYW5kDQo+ Pj4+Pj4+Pj4+Pj4gTz0xIGlzDQo+Pj4+Pj4+Pj4+Pj4gYW4gT0FNIHBhY2tldC4gSWYgdGhlIGRh dGEgcHJvY2Vzc2luZyBkb2VzIG5vdCBoYXZlIGEgDQo+Pj4+Pj4+Pj4+Pj4gaGFuZGxlciBmb3Ig dGhlIHByb3RvY29sIGluIHRoZSBQSUQsIG9yIGl04oCZcyBhbiB1bmRlZmluZWQsIA0KPj4+Pj4+ Pj4+Pj4+IGRyb3BzIHRvIHRoZSBiaXQgYnVja2V0Lg0KPj4+Pj4+Pj4+Pj4+IEVxdWFsbHksIGlm IHRoZSBPQU0gaGFuZGxlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBwcm90b2NvbCBJRCANCj4+Pj4+ Pj4+Pj4+PiBjYXJyaWVkIGFzIE9BTSwgcHVmZi4gSVAgY2FuIGNhcnJ5IGRhdGEgb3IgT0FNIGZv ciBleGFtcGxlIA0KPj4+Pj4+Pj4+Pj4+IGJ5IHRoZSB3YXkuDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+Pj4gSXQgZG9lcyBub3QgZ2V0IGFueSBzaW1wbGVyIGFuZCB1bmFtYmlndW91cyB0aGFu IHRoYXQuIA0KPj4+Pj4+Pj4+Pj4+IFdoYXTigJlzIHRoZSBhZHZhbnRhZ2Ugb2YgbW92aW5nIHRo ZSBPQU0gUElEIGZ1cnRoZXIgaW5zaWRlPw0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IEFu ZCBJIGRvIG5vdCBiZWxpZXZlIHRoZXJl4oCZcyB1bmRlcnNwZWNpZmljYXRpb24gaW4gTlNIIC0+ IA0KPj4+Pj4+Pj4+Pj4+IE89MSwgT0FNIHRyZWF0bWVudCwgbm90IGRldGFpbGVkIGhlcmUuDQo+ Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+Pj4+IOKAlCBDYXJsb3MuDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+Pj4+PiAgICAgICAgICAgICBSZWdhcmRzLA0KPj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgR3JlZw0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gKkZyb206 KiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgDQo+Pj4+Pj4+Pj4+Pj4+IFttYWlsdG86Y3Bp Z25hdGFAY2lzY28uY29tXQ0KPj4+Pj4+Pj4+Pj4+PiAqU2VudDoqIEZyaWRheSwgSnVseSAyMiwg MjAxNiAxMDoxMCBBTQ0KPj4+Pj4+Pj4+Pj4+PiAqVG86KiBHcmVnb3J5IE1pcnNreSA8Z3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tIA0KPj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbT4+DQo+Pj4+Pj4+Pj4+Pj4+ICpDYzoqIHNmY0BpZXRmLm9yZyA8bWFp bHRvOnNmY0BpZXRmLm9yZz47IA0KPj4+Pj4+Pj4+Pj4+PiBydGctb29hbS1kdEBpZXRmLm9yZyA8 bWFpbHRvOnJ0Zy1vb2FtLWR0QGlldGYub3JnPg0KPj4+Pj4+Pj4+Pj4+PiAqU3ViamVjdDoqIFJl OiBbUnRnLW9vYW0tZHRdIElkZW50aWZ5aW5nIE9BTSBpbiBOU0gNCj4+Pj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+Pj4+IEdyZWcsDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+Pj4+Pj4gUGxlYXNlIGZpbmQgc29tZSBjb21tZW50cyBpbmxpbmUuDQo+Pj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+PiBUaHVtYiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0YXJvLg0KPj4+Pj4+ Pj4+Pj4+PiBFeGN1emUgdHlwb2ZyYXBoaWNhayBlcnJvd3MNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBPbiBKdWwgMjEsIDIwMTYsIGF0IDA5OjAxLCBHcmVn b3J5IE1pcnNreSANCj4+Pj4+Pj4+Pj4+Pj4gPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSAN Cj4+Pj4+Pj4+Pj4+Pj4gPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PiB3cm90 ZToNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IERlYXIgQWxsLA0KPj4+Pj4+Pj4+Pj4+ PiB3ZSBoYWQgdmVyeSBnb29kIGRpc2N1c3Npb24gb24gT0FNIHRoaXMgd2Vlay4gV2XigJl2ZSAN Cj4+Pj4+Pj4+Pj4+Pj4gdG91Y2hlZCBvbiAgQWN0aXZlLCBQYXNzaXZlIGFuZCBTb21ldGhpbmct aW4tYmV0d2VlbiBPQU0uIA0KPj4+Pj4+Pj4+Pj4+PiBCdXQgY2FuIE5TSCBpbmRpY2F0ZSAgd2hp Y2ggT0FNIHR5cGUsIGlmIGFueSwgYXNzb2NpYXRlZCANCj4+Pj4+Pj4+Pj4+Pj4gd2l0aCBhIHBh Y2tldD8gSSB0aGluayB0aGF0IHRoZSAgY3VycmVudCB2ZXJzaW9uIG9mIA0KPj4+Pj4+Pj4+Pj4+ PiBkcmFmdC1pZXRmLXNmYy1uc2ggZG9lcyBub3QgYWxsb3cgdGhhdCBhbmQgbWF5ICBiZSANCj4+ Pj4+Pj4+Pj4+Pj4gYW1iaWd1b3VzIGluIHNvbWUgY2FzZXMuIEkgcHJvcG9zZSBjaGFuZ2UgdG8g aW50ZXJwcmV0YXRpb24gDQo+Pj4+Pj4+Pj4+Pj4+IGFuZCAgYXBwbGljYWJpbGl0eSBkZXNjcmlw dGlvbiBvZiB0aGUgTyhBTSkgZmxhZyBhbmQgDQo+Pj4+Pj4+Pj4+Pj4+IGFsbG9jYXRpb24gb2Yg dGhlICBuZXcgcHJvdG9jb2wgdHlwZSB0byBiZSB1c2VkIGluIHRoZSBOZXh0IA0KPj4+Pj4+Pj4+ Pj4+PiBQcm90b2NvbCBmaWVsZC4NCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gQWN0aXZlLCBwYXNzaXZlIGFuZCBzb21ldGhpbmct aW4tYmV0d2VlbiBhcmUgbm90IE9BTSANCj4+Pj4+Pj4+Pj4+Pj4gcHJvdG9jb2wgdHlwZXMgYnV0 IHJhdGhlciB0aGV5IGFyZSBtZWFzdXJpbmcgbWV0aG9kcy4gDQo+Pj4+Pj4+Pj4+Pj4+IEFjdGl2 ZSBPQU0gY2FuIGluY2x1ZGUgYSBwbHVyYWxpdHkgb2YgT0FNIHByb3RvY29scywgDQo+Pj4+Pj4+ Pj4+Pj4+IGluY2x1ZGluZyBCRkQsIFMtQkZELCBzb21ldGhpbmctb3Zlci1pcCwgZXRjLg0KPj4+ Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gSSBhbHNvIGJlbGlldmUgdGhhdCB0aGUgY3VycmVu dCBPQU0gdGV4dCBpbiBOU0ggaXMgbm90IA0KPj4+Pj4+Pj4+Pj4+PiBhbWJpZ3VvdXMgYW5kIGFs bG93cyBlbm91Z2ggcHJvY2Vzc2luZyBvZiB0aGUgaGVhZGVyIHRvIA0KPj4+Pj4+Pj4+Pj4+PiB1 bmRlcnN0YW5kIHNvbWV0aGluZyBpcyBPQU0sIHdpdGhvdXQgZ29pbmcgdGhlIHNwZWNpZmljcyBv ZiANCj4+Pj4+Pj4+Pj4+Pj4gYW4gT0FNIGhhbmRsZXIuDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+Pj4+PiBUaGVyZWZvcmUsIEkgb3Bwb3NlIHRoaXMgY2hhbmdlLg0KPj4+Pj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IFJGQyA3Nzk5IGRlZmluZXMgQWN0aXZlIE9B TSBhcyBmb2xsb3dpbmc6DQo+Pj4+Pj4+Pj4+Pj4+IEFuIEFjdGl2ZSBNZXRyaWMgb3IgTWV0aG9k IGRlcGVuZHMgb24gYSBkZWRpY2F0ZWQgDQo+Pj4+Pj4+Pj4+Pj4+IG1lYXN1cmVtZW50ICBwYWNr ZXQgc3RyZWFtIGFuZCBvYnNlcnZhdGlvbnMgb2YgdGhlIHN0cmVhbS4NCj4+Pj4+Pj4+Pj4+Pj4g VGh1cywgcmVnYXJkbGVzcyBvZiBlbmNhcHN1bGF0aW9uIHVzZWQgYnkgT0FNLCBpdCBpcyB0aGUg DQo+Pj4+Pj4+Pj4+Pj4+IHBhY2tldCAgY29uc3RydWN0ZWQgc29sZWx5IGZvciBtb25pdG9yaW5n LCBtZWFzdXJpbmcgDQo+Pj4+Pj4+Pj4+Pj4+IG5ldHdvcmvigJlzIG1ldHJpYyBhbmQgIHNob3Vs ZCBub3QgbGVhdmUgZ2l2ZW4gZG9tYWluLiBBbmQsIEkgDQo+Pj4+Pj4+Pj4+Pj4+IGJlbGlldmUs IHN1Y2ggcGFja2V0cyBzaG91bGQgIGJlIGlkZW50aWZpZWQgYnkgdGhlIHByb3RvY29sIA0KPj4+ Pj4+Pj4+Pj4+PiB0eXBlIG9mIHRoZWlyIG93bi4NCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBTZWVtcyB5b3UgYXJlIGFkdm9jYXRpbmcgZm9yIGEgc2luZ2xl ICJPQU0iIHByb3RvY29sIHR5cGUgDQo+Pj4+Pj4+Pj4+Pj4+IGZvciBPQU0gcGFja2V0cy4gVGhl IGZ1bmN0aW9uYWxpdHkgb2YgaWRlbnRpZnlpbmcgc29tZXRoaW5nIA0KPj4+Pj4+Pj4+Pj4+PiBh cyBPQU0gaXMgaW4gdGhlIE8tYml0LCBzbyBubyBuZWVkIHRvIHdhc3RlIGJpdHMgaW4gDQo+Pj4+ Pj4+Pj4+Pj4+IGR1cGxpY2F0aW9uLg0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gVGhl biwgYXQgc29tZSBwb2ludCwgeW91IGhhdmUgdG8gZGlmZmVyZW50aWF0ZSBpZiBhbiBPQU0gDQo+ Pj4+Pj4+Pj4+Pj4+IGlzLCBzYXksIElQIG9yICJyYXcgQkZEIiBvciBzb21ldGhpbmcgZWxzZS4g VGhhdCdzIHdoYXQgdGhlIA0KPj4+Pj4+Pj4+Pj4+PiBQcm90b2NvbCBmaWVsZCBpcyBmb3IuDQo+ Pj4+Pj4+Pj4+Pj4+IEkgZG8gbm90IHNlZSBhIG5lZWQgdG8gYWRkIGFuIGluZGlyZWN0aW9uIGhl cmUgdG8gdGhlbiBoYXZlIA0KPj4+Pj4+Pj4+Pj4+PiB0byBoYXZlIGEgcHJvdG9jb2wgZmllbGQg aW5zaWRlIHRoZSBPQU0uDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ Pj4+Pj4gT0FNIHdoaWNoIGJlaGF2ZXMgYXMgbXVjaCBhcyBQYXNzaXZlIE9BTSBvciANCj4+Pj4+ Pj4+Pj4+Pj4gU29tZXRoaW5nLWluLWJldHdlZW4sICBlLmcuIE9BTSBhcHBlbmRlZCB0byBkYXRh IHBhY2tldCANCj4+Pj4+Pj4+Pj4+Pj4gZWl0aGVyIGF0IHRoZSBkb21haW7igJlzIGVkZ2Ugb3Ig IG9uLXRoZS1mbHksIGlkZW50aWZpZWQgYnkgDQo+Pj4+Pj4+Pj4+Pj4+IHRoZSBwcm90b2NvbCB0 eXBlIG9mIHRoZSBkYXRhIHBhY2tldCAgY2FycmllZCBpbiBOU0guDQo+Pj4+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gVGhhdCdzIGNvcnJlY3QsIHdpdGggdGhlIE8g Yml0IGNsZWFyZWQ7IGl0J3MgYSBkYXRhIHBhY2tldCANCj4+Pj4+Pj4+Pj4+Pj4gYW5kIG5vdCBh biBPQU0gb25lLg0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+ IEJlbG93IGFyZSBjaGFuZ2VzIEnigJlkIGxpa2UgdG8gcHJvcG9zZToNCj4+Pj4+Pj4+Pj4+Pj4g U2VjdGlvbiAzLjIgTy1iaXQ6DQo+Pj4+Pj4+Pj4+Pj4+IE9MRA0KPj4+Pj4+Pj4+Pj4+PiAgICBP IGJpdDogd2hlbiBzZXQgdG8gMHgxIGluZGljYXRlcyB0aGF0IHRoaXMgcGFja2V0IGlzIGFuIA0K Pj4+Pj4+Pj4+Pj4+PiBPcGVyYXRpb25zLA0KPj4+Pj4+Pj4+Pj4+PiAgICBBZG1pbmlzdHJhdGlv biBhbmQgTWFpbnRlbmFuY2UgKE9BTSkgbWVzc2FnZS4gIFRoZSANCj4+Pj4+Pj4+Pj4+Pj4gcmVj ZWl2aW5nICBTRkYgYW5kDQo+Pj4+Pj4+Pj4+Pj4+ICAgIFNGcyBub2RlcyBNVVNUIGV4YW1pbmUg dGhlIHBheWxvYWQgYW5kIHRha2UgYXBwcm9wcmlhdGUgDQo+Pj4+Pj4+Pj4+Pj4+IGFjdGlvbiAg KGUuZy4NCj4+Pj4+Pj4+Pj4+Pj4gICAgcmV0dXJuIHN0YXR1cyBpbmZvcm1hdGlvbikuICBPQU0g bWVzc2FnZSBzcGVjaWZpY3MgYW5kIA0KPj4+Pj4+Pj4+Pj4+PiBoYW5kbGluZw0KPj4+Pj4+Pj4+ Pj4+PiAgICBkZXRhaWxzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0K Pj4+Pj4+Pj4+Pj4+PiBFTkQNCj4+Pj4+Pj4+Pj4+Pj4gTkVXDQo+Pj4+Pj4+Pj4+Pj4+IE8gYml0 OiB3aGVuIHNldCB0byAweDEgaW5kaWNhdGVzIHRoYXQgZGF0YSBwYWNrZXQgDQo+Pj4+Pj4+Pj4+ Pj4+IGlkZW50aWZpZWQgYnkgIHRoZSBOZXh0ICBQcm90b2NvbCB0eXBlIGhhcyBPQU0gbWV0YWRh dGEgDQo+Pj4+Pj4+Pj4+Pj4+IGFwcGVuZGVkLg0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IE5vLiBJZiBpdCBpcyBhIGRhdGEgcGFja2V0IGl0IGRvZXMgbm90 IGhhdmUgdGhlIE8gYml0IHNldCANCj4+Pj4+Pj4+Pj4+Pj4gKHRvIDEgb3IgdG8gd2hpY2hldmVy IG90aGVyIHBvc3NpYmxlIHZhbHVlIGZvciB0aGUgYml0IDotKQ0KPj4+Pj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4+Pj4gVGhlIGdvYWwgaXMgdGhhdCBsb29raW5nIGF0IGEgc2luZ2xlIGJ1dCBpdCBj YW4gYmUgDQo+Pj4+Pj4+Pj4+Pj4+IHVuZGVyc3Rvb2QgaWYgaXQgaXMgYSBkYXRhIHBhY2tldCAo d2hpY2ggY2FuIGJlIHVzZWQsIA0KPj4+Pj4+Pj4+Pj4+PiBtYXJrZWQsIGV0Yy4gdG8gYmUgdXNl ZCBmb3IgT0FNIHB1cnBvc2VzLCBvciBub3QpLg0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ Pj4gV2UgZG8gbm90IHdhbnQgT0FNIGRpcmVjdCBleGNlcHRpb24gcHJvY2Vzc2luZyBmb3IgZGF0 YSANCj4+Pj4+Pj4+Pj4+Pj4gcGFja2V0cy4NCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+PiBEZWZpbml0aW9uIG9mIHRoZSBmb3JtYXQocykgIHVzZWQgYnkgT0FN IG1ldGFkYXRhIGlzIA0KPj4+Pj4+Pj4+Pj4+PiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50Lg0KPj4+Pj4+Pj4+Pj4+PiBFTkQNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+ IEF0IHRoZSBlbmQgb2YgU2VjdGlvbiAzLjI6DQo+Pj4+Pj4+Pj4+Pj4+IE9MRA0KPj4+Pj4+Pj4+ Pj4+PiAgICBUaGlzIGRyYWZ0IGRlZmluZXMgdGhlIGZvbGxvd2luZyBOZXh0IFByb3RvY29sIHZh bHVlczoNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+ICAgIDB4MSA6IElQdjQNCj4+Pj4+ Pj4+Pj4+Pj4gICAgMHgyIDogSVB2Ng0KPj4+Pj4+Pj4+Pj4+PiAgICAweDMgOiBFdGhlcm5ldA0K Pj4+Pj4+Pj4+Pj4+PiAgICAweDQ6IE5TSA0KPj4+Pj4+Pj4+Pj4+PiAgICAweDU6IE1QTFMNCj4+ Pj4+Pj4+Pj4+Pj4gICAgMHg2LTB4RkQ6IFVuYXNzaWduZWQNCj4+Pj4+Pj4+Pj4+Pj4gICAgMHhG RS0weEZGOiBFeHBlcmltZW50YWwgIEVORCAgTkVXDQo+Pj4+Pj4+Pj4+Pj4+ICAgIFRoaXMgZHJh ZnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nIE5leHQgUHJvdG9jb2wgdmFsdWVzOg0KPj4+Pj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gICAgMHgxIDogSVB2NA0KPj4+Pj4+Pj4+Pj4+PiAgICAweDIg OiBJUHY2DQo+Pj4+Pj4+Pj4+Pj4+ICAgIDB4MyA6IEV0aGVybmV0DQo+Pj4+Pj4+Pj4+Pj4+ICAg IDB4NDogTlNIDQo+Pj4+Pj4+Pj4+Pj4+ICAgIDB4NTogTVBMUw0KPj4+Pj4+Pj4+Pj4+PiAgICAw eDY6IEFjdGl2ZSBPQU0NCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ Pj4+PiBBcyBwZXIgYWJvdmUgSSBkbyBub3QgYmVsaWV2ZSB0aGVyZSdzIGEgc2luZ2xlIE9BTSBw cm90b2NvbC4NCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiAg ICAweDctMHhGRDogVW5hc3NpZ25lZA0KPj4+Pj4+Pj4+Pj4+PiAgICAweEZFLTB4RkY6IEV4cGVy aW1lbnRhbCAgRU5EDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBBbmQsIGNvbnNlcXVl bnRseSwgc2VjdGlvbiAxMy4yLjUgaW4gSUFOQSBDb25zaWRlcmF0aW9ucyANCj4+Pj4+Pj4+Pj4+ Pj4gc2VjdGlvbiAgd2lsbCByZXF1ZXN0IGFsbG9jYXRpb24gb2YgdmFsdWUgMHg2IHRvIGJlIA0K Pj4+Pj4+Pj4+Pj4+PiBhc3NpZ25lZCB0byBBY3RpdmUgT0FNICBwcm90b2NvbHMuDQo+Pj4+Pj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBHcmVhdGx5IGFwcHJlY2lhdGUgeW91ciBjb25zaWRlcmF0 aW9uIGFuZCBjb21tZW50cy4NCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gTXkg4oKsMC4wMi4NCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IENhcmxvcy4N Cj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAg ICAgICAgUmVnYXJkcywNCj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBHcmVnDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+ Pj4+Pj4gUnRnLW9vYW0tZHQgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+Pj4+IFJ0Zy1vb2FtLWR0 QGlldGYub3JnIDxtYWlsdG86UnRnLW9vYW0tZHRAaWV0Zi5vcmc+ICANCj4+Pj4+Pj4+Pj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGctb29hbS1kdA0KPj4+Pj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4+Pj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4+PiBzZmNAaWV0Zi5v cmcNCj4+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+Pj4+ IA0KPj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBzZmNA aWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+PiANCj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2Zj IG1haWxpbmcgbGlzdA0KPj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNm Y0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4gDQo+IA0KPiAtLQ0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQo+IEFsd2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUg dW5pcXVlLi4uanVzdCBsaWtlIGV2ZXJ5b25lIGVsc2UuLi4NCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4g c2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNm YyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Wed Aug 10 16:34:28 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 C10BC12D618; Wed, 10 Aug 2016 16:34:23 -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: <147087206378.13543.3560135891697576240.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2016 16:34:23 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 23:34:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Service Function Chaining Use Cases In Data Centers Authors : Surendra Kumar Mudassir Tufail Sumandra Majee Claudiu Captari Shunsuke Homma Filename : draft-ietf-sfc-dc-use-cases-05.txt Pages : 23 Date : 2016-08-10 Abstract: Data center operators deploy a variety of layer 4 through layer 7 service functions in both physical and virtual form factors. Most traffic originating, transiting, or terminating in the data center is subject to treatment by multiple service functions. This document describes use cases that demonstrate the applicability of Service Function Chaining (SFC) within a data center environment and provides SFC requirements for data center centric use cases, with primary focus on Enterprise data centers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-dc-use-cases-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 15 12:25: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 B4A9412D0BF; Mon, 15 Aug 2016 12:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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.247, 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 1LWtYg0MpukL; Mon, 15 Aug 2016 12:25:11 -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 BDF2A126D74; Mon, 15 Aug 2016 12:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4422; q=dns/txt; s=iport; t=1471289110; x=1472498710; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8HyHKzjjCvmg+GgGBjh1yU1MJAY1KsDFxLYHupbnPUI=; b=ak3M3JS7hm9rgVvbZvGZ5ieOt/8/dzvNqrEm7bw8B7o+VDGUiS+T5C6G RjQDo1A0GlpL7RDGcEjP+PHt8WpyThycVAZcHjHerZAjcB9Ygz3QAJDkn 4E/2TBDOeJy43ZTjElYH+bLTewKthhocWzIySwzdJEsc1JZmBzG07JcPp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAgDYFrJX/4QNJK1eg0VWfAe5PYF9J?= =?us-ascii?q?IV5AoFROBQCAQEBAQEBAV4nhF4BAQUBARtKBwsMBAIBCBEDAQIBLicLHQgCBAE?= =?us-ascii?q?NBYgxDr4KAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoRNhECFWwWIKIVzC4VUh?= =?us-ascii?q?UQBhh2IeIFrhFuDMoVLjDeDdwEeNoN6bgGGJH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,526,1464652800"; d="scan'208";a="136089591" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Aug 2016 19:25:09 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u7FJP90Z019195 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Aug 2016 19:25:09 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; Mon, 15 Aug 2016 15:25:08 -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; Mon, 15 Aug 2016 15:25:08 -0400 From: "Carlos Pignataro (cpignata)" To: Kengo NAITO , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHR2/NWSmrp/HqhJUW/Rjs6qdOdRaBKnY+A Date: Mon, 15 Aug 2016 19:25:08 +0000 Message-ID: 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> <6513b6fb-959f-c100-81bc-944744879e40@nttv6.jp> In-Reply-To: <6513b6fb-959f-c100-81bc-944744879e40@nttv6.jp> 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.150.50.163] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6170DB6FC7291F49821DA0B2D401B0F5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 15 Aug 2016 19:25:13 -0000 Naito san, Many thanks for your useful and insightful comments! I believe we incorporated most/all comments and suggestions into a new revision, at: URL: =20 https://www.ietf.org/internet-drafts/draft-penno-sfc-appid-05.txt Status: https://datatracker.ietf.org/doc/draft-penno-sfc-appid/ Htmlized: https://tools.ietf.org/html/draft-penno-sfc-appid-05 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-appid-0= 5 Thanks again! =8B Carlos. -----Original Message----- From: Kengo Naito Date: Tuesday, July 12, 2016 at 12:10 AM To: "sfc@ietf.org" Cc: "draft-penno-sfc-appid@ietf.org" , Jim Guichard Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Resent-From: Resent-To: , Benoit Claise , , Carlos Pignataro Resent-Date: Tuesday, July 12, 2016 at 12:10 AM >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 > >--=20 >------------------------------------------------ >Kengo NAITO >Technology Development >NTT Communications Corporation >Tel: +81-50-3813-6053 >E-mail: k.naito@nttv6.jp >------------------------------------------------ From nobody Tue Aug 16 20: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 ABF0812D641; Tue, 16 Aug 2016 20:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 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.247, 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 eo3vsR9w3Pzc; Tue, 16 Aug 2016 20:39:57 -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 D8BF512D10D; Tue, 16 Aug 2016 20:39:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUM23617; Wed, 17 Aug 2016 03:39:54 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 17 Aug 2016 04:39:51 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Tue, 16 Aug 2016 20:39:46 -0700 From: Linda Dunbar To: "mohamed.boucadair@orange.com" , "draft-ietf-sfc-hierarchical@ietf.org" , "sfc@ietf.org" Thread-Topic: comments to draft-ietf-sfc-hierarchical-00 Thread-Index: AdH4Iyt0LnbnJ00eQcCm0BUVCiQUSQ== Date: Wed, 17 Aug 2016 03:39:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F14AB8@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.49] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F14AB8dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57B3DC8B.000F, 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: 04d9592336fdabdcc0f983ec439d5215 Archived-At: Subject: [sfc] comments to draft-ietf-sfc-hierarchical-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 17 Aug 2016 03:40:00 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F14AB8dfweml501mbb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authors of draft-ietf-sfc-hierarchical-00: Here are my comments after reviewing the draft-ietf-sfc-hierarchical-00: - Section 2.2: o Is the "SFC-encapsulated" same as "NSH-encapsulated"? o If the packets entering the sub-domain are already "SFC-encapsulated", = I assume that the packets exiting the sub-domain is also "SFC-encapsulated"= . Correct? Should add some references on the actions done by the "egress = IBN" to restore it to the original SFC SHIM. - Section 3.1: o Does the phrase "after exiting a path in the sub-domain" mean packets l= eaving a sub-domain? If yes, what circumstance will cause "nesting NSH head= er" (does it mean adding a new NSH header)? - Section 3.1.1 (Page 8): Why "State cannot be created by packets ar= riving from lower-level chain? o There could be many types of "states" by SF. How can you generalize wha= t packets can restore the " state"? - Section 3.1.4: what kind of use cases will trigger nesting NSH? Th= e Figure 3 has 3 layers of NSH, greatly increase the likelihood of packet f= ragmentation. I am curious of what cases need multiple layers of NSH header= . NSH is not same as MPLS label (which can be nested because of much smalle= r number of bytes) . - Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657F14AB8dfweml501mbb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Authors of draft-ietf-sfc-hierarchical-00:

 

Here are my comments after reviewing the draft-ietf-= sfc-hierarchical-00:

 

-     &= nbsp;   Section 2.2:  

o   Is the “SFC-encapsulated” same a= s “NSH-encapsulated”?

o   If the packets entering the sub-domain are a= lready “SFC-encapsulated”, I assume that the packets exiting th= e sub-domain is also “SFC-encapsulated”. Correct? Should add so= me references on the  actions done by the  “egress IBN̶= 1; to restore it to the original SFC SHIM.

-     &= nbsp;  Section 3.1:

o   Does the phrase “after exiting a path = in the sub-domain” mean packets leaving a sub-domain? If yes, what ci= rcumstance will cause “nesting NSH header” (does it mean adding= a new NSH header)?  

-     &= nbsp;  Section 3.1.1 (Page 8): Why “State cannot be = created by packets arriving from lower-level chain?

o   There could be many types of “states&#= 8221; by SF. How can you generalize what packets can restore the “ st= ate”?

 

-     &= nbsp;  Section 3.1.4: what kind of use cases will trigger = nesting NSH? The Figure 3 has 3 layers of NSH, greatly increase the likelih= ood of packet fragmentation. I am curious of what cases need multiple layer= s of NSH header. NSH is not same as MPLS label (which can be nested because of much smaller number of bytes= ) .

-     &= nbsp;   

 

Cheers, =

 

Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657F14AB8dfweml501mbb_-- From nobody Thu Aug 18 23:30: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 41F7112D82D for ; Thu, 18 Aug 2016 23:30:08 -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 wp2UvsomnVbE for ; Thu, 18 Aug 2016 23:30:06 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB77312D82B for ; Thu, 18 Aug 2016 23:30:05 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id q128so21738004wma.1 for ; Thu, 18 Aug 2016 23:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=M+YCtxNvI6TNXSCUsJe6/kPOFo2oYKZ9H9BV8V2rc/w=; b=edO+NcabV6M4nIVgQApWrcSt0IXnaN7JQralEeMVWSlyEvIzkZsglhnGSKnMDFUzLc 3A8kF3ufqfmiCLwBvjaLSyT/sIksyItgMrsUBVBB0gzJ5TTOHpVRxlN+KRJ0uanpM3Xi J0JmFlcgUAohHvmFJ8OIifQpdghvO3NIhfLapF8cni31X4dyZ7APAWyHOa+GoL48xCRt S/hwmQ9v+D3hYIKQYk2O27XseZjEEIQwdEDFRjRkXpSDGRBakM4XQ9LoiEzFp114R6J4 em0eVmLjcBqJpOh0ZeCdMdH7z0e1eKDhjhvOI/hzHrUyx7eaKPz7ToRubp+Mp8P6GgSn H80Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=M+YCtxNvI6TNXSCUsJe6/kPOFo2oYKZ9H9BV8V2rc/w=; b=HY7PeHITrZT4KT8vewLxARQzuCUZFOawOKKrWh9WVmx84UQCXcYgjeN2dbJkDEFWDF kH2eGQSPS6DVbQn5+c4fdF8zskkm2c2+F3xFHSfzEktguQ2IKagB3ag9+ilWDC18rnaO T8ritlNRuEwG9B2EHEfT4l7volmdtOwe9yQ+Us4yIn81az/rLRqPVuqcbIAcip2V+Zsx CJMCNyMg5MtjyQthZgEngPQCGXPnkKjFi6YdKR0pyFfeuOMxewm9HDKG4dGRPgOjCv1Q 3V8rOOwXldWiXEigR08DNGDKqmiweKTsUcf4Ep0PYEDpx9APkbNKcaJ7hdVMEThUULHY aouA== X-Gm-Message-State: AEkoouuORZzXYU4AHK65F9DNdBRwjbapeH7/21/7iJZ6nzEf54Q8Wnh/i1FNRZgmJ9+leA== X-Received: by 10.194.113.105 with SMTP id ix9mr5694115wjb.30.1471588204043; Thu, 18 Aug 2016 23:30:04 -0700 (PDT) Received: from ?IPv6:2003:74:cf77:d032:1ded:83e2:ce80:1448? (p2003000615487B321DED83E2CE801448.dip0.t-ipconnect.de. [2003:6:1548:7b32:1ded:83e2:ce80:1448]) by smtp.googlemail.com with ESMTPSA id q137sm2854695wmd.19.2016.08.18.23.30.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Aug 2016 23:30:02 -0700 (PDT) To: sfc@ietf.org From: Martin Stiemerling Message-ID: <56c210b7-3d5c-0b4d-143f-dfea42424d31@gmail.com> Date: Fri, 19 Aug 2016 08:30:01 +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] Security in SFC -- the rough structure X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Aug 2016 06:30:09 -0000 Hi all, I have the task to look for the security in SFC and in its parts, as probably noted during the last SFC session in Berlin. Here a few words about the intended structure for the security in SFC (which has been proven to be effective in many other WGs): Each document has its own Security Considerations section and has to detail the specific attack vectors possible and possible mitigations for the technical solution outlined in such a particular document. It is not sufficient to just say look elsewhere for any answer to security considerations. It can be ok to cite other existing work for parts of the solution. Furhter, there is the design team (and you as working group) that should be working on the overall security considerations. Currently this is being worked on in draft-mglt-sfc-security-environment-req. This document should consider the whole system of SFC with all its parts and describe attack vectors and possible mitigations to these. There is also the need to document the relationships between the various attackes and mitigations in the overall security considertations. Regards, Martin (SFC co-chair) From nobody Thu Aug 18 23:37: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 E44E412D61F for ; Thu, 18 Aug 2016 23:37:52 -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 W_jm9vWs3FKx for ; Thu, 18 Aug 2016 23:37:51 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD6312B015 for ; Thu, 18 Aug 2016 23:37:50 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id i5so25976344wmg.0 for ; Thu, 18 Aug 2016 23:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=fFamcNe9w2wvPc7hd7PrZCkp0gNynRO2SAOXC9qJybo=; b=gV2Xx0WwQRKiyXC/DEQDMOysyo3ul6HBfiymJnSTOg4Ed34AaFL+pV7WEJm6elRP7D vYiGfkT45MS8ZXBOgaiXaCOxue7/RzcMtmEuDiQNUy3dG68YjnpvGzhhNPvc/sugRm5P hPa/HRfiCx8us5L18lfjYcEmqdpeJLI8+4nmTnL7vh6GnrLJqg+0tMT8LNajIVpTvAF0 KbZc96QcJ52l7OKHy1/lYwP7NJ5PTHaXm8jk794KxbntGI0esvVpZUE2HxjMEiWskGN5 I6VT0H+YdlnGzZyS6iGIt1fOygfmWaoyknKkw5YlfrdMrzG7BFWWIrTWzL7rKLkG6xgf b1qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=fFamcNe9w2wvPc7hd7PrZCkp0gNynRO2SAOXC9qJybo=; b=lbfcalqA79bkY8RF4hetABfHOC+6Db3X7wx26Xz562Mz/b0nqf7k2YhPaExWALMiZt A4t8GJlnscwFpzHvpRgL0hMFIEFTAzGWndP9Erqk9fqHAHpG94WqT7Rr+pVtvJNHR+ey s+O0u6bPp/RxAAMpLz2HBuMvPMUlAjkA3DboI6fkCRoJGUBV9+zNL4ZGqjSno8vy/eOc PpTfjzfa1lpCGYCVbydl8XfxnxRIFOJdRHxQ1BM+hbo9qLbCKD9DOvwZy1OrLqGUhX0M 1C2UW+kU5F+5mX8joa5WYVrMrPzCAUeyvTsBkcV0hrRLavwHm0jhWjEcpF1jlFtLMilj tsGQ== X-Gm-Message-State: AEkooutlfV/0lxtyYymJNAmdLP6V87lrU9uYnrRE8lSm8sACCiZfts64iiITXKR/lU6kcw== X-Received: by 10.194.148.81 with SMTP id tq17mr5618435wjb.67.1471588668727; Thu, 18 Aug 2016 23:37:48 -0700 (PDT) Received: from ?IPv6:2003:74:cf77:d032:1ded:83e2:ce80:1448? (p2003000615487B321DED83E2CE801448.dip0.t-ipconnect.de. [2003:6:1548:7b32:1ded:83e2:ce80:1448]) by smtp.googlemail.com with ESMTPSA id kq2sm5524870wjc.41.2016.08.18.23.37.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Aug 2016 23:37:47 -0700 (PDT) To: sfc@ietf.org From: Martin Stiemerling Message-ID: <03133b79-963a-36d1-63b0-838fcaaf9533@gmail.com> Date: Fri, 19 Aug 2016 08:37:46 +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] Security Considerations in draft-ietf-sfc-nsh-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Aug 2016 06:37:53 -0000 Dear all, I am in the process of reviewing the different documents with respect to security and did run through RFC 7665. RFC 7665 is doing a pretty good job in highlighting the areas of interest with respect to SFC security. However, I am shocked by what is document (or better *not* documented) in the NSH draft. Right now the security considerations section says this: "As with many other protocols, NSH data can be spoofed or otherwise modified. In many deployments, NSH will be used in a controlled environment, with trusted devices (e.g. a data center) thus mitigating the risk of unauthorized header manipulation. NSH is always encapsulated in a transport protocol and therefore, when required, existing security protocols that provide authenticity (e.g. RFC 2119 [RFC6071]) can be used. Similarly if confidentiality is required, existing encryption protocols can be used in conjunction with encapsulated NSH. Further security considerations are discussed in [nsh-sec]." This is handwaiving and will not survive any stage of WG external review. So we as WG are better working on this now! Three ideas to get the discussion started: - The usage of NSH may increase the usage of IP fragments. This can lead to security issues, but potentially in the reverse, as a number of firewalls are blocking IP fragments. See also RFC 1858. This may be worth to document. - NSH can be encapsulated in different "transports", e.g., GRE, Ethernet, VXLAN, etc. This has also implications and mainly it will ok to say that these encapsulations have also security considerations that have to be properly obyed. - NSH is going to carry meta data that is linked to Personally Identifiable Information (PII). How is NSH dealing with this? This has to be mentioned and the solution has to be documented. There are more issues to think about, of course. Regards, Martin From nobody Fri Aug 19 09:04: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 7108112D0BB for ; Fri, 19 Aug 2016 09:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMmPh8AO3_QG for ; Fri, 19 Aug 2016 09:04:53 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF0312B04C for ; Fri, 19 Aug 2016 09:04:52 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 74so87699539uau.0 for ; Fri, 19 Aug 2016 09:04:52 -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=DMdxOtiEVtVgbAl+oENIcxR4OG15tR+dOozN/KwWK9w=; b=oPDuACQw2O22B3/eD7JXSunKsbruE0C7rnVnuvUg9Z8YBEpfn4tWxlK1UrhnuYRpCf M8VMasXDlhvtZGnx+7VNmgDxDntspPvhXDXVSHzxjRMzsl2sDne9DHW4UDwplT6HUwYS DxOL04kc8+853XRTV8hp2uq99Coc7IaYYQX2PhApFbGbQBq7SOUV6N/5Ej4x3rjPmOCW J7LpUQp8qqqHiAKwR+vqlsZHcUUHhbJ3z31FpD9wTNLaTNlxvZhM8SgQovx3g2gVyf7F KNDQze51RdrKkgbW1v8mv4jREjjxQQX5R87/lcESHKJvHAt3KSCNHm9TUaVchtds8hbw rXsw== 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=DMdxOtiEVtVgbAl+oENIcxR4OG15tR+dOozN/KwWK9w=; b=Ge2JwxN80X0UcRJo4U6+AgdwxToPnziCA5/EHHT00Pe5vV+MCXKMbEqgtbr3g9fe6h xWlu0DlmmwYA+YIOUib+O17yD0D2Prl8NJgHhoO3tVUU8turF7K/YGM3U3nrpLUljs2X MpZxAygu/foeuNJzG+WAY9K2auakiviUKnfIik1SNGrtZ7ON42RaL1Y972CycZBjcUs1 YDjmkEkV6B9CXQGtpIbaDQ6ZXZSQCsaY5xtHFiWOLqXik51NfUa4hG1krk0tvQIoBy6Y xnqk+TJMBETp581yQqm55OQ7dnd27X/ZLqpQo4AZmQHggv20A2C4w1z0O0HnPr3nzOTd XFtA== X-Gm-Message-State: AEkoout4Xd6ahsx1OvAmth9VTHX82ls6UgsbeniaNC29yaxSmZdA7uMTN4DMZu1DfKddljdYHesn30IWk1fBmQ== X-Received: by 10.159.35.115 with SMTP id 106mr4352242uae.78.1471622691917; Fri, 19 Aug 2016 09:04:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.167 with HTTP; Fri, 19 Aug 2016 09:04:51 -0700 (PDT) In-Reply-To: <03133b79-963a-36d1-63b0-838fcaaf9533@gmail.com> References: <03133b79-963a-36d1-63b0-838fcaaf9533@gmail.com> From: Behcet Sarikaya Date: Fri, 19 Aug 2016 11:04:51 -0500 Message-ID: To: Martin Stiemerling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Security Considerations in draft-ietf-sfc-nsh-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 16:04:54 -0000 Hi Martin, On Fri, Aug 19, 2016 at 1:37 AM, Martin Stiemerling wrote: > Dear all, > > I am in the process of reviewing the different documents with respect to > security and did run through RFC 7665. RFC 7665 is doing a pretty good job > in highlighting the areas of interest with respect to SFC security. > > However, I am shocked by what is document (or better *not* documented) in > the NSH draft. Right now the security considerations section says this: > > "As with many other protocols, NSH data can be spoofed or otherwise > modified. In many deployments, NSH will be used in a controlled > environment, with trusted devices (e.g. a data center) thus > mitigating the risk of unauthorized header manipulation. > > NSH is always encapsulated in a transport protocol and therefore, > when required, existing security protocols that provide authenticity > (e.g. RFC 2119 [RFC6071]) can be used. > > Similarly if confidentiality is required, existing encryption > protocols can be used in conjunction with encapsulated NSH. > > Further security considerations are discussed in [nsh-sec]." > > This is handwaiving and will not survive any stage of WG external review. So > we as WG are better working on this now! > > Three ideas to get the discussion started: > - The usage of NSH may increase the usage of IP fragments. This can lead to > security issues, but potentially in the reverse, as a number of firewalls > are blocking IP fragments. See also RFC 1858. This may be worth to document. > > - NSH can be encapsulated in different "transports", e.g., GRE, Ethernet, > VXLAN, etc. This has also implications and mainly it will ok to say that > these encapsulations have also security considerations that have to be > properly obyed. > > - NSH is going to carry meta data that is linked to Personally Identifiable > Information (PII). How is NSH dealing with this? This has to be mentioned > and the solution has to be documented. > We do have some metadata that is linked to Personally Identifiable Information in https://tools.ietf.org/id/draft-sarikaya-sfc-hostid-serviceheader-03.txt Also in this draft we have a Privacy Considerations section which deals with it. I think that it should be left into the individual documents to deal with security and privacy issues for the metadata that they define. I think you alluded to this in your next mail, which we concur. Regards, Behcet > There are more issues to think about, of course. > > Regards, > > Martin > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Aug 19 09:40: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 9CB4A12D12F for ; Fri, 19 Aug 2016 09:40:38 -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 e5GXOOXzIGo2 for ; Fri, 19 Aug 2016 09:40:36 -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 C4B5D12D169 for ; Fri, 19 Aug 2016 09:40:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7F73E1C0B68; Fri, 19 Aug 2016 09:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1471624836; bh=Ehjfz+TsxcNAHpfEt6uunMktlovMy8rG5A52ANehRYA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ozXU2gmHuTxuoutMr0vWOvkxU4zYcqNA51v29UwBp9tw7SBy4wtTwwRHrVU5PUTIH 2sObB6jCRUrHuDA/JPGguZhMrMVgBmlG7Z7+a3oyDdBcVr7RYK+4Br7/0cb7SJ1nna vnOCaT2FjNWHXyY5gVLpTSdJprikAYTkXE0YpG1w= 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 0408A1C0AF8; Fri, 19 Aug 2016 09:40:35 -0700 (PDT) To: sarikaya@ieee.org, Martin Stiemerling References: <03133b79-963a-36d1-63b0-838fcaaf9533@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 19 Aug 2016 12:43:02 -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: Cc: "sfc@ietf.org" Subject: Re: [sfc] Security Considerations in draft-ietf-sfc-nsh-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Aug 2016 16:40:38 -0000 I can not find the original email from Martin. The security considerations section was discussed during the IETF meeting in Berlin. The next revision of the draft will have more explanation of what we are and are not commiting to in the base spec regarding security. This includes a recapitulation of the recommendations regarding metadata from the architecture document, and observations as to why we expect that we can cover security issues when they are needed with the current header structure. Yours, Joel On 8/19/16 12:04 PM, Behcet Sarikaya wrote: > Hi Martin, > > > On Fri, Aug 19, 2016 at 1:37 AM, Martin Stiemerling wrote: >> Dear all, >> >> I am in the process of reviewing the different documents with respect to >> security and did run through RFC 7665. RFC 7665 is doing a pretty good job >> in highlighting the areas of interest with respect to SFC security. >> >> However, I am shocked by what is document (or better *not* documented) in >> the NSH draft. Right now the security considerations section says this: >> >> "As with many other protocols, NSH data can be spoofed or otherwise >> modified. In many deployments, NSH will be used in a controlled >> environment, with trusted devices (e.g. a data center) thus >> mitigating the risk of unauthorized header manipulation. >> >> NSH is always encapsulated in a transport protocol and therefore, >> when required, existing security protocols that provide authenticity >> (e.g. RFC 2119 [RFC6071]) can be used. >> >> Similarly if confidentiality is required, existing encryption >> protocols can be used in conjunction with encapsulated NSH. >> >> Further security considerations are discussed in [nsh-sec]." >> >> This is handwaiving and will not survive any stage of WG external review. So >> we as WG are better working on this now! >> >> Three ideas to get the discussion started: >> - The usage of NSH may increase the usage of IP fragments. This can lead to >> security issues, but potentially in the reverse, as a number of firewalls >> are blocking IP fragments. See also RFC 1858. This may be worth to document. >> >> - NSH can be encapsulated in different "transports", e.g., GRE, Ethernet, >> VXLAN, etc. This has also implications and mainly it will ok to say that >> these encapsulations have also security considerations that have to be >> properly obyed. >> >> - NSH is going to carry meta data that is linked to Personally Identifiable >> Information (PII). How is NSH dealing with this? This has to be mentioned >> and the solution has to be documented. >> > > We do have some metadata that is linked to Personally Identifiable > Information in > https://tools.ietf.org/id/draft-sarikaya-sfc-hostid-serviceheader-03.txt > > Also in this draft we have a Privacy Considerations section which deals with it. > > I think that it should be left into the individual documents to deal > with security and privacy issues for the metadata that they define. > I think you alluded to this in your next mail, which we concur. > > Regards, > > Behcet >> There are more issues to think about, of course. >> >> Regards, >> >> Martin >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Aug 19 18:55: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 4513412D1B9 for ; Fri, 19 Aug 2016 18:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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.247, 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 mhYCxwma76br for ; Fri, 19 Aug 2016 18:54:57 -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 0D96E12B076 for ; Fri, 19 Aug 2016 18:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3220; q=dns/txt; s=iport; t=1471658096; x=1472867696; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=L1kbLe/A/Bf6NhWaV//NBh4vfqjcmT3nVLNxt0grhI8=; b=k72ahpqLOOAcu3rPfN5rgZORNX4krgDzmN0Qrqk8N9NqxutpccjrHYjf siPntIMQVS9ZKL4/C17RwS7BrOboi6AzjQPBv2z7jOSU9QVajfihswDld 9VIyC8nNCIj+9VGzIwp9IckrBULfCkijhXAz2tjKUNIq/qjB36N44w075 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AgBgt7dX/40NJK1eg0RWfAe3bIF9J?= =?us-ascii?q?oV3AhyBSjgUAgEBAQEBAQFeHAuEXgEBBSMRMxAOBAIBCBEEAQEDAiMDAgICMBQ?= =?us-ascii?q?BBgEBBQMCBBMIiCkOqwWPdQEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAol2h0GCW?= =?us-ascii?q?gWOHospAYYfiHiBck6EDokFhmmFVYN3AR42g3pwAYYufwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,547,1464652800"; d="scan'208";a="142530225" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2016 01:54:56 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u7K1suJW013172 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 20 Aug 2016 01:54:56 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 19 Aug 2016 20:54:55 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Fri, 19 Aug 2016 20:54:55 -0500 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-sfc-nsh-forwarding-01.txt Thread-Index: AQHR+oQIrHBXoG9gOEqg1l224TWt0qBRFlQg Date: Sat, 20 Aug 2016 01:54:55 +0000 Message-ID: References: <147165731169.24256.14082673936338943868.idtracker@ietfa.amsl.com> In-Reply-To: <147165731169.24256.14082673936338943868.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.10.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-nsh-forwarding-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: Sat, 20 Aug 2016 01:54:59 -0000 QSByZXZpc2lvbiB1cGRhdGUsIHdpdGggYSBmZXcgdHlwb3MgZml4ZWQuDQoNClJlZ2FyZHMsDQpT dXJlbmRyYS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBG cmlkYXksIEF1Z3VzdCAxOSwgMjAxNiA2OjQyIFBNDQpUbzogRG9uZ2tlZSBMZWUgPGRvbmdrZWUu bGVlQHNrLmNvbT47IFBldGVyIEJvc2NoIChwYm9zY2gpIDxwYm9zY2hAY2lzY28uY29tPjsgUHJh dmVlbiBNdWxleSA8cHJhdmVlbi5tdWxleUBub2tpYS5jb20+OyBSYWplZXYgTWFudXIgPHJtYW51 ckBicm9hZGNvbS5jb20+OyBKb2VsIE0uIEhhbHBlcm4gPGpvZWwuaGFscGVybkBlcmljc3Nvbi5j b20+OyBTdW1hbmRyYSBNYWplZSA8cy5tYWplZUBmNS5jb20+OyBTdXJlbmRyYSBLdW1hciAoc21r dW1hcikgPHNta3VtYXJAY2lzY28uY29tPjsgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpIDxzbWt1 bWFyQGNpc2NvLmNvbT47IEpvZWwgSGFscGVybiA8am9lbC5oYWxwZXJuQGVyaWNzc29uLmNvbT47 IEtlbnQgTGV1bmcgKGtsZXVuZykgPGtsZXVuZ0BjaXNjby5jb20+DQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWt1bWFyLXNmYy1uc2gtZm9yd2FyZGluZy0wMS50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta3VtYXItc2ZjLW5zaC1mb3J3YXJk aW5nLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdXJlbmRyYSBL dW1hciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1r dW1hci1zZmMtbnNoLWZvcndhcmRpbmcNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlJbmZyYXN0cnVj dHVyZSBTZXJ2aWNlIEZvcndhcmRpbmcgRm9yIE5TSA0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wOC0x OQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTcNClVSTDogICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta3VtYXItc2Zj LW5zaC1mb3J3YXJkaW5nLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt1bWFyLXNmYy1uc2gtZm9yd2FyZGluZy8NCkh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta3VtYXItc2ZjLW5zaC1m b3J3YXJkaW5nLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWt1bWFyLXNmYy1uc2gtZm9yd2FyZGluZy0wMQ0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBzZXBhcmF0aW9uIG9mIHNlcnZpY2UgZm9yd2FyZGlu ZyBmdW5jdGlvbg0KICAgYW5kIHNlcnZpY2UgZGVsaXZlcnkgZnVuY3Rpb24gYWJzdHJhY3Rpb25z LCBhbG9uZyB3aXRoIHRoZSBtZWNoYW5pY3MNCiAgIG9mIE5TSCBlbmNhcHN1bGF0ZWQgcGFja2V0 IGZvcndhcmRpbmcgd2l0aCBzdWNoIHNlcGFyYXRpb24sIGluIFNGQw0KICAgZGVwbG95bWVudHMu DQoNCiAgIFRoaXMgc2VwYXJhdGlvbiBmcmVlcyB0aGUgc2VydmljZSBmdW5jdGlvbnMgZnJvbSBt YWtpbmcgZm9yd2FyZGluZw0KICAgZGVjaXNpb25zIGFuZCB0aGUgbmVjZXNzYXJ5IGNvbnRyb2wg cGxhbmUgaW50ZWdyYXRpb24sIHRoZXJlYnkNCiAgIGtlZXBpbmcgdGhlIHNlcnZpY2UgZnVuY3Rp b25zIHNpbXBsZSBhbmQgZm9jdXNlZCBvbiBzZXJ2aWNlIGRlbGl2ZXJ5Lg0KICAgRnVydGhlciwg dGhpcyBzZXBhcmF0aW9uIGZ1bGx5IGNvbnRhaW5zIHRoZSBmb3J3YXJkaW5nIGRlY2lzaW9ucyBp bg0KICAgZm9yd2FyZGluZyBmdW5jdGlvbnMsIHRoZXJlYnkgYWxsb3dpbmcgaW1wbGVtZW50YXRp b25zIHRvIGVuZm9yY2UNCiAgIGludGVncml0eSBvZiB0aGUgZm9yd2FyZGluZyBzdGF0ZSBjYXJy aWVkIGluIE5TSCB3aGljaCBpbiB0dXJuIGlzDQogICByZXF1aXJlZCBmb3IgY29ycmVjdGx5IGZv cndhcmRpbmcgTlNIIGVuY2Fwc3VsYXRlZCBwYWNrZXRzLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From nobody Sun Aug 21 20:16: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 10C2012B038 for ; Sun, 21 Aug 2016 20:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 QCSjRTGgBm4F for ; Sun, 21 Aug 2016 20:16:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7C712B010 for ; Sun, 21 Aug 2016 20:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1591; q=dns/txt; s=iport; t=1471835815; x=1473045415; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Ka0/9sF4spx9t+8r82bHT4wgbpsDOcXuNio5lh2LYMM=; b=S2UyTcujp1+iKtUWQDlDtVsM0BEcpNwz1b/VKvzjl5EuXKsnYOmpJ+Mg NwtggY4daMYjX/zlv2fSsNM9CZJawGb23JMulHHdEAHB9E6B+fDOggIgx /8b3IZMXvaAVfnSzM9ROzyWcHt4nb56fK/1yEYU4qsyEhsK6wUgMf8TkX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAgATbrpX/5BdJa1dg0RWfAe3cIF9J?= =?us-ascii?q?ocqOBQCAQEBAQEBAV4cC4RlOj0UAT5CHAYFBBOIMQ6dKp9DAQEBAQYBAQEBASK?= =?us-ascii?q?GK45oBY4fiykBhh+If4FtToQOiQUChmmFVoN3AR42gkWBNXCFfH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,558,1464652800"; d="scan'208";a="143827862" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 03:16:54 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u7M3Grwg006859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Aug 2016 03:16:53 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 21 Aug 2016 22:16:52 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Sun, 21 Aug 2016 22:16:52 -0500 From: "Yogendra Pal (yogpal)" To: "sfc@ietf.org" Thread-Topic: [SFC] FW: New Version Notification for draft-ypal-sfc-dhcp-option-for-nsh-for-sfp-02.txt Thread-Index: AQHR/COhyowOyNi8OkO3q9jDEalhIw== Date: Mon, 22 Aug 2016 03:16:52 +0000 Message-ID: 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.65.52.157] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] [SFC] FW: New Version Notification for draft-ypal-sfc-dhcp-option-for-nsh-for-sfp-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: Mon, 22 Aug 2016 03:16:57 -0000 Revision update, taking care of comments from Ted Lemon. Regards, Yogendra On 19/08/16 12:08 am, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ypal-sfc-dhcp-option-for-nsh-for-sfp-02.txt >has been successfully submitted by Yogendra Pal and posted to the >IETF repository. > >Name: draft-ypal-sfc-dhcp-option-for-nsh-for-sfp >Revision: 02 >Title: DHCP option for NSH in Service Function Path (SFP) >Document date: 2016-08-16 >Group: Individual Submission >Pages: 11 >URL: =20 >https://www.ietf.org/internet-drafts/draft-ypal-sfc-dhcp-option-for-nsh-fo >r-sfp-02.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-ypal-sfc-dhcp-option-for-nsh-for-sf >p/ >Htmlized: =20 >https://tools.ietf.org/html/draft-ypal-sfc-dhcp-option-for-nsh-for-sfp-02 >Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-ypal-sfc-dhcp-option-for-nsh-for= -s >fp-02 > >Abstract: > This draft specifies Dynamic Host Configuration Protocol option > (both DHCPv4 and DHCPv6) for NSH aware clients participating in > the service function path(SFP) of the service chaining. As part > of this proposal SFF and SF will receive the SFP information > containing Service Path Identifier(SPI), Transport protocol and > Nexthop(NH) address of subsequent SFF/SF. > > =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 Tue Aug 23 06:54:23 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 5C2C112D1ED; Tue, 23 Aug 2016 06:54:21 -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.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147196046137.30731.1399811299254089080.idtracker@ietfa.amsl.com> Date: Tue, 23 Aug 2016 06:54:21 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 13:54:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Network Service Header Authors : Paul Quinn Uri Elzur Filename : draft-ietf-sfc-nsh-06.txt Pages : 37 Date : 2016-08-23 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 23 07: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 4C13812D7F3 for ; Tue, 23 Aug 2016 07:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 vD5qF9eyJMnZ for ; Tue, 23 Aug 2016 07:02:24 -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 3A85A12D942 for ; Tue, 23 Aug 2016 07:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1862; q=dns/txt; s=iport; t=1471960929; x=1473170529; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=2uZnlJfrdU/6EFNpAgwoikmTn+YddMo0AYuvmujrYXk=; b=b2Nv7i6pQvhARoiqqd/AX+7a8iYwsaauFEIheAjNS1jDl9INjvcDYkNB QjlpCuIFZZg8w7HnNxgGxMIl7/Ja0zw5Qv/fqVV8bDAirfMz6Jo5WJDdx 8cIvHY4A3nMNP5B9IBa6Cyj1P54j3e5/+JmSd0XOGehZs5P05gLmD7F2E k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPAwCWVrxX/4MNJK1dgykBAQEBARxWf?= =?us-ascii?q?AejYpQdgX0khXkCgWk4FAIBAQEBAQEBXhwLhGABAQQBAQE4NBALAgEZAQIBAh8?= =?us-ascii?q?QJwsXBAIIAgQTiCkIDr1yAQEBAQEBAQMBAQEBAQEBAQEehi2BeAiCTYdsgi8Fm?= =?us-ascii?q?UgBhh+JAYFtToQOiQeMQIN4AR42g3pwhRJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,566,1464652800"; d="scan'208";a="138651753" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Aug 2016 14:02:08 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7NE28jK006755 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Aug 2016 14:02:08 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 23 Aug 2016 09:02:07 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Tue, 23 Aug 2016 09:02:07 -0500 From: "Paul Quinn (paulq)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-nsh-06.txt Thread-Index: AQHR/UXf+K2Wk0PpFkuoPewYh4aM6A== Date: Tue, 23 Aug 2016 14:02:07 +0000 Message-ID: <60F54D29-49F6-4962-963B-93FF6F4DF1A1@cisco.com> References: <147196046137.30731.1399811299254089080.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <3CD17B2FE2D98D45B23738EE4223475F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:02:30 -0000 Dear WG, This version includes much of the feedback/review/comments from this list. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-06.txt > Date: August 23, 2016 at 9:54:21 AM EDT > To: > Cc: sfc@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Service Function Chaining of the IETF. >=20 > Title : Network Service Header > Authors : Paul Quinn > Uri Elzur > Filename : draft-ietf-sfc-nsh-06.txt > Pages : 37 > Date : 2016-08-23 >=20 > Abstract: > This document describes a Network Service Header (NSH) inserted onto > packets or frames to realize service function paths. NSH also > provides a mechanism for metadata exchange along the instantiated > service path. NSH is the SFC encapsulation required to support the > Service Function Chaining (SFC) Architecture (defined in RFC7665). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sfc-nsh-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Aug 23 08:47:37 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 959F512D0C0; Tue, 23 Aug 2016 08:47:32 -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.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147196725260.30794.10266895117462060916.idtracker@ietfa.amsl.com> Date: Tue, 23 Aug 2016 08:47:32 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-07.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, 23 Aug 2016 15:47:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Network Service Header Authors : Paul Quinn Uri Elzur Filename : draft-ietf-sfc-nsh-07.txt Pages : 37 Date : 2016-08-23 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 23 09:48: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 5748A12D60A for ; Tue, 23 Aug 2016 09:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 YANej7vZ2Mlu for ; Tue, 23 Aug 2016 09:48:18 -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 B932812D10F for ; Tue, 23 Aug 2016 09:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2854; q=dns/txt; s=iport; t=1471970898; x=1473180498; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Fyg3dnypSsBj1uLyka+ZDE9PuWfdU/9up2oJgshiV/8=; b=EpNnM4lLeFTbu1fyK5JtZ5QWHlOKlLbUMicM9xGovMVNa7lcYpl67e9c 60nPar5BxeETUeC7byEnqQahCBSy736+4Z6x92c3YNmvOM+yDLe/Sa6yV d0xAip2U87CDvSt0VMMa36fZC10Lo38/7QTwVGfGA+ndI27CJtsSdKR0C c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAgDmfLxX/5JdJa1dgykBAQEBARxWf?= =?us-ascii?q?Ae4A4F9JIYXgU84FAIBAQEBAQEBXhwLhGIFAQEhETodARoIAiYCBCULFQIQBBO?= =?us-ascii?q?IMQ6dcI9lkAIBAQEBAQEBAwEBAQEBAQEBAQEdgQKFK4F4ihYrgi8FlAGFRwGGH?= =?us-ascii?q?4kBgW1OhA6HZIEjjECDeAEeNoN6cIUSfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,566,1464652800"; d="scan'208";a="143689610" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2016 16:48:17 +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 u7NGmHRK026427 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Aug 2016 16:48:17 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; Tue, 23 Aug 2016 11:48:17 -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, 23 Aug 2016 11:48:17 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2Xw== Date: Tue, 23 Aug 2016 16:48:17 +0000 Message-ID: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.98] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.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, 23 Aug 2016 16:48:20 -0000 RGVhciBXRzoNCg0KUGxlYXNlIHJldmlldyB0aGlzIG5ldyB2ZXJzaW9uIG9mIHRoZSBTRkMgZW5j YXBzdWxhdGlvbiB0byBtYWtlIHN1cmUgdGhhdCB5b3VyIGNvbW1lbnRzIGZyb20gdGhlIHByZXZp b3VzIFdHTEMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gDQoNCkFueSBjb21tZW50cyBhbmQvb3IgY29u Y2VybnMgcGxlYXNlIHBvc3QgdG8gdGhlIG1haWxpbmcgbGlzdCB3aXRoaW4gdGhlIG5leHQgdHdv IHdlZWtzIHNvIHRoYXQgdGhpcyB3b3JrIGNhbiBiZSBwcm9ncmVzc2VkLg0KDQpBcyBhIGhlYWRz IHVwLCBpZiB0aGVyZSBhcmUgc3RpbGwgc3Vic3RhbnRpdmUgY29tbWVudHMgd2UgcGxhbiB0byBo b2xkIGFuIGludGVyaW0gbWVldGluZyBvbiBTZXB0ZW1iZXIgMTV0aCB0byBhZGRyZXNzIGFueSBv dXRzdGFuZGluZyBpc3N1ZXMNCg0KDQpUaGFua3MhDQoNCkppbSwgTWFydGluLCAmIFRob21hcw0K DQoNCg0KDQpPbiA4LzIzLzE2LCAxMTo0NyBBTSwgInNmYyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu DQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2VydmljZSBGdW5jdGlvbiBDaGFp bmluZyBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IE5ldHdvcmsg U2VydmljZSBIZWFkZXINCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFBhdWwgUXVpbm4NCj4g ICAgICAgICAgICAgICAgICAgICAgICAgIFVyaSBFbHp1cg0KPglGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLXNmYy1uc2gtMDcudHh0DQo+CVBhZ2VzICAgICAgICAgICA6IDM3DQo+CURhdGUg ICAgICAgICAgICA6IDIwMTYtMDgtMjMNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBhIE5ldHdvcmsgU2VydmljZSBIZWFkZXIgKE5TSCkgaW5zZXJ0ZWQgb250bw0K PiAgIHBhY2tldHMgb3IgZnJhbWVzIHRvIHJlYWxpemUgc2VydmljZSBmdW5jdGlvbiBwYXRocy4g IE5TSCBhbHNvDQo+ICAgcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9yIG1ldGFkYXRhIGV4Y2hhbmdl IGFsb25nIHRoZSBpbnN0YW50aWF0ZWQNCj4gICBzZXJ2aWNlIHBhdGguICBOU0ggaXMgdGhlIFNG QyBlbmNhcHN1bGF0aW9uIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhlDQo+ICAgU2VydmljZSBGdW5j dGlvbiBDaGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1cmUgKGRlZmluZWQgaW4gUkZDNzY2NSkuDQo+ DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtbnNoLw0K Pg0KPlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMDcNCj4NCj5BIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2ZjLW5zaC0wNw0KPg0KPg0KPlBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Tue Aug 23 10:20: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 7242912D62E for ; Tue, 23 Aug 2016 10:20:34 -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=unavailable 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 yd4oFcNSxYzy for ; Tue, 23 Aug 2016 10:20:31 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 1B98A12D124 for ; Tue, 23 Aug 2016 10:10:57 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id c15so204793597oig.0 for ; Tue, 23 Aug 2016 10:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yvyqEgtgshiG/ntwrzJ1cKI4rB65KOJhJufGletczio=; b=cYS5eHhvwD0m8yWBenm/oCW/diJ5lX56DyXs0RXfXYg5Ms9gr+xaNwEEH5tRE5DvBs QraUMTnSvGv5kJW9kgIHSLC4h1WUdcpxMY6X/Xb7OKoG+MVUzUqbbSryTulUoAyqYa0k RLVvAeoAEhVisX6Wlq7niRl3T/NEkvJPAYm1dvZCKsroGIKzfR4/wwvwG+FoKGskoq8w GzWQ0HasgePe9XLqFgx7PAg+MJboUgLatYO87RT98GlV0Aq1XRZrqY8StKVMYNSTj4c8 1EiOqb92YmFBrPTxLgYlBGRINOYUbFsC2rYQqjaC87jmaPe3+zX+NYeq28r5NoGC0C/F M46A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yvyqEgtgshiG/ntwrzJ1cKI4rB65KOJhJufGletczio=; b=Oq9d4QZBSrRFDLtNIi3I5azGr54XtmsbN1UmK6lYQx0X+BdYMfbYtcd5LlkTS8S3qX Us2YuvKom5U8heiwFY4WSpiYA4zfC/LXErkRfNIRgFtJIpFASwg8dJkE2GXBkc33ax1J NabkCin7w4ymlNyRgPF0i/NljoDEDJdancrbvDI6fSU3GpgivdrZYlHjLVSN7byzDYqA T6X40NOGQdyS5ptGFB1RTRXRb+XMTVTogvMvqtemBZCGTz3AZ7ziP0j9SHmLG0M0LG3g EyHr6feSLViNqXzLEFfutpmRdZtj8JCPfs1Gs8yw/JB9kxQUBL7V919gFPuQlY06jZh4 WHig== X-Gm-Message-State: AEkooutQfv8qeoyjFKPF2lzKVCIOcfk6J+udY3RIvPqBtVpbVFsC62e0yrw1jVe8LCtpAGwy4oZuXSY00uwPVw== X-Received: by 10.157.0.8 with SMTP id 8mr18428785ota.20.1471972256469; Tue, 23 Aug 2016 10:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.138.35 with HTTP; Tue, 23 Aug 2016 10:10:35 -0700 (PDT) In-Reply-To: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> From: "Andrew G. Malis" Date: Tue, 23 Aug 2016 13:10:35 -0400 Message-ID: To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=94eb2c03755877593c053ac03f20 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.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, 23 Aug 2016 17:20:34 -0000 --94eb2c03755877593c053ac03f20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jim, I noticed an editing error, at the bottom of p. 12 it still discusses three reserved bits in fig. 6, but now there=E2=80=99s only one bit. Cheers, Andy On Tue, Aug 23, 2016 at 12:48 PM, Jim Guichard (jguichar) < jguichar@cisco.com> wrote: > Dear WG: > > Please review this new version of the SFC encapsulation to make sure that > your comments from the previous WGLC have been addressed. > > Any comments and/or concerns please post to the mailing list within the > next two weeks so that this work can be progressed. > > As a heads up, if there are still substantive comments we plan to hold an > interim meeting on September 15th to address any outstanding issues > > > Thanks! > > Jim, Martin, & Thomas > > > > > On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" < > sfc-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >This draft is a work item of the Service Function Chaining of the IETF. > > > > Title : Network Service Header > > Authors : Paul Quinn > > Uri Elzur > > Filename : draft-ietf-sfc-nsh-07.txt > > Pages : 37 > > Date : 2016-08-23 > > > >Abstract: > > This document describes a Network Service Header (NSH) inserted onto > > packets or frames to realize service function paths. NSH also > > provides a mechanism for metadata exchange along the instantiated > > service path. NSH is the SFC encapsulation required to support the > > Service Function Chaining (SFC) Architecture (defined in RFC7665). > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > > > >There's also a htmlized version available at: > >https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 > > > >A diff from the previous version is available at: > >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 > > > > > >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/ > > > >_______________________________________________ > >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 > --94eb2c03755877593c053ac03f20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jim,

I noticed an editing error, at the= bottom of p. 12 it still discusses three reserved bits in fig. 6, but now = there=E2=80=99s only one bit.

Cheers,
An= dy


On Tue, Aug 23, 2016 at 12:48 PM, Jim Guichard (jguichar) <jg= uichar@cisco.com> wrote:
De= ar WG:

Please review this new version of the SFC encapsulation to make sure that y= our comments from the previous WGLC have been addressed.

Any comments and/or concerns please post to the mailing list within the nex= t two weeks so that this work can be progressed.

As a heads up, if there are still substantive comments we plan to hold an i= nterim meeting on September 15th to address any outstanding issues


Thanks!

Jim, Martin, & Thomas




On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" <sfc-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
>This draft is a work item of the Service Function Chaining of the IETF.=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Network Service Header
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Paul Quinn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Uri Elzur
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-sfc-nsh-07.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 37
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2016-08-23
>
>Abstract:
>=C2=A0 =C2=A0This document describes a Network Service Header (NSH) ins= erted onto
>=C2=A0 =C2=A0packets or frames to realize service function paths.=C2=A0= NSH also
>=C2=A0 =C2=A0provides a mechanism for metadata exchange along the insta= ntiated
>=C2=A0 =C2=A0service path.=C2=A0 NSH is the SFC encapsulation required = to support the
>=C2=A0 =C2=A0Service Function Chaining (SFC) Architecture (defined in R= FC7665).
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-= ietf-sfc-nsh/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-sfc= -nsh-07
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-sfc-nsh-07
>
>
>Please note that it may take a couple of minutes from the time of submi= ssion
>until the htmlized version and diff are available at tools.ietf.org. >
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--94eb2c03755877593c053ac03f20-- From nobody Tue Aug 23 10:51: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 5868412B024 for ; Tue, 23 Aug 2016 10:51:07 -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 AjExnyuups1w for ; Tue, 23 Aug 2016 10:51:06 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CDE12D18B for ; Tue, 23 Aug 2016 10:51:05 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l203so206815335oib.1 for ; Tue, 23 Aug 2016 10:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=5b6sCY5MNYr4aaJoaNAnzbxxtfejJSzpc+BBnLgAeXI=; b=FxNXe+svtQnqVx21Fhw5ckNHGBIxkQbUob5wM1XseXeWEE+bmuqkhczWyAHayLU0sy PaZ7oFSB+K5vExg5XOl7vNTNbWKcNIj44j1/QqU9gKgKczDRkNb92RCBXDm++YtAytvK rWAYMvxiHb96MT0j6KW2WYJGAI3RM0ierwNNfR8iIodY5RrOC5TLPQZaGTsxpfK7I2wO hEg06lNp3ED9UIDpXUtRJREAz/kwhduA0IokskgY1rOYKc0juRGAfOhos52a6kjZDMq8 m4bARBmjowtHQn4xK4rr/k4fD3IHunBrBP2/bN36psQGizO/emFvgdSRyzlc9azVQD9D hSFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5b6sCY5MNYr4aaJoaNAnzbxxtfejJSzpc+BBnLgAeXI=; b=PYeps3ce1UokQ8dkH9f1H5iUY8eN1k8Ftzj3OXmlANrePx9REUzdWMxlTXuAQDAmdg 7P4SPQZDbowRadzPKHejtLEVRJDNBWr/DoKWpRadnJd7eIipgdSj3oVNZ9UfYovnNLV1 OtOXuYOVTtV8lR61QCApUAMa5Mlug0PjnooHZ5XCy/IZ8hm37LolMhsvKFbdt3Ya+TAB Eq566Ex6Z8VUhhSiN41Cq/Su0AXeC33rfc9LdtGTFcfMRKxyf8IDlOr5fwmqn4Vqy66G 4NpTvql6+pPixbdgj2dsoaRtXcbmk8L3ZrdFG6Ld7uY5irnXU9Ev5Q/83wJfc+5eu7MF Qm8A== X-Gm-Message-State: AEkoousrjcdV5FjVnRCtludRDPfB67v0GuVy048QFCY+krXMhEMlC/lHR3AkQHSeKFwMe5NedAKnf4xBKMAcAA== X-Received: by 10.157.29.217 with SMTP id w25mr16250889otw.36.1471974664939; Tue, 23 Aug 2016 10:51:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.138.35 with HTTP; Tue, 23 Aug 2016 10:50:44 -0700 (PDT) From: "Andrew G. Malis" Date: Tue, 23 Aug 2016 13:50:44 -0400 Message-ID: To: "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a113e35da05af07053ac0cf4f Archived-At: Subject: [sfc] Question on IANA considerations in draft-ietf-sfc-nsh-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Aug 2016 17:51:07 -0000 --001a113e35da05af07053ac0cf4f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m going to repeat a question I asked about -05, but never receive= d an answer, and I see is still in the IANA considerations for -07. "Standards Action" and "IETF Review" are not the same thing. However, if you look through the list of new registries defined in section 12.2, both Standards Action and IETF Review are used for different registries. Is there a reason that they aren=E2=80=99t all one or the other? Are these con= scious choices? Thanks, Andy --001a113e35da05af07053ac0cf4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99m going to repeat a question I asked about -05, = but never received an answer, and I see is still in the IANA considerations= for -07.=C2=A0

"Sta= ndards Action" and "IETF Review" are not the same thing. How= ever, if you look through the list of new registries defined in section 12.= 2, both Standards Action and IETF Review are used for different registries.= Is there a reason that they aren=E2=80=99t all one or the other? Are these= conscious choices?
Thanks,
= Andy

--001a113e35da05af07053ac0cf4f-- From nobody Tue Aug 23 11:05: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 2451012D66E for ; Tue, 23 Aug 2016 11:05:08 -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 MpfwGaALG4vV for ; Tue, 23 Aug 2016 11:05:07 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B20D12D669 for ; Tue, 23 Aug 2016 11:05:07 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id l203so207364647oib.1 for ; Tue, 23 Aug 2016 11:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=qZD0u7O/5onH84Z1O4G0H7skzTBVfWcHAQk9AoObs38=; b=kQJY/g3mP08nigmr/79DLEFHE66p7LnlhB+BQQ9KLjlTaOAzNT1Z5pU37IeQFdA2O3 jYkKZFAaoOC5r7dSxI5QDcQr5m9C1VbkXOEvPZSvpccHf7A9oz/QgK1/0AjelpRi7ezm 1P1/RF7nl5ecl+2qAZhSVVN4cIBHNFpy7hFLS01gqfT0AWvuVw2Lq0Uvsw5NIuCCawJg 6LXthUWjbejxPQ0EzbQSWmnYNH/UDEuqiDJL1WUhBQzCI3jyDNs6mzXWS6+kqy9hdf6I hxOR6k6gTxWXPM5TF4YG6Edei3RGMef3tLa8q4bfBnrtt2rUhVTAIyuochhB0XvP/mUz 8g/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qZD0u7O/5onH84Z1O4G0H7skzTBVfWcHAQk9AoObs38=; b=Q3OtYc5wvvqtoX22ZxkDfLDkocvpfy04dnFwmEziJ+z6ACEvzQBDjEWL1u4CPJwS0p AHiLT9l2l+T4gReYJp7gjgpdrjXjN1wwWblum1l0gEb9OTxV60pTJZsKrKmEsYM3v0Ee eD5SGzd1bR0Clc/L5ZPFzmtRs7DGTTr9cIqzQ+xXVuv5kcInrvxQytY57Pg/QggcSfdV EoiurwJ/fjuNAcTCMfCRaaL/rlfOL7OQj9vKnakebYA2WBtxQh39DkJKAqzDi99ISkwp lN9jczUkBqca7eC6GQUpqnZzMonoPvPRz0sXZk7zjHsoov+BFewxIlDL/paYY5b8VQko ftyg== X-Gm-Message-State: AEkoouubpF7PTClvssnWnqNOTs/jpWgEnisjaKgah1MQPYqozU103hK9bPefZJ/SahWIIlrLFB7p7yNgo4zEnQ== X-Received: by 10.157.13.56 with SMTP id 53mr19369119oti.55.1471975506384; Tue, 23 Aug 2016 11:05:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.138.35 with HTTP; Tue, 23 Aug 2016 11:04:46 -0700 (PDT) From: "Andrew G. Malis" Date: Tue, 23 Aug 2016 14:04:46 -0400 Message-ID: To: "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a11372f642d1d81053ac10117 Archived-At: Subject: [sfc] Referencing draft-ietf-rtgwg-dt-encap in draft-ietf-sfc-nsh-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Aug 2016 18:05:08 -0000 --001a11372f642d1d81053ac10117 Content-Type: text/plain; charset=UTF-8 In draft-ietf-sfc-nsh-07, draft-ietf-rtgwg-dt-encap-01 is referenced three times, but is not in the list of references. Also, section 6 of draft-ietf-sfc-nsh-07 specifically references section 6 of draft-ietf-rtgwg-dt-encap-01. I suspect that section 9 is what was actually intended. In any case, section 6 is obviously incorrect. Thanks, Andy --001a11372f642d1d81053ac10117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In=C2=A0draft-ietf-sfc-nsh-07,=C2=A0draft-ietf-rtgwg-dt-en= cap-01 is referenced three times, but is not in the list of references.=C2= =A0

Also, section 6 of draft-ietf-sfc-nsh-07 specificall= y references section 6 of draft-ietf-rtgwg-dt-encap-01. I suspect that sect= ion 9 is what was actually intended. In any case, section 6 is obviously in= correct.

Thanks,
Andy

--001a11372f642d1d81053ac10117-- From nobody Tue Aug 23 13:42: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 82F7312D7F8 for ; Tue, 23 Aug 2016 13:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 CChcgy4JzJ3n for ; Tue, 23 Aug 2016 13:42:50 -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 44FA312D7EA for ; Tue, 23 Aug 2016 13:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5742; q=dns/txt; s=iport; t=1471984968; x=1473194568; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uKicpOMoskGB9mHEcq7WTtvugHpI7wNXfosqX7L/dpo=; b=mgxazl2pwAJ4/XPqsjlrAjFH+37YmpQg/MgymGpQ3bKiRU94Uk2n9rYD kq0G8ANl7bwVke6OPdw7E/wsANu6cKhv73VMex7RQOx17cQzKpBIC7OOs 44n+dHXTZseJcBARCm0xYs4G1oe/0pS+72ylDjjuzv8JXSvLN9VNgcD81 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAwDutLxX/5hdJa1dgnYzAQEBAQEeV?= =?us-ascii?q?nwHq1aHJoUIgX0khXkCHIFSOBQCAQEBAQEBAV4nhGEBBQEBIUsLEAIBCAQ7AwI?= =?us-ascii?q?CAh8GCxQRAgQOBYgXAxcOrT2LZQ2ECAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFh?= =?us-ascii?q?i2BeAiCTYJDhH4rgi8FlAGFEzQBjFmCR4FtjWOGaYFOhAmDeAEeNoN6cIUSfwE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.28,567,1464652800"; d="scan'208,217";a="139135144" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2016 20:42:47 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7NKglSh007868 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Aug 2016 20:42:47 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 23 Aug 2016 16:42:46 -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; Tue, 23 Aug 2016 16:42:46 -0400 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [sfc] Question on IANA considerations in draft-ietf-sfc-nsh-07 Thread-Index: AQHR/Wb1Rr5HFe3RVk2j5yCIsjDBpKBXRhEA Date: Tue, 23 Aug 2016 20:42:46 +0000 Message-ID: <7FC87D95-0042-4E22-87A3-56C7C145AB1D@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.5.186] Content-Type: multipart/alternative; boundary="_000_7FC87D9500424E2287A356C7C145AB1Dciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Question on IANA considerations in draft-ietf-sfc-nsh-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Aug 2016 20:42:51 -0000 --_000_7FC87D9500424E2287A356C7C145AB1Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KR3JlYXQgcXVlc3Rpb24uDQoNClRoZSByZWdpc3RyaWVzIHRoYXQgYXJlIGJp dCBtYXNrIG9yIGhhdmUgYSB2ZXJ5IHNtYWxsIHNldCBvZiB2YWx1ZXMgYXJlIG1hcmtlZCDigJxT dGFuZGFyZHMgQWN0aW9u4oCdICgxMi4yLjEgYW5kIDEyLjIuMikuIERlZmluaW5nIGhlYWRlciBi aXRzIG9yIHZlcnNpb24gbnVtYmVycyBpcyBzaWduaWZpY2FudCB0byB0aGUgcHJvdG9jb2wgYW5k IG1pZ2h0IHVwZGF0ZSB0aGUgc3BlYy4NCg0KUmVnaXN0cmllcyB3aXRoIG1vcmUgbnVtYmVycyBs b3dlciB0aGUgYmFyIGEgYml0ICgxMi4yLjMsIGNodW5rcyBvZiAxMi4yLjQpLg0KDQpQcm90b2Nv bCBudW1iZXJzICgxMi4yLjUpIHNlZW1zIGFsc28gYSBudW1iZXIgb2Ygc3BhY2Ugb2YgbWFqb3Ig c2lnbmlmaWNhbmNlLiBJIGNvdWxkIGdvIHdpdGggZWl0aGVyIFN0YW5kYXJkcyBBY3Rpb24gb3Ig SUVURiBSZXZpZXcgZm9yIHRoaXMgb25lLCB0aG91Z2guDQoNCk5ldC1uZXQsIHRoZXkgYXJlIGRl bGliZXJhdGUgY2hvaWNlcy4NCg0KVGhhbmtzIQ0KDQrigJQgQ2FybG9zLg0KDQpPbiBBdWcgMjMs IDIwMTYsIGF0IDEwOjUwIEFNLCBBbmRyZXcgRy4gTWFsaXMgPGFnbWFsaXNAZ21haWwuY29tPG1h aWx0bzphZ21hbGlzQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJ4oCZbSBnb2luZyB0byByZXBlYXQg YSBxdWVzdGlvbiBJIGFza2VkIGFib3V0IC0wNSwgYnV0IG5ldmVyIHJlY2VpdmVkIGFuIGFuc3dl ciwgYW5kIEkgc2VlIGlzIHN0aWxsIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIGZvciAtMDcu DQoNCiJTdGFuZGFyZHMgQWN0aW9uIiBhbmQgIklFVEYgUmV2aWV3IiBhcmUgbm90IHRoZSBzYW1l IHRoaW5nLiBIb3dldmVyLCBpZiB5b3UgbG9vayB0aHJvdWdoIHRoZSBsaXN0IG9mIG5ldyByZWdp c3RyaWVzIGRlZmluZWQgaW4gc2VjdGlvbiAxMi4yLCBib3RoIFN0YW5kYXJkcyBBY3Rpb24gYW5k IElFVEYgUmV2aWV3IGFyZSB1c2VkIGZvciBkaWZmZXJlbnQgcmVnaXN0cmllcy4gSXMgdGhlcmUg YSByZWFzb24gdGhhdCB0aGV5IGFyZW7igJl0IGFsbCBvbmUgb3IgdGhlIG90aGVyPyBBcmUgdGhl c2UgY29uc2Npb3VzIGNob2ljZXM/DQoNClRoYW5rcywNCkFuZHkNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCg0K --_000_7FC87D9500424E2287A356C7C145AB1Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4D8B3956D0909A4B84E7B75E1A81B55E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgQW5keSwNCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWF0IHF1ZXN0aW9uLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ VGhlIHJlZ2lzdHJpZXMgdGhhdCBhcmUgYml0IG1hc2sgb3IgaGF2ZSBhIHZlcnkgc21hbGwgc2V0 IG9mIHZhbHVlcyBhcmUgbWFya2VkIOKAnFN0YW5kYXJkcyBBY3Rpb27igJ0gKDEyLjIuMSBhbmQg MTIuMi4yKS4gRGVmaW5pbmcgaGVhZGVyIGJpdHMgb3IgdmVyc2lvbiBudW1iZXJzIGlzIHNpZ25p ZmljYW50IHRvIHRoZSBwcm90b2NvbCBhbmQgbWlnaHQgdXBkYXRlIHRoZSBzcGVjLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnaXN0 cmllcyB3aXRoIG1vcmUgbnVtYmVycyBsb3dlciB0aGUgYmFyIGEgYml0ICgxMi4yLjMsIGNodW5r cyBvZiAxMi4yLjQpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+UHJvdG9jb2wgbnVtYmVycyAoMTIuMi41KSBzZWVtcyBhbHNvIGEgbnVt YmVyIG9mIHNwYWNlIG9mIG1ham9yIHNpZ25pZmljYW5jZS4gSSBjb3VsZCBnbyB3aXRoIGVpdGhl ciBTdGFuZGFyZHMgQWN0aW9uIG9yIElFVEYgUmV2aWV3IGZvciB0aGlzIG9uZSwgdGhvdWdoLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ TmV0LW5ldCwgdGhleSBhcmUgZGVsaWJlcmF0ZSBjaG9pY2VzLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzITwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCUIENhcmxv cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBdWcgMjMsIDIwMTYsIGF0 IDEwOjUwIEFNLCBBbmRyZXcgRy4gTWFsaXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZ21hbGlzQGdt YWlsLmNvbSIgY2xhc3M9IiI+YWdtYWxpc0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4N CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SeKAmW0gZ29pbmcgdG8gcmVwZWF0IGEgcXVlc3Rpb24g SSBhc2tlZCBhYm91dCAtMDUsIGJ1dCBuZXZlciByZWNlaXZlZCBhbiBhbnN3ZXIsIGFuZCBJIHNl ZSBpcyBzdGlsbCBpbiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBmb3IgLTA3LiZuYnNwOw0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxM3B4IiBjbGFzcz0iIj4mcXVvdDtTdGFuZGFyZHMgQWN0aW9uJnF1b3Q7 IGFuZCAmcXVvdDtJRVRGIFJldmlldyZxdW90OyBhcmUgbm90IHRoZSBzYW1lIHRoaW5nLiBIb3dl dmVyLCBpZiB5b3UgbG9vayB0aHJvdWdoIHRoZSBsaXN0IG9mIG5ldyByZWdpc3RyaWVzIGRlZmlu ZWQgaW4gc2VjdGlvbiAxMi4yLCBib3RoIFN0YW5kYXJkcyBBY3Rpb24gYW5kIElFVEYgUmV2aWV3 IGFyZSB1c2VkIGZvciBkaWZmZXJlbnQgcmVnaXN0cmllcy4NCiBJcyB0aGVyZSBhIHJlYXNvbiB0 aGF0IHRoZXkgYXJlbuKAmXQgYWxsIG9uZSBvciB0aGUgb3RoZXI/IEFyZSB0aGVzZSBjb25zY2lv dXMgY2hvaWNlcz88L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTNweCIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFu PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzcHgiIGNsYXNz PSIiPlRoYW5rcyw8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTNweCIgY2xhc3M9IiI+QW5keTwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxM3B4IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0Kc2ZjIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xh c3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7FC87D9500424E2287A356C7C145AB1Dciscocom_-- From nobody Tue Aug 23 15:36: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 B0C6812DBB8; Tue, 23 Aug 2016 15:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UVamOFf8kyY; Tue, 23 Aug 2016 15:35:55 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 A6B7712DBAF; Tue, 23 Aug 2016 15:35:55 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id 93so16974611qtg.2; Tue, 23 Aug 2016 15:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=X8iORwG76uhSHsQVNQN528lWR7chJAdhTbXWEuGK+Ys=; b=R61m94aKct3Hl7ljjzYlOWZpOp5UO6fss5G/9eu3W29dUzhC3IPFbFpT1i30kcIk3W Y5SeojUuwLL+ztR4JJzDTzX62ZDCpKQZI3piPTHIV0bZQtTNC07Z7pKbLhsC+Y8kn4zx D+Dl8zJxtdXMe8gBTY4cjuxFI/tjztDpHC1dZ3ttjZtHgjjV2dorkJEN0fG6PwNfO+kB IBcIRq9VRdX8eDl60m5QquSJMP1jXZ21YbRVMWsmKsriOO+YEV/L72jD/hYRgTf14UdR slzu4lAEg5YNowtCuQyLXWZ/+ViL1MZWItr54KV6ul6vkteYJ+ozUNEqMSjOBc514H1S jy/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=X8iORwG76uhSHsQVNQN528lWR7chJAdhTbXWEuGK+Ys=; b=kExixvGsIdOLTP+gFIhSbr6WIP3dBzkmr95XH487D5inU3YwprqBCh9ILjCh8D/nvg 1JlgUAidrf30haEiKLs0j40mZPc6Yr2gVnlgdYldUFe+Xrk9R3mQq0gwktbsHha8RAWC vylUZKawSrLu1p1fJEBPx5rqMoSpDkQl+FHZnSu8wyoDObKLRH4pmgug/jaRg/Bp4ST1 VxhoEd/NY0bcMhvEmZOWUowbsHcL+oTpgLgBoPYzizrjY0HiWdDJ4ZdQhmaR0ILeaVzB YrKKtO7ew8cLsy8YxAEvzRwDvCSWMdEEZ53PeUEQEoVeGquCryhyq5rXHwZ3GvDkt6ap x3Rw== X-Gm-Message-State: AEkoouvpmE0i0zBI8fBEgTbiLLMy5/9/p03n1ylMDNxyyaRUrbzuVdtlfZ3vo74PdYH2rX4EZIj60ObZSg0wrA== X-Received: by 10.200.49.100 with SMTP id h33mr32763465qtb.86.1471991754460; Tue, 23 Aug 2016 15:35:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.52.193 with HTTP; Tue, 23 Aug 2016 15:35:54 -0700 (PDT) From: Alia Atlas Date: Tue, 23 Aug 2016 18:35:54 -0400 Message-ID: To: "sfc@ietf.org" , draft-ietf-sfc-control-plane@ietf.org Content-Type: multipart/alternative; boundary=001a11377158a3137e053ac4c991 Archived-At: Subject: [sfc] AD review of draft-ietf-sfc-control-plane-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: Tue, 23 Aug 2016 22:35:58 -0000 --001a11377158a3137e053ac4c991 Content-Type: text/plain; charset=UTF-8 As is customary, I have done my AD review of draft-ietf-sfc-control-plane-06. First, I would like to thank the editor, Mohamed, and all the contributors for their work on this document. Normally, when I review a draft, it is easy to read for what is in the document and provide detailed comments on the text or technical issues. This document is different because some of the concerns are about what is missing as well as the structure and purpose of this. Please regard this as the start of a conversation. a) First, while this document tries to clarify the control plane, it is not something is describing a particular architecture or even providing enough detail that I could go and consider how to develop a control plane protocol or data-models to handle any of the cases. It isn't implementable, it doesn't provide guidance for evaluating options, and it makes very few choices - even to narrow down between very different design alternatives. Can you please clarify what you see as the purpose and usefulness of this document? It has a lot of interesting information in it - but it doesn't feel directed towards a particular purpose. b) When we talk about a networking architecture, there are multiple different planes and aspects discussed. This document says that it is about the control-plane, but I don't find that there is a clean separation between what would be at the management plane and even the OAM and monitoring aspects and what is the control-plane. For instance, there are several references to learning the load of an SF . Even Section 4.8 describes counters and statistics to be provided via the control plane interfaces. Similarly, the information at bootstrapping doesn't distinguish between management information (what the SFCs are, what traffic is to be directed to them) and information that should be dynamically learned from the network, so that changes can also be discovered. c) The dynamics of the control plane aren't discussed at all. There is no indication of the needed timeliness of the interfaces. I'm not even poking at the scalability of these - but questions about what type of responsiveness or change rates are anticipated. d) The interfaces are described largely statically in terms of information to be passed, but not the dynamics of the life-cycle of the pieces of functionality. For instance, I might expect something along the lines of: "A Control-Plane entity is provided by the management system with an SFC to be created and a set of SFs to be followed. To create an SFC, the Control-Plane Entity must determine the meta-data required by each SF and that can be generated by each SF. Then the Control-Plane Entity must determine the specific SFP to be used. An SFP can be created via head-end signaling or by direct communication from the Control-Plane Entity. To create an SFP, it is necessary to specify the sequence of SFs and SFFs, what metadata to be added or removed by each SF and how that metadata is to be carried in the encapsulation. If the specific transport used between SFFs is significant, then that may also be specified. In addition to creation, a Control-Plane Entity must handle modification and removal of an SFP. " Then there could be different options - either "When modification is done, it needs to be done from the end of the SFP to the start to avoid stranding traffic." or "A make-before-break mechanism can be used where a new SFP is allocated, set up, tested, the traffic is migrated to it, and finally the old SFP is removed." In Sec 4.9, the concept of Validity lifetimes is introduced. I don't know if that applies just to the classification rules or the SFPs as well, but if it does, information about where & how it is refreshed is needed. e) Similarly to the life-cycle of objects created and managed by the control-plane, I'd also expect to see a section talking about discovery of information and what needs to be able to learn that information. For instance, how are the locators of SFFs, SFs,classifiers, etc. learned? What needs to learn about them? Is information about what transport each supports something that is dynamically discovered? Is information about what formats of metadata can be handled dynamically discovered? What entities need to learn when an SF or SFF is overloaded? If the control-plane entity doesn't compute the specific detailed SFs to be used and the head-end of the SFP needs to do computation, then presumably, the head-end also needs to be aware of when an SF or SFF is overloaded. f) For more minor comments, the lack of introductory text introducing Figure 1 is unfortunate. It doesn't give the reader context when reading the further sections. The written description around C1/C2/C3 has a lot of redundancy and doesn't highlight what are the differences between the interfaces. This would be much better showing the information that needs to generally be communicated and then the nuances added. g) There are scattered comments around liveness and monitoring - but how that is to be done, what it reports back to, how the control-plane entity or head-end handles it, is simply not described. This feels like a document that badly needs a set of folks to walk through the life-cycle and event flows. As written, I can't tell whether a discovery/flooding protocol is needed. It's very hard to peel apart what work needs to be done. It's quite clear that describing the interfaces to SFFs, SFs, etc. and a "control-plane entity" misses a number of needed communications. I don't currently see how this document provides a basis for moving forward on control-plane work. Regards, Alia --001a11377158a3137e053ac4c991 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As is customary, I have done my AD review of draft-ietf-sf= c-control-plane-06.
First, I would like to thank the editor, Mohamed, a= nd all the contributors for their
work on this document.

Normally, when I review a draft, it is easy to read for wh= at is in the document and provide detailed comments on the text or technica= l issues. =C2=A0 This document is different because some of the concerns ar= e about what is missing as well as the structure and purpose of this. =C2= =A0 Please regard this as the start of a conversation.

=
a) First, while this document tries to clarify the control plane, it i= s not something is describing a particular architecture or even providing e= nough detail that I could go and
consider how to develop a contro= l plane protocol or data-models to handle any of the cases.=C2=A0 It isn= 9;t implementable, it doesn't provide guidance for evaluating options, = and
it makes very few choices - even to narrow down between very = different design alternatives.

Can you please clar= ify what you see as the purpose and usefulness of this document?=C2=A0 It h= as a lot of interesting information in it - but it doesn't feel directe= d towards a particular purpose.

b) When we talk ab= out a networking architecture, there are multiple different planes and aspe= cts discussed. =C2=A0 This document says that it is about the control-plane= , but I don't find that there is a clean separation between what would = be at the management plane and even the OAM and monitoring aspects and what= is the control-plane.

For instance, there are sev= eral references to learning the load of an SF .=C2=A0 Even Section 4.8 desc= ribes counters and statistics to be provided via the control plane interfac= es. =C2=A0 Similarly, the information at bootstrapping doesn't distingu= ish between management information (what the SFCs are, what traffic is to b= e directed to them) and information that should be dynamically learned from= the network, so that changes can also be discovered.

<= div>c) =C2=A0The dynamics of the control plane aren't discussed at all.= =C2=A0 There is no indication of the needed timeliness of the interfaces. = =C2=A0 I'm not even poking at the scalability of these - but questions = about what type of responsiveness or change rates are anticipated.

d) The interfaces are described largely statically in term= s of information to be passed, but not the dynamics of the life-cycle of th= e pieces of functionality.=C2=A0 For instance, I might expect something alo= ng the lines of:

=C2=A0 "A Control-Plane enti= ty is provided by the management system with an SFC to be created and a set= of SFs to be followed. =C2=A0 To create an SFC, the Control-Plane Entity
must determine the meta-data required by each SF and that can be g= enerated by each SF.=C2=A0 Then the Control-Plane Entity must determine the= specific SFP to be used.
An SFP can be created via head-end sign= aling or by direct communication from the Control-Plane Entity.=C2=A0 To cr= eate an SFP, it is necessary to specify the sequence of SFs and SFFs, what = metadata to be added or removed by each SF and how that metadata is to be c= arried in the encapsulation.=C2=A0 If the specific transport used between S= FFs is significant, then that may also be specified.

In addition to creation, a Control-Plane Entity must handle modification= and removal of an SFP. " =C2=A0Then there could be different options = - either =C2=A0"When modification is done, it needs to be done from th= e end of the SFP to the start to avoid stranding traffic." or =C2=A0 &= quot;A make-before-break mechanism can be used where a new SFP is allocated= , set up, tested, the traffic is migrated to it, and finally the old SFP is= removed."

In Sec 4.9, the concept of Validit= y lifetimes is introduced.=C2=A0 I don't know if that applies just to t= he classification rules or the SFPs as well, but if it does, information ab= out where & how it is refreshed is needed.

e) = Similarly to the life-cycle of objects created and managed by the control-p= lane, I'd also expect to see a section talking about discovery of infor= mation and what needs to be able to learn that information.=C2=A0 For insta= nce, how are the locators of SFFs, SFs,classifiers, etc. learned?=C2=A0 Wha= t needs to learn about them?=C2=A0 Is information about what transport each= supports something that is dynamically discovered?=C2=A0 Is information ab= out what formats of metadata can be handled dynamically discovered?=C2=A0 W= hat entities need to learn when an SF or SFF is overloaded?=C2=A0 If the co= ntrol-plane entity doesn't compute the specific detailed SFs to be used= and the head-end of the SFP needs to do computation, then presumably, the = head-end also needs to be aware of when an SF or SFF is overloaded.

f) For more minor comments, the lack of introductory text= introducing Figure 1 is unfortunate.=C2=A0 It doesn't give the reader = context when reading the further sections.=C2=A0 The written description ar= ound C1/C2/C3 has a lot of redundancy and doesn't highlight what are th= e differences between the interfaces.=C2=A0 This would be much better showi= ng the information that needs to generally be communicated and then the nua= nces added.=C2=A0

g) There are scattered comments = around liveness and monitoring - but how that is to be done, what it report= s back to, how the control-plane entity or head-end handles it, is simply n= ot described. =C2=A0

This feels like a document th= at badly needs a set of folks to walk through the life-cycle and event flow= s. =C2=A0 As written, I can't tell whether a discovery/flooding protoco= l is needed.=C2=A0 It's very hard to peel apart what work needs to be d= one.=C2=A0 It's quite clear that describing the interfaces to SFFs, SFs= , etc. and a "control-plane entity" misses a number of needed com= munications. =C2=A0

I don't currently see how = this document provides a basis for moving forward on control-plane work.

Regards,
Alia
--001a11377158a3137e053ac4c991-- From nobody Tue Aug 23 15:58: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 DA54812DBF2; Tue, 23 Aug 2016 15:58: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 zEpzsxeEjKtb; Tue, 23 Aug 2016 15:58:38 -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 D167112DBE7; Tue, 23 Aug 2016 15:58:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B96EA8C18D4; Tue, 23 Aug 2016 15:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1471993118; bh=HZIR9b7c1xtoZkHPuKUWKnz+/cYFG5KW4m6estfU5j4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lddug/bk5osnO7Fgy/OAdidvmC/+3GJSa7X0XOa4z9zRg/FCFBt4d40wLbfkKFzm/ urOtkN0sTo8rQkH4EtVit9P+A1rjgQIkf4oOF5cnX2Hmk1tCD4aFIE6/0ET01UeqHh cQ0Tnyv9Echr6xy8evLwi2AfibbaIovXx4Q/KuSI= 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 08A6B8C18C7; Tue, 23 Aug 2016 15:58:37 -0700 (PDT) To: Alia Atlas , "sfc@ietf.org" , draft-ietf-sfc-control-plane@ietf.org References: From: "Joel M. Halpern" Message-ID: <606d271e-27d9-31b1-ff8b-fa17e034b972@joelhalpern.com> Date: Tue, 23 Aug 2016 18:59:04 -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] AD review of draft-ietf-sfc-control-plane-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: Tue, 23 Aug 2016 22:58:41 -0000 Thank you fro a careful review Alia. What follows is my personal take on the document. On 8/23/16 6:35 PM, Alia Atlas wrote: > As is customary, I have done my AD review of > draft-ietf-sfc-control-plane-06. > First, I would like to thank the editor, Mohamed, and all the > contributors for their > work on this document. > > Normally, when I review a draft, it is easy to read for what is in the > document and provide detailed comments on the text or technical issues. > This document is different because some of the concerns are about what > is missing as well as the structure and purpose of this. Please regard > this as the start of a conversation. > > a) First, while this document tries to clarify the control plane, it is > not something is describing a particular architecture or even providing > enough detail that I could go and > consider how to develop a control plane protocol or data-models to > handle any of the cases. It isn't implementable, it doesn't provide > guidance for evaluating options, and > it makes very few choices - even to narrow down between very different > design alternatives. > > Can you please clarify what you see as the purpose and usefulness of > this document? It has a lot of interesting information in it - but it > doesn't feel directed towards a particular purpose. For me, the purpose of this document is to lay out the expectations the data plane has of the control plane. It is a place to capture, for future work, the behaviors and constraints any control plane solution for SFC must exhibit / meet. It is not an effort to make design or architecture choices. The SFC charter is very clear that we are to work on those requirements. > > b) When we talk about a networking architecture, there are multiple > different planes and aspects discussed. This document says that it is > about the control-plane, but I don't find that there is a clean > separation between what would be at the management plane and even the > OAM and monitoring aspects and what is the control-plane. Given the above stated goal, I do not want the document to care about the differences between "classical control" and "management" or "orchestration". From the point of view of the SFC data plane, it does not matter what kind of mechanism is used to achieve the goals. > > For instance, there are several references to learning the load of an SF > . Even Section 4.8 describes counters and statistics to be provided via > the control plane interfaces. Similarly, the information at > bootstrapping doesn't distinguish between management information (what > the SFCs are, what traffic is to be directed to them) and information > that should be dynamically learned from the network, so that changes can > also be discovered. We probably do need to be clear, in describing the information needs, about what information (in either direction) is dynamic as opposed to largely unchanging. This will help folks avoid using static operational protocols for dynamic information. > > c) The dynamics of the control plane aren't discussed at all. There is > no indication of the needed timeliness of the interfaces. I'm not even > poking at the scalability of these - but questions about what type of > responsiveness or change rates are anticipated. This is probably a good point that we should address. > > d) The interfaces are described largely statically in terms of > information to be passed, but not the dynamics of the life-cycle of the > pieces of functionality. For instance, I might expect something along > the lines of: > > "A Control-Plane entity is provided by the management system with an > SFC to be created and a set of SFs to be followed. To create an SFC, > the Control-Plane Entity > must determine the meta-data required by each SF and that can be > generated by each SF. Then the Control-Plane Entity must determine the > specific SFP to be used. > An SFP can be created via head-end signaling or by direct communication > from the Control-Plane Entity. To create an SFP, it is necessary to > specify the sequence of SFs and SFFs, what metadata to be added or > removed by each SF and how that metadata is to be carried in the > encapsulation. If the specific transport used between SFFs is > significant, then that may also be specified. > > In addition to creation, a Control-Plane Entity must handle modification > and removal of an SFP. " Then there could be different options - either > "When modification is done, it needs to be done from the end of the SFP > to the start to avoid stranding traffic." or "A make-before-break > mechanism can be used where a new SFP is allocated, set up, tested, the > traffic is migrated to it, and finally the old SFP is removed." As noted above, I don't think that this document should attempt to differentiate among classical control, management, and orchestration. As such, it is not useful to talk about information moving between components within the control space. This is particularly apropos as we are not trying to specify the design or architecture of the control components, so we are not picking such flows. > > In Sec 4.9, the concept of Validity lifetimes is introduced. I don't > know if that applies just to the classification rules or the SFPs as > well, but if it does, information about where & how it is refreshed is > needed. Sounds reasonable. > > e) Similarly to the life-cycle of objects created and managed by the > control-plane, I'd also expect to see a section talking about discovery > of information and what needs to be able to learn that information. For > instance, how are the locators of SFFs, SFs,classifiers, etc. learned? > What needs to learn about them? Is information about what transport > each supports something that is dynamically discovered? Is information > about what formats of metadata can be handled dynamically discovered? > What entities need to learn when an SF or SFF is overloaded? If the > control-plane entity doesn't compute the specific detailed SFs to be > used and the head-end of the SFP needs to do computation, then > presumably, the head-end also needs to be aware of when an SF or SFF is > overloaded. Discovery is a complex topic as we are allowing for both situations where existing elements are discovered, and for situations where the control infrastructure creates elements and thus has no need to discover them. As such, the data plane does not require discovery, although some control architectures will have such requirements. > > f) For more minor comments, the lack of introductory text introducing > Figure 1 is unfortunate. It doesn't give the reader context when > reading the further sections. The written description around C1/C2/C3 > has a lot of redundancy and doesn't highlight what are the differences > between the interfaces. This would be much better showing the > information that needs to generally be communicated and then the nuances > added. This sounds like helpful explication. > > g) There are scattered comments around liveness and monitoring - but how > that is to be done, what it reports back to, how the control-plane > entity or head-end handles it, is simply not described. This document does not describe how, only what is required / expected. > > This feels like a document that badly needs a set of folks to walk > through the life-cycle and event flows. As written, I can't tell > whether a discovery/flooding protocol is needed. It's very hard to peel > apart what work needs to be done. It's quite clear that describing the > interfaces to SFFs, SFs, etc. and a "control-plane entity" misses a > number of needed communications. I think you are asking for something that is well beyond our intent. > > I don't currently see how this document provides a basis for moving > forward on control-plane work. To restate, the goal here as I understand it is to provide a set of minimums that any control plane work must meet. Anything more than that is a different can of worms. > > Regards, > Alia > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Aug 24 01:02: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 A69F012D0FE; Wed, 24 Aug 2016 01:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 9uNQKODEOp-v; Wed, 24 Aug 2016 01:02:22 -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 02BC812D08D; Wed, 24 Aug 2016 01:02:22 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 1D86E40230; Wed, 24 Aug 2016 10:02:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id D1CFA12005B; Wed, 24 Aug 2016 10:02:19 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0301.000; Wed, 24 Aug 2016 10:02:19 +0200 From: To: "Joel M. Halpern" , Alia Atlas , "sfc@ietf.org" , "draft-ietf-sfc-control-plane@ietf.org" Thread-Topic: [sfc] AD review of draft-ietf-sfc-control-plane-06 Thread-Index: AQHR/Y659jBJ/fkvDEKO8UUmVO8SX6BXBz8AgACXbIA= Date: Wed, 24 Aug 2016 08:02:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E08AD2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <606d271e-27d9-31b1-ff8b-fa17e034b972@joelhalpern.com> In-Reply-To: <606d271e-27d9-31b1-ff8b-fa17e034b972@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] AD review of draft-ietf-sfc-control-plane-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, 24 Aug 2016 08:02:25 -0000 Dear Alia, all,=20 Many thanks for the review.=20 I second what has been mentioned by Joel.=20 The document focuses on "requirements for conveying information between con= trol or management elements and SFC implementation points" (SFC Charter). T= he document defines what is meant by these "SFC implementation points" in r= eference to the SFC data plane architecture. Distinct interfaces are define= d to distinguish among the information that is needed to be conveyed to eac= h SFC data plane element. It is not a goal of this document to make choices between alternate options= . Also, it does not aim to specify protocols or protocol extensions. Those = aspects are clearly out of the scope. Note that the charter is not clear wh= ether one or many "protocol extension work resulting from these requirement= s" (SFC Charter) will be defined in the future. Such effort, if any, will b= e "under a revised charter" (SFC Charter). Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: mercredi 24 ao=FBt 2016 00:59 > =C0=A0: Alia Atlas; sfc@ietf.org; draft-ietf-sfc-control-plane@ietf.org > Objet=A0: Re: [sfc] AD review of draft-ietf-sfc-control-plane-06 >=20 > Thank you fro a careful review Alia. What follows is my personal take > on the document. >=20 > On 8/23/16 6:35 PM, Alia Atlas wrote: > > As is customary, I have done my AD review of > > draft-ietf-sfc-control-plane-06. > > First, I would like to thank the editor, Mohamed, and all the > > contributors for their > > work on this document. > > > > Normally, when I review a draft, it is easy to read for what is in the > > document and provide detailed comments on the text or technical issues. > > This document is different because some of the concerns are about wha= t > > is missing as well as the structure and purpose of this. Please regar= d > > this as the start of a conversation. > > > > a) First, while this document tries to clarify the control plane, it is > > not something is describing a particular architecture or even providing > > enough detail that I could go and > > consider how to develop a control plane protocol or data-models to > > handle any of the cases. It isn't implementable, it doesn't provide > > guidance for evaluating options, and > > it makes very few choices - even to narrow down between very different > > design alternatives. > > > > Can you please clarify what you see as the purpose and usefulness of > > this document? It has a lot of interesting information in it - but it > > doesn't feel directed towards a particular purpose. >=20 > For me, the purpose of this document is to lay out the expectations the > data plane has of the control plane. It is a place to capture, for > future work, the behaviors and constraints any control plane solution > for SFC must exhibit / meet. It is not an effort to make design or > architecture choices. The SFC charter is very clear that we are to work > on those requirements. >=20 [Med] Agree. > > > > b) When we talk about a networking architecture, there are multiple > > different planes and aspects discussed. This document says that it is > > about the control-plane, but I don't find that there is a clean > > separation between what would be at the management plane and even the > > OAM and monitoring aspects and what is the control-plane. >=20 > Given the above stated goal, I do not want the document to care about > the differences between "classical control" and "management" or > "orchestration". From the point of view of the SFC data plane, it does > not matter what kind of mechanism is used to achieve the goals. [Med] The document is constrained by the scope defined in the WG charter : = "requirements for conveying information between control or management eleme= nts and SFC implementation points" >=20 > > > > For instance, there are several references to learning the load of an S= F > > . Even Section 4.8 describes counters and statistics to be provided vi= a > > the control plane interfaces. Similarly, the information at > > bootstrapping doesn't distinguish between management information (what > > the SFCs are, what traffic is to be directed to them) and information > > that should be dynamically learned from the network, so that changes ca= n > > also be discovered. [Med] The bootstrapping section distinguishes between two 'kinds" of inform= ation: * The one with service instructions (first set of bullets): This one is cle= arly out of scope.=20 * The second set of information gathered from the network: I'd personally r= ecommend those to be discovered dynamically but the outcome of the discussi= on we had in the WG is that discovery is out of scope. For this reason, I i= ncluded this sentence into the draft "How this information is collected is = left unspecified in this document" and=20 " This can be achieved using a variety if mechanisms such as static configuration or the activation of a service discovery mechanism. The exact specification of how this provisioning is achieved is out of scope. " (Section 4.1) The document discusses also information that is needed for "dynamically" ad= justing SFPs (e.g., Sections 3.3.2 and 3.3.4), "dynamic attachment of SFs t= o a SFF and/or discovery of SFs by a SFF" (Section 3.3.2), or notifying cha= nges (e.g., Sections 4.6 and 4.7).=20 >=20 > We probably do need to be clear, in describing the information needs, > about what information (in either direction) is dynamic as opposed to > largely unchanging. This will help folks avoid using static operational > protocols for dynamic information. [Med] The current text uses "unsolicited", "dynamically", "service function= discovery procedure", "dynamic attachment", "notified", to characterize so= me information that is needed to be dynamic.=20 >=20 > > > > c) The dynamics of the control plane aren't discussed at all. There i= s > > no indication of the needed timeliness of the interfaces. I'm not eve= n > > poking at the scalability of these - but questions about what type of > > responsiveness or change rates are anticipated. >=20 > This is probably a good point that we should address. [Med] Good point. Will update the text with such information whenever appro= priate. >=20 > > > > d) The interfaces are described largely statically in terms of > > information to be passed, but not the dynamics of the life-cycle of the > > pieces of functionality. For instance, I might expect something along > > the lines of: [Med] I understand your point.. but it is not easy to write such text becau= se there are several options to realize the same task. This is exactly why = we are focusing on the information to be passed not how it is passed.=20 See for example some alternate options to the flow you are proposing.=20 > > > > "A Control-Plane entity is provided by the management system with an > > SFC to be created and a set of SFs to be followed. [Med] One may argue that the set of SFs to be followed in the context of a = given SFC may be a local decision of the CP, service decision engine, or st= atically configured.=20 To create an SFC, > > the Control-Plane Entity > > must determine the meta-data required by each SF and that can be > > generated by each SF. [Med] One would argue that the CP is not required to **determine** which me= tadata is required for each service chain, but it may be responsible for re= ceiving such instruction from a service decision engine and translate it in= to instructions to underlying SFC DP elements. Then the Control-Plane Entity must determine the > > specific SFP to be used. > > An SFP can be created via head-end signaling or by direct communication > > from the Control-Plane Entity. [Med] ...Or may be dynamically computed.=20 To create an SFP, it is necessary to > > specify the sequence of SFs and SFFs [Med] The set of SFFs is not required to be fully specified, for example. , what metadata to be added or > > removed by each SF and how that metadata is to be carried in the > > encapsulation. If the specific transport used between SFFs is > > significant, then that may also be specified. [Med] Already covered in Section 2.3. > > > > In addition to creation, a Control-Plane Entity must handle modificatio= n > > and removal of an SFP. " Then there could be different options - eithe= r > > "When modification is done, it needs to be done from the end of the SF= P > > to the start to avoid stranding traffic." or "A make-before-break > > mechanism can be used where a new SFP is allocated, set up, tested, the > > traffic is migrated to it, and finally the old SFP is removed." [Med] SFP modification and removal are mentioned in Section 4.5. How this i= s actually enforced is deployment-specific.=20 >=20 > As noted above, I don't think that this document should attempt to > differentiate among classical control, management, and orchestration. > As such, it is not useful to talk about information moving between > components within the control space. > This is particularly apropos as we are not trying to specify the design > or architecture of the control components, so we are not picking such > flows. >=20 > > > > In Sec 4.9, the concept of Validity lifetimes is introduced. I don't > > know if that applies just to the classification rules or the SFPs as > > well, but if it does, information about where & how it is refreshed is > > needed. >=20 > Sounds reasonable. [Med] I see some value in associating a validity lifetime to the entries of= the SFP Forwarding Policy Table maintained by SFFs. The lifetime of such e= ntries can be set of a control plane element or via a signaling protocol du= ring the setup of an SFP (case of RSPs). I can add some to reflect those in= the draft. =20 >=20 > > > > e) Similarly to the life-cycle of objects created and managed by the > > control-plane, I'd also expect to see a section talking about discovery > > of information and what needs to be able to learn that information. Fo= r > > instance, how are the locators of SFFs, SFs,classifiers, etc. learned? [Med] The per-domain discovery is out of scope of this document. Neverthele= ss, the documents mentions what information is needed to be discovered. Als= o, it even hints that some information can be dynamically discovered (e.g.,= SF attachment to SFFs, CP Control Element).=20 > > What needs to learn about them? Is information about what transport > > each supports something that is dynamically discovered?=20 [Med] We only focus on the required behavior once that information is gathe= red (see Section 2.3). Is information > > about what formats of metadata can be handled dynamically discovered? [Med] Good point. I will update the text to reflect this point. =20 > > What entities need to learn when an SF or SFF is overloaded? [Med] This point is explicitly mentioned in various places of the document = (search for "load"). If the > > control-plane entity doesn't compute the specific detailed SFs to be > > used and the head-end of the SFP needs to do computation, then > > presumably, the head-end also needs to be aware of when an SF or SFF is > > overloaded. [Med] I can update Section 4.10.2 if you think this is useful.=20 >=20 > Discovery is a complex topic as we are allowing for both situations > where existing elements are discovered, and for situations where the > control infrastructure creates elements and thus has no need to discover > them. As such, the data plane does not require discovery, although some > control architectures will have such requirements. >=20 > > > > f) For more minor comments, the lack of introductory text introducing > > Figure 1 is unfortunate. It doesn't give the reader context when > > reading the further sections. The written description around C1/C2/C3 > > has a lot of redundancy and doesn't highlight what are the differences > > between the interfaces. This would be much better showing the > > information that needs to generally be communicated and then the nuance= s > > added. [Med] Will update the text. >=20 > This sounds like helpful explication. >=20 > > > > g) There are scattered comments around liveness and monitoring - but ho= w > > that is to be done, what it reports back to, how the control-plane > > entity or head-end handles it, is simply not described. >=20 > This document does not describe how, only what is required / expected. >=20 > > > > This feels like a document that badly needs a set of folks to walk > > through the life-cycle and event flows. As written, I can't tell > > whether a discovery/flooding protocol is needed. It's very hard to pee= l > > apart what work needs to be done. It's quite clear that describing the > > interfaces to SFFs, SFs, etc. and a "control-plane entity" misses a > > number of needed communications. >=20 > I think you are asking for something that is well beyond our intent. [Med] Exactly.=20 >=20 > > > > I don't currently see how this document provides a basis for moving > > forward on control-plane work. >=20 > To restate, the goal here as I understand it is to provide a set of > minimums that any control plane work must meet. Anything more than that > is a different can of worms. >=20 > > > > Regards, > > Alia > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Wed Aug 24 02:11: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 7D54C12D559 for ; Wed, 24 Aug 2016 02:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 LTby2VJglwnI for ; Wed, 24 Aug 2016 02:10:57 -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 2409112B006 for ; Wed, 24 Aug 2016 02:10:56 -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 CPZ82682; Wed, 24 Aug 2016 09:10:54 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 24 Aug 2016 10:10:54 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Wed, 24 Aug 2016 02:10:52 -0700 From: Linda Dunbar To: Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] Security Considerations in draft-ietf-sfc-nsh-05 Thread-Index: AQHR+eRXGW7qRhZqCUaATHbWat9636BXZzNg Date: Wed, 24 Aug 2016 09:10:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F178BC@dfweml501-mbb> References: <03133b79-963a-36d1-63b0-838fcaaf9533@gmail.com> In-Reply-To: <03133b79-963a-36d1-63b0-838fcaaf9533@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.30] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57BD649F.00BF, 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: 8c5ed854eed482fd2b3e660b258c198b Archived-At: Subject: Re: [sfc] Security Considerations in draft-ietf-sfc-nsh-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 24 Aug 2016 09:10:59 -0000 Agree with Martin's observation. On the second note, NSH is an encapsulatio= n, similar to NxLAN, GRE, LISP, except NSH has many more bytes than other t= ypes of encapsulation. Therefore, there is higher chance of fragmentation, = which IMHO needs to be addressed. =20 Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Friday, August 19, 2016 1:38 AM To: sfc@ietf.org Subject: [sfc] Security Considerations in draft-ietf-sfc-nsh-05 Dear all, I am in the process of reviewing the different documents with respect to se= curity and did run through RFC 7665. RFC 7665 is doing a pretty good job in= highlighting the areas of interest with respect to SFC security. However, I am shocked by what is document (or better *not* documented) in t= he NSH draft. Right now the security considerations section says this: "As with many other protocols, NSH data can be spoofed or otherwise modified. In many deployments, NSH will be used in a controlled environment, with trusted devices (e.g. a data center) thus mitigating the risk of unauthorized header manipulation. NSH is always encapsulated in a transport protocol and therefore, when required, existing security protocols that provide authenticity (e.g. RFC 2119 [RFC6071]) can be used. Similarly if confidentiality is required, existing encryption protocols can be used in conjunction with encapsulated NSH. Further security considerations are discussed in [nsh-sec]." This is handwaiving and will not survive any stage of WG external review. S= o we as WG are better working on this now! Three ideas to get the discussion started: - The usage of NSH may increase the usage of IP fragments. This can lead to= security issues, but potentially in the reverse, as a number of firewalls = are blocking IP fragments. See also RFC 1858. This may be worth to document= . - NSH can be encapsulated in different "transports", e.g., GRE, Ethernet, V= XLAN, etc. This has also implications and mainly it will ok to say that the= se encapsulations have also security considerations that have to be properl= y obyed. - NSH is going to carry meta data that is linked to Personally Identifiable= Information (PII). How is NSH dealing with this? This has to be mentioned = and the solution has to be documented. There are more issues to think about, of course. Regards, Martin _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Aug 24 02:39: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 E212612D590; Wed, 24 Aug 2016 02:39: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 eQR89Yn-OtSD; Wed, 24 Aug 2016 02:39:36 -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 C4F3112D5A4; Wed, 24 Aug 2016 02:39:35 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 21763264586; Wed, 24 Aug 2016 11:39:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EDFCE238104; Wed, 24 Aug 2016 11:39:33 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0301.000; Wed, 24 Aug 2016 11:39:33 +0200 From: To: Linda Dunbar , "draft-ietf-sfc-hierarchical@ietf.org" , "sfc@ietf.org" Thread-Topic: comments to draft-ietf-sfc-hierarchical-00 Thread-Index: AdH4Iyt0LnbnJ00eQcCm0BUVCiQUSQFxe/zw Date: Wed, 24 Aug 2016 09:39:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E08B6A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <4A95BA014132FF49AE685FAB4B9F17F657F14AB8@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F14AB8@dfweml501-mbb> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008E08B6AOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.8.23.124518 Archived-At: Subject: Re: [sfc] comments to draft-ietf-sfc-hierarchical-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 24 Aug 2016 09:39:39 -0000 --_000_787AE7BB302AE849A7480A190F8B933008E08B6AOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Linda, Many thanks for the review. Please see inline. Cheers, Med De : Linda Dunbar [mailto:linda.dunbar@huawei.com] Envoy=E9 : mercredi 17 ao=FBt 2016 05:40 =C0 : BOUCADAIR Mohamed IMT/OLN; draft-ietf-sfc-hierarchical@ietf.org; sfc@= ietf.org Objet : comments to draft-ietf-sfc-hierarchical-00 Authors of draft-ietf-sfc-hierarchical-00: Here are my comments after reviewing the draft-ietf-sfc-hierarchical-00: - Section 2.2: o Is the "SFC-encapsulated" same as "NSH-encapsulated"? [Med] Yes. o If the packets entering the sub-domain are already "SFC-encapsulated", = I assume that the packets exiting the sub-domain is also "SFC-encapsulated"= . Correct? [Med] Yes. The text cites the following "The egress IBN finally restores pa= ckets to the original SFC shim and hands them off to SFFs. " Should add some references on the actions done by the "egress IBN" to res= tore it to the original SFC SHIM. [Med] More details are introduced in Section 3.1 and subsections. - Section 3.1: o Does the phrase "after exiting a path in the sub-domain" mean packets l= eaving a sub-domain? [Med] Yes. I do agree with you this sentence is to be clarified. If yes, what circumstance will cause "nesting NSH header" (does it mean add= ing a new NSH header)? [Med] adding another NSH header is one of the methods that are discussed in= the document. Alternate options are also discussed. - Section 3.1.1 (Page 8): Why "State cannot be created by packets = arriving from lower-level chain? [Med] This is an assumption of the stateful model that assumes that a state= must always be created by an incoming packet. I have some concerns with th= is text as it does not allow to send direct message from an SF. Also, it is= not compatible with some SFs (e.g., MPTCP proxy). This is a pending point = we are discussing among authors. FWIW, please check: https://github.com/dcd= olson/draft-dolson-sfc-hierarchical/commit/a2cacebb021ba4e6a44af4d0f27ea7f0= 02224c7e o There could be many types of "states" by SF. How can you generalize wha= t packets can restore the " state"? [Med] Can you please explicit this point? Thank you. - Section 3.1.4: what kind of use cases will trigger nesting NSH? = The Figure 3 has 3 layers of NSH, greatly increase the likelihood of packet= fragmentation. I am curious of what cases need multiple layers of NSH head= er. [Med] We are not recommending NSH nesting, but are discussing how it can be= used as a candidate option. Fragmentation can be indeed one of the drawbac= ks of this approach. This can be added to the draft. NSH is not same as MPLS label (which can be nested because of much smaller = number of bytes) . - Cheers, Linda Dunbar --_000_787AE7BB302AE849A7480A190F8B933008E08B6AOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Many thanks for the review.

 

Please see inline.

 

Cheers,

Med

 

De : Lind= a Dunbar [mailto:linda.dunbar@huawei.com]
Envoy=E9 : mercredi 17 ao=FBt 2016 05:40
=C0 : BOUCADAIR Mohamed IMT/OLN; draft-ietf-sfc-hierarchical@ie= tf.org; sfc@ietf.org
Objet : comments to draft-ietf-sfc-hierarchical-00

 

Authors of draft-ietf-sfc-hiera= rchical-00:

 

Here are my comments after revi= ewing the draft-ietf-sfc-hierarchical-00:

 

-  = ;         Section 2.2: &nbs= p;

o   Is the “SFC-encap= sulated” same as “NSH-encapsulated”?

[Med] Yes.

 

o   If the packets entering= the sub-domain are already “SFC-encapsulated”, I assume that t= he packets exiting the sub-domain is also “SFC-encapsulated”. C= orrect?

[Med] Yes. The text cites the following “The egress IBN finally restores packets to the origi=
nal

   SFC shim and hands them off to= SFFs.

”

Sh= ould add some references on the  actions done by the  “egre= ss IBN” to restore it to the original SFC SHIM.

[Med] More details are introduc= ed in Section 3.1 and subsections.

 

-  = ;        Section 3.1:=

o   Does the phrase “= after exiting a path in the sub-domain” mean packets leaving a sub-do= main?

[Med] Yes. I do agree with you = this sentence is to be clarified.

 

If= yes, what circumstance will cause “nesting NSH header” (does i= t mean adding a new NSH header)?  

[Med] adding another NSH header= is one of the methods that are discussed in the document. Alternate option= s are also discussed.

 

-  = ;        Section 3.1.1 (Page 8):= Why “State cannot be created by packets arriving from lower-level ch= ain?

[Med] This is an assumption of = the stateful model that assumes that a state must always be created by an i= ncoming packet. I have some concerns with this text as it does not allow to send direct message from an SF. Also, it is not co= mpatible with some SFs (e.g., MPTCP proxy). This is a pending point we are = discussing among authors. FWIW, please check: https://github.com/dcdolson/draft-dolson-sfc-hierarchical/commit/a2cacebb02= 1ba4e6a44af4d0f27ea7f002224c7e

 

o   There could be many typ= es of “states” by SF. How can you generalize what packets can r= estore the “ state”?

[Med] Can you please explicit t= his point? Thank you.

 

-  = ;        Section 3.1.4: what kin= d of use cases will trigger nesting NSH? The Figure 3 has 3 layers of NSH, = greatly increase the likelihood of packet fragmentation. I am curious of wh= at cases need multiple layers of NSH header.

[Med] We are not recommending N= SH nesting, but are discussing how it can be used as a candidate option. Fr= agmentation can be indeed one of the drawbacks of this approach. This can be added to the draft.

 

NS= H is not same as MPLS label (which can be nested because of much smaller nu= mber of bytes) .

-  = ;         

 

Chee= rs,

 

Lind= a Dunbar

 

--_000_787AE7BB302AE849A7480A190F8B933008E08B6AOPEXCLILMA3corp_-- From nobody Wed Aug 24 06:34:24 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C542212DD51; Wed, 24 Aug 2016 06:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: 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-_gyAImrUdl; Wed, 24 Aug 2016 06:34: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 0A25012DD65; Wed, 24 Aug 2016 06:34:13 -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.294.0; Wed, 24 Aug 2016 09:34:11 -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, 24 Aug 2016 09:34:11 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "Linda Dunbar" , "draft-ietf-sfc-hierarchical@ietf.org" , "sfc@ietf.org" Thread-Topic: comments to draft-ietf-sfc-hierarchical-00 Thread-Index: AdH4Iyt0LnbnJ00eQcCm0BUVCiQUSQFxe/zwAAhTu0A= Date: Wed, 24 Aug 2016 13:34:10 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657F14AB8@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008E08B6A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E08B6A@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_E8355113905631478EFF04F5AA706E9831071351wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] comments to draft-ietf-sfc-hierarchical-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 24 Aug 2016 13:34:23 -0000 --_000_E8355113905631478EFF04F5AA706E9831071351wtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Linda, thanks for reviewing. See inline [DD] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, August 24, 2016 5:40 AM To: Linda Dunbar; draft-ietf-sfc-hierarchical@ietf.org; sfc@ietf.org Subject: RE: comments to draft-ietf-sfc-hierarchical-00 Hi Linda, Many thanks for the review. Please see inline. Cheers, Med De : Linda Dunbar [mailto:linda.dunbar@huawei.com] Envoy=E9 : mercredi 17 ao=FBt 2016 05:40 =C0 : BOUCADAIR Mohamed IMT/OLN; draft-ietf-sfc-hierarchical@ietf.org; sfc@= ietf.org Objet : comments to draft-ietf-sfc-hierarchical-00 Authors of draft-ietf-sfc-hierarchical-00: Here are my comments after reviewing the draft-ietf-sfc-hierarchical-00: - Section 2.2: o Is the "SFC-encapsulated" same as "NSH-encapsulated"? [Med] Yes. o If the packets entering the sub-domain are already "SFC-encapsulated", = I assume that the packets exiting the sub-domain is also "SFC-encapsulated"= . Correct? [Med] Yes. The text cites the following "The egress IBN finally restores pa= ckets to the original SFC shim and hands them off to SFFs. " Should add some references on the actions done by the "egress IBN" to res= tore it to the original SFC SHIM. [Med] More details are introduced in Section 3.1 and subsections. - Section 3.1: o Does the phrase "after exiting a path in the sub-domain" mean packets l= eaving a sub-domain? [Med] Yes. I do agree with you this sentence is to be clarified. [DD] RFC7665 uses the language of "terminating SFPs". So how about, "At the= termination of an SFP in the sub-domain, packets can be restored to an ori= ginal upper-level SFP..." If yes, what circumstance will cause "nesting NSH header" (does it mean add= ing a new NSH header)? [Med] adding another NSH header is one of the methods that are discussed in= the document. Alternate options are also discussed. - Section 3.1.1 (Page 8): Why "State cannot be created by packets = arriving from lower-level chain? [Med] This is an assumption of the stateful model that assumes that a state= must always be created by an incoming packet. I have some concerns with th= is text as it does not allow to send direct message from an SF. Also, it is= not compatible with some SFs (e.g., MPTCP proxy). This is a pending point = we are discussing among authors. FWIW, please check: https://github.com/dcd= olson/draft-dolson-sfc-hierarchical/commit/a2cacebb021ba4e6a44af4d0f27ea7f0= 02224c7e o There could be many types of "states" by SF. How can you generalize wha= t packets can restore the " state"? [Med] Can you please explicit this point? Thank you. - Section 3.1.4: what kind of use cases will trigger nesting NSH? = The Figure 3 has 3 layers of NSH, greatly increase the likelihood of packet= fragmentation. I am curious of what cases need multiple layers of NSH head= er. [Med] We are not recommending NSH nesting, but are discussing how it can be= used as a candidate option. Fragmentation can be indeed one of the drawbac= ks of this approach. This can be added to the draft. [DD] I've added, "By increasing packet overhead, nesting may lead to fragme= ntation or decreased MTU in some networks." NSH is not same as MPLS label (which can be nested because of much smaller = number of bytes) . - Cheers, Linda Dunbar --_000_E8355113905631478EFF04F5AA706E9831071351wtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Linda, thanks for revi= ewing.

See inline [DD]

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, August 24, 2016 5:40 AM
To: Linda Dunbar; draft-ietf-sfc-hierarchical@ietf.org; sfc@ietf.org=
Subject: RE: comments to draft-ietf-sfc-hierarchical-00

 

Hi Linda,

 

Many thanks for the review.

 

Please see inline.

 

Cheers,

Med

 

De : Linda Dunbar [mailto:linda.dunbar@huawei.com]
Envoy=E9 : mercredi 17 ao=FBt 2016 05:40
=C0 : BOUCADAIR Mohamed IMT/OLN; draft-ietf-sfc-hierarchical@ie= tf.org; sfc@ietf.org
Objet : comments to draft-ietf-sfc-hierarchical-00

 

Authors of draft-ietf-sfc-hierarchical-00:

 

Here are my comments after reviewing the draft-ietf-= sfc-hierarchical-00:

 

-     &= nbsp;     Section 2.2:  

o   Is the “SFC-encapsulated” same a= s “NSH-encapsulated”?

[Med] Yes.

 

o   If the packets entering the sub-domain are a= lready “SFC-encapsulated”, I assume that the packets exiting th= e sub-domain is also “SFC-encapsulated”. Correct? 

[Med] Yes. The text cites the following &#=
8220;The egress IBN finally restores packets to the original

   SFC shim and hands them off to SFFs.

”

Should add some referenc= es on the  actions done by the  “egress IBN” to resto= re it to the original SFC SHIM.

[Med] More details are introduced in Section 3= .1 and subsections.

 

-     &= nbsp;    Section 3.1:

o   Does the phrase “after exiting a path = in the sub-domain” mean packets leaving a sub-domain?

[Med] Yes. I do agree with you this sentence i= s to be clarified.

[DD] RFC7665 uses the = language of “terminating SFPs”. So how about, “At the ter= mination of an SFP in the sub-domain, packets can be restored to an origina= l upper-level SFP…”

 

If yes, what circumstanc= e will cause “nesting NSH header” (does it mean adding a new NS= H header)?  

[Med] adding another NSH header is one of the = methods that are discussed in the document. Alternate options are also disc= ussed.

 

-     &= nbsp;    Section 3.1.1 (Page 8): Why “State cannot be = created by packets arriving from lower-level chain?

[Med] This is an assumption of the stateful mo= del that assumes that a state must always be created by an incoming packet.= I have some concerns with this text as it does not allow to send direct message from an SF. Also, it is not compatible wi= th some SFs (e.g., MPTCP proxy). This is a pending point we are discussing = among authors. FWIW, please check: https://github.com/dcdolson/draft-dolson-sfc-hierarchical/commit/a2cacebb02= 1ba4e6a44af4d0f27ea7f002224c7e

 

o   There could be many types of “states&#= 8221; by SF. How can you generalize what packets can restore the “ st= ate”?

[Med] Can you please explicit this point? Than= k you.

 

-     &= nbsp;    Section 3.1.4: what kind of use cases will trigger = nesting NSH? The Figure 3 has 3 layers of NSH, greatly increase the likelih= ood of packet fragmentation. I am curious of what cases need multiple layer= s of NSH header.

[Med] We are not recommending NSH nesting, but= are discussing how it can be used as a candidate option. Fragmentation can= be indeed one of the drawbacks of this approach. This can be added to the draft.

[DD] I’ve added,= “By increasing packet overhead, nesting may lead to fragmentation or= decreased MTU in some networks.”

 

NSH is not same as MPLS l= abel (which can be nested because of much smaller number of bytes) .

-     &= nbsp;     

 

Cheers, =

 

Linda Dunbar

 

--_000_E8355113905631478EFF04F5AA706E9831071351wtlexchp2sandvi_-- From nobody Wed Aug 24 09:47: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 E5D6712D1B2 for ; Wed, 24 Aug 2016 09:47:36 -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 N8hHRQa7yZTc for ; Wed, 24 Aug 2016 09:47:35 -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 946D612D5BD for ; Wed, 24 Aug 2016 09:47:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7B3DE1C01C0; Wed, 24 Aug 2016 09:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1472057255; bh=3TvqEmreRYr/PLxyIqiZbeKR4UuTwyL6BHL5IMyawFw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NERc3f/N9lwezJeochN6MNDiJ0T7Nbs7t5y1rUd9QT6eSmqYpSZEyIdrjqDkR6yDN mIhNoV5VS2F9LL2aiAkP5CAlLgfrUm5wWld54GUS3spvXdw/CGgOepa2SqvFqbkpR9 52h6kL2+KDw0dVjsRzBPT1pJFMvu5nH3ktQ46lXs= 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 EBA15B802C1; Wed, 24 Aug 2016 09:47:34 -0700 (PDT) To: Linda Dunbar , Martin Stiemerling , "sfc@ietf.org" References: <03133b79-963a-36d1-63b0-838fcaaf9533@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657F178BC@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: <7a3bdee6-e663-a902-7e98-061fafd9e717@joelhalpern.com> Date: Wed, 24 Aug 2016 12:48:17 -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: <4A95BA014132FF49AE685FAB4B9F17F657F178BC@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Security Considerations in draft-ietf-sfc-nsh-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 24 Aug 2016 16:47:37 -0000 Folks, please look at the Security considerations section in -07. We attempted to address the issues that many people have raised. If we missed something, please let us know. Yours, Joel On 8/24/16 5:10 AM, Linda Dunbar wrote: > Agree with Martin's observation. On the second note, NSH is an encapsulation, similar to NxLAN, GRE, LISP, except NSH has many more bytes than other types of encapsulation. Therefore, there is higher chance of fragmentation, which IMHO needs to be addressed. > > Linda > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling > Sent: Friday, August 19, 2016 1:38 AM > To: sfc@ietf.org > Subject: [sfc] Security Considerations in draft-ietf-sfc-nsh-05 > > Dear all, > > I am in the process of reviewing the different documents with respect to security and did run through RFC 7665. RFC 7665 is doing a pretty good job in highlighting the areas of interest with respect to SFC security. > > However, I am shocked by what is document (or better *not* documented) in the NSH draft. Right now the security considerations section says this: > > "As with many other protocols, NSH data can be spoofed or otherwise > modified. In many deployments, NSH will be used in a controlled > environment, with trusted devices (e.g. a data center) thus > mitigating the risk of unauthorized header manipulation. > > NSH is always encapsulated in a transport protocol and therefore, > when required, existing security protocols that provide authenticity > (e.g. RFC 2119 [RFC6071]) can be used. > > Similarly if confidentiality is required, existing encryption > protocols can be used in conjunction with encapsulated NSH. > > Further security considerations are discussed in [nsh-sec]." > > This is handwaiving and will not survive any stage of WG external review. So we as WG are better working on this now! > > Three ideas to get the discussion started: > - The usage of NSH may increase the usage of IP fragments. This can lead to security issues, but potentially in the reverse, as a number of firewalls are blocking IP fragments. See also RFC 1858. This may be worth to document. > > - NSH can be encapsulated in different "transports", e.g., GRE, Ethernet, VXLAN, etc. This has also implications and mainly it will ok to say that these encapsulations have also security considerations that have to be properly obyed. > > - NSH is going to carry meta data that is linked to Personally Identifiable Information (PII). How is NSH dealing with this? This has to be mentioned and the solution has to be documented. > > There are more issues to think about, of course. > > Regards, > > Martin > > _______________________________________________ > 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 Aug 25 01:07:40 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 0042E12D775; Thu, 25 Aug 2016 01:07:35 -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.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147211245499.13582.11401437330157577391.idtracker@ietfa.amsl.com> Date: Thu, 25 Aug 2016 01:07:34 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-control-plane-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 08:07:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Service Function Chaining (SFC) Control Plane Components & Requirements Author : Mohamed Boucadair Filename : draft-ietf-sfc-control-plane-07.txt Pages : 29 Date : 2016-08-25 Abstract: This document describes requirements for conveying information between Service Function Chaining (SFC) control elements and SFC data plane functional elements. Also, this document identifies a set of control interfaces to interact with SFC-aware elements to establish, maintain or recover service function chains. This document does not specify protocols nor extensions to existing protocols. This document exclusively focuses on SFC deployments that are under the responsibility of a single administrative entity. Inter-domain considerations are out of scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-control-plane-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 25 01: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 D1D6F12D589 for ; Thu, 25 Aug 2016 01:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfpp6xQLCEN5 for ; Thu, 25 Aug 2016 01:17:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CAC12D108 for ; Thu, 25 Aug 2016 01:17:47 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B477632496B; Thu, 25 Aug 2016 10:17:45 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 87CF42380B0; Thu, 25 Aug 2016 10:17:45 +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; Thu, 25 Aug 2016 10:17:45 +0200 From: To: "Alia Atlas (akatlas@gmail.com)" Thread-Topic: I-D Action: draft-ietf-sfc-control-plane-07.txt Thread-Index: AQHR/qfEo7UJ7U1IGUWsRM0bRC6z/qBZUkVg Date: Thu, 25 Aug 2016 08:17:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E091B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <147211245499.13582.11401437330157577391.idtracker@ietfa.amsl.com> In-Reply-To: <147211245499.13582.11401437330157577391.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.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-07.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, 25 Aug 2016 08:17:50 -0000 Dear Alia, all,=20 I prepared an updated version to (hopefully) clarify several of the points = raised by Alia in her review. The main changes are as follows: * clarify why no flow exchanges are included in the draft * add new text about SFC dynamics + update the text about the timeless of S= FC control (whenever appropriate) * add an introduction text to the reference architecture * add some text to precise that metadata/encapsulation supported by underly= ing SFC data elements is also part of the information that can be gathered * precise that a validity timer may be associated with SFC forwarding entri= es * cite an example to migrate an SFP (make-before-break) + precise this is d= eployment-specific * add new text to indicate that the load information can be communicated to= a head-end * ..and other edits. FWIW, a diff is available here: https://www.ietf.org/rfcdiff?url1=3Ddraft-i= etf-sfc-control-plane-06&url2=3Ddraft-ietf-sfc-control-plane-07=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: jeudi 25 ao=FBt 2016 10:08 > =C0=A0: i-d-announce@ietf.org > Cc=A0: sfc@ietf.org > Objet=A0: I-D Action: draft-ietf-sfc-control-plane-07.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 : Service Function Chaining (SFC) Control Plane > Components & Requirements > Author : Mohamed Boucadair > Filename : draft-ietf-sfc-control-plane-07.txt > Pages : 29 > Date : 2016-08-25 >=20 > Abstract: > This document describes requirements for conveying information > between Service Function Chaining (SFC) control elements and SFC data > plane functional elements. Also, this document identifies a set of > control interfaces to interact with SFC-aware elements to establish, > maintain or recover service function chains. This document does not > specify protocols nor extensions to existing protocols. >=20 > This document exclusively focuses on SFC deployments that are under > the responsibility of a single administrative entity. Inter-domain > considerations are out of scope. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sfc-control-plane-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-07 >=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 From nobody Thu Aug 25 08:40: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 2BE7F12D1D8 for ; Thu, 25 Aug 2016 08:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vREBO9TYrejI for ; Thu, 25 Aug 2016 08:40:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D50A12D190 for ; Thu, 25 Aug 2016 08:40:05 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D5EFA3244E0; Thu, 25 Aug 2016 17:40:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.21]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B7E224C074; Thu, 25 Aug 2016 17:40:03 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 17:40:03 +0200 From: To: "Paul Quinn (paulq)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt Thread-Index: AQHR/UXf+K2Wk0PpFkuoPewYh4aM6KBZ0hDQ Date: Thu, 25 Aug 2016 15:40:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E0952B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <147196046137.30731.1399811299254089080.idtracker@ietfa.amsl.com> <60F54D29-49F6-4962-963B-93FF6F4DF1A1@cisco.com> In-Reply-To: <60F54D29-49F6-4962-963B-93FF6F4DF1A1@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Subject: Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:40:07 -0000 Hi Paul, I have a comment about this text: Type: the Type field is split into two ranges - 0 to 127 for non- critical options and 128-255 for critical options. While the value allocation is the responsibility of the MD Class owner, critical options MUST NOT be allocated from the 0 to 127 range and non- critical options MUST NOT be allocated from the 128-255 range. * Do you have an example of metadata that is critical for all chains, all d= eployments? * Wouldn't be more appropriate to have one single registry for "type" with = C-bit be a configurable parameter to be set by the administrator of the SFC= -enabled domain? Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Paul Quinn (paulq) > Envoy=E9=A0: mardi 23 ao=FBt 2016 16:02 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt >=20 > Dear WG, >=20 > This version includes much of the feedback/review/comments from this list= . >=20 >=20 >=20 > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-06.txt > > Date: August 23, 2016 at 9:54:21 AM EDT > > To: > > Cc: sfc@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Service Function Chaining of the IETF. > > > > Title : Network Service Header > > Authors : Paul Quinn > > Uri Elzur > > Filename : draft-ietf-sfc-nsh-06.txt > > Pages : 37 > > Date : 2016-08-23 > > > > Abstract: > > This document describes a Network Service Header (NSH) inserted onto > > packets or frames to realize service function paths. NSH also > > provides a mechanism for metadata exchange along the instantiated > > service path. NSH is the SFC encapsulation required to support the > > Service Function Chaining (SFC) Architecture (defined in RFC7665). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-sfc-nsh-06 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-06 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Aug 26 02:31: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 195C512D1BD for ; Fri, 26 Aug 2016 02:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 iCo3BM8qMYn5 for ; Fri, 26 Aug 2016 02:31:28 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4D412D552 for ; Fri, 26 Aug 2016 02:31:27 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 0F530C0100; Fri, 26 Aug 2016 11:31:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id D27D41A0070; Fri, 26 Aug 2016 11:31:25 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 11:31:24 +0200 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Ba4oYg Date: Fri, 26 Aug 2016 09:31:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E099F0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> In-Reply-To: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.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, 26 Aug 2016 09:31:30 -0000 Hi Jim, all, Likewise, I would like to see this document progress as well.=20 In addition to the comment raised in a separate message about the C-bit of = TLVs, I have the following comments: (1) Section 2: I suggest to delete the following sentence:=20 NSH is designed to be easy to implement across a range of devices, both physical and virtual, including hardware platforms. Reason: the use of "easy to implement" should be justified if that text is = maintained. Otherwise, this is subjective.=20 or to reword it as follows:=20 "NSH can be implemented in both physical and virtual platforms." (2) Section 2.3: I suggest to change this OLD text: The semantics of the shared metadata is communicated via a control plane, which is outside the scope of this document, to participating nodes. NEW: The semantics of=20 the shared metadata is communicated via a control plane (Section 3.3 of [I-= D.ietf-sfc-control-plane]). (3) Section 2.3- Not sure I would maintain this text:=20 5. NSH offers a common and standards-based header for service chaining to all network and service nodes. "to all" is not accurate as "legacy" nodes are still there. =20 (4) Section 2.3: OLD: Transport Agnostic: NSH is transport independent and is often carried via a network transport protocol, NEW: Transport Agnostic: NSH is transport independent. Any network transport pro= tocol can be used to transport NSH-encapsulated traffic. (5) Section 3.2: NSH implementations MUST support MD-Type =3D 0x1, and SHOULD support MD- Type =3D 0x2. Because: * of potential interoperability issues. * MD#2 is more compact when no metadata is to be supplied * MD#2 allows to convey more information compared to MD#1 I suggest we revisit that sentence to have MD#2 be mandatory to be supporte= d (my favorite option), or at least require that both MDs defined in this s= pec MUST be supported.=20 (6) Section 3.2: C bit: Indicates that a critical metadata TLV is present. This bit acts as an indication for hardware implementers to decide how to handle the presence of a critical TLV without necessarily needing to parse all TLVs present. For an MD Type of 0x1 (i.e. no variable length metadata is present), the C bit MUST be set to 0x0. 6.1. What is the behavior of the implementation if C-bit is set but not cri= tical metadata is found in the payload? 6.2. What is the behavior of the implementation if C-bit is unset but a cri= tical metadata is found in the payload? 6.3. What is the behavior of the implementation with regards to this bit if= a critical metadata is added in-path? 6.4. What is the behavior of the implementation with regards to this bit if= a critical metadata is stripped in-path? =20 6.5. Should the specification recommend an order of metadata so that critic= al metadata are always positioned first? (7) Section 3.3: The following text=20 " ... however the control plane MAY configure the initial value of SI as appropriate (i.e. taking into account the length of the service function path). " is not aligned with the outcome of the discussion we had during the WG LC o= f draft-ietf-sfc-control-plane (https://www.ietf.org/mail-archive/web/sfc/c= urrent/msg04594.html): The control plane must instruct the classifier about the initial values of the Service Index (SI). 7.1. I suggest to modify NSH draft accordingly.=20 7.2. Please consider adding a reference to draft-ietf-sfc-control-plane (8) Section 3.4: I still do think this section is underspecified. E.g.,=20 8.1. The use of "Mandatory Context Header" conflicts with this text in Sect= ion 3: A Network Service Header (NSH) contains service path information and optionally metadata that are added to a packet or frame and used to ^^^^^^^^^^^^^^^^^^^ create a service plane. 8.2. The specification does not forbid that all context headers are set to = zero. Otherwise, MD#2 should be used instead. 8.3. The specification does not specify how these context headers are to be= validated.=20 8.4. I still don't understand why four headers are chosen. =20 (9) Section 3.5.1: The length of "Metadata Class" is over-dimensioned. I suggest to reduce the= length of this field and increase the length of "Type". =20 For example, let's consider the proposal in https://tools.ietf.org/html/dra= ft-napper-sfc-nsh-broadband-allocation-00#section-4.2:=20 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 =3D 3GPP |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Figure 5: TLV Allocation The intended use of the header is for TLVs associated with 3GPP Radio Access Networks as described in [TS.29.230]. This TLV can be used by 3GPP to extend the metadata as per use cases. Having this TLV helps to carry more information that does not fit within the MD Type 0x01. The list of codes in Table 7.1 of TS.29.230 cannot be conveyed with a "Type= " field of 7 bits. (10) Section 4:=20 OLD: +---------------+------------------+-------+----------------+---------+ | | Insert |Select | Update |Service | | | or remove NSH |Service| NSH |policy | | | |Function| |selection| | Component +--------+--------+Path +----------------+ | | | | | | Dec. |Update | | | | Insert | Remove | |Service |Context| | | | | | | Index |Header | | +----------------+--------+--------+-------+--------+-------+---------+ | | + | + | | | + | | |Classifier | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service Function| | + | + | | | | |Forwarder(SFF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service | | | | + | + | + | |Function (SF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |SFC Proxy | + | + | | + | | | +----------------+--------+--------+-------+--------+-------+---------+ NEW: +---------------+------------------+-------+----------------+---------+ | | Insert |Select | Update |Service | | | or remove NSH |Service| NSH |policy | | | |Function| |selection| | Component +--------+--------+Path +----------------+ | | | | | | Dec. |Update | | | | Insert | Remove | |Service |Context| | | | | | | Index |Header | | +----------------+--------+--------+-------+--------+-------+---------+ | | + | + | | | + | | |Classifier | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service Function| | + | + | | | | |Forwarder(SFF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service | | | | + | + | + | |Function (SF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |SFC Proxy | + | + | | + | + | | +----------------+--------+--------+-------+--------+-------+---------+ (11) Section 7.2: Please consider adding an IPv6 example. Thank you. Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard > (jguichar) > Envoy=E9=A0: mardi 23 ao=FBt 2016 18:48 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > Dear WG: >=20 > Please review this new version of the SFC encapsulation to make sure that > your comments from the previous WGLC have been addressed. >=20 > Any comments and/or concerns please post to the mailing list within the > next two weeks so that this work can be progressed. >=20 > As a heads up, if there are still substantive comments we plan to hold an > interim meeting on September 15th to address any outstanding issues >=20 >=20 > Thanks! >=20 > Jim, Martin, & Thomas >=20 >=20 >=20 >=20 > On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: >=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. > > > > Title : Network Service Header > > Authors : Paul Quinn > > Uri Elzur > > Filename : draft-ietf-sfc-nsh-07.txt > > Pages : 37 > > Date : 2016-08-23 > > > >Abstract: > > This document describes a Network Service Header (NSH) inserted onto > > packets or frames to realize service function paths. NSH also > > provides a mechanism for metadata exchange along the instantiated > > service path. NSH is the SFC encapsulation required to support the > > Service Function Chaining (SFC) Architecture (defined in RFC7665). > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > > > >There's also a htmlized version available at: > >https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 > > > >A diff from the previous version is available at: > >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 > > > > > >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/ > > > >_______________________________________________ > >sfc mailing list > >sfc@ietf.org > >https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Aug 26 05:53: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 C7DBA12D787; Fri, 26 Aug 2016 05:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 K19m1QMP2UKy; Fri, 26 Aug 2016 05:52:56 -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 959CA12D114; Fri, 26 Aug 2016 05:51:48 -0700 (PDT) Received: from smtptc.telefonica.com (tgtim3c01.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5AD354611C7; Fri, 26 Aug 2016 14:51:46 +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 smtptc.telefonica.com (Postfix) with ESMTPS id 39BE64611B6; Fri, 26 Aug 2016 14:51:46 +0200 (CEST) Received: from EUR03-AM5-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; Fri, 26 Aug 2016 14:51:36 +0200 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Fri, 26 Aug 2016 12:51:33 +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.0599.010; Fri, 26 Aug 2016 12:51:33 +0000 From: "Diego R. Lopez" To: "Frank Brockners (fbrockne)" Thread-Topic: [sfc] Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tCABdCDgIAu5HmA Date: Fri, 26 Aug 2016 12:51:33 +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: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2.140.207.136] x-ms-office365-filtering-correlation-id: 0cc2d758-56a3-46ec-0e60-08d3cdafb587 x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2167; 6:G8ncV+rluyBQCmMFsKSdK+D4KRcQ8bH9vC4VXe4pheab6GmtgQcGHojVW+8ThaQ34I0LpNI1vr3VkTpe1b/6U1+HLvQZrMWR8ir43wOK31nw8Vm48QcVcyFlBEXtR5wBlWiULF4vcFFLtJUGX/wO/ZQpnFpVzbRReXn6B82tZ9vzVFSB/Veuc4QdC3mCDTuvzuvWpzwCPWhf3M4QvDydSSKGENE6DVy69qU8IKSVEFVgJSD0I31QSXJjtZebTSlUuD2KeZeOUtDMDJv5Efka03wrct+vvqUNIGvHTLpUOsw=; 5:uy8f3l9uPFR2SXBFnw1zUg7VBj8CatKytyYd4SwD8QqB9ecygaX+DXLWw+sgXMbBfNre7P2HzK6/Ssn+6V9oC85UTa0yAYp73R2JdrTVY224eCbFGTlVlovsQoDa2NGPlI0jFm4v4BUz4c+Fa/TnBw==; 24:uli8VwsK/pENWf78NOsOAXwq0m8Z5axaYDIBwmYdg9LfYbqV8INk+pxQAUjNPheV8426B6gZtIR44PGQA4CYEjV7mVsno+m0P8J8oANMDs8=; 7:aYtPb0lsBHdwOo4uF9N/zHlbRVfpoHlufHc6OOLG1sQhxiZk7snjo6kgwtiuqV8kJKYkrbBiNt5C1/s4tjgq4JzGoyxpSIrfhJ9tDFd6fUQAgRzbb3DkcMrWtU18xbZ/VtVW7qHTBhRYm+A8ObCkBYogUsxB9PQsZRnGyggp/S5phW2gQz/wtmHYe/CsadJEAwQtFQWSUaUMDpTkXxV3nRsy/dIQUaEiaU/1+S7Aj55PlTLcKhZPTflCmyL3xoLp x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0601MB2167; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(40392960112811)(278428928389397)(192374486261705)(788757137089)(95692535739014)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB6PR0601MB2167; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2167; x-forefront-prvs: 00462943DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(252514010)(189002)(199003)(24454002)(51914003)(377454003)(5890100001)(3900700001)(8936002)(81166006)(345774005)(7906003)(554214002)(68736007)(36756003)(106356001)(11100500001)(7846002)(3280700002)(3660700001)(86362001)(7736002)(2906002)(54356999)(50986999)(83716003)(8676002)(4326007)(76176999)(561944003)(81156014)(82746002)(77096005)(15975445007)(122556002)(110136002)(5660300001)(101416001)(97736004)(2950100001)(189998001)(105586002)(93886004)(102836003)(2900100001)(33656002)(6116002)(3846002)(5002640100001)(19580395003)(586003)(10400500002)(19617315012)(66066001)(92566002)(19580405001)(87936001)(16236675004)(104396002)(579004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2167; H:DB6PR0601MB2167.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_F40A6DC030A64CB79DE8C8DAA3258CE3telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2016 12:51:33.5117 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2167 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Cc: Tal Mizrahi , "sfc@ietf.org" , "nvo3@ietf.org" , "Sashank Dara \(sadara\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@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: Fri, 26 Aug 2016 12:53:03 -0000 --_000_F40A6DC030A64CB79DE8C8DAA3258CE3telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRnJhbmssDQoNClRoaXMgaXMgYSByZWFsbHkgaW50ZXJlc3RpbmcgcGllY2Ugb2Ygd29yaywg YW5kIEkgbXVzdCBzYXkgd2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgdGhlIFBvVCBpc3N1ZSB3aXRo IHNvbWUgY3VzdG9tZXJzICh0aG91Z2ggd2UgdXNlZCB0byBjYWxsIGl0IOKAnGFzc3VyZWQgcGF0 aCB0cmF2ZXJzYWzigJ0pIGFuZCB3ZSBoYXZlIGJlZW4gZXhwbG9yaW5nIHBvc3NpYmxlIHNvbHV0 aW9ucywgdHJ5aW5nIHRvIGNvbWJpbmUgZ29vZC1lbm91Z2ggc2VjdXJpdHkgd2l0aCBhIHJlYXNv bmFibGUgYW1vdW50IG9mIGNvbXB1dGF0aW9uYWwgY29tcGxleGl0eSwgYW5kIEkgYW0gZ2xhZCB0 byBzZWUgYSBwcmFjdGljYWwgcHJvcG9zYWwgYWRkcmVzc2luZyB0aGlzIHByb2JsZW0uIEkgaGFk IGEgYnJpZWYgY29udmVyc2F0aW9uIHdpdGggQ2FybG9zIHdoaWxlIGluIEJlcmxpbiwgYnV0IEkg YW0gYWZyYWlkIHRoYXQgdGhlIElFVEYgd2VlayB3YXMgdG9vIGhlY3RpYyBmb3IgYSBkZXRhaWxl ZCBkaXNjdXNzaW9uLg0KDQpMZXQgbWUgYWRkIHRvIFRhbOKAmXMgYW5hbHlzaXMgYSB0aGlyZCBp c3N1ZSB0byBjb25zaWRlci4gTXkgdW5kZXJzdGFuZGluZyBvZiBTaGFtaXLigJlzIHBvbHlub21p YWxzIGlzIHRoYXQgdGhleSBjYW4gYmUgdXNlZCB0byByZWNvbnN0cnVjdCBhIHNlY3JldCBmcm9t IE4gcGllY2VzIHlvdSBuZWVkIGEgcG9seW5vbWlhbCBvZiBkZWdyZWUgTi0xLCBzbyB0aGF0IGlt cGxpZXMgdGhhdCB0aGUgdmVyaWZpY2F0aW9uIGlzIGxpbWl0ZWQgdG8gYSBjZXJ0YWluIG51bWJl ciBvZiBTRnMgKG9yIFNGRnMpLCBkZXBlbmRpbmcgb24gdGhlIGRlZ3JlZSBvZiB0aGUgYXBwbGll ZCBwb2x5bm9taWFsLiBXZeKAmWQgbmVlZCBhbmQgYXNzZXNzbWVudCBvbiB0aGUgY29tcHV0YXRp b25hbCBjb21wbGV4aXR5IGFzc29jaWF0ZWQgd2l0aCBwYXRoIGxlbmd0aCBhbmQgdGhlIHJlcXVp cmVtZW50cyBmb3IgYWRhcHRhdGlvbiBvZiB0aGUgUG9UIG5vZGVzIChJIGd1ZXNzIFNETi9ORlYg Y291bGQgcGxheSBhIHJvbGUgdGhlcmXigKYpDQoNCkJlIGdvb2RlLA0KDQpPbiAyMCBKdWwgMjAx NiwgYXQgMDk6MTYgLCBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVAY2lzY28u Y29tPG1haWx0bzpmYnJvY2tuZUBjaXNjby5jb20+PiB3cm90ZToNCg0KSGkgVGFsLA0KDQp3ZWxs Li4uIGlmIHlvdSBjb3VsZCBwcm90ZWN0IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGRhdGEgc3RyZWFt IGJldHdlZW4gc291cmNlIGFuZCBkZXN0aW5hdGlvbiwgeW91IHdvdWxkIG5vdCBiZSBhYmxlIHRv IHN3YXAgdGhlIGNvbnRlbnQgb2YgYSBwYWNrZXQg4oCTIHdoaWNoIGlzIHdoYXQgeW91ciBhdHRh Y2sgaXMgYWxsIGFib3V0LiBSYXRoZXIgdGhhbiBjb250aW51ZSBhcmd1aW5nIHRoZSBwb2ludCwg bGV04oCZcyBhY2tub3dsZWRnZSB0aGF0IGl0IGlzIGEgdmFsaWQgYXR0YWNrIGFuZCBsZXTigJlz IGxvb2sgZm9yIGEgc29sdXRpb24gOi0pLiBXZeKAmWxsIG5lZWQgdG8gY291cGxlIFBPVCB0byBp bnRlZ3JpdHkgcHJvdGVjdGlvbiBvZiB0aGUgcGFja2V0Lg0KDQpIZW5jZSwgSeKAmWQgbGlrZSB0 byBjb21lIGJhY2sgdG8gbXkgcXVlc3Rpb24gYXNrZWQgYmVsb3c6DQpEbyB5b3UgKGFuZCB0aGUg ZW50aXJlIFNGQyB0ZWFtIGhlcmUpIHRoaW5rIGl0IGlzIHdvcnRod2hpbGUgdG8gcHJvdmlkZSBh IHNvbHV0aW9uIGZvciBhIGRlcGxveW1lbnQgd2hpY2ggaXMgZXhwZWN0ZWQgdG8gKm5vdCogYWx0 ZXIgdGhlIHBhY2tldCBwYXlsb2FkPw0KDQpUaGFua3MsIEZyYW5rDQoNCkZyb206IFRhbCBNaXpy YWhpIFttYWlsdG86dGFsbWlAbWFydmVsbC5jb21dDQpTZW50OiBEaWVuc3RhZywgMTkuIEp1bGkg MjAxNiAxODoxNQ0KVG86IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNj by5jb208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+OyBTYXNoYW5rIERhcmEgKHNhZGFyYSkg PHNhZGFyYUBjaXNjby5jb208bWFpbHRvOnNhZGFyYUBjaXNjby5jb20+PjsgZHJhZnQtYnJvY2tu ZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWJyb2NrbmVy cy1wcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPg0KQ2M6IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+ OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFF1ZXN0 aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQoNCkhpIEZyYW5rLA0KDQpUaGUg UE9UIHJlcGxhY2VtZW50IGF0dGFjayAoMS4pIGlzIG5vdCBhbiBhdHRhY2sgb24gdGhlIGludGVn cml0eS4gSXQgaXMgYW4gYXR0YWNrIG9uIHRoZSBwYXRoIHZlcmlmaWNhdGlvbi4NClRoaXMgc2lt cGxlIGF0dGFjayBjYW4gY2F1c2UgdGhlIHZlcmlmaWVyIHRvIGFjY2VwdCBhIHBhY2tldCB0aGF0 IGRpZCBub3QgZ28gdGhyb3VnaCB0aGUgZmlyZXdhbGwgU0YgKGV2ZW4gdGhvdWdoIGl0IHNob3Vs ZCkuIEkgYmVsaWV2ZSB0aGlzIGlzIGV4YWN0bHkgdGhlIHByb2JsZW0geW91IHdlcmUgYWltaW5n IHRvIGFkZHJlc3MgaW4gdGhpcyBkcmFmdC4NCg0KVGhhbmtzLA0KVGFsLg0KDQpGcm9tOiBGcmFu ayBCcm9ja25lcnMgKGZicm9ja25lKSBbbWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbV0NClNlbnQ6 IFR1ZXNkYXksIEp1bHkgMTksIDIwMTYgNjowMCBQTQ0KVG86IFRhbCBNaXpyYWhpOyBTYXNoYW5r IERhcmEgKHNhZGFyYSk7IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi10cmFuc2l0QHRvb2xzLmll dGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRm Lm9yZz4NCkNjOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47IG9wc2F3Z0BpZXRm Lm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNp dCBkcmFmdA0KDQpIaSBUYWwsDQoNCnRoYW5rcyBmb3IgdGhlIHN1bW1hcnkuIFdl4oCZbGwgcHJv dmlkZSBtb3JlIGRldGFpbHMgb24gMi4gUGVyIG15IGVhcmxpZXIgcG9pbnQg4oCTIDEuIGlzIGFu IGludGVyZXN0aW5nIGRpc2N1c3Npb24sIGdpdmVuIHRoYXQgd2UgZG9u4oCZdCBjbGFpbSB0byBw cm92aWRlIGludGVncml0eSBwcm90ZWN0aW9uIGZvciB0aGUgcGFja2V0IHBheWxvYWQuIE9yIGlu IG90aGVyIHRlcm1zIOKAkyB0byBiZSBleGFjdDogV2hhdCBQT1QgcHJvdmlkZXMgaXMgYSBwcm9v ZiB0aGF0IHRoZSBQT1QtaGVhZGVyL21ldGEtZGF0YSB0cmFuc2l0ZWQgYWxsIHRoZSByZXF1aXJl ZCBub2Rlcy4gVGhlcmUgaXMgbm8gYXNzb2NpYXRpb24gKGFuZCB0aHVzIHByb29mKSBwcm92aWRl ZCBmb3IgdGhlIGFkZGl0aW9uYWwgZGF0YSBjYXJyaWVkIGFsb25nIHdpdGggdGhlIFBPVC1oZWFk ZXIg4oCTIG5laXRoZXIgaGVhZGVyIG5vciBwYXlsb2FkLiBBcyBhIGNvbnNlcXVlbmNlLCBhdHRh Y2tzIHdoaWNoIGNoYW5nZSB0aGUgcGFja2V0IHBheWxvYWQgd29u4oCZdCBiZSBkZXRlY3RlZC9t aXRpZ2F0ZWQuIFdl4oCZbGwgZXhwbGljaXRseSBzdGF0ZSB0aGlzIGluIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBpbiB0aGUgbmV4dCByZXYgb2YgdGhlIGRvY3VtZW50Lg0KV2hhdCB3ZSBj b3VsZCBjb25zaWRlciBpcyBsaW5raW5nIHRoZSBSTkQgbnVtYmVyIHRvIENSQyBhY3Jvc3MgdGhl IHBhY2tldCBwYXlsb2FkIG9yIHNpbWlsYXIg4oCTIGJ1dCB0aGF0IHdheSB3ZeKAmWQgcmVzdHJp Y3QgdGhlIGFwcGxpY2FiaWxpdHkgdG8gZGVwbG95bWVudHMgd2hlcmUgdGhlIHBhY2tldCBwYXls b2FkIGlzbuKAmXQgY2hhbmdlZCBhY3Jvc3MgdGhlIHBhdGggKHdoaWNoIG1pZ2h0IG5vdCBhcHBs eSB0byBjZXJ0YWluIGRlcGxveW1lbnQg4oCTIGUuZy4gV0FOIG9wdGltaXphdGlvbiAvIGNvbXBy ZXNzaW9uIHNjaGVtZXMpLg0KRG8geW91IHRoaW5rIGl0IGlzIHdvcnRod2hpbGUgdG8gcHJvdmlk ZSBhIHNvbHV0aW9uIGZvciBhIGRlcGxveW1lbnQgd2hpY2ggaXMgZXhwZWN0ZWQgdG8gbm90IGFs dGVyIHRoZSBwYWNrZXQgcGF5bG9hZD8NCg0KVGhhbmtzLA0KRnJhbmsNCg0KRnJvbTogVGFsIE1p enJhaGkgW21haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbV0NClNlbnQ6IERpZW5zdGFnLCAxOS4gSnVs aSAyMDE2IDE3OjQ0DQpUbzogU2FzaGFuayBEYXJhIChzYWRhcmEpIDxzYWRhcmFAY2lzY28uY29t PG1haWx0bzpzYWRhcmFAY2lzY28uY29tPj47IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxm YnJvY2tuZUBjaXNjby5jb208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+OyBkcmFmdC1icm9j a25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tu ZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+DQpDYzogc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9y Zz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUXVl c3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQNCg0KSGksDQoNClRvIHN1bW1h cml6ZSBteSB0YWtlIG9uIHRoaXMgdGhyZWFkOg0KVGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBoYXMg dHdvIHNpZ25pZmljYW50IHZ1bG5lcmFiaWxpdGllcyB0aGF0IChpbiBteSB1bmRlcnN0YW5kaW5n KSBhcmUgY3VycmVudGx5IG5vdCBhZGRyZXNzZWQ6DQoxLiAgICAgICBBIG1hbi1pbi10aGUtbWlk ZGxlIGNhbiByZXBsYWNlIHRoZSBQT1Qgb2YgcGFja2V0IEEgd2l0aCB0aGUgUE9UIG9mIHBhY2tl dCBCLg0KMi4gICAgICAgSXQgaXMgcG9zc2libGUgdG8gcmVwbGF5IFBPVHMgd2l0aGluIGEgY2Vy dGFpbiB0aW1lIHdpbmRvdywgd2hvc2UgbGVuZ3RoIGlzIGRldGVybWluZWQgYnkgdGhlIHRpbWVz dGFtcCByZXNvbHV0aW9uLg0KDQpTYXNoYW5rLCB0aGFua3MgZm9yIGFncmVlaW5nIHRvIGxvb2sg aW50byBpdCBmdXJ0aGVyLiBJIGFtIGxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIGluc2lnaHRzIG9u IHRoaXMuDQoNClJlZ2FyZHMsDQpUYWwuDQoNCkxpbmsgdG8gdGhlIGRyYWZ0OiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXQtMDENCg0K DQoNCkZyb206IFNhc2hhbmsgRGFyYSAoc2FkYXJhKSBbbWFpbHRvOnNhZGFyYUBjaXNjby5jb21d DQpTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDEyOjIwIFBNDQpUbzogVGFsIE1penJhaGk7 IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpOyBkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJh bnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5z aXRAdG9vbHMuaWV0Zi5vcmc+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdA0KDQoN Cg0KSSB3YW50IHRvIGFzayBhIHNpbXBsZSBxdWVzdGlvbjoNCklmIHRoZSBhdHRhY2tlciBhdHRh Y2hlcyB0aGUgUE9UIG9mIHBhY2tldCBBIChpbmRpY2F0aW5nIHRoZSBwYXRoIHRocm91Z2ggMSwz LDUsNikgdG8gcGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2VwdCBwYWNrZXQgQiBhbmQg YmVsaWV2ZSB0aGF0IGl0cyBwYXRoIHdhcyBpbmRlZWQgKDEsMyw1LDYpPw0KDQpbU0RdIElmIHRo ZSB2ZXJpZmllciBpcyBwcm9ncmFtbWVkIHRvIGp1c3QgdmFsaWRhdGUgdGhlIFBPVCBtZXRhIGRh dGEgYWdhaW5zdCB7MSwzLDUsNn0gdGhlbiB5ZXMgaXQgYWNjZXB0cyBpdC4NCklmIHRoZSB2ZXJp ZmllciBpcyBwcm9ncmFtbWVkIHRvIGNvbnN1bHQgYSBwb2xpY3kgZGF0YWJhc2UgdG8gY3Jvc3Mg Y2hlY2sgaWYgdGhlIHJlY29uc3RydWN0ZWQgcGF0aCB7MSwzLDUsNn0gaXMgYXMgcGVyIHRoZSBw b2xpY2llcyB0aGVuIG5vICwgaXQgZHJvcHMgaXQgLg0KDQpCdXQgSSBzZWUgeW91ciBwb2ludCAs IHRoYXQgdGhlIHBhcmFtZXRlcnMgdXNlZCBpbiBQT1QgZGF0YSBkb25vdCBjb25zaWRlciB0aGUg cGF0aCBvciBub2RlLWlkcyBldGMgLiBXZSBzaGFsbCBkaXNjdXNzIHRoaXMgaW50ZXJuYWxseSBh bmQgZ2V0IGJhY2suDQoNCkFsc28sIFdlIHNoYWxsIGdldCBiYWNrIHdpdGggbW9yZSBjb25jcmV0 ZSBudW1iZXJzIG9mIHRoZSB0aW1lc3RhbXAgcmVzb2x1dGlvbiBhbmQgY2FjaGUgc2l6ZXMgKG9y IG90aGVyIGJldHRlciBhcHByb2FjaGVzKS4NCg0KVGhhbmsgeW91IHNvIG11Y2ggZm9yIGFsbCB0 aGUgaW5wdXRzLg0KDQoNCg0KRnJvbTogVGFsIE1penJhaGkNClNlbnQ6IFR1ZXNkYXksIEp1bHkg MTksIDIwMTYgMTA6MjggQU0NClRvOiAnU2FzaGFuayBEYXJhIChzYWRhcmEpJzsgRnJhbmsgQnJv Y2tuZXJzIChmYnJvY2tuZSk7IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi10cmFuc2l0QHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5p ZXRmLm9yZz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUkU6 IFF1ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQoNCkRlYXIgU2FzaGFu aywNCg0KSSByZWFsbHkgYXBwcmVjaWF0ZSB0aGUgcXVpY2sgYW5kIGRldGFpbGVkIHJlc3BvbnNl cy4NCg0KPj4+TGV0cyB0YWtlIGNvcnJlY3QgcGF0aCB0YWtlbiBieSBQYWNrZXQgQSAgdG8gYmUg UGF0aDEgLSAoIDEsMyw1LDYpIG5vZGVzLg0KPj4+TGV0cyBhc3N1bWUgaW5jb3JyZWN0IHBhdGgg dG8gYmUgUGFja2V0IEIgaS5lLiBQYXRoMiAtICAoMSwyLDMsNikuDQo+Pj4NCj4+PklmIHRoZSBh dHRhY2tlciBjb3VsZCB0YWtlIHZhbHVlcyBmcm9tIFBhdGgxIGFuZCByZWF0dGFjaCB0aGVtIHRv IFBhdGgyICwNCj4+PnRoZSByZWNvbnN0cnVjdGlvbiBmb3IgUGFja2V0QiB3b3VsZCByZXN1bHQg aW4gKDEsMyw1LDYpIGluc3RlYWQgb2YgKDEsMiwzLDYpLg0KPj4+VGhpcyBjb3VsZCBiZSBjb21w YXJlZCB3aXRoIHRvcG9sb2d5L3BvbGljeSBkYiBpbmZvcm1hdGlvbiBmb3IgYW55IHBvbGljeQ0K Pj4+dmlvbGF0aW9ucy4gUE9UIGRvZXMgbm90IGVuZm9yY2UgYSBwYXJ0aWN1bGFyIHBhdGggdG8g YmUgdGFrZW4uDQo+PlNvIHBhY2tldCBCIHNraXBwZWQgbm9kZSA1IChlLmcuIHRoZSBmaXJld2Fs bCBTRiksIGJ1dCB0aGUgdmVyaWZpZXIgYmVsaWV2ZXMgaXQgd2VudCB0aHJvdWdoIHRoZSBjb3Jy ZWN0IHBhdGguDQo+PldvdWxkIHlvdSBhZ3JlZT8NCj5bU0RdIFRoZSB2ZXJpZmllciBvbmx5IGNv bnN0cnVjdHMgdGhlIHBhdGggdGhlIHBhY2tldCB0b29rIGFjY3VyYXRlbHksIGl0IGlzIHVwdG8N Cj50aGUgYXBwbGljYXRpb24gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQgdmlvbGF0ZXMgYW55IHBv bGljaWVzIChJLmUgbWlzc2luZyBhbnkgZnVuY3Rpb24pDQo+VGhlIGJvdHRvbSBsaW5lIGlzICwg YW4gYXR0YWNrZXIgdGFraW5nIGEgZGlmZmVyZW50IHBhdGggY2Fubm90IGdldCBhd2F5IHdpdGgg aXQgIQ0KPlRoZSB3aG9sZSBpbnRlbnQgb2Yg4oCccHJvb2Ytb2YtdHJhbnNpdOKAnSBpcyB0byBw cm92ZSB0aGUgcGF0aCBwYWNrZXQgaGFzIHRha2VuIGV4YWN0bHkuDQo+UE9UIGRvZXMgbm90IGRl ZmluZSB3aGV0aGVyIGl0IGdvb2QvYmFkIHBhdGguIEl0IGlzIHVwdG8gaGlnaCBsZXZlbCBhcHBs aWNhdGlvbnMgb24gd2hhdA0KPmRvIHdpdGgg4oCccmVjb25zdHJ1Y3RlZOKAnSBwYXRoLg0KDQoN Cg0KSSB3YW50IHRvIGFzayBhIHNpbXBsZSBxdWVzdGlvbjoNCklmIHRoZSBhdHRhY2tlciBhdHRh Y2hlcyB0aGUgUE9UIG9mIHBhY2tldCBBIChpbmRpY2F0aW5nIHRoZSBwYXRoIHRocm91Z2ggMSwz LDUsNikgdG8gcGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2VwdCBwYWNrZXQgQiBhbmQg YmVsaWV2ZSB0aGF0IGl0cyBwYXRoIHdhcyBpbmRlZWQgKDEsMyw1LDYpPw0KDQoNCj4+SG1tbeKA piBMZXTigJlzIHNheSB3ZSBhcmUgdGFsa2luZyBhYm91dCB0cmFmZmljIGF0IDEwIEdicHMsIHdo aWNoIGlzIHJvdWdobHkNCj4+MSBtaWxsaW9uIHBhY2tldHMgcGVyIHNlY29uZC4gVGhhdCB3b3Vs ZCBtZWFuIHRoZSB2ZXJpZmllciBoYXMgdG8gc3RvcmUgYSBtaWxsaW9uIHZhbHVlcyBvZiBSTkQt Mi4NCj4+TW9yZW92ZXIsIGV2ZXJ5IHRpbWUgYSBwYWNrZXQgYXJyaXZlcywgdGhlIHZlcmlmaWVy IHdvdWxkIGhhdmUgdG8gY29tcGFyZSBpdHMNCj4+Uk5ELTIgdmFsdWUgd2l0aCB0aGUgMSBtaWxs aW9uIHN0b3JlZCB2YWx1ZXMsIGluIG9yZGVyIHRvIHZlcmlmeSB0aGVyZSBpcyBubyByZXBsYXku DQo+PlRoYXQgZG9lcyBub3Qgc291bmQgZmVhc2libGUuDQo+PkFtIEkgbWlzc2luZyBzb21ldGhp bmcgaGVyZT8NCj5bU0RdIFNlY29uZCBsZXZlbCBwcmVjaXNpb24gaXMgb25seSBhbiBleGFtcGxl LCB3ZSBjb3VsZCB1c2UgYXMgbXVjaCBwcmVjaXNpb24gYXMgd2Ugd2FudCB0byByZWR1Y2UgdGhl IG51bWJlciBvZiB2YWx1ZXMgdG8gYmUgY2FjaGVkICENCg0KTXkgcG9pbnQgaXMgdGhhdCBhc3N1 bWluZyByZWFzb25hYmxlIHJlc291cmNlcyBhcmUgdXNlZCwgdGhlIG1lY2hhbmlzbSBpcyB2dWxu ZXJhYmxlIHRvIGEgcmVwbGF5IGF0dGFjay4NCkluIG9yZGVyIHRvIHByb3ZlIG1lIHdyb25nLCBj YW4geW91IHByZXNlbnQgY29uY3JldGUgbnVtYmVycyBvZiB0aGUgdGltZXN0YW1wIHJlc29sdXRp b24gYW5kIHRoZSBjYWNoZSBzaXplPw0KT3RoZXJ3aXNlLCB5b3UgbWF5IGNvbnNpZGVyIHVzaW5n IGEgc2VxdWVuY2UgbnVtYmVyICsgc2xpZGluZyB3aW5kb3cgKGUuZy4sIGFzIGluIElQc2VjKS4N Cg0KDQpUaGFua3MsDQpUYWwuDQoNCg0KDQpGcm9tOiBTYXNoYW5rIERhcmEgKHNhZGFyYSkgW21h aWx0bzpzYWRhcmFAY2lzY28uY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiA5OjU2 IEFNDQpUbzogVGFsIE1penJhaGk7IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpOyBkcmFmdC1i cm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYnJv Y2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc+OyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Yg b2YgVHJhbnNpdCBkcmFmdA0KDQoNCg0KDQo+W1NEXSBPay4gVGhpcyBpcyBhbiBpbnRlcmVzdGlu ZyBhdHRhY2suDQo+DQo+TGV0cyB0YWtlIGNvcnJlY3QgcGF0aCB0YWtlbiBieSBQYWNrZXQgQSAg dG8gYmUgUGF0aDEgLSAoIDEsMyw1LDYpIG5vZGVzLg0KPkxldHMgYXNzdW1lIGluY29ycmVjdCBw YXRoIHRvIGJlIFBhY2tldCBCIGkuZS4gUGF0aDIgLSAgKDEsMiwzLDYpLg0KPg0KPklmIHRoZSBh dHRhY2tlciBjb3VsZCB0YWtlIHZhbHVlcyBmcm9tIFBhdGgxIGFuZCByZWF0dGFjaCB0aGVtIHRv IFBhdGgyICwNCj50aGUgcmVjb25zdHJ1Y3Rpb24gZm9yIFBhY2tldEIgd291bGQgcmVzdWx0IGlu ICgxLDMsNSw2KSBpbnN0ZWFkIG9mICgxLDIsMyw2KS4NCj5UaGlzIGNvdWxkIGJlIGNvbXBhcmVk IHdpdGggdG9wb2xvZ3kvcG9saWN5IGRiIGluZm9ybWF0aW9uIGZvciBhbnkgcG9saWN5DQo+dmlv bGF0aW9ucy4gUE9UIGRvZXMgbm90IGVuZm9yY2UgYSBwYXJ0aWN1bGFyIHBhdGggdG8gYmUgdGFr ZW4uDQoNClNvIHBhY2tldCBCIHNraXBwZWQgbm9kZSA1IChlLmcuIHRoZSBmaXJld2FsbCBTRiks IGJ1dCB0aGUgdmVyaWZpZXIgYmVsaWV2ZXMgaXQgd2VudCB0aHJvdWdoIHRoZSBjb3JyZWN0IHBh dGguDQpXb3VsZCB5b3UgYWdyZWU/DQoNCltTRF0gVGhlIHZlcmlmaWVyIG9ubHkgY29uc3RydWN0 cyB0aGUgcGF0aCB0aGUgcGFja2V0IHRvb2sgYWNjdXJhdGVseSwgaXQgaXMgdXB0byB0aGUgYXBw bGljYXRpb24gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQgdmlvbGF0ZXMgYW55IHBvbGljaWVzIChJ LmUgbWlzc2luZyBhbnkgZnVuY3Rpb24pDQpUaGUgYm90dG9tIGxpbmUgaXMgLCBhbiBhdHRhY2tl ciB0YWtpbmcgYSBkaWZmZXJlbnQgcGF0aCBjYW5ub3QgZ2V0IGF3YXkgd2l0aCBpdCAhIFRoZSB3 aG9sZSBpbnRlbnQgb2Yg4oCccHJvb2Ytb2YtdHJhbnNpdOKAnSBpcyB0byBwcm92ZSB0aGUgcGF0 aCBwYWNrZXQgaGFzIHRha2VuIGV4YWN0bHkuDQpQT1QgZG9lcyBub3QgZGVmaW5lIHdoZXRoZXIg aXQgZ29vZC9iYWQgcGF0aC4gSXQgaXMgdXB0byBoaWdoIGxldmVsIGFwcGxpY2F0aW9ucyBvbiB3 aGF0IGRvIHdpdGgg4oCccmVjb25zdHJ1Y3RlZOKAnSBwYXRoLg0KDQoNCkhtbW3igKYgTGV04oCZ cyBzYXkgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdHJhZmZpYyBhdCAxMCBHYnBzLCB3aGljaCBpcyBy b3VnaGx5IDEgbWlsbGlvbiBwYWNrZXRzIHBlciBzZWNvbmQuIFRoYXQgd291bGQgbWVhbiB0aGUg dmVyaWZpZXIgaGFzIHRvIHN0b3JlIGEgbWlsbGlvbiB2YWx1ZXMgb2YgUk5ELTIuDQpNb3Jlb3Zl ciwgZXZlcnkgdGltZSBhIHBhY2tldCBhcnJpdmVzLCB0aGUgdmVyaWZpZXIgd291bGQgaGF2ZSB0 byBjb21wYXJlIGl0cyBSTkQtMiB2YWx1ZSB3aXRoIHRoZSAxIG1pbGxpb24gc3RvcmVkIHZhbHVl cywgaW4gb3JkZXIgdG8gdmVyaWZ5IHRoZXJlIGlzIG5vIHJlcGxheS4NClRoYXQgZG9lcyBub3Qg c291bmQgZmVhc2libGUuDQpBbSBJIG1pc3Npbmcgc29tZXRoaW5nIGhlcmU/DQoNCltTRF0gU2Vj b25kIGxldmVsIHByZWNpc2lvbiBpcyBvbmx5IGFuIGV4YW1wbGUsIHdlIGNvdWxkIHVzZSBhcyBt dWNoIHByZWNpc2lvbiBhcyB3ZSB3YW50IHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIHZhbHVlcyB0 byBiZSBjYWNoZWQgIQ0KDQoNClNhc2hhbmsNCg0KDQoNCkZyb206IFNhc2hhbmsgRGFyYSAoc2Fk YXJhKSBbbWFpbHRvOnNhZGFyYUBjaXNjby5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAy MDE2IDg6MzMgQU0NClRvOiBUYWwgTWl6cmFoaTsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSk7 IGRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZz47IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFF1ZXN0aW9uIHJlZ2FyZGlu ZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0DQoNCklubGluZSAuLg0KDQoNCldlIGhhdmUgdHdvIGNv bnNlY3V0aXZlIHBhY2tldHMsIEEgYW5kIEI6DQotIFBhY2tldCBBIHRoYXQgd2VudCB0aHJvdWdo IHRoZSBjb3JyZWN0IHBhdGggYW5kIGhhcyBhIGNvcnJlY3QgUE9ULg0KLSBQYWNrZXQgQiB0aGF0 IGRpZCBub3QgZ28gdGhyb3VnaCB0aGUgY29ycmVjdCBwYXRoIGFuZCBkb2VzIG5vdCBoYXZlIGEg Y29ycmVjdCBQT1QuDQogTm93IHRoZSBhdHRhY2tlciBwZXJmb3JtcyBhIOKAmG1peCBhbmQgbWF0 Y2jigJkgYXR0YWNrLCBieSB0YWtpbmcgdGhlIGNvcnJlY3QgUE9UIGZyb20gcGFja2V0IEEgYW5k IGF0dGFjaGluZyBpdCB0byBwYWNrZXQgQi4NClRoZSBhdHRhY2tlciBhbHNvIHRlcm1pbmF0ZXMg cGFja2V0IEEuDQpUaGVyZSBpcyBubyByZXBsYXkgaGVyZSwgYmVjYXVzZSB0aGUgdmVyaWZpZXIg cmVjZWl2ZXMgdGhlIGNvcnJlY3QgUE9UIG9ubHkgb25jZS4gVGhlIHByb2JsZW0gaXMgdGhhdCB0 aGUgY29ycmVjdCBQT1QgaGFwcGVucyB0byBhcnJpdmUgd2l0aCBwYWNrZXQgQi4g4pi5DQpUaHVz LCBwYWNrZXQgQiBhcHBlYXJzIG9rYXkgdG8gdGhlIHZlcmlmaWVyLCBldmVuIHRob3VnaCBpdCBk aWQgbm90IGdvIHRocm91Z2ggdGhlIGNvcnJlY3QgcGF0aC4NCg0KSXMgdGhlcmUgYSB3YXkgdG8g bWl0aWdhdGUgdGhpcyBhdHRhY2s/DQoNCltTRF0gT2suIFRoaXMgaXMgYW4gaW50ZXJlc3Rpbmcg YXR0YWNrLg0KDQpMZXRzIHRha2UgY29ycmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tldCBBICB0byBi ZSBQYXRoMSAtICggMSwzLDUsNikgbm9kZXMuDQpMZXRzIGFzc3VtZSBpbmNvcnJlY3QgcGF0aCB0 byBiZSBQYWNrZXQgQiBpLmUuIFBhdGgyIC0gICgxLDIsMyw2KS4NCg0KSWYgdGhlIGF0dGFja2Vy IGNvdWxkIHRha2UgdmFsdWVzIGZyb20gUGF0aDEgYW5kIHJlYXR0YWNoIHRoZW0gdG8gUGF0aDIg LCB0aGUgcmVjb25zdHJ1Y3Rpb24gZm9yIFBhY2tldEIgd291bGQgcmVzdWx0IGluICgxLDMsNSw2 KSBpbnN0ZWFkIG9mICgxLDIsMyw2KS4NClRoaXMgY291bGQgYmUgY29tcGFyZWQgd2l0aCB0b3Bv bG9neS9wb2xpY3kgZGIgaW5mb3JtYXRpb24gZm9yIGFueSBwb2xpY3kgdmlvbGF0aW9ucy4gUE9U IGRvZXMgbm90IGVuZm9yY2UgYSBwYXJ0aWN1bGFyIHBhdGggdG8gYmUgdGFrZW4uDQogSXQganVz dCByZWNvbnN0cnVjdHMgdGhlIHBhcnRpY3VsYXIgcGF0aCB0YWtlbiBieSB0aGUgcGFja2V0cy4N Cg0KRG8geW91IG1lYW4gdGhhdCB0aGVyZSBpcyBhIG9uZS1zZWNvbmQtdnVsbmVyYWJpbGl0eSBm b3IgcmVwbGF5IGF0dGFja3M/DQpPbmUgc2Vjb25kIGlzIHByYWN0aWNhbGx5IGZvcmV2ZXIuDQoN CltTRF0gTm90IHJlYWxseSAsIHRoZSB2ZXJpZmllciBjb3VsZCBjYWNoZSB0aGUgUk5ELTIgbnVt YmVycyB1c2VkIGluIHRoZSB0aW1lIHNsaWNlIG9mIG9uZSBzZWNvbmQgYW5kIGZsdXNoIG9mZiBh ZnRlciBldmVyeSBzZWNvbmQuIFRoZXJlIGlzIG5vIG9uZS1zZWNvbmQtdnVsbmVyYWJpbGl0eSBh cyBzdWNoLCBpZiB0aGUgdmVyaWZpZXIgY2FjaGVzIHRob3NlIHZhbHVlcy4NCg0KRWZmZWN0aXZl IHJlcGxheSBwcmV2ZW50aW9uIGlzIHR5cGljYWxseSBwZXJmb3JtZWQgdXNpbmcgYSBzZXF1ZW5j ZSBudW1iZXIsIHdpdGggYSBzbGlkaW5nIHdpbmRvdyB0byBhbGxvdyBvdXQtb2Ytb3JkZXIgcGFj a2V0cy4gV291bGRu4oCZdCBpdCBiZSBwb3NzaWJsZSB0byBpbmNvcnBvcmF0ZSBzdWNoIGEgc2Vx dWVuY2UgbnVtYmVyIGludG8geW91ciBtZWNoYW5pc20/DQoNCltTRF0gVGltZSBzdGFtcCBpcyBl c3NlbnRpYWxseSBhdCBoaWdoIGxldmVsIHNlcXVlbmNlIG51bWJlciAoYXQgc2Vjb25kcyBsZXZl bCkhIFRoZSBjaGFsbGVuZ2Ugd2l0aCB1c2luZyBjb21wbGV0ZSBSTkQtMiBhcyBzZXF1ZW5jZSBu dW1iZXIgaXMgdGhhdCB0aGUgZGlmZmVyZW50aWFsIGFuYWx5c2lzIG9mIENNTCB2YWx1ZXMgKGFj cm9zcyBwYWNrZXRzKSBiZWNvbWVzIHZlcnkgZWFzeSAgYW5kIHByZWRpY3RhYmxlLg0KdGhhdOKA mXMgcmVhc29uIHdlIHJlY29tbWVuZCB1c2luZyAgKCBUaW1lc3RhbXAoLyBzZXF1ZW5jZSBudW1i ZXIpICsgUk5EICkNCg0KDQoNCg0KRnJvbTogU2FzaGFuayBEYXJhIChzYWRhcmEpIFttYWlsdG86 c2FkYXJhQGNpc2NvLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTksIDIwMTYgMToxMSBBTQ0K VG86IFRhbCBNaXpyYWhpOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTsgZHJhZnQtYnJvY2tu ZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWJyb2NrbmVy cy1wcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnPjsgc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRy YW5zaXQgZHJhZnQNCg0KRGVhciBUYWwsDQpUaGFuayB5b3UgZm9yIHlvdXIgaW50ZXJlc3QgaW4g b3VyIHdvcmsuIE1vcmUgaW5saW5lIHdpdGggW1NEXSAuLg0KDQoNClJpZ2h0LCBJIGFtIHJlZmVy cmluZyB0byB0aGUgZm9ybWVyLiBUaGUgaW50ZWdyaXR5IGNoZWNrIGlzIG5vdCB0aGUgaXNzdWUu DQpMZXTigJlzIHNheSB3ZSBoYXZlOg0KLSBQYWNrZXQgQSB0aGF0IHdlbnQgdGhyb3VnaCB0aGUg Y29ycmVjdCBwYXRoIGFuZCBoYXMgYSBjb3JyZWN0IFBPVC4NCi0gUGFja2V0IEIgdGhhdCBkaWQg bm90IGdvIHRocm91Z2ggdGhlIGNvcnJlY3QgcGF0aCBhbmQgZG9lcyBub3QgaGF2ZSBhIGNvcnJl Y3QgUE9ULg0KDQpUaGUgYXR0YWNrZXIgY2FuIOKAmGxhdW5kZXLigJkgcGFja2V0IEIgYnkgcmVw bGFjaW5nIHRoZSAoaW5jb3JyZWN0KSBQT1Qgb2YgcGFja2V0IEIgd2l0aCB0aGUgY29ycmVjdCBQ T1Qgb2YgcGFja2V0IEEgKGFuZCBkcm9wIHBhY2tldCBBKS4NClRodXMsIHBhY2tldCBCIGlzIHZl cmlmaWVkIGNvcnJlY3RseSwgZXZlbiB0aG91Z2ggaXQgZGlkIG5vdCBnbyB0aHJvdWdoIHRoZSBj b3JyZWN0IHBhdGguDQoNCltTRF0gVGhpcyBpcyB2YWxpZCBzY2VuYXJpbyBhbmQgd2UgaGF2ZSBj ZXJ0YWluIGluLWJ1aWx0IG1pdGlnYXRpb24gdGVjaG5pcXVlcyBhbmQgcmVjb21tZW5kYXRpb25z IGZvciB0aGUgc2FtZS4NClRoZXJlIGFyZSB0d28gc2NlbmFyaW9zIGhlcmUNCg0KUGFydGlhbCBS ZXBsYXkgb2YgUE9UIGRhdGEgKFJlcGxheWluZyBpbnRlcm1lZGlhdGUgQ01McykNCg0KQXR0YWNr ZXIgY2Fubm90IHJldXNlIGZldyBpbnRlcm1lZGlhdGUgbm9kZeKAmXMgUE9UIHZhbHVlcyAoZnJv bSBvbGRlciBwYWNrZXQgdHJhY2VzKSBhcyBpdCB3b3VsZCBkaXNydXB0IHRoZSBQT0xZLTMgY29u c3RydWN0aW9uLg0KT24gdGhlIG90aGVyIGhhbmQgaWYgdGhlIGF0dGFja2VyIHRyaWVzIHRvIHJl cGxheSBlbnRpcmUgc2VxdWVuY2Ugb2YgQ01MIHZhbHVlcywgaGUgY2Fubm90IHN0aWxsICwgYmVj YXVzZSBub3RpY2UgdGhhdCB2ZXJpZmllciBhbHNvIGhhcyBhIHNlY3JldCBzaGFyZSBvZiBSTkQt MSBhbmQgcGFydGljaXBhdGVzIGluIHRoZSByZWNvbnN0cnVjdGlvbiBvZiBSTkQtMy4NClZlcmlm aWVy4oCZcyBzaGFyZSBvZiBSTkQtMyBpcyBuZXZlciBvbiB3aXJlICwgc28gYXR0YWNrZXIgY2Fu bm90IGp1c3Qgb2JzZXJ2ZSB0aGUgcGFja2V0IHRyYWNlcyB0byByZXVzZSBhbmQgcmVwbGF5IGl0 Lg0KDQpUb3RhbCBSZXBsYXkgb2YgUE9UIGRhdGEgKFJlcGxheWluZyBjb21wbGV0ZSBSTkQtMikN Cg0KQW5vdGhlciB0cmljaywgYXR0YWNrZXIgY291bGQgZG8gaXMgYnkgY29tcGxldGVseSByZXVz aW5nIFJORC0yIChidXQgbm90IGludGVybWVkaWF0ZSBDTUwgdmFsdWVzKQ0KSW4gb3JkZXIgdG8g cHJldmVudCB0aGUg4oCcUmVwbHkgQXR0YWNrc+KAnSAsIHdlIHJlY29tbWVuZCB0aGF0IHRoZSBS TkQtMiAoZ2VuZXJhdGVkIHBlciBwYWNrZXQpIGJlIGEgY29tYmluYXRpb24gKEkuZS4gUk5EMiA9 IOKAnFRpbWUgU3RhbXAgKyBSTkQgbnVtYmVy4oCdKQ0KU28gaW4gY2FzZSBhIHBhc3NpdmUgYXR0 YWNrZXIgdHJpZXMgdG8gcmVwbGF5IG9uZSBvZiB0aGUgY29ycmVjdCBidXQgb2xkZXIgUk5ELTIs IHRoZSB2ZXJpZmllciBmaXJzdCBjb3VsZCBjaGVjayB0aGUgY3VycmVudCB0aW1lc3RhbXAgYWdh aW5zdCB0aGUgdGltZXN0YW1wIHJldHJpZXZlZCBmcm9tIFJORC0yLg0KSWYgdGhlIHJldHJpZXZl ZCB0aW1lc3RhbXAgaXMgb2xkZXIgdGhhbiBjdXJyZW50IHRpbWVzdGFtcCB3ZSBkcm9wL3JhaXNl IGEgZmxhZyAhDQoNClRoZXJlIGlzIHN0aWxsIGEgc21hbGwgd2luZG93ICwgd2hlcmUgdGhlIGF0 dGFja2VyIGNvdWxkIHJlcGxheSBpdCB3aXRoaW4gdGhlIHZhbGlkIHRpbWUgc2xpY2UgaXRzZWxm IGJ1dCBieSBjYXJlZnVsbHkgY2hvb3NpbmcgdGhlIHRpbWUgc2xpY2Ugd2UgY2FuIG1ha2UgaXQg bmVhcmx5IGltcG9zc2libGUgZm9yIHRoZSBhdHRhY2tlciB0byByZXBsYXkuDQpGb3IgZXhhbXBs ZSAsIGlmIHRoZSBUaW1lIFN0YW1wIGNob3NlbiBpcyAzMiBiaXRzICwgd2UgY291bGQgZ2V0IG9u ZSBzZWNvbmRzIGxldmVsIHByZWNpc2lvbiBpbiB0aGUgdGltZSB3aW5kb3cgLiBTbyBpdCBpcyBo aWdobHkgaW1wb3NzaWJsZSBmb3IgdGhlIGF0dGFja2VyIHRvIHJlcGxheSB3aXRoaW4gc3VjaCBh IHNtYWxsIHRpbWUgYXQgc3VjaCBhIGhpZ2ggcGFja2V0IHJhdGVzLg0KDQpBbHNvICwgdGhlIHZl cmlmaWVyIGNvdWxkIGNhY2hlLCBpZiBuZWVkZWQsIGNlcnRhaW4gbnVtYmVyIG9mIHByZXZpb3Vz bHkgdXNlZCBSTkQtMiB0byBtaXRpZ2F0ZSByZXBsYXkgYXR0YWNrcy4NCg0KSG9wZSB0aGlzIGNs YXJpZmllcy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f 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_F40A6DC030A64CB79DE8C8DAA3258CE3telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <2C19B08C92B5304094995D56CFA9F560@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgRnJhbmssDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGlzIGEgcmVhbGx5 IGludGVyZXN0aW5nIHBpZWNlIG9mIHdvcmssIGFuZCBJIG11c3Qgc2F5IHdlIGhhdmUgYmVlbiBk aXNjdXNzaW5nIHRoZSBQb1QgaXNzdWUgd2l0aCBzb21lIGN1c3RvbWVycyAodGhvdWdoIHdlIHVz ZWQgdG8gY2FsbCBpdCDigJxhc3N1cmVkIHBhdGggdHJhdmVyc2Fs4oCdKSBhbmQgd2UgaGF2ZSBi ZWVuIGV4cGxvcmluZyBwb3NzaWJsZSBzb2x1dGlvbnMsIHRyeWluZyB0byBjb21iaW5lIGdvb2Qt ZW5vdWdoDQogc2VjdXJpdHkgd2l0aCBhIHJlYXNvbmFibGUgYW1vdW50IG9mIGNvbXB1dGF0aW9u YWwgY29tcGxleGl0eSwgYW5kIEkgYW0gZ2xhZCB0byBzZWUgYSBwcmFjdGljYWwgcHJvcG9zYWwg YWRkcmVzc2luZyB0aGlzIHByb2JsZW0uIEkgaGFkIGEgYnJpZWYgY29udmVyc2F0aW9uIHdpdGgg Q2FybG9zIHdoaWxlIGluIEJlcmxpbiwgYnV0IEkgYW0gYWZyYWlkIHRoYXQgdGhlIElFVEYgd2Vl ayB3YXMgdG9vIGhlY3RpYyBmb3IgYSBkZXRhaWxlZCBkaXNjdXNzaW9uLjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TGV0IG1lIGFkZCB0 byBUYWzigJlzIGFuYWx5c2lzIGEgdGhpcmQgaXNzdWUgdG8gY29uc2lkZXIuIE15IHVuZGVyc3Rh bmRpbmcgb2YgU2hhbWly4oCZcyBwb2x5bm9taWFscyBpcyB0aGF0IHRoZXkgY2FuIGJlIHVzZWQg dG8gcmVjb25zdHJ1Y3QgYSBzZWNyZXQgZnJvbSBOIHBpZWNlcyB5b3UgbmVlZCBhIHBvbHlub21p YWwgb2YgZGVncmVlIE4tMSwgc28gdGhhdCBpbXBsaWVzIHRoYXQgdGhlIHZlcmlmaWNhdGlvbiBp cyBsaW1pdGVkDQogdG8gYSBjZXJ0YWluIG51bWJlciBvZiBTRnMgKG9yIFNGRnMpLCBkZXBlbmRp bmcgb24gdGhlIGRlZ3JlZSBvZiB0aGUgYXBwbGllZCBwb2x5bm9taWFsLiBXZeKAmWQgbmVlZCBh bmQgYXNzZXNzbWVudCBvbiB0aGUgY29tcHV0YXRpb25hbCBjb21wbGV4aXR5IGFzc29jaWF0ZWQg d2l0aCBwYXRoIGxlbmd0aCBhbmQgdGhlIHJlcXVpcmVtZW50cyBmb3IgYWRhcHRhdGlvbiBvZiB0 aGUgUG9UIG5vZGVzIChJIGd1ZXNzIFNETi9ORlYgY291bGQgcGxheSBhDQogcm9sZSB0aGVyZeKA pik8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkJlIGdvb2RlLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5PbiAyMCBKdWwgMjAxNiwgYXQgMDk6MTYgLCBGcmFuayBCcm9ja25lcnMg KGZicm9ja25lKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbSIgY2xhc3M9 IiI+ZmJyb2NrbmVAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEx1Y2lk YUdyYW5kZTsgZm9udC1zaXplOiAxMXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkhpIFRhbCw8bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBj bGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPndlbGwuLi4gaWYgeW91IGNvdWxkIHByb3RlY3QgdGhlIGludGVn cml0eSBvZiB0aGUgZGF0YSBzdHJlYW0gYmV0d2VlbiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uLCB5 b3Ugd291bGQgbm90IGJlIGFibGUgdG8gc3dhcCB0aGUgY29udGVudCBvZiBhIHBhY2tldA0KIOKA kyB3aGljaCBpcyB3aGF0IHlvdXIgYXR0YWNrIGlzIGFsbCBhYm91dC4gUmF0aGVyIHRoYW4gY29u dGludWUgYXJndWluZyB0aGUgcG9pbnQsIGxldOKAmXMgYWNrbm93bGVkZ2UgdGhhdCBpdCBpcyBh IHZhbGlkIGF0dGFjayBhbmQgbGV04oCZcyBsb29rIGZvciBhIHNvbHV0aW9uIDotKS4gV2XigJls bCBuZWVkIHRvIGNvdXBsZSBQT1QgdG8gaW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgdGhlIHBhY2tl dC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5IZW5jZSwgSeKAmWQgbGlrZSB0 byBjb21lIGJhY2sgdG8gbXkgcXVlc3Rpb24gYXNrZWQgYmVsb3c6ICZuYnNwOzxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IiBjbGFzcz0iIj5EbyB5b3UgKGFuZCB0aGUgZW50aXJlIFNGQyB0ZWFtIGhlcmUpIHRoaW5r IGl0IGlzIHdvcnRod2hpbGUgdG8gcHJvdmlkZSBhIHNvbHV0aW9uIGZvciBhIGRlcGxveW1lbnQg d2hpY2ggaXMgZXhwZWN0ZWQgdG8gKjxiIGNsYXNzPSIiPm5vdDwvYj4qIGFsdGVyDQogdGhlIHBh Y2tldCBwYXlsb2FkPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlRoYW5rcywg RnJhbms8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3Jk ZXItdG9wLWNvbG9yOiByZ2IoMjI1LCAyMjUsIDIyNSk7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsg cGFkZGluZzogM3B0IDBjbSAwY207IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRhbCBNaXpy YWhpDQogWzxhIGhyZWY9Im1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbSIgc3R5bGU9ImNvbG9yOiBw dXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bWFpbHRvOnRhbG1p QG1hcnZlbGwuY29tPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRpZW5zdGFnLCAxOS4gSnVsaSAy MDE2IDE4OjE1PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GcmFuayBCcm9ja25lcnMgKGZicm9j a25lKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9y OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ZmJyb2NrbmVA Y2lzY28uY29tPC9hPiZndDs7IFNhc2hhbmsgRGFyYSAoc2FkYXJhKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNhZGFyYUBjaXNjby5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNhZGFyYUBjaXNjby5jb208L2E+Jmd0Ozs8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OmRyYWZ0LWJyb2NrbmVycy1wcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnIiBzdHlsZT0i Y29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5kcmFm dC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzwvYT48YnIgY2xhc3M9 IiI+DQo8YiBjbGFzcz0iIj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHN0eWxlPSJjb2xv cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNmY0BpZXRm Lm9yZzwvYT47PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm9wc2F3Z0BpZXRmLm9yZzwvYT47 PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpudm8zQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0 aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5udm8zQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5SRTogUXVlc3Rpb24gcmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQg ZHJhZnQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+SGkgRnJhbmssPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+VGhlIFBPVCByZXBsYWNlbWVudCBhdHRhY2sgKDEuKSBpcyBub3QgYW4gYXR0YWNrIG9uIHRo ZSBpbnRlZ3JpdHkuIEl0IGlzIGFuIGF0dGFjayBvbiB0aGUgcGF0aCB2ZXJpZmljYXRpb24uPG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiIGNsYXNzPSIiPlRoaXMgc2ltcGxlIGF0dGFjayBjYW4gY2F1c2UgdGhlIHZl cmlmaWVyIHRvIGFjY2VwdCBhIHBhY2tldCB0aGF0IGRpZCBub3QgZ28gdGhyb3VnaCB0aGUgZmly ZXdhbGwgU0YgKGV2ZW4gdGhvdWdoIGl0IHNob3VsZCkuIEkgYmVsaWV2ZSB0aGlzIGlzIGV4YWN0 bHkNCiB0aGUgcHJvYmxlbSB5b3Ugd2VyZSBhaW1pbmcgdG8gYWRkcmVzcyBpbiB0aGlzIGRyYWZ0 LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlRoYW5rcyw8bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyIgY2xhc3M9IiI+VGFsLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3Jk ZXItbGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAw Y20gMGNtIDBjbSA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJi b3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwg MTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNwdCAwY20gMGNtOyIg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPGIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJhbmsgQnJvY2tuZXJzDQogKGZicm9ja25lKSBbPGEg aHJlZj0ibWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bWFpbHRvOmZicm9ja25lQGNpc2Nv LmNvbTwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDY6MDAg UE08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRhbCBNaXpyYWhpOyBTYXNoYW5rIERhcmEgKHNh ZGFyYSk7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRm Lm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFz cz0iIj5zZmNAaWV0Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYub3JnIiBzdHlsZT0iY29s b3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5vcHNhd2dA aWV0Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bnZvM0BpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IFF1ZXN0aW9uIHJlZ2FyZGluZyBQcm9v ZiBvZiBUcmFuc2l0IGRyYWZ0PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+SGkgVGFsLDxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+dGhhbmtzIGZvciB0aGUgc3VtbWFyeS4gV2XigJlsbCBwcm92aWRlIG1vcmUgZGV0YWlscyBv biAyLiBQZXIgbXkgZWFybGllciBwb2ludCDigJMgMS4gaXMgYW4gaW50ZXJlc3RpbmcgZGlzY3Vz c2lvbiwgZ2l2ZW4gdGhhdCB3ZSBkb27igJl0IGNsYWltIHRvIHByb3ZpZGUNCiBpbnRlZ3JpdHkg cHJvdGVjdGlvbiBmb3IgdGhlIHBhY2tldCBwYXlsb2FkLiBPciBpbiBvdGhlciB0ZXJtcyDigJMg dG8gYmUgZXhhY3Q6IFdoYXQgUE9UIHByb3ZpZGVzIGlzIGEgcHJvb2YgdGhhdCB0aGUgUE9ULWhl YWRlci9tZXRhLWRhdGEgdHJhbnNpdGVkIGFsbCB0aGUgcmVxdWlyZWQgbm9kZXMuIFRoZXJlIGlz IG5vIGFzc29jaWF0aW9uIChhbmQgdGh1cyBwcm9vZikgcHJvdmlkZWQgZm9yIHRoZSBhZGRpdGlv bmFsIGRhdGEgY2FycmllZCBhbG9uZw0KIHdpdGggdGhlIFBPVC1oZWFkZXIg4oCTIG5laXRoZXIg aGVhZGVyIG5vciBwYXlsb2FkLiBBcyBhIGNvbnNlcXVlbmNlLCBhdHRhY2tzIHdoaWNoIGNoYW5n ZSB0aGUgcGFja2V0IHBheWxvYWQgd29u4oCZdCBiZSBkZXRlY3RlZC9taXRpZ2F0ZWQuIFdl4oCZ bGwgZXhwbGljaXRseSBzdGF0ZSB0aGlzIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBp biB0aGUgbmV4dCByZXYgb2YgdGhlIGRvY3VtZW50LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5X aGF0IHdlIGNvdWxkIGNvbnNpZGVyIGlzIGxpbmtpbmcgdGhlIFJORCBudW1iZXIgdG8gQ1JDIGFj cm9zcyB0aGUgcGFja2V0IHBheWxvYWQgb3Igc2ltaWxhciDigJMgYnV0IHRoYXQgd2F5IHdl4oCZ ZCByZXN0cmljdCB0aGUgYXBwbGljYWJpbGl0eSB0byBkZXBsb3ltZW50cw0KIHdoZXJlIHRoZSBw YWNrZXQgcGF5bG9hZCBpc27igJl0IGNoYW5nZWQgYWNyb3NzIHRoZSBwYXRoICh3aGljaCBtaWdo dCBub3QgYXBwbHkgdG8gY2VydGFpbiBkZXBsb3ltZW50IOKAkyBlLmcuIFdBTiBvcHRpbWl6YXRp b24gLyBjb21wcmVzc2lvbiBzY2hlbWVzKS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+RG8geW91 IHRoaW5rIGl0IGlzIHdvcnRod2hpbGUgdG8gcHJvdmlkZSBhIHNvbHV0aW9uIGZvciBhIGRlcGxv eW1lbnQgd2hpY2ggaXMgZXhwZWN0ZWQgdG8gbm90IGFsdGVyIHRoZSBwYWNrZXQgcGF5bG9hZD88 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5UaGFua3MsPG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi IGNsYXNzPSIiPkZyYW5rPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUg bm9uZTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBib3JkZXItdG9wLXdp ZHRoOiAxcHQ7IHBhZGRpbmc6IDNwdCAwY20gMGNtOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5UYWwgTWl6cmFoaQ0KIFs8YSBocmVmPSJtYWlsdG86dGFsbWlAbWFydmVsbC5jb20iIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1h aWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbTwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5EaWVuc3RhZywg MTkuIEp1bGkgMjAxNiAxNzo0NDxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U2FzaGFuayBEYXJh IChzYWRhcmEpICZsdDs8YSBocmVmPSJtYWlsdG86c2FkYXJhQGNpc2NvLmNvbSIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+c2FkYXJh QGNpc2NvLmNvbTwvYT4mZ3Q7OyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ZmJyb2NrbmVAY2lzY28uY29tPC9hPiZn dDs7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9y ZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5zZmNAaWV0Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYub3JnIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5vcHNhd2dAaWV0 Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bnZvM0BpZXRmLm9yZzwvYT48YnIg Y2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IFF1ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBv ZiBUcmFuc2l0IGRyYWZ0PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkhpLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJz cDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPlRvIHN1bW1hcml6ZSBteSB0YWtlIG9uIHRoaXMgdGhyZWFkOjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IiBjbGFzcz0iIj5UaGUgcHJvcG9zZWQgbWVjaGFuaXNtIGhhcyB0d28gc2lnbmlmaWNhbnQgdnVs bmVyYWJpbGl0aWVzIHRoYXQgKGluIG15IHVuZGVyc3RhbmRpbmcpIGFyZSBjdXJyZW50bHkgbm90 IGFkZHJlc3NlZDo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdCAzNnB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IHRleHQtaW5kZW50OiAtMThwdDsiIGNsYXNz PSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNz PSIiPjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiA3cHQ7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+QQ0KIG1hbi1pbi10aGUtbWlkZGxlIGNhbiByZXBsYWNlIHRoZSBQT1Qgb2YgcGFj a2V0IEEgd2l0aCB0aGUgUE9UIG9mIHBhY2tldCBCLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0IDM2cHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgdGV4dC1p bmRlbnQ6IC0xOHB0OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Mi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDdwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5JdA0KIGlzIHBvc3NpYmxlIHRvIHJlcGxheSBQ T1RzIHdpdGhpbiBhIGNlcnRhaW4gdGltZSB3aW5kb3csIHdob3NlIGxlbmd0aCBpcyBkZXRlcm1p bmVkIGJ5IHRoZSB0aW1lc3RhbXAgcmVzb2x1dGlvbi48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IiBjbGFzcz0iIj5TYXNoYW5rLCB0aGFua3MgZm9yIGFncmVlaW5nIHRvIGxvb2sgaW50byBpdCBm dXJ0aGVyLiBJIGFtIGxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIGluc2lnaHRzIG9uIHRoaXMuPG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+UmVnYXJkcyw8bzpwIGNsYXNzPSIiPjwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+VGFsLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkxpbmsgdG8g dGhlIGRyYWZ0OjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJzLXBy b29mLW9mLXRyYW5zaXQtMDEiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i cm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdC0wMTwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6 IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxl ZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwY20gMGNtIDBjbSA0cHQ7IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsg Ym9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAx cHQ7IHBhZGRpbmc6IDNwdCAwY20gMGNtOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9iPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNhc2hh bmsgRGFyYQ0KIChzYWRhcmEpIFs8YSBocmVmPSJtYWlsdG86c2FkYXJhQGNpc2NvLmNvbSIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ bWFpbHRvOnNhZGFyYUBjaXNjby5jb208L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TZW50OjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwg SnVseSAxOSwgMjAxNiAxMjoyMCBQTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGFsIE1penJh aGk7IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtYnJvY2tuZXJzLXBy b29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmRyYWZ0LWJyb2NrbmVycy1wcm9vZi1v Zi10cmFuc2l0QHRvb2xzLmlldGYub3JnPC9hPjs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgc3R5bGU9 ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+c2Zj QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogUXVlc3Rpb24g cmVnYXJkaW5nIFByb29mIG9mIFRyYW5zaXQgZHJhZnQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB3aWRvd3M6IGF1dG87IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC1zcGFjaW5nOiAwcHg7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0i Ij5JIHdhbnQgdG8gYXNrIGEgc2ltcGxlIHF1ZXN0aW9uOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHdpZG93czogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB3b3JkLXNwYWNpbmc6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPklmIHRoZSBhdHRhY2tlciBhdHRhY2hlcyB0 aGUgUE9UIG9mIHBhY2tldCBBIChpbmRpY2F0aW5nIHRoZSBwYXRoIHRocm91Z2ggMSwzLDUsNikg dG8gcGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2VwdCBwYWNrZXQgQiBhbmQgYmVsaWV2 ZSB0aGF0DQogaXRzIHBhdGggd2FzIGluZGVlZCAoMSwzLDUsNik/PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPltTRF0gSWYgdGhlIHZlcmlmaWVyIGlzIHByb2dyYW1tZWQgdG8ganVz dCB2YWxpZGF0ZSB0aGUgUE9UIG1ldGEgZGF0YSBhZ2FpbnN0IHsxLDMsNSw2fSB0aGVuIHllcyBp dCBhY2NlcHRzIGl0LiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+SWYgdGhlIHZlcmlmaWVyIGlzIHByb2dyYW1tZWQgdG8gY29u c3VsdCBhIHBvbGljeSBkYXRhYmFzZSB0byBjcm9zcyBjaGVjayBpZiB0aGUgcmVjb25zdHJ1Y3Rl ZCBwYXRoIHsxLDMsNSw2fSBpcyBhcyBwZXIgdGhlIHBvbGljaWVzIHRoZW4gbm8gLCBpdCBkcm9w cyBpdCAuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij5CdXQgSSBzZWUgeW91ciBwb2ludCAsIHRoYXQgdGhlIHBhcmFtZXRlcnMgdXNlZCBpbiBQT1Qg ZGF0YSBkb25vdCBjb25zaWRlciB0aGUgcGF0aCBvciBub2RlLWlkcyBldGMgLiBXZSBzaGFsbCBk aXNjdXNzIHRoaXMgaW50ZXJuYWxseSBhbmQgZ2V0IGJhY2suPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5BbHNvLCBXZSBzaGFsbCBnZXQgYmFjayB3aXRoIG1v cmUgY29uY3JldGUgbnVtYmVycyBvZiB0aGUgdGltZXN0YW1wIHJlc29sdXRpb24gYW5kIGNhY2hl IHNpemVzIChvciBvdGhlciBiZXR0ZXIgYXBwcm9hY2hlcykuJm5ic3A7PG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5UaGFuayB5b3Ugc28gbXVjaCBmb3IgYWxs IHRoZSBpbnB1dHMuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBU YWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9iPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvYj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0i Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IFRhaG9tYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2I+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+VGFsIE1penJhaGk8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEp1bHkg MTksIDIwMTYgMTA6MjggQU08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPidTYXNoYW5rIERhcmEg KHNhZGFyYSknOyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTs8c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWJyb2Nr bmVycy1wcm9vZi1vZi10cmFuc2l0QHRvb2xzLmlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5kcmFmdC1icm9ja25lcnMt cHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZzwvYT47PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci IHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNz PSIiPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0Ojwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IFF1 ZXN0aW9uIHJlZ2FyZGluZyBQcm9vZiBvZiBUcmFuc2l0IGRyYWZ0PG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj4mbmJz cDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPkRlYXIgU2FzaGFuayw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5J IHJlYWxseSBhcHByZWNpYXRlIHRoZSBxdWljayBhbmQgZGV0YWlsZWQgcmVzcG9uc2VzLjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4mZ3Q7Jmd0OyZndDtMZXRzIHRha2UgY29ycmVjdCBwYXRoIHRha2VuIGJ5IFBhY2tl dCBBICZuYnNwO3RvIGJlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxiIGNsYXNzPSIiPlBhdGgxPC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj4tICggMSwzLDUsNikNCiBub2Rlcy4mbmJzcDs8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyZndDtMZXRzIGFzc3VtZSBpbmNvcnJlY3QgcGF0aCB0byBiZSBQYWNrZXQg QiBpLmUuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi IGNsYXNzPSIiPlBhdGgyPC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj4tICZuYnNwOygxLDIsMyw2KS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsm bmJzcDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDtJZiB0aGUgYXR0YWNrZXIgY291bGQgdGFr ZSB2YWx1ZXMgZnJvbTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YiBjbGFzcz0iIj5QYXRoMTwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+YW5kIHJlYXR0YWNoIHRoZW0gdG8mbmJzcDs8YiBjbGFzcz0iIj5Q YXRoMiAsPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi ciBjbGFzcz0iIj4NCjwvYj4mZ3Q7Jmd0OyZndDt0aGUmbmJzcDtyZWNvbnN0cnVjdGlvbiBmb3Ig UGFja2V0QiB3b3VsZCByZXN1bHQgaW4gKDEsMyw1LDYpIGluc3RlYWQgb2YgKDEsMiwzLDYpLiZu YnNwOzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0O1RoaXMgY291bGQgYmUgY29tcGFyZWQgd2l0 aCB0b3BvbG9neS9wb2xpY3kgZGIgaW5mb3JtYXRpb24gZm9yIGFueSBwb2xpY3k8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsmZ3Q7dmlvbGF0aW9ucy4gUE9UIGRvZXMgbm90IGVuZm9yY2UgYSBwYXJ0aWN1bGFyIHBh dGggdG8gYmUgdGFrZW4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0i Ij48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jmd0OyZndDtTbyBwYWNrZXQgQiBza2lwcGVkIG5v ZGUgNSAoZS5nLiB0aGUgZmlyZXdhbGwgU0YpLCBidXQgdGhlIHZlcmlmaWVyIGJlbGlldmVzIGl0 IHdlbnQgdGhyb3VnaCB0aGUgY29ycmVjdCBwYXRoLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mZ3Q7Jmd0O1dvdWxkIHlvdSBh Z3JlZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jmd0O1tT RF0gVGhlIHZlcmlmaWVyIG9ubHkgY29uc3RydWN0cyB0aGUgcGF0aCB0aGUgcGFja2V0IHRvb2sg YWNjdXJhdGVseSwgaXQgaXMgdXB0bzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jmd0O3RoZSBhcHBsaWNhdGlvbiB0byBkZXRlcm1pbmUg d2hldGhlciBpdCB2aW9sYXRlcyBhbnkgcG9saWNpZXMgKEkuZSBtaXNzaW5nIGFueSBmdW5jdGlv bikmbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPiZndDtUaGUgYm90dG9tIGxpbmUgaXMgLCBhbiBhdHRhY2tlciB0YWtpbmcgYSBk aWZmZXJlbnQgcGF0aCBjYW5ub3QgZ2V0IGF3YXkgd2l0aCBpdCAhPG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mZ3Q7VGhlIHdob2xlIGlu dGVudCBvZiDigJxwcm9vZi1vZi10cmFuc2l04oCdIGlzIHRvIHByb3ZlIHRoZSBwYXRoIHBhY2tl dCBoYXMgdGFrZW4gZXhhY3RseS4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZndDtQT1QgZG9lcyBub3QgZGVmaW5lIHdoZXRo ZXIgaXQgZ29vZC9iYWQgcGF0aC4gSXQgaXMgdXB0byBoaWdoIGxldmVsIGFwcGxpY2F0aW9ucyBv biB3aGF0PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4mZ3Q7ZG8gd2l0aCDigJxyZWNvbnN0cnVjdGVk4oCdIHBhdGguJm5ic3A7PG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkkgd2Fu dCB0byBhc2sgYSBzaW1wbGUgcXVlc3Rpb246PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPklmIHRo ZSBhdHRhY2tlciBhdHRhY2hlcyB0aGUgUE9UIG9mIHBhY2tldCBBIChpbmRpY2F0aW5nIHRoZSBw YXRoIHRocm91Z2ggMSwzLDUsNikgdG8gcGFja2V0IEIsIHdpbGwgdGhlIHZlcmlmaWVyIGFjY2Vw dCBwYWNrZXQgQiBhbmQgYmVsaWV2ZSB0aGF0DQogaXRzIHBhdGggd2FzIGluZGVlZCAoMSwzLDUs Nik/PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jmd0OyZndDtIbW1t4oCm IExldOKAmXMgc2F5IHdlIGFyZSB0YWxraW5nIGFib3V0IHRyYWZmaWMgYXQgMTAgR2Jwcywgd2hp Y2ggaXMgcm91Z2hseTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzEgbWlsbGlvbiBwYWNrZXRzIHBlciBzZWNvbmQu IFRoYXQgd291bGQgbWVhbiB0aGUgdmVyaWZpZXIgaGFzIHRvIHN0b3JlIGEgbWlsbGlvbiB2YWx1 ZXMgb2YgUk5ELTIuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtNb3Jlb3ZlciwgZXZlcnkgdGltZSBh IHBhY2tldCBhcnJpdmVzLCB0aGUgdmVyaWZpZXIgd291bGQgaGF2ZSB0byBjb21wYXJlIGl0czxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0O1JORC0yIHZhbHVlIHdpdGggdGhlIDEgbWlsbGlvbiBzdG9yZWQgdmFsdWVz LCBpbiBvcmRlciB0byB2ZXJpZnkgdGhlcmUgaXMgbm8gcmVwbGF5LjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7VGhhdCBkb2VzIG5vdCBzb3VuZCBmZWFzaWJsZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 O0FtIEkgbWlzc2luZyBzb21ldGhpbmcgaGVyZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4mZ3Q7W1NEXSZuYnNwO1NlY29uZCBsZXZlbCBwcmVjaXNpb24gaXMg b25seSBhbiBleGFtcGxlLCB3ZSBjb3VsZCB1c2UgYXMgbXVjaCBwcmVjaXNpb24gYXMgd2Ugd2Fu dCB0byByZWR1Y2UgdGhlIG51bWJlciBvZiB2YWx1ZXMgdG8gYmUgY2FjaGVkICE8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNz PSIiPk15IHBvaW50IGlzIHRoYXQgYXNzdW1pbmcgcmVhc29uYWJsZSByZXNvdXJjZXMgYXJlIHVz ZWQsIHRoZSBtZWNoYW5pc20gaXMgdnVsbmVyYWJsZSB0byBhIHJlcGxheSBhdHRhY2suPG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPkluIG9yZGVyIHRvIHByb3ZlIG1lIHdyb25nLCBjYW4geW91IHBy ZXNlbnQgY29uY3JldGUgbnVtYmVycyBvZiB0aGUgdGltZXN0YW1wIHJlc29sdXRpb24gYW5kIHRo ZSBjYWNoZSBzaXplPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5PdGhlcndpc2UsIHlvdSBtYXkg Y29uc2lkZXIgdXNpbmcgYSBzZXF1ZW5jZSBudW1iZXIgJiM0Mzsgc2xpZGluZyB3aW5kb3cgKGUu Zy4sIGFzIGluIElQc2VjKS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJz cDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPlRoYW5rcyw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+VGFsLjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQt Y29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgcGFkZGluZzogMGNtIDBjbSAw Y20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0 eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6IHJnYigxODEsIDE5NiwgMjIz KTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGNtIDBjbTsiIGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21h LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlNhc2hhbmsgRGFyYQ0KIChzYWRhcmEpIFs8YSBocmVmPSJtYWlsdG86 c2FkYXJhQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyIgY2xhc3M9IiI+bWFpbHRvOnNhZGFyYUBjaXNjby5jb208L2E+XTxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+VHVlc2RheSwgSnVseSAxOSwgMjAxNiA5OjU2IEFNPGJyIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5UYWwgTWl6cmFoaTsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSk7PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZyIgc3R5bGU9 ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ZHJh ZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8L2E+OzxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFmdDxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jmd0O1tTRF0gT2suIFRoaXMgaXMg YW4gaW50ZXJlc3RpbmcgYXR0YWNrLiAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+Jmd0OyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4mZ3Q7TGV0cyB0YWtlIGNvcnJlY3QgcGF0aCB0YWtlbiBieSBQYWNr ZXQgQSAmbmJzcDt0byBiZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YiBjbGFzcz0iIj5QYXRoMTwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+LSAoIDEsMyw1LDYpDQogbm9kZXMuJm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZndDtMZXRzIGFzc3VtZSBpbmNv cnJlY3QgcGF0aCB0byBiZSBQYWNrZXQgQiBpLmUuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPlBhdGgyPC9iPjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4tICZuYnNwOygxLDIsMyw2KS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jmd0OyZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mZ3Q7SWYgdGhlIGF0dGFj a2VyIGNvdWxkIHRha2UgdmFsdWVzIGZyb208c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+UGF0aDE8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFuZCByZWF0dGFjaCB0aGVtIHRvJm5ic3A7 PGIgY2xhc3M9IiI+UGF0aDINCiAsPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNz PSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+Jmd0O3RoZSZuYnNwO3JlY29uc3RydWN0aW9uIGZvciBQYWNrZXRCIHdvdWxkIHJlc3Vs dCBpbiAoMSwzLDUsNikgaW5zdGVhZCBvZiAoMSwyLDMsNikuJm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZndDtUaGlzIGNvdWxkIGJlIGNvbXBhcmVk IHdpdGggdG9wb2xvZ3kvcG9saWN5IGRiIGluZm9ybWF0aW9uIGZvciBhbnkgcG9saWN5PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZndDt2aW9sYXRpb25zLiBQ T1QgZG9lcyBub3QgZW5mb3JjZSBhIHBhcnRpY3VsYXIgcGF0aCB0byBiZSB0YWtlbi48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFz cz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5TbyBwYWNrZXQgQiBza2lwcGVkIG5vZGUgNSAoZS5nLiB0 aGUgZmlyZXdhbGwgU0YpLCBidXQgdGhlIHZlcmlmaWVyIGJlbGlldmVzIGl0IHdlbnQgdGhyb3Vn aCB0aGUgY29ycmVjdCBwYXRoLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xh c3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPldvdWxkIHlvdSBhZ3JlZT88L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0i Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPltTRF0gVGhlIHZlcmlmaWVyIG9u bHkgY29uc3RydWN0cyB0aGUgcGF0aCB0aGUgcGFja2V0IHRvb2sgYWNjdXJhdGVseSwgaXQgaXMg dXB0byB0aGUgYXBwbGljYXRpb24gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQgdmlvbGF0ZXMgYW55 IHBvbGljaWVzIChJLmUgbWlzc2luZyBhbnkgZnVuY3Rpb24pJm5ic3A7PG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj5UaGUgYm90dG9tIGxpbmUgaXMgLCBhbiBhdHRhY2tlciB0YWtpbmcgYSBkaWZm ZXJlbnQgcGF0aCBjYW5ub3QgZ2V0IGF3YXkgd2l0aCBpdCAhIFRoZSB3aG9sZSBpbnRlbnQgb2Yg 4oCccHJvb2Ytb2YtdHJhbnNpdOKAnSBpcyB0byBwcm92ZSB0aGUgcGF0aCBwYWNrZXQgaGFzIHRh a2VuIGV4YWN0bHkuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5QT1QgZG9lcyBub3Qg ZGVmaW5lIHdoZXRoZXIgaXQgZ29vZC9iYWQgcGF0aC4gSXQgaXMgdXB0byBoaWdoIGxldmVsIGFw cGxpY2F0aW9ucyBvbiB3aGF0IGRvIHdpdGgg4oCccmVjb25zdHJ1Y3RlZOKAnSBwYXRoLiZuYnNw OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyIgY2xhc3M9IiI+PG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiIGNsYXNzPSIiPkhtbW3igKYgTGV04oCZcyBzYXkgd2UgYXJlIHRhbGtpbmcgYWJvdXQg dHJhZmZpYyBhdCAxMCBHYnBzLCB3aGljaCBpcyByb3VnaGx5IDEgbWlsbGlvbiBwYWNrZXRzIHBl ciBzZWNvbmQuIFRoYXQgd291bGQgbWVhbiB0aGUgdmVyaWZpZXIgaGFzIHRvIHN0b3JlDQogYSBt aWxsaW9uIHZhbHVlcyBvZiBSTkQtMi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5Nb3Jl b3ZlciwgZXZlcnkgdGltZSBhIHBhY2tldCBhcnJpdmVzLCB0aGUgdmVyaWZpZXIgd291bGQgaGF2 ZSB0byBjb21wYXJlIGl0cyBSTkQtMiB2YWx1ZSB3aXRoIHRoZSAxIG1pbGxpb24gc3RvcmVkIHZh bHVlcywgaW4gb3JkZXIgdG8gdmVyaWZ5IHRoZXJlDQogaXMgbm8gcmVwbGF5Ljwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPlRoYXQgZG9lcyBub3Qgc291bmQgZmVhc2libGUuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IiBjbGFzcz0iIj48bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyIgY2xhc3M9IiI+QW0gSSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlPzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyIgY2xhc3M9IiI+PG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPltTRF0mbmJzcDtTZWNvbmQgbGV2ZWwgcHJlY2lzaW9uIGlzIG9ubHkg YW4gZXhhbXBsZSwgd2UgY291bGQgdXNlIGFzIG11Y2ggcHJlY2lzaW9uIGFzIHdlIHdhbnQgdG8g cmVkdWNlIHRoZSBudW1iZXIgb2YgdmFsdWVzIHRvIGJlIGNhY2hlZCAhPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj5TYXNoYW5rJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNz PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUg bm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRoOiAx LjVwdDsgcGFkZGluZzogMGNtIDBjbSAwY20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3At Y29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5n OiAzcHQgMGNtIDBjbTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNhc2hhbmsgRGFyYQ0KIChz YWRhcmEpIFs8YSBocmVmPSJtYWlsdG86c2FkYXJhQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBw dXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bWFpbHRvOnNhZGFy YUBjaXNjby5jb208L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgSnVseSAxOSwgMjAx NiA4OjMzIEFNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UYWwgTWl6cmFoaTsgRnJhbmsgQnJv Y2tuZXJzIChmYnJvY2tuZSk7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNp dEB0b29scy5pZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyIgY2xhc3M9IiI+ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9v bHMuaWV0Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJv b2Ygb2YgVHJhbnNpdCBkcmFmdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xh c3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPklubGluZSAuLiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBj bGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IiBjbGFzcz0iIj5XZSBoYXZlIHR3byBjb25zZWN1dGl2ZSBwYWNrZXRzLCBBIGFuZCBC Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiIGNsYXNzPSIiPi0gUGFja2V0IEEgdGhhdCB3ZW50IHRocm91Z2ggdGhlIGNvcnJlY3QgcGF0 aCBhbmQgaGFzIGEgY29ycmVjdCBQT1QuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgd2lkb3dzOiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtc3Bh Y2luZzogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyIgY2xhc3M9IiI+LSBQYWNrZXQgQiB0aGF0IGRpZCBub3QgZ28gdGhyb3VnaCB0 aGUgY29ycmVjdCBwYXRoIGFuZCBkb2VzIG5vdCBoYXZlIGEgY29ycmVjdCBQT1QuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgd2lkb3dzOiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHdvcmQtc3BhY2luZzogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7Tm93IHRo ZSBhdHRhY2tlciBwZXJmb3JtcyBhIOKAmG1peCBhbmQgbWF0Y2jigJkgYXR0YWNrLCBieSB0YWtp bmcgdGhlIGNvcnJlY3QgUE9UIGZyb20gcGFja2V0IEEgYW5kIGF0dGFjaGluZyBpdCB0byBwYWNr ZXQgQi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IiBjbGFzcz0iIj5UaGUgYXR0YWNrZXIgYWxzbyB0ZXJtaW5hdGVzIHBhY2tldCBBLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi IGNsYXNzPSIiPlRoZXJlIGlzIG5vIHJlcGxheSBoZXJlLCBiZWNhdXNlIHRoZSB2ZXJpZmllciBy ZWNlaXZlcyB0aGUgY29ycmVjdCBQT1Qgb25seSBvbmNlLiBUaGUgcHJvYmxlbSBpcyB0aGF0IHRo ZSBjb3JyZWN0IFBPVCBoYXBwZW5zIHRvIGFycml2ZSB3aXRoIHBhY2tldA0KIEIuPHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IFdpbmdkaW5nczsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5MPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+VGh1cywgcGFj a2V0IEIgYXBwZWFycyBva2F5IHRvIHRoZSB2ZXJpZmllciwgZXZlbiB0aG91Z2ggaXQgZGlkIG5v dCBnbyB0aHJvdWdoIHRoZSBjb3JyZWN0IHBhdGguPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+SXMgdGhlcmUgYSB3YXkgdG8gbWl0aWdhdGUgdGhpcyBhdHRhY2s/PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+W1NEXSBPay4gVGhpcyBpcyBhbiBpbnRl cmVzdGluZyBhdHRhY2suICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIg Y2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+TGV0 cyB0YWtlIGNvcnJlY3QgcGF0aCB0YWtlbiBieSBQYWNrZXQgQSAmbmJzcDt0byBiZTxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5QYXRo MTwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+LSAo IDEsMyw1LDYpDQogbm9kZXMuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkxldHMgYXNzdW1lIGluY29ycmVj dCBwYXRoIHRvIGJlIFBhY2tldCBCIGkuZS48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+UGF0aDI8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPi0gJm5ic3A7KDEsMiwzLDYpLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+SWYgdGhlIGF0dGFja2VyIGNvdWxkIHRha2UgdmFsdWVz IGZyb208c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIg Y2xhc3M9IiI+UGF0aDE8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPmFuZCByZWF0dGFjaCB0aGVtIHRvJm5ic3A7PGIgY2xhc3M9IiI+UGF0aDINCiAs PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj50aGUm bmJzcDtyZWNvbnN0cnVjdGlvbiBmb3IgUGFja2V0QiB3b3VsZCByZXN1bHQgaW4gKDEsMyw1LDYp IGluc3RlYWQgb2YgKDEsMiwzLDYpLiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5UaGlzIGNvdWxkIGJlIGNv bXBhcmVkIHdpdGggdG9wb2xvZ3kvcG9saWN5IGRiIGluZm9ybWF0aW9uIGZvciBhbnkgcG9saWN5 IHZpb2xhdGlvbnMuIFBPVCBkb2VzIG5vdCBlbmZvcmNlIGEgcGFydGljdWxhciBwYXRoIHRvIGJl IHRha2VuLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDtJdCBqdXN0IHJlY29uc3RydWN0cyB0aGUgcGFydGlj dWxhciBwYXRoIHRha2VuIGJ5IHRoZSBwYWNrZXRzLiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi IGNsYXNzPSIiPkRvIHlvdSBtZWFuIHRoYXQgdGhlcmUgaXMgYSBvbmUtc2Vjb25kLXZ1bG5lcmFi aWxpdHkgZm9yIHJlcGxheSBhdHRhY2tzPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPk9uZSBzZWNvbmQgaXMgcHJhY3Rp Y2FsbHkgZm9yZXZlci48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIi PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj5bU0RdIE5vdCByZWFsbHkgLCB0aGUgdmVyaWZpZXIgY291bGQgY2FjaGUgdGhlIFJORC0y IG51bWJlcnMgdXNlZCBpbiB0aGUgdGltZSBzbGljZSBvZiBvbmUgc2Vjb25kIGFuZCBmbHVzaCBv ZmYgYWZ0ZXIgZXZlcnkgc2Vjb25kLiBUaGVyZSBpcyBubyBvbmUtc2Vjb25kLXZ1bG5lcmFiaWxp dHkNCiBhcyBzdWNoLCBpZiB0aGUgdmVyaWZpZXIgY2FjaGVzIHRob3NlIHZhbHVlcy4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFz cz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5FZmZlY3RpdmUgcmVwbGF5IHByZXZlbnRpb24g aXMgdHlwaWNhbGx5IHBlcmZvcm1lZCB1c2luZyBhIHNlcXVlbmNlIG51bWJlciwgd2l0aCBhIHNs aWRpbmcgd2luZG93IHRvIGFsbG93IG91dC1vZi1vcmRlciBwYWNrZXRzLiBXb3VsZG7igJl0IGl0 IGJlIHBvc3NpYmxlDQogdG8gaW5jb3Jwb3JhdGUgc3VjaCBhIHNlcXVlbmNlIG51bWJlciBpbnRv IHlvdXIgbWVjaGFuaXNtPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9 IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+W1NEXSBUaW1lIHN0YW1wIGlzIGVzc2VudGlhbGx5IGF0IGhpZ2ggbGV2ZWwgc2VxdWVu Y2UgbnVtYmVyIChhdCBzZWNvbmRzIGxldmVsKSEgVGhlIGNoYWxsZW5nZSB3aXRoIHVzaW5nIGNv bXBsZXRlIFJORC0yIGFzIHNlcXVlbmNlIG51bWJlciBpcyB0aGF0IHRoZSBkaWZmZXJlbnRpYWwg YW5hbHlzaXMNCiBvZiBDTUwgdmFsdWVzIChhY3Jvc3MgcGFja2V0cykgYmVjb21lcyB2ZXJ5IGVh c3kgJm5ic3A7YW5kIHByZWRpY3RhYmxlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj50aGF04oCZcyByZWFzb24gd2Ug cmVjb21tZW5kIHVzaW5nICZuYnNwOyggVGltZXN0YW1wKC8gc2VxdWVuY2UgbnVtYmVyKSAmIzQz OyBSTkQgKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBj bGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVy LWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgcGFkZGluZzogMGNt IDBjbSAwY20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9y ZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6IHJnYigxODEsIDE5 NiwgMjIzKTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGNtIDBjbTsiIGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNhc2hhbmsgRGFyYQ0KIChzYWRhcmEpIFs8YSBocmVmPSJt YWlsdG86c2FkYXJhQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bWFpbHRvOnNhZGFyYUBjaXNjby5jb208L2E+XTxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9 IiI+DQo8YiBjbGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgSnVseSAxOSwgMjAxNiAxOjExIEFNPGJyIGNsYXNz PSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5UYWwgTWl6cmFoaTsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSk7 PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpkcmFmdC1icm9ja25lcnMtcHJvb2Ytb2YtdHJhbnNpdEB0b29scy5pZXRmLm9yZyIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9 IiI+ZHJhZnQtYnJvY2tuZXJzLXByb29mLW9mLXRyYW5zaXRAdG9vbHMuaWV0Zi5vcmc8L2E+Ozxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGIg Y2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlJlOiBRdWVzdGlvbiByZWdhcmRpbmcgUHJvb2Ygb2YgVHJhbnNpdCBkcmFm dDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i IiBjbGFzcz0iIj4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPkRlYXIgVGFsLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xh c3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5UaGFuayB5b3UgZm9yIHlvdXIgaW50ZXJl c3QgaW4gb3VyIHdvcmsuIE1vcmUgaW5saW5lIHdpdGggW1NEXSAuLiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgd2lk b3dzOiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtc3BhY2luZzog MHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+UmlnaHQsIEkgYW0gcmVmZXJyaW5nIHRvIHRoZSBmb3JtZXIuIFRoZSBp bnRlZ3JpdHkgY2hlY2sgaXMgbm90IHRoZSBpc3N1ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB3aWRvd3M6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg d29yZC1zcGFjaW5nOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5MZXTigJlzIHNheSB3ZSBoYXZlOjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHdpZG93czogYXV0bzsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB3b3JkLXNwYWNpbmc6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPi0gUGFja2V0IEEg dGhhdCB3ZW50IHRocm91Z2ggdGhlIGNvcnJlY3QgcGF0aCBhbmQgaGFzIGEgY29ycmVjdCBQT1Qu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgd2lkb3dzOiBhdXRvOyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtc3BhY2luZzogMHB4OyIgY2xhc3M9IiI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+LSBQ YWNrZXQgQiB0aGF0IGRpZCBub3QgZ28gdGhyb3VnaCB0aGUgY29ycmVjdCBwYXRoIGFuZCBkb2Vz IG5vdCBoYXZlIGEgY29ycmVjdCBQT1QuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgd2lkb3dzOiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtc3Bh Y2luZzogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgd2lkb3dzOiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQt c3BhY2luZzogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+VGhlIGF0dGFja2VyIGNhbiDigJhsYXVuZGVy4oCZIHBh Y2tldCBCIGJ5IHJlcGxhY2luZyB0aGUgKGluY29ycmVjdCkgUE9UIG9mIHBhY2tldCBCIHdpdGgg dGhlIGNvcnJlY3QgUE9UIG9mIHBhY2tldCBBIChhbmQgZHJvcCBwYWNrZXQgQSkuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgd2lkb3dzOiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHdvcmQtc3BhY2luZzogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+VGh1cywgcGFja2V0 IEIgaXMgdmVyaWZpZWQgY29ycmVjdGx5LCBldmVuIHRob3VnaCBpdCBkaWQgbm90IGdvIHRocm91 Z2ggdGhlIGNvcnJlY3QgcGF0aC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5bU0RdIFRoaXMgaXMg dmFsaWQgc2NlbmFyaW8gYW5kIHdlIGhhdmUgY2VydGFpbiBpbi1idWlsdCBtaXRpZ2F0aW9uIHRl Y2huaXF1ZXMgYW5kIHJlY29tbWVuZGF0aW9ucyBmb3IgdGhlIHNhbWUuJm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPlRoZXJlIGFyZSB0d28gc2NlbmFyaW9zIGhlcmUmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPlBhcnRpYWwgUmVwbGF5IG9mIFBPVCBkYXRhIChSZXBs YXlpbmcgaW50ZXJtZWRpYXRlIENNTHMpPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+QXR0YWNrZXIgY2Fubm90IHJldXNlIGZldyBpbnRlcm1lZGlhdGUgbm9kZeKAmXMgUE9UIHZh bHVlcyAoZnJvbSBvbGRlciBwYWNrZXQgdHJhY2VzKSBhcyBpdCB3b3VsZCBkaXNydXB0IHRoZSBQ T0xZLTMgY29uc3RydWN0aW9uLiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5PbiB0aGUgb3RoZXIgaGFuZCBp ZiB0aGUgYXR0YWNrZXIgdHJpZXMgdG8gcmVwbGF5IGVudGlyZSBzZXF1ZW5jZSBvZiBDTUwgdmFs dWVzLCBoZSBjYW5ub3Qgc3RpbGwgLCBiZWNhdXNlIG5vdGljZSB0aGF0IHZlcmlmaWVyIGFsc28g aGFzIGEgc2VjcmV0IHNoYXJlIG9mIFJORC0xIGFuZCBwYXJ0aWNpcGF0ZXMNCiBpbiB0aGUgcmVj b25zdHJ1Y3Rpb24gb2YgUk5ELTMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBj bGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPlZlcmlmaWVy4oCZcyBzaGFyZSBvZiBS TkQtMyBpcyBuZXZlciBvbiB3aXJlICwgc28gYXR0YWNrZXIgY2Fubm90IGp1c3Qgb2JzZXJ2ZSB0 aGUgcGFja2V0IHRyYWNlcyB0byByZXVzZSBhbmQgcmVwbGF5IGl0LiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+VG90YWwgUmVwbGF5IG9mIFBPVCBkYXRh IChSZXBsYXlpbmcgY29tcGxldGUgUk5ELTIpPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+QW5vdGhlciB0cmljaywgYXR0YWNrZXIgY291bGQgZG8gaXMgYnkgY29tcGxldGVseSBy ZXVzaW5nIFJORC0yIChidXQgbm90IGludGVybWVkaWF0ZSBDTUwgdmFsdWVzKTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij5JbiBvcmRlciB0byBwcmV2ZW50IHRoZSDigJxSZXBseSBBdHRhY2tz4oCdICwgd2UgcmVjb21t ZW5kIHRoYXQgdGhlIFJORC0yIChnZW5lcmF0ZWQgcGVyIHBhY2tldCkgYmUgYSBjb21iaW5hdGlv biAoSS5lLiBSTkQyID0g4oCcVGltZSBTdGFtcCAmIzQzOyBSTkQgbnVtYmVy4oCdKTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj5TbyBpbiBjYXNlIGEgcGFzc2l2ZSBhdHRhY2tlciB0cmllcyB0byByZXBsYXkgb25lIG9m IHRoZSBjb3JyZWN0IGJ1dCBvbGRlciBSTkQtMiwgdGhlIHZlcmlmaWVyIGZpcnN0IGNvdWxkIGNo ZWNrIHRoZSBjdXJyZW50IHRpbWVzdGFtcCBhZ2FpbnN0IHRoZSB0aW1lc3RhbXAgcmV0cmlldmVk IGZyb20NCiBSTkQtMi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIi PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+SWYgdGhlIHJldHJpZXZlZCB0aW1lc3RhbXAgaXMg b2xkZXIgdGhhbiBjdXJyZW50IHRpbWVzdGFtcCB3ZSBkcm9wL3JhaXNlIGEgZmxhZyAhJm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xh c3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5UaGVyZSBpcyBzdGlsbCBhIHNtYWxsIHdp bmRvdyAsIHdoZXJlIHRoZSBhdHRhY2tlciBjb3VsZCByZXBsYXkgaXQgd2l0aGluIHRoZSB2YWxp ZCB0aW1lIHNsaWNlIGl0c2VsZiBidXQgYnkgY2FyZWZ1bGx5IGNob29zaW5nIHRoZSB0aW1lIHNs aWNlIHdlIGNhbiBtYWtlIGl0IG5lYXJseSBpbXBvc3NpYmxlDQogZm9yIHRoZSBhdHRhY2tlciB0 byByZXBsYXkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZvciBleGFtcGxlICwgaWYgdGhlIFRpbWUgU3RhbXAgY2hv c2VuIGlzIDMyIGJpdHMgLCB3ZSBjb3VsZCBnZXQgb25lIHNlY29uZHMgbGV2ZWwgcHJlY2lzaW9u IGluIHRoZSB0aW1lIHdpbmRvdyAuIFNvIGl0IGlzIGhpZ2hseSBpbXBvc3NpYmxlIGZvciB0aGUg YXR0YWNrZXIgdG8gcmVwbGF5DQogd2l0aGluIHN1Y2ggYSBzbWFsbCB0aW1lIGF0IHN1Y2ggYSBo aWdoIHBhY2tldCByYXRlcy4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIi IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkFs c28gLCB0aGUgdmVyaWZpZXIgY291bGQgY2FjaGUsIGlmIG5lZWRlZCwgY2VydGFpbiBudW1iZXIg b2YgcHJldmlvdXNseSB1c2VkIFJORC0yIHRvIG1pdGlnYXRlIHJlcGxheSBhdHRhY2tzLiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+SG9wZSB0aGlzIGNsYXJpZmllcy4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBj bGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBMdWNpZGFHcmFuZGU7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEx1Y2lkYUdyYW5kZTsgZm9udC1zaXplOiAx MXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBMdWNpZGFHcmFuZGU7IGZvbnQtc2l6ZTogMTFweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnNmYw0KIG1haWxpbmcgbGlzdDwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBMdWNpZGFHcmFuZGU7IGZvbnQtc2l6ZTogMTFweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29y YXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEx1Y2lkYUdyYW5kZTsgZm9udC1zaXplOiAx MXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPnNm Y0BpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBMdWNpZGFHcmFuZGU7IGZvbnQt c2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQt ZmFtaWx5OiBMdWNpZGFHcmFuZGU7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYzwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCi0tPGJyIGNsYXNzPSIiPg0KJnF1b3Q7RXN0YSB2 ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KRHIgRGllZ28gUi4gTG9wZXo8YnIgY2xhc3M9IiI+DQpUZWxlZm9uaWNhIEkm IzQzO0Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5s b3Blei8iIGNsYXNzPSIiPmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6LzwvYT48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmlj YS5jb208YnIgY2xhc3M9IiI+DQpUZWw6ICZuYnNwOyAmbmJzcDsmIzQzOzM0IDkxMyAxMjkgMDQx PGJyIGNsYXNzPSIiPg0KTW9iaWxlOiAmIzQzOzM0IDY4MiAwNTEgMDkxPGJyIGNsYXNzPSIiPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNv bG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2Ug ZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIg aW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4 Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3Rl ZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYQ0K IGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3Jp emFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOz biB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dh bW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbD rWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2Fn ZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwNCiBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlz IGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1t ZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg Y29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuPGJyPg0KPGJyPg0KRXN0 YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1 IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3Ug Y29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFk ZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBp bmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhDQogbGVpdHVyYSwgdXRpbGl6YcOnw6Nv LCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBw cm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVz dGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1l ZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Oj bzxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F40A6DC030A64CB79DE8C8DAA3258CE3telefonicacom_-- From nobody Wed Aug 31 01:19: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 43FC412DA07 for ; Wed, 31 Aug 2016 01:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.749 X-Spam-Level: X-Spam-Status: No, score=-104.749 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=-0.548, 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 vSMyqG1kYQsi for ; Wed, 31 Aug 2016 01:19: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 06A6E12DA0A for ; Wed, 31 Aug 2016 01:19:02 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 0F3F0104AA31; Wed, 31 Aug 2016 16:18:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u7V8IiUV066108; Wed, 31 Aug 2016 16:18:44 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <147196725260.30794.10266895117462060916.idtracker@ietfa.amsl.com> References: <147196725260.30794.10266895117462060916.idtracker@ietfa.amsl.com> To: "Paul Quinn (paulq)" , uri.elzur@intel.com MIME-Version: 1.0 X-KeepSent: 6A19F345:6E1F79A3-48258020:002C63D4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.cui1@zte.com.cn Date: Wed, 31 Aug 2016 16:19:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-08-31 16:18:24, Serialize complete at 2016-08-31 16:18:24 Content-Type: multipart/alternative; boundary="=_alternative 002DAC1248258020_=" X-MAIL: mse01.zte.com.cn u7V8IiUV066108 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-nsh-07.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, 31 Aug 2016 08:19:05 -0000 This is a multipart message in MIME format. --=_alternative 002DAC1248258020_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgZWRpdG9ycywNCg0KIEkgaGF2ZSBhIGNsYXJpZmljYXRpb24gY29tbWVudCBhYm91dCB0aGUg Zm9sbG93aW5nIHRleHQ6DQoNCiAgICBTZWN0aW9uIDcuMiBNYXBwaW5nIE5TSCB0byBOZXR3b3Jr IFRyYW5zcG9ydA0KICAgIC4uLi4uLg0KICAgIDIuIE5leHQgU0YgaXMgbG9jYXRlZCBhdCBTRkZj IHdpdGggbXVsdGlwbGUgbmV0d29yayBsb2NhdG9ycyBmb3IgbG9hZCANCmRpc3RyaWJ1dGlvbiBw dXJwb3NlczoNCiAgICAgICAgU0ZGYiBtYXBwaW5nOiBTUEk9MTAgLS0+IFZYTEFOLWdwZSwgDQpk c3RfaXA6MjAzLjAuMTEzLjEsMjAzLjAuMTEzLjIsMjAzLjAuMTEzLjMsIGVxdWFsIGNvc3QNCg0K Q291bGQgeW91IGFkZCBzb21lIHRleHQgb3IgYWRkIGEgZmlndXJlIHRvIGlsbHVzdHJhdGUgdGhp cyBleGFtcGxlIGNsZWFybHkgDQo/IEl0IHNlZW0ga2luZCBvZiBjb25mdXNpbmcgaG93IGEgU0ZG YyBoYXMgbXVsdGlwbGUgbmV0d29yayBsb2NhdG9ycyBmb3IgDQpMQi4NCg0KVGhhbmtzLA0KDQpC UnMsDQpMaW5kYSBXYW5nDQogDQoic2ZjIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+INC009ogMjAx Ni8wOC8yMyAyMzo0NzozMjoNCg0KPiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQo+ILeivP7I yzogICJzZmMiIDxzZmMtYm91bmNlc0BpZXRmLm9yZz4NCj4gDQo+IDIwMTYvMDgvMjMgMjM6NDcN Cj4gDQo+IMrVvP7Iyw0KPiANCj4gPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4sIA0KPiANCj4gs63L zQ0KPiANCj4gc2ZjQGlldGYub3JnDQo+IA0KPiDW98ziDQo+IA0KPiBbc2ZjXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXNmYy1uc2gtMDcudHh0DQo+IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KPiBkaXJl Y3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2VydmljZSBGdW5j dGlvbiBDaGFpbmluZyBvZiB0aGUgSUVURi4NCj4gDQo+ICAgICAgICAgVGl0bGUgICAgICAgICAg IDogTmV0d29yayBTZXJ2aWNlIEhlYWRlcg0KPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFBh dWwgUXVpbm4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBVcmkgRWx6dXINCj4gICAgRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1zZmMtbnNoLTA3LnR4dA0KPiAgICBQYWdlcyAgICAg ICAgICAgOiAzNw0KPiAgICBEYXRlICAgICAgICAgICAgOiAyMDE2LTA4LTIzDQo+IA0KPiBBYnN0 cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBOZXR3b3JrIFNlcnZpY2UgSGVh ZGVyIChOU0gpIGluc2VydGVkIG9udG8NCj4gICAgcGFja2V0cyBvciBmcmFtZXMgdG8gcmVhbGl6 ZSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzLiAgTlNIIGFsc28NCj4gICAgcHJvdmlkZXMgYSBtZWNo YW5pc20gZm9yIG1ldGFkYXRhIGV4Y2hhbmdlIGFsb25nIHRoZSBpbnN0YW50aWF0ZWQNCj4gICAg c2VydmljZSBwYXRoLiAgTlNIIGlzIHRoZSBTRkMgZW5jYXBzdWxhdGlvbiByZXF1aXJlZCB0byBz dXBwb3J0IHRoZQ0KPiAgICBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIEFyY2hpdGVj dHVyZSAoZGVmaW5lZCBpbiBSRkM3NjY1KS4NCj4gDQo+IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtbnNoLw0KPiANCj4gVGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXNmYy1uc2gtMDcNCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtc2ZjLW5zaC0wNw0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0Kc3VibWlzc2lv bg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K --=_alternative 002DAC1248258020_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkhpIGVkaXRvcnMsPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDtJIGhhdmUgYSBjbGFyaWZpY2F0aW9u IGNvbW1lbnQgYWJvdXQNCnRoZSBmb2xsb3dpbmcgdGV4dDo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgU2VjdGlvbiA3LjIgTWFwcGlu ZyBOU0ggdG8NCk5ldHdvcmsgVHJhbnNwb3J0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7IC4uLi4uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyAyLiBOZXh0IFNGIGlzIGxvY2F0ZWQgYXQNClNG RmMgd2l0aCBtdWx0aXBsZSBuZXR3b3JrIGxvY2F0b3JzIGZvciBsb2FkIGRpc3RyaWJ1dGlvbiBw dXJwb3Nlczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBTRkZiIG1hcHBpbmc6DQpTUEk9MTAgLS0mZ3Q7IFZYTEFOLWdw ZSwgZHN0X2lwOjIwMy4wLjExMy4xLDIwMy4wLjExMy4yLDIwMy4wLjExMy4zLCBlcXVhbA0KY29z dDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+Q291bGQgeW91 IGFkZCBzb21lIHRleHQgb3IgYWRkIGEgZmlndXJlDQp0byBpbGx1c3RyYXRlIHRoaXMgZXhhbXBs ZSBjbGVhcmx5ID8gSXQgc2VlbSBraW5kIG9mIGNvbmZ1c2luZyBob3cgYSBTRkZjDQpoYXMgbXVs dGlwbGUgbmV0d29yayBsb2NhdG9ycyBmb3IgTEIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJDYWxpYnJpIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJDYWxpYnJpIj5CUnMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxp YnJpIj5MaW5kYSBXYW5nPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtzZmMmcXVvdDsgJmx0 O3NmYy1ib3VuY2VzQGlldGYub3JnJmd0OyDQtNPaDQoyMDE2LzA4LzIzIDIzOjQ3OjMyOjxicj4N Cjxicj4NCiZndDsgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyC3orz+yMs6ICZuYnNwOyZxdW90O3NmYyZxdW90OyAmbHQ7c2Zj LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgMjAxNi8wOC8yMyAyMzo0NzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IMrVvP7IyzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZsdDtpLWQtYW5ub3VuY2VAaWV0Zi5vcmcmZ3Q7LCA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgc2ZjQGlldGYu b3JnPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM 4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFtzZmNd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc2ZjLW5zaC0wNy50eHQ8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPGJy Pg0KJmd0OyBkaXJlY3Rvcmllcy48YnI+DQomZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgb2YgdGhlDQpJRVRGLjxicj4NCiZndDsg PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KOiBOZXR3b3JrIFNlcnZpY2UgSGVhZGVyPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9ycyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgOg0KUGF1bCBRdWlubjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyBVcmkgRWx6dXI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IGRyYWZ0LWlldGYtc2ZjLW5zaC0wNy50eHQ8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDtQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogMzc8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtEYXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7OiAyMDE2LTA4LTIzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3Ry YWN0Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgTmV0 d29yayBTZXJ2aWNlIEhlYWRlciAoTlNIKQ0KaW5zZXJ0ZWQgb250bzxicj4NCiZndDsgJm5ic3A7 ICZuYnNwO3BhY2tldHMgb3IgZnJhbWVzIHRvIHJlYWxpemUgc2VydmljZSBmdW5jdGlvbiBwYXRo cy4NCiZuYnNwO05TSCBhbHNvPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7cHJvdmlkZXMgYSBtZWNo YW5pc20gZm9yIG1ldGFkYXRhIGV4Y2hhbmdlIGFsb25nIHRoZQ0KaW5zdGFudGlhdGVkPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7c2VydmljZSBwYXRoLiAmbmJzcDtOU0ggaXMgdGhlIFNGQyBlbmNh cHN1bGF0aW9uIHJlcXVpcmVkDQp0byBzdXBwb3J0IHRoZTxicj4NCiZndDsgJm5ic3A7ICZuYnNw O1NlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlIChkZWZpbmVkDQpp biBSRkM3NjY1KS48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7IDwvZm9udD48 L3R0PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt c2ZjLW5zaC8iPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1zZmMtbnNoLzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxi cj4NCiZndDsgPGJyPg0KJmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDo8YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMDciPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLW5zaC0wNzwvZm9udD48L3R0Pjwv YT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyBBIGRpZmYgZnJvbSB0aGUg cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zZmMt bnNoLTA3Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXNmYy1uc2gtMDc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0Kc3VibWlzc2lvbjxicj4N CiZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZndDsgPC9mb250Pjwv dHQ+PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPjx0dD48Zm9u dCBzaXplPTI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2ZvbnQ+PC90dD48 L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNmYyBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IHNmY0BpZXRmLm9yZzxicj4NCiZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYz48dHQ+PGZvbnQgc2l6ZT0y Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9mb250PjwvdHQ+PC9h Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 002DAC1248258020_=--